Capability Maturity Model for Software – CMM Fundamentos da Engenharia de Software Janeiro/2003 Daniel Leitão Corrêa e Silva Eduardo Lima Fernandes Rafael Studart Monclar

Apresentação Visão Geral do Modelo de Maturidade de Capacitação para o Desenvolvimento de Software

O que é o CMM Modelo de qualidade para o desenvolvimento e manutenção de sistemas de software Criado no Instituto de Engenharia de Software (SEI) da Universidade Carnegie Mellon (Pensilvânia).

Introdução do CMM Descreve os elementos chaves de um processo de desenvolvimento de software O melhoramento de maneira evolucionária do caminho de um processo imaturo de ad hoc, para um processo maduro disciplinado Cobre as práticas de planejamento, engenharia e gerência de desenvolvimento e manutenção de software Estabelece um parâmetro que possibilita avaliar o estágio de maturidade dos processos de software da organização comparando-o as práticas da indústria

Composição do CMM Cinco níveis de maturidade Com exceção do Nível 1, cada nível de maturidade tem várias áreas-chave de processos Cada área-chave de processo é organizada dentro de cinco seções chamadas características comuns A característica comum especifica as práticas-chave que, quando direcionadas em grupo, executam os objetivos da área-chave de processo

Componentes do CMM Níveis de Maturidade Áreas-chave de processo Capacitação do Processo Características comuns Metas Práticas-chave

Esquema da Estrutura Níveis de Maturidade Áreas-chave de Processo Capacitação do Processo Níveis de Maturidade Indicam Contêm Metas Áreas-chave de Processo Alcançam Organizadas pelas Compromisso Habilitação Atividade Medição e Análise Verificação Implementação ou Institucionalização Características Comuns Abordam São Contêm Atividades ou Infra-estrutura Práticas- Chave Descrevem (Paulk 93a)

Estrutura do CMM ... ... ... ... (Dymond 95) Níveis de Maturidade (N5) Nível de Maturidade (N2) Área-chave (Gerência de Requisitos) Área-chave (Planejamento do Proje.. ... Meta 1 Os requisitos... Meta 2 Os planos... ... ... Características Comuns Compromisso em executar (C) Habilitação para executar (H) Atividades a executar (A) Medição e Análise (M) Verificação implantação (V) ... Prática-Chave C1 Prática-Chave H3 Prática-Chave H4 (Dymond 95)

Níveis de Maturidade Nível de maturidade é um patamar evolucionário bem definido para alcançar a maturidade do processo de desenvolvimento de software. Cada nível de maturidade fornece uma camada no fundamento para o melhoramento contínuo do processo. Cada área-chave engloba um grupo de objetivos.

Níveis de Maturidade Em Otimização (5) Gerenciado (4) Definido (3) Processo de Melhoria Contínua Melhoria Contínua Em Otimização (5) 0,4% Controle Quantitativo de Processo Gerenciado (4) Processo Previsível 1,7% Processo Integrado de Engenharia Definido (3) Processo Padronizado e Consistente 13,1% Gerência de Projeto Repetitivo (2) Processo Disciplinado 23,3% Inicial (1) Processo Caótico Ad Hoc (61,5% (Paulk 93a) SEI – ABR/97

Nível 1 – Inicial Processo ad hoc, às vezes caótico. Poucos processos definidos Sucesso depende de esforços individuais. Ambiente instável para o desenvolvimento e manutenção. As boas práticas de engenharia de software são minadas pelo planejamento ineficaz. Na crise, abandonam processos planejados e revertem para codificação e teste. Imprevisível, o processo é constantemente modificado ou trocado conforme o ambiente

Nível 2 – Repetitivo Gerência Básica Estabelecida. Novos projetos são baseados na experiência de projetos similares. Permite a organização de planos realistas repetindo o sucesso de práticas em projetos anteriores. Cada projeto tem processos definidos, documentados, praticados, obedecidos, treinados, medidos e capazes de melhorias. Verifica se está sendo executado conforme o plano. Controle das configurações. Gerentes acompanham custos, cronograma e funcionalidades e os problemas para atingir os compromissos são identificados quando eles surgem.

Nível 2 – Repetitivo Registro e controle da integridade do baseline dos requerimentos e das entregas. Padrões são definidos e seguidos fielmente. Relacionamento forte com sub-contratados. O processo é disciplinado, porque o planejamento e o acompanhamento são estáveis.

Nível 3 – Definido Processo de Engenharia de Software Estabelecido. O processo padrão para desenvolvimento e manutenção de software na organização é documentado e estão integrados coerentemente. Processos estabelecidos aqui são usados (e modificados, quando apropriado) para ajudar os gerentes e técnicos no desempenho mais efetivo. Práticas de engenharia de software são efetivas quando os processos estão padronizados. Um grupo é responsável pelas atividades do processo, ex:. um grupo de processo de engenharia de software ou SEPG [Fowler90].

Nível 3 – Definido Implementação de um programa de treinamento para assegurar que a equipe técnica e os gerentes tenham conhecimentos e habilidades requeridas para desempenharem plenamente seus papéis. O Processo Padrão da Organização é adequado às características individuais de cada projeto. Um processo bem definido pode ser caracterizado por seus critérios de disponibilidade, entradas, padrões e procedimentos para realizar o trabalho, mecanismo de verificação, saídas e critérios de aceitação. Pode ser resumido como consistente e padronizado porque as atividades de engenharia e gerência são estáveis e repetitivas.

Nível 4 – Gerenciado Gerência Quantitativa. Estabelecimento de metas quantitativa de qualidade. Os processos são medidos quantitativamente. Uma base para tomadas de decisões. A variabilidade nos processos são menores. Entendimento da capacitação e do risco. Minimização de impacto na ocorrência do inesperado. Produtos são previsivelmente de alta qualidade.

Nível 5 – Em Otimização Evolução Sistemática do Processo. Melhoria contínua do processo como um todo Projetos pilotos para a absorção e internalização de novas tecnologias Alto nível de qualidade Alto nível de satisfação dos clientes

Pesquisa de Evolução Pesquisas de evolução nas empresas apontaram as seguintes durações médias: De 1987 a 1996 Após 1996 N1 N2 31 meses N1 N2 26 meses N2 N3 18 meses N2 N3 17 meses

Capacitação do Processo Níveis de Maturidade Indicam De desenvolvimento de software descreve a abrangência dos resultados esperados que podem ser alcançados e fornece os meios para isso.

Áreas-chave de processo Metas Áreas-chave de Processo Alcançam Cada área-chave de processo identifica um grupo de atividades relacionadas que, quando executadas coletivamente, alcança um grupo de objetivos considerados importantes para o estabelecimento da capacidade de processo do nível de maturidade. As áreas-chave de processo tem sido definidas para residir em um único nível de maturidade. Ex: uma das áreas-chave para o Nível 2 é Planejamento do Projeto. Alcançam metas através de práticas-chave.

Áreas-chave de processo O objetivo principal das 18 KPAs (key process areas) são: N1 – Não tem kpas N2 – Estabelecer controles gerenciais básicos Gerência de Requisitos Planejamento do Projeto de Software Supervisão e Acompanhamento do Projeto Gerência de Contratos de Software Garantia da Qualidade de Software Gerência de Configuração de Software

Áreas-chave de processo N3 – Ações técnicas e gerenciais num só processo Revisão por Parceiros Coordenação entre Grupos Engenharia do Produto de Software Gerência de Software Integrada Programa de Treinamento Definição do Processo da Organização Foco no Processo da Organização os processos em vermelho são de responsabilidade da organização os demais são do projeto.

Áreas-chave de processo N4 – Entender quantitativamente o processo Gerência da Qualidade de Software Gerência Quantitativa do Processo N5 – Manter melhoria contínua do processo Gerência da Evolução de Processos Gerência da Evolução da Tecnologia Prevenção de Defeitos

Metas Resumem as práticas-chave das áreas-chave de processo e podem ser usadas para determinar se uma organização ou projeto tem efetivamente implementado a área-chave de processo. Significam o escopo, as fronteiras e a intenção de cada área-chave de processo. Um exemplo de um objetivo para a área-chave de processo do Planejamento de Projeto de Software é “estimativas são documentadas para uso no planejamento e controle do projeto".

Práticas-chave Práticas- Chave Atividades ou Infra-estrutura Descrevem Práticas- Chave Cada área-chave de processo é descrita em termos de práticas-chave que, quando implementada, ajudam a realizar seus objetivos. Descrevem a infra-estrutura e a maioria das atividades que contribuem para a implantação e institucionalização da área-chave. Ex: uma das práticas para a área-chave do processo de Planejamento de Projeto é "O plano de projeto é desenvolvido de acordo com um processo documentado”.

Práticas-chave Uma prática-chave descreve “o que” fazer sem estabelecer “como” fazer. O CMM define 316 práticas-chave. Distribuição de Áreas, Práticas e Metas por Nível: Áreas Práticas Metas N1 N2 6 121 20 N3 7 108 17 N4 2 31 6 N5 3 56 9

Características comuns Compromisso Habilitação Atividade Medição e Análise Verificação Implementação ou Institucionalização Abordam Características Comuns São As práticas-chave são divididas entre cinco seções. Características: Compromissos, Habilidades, Atividades, Medição e Análise, e Verificação da Implementação. São atributos que indicam se a implementação e institucionalização de uma área-chave esta efetiva, repetível, e permanente. A característica Atividade descreve as atividades de implementação. As demais características descrevem os fatores de institucionalização, que fazem parte do processo da cultura organizacional.

Conclusão Assim como os processos de software o CMM está em constante evolução. O CMM fornece uma estrutura conceitual para melhoria na gerência e desenvolvimento de produtos de software mas não assegura (nem pretende) que o software terá sucesso ou que todos os problemas serão resolvidos. CMM identifica características de um processo de software eficaz, mas outros fatores também são essenciais para o sucesso de um projeto como pessoas e tecnologia.

Referências Soeli T. Fiorini, Arndt von Staa, Renan Marins Baptista Engenharia de Software com CMM, 2002; Mark C. Paulk,Bill Curtis,Mary Beth, Chrissis, Charles V. Weber Capability Maturity ModelSMfor Software, Version 1.1, 1993. Carnegie Mellon – Software Engeneering Institute http://www.sei.cmu.edu/cmm/