Aula 3 - Cap 5

Prévia do material em texto

Capítulo 1
Capability Maturity Model 
(CMM) 
 Capability Maturity Model Integration (CMMI)
O que é CMM
Os 5 Niveis de Maturidade do CMM
Caracterização Comportamental dos Níveis de Maturidade
As inspirações do CMM
Os objetivos do CMMI
Conceitos básicos do CMMI
Áreas de Processo do CMMI
Agenda
Qualidade de Software
Uma empresa imatura:
Processos são improvisados ou não são seguidos;
O trabalho é feito em regime de emergência (apagar incêndio);
Compromissos de prazo e custo não são cumpridos;
O planejamento não é feito com base em estimativas realistas;
Como os processos não são bem definidos todas as iniciativas de melhoria não se sustentam e não se perpetuam;
Quando o projeto é pressionado por prazo, a qualidade e a funcionalidade são sacrificadas;
O sucesso de um projeto depende de especialistas (“gurus”) para resolver grandes problemas;
Frequentemente novas tecnologias são adotadas como solução milagrosa.
Qualidade de Software
desenvolvedor
usuário
organização
Processo
de
Desenvolvimento
SOFTWARE PRODUTO
requisitosatendidos
PROCESSO DE SOFTWARE
requisitos de software produto 
SOFTWARE COM QUALIDADE
Capability Maturity Model (CMM)
http://www.baguete.com.br/artigos/143/carlos-alberto-caram-amp-renato-chaves-vasques/24/04/2007/passos-para-comprovacao-da-aut
5
Histórico
O SW-CMM (Capability Maturity Model for Software) é um modelo de capacitação de processos de software, desenvolvido pelo SEI (Software Engineering Institute) Carnegie Mellon University, Pittsburgh, PA e patrocinado pelo Departamento de Defesa Americano (DoD), para a avaliação da capacidade dos fornecedores de software deste último.
Início dos trabalhos deu-se em 1986, tendo sido publicada a versão 1.0 do SW-CMM em agosto de 1991.
Em junho 1987 - liberação de breve descrição do modelo de maturidade de processo de software.
Em setembro 1987 - versão preliminar do questionário de maturidade
1991 – 1ª versão do CMM (Versão 1.0)
Em fevereiro de 1993, foi publicada a versão 1.1.
Histórico
Por ser específico para a área de software, o SW-CMM não contemplava outras áreas importantes das organizações, tais como Recursos Humanos e Engenharia de Sistemas.
Com o sucesso do SW-CMM, outros modelos semelhantes foram criados para outras áreas, tais como Gestão de Recursos Humanos (People-CMM), Aquisição de Software (SA-CMM) e Engenharia de Sistemas (SE-CMM).
Entretanto, os diversos modelos apresentavam estruturas, formatos e termos diferentes, dificultando sua aplicação conjunta.
Software
CMM
Systems
Security
Engineering CMM
Systems
Engineering
CMM
People
CMM
SECM 
(EIA 731)
Integrated
 Product 
Development
CMM
Software
Acquisition
CMM
Diferentes estruturas, formatos, termos, maneiras de medir maturidade
Causa confusão, especialmente quando mais de um modelo é utilizado
Difícil de integrar em um único programa de melhoria
Histórico
Proliferação de Modelos e Padrões em diversas áreas
SECM : System Engineering Capability Model
8
Histórico
O CMMI (Capability Maturity Model Integration) foi criado, então, com a finalidade de integrar os diversos modelos CMM.
Em 1999, foi publicado o esboço (draft), versão 0.2: CMMI-SE/SW (Capability Maturity Model Integrated – System/Software Engineering).
Versões do CMMI:
Versão 1.0: Agosto de 2000
Versão 1.1: Março de 2002
Versão 1.2: Agosto de 2006 (CMMI for Development)
Versão 1.3: Novembro de 2010
SW-CMM
Modelo de Maturidade de Capacitação para Software
Objetivo Principal: guiar organizações a conhecerem e melhorarem seus processos de software.
Identifica práticas para um processo de software maduro, definindo as características de um processo de software efetivo. 
Descreve como as práticas de engenharia de software evoluem sob certas condições.
Organiza os estágios de evolução da melhoria dos processos em cinco níveis de maturidade.
O modelo descreve um caminho evolucionário que vai de um processo indisciplinado para um processo disciplinado
SW-CMM: Estrutura
Cada nível de maturidade, com exceção do primeiro, é composto por áreas-chave de processo (Key Process Areas – KPAs).
Cada KPA identifica atividades relacionadas que, quando executadas adequadamente, atingem determinados objetivos considerados importantes para o aumento da capacidade do processo.
As KPAs são os requisitos para a obtenção de um nível no CMM.
As KPAs são cumulativas, isto é, para uma organização atingir um determinado nível de maturidade, ela deve satisfazer todas as KPAs daquele nível e de seus inferiores.
SW-CMM: Estrutura
Cada KPA é descrita em termos de práticas-chave (Key Practices). 
Uma prática-chave descreve as atividades e a infra-estrutura necessárias para a efetiva implementação e institucionalização de uma KPA.
Uma prática-chave descreve “o quê” deve ser feito, e não “como” deve ser feito.
SW-CMM: Estrutura
Para cada KPA existem metas a serem alcançadas, que caracterizam o seu conteúdo, escopo e limite. 
Metas são usadas para determinar se a organização ou projeto efetivamente implantou a KPA em questão.
 
Em uma avaliação de conformidade com o CMM, o mais importante é verificar se todas as metas da KPA foram atingidas 
SW-CMM: Visão Geral
http://www.dcc.ufrj.br/~schneide/es/2002/2/t01/index.html
14
SW-CMM: Níveis de Maturidade
Um nível de maturidade é um patamar evolutivo bem definido, que visa a alcançar um processo de software maduro. 
Os níveis são uma forma de priorizar as ações de melhoria, de tal forma que se aumente a maturidade do processo de software. 
No nível 2 por exemplo, são focados aspectos gerenciais dos projetos.
O conceito de maturidade é baseado na noção de que alguns processos provêem mais estrutura e controle do que outros.
SW-CMM – Níveis de Maturidade
Processo continuamente 
melhorado
Processo previsível e controlado
Processo consistente e padronizado
Processo disciplinado
1- Inicial
2- Repetível
3- Definido
4- Gerenciado
5- Otimizado
Processo imprevisível e sem controle
16
INICIAL
Organizações Caóticas
REPETÍVEL
Organizações Disciplinadas
DEFINIDO
Organizações Padronizadas
GERENCIADO
Organizações Previsíveis
OTIMIZADO
Organizações com Melhoria Contínua
SW-CMM – Níveis de Maturidade
SW-CMM: Exemplo
http://www.cordeiro.pro.br/aulas/engenharia/qualidade/Cmm6Slides.pdf
18
SW-CMM: Exemplo
http://www.cordeiro.pro.br/aulas/engenharia/qualidade/Cmm6Slides.pdf
19
SW-CMM: Exemplo
http://www.cordeiro.pro.br/aulas/engenharia/qualidade/Cmm6Slides.pdf
20
SW-CMM: Nível 1 (Inicial)
entrada
saída
O processo de software é caracterizado como sendo imprevisível e ocasionalmente caótico.
Poucos processos são definidos e o sucesso depende de esforços individuais e, muitas vezes, heróicos.
O processo de software é uma caixa preta, de forma que somente as entradas e os produtos finais podem ser vistos com clareza. 
SW-CMM: Nível 1
Organizações no nível 1 apresentam deficiências de planejamento e enfrentam dificuldades ao realizarem previsões.
Cronogramas e planos são irrealistas.
Como não há credibilidade no planejamento, mesmo aquilo que foi planejado não é seguido.
Não há controle de requisitos e o cliente só avalia os mesmos na entrega do produto.
É comum passar diretamente dos requisitos à codificação.
A documentação é encarada como algo inútil.
São comuns reações intransigentes à coleta de dados e ao uso de padrões, documentação e ferramentas.
SW-CMM: Nível 1
A organização não possui um ambiente estável para o desenvolvimento e manutenção de software.
Cronogramas e orçamentos são freqüentemente abandonados por não serem baseados em estimativas realísticas.
Em uma crise para cumprir cronograma, etapas planejadas do ciclo de vida não são realizadas prejudicando a qualidade do software.
SW-CMM: Nível 2 (Repetível)
entrada
saída
Processos básicos de gerência de projetos são estabelecidos para controle de custos, prazos e escopo.
É possível repetir sucessos de projetos anteriores em aplicações similares.
No lugar do processo ser uma única caixa preta, ele passa a ser uma seqüência de caixas pretas que asseguram a visibilidade em determinados pontos, os marcos do projeto.
SW-CMM: Nível2 (Repetível)
Neste nível, organizações têm maior probabilidade de cumprir compromissos de requisitos, prazos e custos, mas desde que sejam semelhantes a outros realizados anteriormente.
A organização é disciplinada, mas não está bem preparada para mudanças.
Há preocupação com a gerência do projeto. Os gerentes acompanham custos, cronogramas e funcionalidades de cada um dos projetos. Porém, a gerência ainda não é pró-ativa, tomando ações normalmente quando se está diante de uma crise.
Os projetos podem ter processos diferentes. No entanto, existe uma política para guiar os projetos no estabelecimento desses processos.
Controla-se a evolução dos requisitos, permitindo avaliações ao final de cada marco do projeto, e controla-se, também, a evolução das configurações do software.
SW-CMM: Nível 2 (KPAs)
Gerência de Requisitos
Planejamento de Projetos
Supervisão e Acompanhamento de Projetos
Gerência da Subcontratação de Software
Garantia da Qualidade de Software
Gerência de Configuração de Software 
Durante o ciclo de vida do desenvolvimento, o software passa por uma série de modificações, desde sua concepção à implantação. Durante seu ciclo de vida, o software passa por uma série de modificações, desde sua concepção à implantação.  
Sob este aspecto, a Gerência de Configuração de Software (CGS) vem a definir critérios que permitam realizar tais modificações mantendo-se a consistência e a integridade do software com as especificações. 
26
SW-CMM: Nível 3 (Definido)
entrada
saída
Um processo de software, composto por atividades de gerência e engenharia, é documentado, padronizado e integrado em um processo de software padrão da organização.
Todos os projetos utilizam uma versão aprovada e adaptada do processo organizacional para desenvolvimento e manutenção de software.
A organização interna das tarefas está definida e visível
SW-CMM: Nível 3 (Definido)
Processos utilizados são estabelecidos e padronizados em toda a organização.
Os processos pertencem à organização e não aos projetos.
O Grupo de Processos (Software Engineering Process Group - SEPG) é responsável pelos processos da organização.
Apesar da padronização, é possível adaptar os processos para as necessidades particulares de um projeto.
Processos de engenharia de software são considerados ao lado dos processos gerenciais.
Há treinamento técnico e gerencial.
A organização consegue se manter dentro do processo mesmo em períodos de crise.
Como o processo é bem definido, caso um desenvolvedor abandone o projeto antes de seu término, o impacto é relativamente menor que nos níveis anteriores.
Passagem do nível 2 para o 3: a padronização realizada é a oportunidade de escolher as melhores práticas existentes na organização.
SW-CMM: Nível 3 (KPAs)
Foco no Processo da Organização
Definição do Processo da Organização
Programa de Treinamento
Gerência de Software Integrada
Coordenação entre grupos
 
Engenharia de Produtos de Software
Revisão por Pares 
SW-CMM: Nível 4 (Gerenciado)
entrada
saída
Métricas detalhadas do processo de software e da qualidade do produto são coletadas.
Tanto o processo como o produto de software são quantitativamente compreendidos e controlados.
30
SW-CMM: Nível 4 (Gerenciado)
A organização estabelece metas quantitativas de qualidade e produtividade para as atividades do processo;
Medidas de qualidade e produtividade são coletadas em todos os projetos como parte de um processo organizacional de medição e estabelecem uma base quantitativa para que os gerentes possam avaliar o progresso do desenvolvimento e a ocorrência de problemas.
Os projetos melhoram o seu controle sobre os produtos e processos e a variação das medidas é pequena.
É estabelecido o controle estatístico de processos.
Uma organização no nível 4 passa a ter uma gestão feita com bases quantitativas.
SW-CMM: Nível 4 (KPAs)
Gerência Quantitativa dos Processos
Gerência da Qualidade de Software
SW-CMM: Nível 5 (Otimizado)
entrada
saída
A melhoria contínua do processo é estabelecida por meio de sua avaliação quantitativa, e da implantação planejada e controlada de tecnologias e idéias inovadoras.
SW-CMM: Nível 5 (Otimizado)
A organização está engajada na melhoria contínua de seus processos, possuindo meios para identificar fraquezas e fortalecer o processo de forma pró-ativa, prevenindo defeitos.
O entendimento do processo ultrapassa os processos praticados, possibilitando compreender os efeitos de alterações potenciais no processo.
Melhorias em processos e tecnologias são planejadas e executadas como parte das atividades de rotina.
Mudanças mais significativas de processos ou de tecnologias são feitas a partir de análises de custo/benefício com base em dados quantitativos cuja coleta iniciou-se no nível 4.
SW-CMM: Nível 5 (KPAs)
Prevenção de Defeitos
Gerência da Evolução dos Processos
Gerência da Evolução das Tecnologias 
SW-CMM: Capacidade x Pessoas
sucesso depende de heróis individuais
sucesso depende de indivíduos, apoio administra-tivo
grupos de projeto trabalham juntos
forte senso de trabalho em equipe dentro de cada projeto
forte senso de trabalho em equipe na organização
“apagando incêndio” é o modo de viver
comprometimentos são compreendi-dos e admi-nistrados
treinamento é planejado e de acordo com os papéis
todos estão envolvidos na melhoria do processo
relacão entre disciplinas são descordena-das e até adversas
as pessoas são treinadas
Nível 1
Nível 2
Nível 3
Nível 4
Nível 5
SW-CMM: Capacidade x Tecnologia
introdução de nova tecnologia é um risco
tecnologia apoia atividades estáveis e estabeleci-das
novas tecnologias são avaliadas em bases qualitativas
novas tecnologias são procuradas e desenvolvi-das
Nível 1
Nível 2
Nível 3
Nível 4
Nível 5
novas tecnologias são avaliadas em bases quantitativas
SW-CMM: Capacidade x Tecnologia
coleta de dados e análise são feitas ad hoc
dados de administração e planejamento usados em projetos individuais
dados são coletados e usados em todo processo definido
definição e coleta de dados padroniza-dos na organização
dados são usados para avaliar e selecionar melhorias de processo
dados são compartilha-dos ao longo do projeto
dados são usados para compreender o processo quan-titativamente e estabilizá-lo
Nível 1
Nível 2
Nível 3
Nível 4
Nível 5
CMMI
Proposta de um modelo integrado que pode ser utilizado em várias disciplinas.
Disciplinas do CMMI:
Engenharia de Software
Engenharia de Sistemas: abordagem interdisciplinar cujo objetivo é o desenvolvimento bem-sucedido de sistemas como um todo, envolvendo software ou não.
Desenvolvimento integrado do produto e processo: abordagem sistemática que utiliza a colaboração dos stakeholders para melhor satisfazer as expectativas e requisitos dos clientes. Usada em conjunto com práticas de produção de um produto específico.
Fontes de Aquisição: aquisição de produtos de fornecedores.
Objetivos do CMMI
Além da integração dos modelos e redução dos custos com melhorias de processo, os seguintes objetivos também fazem parte do projeto CMMI:
Aumento do foco das atividades
Integração dos processos existentes
Eliminar inconsistências
Reduzir duplicações
Fornecer terminologia comum
Assegurar consistência com a norma ISO 15504
Flexibilidade e extensão para outras disciplinas
CMMI
É um modelo que descreve orientações para a definição e implantação de processos.
O modelo não descreve processo algum, são orientações definidas através das práticas especificadas.
Método de avaliação utilizado: SCAMPI (Standard CMMI Assessment Method for Process Improvement)
Um método de avaliação cujo objetivo é determinar o nível de aderência de um processo, ou conjunto de processos, à um modelo de referência.
CMMI: Conceitos Básicos
Área de Processo (Process Area – PA): práticas relacionadas em uma área que, quando executadas de forma coletiva, satisfazem um conjunto de metas consideradas importantes para trazer uma melhoria nessa área. 
Metas Específicas: se aplicam a uma PA e tratam de características que descrevem o que deve ser implementado para satisfazer essa PA. São utilizadas nas avaliaçõespara auxiliar a determinar se a PA está sendo satisfeita.
CMMI: Conceitos Básicos
Práticas Específicas: atividades que são consideradas importantes na satisfação de uma meta específica associada
Metas Genéricas: aparecem em diversas PAs.
Práticas genéricas: oferecem uma institucionalização que assegura que os processos associados com a PA serão eficientes, repetíveis e duráveis.
Produtos de trabalho típicos: exemplos de saídas de uma prática específica ou genérica.
Sub-práticas: descrições detalhadas que fornecem um direcionamento para a interpretação de práticas específicas ou genéricas. 
CMMI: Conceitos Básicos
Metas específicas e metas genéricas são componentes exigidos do modelo. Esses componentes devem ser atingidos pelos processos planejados e implementados por uma organização.
Práticas específicas e práticas genéricas são componentes esperados do modelo. Os componentes esperados descrevem o que uma organização normalmente implementará para satisfazer um componente exigido. 
CMMI: Conceitos Básicos
Sub-práticas, produtos de trabalho típicos, entre outros, são componentes informativos do modelo que auxiliam os usuários do modelo a entender as metas e práticas e a maneira como elas devem ser satisfeitas. 
Os componentes informativos fornecem detalhes que auxiliam os usuários do modelo a começar a pensar em como abordar as metas e práticas.
CMMI: Conceitos Básicos
http://chaienes.com.br/?p=297
46
Exemplo: Meta e Prática Específicas
PA: Gerência de Requisitos
Meta Específica: Gerenciar Requisitos
Requisitos são gerenciados e inconsistências com planos de projeto e produtos de trabalho são identificados.
Prática Específica: Manter rastreabilidade bidirecional entre requisitos. 
Manter rastreabilidade bidirecional entre os requisitos e planos de projeto e produtos de trabalho.
Produtos de Trabalho Típicos: Matriz de rastreabilidade, Sistema de Acompanhamento de Requisitos
Meta Genérica (do Nível 2 de Capacidade ou Maturidade)
 Institucionalizar um processo gerenciado.
Prática Genérica (do Nível 2 de Capacidade ou Maturidade)
 Estabelecer uma política organizacional.
Exemplo: Meta e Prática Genéricas
CMMI: Representações 
 Contínua
Níveis de Capacidade
Agrupamento de Áreas de Processo por Categoria
Avaliação da Capacidade nas Áreas de Processo
Por Estágios
Níveis de Maturidade
Agrupamento de Áreas de Processo por Nível
Avaliação da Organização/Unidade Organizacional como um todo
As PAs do CMMI são as mesmas para ambas as representações.
http://www.dgz.org.br/dez08/Art_04.htm
49
CMMI: Representações 
http://dc228.4shared.com/doc/xFBKPBDY/preview.html
50
CMMI: Representações 
http://dc228.4shared.com/doc/xFBKPBDY/preview.html
51
CMMI: Representações 
http://dc228.4shared.com/doc/xFBKPBDY/preview.html
52
CMMI: Representações 
CMMI: Representações 
http://dc228.4shared.com/doc/xFBKPBDY/preview.html
54
Processo imprevisível, pouco controlado 
Processo caracterizado para projetos e freqüentemente reativo
Processo pró-ativo e caracterizado para a organização
Processo medido e controlado
Foco na melhoria do processo
Gerenciado Quantitativamente
Inicial
Gerenciado
Definido
1 
2
3
4 
5 
Otimizado
Níveis de Maturidade
Representação por Estágios
Inicial
Repetível
Definido
Gerenciado
Otimizado
CMM:
Inicial
Repetível
Definido
Gerenciado
Otimizado
55
Representação por Estágios
57
Em Estágios
NM1
NM2
NM3
NM4
NM5
Um conjunto de áreas de processo de um nível de maturidade (NM).
PA
PA
 Capacidade
0 1 2 3 4 5
PA
Contínua
Uma única área de processo (PA) ou um conjunto de áreas de processo.
Comparando as Representações
Representação Contínua: Vantagens
Fornece maior flexibilidade focando em áreas de processo específicas de acordo com metas e objetivos de negócio
Permite a comparação de áreas de processo entre diferentes organizações
Estrutura familiar para aqueles que estão migrando da comunidade de engenharia de sistemas
Foco bem definido nos riscos específicos de cada área de processo
Estrutura compatível com a ISO/IEC 15504
Representações Por Estágios: Vantagens
Fornece uma rota de implementação por meio de:
grupos de área de processo
implementação em seqüência
cada nível funciona como a fundação para o próximo
Estrutura familiar para aqueles que estão migrando do SW-CMM.
Habilidade de gerenciar processos ao longo da organização.
Em uma avaliação, atribui um nível de maturidade em que a organização se encontra, permitindo, assim, comparar organizações de forma direta.
http://www.sinfic.pt/SinficNewsletter/sinfic/Newsletter30/Dossier2.CMMIDuasRepresentacoes.html
59
Áreas de Processo do CMMI
PAs são organizadas em quatro categorias de processo: Gerenciamento de Processos, Gerenciamento de Projetos, Engenharia e Suporte.
http://cmmi05.vilabol.uol.com.br/AreaProcesso2.html#OPF
60
Gerenciamento de Processos
Atividades relativas à definição, planejamento, distribuição de recursos, aplicação, implementação, monitoramento, controle, avaliação, medição e melhoria de processos. 
Envolve as seguintes PAs:
Foco no Processo Organizacional (básica)
Definição do Processo Organizacional (básica)
Treinamento Organizacional (básica)
Desempenho do Processo Organizacional (avançada)
Inovação e Desenvolvimento Organizacional (avançada)
Gerenciamento de Projetos
Atividades de gerência de projetos relacionadas ao planejamento, monitoramento e controle do projeto. 
Envolve as seguintes PAs:
Planejamento de Projetos (básica)
Monitoramento e Controle de Projetos (básica)
Gerência de Acordos com Fornecedores (básica)
Gerência Integrada de Projetos (avançada)
Gerência de Riscos (avançada)
Integração de Equipes (avançada)
Gerência Quantitativa de Projetos (avançada)
Engenharia
Atividades de desenvolvimento e manutenção que são compartilhadas entre as disciplinas de engenharia (por exemplo, engenharia de sistemas e engenharia de software).
Envolve as seguintes PAs:
Gerência de Requisitos 
Desenvolvimento de Requisitos 
Solução Técnica 
Integração de Produtos 
Verificação 
Validação
Engenharia de Software
Engenharia de Sistemas: abordagem interdisciplinar cujo objetivo é o desenvolvimento bem-sucedido de sistemas como um todo, envolvendo software ou não.
63
Suporte
Atividades que apóiam o desenvolvimento e a manutenção de produtos.
As PAs de Suporte tratam os processos que são utilizados no contexto da execução de outros processos, a saber:
Gerência de Configuração (básica)
Garantia da Qualidade do Processo e do Produto (básica)
Medição e Análise (básica)
Ambiente Organizacional para Integração (avançada)
Análise de Decisões e Resoluções (avançada)
Análise de Causas e Resoluções (avançada)
Mudanças durante o desenvolvimento são inevitáveis; o entendimento dos usuários sobre suas necessidades muda, o ambiente no qual o sistema vai operar muda, a legislação muda, os requisitos mudam. Com tantas mudanças assim, é necessária alguma forma de gerenciamento para que o desenvolvimento não fique caótico.
Gerência de Configuração de Software (GCS) é um conjunto de atividades de apoio que permite a absorção controlada das mudanças inerentes ao desenvolvimento de software, mantendo a estabilidade na evolução do projeto.
A GCS responde às seguintes questões básicas, que depois são desmembradas em outras questões mais específicas:
Quais mudanças aconteceram no sistema?
Por que essas mudanças aconteceram?
O sistema continua íntegro mesmo depois das mudanças?
http://pronus.eng.br/artigos_tutoriais/gerencia_configuracao/gerencia_configuracao.php
64
Gerência de Requisitos
Planejamento de Projeto 
Monitoração e Controle de Projeto
Garantia da Qualidade do Processo e do Produto
Gerência de Acordo com Fornecedores
Gerência de Configuração 
Medição e Análise
CMMI: Objetivos das PAs do Nível 2
CMMI: Objetivos das PAs do Nível 2
Gerência de Requisitos: gerenciar os requisitos dos produtos e componentes de produtos do projeto e identificar as inconsistências entre estes requisitos e os planos e os produtos de trabalho do projeto. Envolve:
Assegurar que o conjunto de requisitos acordados é gerenciado paraapoiar as necessidades de planejamento e execução do projeto.
Documentar as mudanças nos requisitos e suas justificativas, e manter a rastreabilidade bidirecional entre os requisitos fonte e todos os requisitos de produtos e componentes de produtos.
Planejamento de Projetos: estabelecer e manter planos que definem as atividades do projeto. Envolve:
Desenvolver o plano do projeto
Interagir com os stakeholders de forma apropriada
Obter compromissos com o plano
Manter o plano
CMMI: Objetivos das PAs do Nível 2
Monitoramento e Controle do Projeto: oferecer um entendimento do progresso do projeto, de maneira que as ações corretivas apropriadas possam ser tomadas quando o desempenho do projeto se desviar significativamente do plano. Envolve:
Monitorar atividades, comunicar status e tomar as ações corretivas. 
O progresso é basicamente determinado pela comparação dos atributos reais de produtos de trabalho e tarefas, esforço, custo e cronograma com o que foi planejado. 
CMMI: Objetivos das PAs do Nível 2
Gerenciamento de Acordos com Fornecedores: gerenciar a aquisição de produtos de fornecedores para os quais existe um acordo formal. Envolve:
Determinar o tipo de aquisição que será utilizada para os produtos a serem adquiridos
Selecionar os fornecedores
Estabelecer e manter acordos com fornecedores
Executar o acordo com o fornecedor
Aceitar a entrega dos produtos adquiridos
Fazer a transição dos produtos adquiridos para o projeto 
CMMI: Objetivos das PAs do Nível 2
Medição e Análise: desenvolver e sustentar a capacidade de medições que é utilizada para apoiar as necessidades de gerenciamento de informações. Envolve:
Especificar os objetivos de medições e análises, de forma que estes estejam alinhados com as necessidades e objetivos de informações identificadas
Especificar as medidas, mecanismos de coleta de dados e armazenamento, técnicas de análises e mecanismos de comunicação e de feedback
Implementar a coleta, armazenagem, análise e relatórios sobre os dados
Fornecer resultados objetivos que possam ser utilizados na tomada de decisões bem informadas e na tomada das ações corretivas apropriadas 
CMMI: Objetivos das PAs do Nível 2
Garantia da Qualidade do Processo e do Produto: fornecer à equipe e à gerência um entendimento objetivo dos processos e seus produtos de trabalho associados. Envolve:
Avaliar objetivamente os processos, produtos de trabalho e serviços executados contra as descrições de processo, padrões e procedimentos aplicáveis
Identificar e documentar questões de não conformidades
Fornecer feedback para a equipe do projeto e gerentes sobre os resultados das atividades de garantia da qualidade
Assegurar que as questões de não conformidades sejam tratadas
CMMI: Objetivos das PAs do Nível 2
Gerência de Configuração: estabelecer e manter a integridade dos produtos de trabalho, utilizando a identificação da configuração, controle da configuração, comunicação do status da configuração e auditorias de configurações. Envolve:
Identificar a configuração de produtos de trabalho selecionados que compõem as baselines em determinados momentos no tempo
Controlar as mudanças nos itens de configuração
Construir ou fornecer especificações para construir produtos de trabalho a partir do sistema de gerenciamento de configurações
Manter a integridade das baselines
Fornecer um status preciso e os dados atuais de configurações para desenvolvedores, usuários finais e clientes 
CMMI: Objetivos das PAs do Nível 2
Mudanças durante o desenvolvimento são inevitáveis; o entendimento dos usuários sobre suas necessidades muda, o ambiente no qual o sistema vai operar muda, a legislação muda, os requisitos mudam. Com tantas mudanças assim, é necessária alguma forma de gerenciamento para que o desenvolvimento não fique caótico.
Gerência de Configuração de Software (GCS) é um conjunto de atividades de apoio que permite a absorção controlada das mudanças inerentes ao desenvolvimento de software, mantendo a estabilidade na evolução do projeto.
A GCS responde às seguintes questões básicas, que depois são desmembradas em outras questões mais específicas:
Quais mudanças aconteceram no sistema?
Por que essas mudanças aconteceram?
O sistema continua íntegro mesmo depois das mudanças?
http://pronus.eng.br/artigos_tutoriais/gerencia_configuracao/gerencia_configuracao.php
Uma baseline é um conjunto de especificações ou produtos de trabalho que foram formalmente revisados e sobre os quais foi feito um acordo, que serve como base para desenvolvimento posterior e que pode ser modificado somente através dos procedimentos de controle de mudanças. 
Uma baseline representa a atribuição de um identificador a um item de configuração e suas entidades associadas.
Para Engenharia de Sistemas: Liberar uma baseline envolve aprovar um conjunto de dados de configurações para o conjunto acordado de itens de configurações, a partir do sistema de gerenciamento de configurações e liberar a baseline para posterior desenvolvimento. Múltiplas baselines podem ser utilizadas para definir um produto que está evoluindo no seu ciclo de desenvolvimento. Um conjunto comum inclui os requisitos no nível do sistema, requisitos de design no nível de elementos do sistema e a definição do produto no final do desenvolvimento/início da produção. Estes são referenciados como a “baseline funcional”, “baseline alocada” e “baseline do produto”.
Para Engenharia de Software: Um conjunto de requisitos, design, arquivos de código fonte e o código executável associado, arquivos de construção e documentação do usuário (entidades associadas) aos quais tenha sido atribuído um identificador único, pode ser considerado como sendo uma baseline. Liberar uma baseline consiste na recuperação dos arquivos de código fonte (itens de configurações) a partir do sistema de gerenciamento de configurações e geração dos arquivos executáveis. Uma baseline que é entregue a um cliente é normalmente chamada de “release”, enquanto que uma baseline para uso interno é normalmente chamada de “build”.
http://www.spinsp.org.br/CMMI/CM/SP13CM.htm
72
Gerência de Projeto Integrada 
Definição do Processo Organizacional 
Foco no Processo Organizacional 
Treinamento Organizacional 
Desenvolvimento de Requisitos 
Solução Técnica 
Integração do Produto 
Verificação
Validação 
Gerência de Riscos 
Análise de Decisão e Resolução
CMMI: PAs do Nível 3
Nível 4:
Gerência Quantitativa do Projeto 
Desempenho do Processo Organizacional
Nível 5:
Análise de Causas e Resolução 
Inovação e Implantação na Organização 
CMMI: PAs do Nível 4 e 5
CMMI no Mundo
CMMI no Mundo
CMMI no Mundo
CMMI no Mundo
CMMI no Mundo
http://www.blogcmmi.com.br/avaliacao/como-anda-o-cmmi-no-mundo-2011
http://www.blogcmmi.com.br/avaliacao/lista-de-empresas-cmmi-no-brasil
http://www.blogcmmi.com.br/avaliacao/lista-de-empresas-mps-br-no-brasil
79
http://www.blogcmmi.com.br/avaliacao/como-anda-o-cmmi-no-mundo-2011
http://www.blogcmmi.com.br/avaliacao/lista-de-empresas-cmmi-no-brasil
http://www.blogcmmi.com.br/avaliacao/lista-de-empresas-mps-br-no-brasil
http://sas.sei.cmu.edu/pars/pars.aspx
CMMI: Links Importantes
http://www.blogcmmi.com.br/
http://www.sei.cmu.edu/
CMMI: Links Importantes