CMMI

INTRODUÇÃO

O projeto CMM Integration foi formado para solucionar os problemas de uso múltiplo dos CMMs em um framework único de melhoria, o framework CMMI. Apesar de o CMMI prover uma cobertura mais detalhada do ciclo de vida dos produtos que o uso isolado de outros processos de melhoria, ainda assim não pode ser visto como uma metodologia pronta para ser utilizada pelas organizações.

Cada organização deve mapear as áreas de processo do nível CMMI desejado à sua metodologia, aos seus métodos e técnicas de desenvolvimento de produtos e sistemas, levando também em consideração os objetivos de negócio da organização. Tanto o CMMI como as demais normas e modelos, dizem “o que” fazer e não “como” fazer. O CMM original era específico para a área de desenvolvimento de software, mas com o tempo foi surgindo a necessidade de achar um padrão também outras áreas. Para isso, foram criados diversos “CMMs”, que no fim, não seguiam os mesmos padrões entre si. Com isso, em 2002 foi lançado o CMMi (Capability Maturity Model Integration), sem abandonar o CMM original, que visa a integração de todos os CMMs, buscando corrigir as inconsistências existentes entre eles. O CMMi tem uma diferença básica em relação ao CMM, a dupla representação. Existe a Representação por Estágios e a contínua. A representação por Estágios é dividida em 5 Níveis, nos quais existem Áreas de Processo específicas por nível, e para progredir de nível a organização precisa cumprir os requisitos de cada nível mais os requisitos dos níveis anteriores. Já na Representação Continua, as Áreas de Processo são independentes dos níveis, sendo que uma Área pode estar em um nível e outra em outro.

RESUMO

Este material de estudo diz respeito a uma proposta a ser elaborada á empresa Software Developer, indicando a esta, como atender as áreas de processo definidas para alcançar o nível 2 de maturidade do CMMI.

Nos dias atuais algumas empresas desenvolvedoras de software criam sua própria metodologia de trabalho. Devido à concorrência, a preocupação das empresas está voltada muito mais na ênfase dos custos do que em qualidade agregada ao produto. O objetivo da pesquisa é abordar a melhoria nos processos de software segundo os principais modelos de qualidade e de maturidade de softwares existentes no mercado empresarial. Para obter vantagem competitiva, bem como a satisfação dos clientes, as empresas devem buscar a maturidade dos processos, eliminar as falhas operacionais e atualizar-se continuamente na tecnologia empregada. Isso requer uma interação das pessoas, dos processos e da empresa.

CMMI – NÍVEL 2

Em termos de sua implementação, cada nível do CMM é composto de um certo número de Áreas-Chave de Processo (PAs - Process Areas). Estas áreas descrevem as questões que devem ser abordadas e resolvidas para se alcançar aquele nível. Assim, por exemplo, uma organização pode dominar uma PA do nível três sem contudo estar sequer no nível dois em outras PAs. Em geral, considera-se que uma organização está em determinado nível caso todas as PAs definidas para aquele nível sejam cumpridas. Cada PA, portanto, identifica um conjunto de atividades que, tomadas em conjunto, permitem alcançar uma série de objetivos importantes para se obter uma melhoria de processo. As PAs do nível 2 são seis e estão listadas a seguir:

• Gerenciamento de Requisitos

• Planejamento de Projetos

• Acompanhamento e Supervisão de Projetos

• Gerenciamento de Subcontratação

• Garantia de Qualidade de Software

• Gerenciamento de Configuração

Gerenciamento de Requisitos

O propósito do Gerenciamento de Requisitos é estabelecer um entendimento comum entre o usuário e a equipe de projeto a respeito dos requerimentos que serão atendidos pelo projeto. Além disso, são estabelecidos procedimentos para a mudança dos requisitos, garantindo que os planos, cronogramas e recursos alocados estejam sempre coerentes com os requisitos.

Não é novidade para ninguém que nada é mais deletério para o prazo e qualidade de um projeto do que requisitos que mudam constantemente. A pior situação, porém, é quando estas mudanças (algumas vezes realmente necessárias, mas nem sempre) são aceitas pela equipe sem que prazos e recursos sejam revistos.

Para cumprir esta PA, a organização deve, em primeiro lugar, instituir procedimentos para a documentação dos requisitos. Estes requisitos devem também ser revisados por diversas áreas envolvidas (para verificar sua viabilidade) e ter sua qualidade controlada. Observe-se que a documentação dos requisitos e sua revisão devem ser feitas antes da elaboração do plano do projeto. Embora isto pareça óbvio, é impressionante ver a quantidade de gerentes de projeto que se comprometem com prazos antes de saber o que terão de fazer!

Em seguida, a organização precisa instituir procedimentos para a alteração dos requisitos. Isto significa que os requisitos não podem ser alterados "por telefone". A existência de um procedimento formal para alteração de requisitos têm dois benefícios: garante que os planos serão revistos para acomodar as alterações (isto é, renegociação de prazos e recursos) e funciona como um freio para alterações desnecessárias ou postergáveis (normalmente, a maioria), instituindo uma disciplina de controle de prioridades. Afinal, é impossível desenvolver software decente se os requisitos não forem "congelados" por algum tempo.

Planejamento de Projetos

O propósito desta PA é garantir que, a cada projeto, sejam elaborados planos razoáveis para o desenvolvimento. Isto envolve a realização de estimativas e o estabelecimento de compromissos. Também se incluem aqui atividades de gerenciamento de riscos e alocação de recursos. Para cumprir esta PA, a empresa deve instituir políticas e procedimentos padronizados para o planejamento de projetos. Estes procedimentos devem incluir, entre outras coisas, a necessidade de envolver todas as áreas interessadas (técnicas e usuárias) no processo de planejamento. Esta PA também pressupõe que a empresa tenha definido um ciclo de vida de sistemas para ser usado no planejamento. Estimativas, planejamento de projetos