cmm – capability maturity model

CMM – Capability Maturity Model

Alef MenezesAndré Teixeira

Danilo GoisEdton LemosLeandro Neto

UNIVERSIDADE FEDERAL DE SERGIPEDepartamento de Computação –

DCOMPQualidade de Software – T01 – 2016.1Prof: José Henrique de Melo Cardoso

2

ROTEIRO1. INTRODUÇÃO;2. PRINCIPAIS CARACTERÍSTICAS DO CMM;3. NÍVEIS DE MATURIDADE;4. ÁREAS CHAVES DE PROCESSO;5. CARACTERÍSTICAS COMUNS E PRÁTICAS BÁSICAS;6. CONSIDERAÇÕES FINAIS E EVOLUÇÃO.

1 - INTRODUÇÃO

4

INTRODUÇÃO: O CMM

• O modelo Capability Maturity Model (CMM), ou Modelo de Maturidade em Capacitação, é uma iniciativa do SEI (Software Engineering Institute) e apoiado pelo DoD (Department of Defense), para avaliar e melhorar a capacitação de empresas que produzem software;

5

HISTÓRICO

• O projeto CMM foi apoiado pelo Departamento de Defesa dos EUA por ser um grande consumidor de software e precisava de um modelo formal que permitisse selecionar os seus fornecedores de software de forma adequada;

• Década de 1980 como um modelo para avaliação de risco na contratação de empresas de software;

• Avaliar os processos de desenvolvimento utilizados pelas empresas que concorriam em licitações como indicação da previsibilidade da qualidade, custos e prazos nos projetos contratados;

6

HISTÓRICO

• Embora não seja uma norma emitida por uma Instituição Internacional (como a ISO ou IEEE), esta norma teve uma grande aceitação mundial, até mesmo fora do mercado americano;

• O CMM é também chamado de SW-CMM (Software CMM);

• Divulgado a partir de 1991, tornou-se um dos modelos de maior prestígio.

7

HISTÓRICO: O CMM

• Neste modelo, as organizações de software são enquadradas em um dos cinco níveis de maturidade que são definidos;

• Essa estrutura, em níveis do CMM, está baseada nos princípios de qualidade de produto propostos por Walter Shewart, William Edwards Deming, Joseph Juran e Philip Crosby;

8

HISTÓRICO: O CMM

• É um modelo desenvolvido para aplicação específica em software dentro de um contexto de qualidade total (TQM – Total Quality Management) no âmbito de uma organização;

• Se baseia principalmente na experiência da comunidade de software da indústria americana e em conceitos de gerenciamento de processos de autores consagrados em aplicação de processos de qualidade em outras áreas.

9

REPERCUSSÃO

• O modelo CMM teve repercutiu tão bem que diversos outros se baseiam diretamente nele, como é o caso do Bootstrap e do Trillium, e ainda influenciou fortemente outros como o SPICE.

10

MODELO DE MATURIDADE

• O CMM é um modelo para medição da maturidade de uma organização no que diz respeito ao processo de desenvolvimento e administração de software;

• Seu objetivo é definir qual o nível de maturidade e traçar os planos de ação para o desenvolvimento da organização;

11

MODELO DE MATURIDADE

• A definição do que é “Maturidade” pode ser melhor compreendida através da análise do quadro abaixo:

2 - PRINCIPAIS CARACTERÍSTICAS DO

CMM

13

PRINCIPAIS CARACTERÍSTICAS DO CMM

Aspecto Abordado Característica do CMM

ObjetivoDeterminar a capacitação da organização e apoiar a sua evolução de acordo com os níveis estabelecidos

AbordagemAvaliação dos processos e enquadramento da organização em um dos níveis de maturidade

Organizações alvo Organizações que necessitam de comprovação formal de sua capacidade

Definição de processosEstabelece 18 áreas de processos organizados em 5 níveis crescentes de maturidade

Instrumento de Avaliação Questionário

3 - NÍVEIS DE MATURIDADE

Contextualização

• O CMM classifica as organizações em níveis de maturidade e os dividi em 5, onde cada um possui suas características próprias;

• A divisão de níveis é feita em ordem crescente, quanto maior o nível maior a garantia de qualidade.

15

Níveis de Maturidade

16

Nível 1 - Inicial

• Organização imatura;• Sem metodologia definida;• Processo de Software

desorganizado;• Poucos ou nenhum processo

definido;• Sucesso derivado do esforço

individual e heroísmo.

17

Nível 1 - Inicial

• Sem garantias:• Custo;• Prazo e;• Funcionalidade;

• Requisitos fluem para dentro e produto flui para fora e espera-se que ele funcione.

18

Nível 2 - Repetível

• Processos básicos de gerenciamento de projeto:• Custo, cronograma e funcionalidade;

• Sucesso ligado a sucessos anteriores (projetos similares);• Processos caixa preta com pontos de verificação;• Possibilidade de produção de software de qualidade.

19

Nível 3 - Definido

• Desenvolvimento de software de acordo com um processo bem definido (Gerenciamento e Engenharia);

• Definição de como cada processo deve ser feito;• Aproveitamento e adaptação do processo padrão de

software da organização para o desenvolvimento e manutenção.

20

Nível 4 – Gerenciado

• Realização de medições detalhadas do processo de software e qualidade do produto;

• Processo e produto são gerenciados (entendidos e controlados) quantitativamente;

• A gerência é capaz de prever o desempenho dentro de limites quantificados.

21

Nível 5 – Otimização

• Foco na melhoria contínua do processo;• Realimentação quantitativa do processo através de ideias

e tecnologias inovadoras;• Mudança disciplinada é um meio de vida.

22

Observações

• Certificação de determinado nível só é obtida ao atingir todos os seus objetivos;

• Poucas empresas conseguiram atingir os níveis 4 ou 5 do CMM;

23

4 - ÁREAS CHAVES DE PROCESSO

ÁREAS CHAVE DE PROCESSOS (KPA’S)

• As áreas são o foco que a organização deve ter para melhorar seu processo de desenvolvimento de software;

• O critério para que um empresa possa se qualificar em um determinado nível de maturidade CMM, é realizar os processos relacionados às áreas chaves daquele determinado nível.

25

ÁREAS CHAVE DE PROCESSOS (KPA’S)

26

Nível CMM Foco Áreas Chave do Processo

Nível 1 – Inicial Pessoas competentes e “heróis”

ÁREAS CHAVE DE PROCESSOS (KPA’S)

27

Nível CMM Foco Áreas Chave do Processo

Nível 2 – Repetitivo Processos de gerenciamento de projetos

• Gerenciamento de requisitos

• Planejamento de projeto de software

• Acompanhamento de projeto de software

• Gerenciamento de subcontratos

• Qualidade assegurada de software

• Gerenciamento de configuração

ÁREAS CHAVE DE PROCESSOS (KPA’S)

28

Nível CMM Foco Áreas Chave do Processo

Nível 3 – Definido Processos de engenharia de apoio

• Foco no processo da organização

• Definição do processo da organização

• Programa de treinamento• Gerenciamento integrado

do software• Engenharia de produto do

software• Coordenação entre

grupos• Revisões

ÁREAS CHAVE DE PROCESSOS (KPA’S)

29

Nível CMM Foco Áreas Chave do Processo

Nível 4 – Gerenciado Qualidade do produto e do processo

• Gerenciamento quantitativo do processo

• Gerenciamento da qualidade do software

ÁREAS CHAVE DE PROCESSOS (KPA’S)

30

Nível CMM Foco Áreas Chave do Processo

Nível 5 – Otimizado Melhoramento contínuo do processo

• Prevenção de defeitos• Gerenciamento de

mudanças tecnológicas• Gerenciamento de

mudanças de processo

5 - CARACTERÍSTICAS COMUNS E PRÁTICAS

BASE

Características Comuns

• Itens a serem observados para verificar a implementação e institucionalização de cada área chave de processo.

• Podem indicar se a área chave de processo é eficiente, repetível e duradoura.

• Estabelece planos e procedimentos para desempenhar e monitorizar o trabalho, e caso necessário tomar ações corretivas.

32

Características Comuns

33

Característica comum Descrição Práticas-base relacionadas

Compromisso de realizar Atitudes a serem tomadaspela organização para

garantir que o processo se

estabeleça e seja duradouro.

Estabelecimento de políticas

de apadrinhamento degerente experiente.

Características Comuns

34

Característica comum Descrição Práticas-base relacionadas

Capacidade de realizar Pré-requisitos que devemexistir no projeto ou na

organização paraimplementar o processo

deforma competente.

Alocação de recursos,definição da estrutura

organizacional e detreinamento.

Características ComunsCaracterística comum Descrição Práticas-base

relacionadas

Atividades realizadas Papéis e o procedimentonecessário para

implementaruma área-chave de

processo.

Estabelecimento de planos e

procedimentos, realização do

trabalho, acompanhamento

do trabalho e tomada deações corretivas, se

necessário.

35

Características ComunsCaracterística comum Descrição Práticas-base

relacionadas

Medições e análise Necessidade de medir oprocesso e analisar as

medições.

Realização de medições para

determinar o estado e aefetividade das atividades

realizadas.

36

Características ComunsCaracterística comum Descrição Práticas-base

relacionadas

Implementação comverificação

Passos para garantir que as

atividades são realizadas de

acordo com o processoestabelecido.

Revisão, auditoria e garantia

de qualidade.

37

Práticas Base

• As práticas-base devem descrever “O que” deve ser feito e não “como” os objetivos devem ser atingidos.

• O modelo CMM inclui um extenso documento em separado, chamado “Práticas-base para o CMM”, que lista todas as práticas-chave e sub-práticas para cada uma das áreas chave de processo.

38

6 - CONSIDERAÇÕES FINAIS E EVOLUÇÃO

Estrutura Geral

40

Evolução do CMM

• Problemas de integração.

• Custos elevados na melhoria de processos.

• Custos elevados no treinamento do pessoal.

41

Modelo de Maturidade em Capacitação - Integração

• Criado para suprir os problemas do CMM.• Aumento do foco das atividades.• Integração dos processos existentes através de framework.• Eliminar inconsistências.• Reduzir duplicações.

42

CMM vs CMMI

• Representação Estagiada• Níveis de maturidade.• Agrupamento de áreas de processo por nível.• Avaliação da Organização/Unidade Organizacional como

um todo.

43

CMM vs CMMI

• Representação Contínua• Níveis de capacidade.

• Nível 0 – Incompleto• Nível 1 – Realizado• Nível 2 – Gerenciado• Nível 3 – Definido• Nível 4 – Gerenciado quantitativamente• Nível 5 – Otimizado

44

CMM vs CMMI

• Representação Contínua• Agrupamento de áreas de processo por categoria.• Avaliação da capacidade nas áreas de processo.• Usada quando deseja-se tornar apenas alguns processos

mais maduros.

45

REFERÊNCIAS• ALMEIDA, K.; AS CARACTERÍSTICAS DO CMM E O

DESENVOLVIMENTO. REVISTA ELETRÔNICA DE ADMINISTRAÇÃO, ed. 8, jun. 2005.

• RAMOS, R. A.; PADRÕES DE QUALIDADE DE SOFTWARE. DISCISPLINA ENGENHARIA DE SOFTWARE I. UNIVERSIDADE FEDERAL DO VALE DO SÃO FRANCISCO.

46

DÚVIDAS?

OBRIGADO!