CMM Aula 7

Prévia do material em texto

Capability Maturity Model Integration (CMMI)
Introdução
· Aumento no consumo de software nos últimos anos;
· Cultura própria de trabalho em empresas pequenas (ROCHA et al., 2001).
· Clientes de software desejam ter:
· Suas necessidades e expectativas atendidas;
· Softwares entregues no prazo acordado;
· Sem custos adicionais;
· Sem sustos e percalços; e
· Suporte ao longo de todo ciclo de vida.
· Desenvolvedores devem demonstrar competência:
· Entregar e suportar os níveis de serviço especificados;
· Menos espaço para informalidade;
· Busca e sustentabilidade:
· Para obter vantagem competitiva (enfoque no custo de cada projeto).
· A adoção de um modelo de maturidade se tornou uma exigência (comercialização internacional de produtos de software).
· Competência exigida dos desenvolvedores de software:
· Domínio da tecnologia;
· Controle dos processos operacionais;
· Gestão tática; e
· Gestão dos negócios
· Competência da empresa:
· Disciplina do controle;
· Elevados padrões de maturidade.
· Estrutura organizacional:
· Fator crítico de sucesso para a implementação de qualquer estratégia
· Fornece elementos para a inferência sobre os principais direcionadores de mudança e sustentação a uma estratégia organizacional.
Introdução ao CMM
· Tendo em vista estes fatores, foi especificado na década de 80 um modelo que possibilitasse as organizações avaliar riscos de contratação de fornecedores de software para as forças armadas Norte Americanas.
· O objetivo era garantir que os produtos fossem entregues com prazo estipulado e com qualidade.
· Para implantar esse modelo, as forças Armadas instituíram o SEI (Software Engineering Institute), o qual ficou responsável pela evolução do Capability Maturity Model (CMM)
· O CMM é um modelo de avaliação e melhoria de maturidade de processo de software.
Origem do CMM
· 1986: início do desenvolvimento de um modelo de maturidade de processo, para ajudar as organizações a melhorar seus processos de software.
· junho 1987: liberação de breve descrição do modelo de maturidade de processo de software.
· setembro 1987: versão preliminar do questionário de maturidade
· 1991: 1a versão do CMM (Versão 1.0)
· 1993: depois de 5 anos de experiência, o modelo de maturidade evoluiu para um modelo completamente definido, usando conhecimento adquirido das avaliações de processo de software e de extensivo retorno das indústrias e do governo <-> CMM
· fevereiro 1993: Versão 1.1 do CMM - Capability Maturity Model for Software (atualmente usada)
Objetivos do CMM
· Auxiliar o gerenciamento e mudança de processo;
· Fornecer uma estrutura básica para métodos confiáveis e coerentes de avaliação de organizações de software;
· Auxiliar a melhoria do processo interno de software;
· Fornecer um guia para empresas implementarem melhorias em seu processo.
CMM Hoje
· CMM deixou de ser aplicado apenas ao governo Norte Americano e passou a ser utilizado em:
· Software Houses;
· Grandes Bancos;
· Fabricantes de Hardware;
· Empresas de consultorias.
Dados sobre CMM
· Primeiro trimestre de 2003
· SW-CMM: 2616 appraisals (avaliação) realizados em 51 países e reportados ao SEI:
· EUA (1671), Índia (238), Reino Unido (119), França (110), Japão (77), China (73), Canadá (59), Alemanha (30), Israel (28), Austrália (27), Itália (26), Coréia (22), Singapura (17), Brasil (16), etc.
· CMMI : 71 appraisals reportados em 11 países e reportados ao SEI
· EUA (34), Japão (13), Austrália (8), França (4), Índia (4), Reino Unido (2), Taiwan (2), Dinamarca (1), Rússia (1), Coréia do Sul (1), Suíça (1).
Conceitos sobre maturidade de processos
· Processo de software: é um conjunto de atividades, métodos, práticas e transformações utilizados para desenvolver e manter um software.
· Capacidade do processo de software: descreve o alcance dos resultados esperados que podem ser obtidos pela utilização do processo de software.
· Maturidade do processo de software: é a extensão em que um processo específico é explicitamente definido, gerenciado, medido, controlado e efetivo.
· Como uma organização pode obter ganhos de maturidade no processo de software: institucionalizando seu processo por meio de políticas, padrões e estruturas organizacionais.
CMM
· O CMM possui 5 níveis de certificação ou como são chamados, níveis de maturidade, sendo estes:
1. Inicial: Imprevisível; Incontrolável;
2. Repetível: tem por objetivo identificar e documentar os processos possibilitando repetir o sucesso.
3. Definido: aplicar as políticas definidas em todos os projetos.
4. Gerenciado: analisar os resultados dos projetos para melhorias.
5. Otimizado: a organização é totalmente madura e entra em um círculo de melhoria contínua. Essa certificação ou nível é muito rigoroso e exige muita dedicação para ser atingido, tanto é que no nível 2 no Brasil temos apenas 16 empresas.
CMM – 5 níveis de maturidade
Nível 1 - INICIAL
· Nível 1: no nível inicial os processos são:
· Informais e imprevisíveis, tanto positiva quanto negativamente.
· O desempenho está ligado diretamente em função da competência e heroísmo das pessoas que realizam o trabalho.
· Atingir uma alta qualidade e um excelente desempenho é possível, porém, depende das pessoas envolvidas.
· Neste nível o maior problema é gerencial e não técnico.
· Neste nível o processo é uma CAIXA-PRETA
· Os requisitos fluem para dentro do processo.
· Um produto de software é (normalmente) produzido por meio de algum processo.
· O produto flui para fora do processo e (espera-se) funciona.
· O nível 1 não possuí áreas-chaves de processo, também conhecidas como KPA (Key Process Area).
· O cronograma e a previsão de custos normalmente estouram em organizações que estão no nível 1.
Nível 2 - REPETÍVEL
· Nível 2: neste nível são utilizados sistemas de gerenciamentos de projeto, tendo como objetivo obter:
· Desempenho é repetido.
· Gerenciamento eficaz de projeto de software. Isto é basicamente uma necessidade constante na organização.
· Documentação e acompanhamento constante dos processos de gerenciamento de software.
· Práticas bem-sucedidas desenvolvidas em projetos anteriores podem ser repetidas em novos projetos.
· Políticas organizacionais orientam os projetos estabelecendo processos de gerenciamento.
· O foco neste nível é mais voltado nos projetos do que na organização.
· Observação importante:
· o nível 2 de maturidade foca na melhoria dos processos de gerência de projetos e o maior desafio que as organizações enfrentam para alcançar este nível é relacionado as mudanças culturais e não com a implantação dos novos processos propriamente dito.
· Implementar mudanças no meio do projeto requer:
· Sensibilidade e comprometimento da alta direção, corpo gerencial e técnico, podendo ser arriscado e ainda comprometer o sucesso do projeto.
· Neste nível o processo é um conjunto de CAIXAS PRETAS com pontos de verificação definidos.
· Os planos baseados no passado são mais realistas em organizações no nível 2.
Nível 3 - DEFINIDO
· Os processos de software estão: (administrativa e de engenharia)
· Documentados;
· Padronizados; e
· Integrados.
· Isto por meio de um processo de software padrão para a organização.
· Todos os projetos usam uma versão aprovada do processo de software padrão da organização para desenvolvimento e manutenção de software
· Neste nível o processo é um conjunto de CAIXAS BRANCAS com pontos de verificação definidos.
· Funções e responsabilidades no processo são bem entendidos.
· A produção de software é visível por meio do processo
· Caracterizado principalmente pela existência:
· Processo de engenharia de software bem definido, documentado e um padrão para a empresa.
· As saídas de uma atividade fluem naturalmente para as entradas da próxima atividade.
· Cada projeto de software utiliza o processo padrão da organização como base para implementar seu próprio processo.
· Um grupo para processos de software responsável por facilitar atividades de definição e melhoria de processos.
· Treinamento para pessoas e grupos: assegura que todos tenham conhecimento e a capacidade desejada para desenvolver astarefas.
· Processos que deem poderes as pessoas para realizarem o trabalho.
Nível 4 - GERENCIADO
· Neste nível o processo é um conjunto de CAIXAS BRANCAS e são gerenciados quantitativamente.
· A gerência tem bases objetivas para tomada de decisão.
· A gerência é capaz de prever o desempenho dentro de limites quantificados.
· Caracterizado principalmente pela existência:
· Processos de software passíveis de medida.
· Produtividade e a qualidade: medidas em todas as etapas do processo e para todos os projetos da organização.
· Controle sobre produtos e processos de todos os projetos: adquiridos por meio da diminuição da variação do seu desempenho para dentro de limites quantitativos aceitáveis.
· Aplicação de métricas de controle de qualidade: aumentar a qualidade e a produtividade do software entregue.
· Conhecimento sobre o produto: oportunidade de remover várias fontes de comprometimento da qualidade final.
· Este controle proporciona a oportunidade de colocar o produto sob um controle estatístico de qualidade.
Nível 5 – MATURIDADE
· Melhorias contínuas no processo, utilizando medidas quantitativas de qualidade do processo e produto, e aplicando ideias e tecnologias inovadoras.
· Caracterizado principalmente pela existência:
· Processos de software com contínua melhoria.
· Avaliação do processo: prevenir defeitos conhecidos (recorrência), e as lições aprendidas são disseminadas para outros projetos.
· Tecnologias que proporcionem mais retorno para processos específicos, utilizados pela organização, são selecionadas para serem introduzidas, de maneira gerenciável na organização.
· Apesar de o processo ser maduro, ele é alvo de contínuas melhorias.
· Os grupos de projetistas analisam o rendimento do projeto para determinar as causas dos defeitos.
· Nesse nível foi atingido um ambiente de excelência em engenharia de software.
Modelos CMM
· CMMI: CMM Integration
· SW-CMM: Capability Maturity Model for Software
· SA-CMM: (Software Acquisition Capability Maturity Model) usado para avaliar a maturidade de uma organização em seus processos de seleção, compra e instalação de software desenvolvido por terceiros.
· SE-CMM: (Systems Engineering capibility Maturity Model) avalia a maturidade da organização em seus processos de engenharia de sistemas, concebidos como algo maior que o software. Um “sistema” inclui o hardware, o software e quaisquer outros elementos que participam do produto completo.
· IPD-CMM: (Integrated Product Development capibility Maturity Model) ainda mais abrangente que o SE-CMM, inclui também outros processos necessários à produção e suporte ao produto, tais como suporte ao usuário, processos de fabricação, etc.
· P-CMM: (People Capability Maturity Model) avalia a maturidade da organização em seus processos de administração de recursos humanos no que se refere a software; recrutamento e seleção de desenvolvedores, treinamento e desenvolvimento, remuneração etc.
Principais problemas
· O surgimento de todos estes modelos gerou alguns problemas.
· Terminologia não é comum aos modelos, ou o mesmo termo com significados diferentes.
· Necessidade de um formato padrão. Os modelos tinham diferentes números de níveis ou formas diferentes de avaliar o progresso.
· Altos custos de treinamento, avaliação e harmonização para organizações que tentassem usar mais de um modelo.
· Por outro lado, a experiência no uso do SW-CMM durante uma década serviu para identificar pontos em que o modelo poderia ser melhorado
O que é o CMMI
· É um modelo de referência que fornece orientação para o desenvolvimento de processos de softwares e tem como principais objetivos:
· Eliminar suas inconsistências;
· Aumentar sua clareza e entendimento;
· Fornecer uma terminologia comum e um estilo consistente;
· Estabelecer regras de construção uniformes e assegurar consistência com a ISO/IEC 15504.
· O CMMI não define como o processo deve ser implementado, mas prescreve suas características estruturais e semânticas em termos de objetivos e de grau de qualidade com que o trabalho deve ser realizado.
· O CMMI constitui tanto um modelo de capacidade como um modelo de maturidade.
· O modelo dentro de uma empresa pode ser alcançado em etapas consecutivas, representando a idéia de maturidade ou também de maneira contínua, onde são mensuradas a capacidade em práticas individuais.
· Quando uma organização atinge um nível de maturidade, considera-se que seus processos alcançaram uma determinada capacidade, ou seja, tem mecanismos que garantem a repetição sucessiva de bons resultados futuros relacionados principalmente à qualidade, custos e prazos.
Objetivo do CMMI
· Suprir as limitações do modelo CMM;
· Criação de um framework comum, eliminado inconsistências e permitindo a inclusão de novos modelos;
· Preservar os investimentos já realizados pelos:
· Organismos governamentais;
· Empresas privadas;
· Fornecedores; e 
· Indústria no processo de transição;
· Unificar os vários modelos CMM existentes.
· Implementar melhorias no SW-CMM a partir das experiências adquiridas com os projetos já implementados;
· Reduzir o custo do treinamento, das implementações de melhorias, da formação de avaliadores oficiais e das avaliações oficiais
Principais vantagens do CMMI
· Integração entre as atividades de gerenciamento e engenharia em suas metas de negócio;
· Ampliar o escopo e a visibilidade em todo o ciclo de vida dos produtos e atividades de engenharia, para permitir que o produto ou os serviços atenda às expectativas dos clientes;
· Ter maior ênfase nas atividades de gerenciamento de riscos, requerimentos, rastreabilidade, medição e análise;
· Ter foco tanto em produtos, serviços e em processos, como na capacitação dos processos e na maturidade da organização.
CMMI
· Principal mudança do CMMI em relação ao SW-CMM é a possibilidade de utilizar 2 diferentes abordagens para a melhoria de processos: Modelo contínuo e o Modelo em estágios.
· O SW-CMM é um modelo em estágios.
· Existem cinco níveis de maturidade, e a organização é avaliada como estando em apenas um deles.
· Em cada nível, a partir do nível 2, existem as chamadas “áreas chave de processo”. O SW-CMM possui 18 áreas-chave, e cada uma situa-se em apenas um nível. Assim, para uma organização estar no nível 2, é necessário que as 6 áreas-chave deste nível estejam institucionalizadas.
· Uma organização no nível 2 pode, por exemplo, possuir práticas de níveis mais altos, mas ser apenas nível 2, por não possuir o conjunto completo das áreas do nível mais alto.
· No “modelo contínuo” cada área-chave de processo possui características relativas a mais de um nível.
· Uma área-chave que, no modelo em estágios, pertence exclusivamente ao nível 2, no modelo contínuo pode ter características que a coloquem em outros níveis.
· No modelo contínuo, cada área chave é classificada separadamente, de modo que a organização pode ter áreas no nível 1, outras no nível 2, ainda outras no nível 3 e assim por diante.
Estágios X Contínua
· Representação por estágios (staged): foca a maturidade organizacional e provê um caminho evolutivo para a melhoria do processo. Esta representação direciona e auxilia às organizações que desejam estabelecer a melhoria de processos de software. As áreas do processo são agrupadas em níveis de maturidade, que devem ser atendidas na sua totalidade para viabilizar um estágio definido de melhorias.
· Representação contínua (continuous): foca a capacitação do processo e oferece um caminho flexível para a implementação de melhorias. Permite que as organizações escolham áreas específicas do processo para a implementação de melhorias, bem como implementar níveis diferentes de capabilidade para diferentes processos.
CMM - SCAMPI
· O CMMI adota outro método de avaliação, o SCAMPI (Standard CMMI Appraisal Method for Process Improvement), baseado no ARC (Appraisal Requirements for CMMI) , combina as características do CBA-IPI e SCE e também pode suportar a condução de avaliações ISO/IEC 15504 (SPICE). O SCAMPI avalia o processo de engenharia (software, sistemas e hardware) e tanto podeser utilizado para avaliar a maturidade de um processo de software como a capacitação de processos para efeito de benchmarking entre organizações.
· A avaliação oficial é conduzida por um Lead Appraiser e possui uma maior ênfase na coleta e análise de dados, buscando mais evidências.