Embed Size (px)
Citation preview
CMM – Capability Maturity Model
Carlos Augusto Mar
Ago/2014
HISTÓRICO
• O DoD patrocinou a fundação do SEI (Software Engineering Institute) na Universidade de Carnegie Mellon (Pittsburg) com o objetivo de propor um modelo para avaliar seus fornecedores.
• O intuito era que esses desenvolvessem sw com o mesmo nível de repetibilidade e controle encontrado em outros setores
HISTÓRICO
• Início dos trabalhos em 1986;
• Publicação da Versão 1.0 do SW-CMM em agosto
de 1991.
• Em fevereiro de 1993, publicação da versão 1.1.
• Uso específico para a área de software;
– Não contemplava outras áreas como Recursos Humanos
e Engenharia de Sistemas.
HISTÓRICO
SoftwareCMM
SystemsSecurity
Engineering CMM
SystemsEngineering
CMM
PeopleCMM
SECM (EIA 731)
Integrated Product
DevelopmentCMM
SoftwareAcquisition
CMM
• Diferentes estruturas, formatos, termos, maneiras de medir maturidade
• Causa confusão, especialmente quando mais de um modelo é utilizado
• Difícil de integrar em um único programa de melhoria
HISTÓRICO
• O CMMI (Capability Maturity Model Integration) foi criado, então, com a finalidade de integrar os diversos modelos CMM.
• Em 1999, foi publicado o esboço (draft), versão 0.2: CMMI-SE/SW (Capability Maturity Model -Integrated – System / Software Engineering).
• Versões do CMMI:– Versão 1.0: Agosto de 2000– Versão 1.1: Março de 2002– Versão 1.2: Agosto de 2006 (CMMI for Development)
CMM - NÍVEIS DE MATURIDADE• Processo continuamente • melhorado
• Processo previsível e controlado
• Processo consistente e padronizado
• Processo disciplinado
• 1- Inicial
• 2- Repetíve
l
• 3- Definido
• 4- Gerenciad
o
• 5- Otimizad
o
• Processo imprevisível e sem controle
CMM – NÍVEIS DE MATURIDADE
Focoem melhoria do processo
Processo Medido econtrolado
Processo caracterizadopela organização e porser proativo
Processo caracterizado porprojetos e é frequentementereativo
Processo imprevisivelpobremente controladoé reativo
4
5
3
2
1Executado
Gerenciado
GerenciadoQuantitativamente
Definido
Otimizado
CMM – ESTRUTURA GERAL
VISIBILIDADE DO PROCESSONÍVEL 1
• entrada • saída
• Deficiências de planejamento e enfrentam dificuldades ao realizarem previsões.• Cronogramas e planos são irreais.• Como não há credibilidade no planejamento, mesmo aquilo que foi planejado não é seguido.• Não há controle de requisitos e o cliente só os avalia na entrega do produto.• É comum passar diretamente dos requisitos à codificação.• A documentação é encarada como algo inútil.• São comuns reações intransigentes à coleta de dados e ao uso de padrões, documentação e
ferramentas.
VISIBILIDADE DO PROCESSONÍVEL 2
entrada saída
1. Gerência de Requisitos2. Planejamento de Projetos3. Supervisão e Acompanhamento de Projetos4. Gerência da Subcontratação de Software5. Garantia da Qualidade de Software6. Gerência de Configuração de Software
VISIBILIDADE DO PROCESSONÍVEL 3
entrada saída
1. Foco no Processo da Organização 2. Definição do Processo da Organização 3. Programa de Treinamento 4. Gerência de Software Integrada 5. Coordenação entre grupos 6. Engenharia de Produtos de Software 7. Revisão por Pares
VISIBILIDADE DO PROCESSONÍVEL 4
entrada saída
• Gerência Quantitativa dos Processos• Gerência da Qualidade de Software
VISIBILIDADE DO PROCESSONÍVEL 5
entrada saída
• Prevenção de Defeitos • Gerência da Evolução dos Processos • Gerência da Evolução das Tecnologias
KPA´s e os NÍVEIS
