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 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 Software CMM Software CMM Systems Security Engineering CMM Systems Security Engineering CMM Systems Engineering CMM Systems Engineering CMM People CMM People CMM SECM (EIA 731) SECM (EIA 731) Integrated Product Development CMM Integrated Product Development CMM Software Acquisition CMM Software Acquisition 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ível 3- Definido 4- Gerenciado 5- Otimizado Processo imprevisível e sem controle

CMM – NÍVEIS DE MATURIDADE

CMM – ESTRUTURA GERAL

VISIBILIDADE DO PROCESSO NÍVEL 1 entradasaí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 PROCESSO NÍVEL 2 entradasaída 1.Gerência de Requisitos 2.Planejamento de Projetos 3.Supervisão e Acompanhamento de Projetos 4.Gerência da Subcontratação de Software 5.Garantia da Qualidade de Software 6.Gerência de Configuração de Software

VISIBILIDADE DO PROCESSO NÍVEL 3 entradasaí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 PROCESSO NÍVEL 4 entradasaída Gerência Quantitativa dos Processos Gerência da Qualidade de Software

VISIBILIDADE DO PROCESSO NÍ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