A apresentação está carregando. Por favor, espere

A apresentação está carregando. Por favor, espere

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

Apresentações semelhantes


Apresentação em tema: "Capability Maturity Model for Software – CMM Fundamentos da Engenharia de Software Janeiro/2003 Daniel Leitão Corrêa e Silva Eduardo Lima Fernandes Rafael."— Transcrição da apresentação:

1 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

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

3 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).

4 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

5 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

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

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

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

9 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.

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

11 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

12 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.

13 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.

14 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].

15 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.

16 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.

17 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

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

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

20 Áreas-chave de processo 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. Metas Áreas-chave de Processo Áreas-chave de Processo Alcançam

21 Á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

22 Á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.

23 Á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

24 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".

25 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 Práticas- Chave Atividades ou Infra-estrutura Atividades ou Infra-estrutura Descrevem

26 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: N1000 N N N46312 N59563 MetasPráticasÁreas

27 Características comuns 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. Características Comuns Características Comuns Compromisso Habilitação Atividade Medição e Análise Verificação Compromisso Habilitação Atividade Medição e Análise Verificação Implementação ou Institucionalização Implementação ou Institucionalização Abordam São

28 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.

29 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, Carnegie Mellon – Software Engeneering Institute


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

Apresentações semelhantes


Anúncios Google