Plano de fundo para CMMI

O guia definitivo do CMMI (Capability Maturity Model Integration) for Development é publicado pelo Software Engineering Institute sob o título "CMMI: Guidelines for Process Integration and Product Improvement". Esse livro descreve especificamente o CMMI for Development (CMMI-DEV) versão 1.3, que é um dos modelos dentro do pacote de produtos do CMMI atual no momento desta publicação. Esse modelo é extremamente estável e deve continuar atual por um bom tempo após 2010. Você também pode achar o volume "CMMI Distilled: A Practical Introduction to Integrated Process Improvement" útil e acessível sobre esse tópico. Para obter mais informações sobre esses dois livros, consulte Recursos Adicionais posteriormente neste tópico.

O CMMI foi introduzido em 1987 como o CMM (Capability Maturity Model), um projeto no Software Engineering Institute, que é um centro de pesquisa na Universidade de Carnegie-Mellon. Esse centro foi estabelecido e fundado pelo Departamento de Defesa dos Estados Unidos. O CMM for Software foi publicado pela primeira vez em 1991 e baseia-se em uma lista de verificação de fatores críticos para o sucesso em projetos de desenvolvimento de software durante o final dos anos 1970 e início da década de 1980. O modelo também é informado por pesquisas na IBM (International Business Machines) Corporation e pelos líderes em controle de qualidade do século XX, Philip Crosby e W. Edwards Deming. Tanto o nome, Capability Maturity Model, quanto os cinco níveis da Representação em Estágios (como discutido posteriormente neste tópico) foram inspirados pelo Modelo de Maturidade de Fabricação de Crosby. Aplicado principalmente a programas de defesa, o CMM alcançou um nível de adoção considerável e passou por diversas revisões e iterações. Seu sucesso levou ao desenvolvimento de CMMs por uma variedade de motivos além do software. A proliferação de novos modelos se tornou confusa, por isso, o governo fundou um projeto de dois anos que envolveu mais de 200 especialistas no setor e acadêmicos para criar uma única estrutura extensível que integrasse a engenharia de sistemas, a engenharia de software e o desenvolvimento de produtos. O resultado foi o CMMI.

A coisa mais importante para entender sobre o CMMI-DEV é que ele é um modelo. Não é um processo ou uma prescrição a ser seguida. É um conjunto de comportamentos organizacionais comprovados como sendo úteis no desenvolvimento de software e engenharia de sistemas. Por que usar esse modelo? Qual é sua finalidade? Qual a melhor maneira de usá-lo? Essas são questões críticas e talvez sejam as mais incompreendidas em relação ao CMMI.

Por que usar um modelo?

Sem um modelo de como nossas organizações funcionam, quais funções elas precisam e como essas funções interagem, é difícil liderar esforços que levem a melhorias. Um modelo oferece um entendimento dos elementos discretos em nossas organizações e nos ajudam a formular linguagens e discussões do que precisa ser melhorado e como essas melhorias podem ser alcançadas. Um modelo oferece os seguintes benefícios:

• oferece uma estrutura e linguagem comuns para ajudar na comunicação

• beneficia-se de anos de experiência

• ajuda os usuários a manter o objetivo principal em mente ao mesmo tempo em que se concentram no aprimoramento

• geralmente recebe suporte de treinadores e consultores

• poder oferecer um padrão para ajudar a resolver desentendimentos

Qual é o objetivo do modelo CMMI?

O livro dirá que o objetivo do modelo é avaliar a maturidade dos processos de uma organização e oferecer orientações sobre como melhorar processos que levarão a produtos aprimorados. Ao falar diretamente com as pessoas no Software Engineering Institute, você pode ouvi-las dizer que o CMMI é um modelo de gerenciamento de riscos e indica a capacidade que uma organização tem para gerenciar riscos. Essa indicação é uma evidência da probabilidade de uma organização cumprir suas promessas ou oferecer produtos de alta qualidade que sejam atraentes ao mercado. Outro modo de pensar sobre isso é que o modelo oferece um bom indicador de como uma organização se comportará sob estresse. Uma organização de alta maturidade e alta capacidade enfrentará eventos inesperados e estressantes com firmeza, reagirá, mudará e seguirá em frente. Uma organização com baixo nível de maturidade e capacidade tenderá a entrar em pânico sob estresse, a seguir cegamente procedimentos de prevenção ou ignorar todos os processos e voltar ao caos.

O CMMI não provou ser um bom indicador do desempenho econômico de uma organização. Embora organizações com um nível mais alto de maturidade possa gerenciar o risco melhor e ser mais previsíveis, há evidências de aversão ao risco entre elas. Essa aversão pode levar a uma falta de inovação ou evidenciar um alto nível de burocracia que resulta em longos tempos de aprovisionamento e falta de competitividade. Empresas com menos maturidade tendem a ser mais inovadoras e criativas, porém são também caóticas e imprevisíveis. Quando os resultados são conquistados, eles geralmente são provenientes do esforço heroico de indivíduos ou gerentes.

Qual é a melhor maneira de usar o modelo CMMI?

O modelo foi projetado para ser usado como base para uma iniciativa de aprimoramento de processo, com seu uso na avaliação somente para um sistema de suporte e aprimoramento de medidas. Tem havido um certo êxito com seu uso. Também é muito fácil confundir o modelo com uma definição de processo e tentar segui-lo, ao invés de seguir um mapa que identifica lacunas nos processos existentes que precisam ser preenchidas. A base fundamental do CMMI é uma área de processo que define os objetivos e diversas atividades que são geralmente usadas para atendê-los. Um exemplo de uma área de processo é o Controle de Qualidade de Processo e Produto. Outra é o Gerenciamento de Configuração. É importante entender que uma área de processo não é um processo. Um único processo pode cruzar diversas áreas de processo, e uma área de processo individual pode envolver vários processos.

O CMMI-DEV são na verdade dois modelos que compartilham os mesmos elementos subjacentes. O primeiro e mais familiar deles é a Representação em Estágios, que apresenta as 22 áreas de processo mapeadas em um de cinco níveis de maturidade organizacional. Na avaliação de uma organização analisaria o nível na qual ela opera, e esse nível seria um indicador de sua capacidade de gerenciar riscos e, portanto, de cumprir suas promessas.

Os níveis 4 e 5 geralmente são considerados níveis de maturidade mais altos. Geralmente, há uma diferença clara entre organizações com um nível de maturidade mais alto, que exibem o gerenciamento quantitativo e comportamentos de otimização, e organizações de maturidade mais baixa, que são meramente gerenciadas ou que seguem processos definidos. Organizações com mais alto nível de maturidade exibem menos variabilidade nos processos e geralmente usam indicadores de liderança como parte de um método de gerenciamento estatisticamente defensível. Como resultado, organizações mais maduras tendem a ser mais previsíveis e mais rápidas para responder a novas informações, presumindo que outras burocracias não sejam um obstáculo. Enquanto organizações com baixo nível de maturidade tendem a exibir um esforço heroico, organizações mais maduras podem seguir cegamente processos quando estiverem sob estresse e deixar de reconhecer que uma alteração em um processo pode ser uma resposta mais adequada.

O segundo, a Representação Contínua, modela a capacidade de processo dentro de cada uma das 22 áreas de processo individualmente, permitindo que a organização ajuste seus esforços de aprimoramento aos processos que oferecem o maior valor de negócios. Essa representação está mais alinhada com o modelo original de Crosby. Avaliações em relação a esse modelo resultam em perfis de capacidade ao invés de um único número. É claro que, como o nível de maturidade organizacional é o nível que a maioria dos gerentes e executivos entende, há maneira de mapear os resultados de uma avaliação de modelo contínuo dentro dos cinco estágios.

Usar o modelo em estágios como base para um programa de aprimoramento de processo pode ser perigoso, pois os implementadores podem se esquecer de que o CMMI não é um processo ou modelo de fluxo de trabalho, mas oferece metas que devem ser alcançadas pelo processo e o fluxo de trabalho. Atender essas metas aprimorará a maturidade da organização e a probabilidade de que os eventos ocorram como planejado. Talvez a maior falha seja atingir um determinado nível da meta e depois criar processos e infraestruturas simplesmente para passar na avaliação. O objetivo de qualquer atividade de aprimoramento deve ser o aprimoramento mensurável, e não um número.

O modelo Contínuo parece ter maior sucesso como um guia para o aprimoramento de processo, e algumas empresas de consultoria escolhem somente oferecer orientação baseada no modelo Contínuo. A diferença mais óbvia é que um programa de aprimoramento de processo que é elaborado em torno do modelo Contínuo não possui metas artificiais que são determinadas por níveis de maturidade. O modelo Contínuo também funciona de maneira mais natural para aplicar o aprimoramento de processos nas áreas em que ele mais provavelmente levaria a um benefício econômico para a organização. Portanto, aqueles que seguem o modelo Contínuo, provavelmente, receberão mais comentários positivos de uma iniciativa baseada no modelo CMMI. Além disso, comentários positivos provavelmente levarão mais ao desenvolvimento de um ciclo virtuoso de melhorias.

Elementos do modelo CMMI

O modelo CMMI é dividido em 22 áreas de processo, que são listadas na tabela a seguir:

Acrônimo	Área de Processo
CAR	Análise e Resolução Casuais
CM	Gerenciamento de Configuração
DAR	Análise e Resolução de Decisão
IPM	Gerenciamento de Projeto Integrado
MA	Medida e Análise
OID	Inovação e Implantação Organizacionais
OPD	Definição do Processo Organizacional
OPF	Foco do Processo Organizacional
OPP	Desempenho do Processo Organizacional
OT	Treinamento Organizacional
PI	Integração do Produto
PMC	Monitoramento e Controle do Projeto
PP	Planejamento do Projeto
PPQA	Controle de Qualidade do Processo e do Produto
QPM	Gerenciamento Quantitativo do Projeto
RD	Definição de Requisitos
REQM	Gerenciamento de Requisitos
RSKM	Gerenciamento de Riscos
SAM	Gerenciamento do Contrato de Fornecimento
TS	Solução Técnica
VER	Verificação
VAL	Validação

Na Representação em Estágios, as áreas de processo são mapeadas em relação a cada estágio, como mostrado na ilustração a seguir.

Na Representação Contínua, as áreas de processo são mapeadas em agrupamentos funcionais, como mostrado na ilustração a seguir.

Cada área de processo é composta de componentes necessários, esperados e informativos. Somente os componentes necessários são de fato exigidos para satisfazer uma avaliação relativa ao modelo. Os componentes necessários são os objetivos específicos e genéricos para cada área de processo. Os componentes esperados são as práticas específicas e genéricas para cada objetivo específico ou genérico. Observe que, como um componente esperado é meramente esperado e não necessário, isso indica que uma prática específica ou genérica possa ser substituída por uma prática equivalente. As práticas esperadas existem para orientar os implementadores e avaliadores. Se uma prática alternativa for escolinha, dependerá do implementador aconselhar um avaliador e justificar por que uma prática alternativa é adequada. Componentes informativos oferecem detalhes que ajudam os implementadores a iniciar uma iniciativa de aprimoramento de processo orientada pelo modelo CMMI. Componentes informativos incluem subpráticas de práticas genéricas e específicas e produtos de trabalho típicos.

É muito importante entender que somente metas genéricas e específicas são necessárias. Tudo o mais é fornecido como orientação. Os exemplos dos componentes esperados e informativos que são fornecidos na literatura do CMMI são muito frequentemente extraídos de projetos em um espaço maior e de integração de sistemas de defesa. Esses projetos são executados por empresas que patrocinam e dão suporte ao Software Engineering Institute na Universidade de Carnegie-Mellon. Esses projetos podem não refletir o tipo de projetos realizado em sua organização, assim como podem não refletir as tendências mais recentes no setor, como a emergência de métodos de desenvolvimento do software Agile.

Recursos adicionais

Para obter mais informações, consulte os seguintes recursos da Web:

• CMMI for Development, Version 1.3, Improving processes for developing better products and services Programa de Gerenciamento de Processo de Engenharia de Software

• CMMI Institute

• CMMI: Guidelines for Process Integration and Product Improvement (em inglês) (2ª Edição), Mary Beth Chrissis, Mike Konrad e Sandy Shrum; Addison-Wesley Professional, 2006.

• CMMI Distilled: A Practical Introduction to Integrated Process Improvement (em inglês) (3ª Edição), Dennis M. Ahren, Aaron Clause e Richard Turner; Addison-Wesley Professional, 2008.

Consulte também

Conceitos

Melhoria no processo MSF para CMMI para Visual Studio ALM