Capability Maturity Model – Wikipédia, a enciclopédia livre

Capability Maturity Model (CMM ou Modelo de Maturidade em Capacitação), também conhecido como Software CMM (SW-CMM) pode ser definido como sendo uma soma de "melhores práticas" para diagnóstico e avaliação de maturidade do desenvolvimento de softwares em uma organização. "CMM" não deve ser entendido como sendo uma metodologia, pois o "CMM" não diz exatamente como fazer, mas sim o que deve ser feito (melhores práticas).

Ele descreve os principais elementos de um processo de desenvolvimento de software. O CMM descreve os estágios de maturidade por que passam as organizações enquanto evoluem no seu ciclo de desenvolvimento de software, através de avaliação contínua, identificação de problemas e ações corretivas, dentro de uma estratégia de melhoria dos processos. Este caminho de melhoria é definido por cinco níveis de maturidade:

1. Inicial
2. Repetitivo
3. Definido
4. Gerenciado Quantitativamente
5. Em Otimização

O CMM fornece às organizações orientação sobre como ganhar controle do processo de desenvolvimento de software e como evoluir para uma cultura de excelência na gestão de software. O objetivo principal nas transições através desses níveis de maturidade é a realização de um processo controlado e mensurado que tem como fundamento a melhoria contínua. A cada nível de maturidade corresponde um conjunto de práticas de software e de gestão específicas, denominadas áreas-chave do processo (KPAs - Key Process Areas). Estas devem ser implantadas para que a organização possa atingir o nível de maturidade desejado.

O CMM surgiu durante a década de 1980 como um modelo para avaliação de risco na contratação de empresas de software pelo Departamento de Defesa dos Estados Unidos que desejava ser capaz de avaliar os processos de desenvolvimento utilizados pelas empresas que concorriam em licitações como indicação da previsibilidade da qualidade, custos e prazos nos projetos contratados. Para desenvolver esse processo, o DOD constituiu junto a Carnegie-Mellon University o SEI (Software Engineering Institute), o qual além de ser responsável pela evolução da família CMM, realiza diversas outras pesquisa em engenharia de software.

Um modelo de maturidade é uma coleção estruturada de elementos que descrevem certos aspectos da maturidade de uma organização. Um modelo de maturidade fornece, por exemplo:

• um ponto de partida
• os benefícios dos usuários em experiências anteriores
• um vocabulário comum e uma visão compartilhada
• um framework para priorizar ações
• uma forma de definir as melhorias mais significativas para uma organização

Um modelo de maturidade pode ser usado como base para avaliar diferentes organizações e estabelecer comparações. O modelo descreve a maturidade da empresa baseado nos projetos que ela está desenvolvendo e nos clientes relacionados.

^[1] No nível 1 de maturidade os processos são geralmente ad hoc(expressão latina cuja tradução literal é "para isto") e caóticos. A organização geralmente não dispõe de um ambiente estável. O sucesso nessas organizações depende da competência e heroísmo dos seus funcionários e não no uso de processos estruturados. Devido ao imediatismo, o nível 1 de maturidade produz produtos e serviços que em geral funcionam, mas frequentemente excedem o orçamento e o prazo dos projetos. No caso de problemas que venham a ocorrer durante a realização de um projeto, a organização tem uma tendência a abandonar totalmente os procedimentos planejados e passa a um processo de codificação e testes, onde o produto obtido pode apresentar um nível de qualidade suspeito.

^[2] No nível 2 de maturidade, o desenvolvimento do software é repetido. O processo pode não se repetir para todos os projetos da organização. A organização pode usar ferramentas de Gerência de Projetos para mapear os custos e o prazo do projeto.

A adoção de um processo de desenvolvimento ajuda a garantir que práticas existentes sejam utilizadas em momentos de stress. Quando essas práticas são adotadas, os projetos decorrem (e são gerenciados) de acordo com o planejamento inicial.

O status do projeto e os serviços entregues são visíveis ao gerenciamento (por exemplo: é possível a visualização de marcos do projeto e o término da maioria das tarefas).

Técnicas de gerenciamento de projetos são estabelecidas para mapear custos, prazos, e funcionalidades. Um mínimo de disciplina nos processos é estabelecido para que se possa repetir sucessos anteriores em projetos com escopo e aplicação similares. Ainda há um risco significativo de exceder as estimativas de custos e o prazo de desenvolvimento.

Este nível apresenta as seguintes KPAs (Key Process Areas ou áreas chave de processo):

• Gerenciamento de Configuração (CM)
• Análise e Medição (MA)
• Acompanhamento e Supervisão de Projetos (PMC)
• Planejamento de Projetos (PP)
• Garantia de Qualidade de Software (PPQA)
• Gerenciamento de Requisitos (REQM)
• Gerenciamento de Subcontratação (SAM)

^[3] No nível 3 de maturidade, uma organização alcançou todas as metas genéricas e específicas das áreas de processo designadas como de níveis 1 e 2. No nível 3 de maturidade, processos são bem caracterizados e entendidos, e são descritos utilizando padrões, procedimentos, ferramentas e métodos.

A organização possui um conjunto de padrões de processos, os quais são a base do nível 3. Estes estão estabelecidos e são melhorados periodicamente. Estes padrões de processos são usados para estabelecer uma consistência dentro da organização. Projetos estabelecem seus processos segundo o conjunto de padrões processuais da organização, de acordo com guias.

O gerenciamento da organização estabelece os objetivos dos processos baseado no conjunto de padrões predefinidos e garante que estes objetivos sejam encaminhados de forma apropriada.

Uma crítica distinção entre os níveis 2 e 3 é o escopo dos padrões e a descrição dos processos e procedimentos. No nível 2, os padrões e a descrição de processos e procedimentos podem ser bem diferentes em cada instância específica do processo (por exemplo, em um projeto particular). No nível 3, os padrões e a descrição de processos e procedimentos para o projeto são guiados pelo conjunto de padrões de processos da organização. O conjunto de padrões de processo da organização inclui os processos do nível 2 e 3. Como resultado, os processos realizados através da organização são consistentes exceto pelas diferenças permitidas pelos guias.

Outra distinção crítica é que, no nível 3, processos são geralmente descritos com mais detalhes e com mais rigor do que no nível 2. No nível 3, processos são gerenciados mais proativamente. Há entendimento acerca das inter-relações entre as atividades dos processos. Há medidas detalhadas dos processos, produtos e serviços.

KPAs deste nível:

• Gerenciamento de Software Integrado (IPM)
• Definição do Processo da Organização (OPD)
• Foco no Processo da Organização (OPF)
• Programa de Treinamento (OT)
• Coordenação de Intergrupos totalmente originais (PI)
• Desenvolvimento de Requisitos (RD)
• Gerenciamento de Risco (RSKM)
• Solução Técnica dos Requisitos (TS)
• Validação (VAL)
• Verificação (VER)

^[4] Utilizando métricas precisas, o gerenciamento pode efetivamente controlar os esforços para desenvolvimento de software. Em particular, o gerenciamento pode identificar caminhos para ajustar e adaptar o processo a projetos particulares, sem perda de métricas de qualidade ou desvios das especificações.

Organizações neste nível conseguem metas quantitativas para o processo de desenvolvimento de software e de manutenção.

Subprocessos são selecionados conforme a importância na performance total do processo. Esses subprocessos selecionados são controlados usando técnicas estatísticas e quantitativas.

Uma distinção crítica entre o nível de maturidade 3 e 4 é a previsibilidade do desempenho do processo. No nível 4, o desempenho do processo é controlado usando técnicas estatísticas e quantitativas, e é previsível quantitativamente. No nível 3, os processos são somente previsíveis qualitativamente.

KPAs deste nível:

• Desempenho do Processo Organizacional (OPP)
• Gerenciamento Quantitativo do Processo (QPM)

^[5] No nível 5, uma organização adquiriu todas as metas específicas das áreas de processo dos níveis 2, 3, 4, e 5 e as metas genéricas dos níveis 2 e 3. Processos são continuamente melhorados com base no entendimento quantitativo das causas comuns de variação inerente aos processos.

No nível de maturidade 5, o foco é o contínuo progresso do desempenho dos processos, através da introdução de melhorias de inovação tecnológica e incremental. Objetivos de melhoria quantitativa dos processos para a organização são estabelecidos, continuamente revisados, refletindo as mudanças nos objetivos da organização, e usando critérios de melhoria na gerência de processos.

Os efeitos da melhoria da revisão dos processos são medidos e acompanhados, utilizando-se processos de melhoria de qualidade. Os processos definidos e o conjunto de processos padrões da organização são alvos de melhoria de métricas.

Uma distinção crítica entre os níveis 4 e 5 é o tipo de variação do processo. No nível 4, o interesse é verificar as causas especiais de variação de processo e fornecer resultados estatísticos. No nível 5, o foco são as causas comuns de variação de processo e a introdução de mudanças de modo a melhorar a performance do processo, atingindo objetivos quantitativos.

KPAs deste nível:

• Análise e Resolução de Causas (CAR)
• Gerenciamento de Desempenho (OPM)

• CMMI
• CIMM
• Zádor Dániel Kelemen (2007). «mini CMMI-survey» (em inglês). SQI Hungarian Software Quality Consulting Institute Ltd. Consultado em 7 de agosto de 2007 

Notas e referências

• Página inicial sobre o CMM para software (em inglês)
• Página inicial sobre Capability Maturity Model (em inglês)
• Visão geral sobre CMMI, em PDF
• Blog contendo diversas dicas sobre CMMI
• CMMI Para Desenvolvimento Versão 1.3(em inglês)

• Portal das tecnologias de informação