Segundo plano da CMMI (Integração do Modelo de Maturidade de Funcionalidade)
Azure DevOps Services | Azure DevOps Server 2022 - Azure DevOps Server 2019
O guia definitivo para a CMMI (Integração de Modelos de Maturidade de Capacidade) para Desenvolvimento é publicado pelo Instituto de Engenharia de Software como "CMMI: Diretrizes para Integração de Processos e Melhoria de Produtos". Este livro descreve especificamente a CMMI para Desenvolvimento (CMMI-DEV) versão 1.3, que é um dos modelos dentro do pacote de produtos de CMMI. Você também pode encontrar "CMMI Destilado: Uma Introdução Prática ao Aperfeiçoamento Integrado do Processo" como um livro útil e acessível sobre a CMMI.
Observação
As diretrizes fornecidas aqui se baseiam na versão 1.3 para CMMI e dão suporte ao processo CMMI disponível com o Azure DevOps. No momento, não existem planos para atualizar esse conteúdo para dar suporte a versões posteriores.
Notas históricas
A CMMI começou em 1987 como o CMM (Modelo de Maturidade de Capacidade), um projeto do SEI (Instituto de Engenharia de Software). O SEI é um centro de pesquisa da Universidade Carnegie-Mellon, que foi criado e financiado pelo Departamento de Defesa Estados Unidos. Publicado pela primeira vez em 1991, o CMM para Software começou como uma lista de verificação de fatores críticos de sucesso. O modelo também é criado nas pesquisas na IBM (International Business Machines) Corporation e pelos líderes em controle de qualidade do século XX, como Philip Crosby e W. Edwards Deming. Tanto o nome, Modelo de Maturidade de Capacidade e os cinco níveis da Representação em Estágios 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. Seu sucesso levou ao desenvolvimento de CMMs por uma variedade de motivos 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 integrava engenharia de sistemas, engenharia de software e desenvolvimento de produtos. Esse esforço envolveu mais de 200 especialistas da indústria e acadêmicos. O resultado foi o CMMI.
O CMMI-DEV é um modelo. Não é um processo ou uma receita a ser seguida. Em vez disso, o CMMI-DEV fornece 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 questões críticas talvez sejam as mais incompreendidas em relação ao CMMI.
Por que usar um modelo?
Os esforços de melhoria exigem um modelo de como sua organização funciona, quais funções elas precisam e como elas interagem. Um modelo fornece 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:
- Oferece uma estrutura e linguagem comuns para ajudar na comunicação
- Beneficia-se de anos de experiência
- Ajuda os usuários a considerar toda a imagem enquanto se concentram na melhoria
- Geralmente recebe suporte de treinadores e consultores
- Pode ajudar a resolver divergências, 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 oferecer orientações sobre como melhorar processos, com o objetivo de produtos aprimorados. Além disso, o CMMI é um modelo de gerenciamento de riscos e fornece uma maneira de medir a capacidade de gerenciar riscos da organização. A capacidade de gerenciar fatores de risco nas organizações proporciona a entrega de produtos de alta qualidade. Outra perspectiva sobre como gerenciar riscos é o desempenho de uma organização sob estresse. Uma organização de alta maturidade e capacidade pode responder com facilidade a eventos inesperados e estressantes. 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.
Entretanto, a CMMI não é um indicador comprovado do desempenho econômico de uma organização. Embora organizações com um nível mais alto de maturidade possam gerenciar melhor os riscos e serem mais previsíveis, existem evidências de que as empresas de maior maturidade tendem a ser avessas ao risco. A aversão ao risco pode levar a uma falta de inovação ou evidenciar um alto nível de burocracia que resulta em longos prazos de entrega 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 demonstram 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 apresentam 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 com alta maturidade 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 demonstrar 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.
A Representação Contínua modela a capacidade de processo dentro de cada uma das 22 áreas de processo individualmente, que permite 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. 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 etapas como base para um programa de melhoria de processo pode ser perigoso quando os implementadores esquecem que a CMMI não é um processo nem um modelo de fluxo de trabalho. Em vez disso, a CMMI foi projetada para fornecer metas para que o processo e o fluxo de trabalho sejam alcançados. Atender a essas metas aprimora 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 teve êxito como um guia para aprimoramento do processo. Algumas empresas de consultoria optam apenas por oferecer diretrizes sobre o 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 a 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
A tabela a seguir lista as 22 áreas de processo que compõem o modelo CMMI (versão 1.3):
Acrônimo | Área de Processo |
---|---|
CAR | Análise de Causa e Resolução |
CM | Gerenciamento de configuração |
DAR | Análise de Decisão e Resoluçã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.
São necessárias somente metas genéricas e específicas. Tudo o mais é fornecido como orientação. Para obter exemplos de componentes esperados e informativos, a literatura de CMMI retirou dados de grandes projetos de sistemas de defesa e espacial. 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.
Artigos relacionados
- Processo CMMI
- O Instituto de Engenharia de Software lança a versão 1.3 do Pacote de Produtos CMMI
- 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 produtos (série SEI na Engenharia de Software)
- O que é o Desenvolvimento Agile?