Antecedentes da Integração do Modelo de Maturidade de Capacidade (CMMI)
Serviços de DevOps do Azure | Azure DevOps Server 2022 - Azure DevOps Server 2019
O guia definitivo para o Capability Maturity Model Integration (CMMI) para Desenvolvimento é publicado pelo Software Engineering Institute como "CMMI: Guidelines for Process Integration and Product Improvement". Este livro descreve especificamente o CMMI for Development (CMMI-DEV) versão 1.3, que é um dos modelos dentro do pacote de produtos CMMI. Você também pode encontrar "CMMI Distilled: A Practical Introduction to Integrated Process Improvement" para ser um livro útil e acessível sobre CMMI.
Nota
A orientação fornecida aqui é baseada na versão 1.3 para CMMI e dá suporte ao processo CMMI disponível com o Azure DevOps. Não existem planos neste momento para atualizar este conteúdo para suportar versões posteriores.
Notas históricas
O CMMI começou em 1987 como o Capability Maturity Model (CMM), um projeto do Software Engineering Institute (SEI). O SEI é um centro de pesquisa da Universidade Carnegie-Mellon, que foi estabelecido e financiado pelo Departamento de Defesa dos Estados Unidos. Publicado pela primeira vez em 1991, o CMM for Software começou como uma lista de verificação de fatores críticos de sucesso. O modelo também se baseou em pesquisas da International Business Machines (IBM) Corporation e líderes de garantia de qualidade do século 20, como Philip Crosby e W. Edwards Deming. Tanto o nome, Modelo de Maturidade de Capacidade, quanto os cinco níveis de Representação Encenada foram inspirados no Modelo de Maturidade de Fabricação de Crosby. Aplicado principalmente a programas de defesa, o CMM alcançou considerável adoção e passou por várias revisões. Seu sucesso levou ao desenvolvimento de CMMs para uma variedade de assuntos além do software. A proliferação de novos modelos foi confusa. Em resposta, o governo financiou um projeto de dois anos para criar uma estrutura única e extensível que integrasse engenharia de sistemas, engenharia de software e desenvolvimento de produtos. Este esforço envolveu mais de 200 especialistas da indústria e académicos. O resultado foi o CMMI.
CMMI-DEV é um modelo. Não é um processo, nem uma prescrição a ser seguida. Em vez disso, o CMMI-DEV fornece um conjunto de comportamentos organizacionais que provaram ser úteis no desenvolvimento de software e engenharia de sistemas. Porquê utilizar um modelo destes? Qual é a sua finalidade? E qual a melhor forma de o utilizar? Estas questões críticas são talvez as questões mais incompreendidas com o CMMI.
Porquê usar um modelo?
Os esforços de melhoria exigem um modelo de como sua organização funciona, quais funções precisam e como essas funções interagem. Um modelo dá-lhe uma compreensão dos elementos organizacionais e auxilia nas discussões sobre como e o que pode e deve ser melhorado.
Um modelo oferece os seguintes benefícios:
- Fornece uma estrutura e uma linguagem comuns para ajudar a comunicar
- Aproveita anos de experiência
- Ajuda os usuários a considerar a imagem geral enquanto se concentram na melhoria
- É frequentemente apoiado por formadores e consultores
- Pode ajudar a resolver diferendos fornecendo padrões acordados
Qual é o objetivo do modelo CMMI?
O objetivo do modelo CMMI é avaliar a maturidade dos processos de uma organização e fornecer orientação sobre a melhoria dos processos, com o objetivo de melhorar os produtos. Além disso, o CMMI é um modelo de gestão de riscos e fornece uma maneira de medir a capacidade de uma organização de gerenciar riscos. A capacidade de gerenciar fatores de risco em uma capacidade da organização de entregar produtos de alta qualidade. Outra perspetiva sobre o gerenciamento de riscos é o desempenho de uma organização sob estresse. Uma organização de alta maturidade e alta capacidade pode responder facilmente a eventos inesperados e estressantes. Uma organização de baixa maturidade e baixa capacidade tende a entrar em pânico sob estresse, seguir cegamente procedimentos obviados ou jogar fora todo o processo completamente e recuar para o caos.
O CMMI, no entanto, não é um indicador comprovado do desempenho econômico de uma organização. Embora as organizações de maior maturidade possam gerir melhor o risco e ser mais previsíveis, existem evidências de que as empresas de maturidade mais elevada tendem a ser avessas ao risco. A aversão ao risco pode conduzir a uma falta de inovação ou a provas de uma maior burocracia que resulta em prazos de entrega longos e numa falta de competitividade. As empresas de menor maturidade tendem a ser mais inovadoras e criativas, mas caóticas e imprevisíveis. Quando os resultados são alcançados, são muitas vezes o resultado de um esforço heroico por parte de indivíduos ou gestores.
Qual é a melhor maneira de usar o modelo CMMI?
O modelo foi concebido para ser usado como base para uma iniciativa de melhoria de processos, sendo a sua utilização na avaliação apenas um sistema de apoio para medir a melhoria. Tem havido um sucesso misto com este uso. É muito fácil confundir o modelo com uma definição de processo e tentar segui-lo, em vez de um mapa que identifica lacunas nos processos existentes que podem precisar ser preenchidas. O bloco de construção fundamental do CMMI é uma área de processo que define metas e várias atividades que são frequentemente usadas para cumpri-las. Um exemplo de área de processo é a Garantia da Qualidade de Processos e Produtos. Outro é o Gerenciamento de Configuração. É importante entender que uma área de processo não é um processo. Um único processo pode atravessar várias áreas de processo, e uma área de processo individual pode envolver vários processos.
O CMMI-DEV é realmente dois modelos que compartilham os mesmos elementos subjacentes. A primeira e mais conhecida é a Representação Encenada, que apresenta as 22 áreas de processo mapeadas em um dos cinco níveis de maturidade organizacional. Uma avaliação de uma organização avaliaria o nível em que ela estava operando, e esse nível seria um indicador de sua capacidade de gerenciar riscos e, como, cumprir suas promessas.
Os níveis 4 e 5 são frequentemente referidos como níveis de maturidade mais elevados. Muitas vezes há uma clara diferença entre organizações de maior maturidade, que demonstram a gestão quantitativa e otimizando comportamentos, e organizações de menor maturidade, que são meramente gerenciadas ou seguindo processos definidos. Organizações de maior maturidade mostram menor variabilidade nos processos e muitas vezes usam indicadores líderes como parte de um método de gestão estatisticamente defensável. Como resultado, as organizações de maior maturidade tendem a ser mais previsíveis e rápidas na resposta a novas informações, assumindo que outras burocracias não atrapalham. Onde organizações de baixa maturidade tendem a demonstrar esforço heroico, organizações de alta maturidade podem seguir cegamente os processos quando estão sob estresse e não reconhecer que uma mudança de processo pode ser uma resposta mais apropriada.
A Representação Contínua modela a capacidade de processo dentro de cada uma das 22 áreas de processo individualmente, o que permite à organização adaptar os seus esforços de melhoria aos processos que oferecem o maior valor de negócio. Esta representação está mais de acordo com o modelo original de Crosby. As avaliações em relação a este modelo resultam em perfis de capacidade em vez de um único número. Como o nível de maturidade organizacional é o nível que a maioria dos gerentes e executivos entende, existem maneiras de mapear os resultados de uma avaliação contínua do modelo nas cinco etapas.
Usar o modelo em estágios como base para um programa de melhoria de processos pode ser perigoso quando os implementadores esquecem que o CMMI não é um processo nem um modelo de fluxo de trabalho. Em vez disso, o CMMI foi projetado para fornecer metas para o processo e o fluxo de trabalho alcançarem. Atingir tais objetivos melhora a maturidade da organização e a probabilidade de que os eventos se desenrolem conforme planejado. Talvez o maior modo de falha seja fazer com que atingir um nível seja o objetivo e, em seguida, criar processos e infraestrutura simplesmente para passar na avaliação. O objetivo de qualquer atividade de melhoria de processos deve ser uma melhoria mensurável, não um número.
O modelo Continuous tem tido sucesso como guia para a melhoria de processos. Algumas empresas de consultoria optam apenas por oferecer orientação em torno do modelo Contínuo. A diferença mais óbvia é que um programa de melhoria de processos que é projetado em torno do modelo Contínuo não tem metas artificiais que são determinadas por níveis de maturidade. O modelo Continuous também se presta a aplicar a melhoria de processos em áreas onde é mais provável alavancar um benefício econômico para a organização. Portanto, aqueles que seguem o modelo Contínuo são mais propensos a receber feedback positivo de uma iniciativa baseada no modelo CMMI. Além disso, é mais provável que um feedback positivo conduza ao desenvolvimento de um ciclo virtuoso de melhorias.
Elementos do modelo CMMI
A tabela a seguir lista as 22 áreas de processo que compõem o modelo CMMI (versão 1.3):
Acrónimos | Área de Processo |
---|---|
CARRO | Análise Causal & Resolução |
CM | Gestão da Configuração |
DAR | Análise de Decisão e Resolução |
MIP | Gestão Integrada de Projetos |
MA | Medição e Análise |
OIDE | Inovação Organizacional e Implantação |
OPD | Definição de Processos Organizacionais |
OPF | Foco no Processo Organizacional |
OPP | Desempenho do Processo Organizacional |
OT | Formação Organizacional |
PI | Integração de produtos |
PMC | Monitorização de Projetos e Controlo |
PP | Planeamento de Projeto |
PPQA | Processo & Garantia de Qualidade do Produto |
QPM | Gestão Quantitativa de Projetos |
RD | Definição de Requisitos |
REQM | Gestão de Requisitos |
RSKM | Gestão de Riscos |
SAM | Gestão de Contratos de Fornecedores |
TS | Solução Técnica |
VER | Verificação |
VAL | Validação |
Na Representação Encenada, as áreas do processo são mapeadas em relação a cada estágio, conforme mostrado na ilustração a seguir.
Na Representação Contínua, as áreas do processo são mapeadas em agrupamentos funcionais, como mostra a ilustração a seguir.
Cada área de processo é composta por componentes necessários, esperados e informativos. Apenas os componentes necessários são realmente necessários para satisfazer uma avaliação em relação 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. Note-se que, uma vez que uma componente esperada é meramente esperada e não necessária, tal indica que uma prática específica ou genérica pode ser substituída por uma prática equivalente. As práticas esperadas existem para orientar implementadores e avaliadores. Se for escolhida uma prática alternativa, cabe ao responsável pela implementação aconselhar um avaliador e justificar por que razão uma prática alternativa é adequada. Os componentes informativos fornecem detalhes que ajudam os implementadores a começar com uma iniciativa de melhoria de processo guiada pelo modelo CMMI. Os componentes informativos incluem subpráticas de práticas genéricas e específicas e produtos típicos de trabalho.
Apenas objetivos genéricos e específicos são necessários. Todo o resto é fornecido como um guia. Para exemplos de componentes esperados e informativos, a literatura do CMMI extraiu dados de grandes projetos espaciais e de sistemas de defesa. Esses projetos podem não refletir o tipo de projetos que são realizados em sua organização, nem podem refletir tendências mais recentes no setor, como o surgimento de métodos ágeis de desenvolvimento de software.
Artigos relacionados
- Processo CMMI
- Software Engineering Institute lança a versão 1.3 do CMMI Product Suite
- CMMI para Desenvolvimento: Diretrizes para Integração de Processos e Melhoria de Produtos, Terceira Edição
- CMMI para Desenvolvimento: Diretrizes para Integração de Processos e Melhoria de Produto (Série SEI em Engenharia de Software)
- O que é Desenvolvimento Ágil?