Robson Martins

 

Faculdade Batista de Administração e Informática

Curso de Sistemas de Informação
Engenharia de Software I

Profª. Solange

Documento originado por:
Nome Número Matrícula
Cícero Marcelo da Silva 06 52
Granhan Bell de França Ribeiro 15 71
Robson S. Martins 33 48
Sandra R. C. Ramires 37 40
Revisão: 0 09/2000

 

Sumário

  • 1. Introdução
  • 2. Histórico
  • 3. Definições
  • 4. Processo de Certificação
  • 5. Estrutura do Modelo
  • 6. Áreas Chaves do Processo
  • 7. Bibliografia

 

1.Introdução

O Modelo de Maturidade da Capacitação (MMC) é o qualificador de processos desenvolvido pelo Instituto de Engenharia de Software da Universidade de Carnegie Mellon (SEI/CMU) (USA).

De acordo com os desenvolvedores do CMM, o que em geral ocorre é a falta de processo entre os profissionais ligados a um determinado projeto. Pois é essencial conhecer o projeto para que haja uma melhor compreensão do que irá ser desenvolvido.

Segundo o modelo de Maturidade de capacitação para software ou CMM, o que é correto fazer, é organizar as funções existentes nas empresas para que cada profissional se dedique a uma área especifica, sendo assim, quando ocorrer um problema com o software, saibam como proceder diante do problema surgido. O CMM também busca um melhoramento das empresas para que a cada nível a margem de erros sejam menor.

O CMM foi criado para ser adaptado a qualquer ambiente de trabalho, pois é isso o que ele sugere.

O CMM busca uma melhoria no processo, e enfatiza que é preciso conhecê-lo para melhor entendê-lo.

Portanto o CMM foi desenvolvido para auxiliar o profissional em software a ter total controle da situação, fazendo com que todos os que estão envolvidos no projeto sigam a risca um cronograma de trabalho para que possa prever o término no produto, e para fazer com que o índice de erro seja cada vez menor. Com isso, o gerente vai ter melhor credibilidade no mercado, vai adquirir uma alta qualidade e por fim terá uma empresa de ponta em matéria de software.

 

2. Histórico

Em 1986, o SEI/CMU iniciou o desenvolvimento de uma estrutura conceitual do processo de software, capaz de abranger grandes organizações, com diversos níveis hierárquicos. No ano seguinte, o Departamento de Defesa Americano contratou-os para a criação de um questionário preliminar sobre a maturidade do processo de desenvolvimento de software de empresas, com a finalidade de classificar as empresas que prestavam serviços ao departamento. Em agosto de 1991, foi divulgada a versão 1.0 de o Modelo de Maturidade de Capacitação, dois anos depois em fevereiro de 1993, saiu a versão 1.1 que até o momento.

 

3. Definições Básicas

Processo de software - é o conjunto de atividades, métodos e práticas e transformações que as pessoas utilizam para desenvolver, manter e evoluir software e seus artigos associados.

Capacitação do Processo - é a habilidade em produzir os resultados planejados.

Desempenho no Processo - verifica os reais resultados do planejado.

Maturidade do Processo - é quando um processo é definido e planejado para uma melhor capacitação da garantia do software, satisfazendo os índices necessário, produz um nível de maturidade elevado.

 

4. Processo de Certificação

  • Seleção da equipe de certificação - Os seus membros devem possuir conhecimentos sólidos nas áreas de Engenharia de Software e gerência. Assim mesmo devem ter o treinamento nos conceitos do MMC e em suas metodologias de trabalho.
  • Aplicação do Questionário de Maturidade - assim como outros instrumentos de diagnostico.
  • Análise das respostas.
  • Visita ao local a ser certificado - Faz-se entrevistas, revisões de documentações, principalmente nas áreas chaves do processo.
  • Emissão do Laudo baseado no MMC. - Aqui se realiza o julgamento acerca da satisfação ou não dos requisitos do modelo, identificação dos pontos fortes e fracos da organização.
  • Identificação das áreas que satisfazem ou não as metas das áreas chaves do processo, previstas no Modelo de Maturidade de Capacitação.

 

5. Estrutura do Modelo

É formada pelas áreas chave de processo (ACPS) que indica o nível de maturidade de cada nível.

Cada nível corresponde a várias áreas chaves. Só pode passar de um nível para outro depois que cumpriu todas as exigências assim determinadas.

Um nível é um alvo a ser alcançado de maneira tal que aumente a maturidade do software. Quando um desses alvos é alcançado foi satisfeita mais uma exigência na maturidade do software.

De acordo com o CMM todas as ACP tem que ser alcançada, pois se falta apenas uma a empresa estará ainda no nível inferior.

Conforme a CMM a empresa não precisa passar para o próximo nível para começar a utilizar as ACP's deste nível mais elevado, pois é recomendado que faça isso para que se tenha uma melhor qualidade de software.

  • Nível 1 - Inicial

Neste nível a empresa não tem uma organização bem definida, mas isto não significa que produza software de baixa qualidade, mas sim satisfatório.

Neste nível ocorre muito, uma grande falta de tempo quanto a disponibilidade dos profissionais envolvidos no projeto, com isso aumenta o índice de manutenção, pois as pessoas envolvidas no projeto abandonam com facilidade as regras já estabelecidas e partem para mais adiante fazendo com que gere um índice muito alto de desorganização e manutenção.

  • Nível 2 - Repetitivo

Neste nível o Gerente tem mais controle do projeto, consegue organizar as funções de cada profissional, se baseia em projetos anteriores, com isso tornando mais acessível a condução do projeto.

Neste nível é possível já ver o projeto em questão, com isso torna mais fácil detectar os possíveis erros do processo.

  • Nível 3 - Definido

Neste nível já está definido todas as partes da organização, tornando assim um processamento padrão. A equipe já está estabelecida e com isto ficando mais acessível a produção de software. O cronograma e a funcionalidade já estão sob controle, já está sendo tudo documentado em matéria de software facilitando o controle total da situação, a linha de produção é acompanhada.

Isto tudo sendo executado pela organização e não pelas pessoas.

  • Nível 4 - Gerenciado

Neste nível o Gerente é capaz de dizer qual será a margem de erro de acordo com o desenvolvimento do produto. E o cliente passa tomar conhecimento dos fatos antes do projeto ser iniciado. São estabelecidas metas para ser cumpridas que envolvem todos os projetos, fazendo assim, buscar cada vez mais um aperfeiçoamento dos projetos.

Os limites determinados são superados dentro do estabelecido.

  • Nível 5 - Otimização

Neste nível, os gerentes tentam novas formas no desenvolvimento de software para que se torne mais rápida a fabricação e mais acessível acompanhar as modificações no processo. A organização trabalha sempre envolvida com pessoas, para que com isso melhore a tecnologia e medições, buscando uma melhora contínua no processo. A organização é capaz de identificar pequenas falhas e prevenir-se de eventuais problemas. É feita uma abordagem para buscar novos benefícios para a organização. É analisado os defeitos para ver suas causas e exterminá-lo. Toda a organização fica sabendo dos novos procedimentos. Embora os desperdícios ocorram em todos os níveis, é neste nível que se dá maior importância para os retrabalhos. Ocorre um melhoramento continuo das atividades.

 

6. Áreas Chaves do Processo (ACP's)

As áreas-chaves do processo (ACP's) é formada das práticas - chaves ou, melhor dizendo, procedimento que tem que ser adotado para que se atinja uma meta.

As práticas-chaves só são encontradas no segundo nível, pois no primeiro não é exigido uma organização estabelecida.

Os objetivos nos níveis são:

  • nível 1: não possui ACP,
  • nível 2: estabelecer controles básicos de Gerência,
  • nível 3: fundir as técnicas e gerencia em um único processo,
  • nível 4: entender quantitativamente o processo de software, bem como os artefatos produzidos,
  • nível 5: manter de maneira contínua, a melhoria do processo.

As ACP's são divididas em duas partes, as de projetos e as de organização, a segunda é mais detalhada.

As práticas-chaves são independentemente de qualquer modificação, tem que usar rotineiramente para que os objetivos sejam alcançados. Essas práticas-chaves são divididas em atividades que precisam ser implementados para garantir a capacitação do processo e infra-estrutura que usa as práticas descritas nas atividades.

Características comuns: são infra-estruturas que compõe compromisso em executar, habilitação para executar medição e análise verificação da implementação. A outra é atividade que compõe atividade a realizar.

  • Descrição: é a forma que a ACP e implementada
  • Metas: é o que auxilia na prática para alcança-la
  • Características comuns: é descrita no mínimo uma prática- chave, que consiste numa sentença única.
  • Recomendações: sugere treinamento para utiliza as ACP
  • Produtos gerenciados e controlados: precisam ter um controle sobre suas alterações e versos.
  • Procedimentos Documentados: documentos para executar uma determinada atividade.
  • Perfil das(ACP's): é feita uma análise do que foi obtido no todo com isso ilumina o que não é aproveitado e utiliza somente o necessário, com isso tem-se uma melhoria no processo.

 

6.1. ACP'S nos Níveis de Maturidade

6.1.1. Nível 2 - Repetitivo
6.1.1.1 Gerência de Requisitos

Tem a função de gerenciar requisitos, e determiná-los no processo de desenvolvimento de software. Esses requisitos não se referem apenas à funcionalidade desejada para um sistema ou software, mas também se referem a questões não funcionais, requisitos inversos. Portanto, existem dois conceitos para estas definições:

  • Requisitos Funcionais: especificam as funções que o sistema ou componente do sistema deve ser capaz de executar.
  • Requisitos não Funcionais: são relacionados, entre outros com:
    • Acurácia: exatidão de dados e resultados.
    • Precisão: número de algarismos de cálculo; número de caracteres de um nome.
    • Confiabilidade: verificar se o artefato produz resultados corretos, precisos e acurados.
    • Segurança: verifica, os riscos pessoais, materiais ecológicos ou financeiros oferecido pelo artefato, são compatíveis com a do serviço.
    • Desempenho: o desempenho de hardware e do software com a funcionalidade ao ambiente em que vai ser utilizado.
    • Rentabilidade: o retorno financeiro após a implantação do sistema.
    • Manutenibilidade: o artefato está apto para ser fácil, rápida e corretamente mantido.
    • Disponibilidade: o artefato está pronto para ser utilizado quando necessário.
    • Recuperabilidade: o artefato permite a recuperação em caso de erros e acidentes.

O processo de determinar requisitos é chamado de: Processo de Definição de Requisitos, que tem a função de desenvolver ou evoluir um determinado sistema com êxito. Essas definições de requisitos são divididas em algumas partes:

  • Identificação dos Requisitos.
  • Identificação das Restrições de Desenvolvimento de Software.
  • Análise de Requisitos
  • Representação de Requisitos
  • Comunicação de Requisitos
  • Preparação de validação de Requisitos se Software
  • Gerenciar o Processo de Definição de Requisitos

Finalidade: estabelecer e manter um acordo com o cliente com relação dos requisitos a serem observados no projeto de software para que haja um entendimento entre ambas as partes.

Os clientes podem ser o grupo de engenharia de sistemas, o grupo de marketing, outra organização interna ou um cliente externo. Dessa forma o sistema que pode ser de hardware de software ou ambos, deve ser participado em uma hierarquia de elementos. Cada requisito de sistema deve ser alocado a estes elementos, por exemplo, subsistemas, programas. Chama-se esta tarefa de alocação de requisitos, e este é fundamental para realizar o acompanhamento e rastreabilidade dos requisitos. Existe:

  • Requisitos do Sistema: Definem o comportamento do sistema do ponto de vista do usuário.
  • Requisitos do Sistema Alocados para o Software: São um subconjunto dos Requisitos do Sistema e serão implementados nos componentes de software do sistema. Os requisitos alocados são a primeira entrada para elaborar o projeto de software.
  • Requisitos de Software: condição ou capacitação que deve ser contemplada pelo software, necessitada pelo usuário para resolver um problema ou alcançar um objetivo.

A análise e a alocação dos requisitos de sistema ou software, hardware, ou a outros componentes do sistema, pode ser feita por um grupo externo ao grupo de engenharia de software ( por exemplo, o grupo de engenharia de sistemas ). Porem, este obtém a responsabilidade de associar os requisitos ao projeto do software.

 

6.1.1.2. Planejamento do Projeto de Software

Finalidade: é estabelecer plano exeqüível para desenvolver um determinado software, bem como para gerenciar o projeto de desenvolvimento de software segundo estes planos.

Inicia com a Declaração dos Trabalhos que visa identificar os artefatos de software a serem desenvolvidos, estimar o tamanho desses artefatos, estimar os recursos necessários para produzi-los, produzir o cronograma, identificar e avaliar os riscos inerentes ao projeto e negociar os compromissos.

O plano provê as bases para a execução e a gerência das atividades do projeto de desenvolvimento software, contempla os compromissos junto ao cliente do projeto de software do acordo com os recursos, as restrições e as capacidades do projeto de software.

 

6.1.1.3. Supervisão e Acompanhamento do Projeto de Software

Finalidade de supervisionar e acompanhar um projeto de software, fornecendo uma visão realista do efetivo progresso do projeto, permitindo que a gerência de desenvolvimento possa tomar ações eficazes quando o desempenho do projeto desvia-se de forma significativa dos planos de software.

Também, envolve acompanhar e revisar a execução e os resultados do desenvolvimento, confrontando-os com as estimativas documentadas.

Ao verificar-se que os planos do projeto de software não refletem satisfatoriamente a sua execução, devem ser tomadas ações corretivas. Tais ações podem incluir a revisão do plano de desenvolvimento de software, de modo que reflita a execução real ou o replanejamento do trabalho restante, ou a tomada de ações para aprimorar o desempenho na execução do desenvolvimento.

 

6.1.1.4. Garantia de Qualidade de Software

Propósito: é fornecer a gerência a visibilidade da eficácia, no sentido de produzir software de qualidade, do processo sendo utilizado pelo projeto de desenvolvimento de software e da qualidade dos artefatos que estão sendo criados.

A GQS envolve rever e auditar os artefatos e atividades de software de maneira a verificar se estão de acordo com os procedimentos e padrões aplicáveis, bem como prover os resultados dessas auditorias e revisões do projeto de software e aos gerentes envolvidos.

O grupo GQS trabalha junto com o projeto de software já durante seus estágios iniciais estabelecendo planos, padrões e procedimentos, que irão adicionar valor ao projeto de software através da Garantia de Qualidade de Software, no qual muitas informações podem ser conseguidas para beneficiar a organização. 

No entanto, o papel e as atividades do grupo de GQS precisam estar bem definidos antes de iniciar o trabalho, por muitas vezes este grupo é visto pelos desenvolvedores como um grupo que trará mais burocracia do que ajuda. O CMM tenta trabalhar este ponto através da comunicação regular entre engenheiros de software, gerentes de projeto, gerência sênior e clientes, informando-os quanto aos resultados obtidos durante revisões e auditorias.

 

6.1.1.5. Gerência de Configuração de Software

Finalidade: estabelece e mantém a integridade dos produtos de software ao longo do ciclo de vida de software.

Envolve: identifica a configuração de software, artefatos de software selecionados e sua descrição, em um dado momento, controla sistematicamente as mudanças na configuração, mantém através da gerência, a integridade e rastreabilidade da configuração ao longo do ciclo de vida de software, controla a integridade de artefatos compostos, levando em conta a versão de cada um dos componentes, ou seja, controla a configuração do artefato composto, registra e relata o estado do processo de alteração.

  • Configuração: conjunto de características físicas e funcionais de hardware e software.
  • Itens de configuração: partes de um todo, cada qual com seu aspecto próprio de configuração.
  • Gerenciado e controlado: implica que a versão do artefato em uso é conhecida - controle de versão.
  • Sob gerência de configuração: implica que o artefato necessita de um grau maior de controle.
  • Baseline: conjunto de artefatos formalmente aceitos.
  • Biblioteca de baselines de software: repositório que armazena várias baselines.
  • Sistema de biblioteca de gerência de configuração: conjunto de ferramentas e procedimentos usados para acessar ou manipular a biblioteca de baselines de software.

 

6.1.1.6. Gerência de Contrato de Software

Finalidade: seleciona contratadas de software qualificadas e gerenciá-las efetivamente.

Envolve: seleciona uma contratada de software, estabelece compromissos com a mesma, acompanha e revisa os seus resultados e desempenho.

 

6.1.2 Nível 3 - Definido
6.1.2.1 Foco no Processo da Organização

Finalidade: estabelece a responsabilidade organizacional para as atividades de processo de software.

Envolve: cria e mantém um entendimento dos processos de software dos projetos e da organização e coordenar as atividades para avaliar, desenvolver, manter e melhorar esses processos.

Processo de Software Padrão da Organização: definição operacional do processo básico que visa o estabelecimento de um processo de software comum a todos os projetos de software na organização.

Ativos do Processo de Software da Organização: entidades mantidas pela organização e usadas pelos projetos para o desenvolvimento, adaptação, manutenção e implementação de seus processos de software.

 

6.1.2.2 - Gerência de Software Integrada

Finalidade: é integrar as atividades de engenharia e de gerência em um processo coerente e bem definido, e que é adaptado a partir do processo de software padrão da organização, em suma, é fundir as ações técnicas e gerenciais em um único processo.

Suas práticas estão estabelecidas com base na ACP - Planejamento do Projeto de Software e Supervisão e Acompanhamento do Projeto de Software, que focalizam a identificação de problemas quando estes acontecem, e conduzem o ajuste dos planos ou do desempenho do processo de modo a contemplar os problemas identificados.

A ênfase da GSI é antecipar problemas e agir prevenindo ou minimizando os efeitos destes problemas, documentando todos os procedimentos.

As organizações, neste nível, planejam e gerenciam baseadas em um processo que acumulou as melhores práticas.

 

6.1.2.3 - Engenharia de Produtos de Software

Finalidade: é executar de forma consistente um processo de engenharia bem definido, que integra todas as atividades, para produzir, de maneira eficaz e eficiente, produtos de software corretos.

Envolve: executar as tarefas de engenharia para desenvolver e manter o software, usando o processo definido de projeto, bem como métodos e ferramentas apropriados.

Tarefas: analisar, desenvolver, projetar o design, implementar o código, integrar os componentes, gerar a documentação técnica e a destinada ao usuário e testar o software de maneira a verificar se satisfazem os requisitos especificados.

Métodos: fornecem as informações relativas à "como fazer", que deverão ser utilizados ao construir software.

Ferramentas: fornecem o suporte automatizado ou semi-automatizado, para o processo e para os métodos.

À medida que as tarefas vão sendo executadas, uma série de artefatos são gerados e alterados, estes devem ser passados ao controle de qualidade estabelecido na revisão por parceiros.

Documentação: necessária para executar as tarefas é desenvolvida e revisada para assegurar que cada tarefa aborde os resultados produzidos sejam apropriados para as tarefas subseqüentes, incluindo as tarefas de operação e manutenção de software.

Revisão por terceiros: revisam, refletem qualquer alteração aprovada nas atividades, processos, compromissos, planos e artefatos envolvidos.

 

6.1.2.4 Coordenação Entre Grupos

Finalidade: é necessário que haja uma relação entre os grupos envolvidos para que no final do sistema os requisitos e objetivos sejam a base das atividades de engenharia.

Envolve: a equipe de tal modo que a engenharia de software está totalmente ligada para assim com o cliente.

Estabelece: um total envolvimento entre os grupos de engenharia de software, engenharia de hardware e outros departamentos que estejam envolvidos no projeto. Para habilitar e satisfazer efetivamente, as necessidades dos clientes com o grupo em si, para que os requisitos, objetivos, e planos tornem-se a base de todas as atividades de engenharia.

Entre os Grupos são trocadas informações para melhor conduzir o projeto até o final, são as características principais da ACP.

 

6.1.2.5 Programa de Treinamento

Finalidade: estabelece um treinamento especifico para as pessoas envolvidas para que haja uma melhor operação do software, esse treinamento visa um melhoramento nos envolvidos. São determinados os prazos de treinamento para as instituições.

Esses treinamentos visam viabilizar as necessidades da empresa para que seja feita uma abordagem da área que necessita de treinamento.

 

6.1.2.6 Revisões por Parceiros

Finalidade: é a revisão que é feita, um parceiro verifica o serviço realizado por outro, a fim de eliminar erros no projeto e não para ver as causas dos problemas.

Essa verificação é feita em reuniões que são marcadas periodicamente, para assim tomar cada vez melhor a qualidade do software.

 

6.1.3. Nível 4 - Gerenciado
6.1.3.1 Gerência Qualidade de Software

Finalidade: desenvolver um entendimento quantitativo de qualificar do projeto de software e realizar metas especificas de qualidade.

Aplica em compreender um programa de medidas para produzir o software descrito na Engenharia de Produtos de Software.

 

6.1.3.2 Gerência Quantitativa de Processo

Finalidade: é controlar o processo no desempenho do projeto de software, analisar, efetuar e alcançar os processos estabelecidos de software.

Baseia-se nas práticas de Gerência de Software, Engenharia de Produto de Software e também na Gerencia Qualidade de Processo.

 

6.1.4. Nível 5 - Otimização
6.1.4.1 Prevenção de Defeitos

Finalidade: faz um acompanhamento dos defeitos que foram encontrados para que seja feita uma prevenção fazendo com que haja sempre um aperfeiçoamento dos projetos de processo de software.

A Prevenção de Defeitos envolve uma série de ACP's vistos nos níveis anteriores como o Gerente de Software integrada, Engenharia de Produto de Software, Gerencia de Mudanças de Processo, que envolve todos os produtos já realizados que são analisados para que não ocorra os erros que já ocorreram anteriormente.

 

6.1.4.2 Gerência de Mudança da Tecnologia

Finalidade: busca novas ferramentas no mercado para melhor desenvolver software, ou para dar manutenção.

O grupo analisa novas ferramentas para assim ter uma boa tecnologia na produção de software.

 

6.1.4.3 Gerência de Mudança do Processo

Finalidade: melhorar o processo de software, é usado um programa de treinamento continuo, para buscar uma melhor atuação dos participantes da organização.

É montado um projeto de aprimoramento de software para averiguar os processos antes de serem implantados na organização. É feita uma revisão do projeto e analisado para que futuramente se torne padrão é assim a organização esteja sempre aprimorando seus projetos.

 

7. Bibliografia

1. Paulk, Mark C. et al. Capability Maturity Model for Software, Verson 1.1, Pittsburg Pensylvania,Technical Report CMU/SEI-93-TR-024, 1993.

2. Fiorini, Soeli T. et al. Engenharia de Software com CMM, Rio de Janeiro, Brasport Livros e Multimídia, 1999.

3. http://www.les.inf.puc-rio.br/~wcourse/socinfo/nestor/cuerpo.htm#PMC93