Introdução ao CMM SM Capability Maturity Model

Transcrição

1 Introdução ao CMM SM Capability Maturity Model I Workshop de Qualidade em Produção de Software UEM - Universidade Estadual de Maringá Maringá - PR - 21 de novembro de 2001 Eduardo Paulo de Souza Eduardo.Souza@iti.gov.br Assuntos a Serem Tratados no Mini-Curso Considerações sobre Modelos de Introdução ao CMM Informações sobre CMMI 2 Apresentador Eduardo Paulo de Souza Especialista em Melhoria de no Laboratório de Avaliação e Melhoria Software. Bacharel em Análise de Sistemas - (PUCCAMP/85) Mestrando em Qualidade - (UNICAMP/01) 16 anos de experiência em Desenvolvimento de Software, Pesquisa Tecnológica, Qualidade, Treinamento e Consultoria em empresas privadas e públicas Áreas de Experiência / Interesse: Melhoria de e Melhoria de Produto foco em ISO/IEC / 9126 / / CMM / CMMI - ISO 9000: Até julho de 2000: Fundação Centro Tecnológico para Informática A partir de agosto de 2000: Instituto Nacional de Tecnologia da Informação Ministério da Ciência e Tecnologia - MCT ITI - Tecnologia & Soluções ITI para Qualidade de Software 9 Avaliação e Melhoria de s utilizando Modelos ISO/IEC (SPICE) e CMM/CMMI 9 Melhoria do de Gerência de Configuração de Sw 9 Melhoria do de Documentação para Usuário de Sw 9 Melhoria do de Teste de Software 9 Avaliação de Produtos de Software - Método MEDE-PROS 9 Avaliação e Melhoria de Web Sites Campinas, SP 5 6 página 1

2 Atuação do ITI em Melhoria de Foco atual: Melhoria do de Software com modelos ISO/IEC (SPICE), CMM / CMMI e outros Por meio de: Acompanhamento e Desenvolvimento Tecnológico de Modelos, Métodos, Normas (ISO/IEC e ABNT),... Eventos, Cursos, Palestras, Publicações,... Consultoria em Melhoria de, Avaliação, Plano de Ação, Implantação... 7 Projetos de consultoria realizados em Melhoria de Î Melhoria com ISO/IEC Senior (Blumenau, 99); Ábaco (Cuiabá, 99); Inep - MEC (Brasília, 2001). Î Melhoria com CMM CPqD sob liderança da Sodália (Itália); Alcatel (Campinas, 99). Î Melhoria com CMM e ISO/IEC Secretaria da Fazenda (São Paulo, 2000). 8 Introdução ao CMM SM Capability Maturity Model SM CMM e Capability Maturity Model são marcas de serviço (service marks) de Carnegie Mellon University 9 Visão Geral do CMM Aplicação criteriosa de conceitos de gerenciamento de processos e de melhoria da qualidade ao desenvolvimento e manutenção de software Baseado em boas organizações de software Modelo para melhoria organizacional, com um roteiro sequencial para a melhoria Define o quê deve ser feito, não o como Independente da tecnologia a ser utilizada 10 Histórico do CMM 1987: Characterizing the Software Process: A Maturity Framework, Watts Humphrey, IEEE Software 1989: Managing the Software Process, Watts Humphrey 1991: CMM v : CMM v : CMMI v CMM Capability Maturity Model Modelo do SEI (Estados Unidos) Versão 1.1, 1993 (e versão CMMI, 2000) Descreve elementos chave para melhoria e avaliação de processo de software Um roteiro sequencial, com cinco níveis de maturidade para evoluir as organizações de processos imaturos para processos maduros. 5. Otimizando 4. Gerenciado 3. Definido 2. Repetível 1. Inicial 12 página 2

3 Elementos e Estrutura do CMM indica capacidade do processo Níveis de Maturidade contém Níveis de Maturidade (Maturity Levels) Estágios para maturidade da organização metas realiza Áreas-chave de processo contém Características Comuns Cada nível atua como fundação do nível subseqüente Indica a capacidade dos processos implementação ou institucionalização descreve Práticas-chave organizadas por CMM define cinco níveis Cinco Níveis de Maturidade Disciplinado Padrão e Consistente 1. Inicial Imprevisível e mal controlado Previsível 3. Definido definido e bem entendido 2. Repetível Pode repetir atividades já dominadas Melhorando Continuamente 4. Gerenciado medido e controlado Gerenciamento de Projeto 5. Otimizando Foco na melhoria do processo Integrado com a Engenharia Gerenciando Mudanças Qualidade do Produto e do Níveis Entrada Visibilidade Capacidade Q & P Gerencial do R & R N-z N-y N-x N+a Probabilidade Alvo Saída N Custo/Prazo/... Qualidade Produtividade Risco Retrabalho 16 Áreas Chave de (Key Process Areas - KPA) Identifica um conjunto de atividades correlatas que, quando executadas, atingem um conjunto de metas consideradas importantes para a melhoria da capacidade dos processos Alocada em um único nível de maturidade São definidas 18 KPAs no CMM. 17 Nível 1: Inicial é improvisado por profissionais e gerentes; Não é rigorosamente acompanhado, nem controlado; Altamente dependente dos profissionais atuais; Funcionalidade e qualidade do produto podem ser comprometidas para cumprimento de prazos; Custos excessivos de manutenção; Qualidade, custos e prazos difíceis de se prever; Opera reagindo a crises; Maiores problemas são gerenciais e não técnicos. 18 página 3

4 Nível 2: Repetível Projetos podem repetir tarefas já dominadas Gerenciamento de projetos estabelecido 6 KPAs Gerenciamento de Configuração de Software Garantia da Qualidade de Software Gerenciamento de Subcontrato de Software Acompanhamento de Planejamento de Gerenciamento de Requisitos 19 Mudando do Nível 2 para o Nível 3 No Nível 2, o foco é no projeto. No Nível 3, a ênfase passa para a organização: as melhores práticas são colhidas em toda a organização processos são adaptados às necessidades particulares quando conveniente Organização suporta os projetos ao estabelecer: processos comuns medidas comuns treinamento 20 Áreas chave de processo (KPA) Nível 3: Definido 7 KPAs Revisões (peer review) Coordenação Intergrupos Engenharia de Produto de Software Gerenciamento Integrado de Software Programa de Treinamento Definição do da Organização Foco no da Organização 21 CMM Nível 3: Definido Melhores práticas s da engenharia de produto s da gerência de software de Software Padrão da Organização de software para o projeto Programa de treinamento para toda a Organização Nível 4: Gerenciado Nível 5: Otimizando é medido e controlado Foco na melhoria contínua do processo 2 KPAs Gerenciamento da Qualidade de Software Gerenciamento Quantitativo de 3 KPAs Gerenciamento de Mudança de Gerenciamento de Mudança de Tecnologia Prevenção de Defeitos página 4

5 Níveis de Maturidade não podem ser omitidos s dos níveis mais altos de maturidade podem ser realizados, embora talvez ineficazmente, até mesmo por organizações do nível 1; Cada nível oferece um fundamento necessário para melhorias a serem implementadas no nível seguinte; Sem a disciplina de gerenciamento o processo de engenharia é sacrificado; Medidas detalhadas são inconsistentes sem um processo definido. 25 Elementos das Áreas Chave de (KPA - Key Process Areas) Propósito Metas Práticas Chave, organizadas em: comprometimento para execução habilidade para execução atividades executadas medição e análise verificação da implementação 26 Práticas Chaves (Key Practices) CMM Nível 2: Repetível Infra-estrutura, políticas, procedimentos e atividades que mais contribuem para a efetiva institucionalização de uma KPA o quê deve ser feito (não como ) Organizadas pelas características comuns Existem 316 práticas chaves no CMM Estabelece processos para Gerenciamento de Projetos s são diferentes entre projetos Organização define políticas para os projetos Gerência de Requisitos project standar d Planejamento de Projeto Acompanhamento de Projeto Garantia da Qualidade Gerência de Configuração Gerência de Subcontrato Gerência de Projeto no CMM O Nível 2 de Maturidade do CMM estabelece processos para Gerenciamento de Projetos KPAs: Gerenciamento de Requisitos Planejamento de Acompanhamento de Com suporte das outras KPAs do Nível 2 29 Gerenciamento de Requisitos Gerenciando um Projeto Descrição do trabalho (ex.: contrato) Planejamento de Acompanhamento de Plano de desenvolvimento do software 30 página 5

6 Gerenciamento de Requisitos (Requirements Management) A finalidade é estabelecer um entendimento comum entre o cliente e a equipe do projeto de software sobre requisitos do cliente que serão abordados pelo software. documentar e controlar os requisitos do cliente; manter planos, produtos e atividades consistentes com os requisitos. 31 Planejamento de (Software Project Planning) A finalidade é estabelecer planos razoáveis para desenvolver o software e para gerenciar o projeto de software. z desenvolver estimativas para o trabalho a ser executado; z estabelecer os compromissos necessários; z definir o plano para realizar o trabalho. 32 Acompanhamento de (Software Project Tracking and Oversight) A finalidade é oferecer visibilidade adequada do progresso real para que a gerência possa tomar ações efetivas quando o desempenho se desvia significativamente do planejado z acompanhar e revisar os resultados e desempenho do projeto em relação aos planos, estimativas documentadas e compromissos; z ajustar os planos com base nos resultados efetivamente alcançados. 33 z z Garantia da Qualidade de Software (Software Quality Assurance) A finalidade é oferecer gerenciamento com visibilidade apropriada do processo que está sendo utilizado e dos produtos que estão sendo construídos. revisar e auditar os produtos de software e atividades para assegurar que estão em conformidade com os padrões e procedimentos aplicáveis; fornecer ao gerente do projeto e outros gerentes envolvidos os resultados das revisões e auditorias. 34 Gerenciamento de Configuração de Software (Software Configuration Management) A finalidade é estabelecer e manter a integridade dos produtos do projeto de software ao longo do ciclo de vida do software. identificar itens/unidades de configuração; controlar sistematicamente as alterações; manter integridade e rastreabilidade da configuração ao longo do ciclo de vida. 35 Gerenciamento de Subcontrato de Software (Software Subcontract Management) A finalidade é selecionar fornecedores qualificados de software e gerenciá-los eficazmente. selecionar um fornecedor de software; estabelecer compromissos com o fornecedor; acompanhar e revisar o desempenho do fornecedor e os resultados conseguidos. 36 página 6

7 Gerenciamento de Requisitos (Requirements Management) A finalidade é estabelecer um entendimento comum entre o cliente e a equipe do projeto de software sobre requisitos do cliente que serão abordados pelo software. documentar e controlar os requisitos do cliente; manter planos, produtos e atividades consistentes com os requisitos. 37 Requisitos alocados ao Software São um subconjunto dos requisitos de um sistema que serão atendidos por software Estes requisitos tem que ser documentado simples: um memorando elaborado: especificações em vários volumes Podem ser o contrato estabelecido entre o cliente e o desenvolvedor Foco é a visão do Cliente 38 Metas da KPA Gerenciamento de Requisitos Meta 1: Os requisitos alocados para o software são controlados para estabelecer uma configuração base para engenharia de software e uso do gerenciamento Meta 2: Planos de software, produtos, e atividades são mantidas consistentemente com os requisitos alocados para o software 39 Características Comuns (Common Features) Organizam as práticas chaves das KPAs Institucionalizam (e implementam) as práticas comprometimento para execução habilidade para execução atividades executadas medição e análise verificação da implementação 40 Práticas Chave (Key Practices) Infra-estrutura, políticas, procedimentos e atividades que mais contribuem para a efetiva institucionalização de uma KPA o quê deve ser feito (não como ) Organizadas pelas características comuns Existem 316 práticas chaves no CMM Práticas Chave KPA GR comprometimento para execução C1: O projeto segue uma política organizacional documentada para o gerenciamento dos requisitos página 7

8 Práticas Chave KPA GR habilidade para execução Ab1: Para cada projeto, a responsabilidade é estabelecida para análise dos requisitos do sistema e sua alocação de hardware, software e outros componentes Ab2: Os requisitos alocados são documentados Ab3: Recursos e verbas adequados são fornecidos para o gerenciamento dos requisitos Ab4: Membros do grupo de desenvolvimento de software e de outros grupos são treinados para executar as atividades do gerenciamento dos Práticas Chave KPA GR atividades executadas Ac1: O grupo de desenvolvimento de software revisa os requisitos alocados, antes que eles sejam incorporados ao projeto de software Ac2: O grupo de desenvolvimento de software utiliza os requisitos alocados como base para o plano de software, produtos de trabalho e atividades Ac3: Mudanças nos requisitos alocados são revisadas e incorporadas ao projeto de software requisitos Práticas Chave KPA GR medição e análise M1: Medições são realizadas e utilizadas para determinar o estado das atividades do gerenciamento dos requisitos Práticas Chave KPA GR verificação da implementação V1: As atividades para gerenciamento dos requisitos são revisadas com o gerente senior regularmente V2: As atividades para gerenciamento dos requisitos são revisadas com o gerente do projeto regularmente e por demanda V3: O grupo de garantia da qualidade revisa e/ou audita as atividades e produtos de trabalho do GR e documenta os resultados CMM Perfil de Maturidade das Organizações CMM, Agosto de 2001, 1018 Orgs. 40,0% 35,0% 39,1% Resultados de Utilização do Modelo Referência 30,0% 25,0% 20,0% 15,0% 10,0% 5,0% 27,1% 23,4% 5,6% 4,8% 0,0% 1:Inicial 2:Repetív. 3:Definido 4:Gerenc. 5:Otimiz. Fonte: SEI, 2001 Mid-Year Update - August página 8

9 Tendências dos Perfis de Maturidade CMM, 1987 a Fonte: Profile August 2001 % de Organizações :Inicial 2:Repetív. 3:Definido 4:Gerenc. 5:Otimiz ,3 6,9 0 0, ,4 21,8 11,9 1,4 0, ,5 22,5 14,2 2,1 0, ,6 26,7 14,7 3,1 0, ,3 30,3 15,8 3, ,4 32,7 17,4 4,3 3, ,7 32,4 19,3 4,2 3,5 Periodo #Orgs PSP, TSP & CMM, Criados por Watts Humphrey PSP: Personal Software Process - orientar PESSOAS TSP: Team Software Process - orientar EQUIPES CMM TSP PSP Principais Referências CMM / CMMI 9 Mark C. Paulk et al., The Capability Maturity Model for Software: Guidelines for Improving the Software Process, CMU SEI and Addison-Wesley, CMM for Software, Version 1.1; Relatório Técnico CMU/SEI-93-TR-24; Fevereiro Key Practices of the CMM for Software, Version 1.1; Relatório Técnico CMU/SEI-93-TR-25; Fevereiro Introduction to the Capability Maturity Model, Material oficial do curso CMU/SEI Vários livros, artigos, apresentações, tutoriais, etc Dúvidas, Comentários, outros pontos... Rodovia SP-65 (D. Pedro I), Km 143,6 Caixa Postal 6162, CEP Campinas - São Paulo Equipe de Melhoria de : Clenio.Salviano@iti.gov.br Eduardo.Souza@iti.gov.br Mary.Sant Ana@iti.gov.br telefone: 0xx fax: 0xx Contatos Obrigado pela atenção 53 página 9