CMMI em Português

em
CMMI-SE/SW, v1.1
Representação em Estágios
Prefácio
O projeto Capability Maturity Model Integration (CMMISM) envolveu

uma grande quantidade de pessoas de diferentes organizações do
®
mundo todo. Estas organizações utilizavam um modelo CMM ou
múltiplos CMMs e estavam interessadas nos benefícios do
desenvolvimento de um framework integrado para auxiliar a melhoria
de processos no âmbito do empreendimento como um todo. [FM101.T101]
O trabalho do projeto CMMI é patrocinado pelo Departamento de

Defesa dos Estados Unidos (Department of Defense – DoD),
especificamente pelo departamento da Sub-Secretaria de Defesa,
Aquisição, Tecnologia e Logística (Office of the Under Secretary of
Defense, Acquisition, Technology, and Logistics - OUSD/AT&L). O
patrocínio da indústria é garantido pelo Comitê de Engenharia de
Sistemas da Associação Industrial da Defesa Nacional (National
Defense Industrial Association - NDIA). [FM101.T102]
Organizações da indústria e do governo e o Instituto de Engenharia de

Software (Software Engineering Institute - SEI) se juntaram para
desenvolver o CMMI Framework, um conjunto integrado de modelos
CMMI, um método de avaliação CMMI e produtos de suporte. Estas
organizações doaram o tempo de um ou mais de seus empregados na
participação no projeto CMMI. [FM101.T103]
Histórico do Desenvolvimento
A equipe do projeto CMMI trabalhou para oferecer um direcionamento

que incentive a melhoria de processos em organizações de qualquer
estrutura. [FM101.HDA101.T101]
Desde 1991, têm sido desenvolvidos CMMs para uma grande

variedade de disciplinas. Alguns dos mais notáveis são os modelos
para engenharia de sistemas, engenharia de software, aquisição de
software, gerenciamento e desenvolvimento da força de trabalho e
Desenvolvimento Integrado de Produtos e Processos (Integrated
Product and Process Development – IPPD). [FM101.HDA101.T102]
CMM, Capability Maturity Model e Capability Maturity Modeling são marcas registradas no U.S. Patent and
Trademark Office.
S M
CMMI é uma marca de serviços da Carnegie Mellon University.
Prefácio i
CMMI-SE/SW, v1.1
Embora estes modelos tenham provado ser úteis para muitas

organizações, o uso de múltiplos modelos tem sido problemático.
Muitas organizações gostariam de concentrar seus esforços de
melhoria entre as disciplinas de suas organizações. Entretanto, as
diferenças entre estes modelos específicos de disciplinas, incluindo sua
arquitetura, conteúdo e abordagem, têm limitado a capacidade destas
organizações de concentrar com sucesso seus esforços de melhorias.
Além disso, aplicar diversos modelos que não estão integrados em
uma organização e em cada um de seus departamentos específicos,
se torna mais caro em termos de treinamentos, avaliações e das
próprias atividades de melhorias. Um conjunto de modelos integrados
que trate com sucesso disciplinas diversas e tenha um suporte
integrado a treinamentos e avaliações resolve esses problemas.
[FM101.HDA101.T103]
O projeto do CMM IntegrationSM foi montado para solucionar o

problema do uso de múltiplos CMMs. A missão da Equipe de Produto
do CMMI foi combinar três modelos básicos – (1) Capability Maturity
Model for Software (SW-CMM) v2.0 draft C, (2) Electronic Industries
Alliance Interim Standard (EIA/IS) 731, e (3) Integrated Product
Development Capability Maturity Model (IPD-CMM) v0.98 – em um
único framework de melhoria para ser utilizado por organizações que
estivessem em busca de uma melhoria de processos que abrangesse o
empreendimento como um todo. [FM101.HDA101.T106]
Desenvolver um conjunto de modelos integrados envolveu mais que

simplesmente juntar os materiais dos modelos já existentes. Utilizando
processos que promovem o consenso, a Equipe de Produto do CMMI
construiu um framework que acomoda diversas disciplinas e é flexível o
bastante para suportar dois tipos diferentes de representações (em
estágios e contínua). [FM101.HDA101.T107]
Usando como material fonte informações de modelos populares e bem

conhecidos, a Equipe de Produto do CMMI criou um conjunto coeso de
modelos integrados que podem ser adotados por aqueles que hoje
estejam utilizando outros modelos CMMs, bem como por aqueles que
ainda estão começando a conhecer o conceito do CMM. [FM101.HDA101.T108]
Durante a fase de desenvolvimento do projeto CMMI, a missão da

equipe incluiu o desenvolvimento de um framework comum para servir
de suporte para a futura integração de outros modelos CMMI de
disciplinas específicas. Além disso, a missão da equipe incluiu o
objetivo de assegurar que todos os produtos desenvolvidos eram
consistentes e compatíveis com o Relatório Técnico para Avaliação do
Processo de Software 15504 (15504 Technical Report for Software
Process Assessment) da International Organization for
Standardization/International Electrotechnical Commission (ISO/IEC).
[FM101.HDA101.T109]
S M
CMM Integration é uma marca de serviço da Carnegie Mellon University.
ii Prefácio
CMMI-SE/SW, v1.1
O CMMI versão 0.2 foi publicamente revisado e utilizado em atividades

piloto iniciais. A partir da liberação daquela versão, as melhorias foram
feitas a partir das solicitações de alteração originadas da revisão
pública, organizações piloto e sessões de grupo sobre diversos
assuntos. A Equipe de Produto do CMMI avaliou mais de 3.000
solicitações de alteração para criar o CMMI versão 1.0. Pouco tempo
depois, a versão 1.02 foi liberada, incorporando diversas pequenas
melhorias. Como ocorre com qualquer liberação, entretanto,
continuaram existindo oportunidades para outras melhorias. A versão
1.1 acomoda novas melhorias originadas a partir do uso inicial, bem
como de mais de 1.500 solicitações de alteração. [FM101.HDA101.T111]
Agradecimentos
Muitas pessoas talentosas estiveram envolvidas como parte da equipe

de produto para o CMMI Product Suite1. Os quatro grupos iniciais
envolvidos neste desenvolvimento foram o Grupo de Direcionamento
(Steering Group), a Equipe de Produto (Product Team), o Comitê de
Controle de Configurações (Configuration Control Board) e os
Stakeholders/Revisores. [FM101.HDA102.T101]
O Grupo de Direcionamento direciona e aprova os planos da Equipe de

Produto, fornece consultoria sobre questões significativas do projeto
CMMI e assegura o envolvimento de diversas comunidades
interessadas. [FM101.HDA102.T102]
A Equipe de Produto escreve, revisa, reexamina, discute e chega a

acordos sobre a estrutura e o conteúdo técnico do CMMI Product Suite,
incluindo o framework, modelos, treinamentos e materiais de avaliação.
As atividades de desenvolvimento foram baseadas na Especificação-A
(A-Specification) fornecida pelo Grupo de Direcionamento, os três
modelos fonte e comentários dos Stakeholders e dos membros do
Grupo de Direcionamento. [FM101.HDA102.T104]
O Comitê de Controle de Configuração tem sido o mecanismo oficial

para controlar as alterações nos modelos CMMI. Como tal, este grupo
assegura a integridade ao longo da vida do conjunto de produtos,
através da revisão de todas as alterações feitas na baseline e da
aprovação somente das mudanças que atendem os critérios da
próxima liberação. [FM101.HDA102.T113]
O grupo de organizações de Stakeholders/Revisores forneceu valiosas

colaborações sobre os primeiros esforços que foram feitos para
combinar os modelos. Com suas revisões das diversas versões do
conjunto de produtos deram ótimas contribuições à Equipe de Produto.
[FM101.HDA102.T105]
1
Veja no Capítulo 3 uma discussão sobre o “CMMI Product Suite” e o “CMMI Framework”, que ajudará a
esclarecer as diferenças entre eles.
Prefácio iii
CMMI-SE/SW, v1.1
No Apêndice E estão listados os membros atuais e eméritos dos quatro

grupos envolvidos no desenvolvimento dos produtos CMMI.
[FM101.HDA102.T111]
Onde Procurar Informações Adicionais
Você pode encontrar informações adicionais, como o público alvo,

cenários, históricos dos modelos CMMI e os benefícios de se utilizar os
modelos CMMI em diversas fontes. Muitas destas fontes estão
documentadas no site do CMMI, em http://www.sei.cmu.edu/cmmi/.
[FM101.HDA103.T101]
Feedback
Sugestões para melhorar o CMMI Product Suite são bem-vindas. Veja

o site do CMMI para obter informações sobre como fornecer feedback:
http://www.sei.cmu.edu/cmmi/. [FM101.HDA104.T101]
Se tiver perguntas, envie um e-mail para cmmi-

comments@sei.cmu.edu. [FM101.HDA104.T103]
iv Prefácio
CMMI-SE/SW, v1.1
Conteúdo
Prefácio i
Histórico do Desenvolvimento i
Agradecimentos iii
Onde Procurar Informações Adicionais iv
Feedback iv
1 Introdução 1
Sobre os Modelos CMMI 1
Selecionando um Modelo CMMI 2
Representações: Contínua ou em Estágios? 2
Representação Contínua 2
Representação em Estágios 3
Que Modelo Integrado Escolher? 3
Disciplinas: Qual é a Diferença? 3
Engenharia de Sistemas 4
Engenharia de Software 4
Desenvolvimento Integrado de Produtos e Processos 4
Uma Recomendação 5
O Conteúdo dos Modelos CMMI 5
Convenções Tipográficas 6
Metas Específicas e Genéricas 7
Práticas Específicas e Genéricas 7
Referências 7
Notas Introdutórias, Produtos de Trabalho Típicos e Sub-práticas 7
Exemplos 7
Elaborações das Práticas Genéricas 8
Definições Ampliadas de Disciplinas 8
Esquema de Numeração 8
Códigos de Identificação de Parágrafos 9
2 Componentes do Modelo 10
Visão Geral da Estrutura 10
Níveis de Maturidade 11
Detalhes dos Níveis de Maturidade 12
Nível de Maturidade 1: Inicial 12
Nível de Maturidade 2: Gerenciado 12
Nível de Maturidade 3: Definido 13
Prefácio v
CMMI-SE/SW, v1.1
Nível de Maturidade 4: Gerenciado Quantitativamente 14

Nível de Maturidade 5: Otimizado 15
Avançando Através dos Níveis de Maturidade 16
Saltando Níveis de Maturidade 17
Componentes Exigidos, Esperados e Informativos 18
Componentes do Modelo 19
Áreas de Processos 19
Metas Específicas 19
Práticas Específicas 20
Características Comuns 20
Produtos de Trabalho Típicos 20
Sub-práticas 20
Definições Ampliadas de Disciplinas 21
Metas Genéricas 21
Práticas Genéricas 21
Elaborações de Práticas Genéricas 21
Referências 22
Comparação das Representações de Modelos 22
3 Terminologia do Modelo 24
Evolução da Terminologia 24
Terminologia Comum com Significados Especiais 25
Adequado, Apropriado, Conforme Necessário 25
Estabelecer e Manter 25
Cliente 25
Stakeholder 25
Stakeholders relevantes 26
Gerente 26
Gerente do Projeto 26
Gerente Sênior 26
Visão Compartilhada 27
Organização 27
Empreendimento 27
Desenvolvimento 27
Disciplina 27
Projeto 28
Produto 28
Produto de Trabalho 28
Componente do Produto 28
Avaliação (Appraisal) 29
Análise (Assessment) 29
Instruções para Adaptação 29
Verificação 30
vi Prefácio
CMMI-SE/SW, v1.1
Validação 30
Meta 30
Objetivo 30
Objetivos de Qualidade e Desempenho do Processo 31
Padrão 31
Terminologia Específica do CMMI 31
CMMI Product Suite 31
Framework CMMI 31
Modelo CMMI 32
Revisão por Pares 32
Conjunto de Processos Padrão da Organização 32
Processo 32
Processo Gerenciado 33
Processo Definido 33
Ativos de Processos Organizacionais 33
Arquitetura dos Processos 34
Ciclo de Vida do Produto 34
Repositório de Medições da Organização 34
Biblioteca de Ativos de Processos da Organização 35
Documento 35
4 Características Comuns, Metas Genéricas e Práticas Genéricas 37

Visão Geral 37
Características da Institucionalização 37
Metas Genéricas 39
Características Comuns 40
Práticas Genéricas Listadas por Características Comuns 40
5 Interações do Framework 53
Quatro Categorias de Áreas de Processos do CMMI 53
Gerenciamento de Processos 54
O Escopo do Gerenciamento de Processos 54
Áreas de Processos Básicas do Gerenciamento de Processos 55
Áreas de Processos Avançadas do Gerenciamento de Processos 57
Gerenciamento de Projetos 59
O Escopo do Gerenciamento de Projetos 59
Áreas de Processos Básicas do Gerenciamento de Projetos 60
Áreas de Processos Avançadas de Gerenciamento de Projetos 61
Engenharia 64
O Escopo da Engenharia 64
Interações Entre as Áreas de Processos de Engenharia 65
Áreas de Processos de Engenharia e Recursão 68
Suporte 69
Prefácio vii
CMMI-SE/SW, v1.1
O Escopo do Suporte 69
Áreas de Processos Básicas de Suporte 70
Áreas de Processos Avançadas de Suporte 72
6 Utilizando os Modelos CMMI 76

Interpretando os Modelos CMMI 76
Avaliações e Benchmarking 77
Requisitos de Avaliações para o CMMI 79
Compatibilidade e Conformidade com o ISO/IEC 15504 79
Fazendo a Transição para o CMMI 80
Organizações com Experiência no CMM para Software 80
Organizações com Experiência em EIA/IS 731 81
Organizações Não Familiarizadas com os Modelos do Tipo CMM 82
Treinamento 83
Perspectivas de Adaptação 83
Adaptação do Modelo 83
Perspectivas de Adaptação do Modelo 83
Critérios de Adaptação de Modelos para Melhoria de Processos Internos 84
Critérios de Adaptação de Modelos para Benchmarking 85
Adaptação de Modelos para Pequenos Projetos 86
Adaptação de Avaliações 87
7 Áreas de Processos 89
Nível de Maturidade 2: Gerenciado 91
Gerenciamento de Requisitos 92
Planejamento do Projeto 105
Monitoramento e Controle do Projeto 136
Gerenciamento de Acordos com Fornecedores 153
Medições e Análises 171
Garantia da Qualidade do Processo e do Produto 195
Gerenciamento de Configurações 208
Nível de Maturidade 3: Definido 229
Desenvolvimento de Requisitos 230
Soluções Técnicas 254
Integração de Produtos 289
Verificação 312
Validação 331
Foco no Processo Organizacional 345
Definição do Processo Organizacional 365
Treinamento Organizacional 383
Gerenciamento Integrado do Projeto 402
Gerenciamento de Riscos 425
Análises de Decisões e Resoluções 448
viii Prefácio
CMMI-SE/SW, v1.1
A. Acrônimos 463
B. Glossário 468
C. Elementos Exigidos e Esperados do Modelo 498

Nível de Maturidade: 2 499
Gerenciamento de Requisitos 500
Planejamento do Projeto 503
Monitoramento e Controle do Projeto 508
Gerenciamento de Acordos com Fornecedores 512
Medições e Análises 516
Garantia da Qualidade do Processo e do Produto 520
Gerenciamento de Configurações 524
Nível de Maturidade: 3 529
Desenvolvimento de Requisitos 530
Soluções Técnicas 535
Integração de Produtos 540
Verificação 545
Validação 550
Foco no Processo Organizacional 554
Definição do Processo Organizacional 559
Treinamento Organizacional 563
Gerenciamento Integrado do Projeto 567
Gerenciamento de Riscos 572
Análises de Dcisões e Resoluções 576
Prefácio ix
CMMI-SE/SW, v1.1
1 Introdução
Um modelo é uma representação simplificada do mundo real. Os

modelos de maturidade de capacitação (Capability Maturity Models -
CMMs) contêm os elementos essenciais de processos eficientes para
uma ou mais áreas de conhecimento. Estes elementos se baseiam nos
conceitos desenvolvidos por Crosby, Deming, Juran e Humphrey
[Crosby 79, Juran 88, Deming 86, Humphrey 89]. [FM108.T101]
Como os outros CMMs, os modelos integrados de maturidade de

capacitação (Capability Maturity Model Integration - CMMI) fornecem
direcionamentos a serem utilizados no desenvolvimento de processos.
Os modelos CMMI não são processos ou descrições de processos. Os
processos reais utilizados em uma organização dependem de muitos
fatores, inclusive o(s) domínio(s) da aplicação e o tamanho e estrutura
da organização. Especificamente, as áreas de processos de um
modelo CMMI normalmente não podem ser mapeadas de um para um
com os processos utilizados na sua organização. [FM108.T102]
Sobre os Modelos CMMI
Um processo é um ponto de apoio da melhoria sustentada de uma

organização. O objetivo do CMM Integration é fornecer
direcionamentos para melhorar os processos de sua organização e sua
capacidade de gerenciar o desenvolvimento, aquisição e manutenção
de produtos e serviços. O CMM Integration coloca abordagens
comprovadas em uma estrutura que ajuda a sua organização a avaliar
a sua maturidade organizacional ou a capacitação da área de
processo, estabelecer prioridades de melhoria e implementá-las.
[FM108.HDA102.T101]
O conjunto de produtos CMMI (CMMI Product Suite) contém e é

produzido a partir de um framework que oferece a capacidade de gerar
múltiplos modelos e seus materiais de treinamento e avaliação
associados. Estes modelos podem refletir o conteúdo de áreas de
conhecimento (isto é, engenharia de sistemas, engenharia de software,
Desenvolvimento Integrado de Produtos e Processos) em combinações
mais úteis para você (isto é, CMMI-SE/SW, CMMI-SE/SW/IPPD).
[FM108.HDA102.T103]
Visão Geral 1
CMMI-SE/SW, v1.1
Sua organização pode utilizar um modelo CMMI para ajudar a definir os

objetivos e prioridades de melhoria de processos, melhorar processos
e fornecer direcionamento para assegurar processos estáveis,
capacitados e maduros. Um modelo CMMI selecionado pode servir
como guia para a melhoria dos processos organizacionais.
[FM108.HDA102.T102]
Utilize uma opinião profissional para interpretar as práticas específicas

e genéricas do CMMI. Embora as áreas de processos ilustrem
comportamentos que deveriam aparecer em qualquer organização,
todas as práticas devem ser interpretadas utilizando um conhecimento
profundo do modelo CMMI que está sendo utilizado, da organização,
do ambiente de negócios e das circunstâncias envolvidas.
[FM108.HDA102.T104]
Selecionando um Modelo CMMI
Existem diversos modelos CMMI disponíveis, gerados a partir do CMMI

Framework. Em conseqüência disso, você precisa estar preparado
para decidir qual modelo CMMI melhor atende às necessidades de
melhoria de processos da sua organização. [FM108.HDA101.T101]
Você deve selecionar uma representação, contínua ou em estágios, e

determinar as áreas de conhecimento que deseja incluir no modelo que
sua organização irá utilizar. [FM108.HDA101.T102]
Representações: Contínua ou em Estágios?
Existem muitas razões válidas para selecionar uma representação ou

outra. Pode ser que a sua organização escolha utilizar a representação
que lhe seja mais familiar. As listas seguintes descrevem algumas das
possíveis vantagens e desvantagens de selecionar cada uma das
representações. [FM108.HDA101.HDB101.T101]
Representação Contínua
Se você escolher a representação contínua para sua organização,

pode esperar que o modelo: [FM108.HDA101.HDB102.T101]
• Permitirá que você selecione a seqüência de melhorias que melhor

atende os objetivos de negócios e reduz as áreas de risco da sua
organização
• Possibilitará comparações dentro e entre organizações em uma
área de processo em termos de área de processo ou pela
comparação de resultados através do uso de estágios equivalentes
• Oferecerá uma migração fácil do Electronic Industries Alliance
Interim Standard (EIA/IS) 731 para o CMMI
2 Visão Geral
CMMI-SE/SW, v1.1
• Suportará uma fácil comparação de melhoria de processos para a

International Organization for Standardization and International
Electrotechnical Commission (ISO/IEC) 15504, já que a
organização das áreas de processos é similar ao ISO/IEC 15504
Se você escolher a representação em estágios para a sua organização,

pode esperar que o modelo: [FM108.HDA101.HDB103.T101]
• Oferecerá uma seqüência comprovada de melhorias, começando

com práticas básicas de gerenciamento e progredindo por um
caminho pré-definido e comprovado de níveis sucessivos, cada um
servindo como base para o próximo
• Permitirá comparação dentro da organização e entre organizações
pelo uso de níveis de maturidade
• Oferecerá uma migração fácil do SW-CMM para o CMMI
• Oferecerá uma classificação única que resume os resultados de
avaliações e permite comparações entre organizações
Quer sejam utilizadas para melhoria de processos ou avaliações,

ambas as representações foram projetadas para oferecer resultados
essencialmente equivalentes. [FM108.HDA101.HDB103.T102]
Que Modelo Integrado Escolher?
Atualmente existem três áreas de conhecimento disponíveis, quando

for selecionar um modelo CMMI: [FM108.HDA101.HDB104.T106]
• Engenharia de sistemas
• Engenharia de software
• Desenvolvimento Integrado de Produtos e Processos (Integrated
Product and Process Development – IPPD)
Este texto fará referências a estas áreas de conhecimento como

“disciplinas”. Por exemplo, quando nos referirmos a selecionar uma
“disciplina”, poderá ser uma das opções listadas acima. A Equipe de
Produto do CMMI prevê que outras áreas de conhecimento serão
integradas ao CMMI Framework. [FM108.HDA101.HDB104.T107]
Disciplinas: Qual é a Diferença?
Dependendo da disciplina que selecionar para seu modelo CMMI, leia

as seções relevantes abaixo. [FM108.HDA101.HDB109.T101]
Visão Geral 3
CMMI-SE/SW, v1.1
Engenharia de Sistemas
A engenharia de sistemas cobre o desenvolvimento de sistemas

completos, que podem ou não incluir software. Os engenheiros de
sistemas concentram-se em transformar necessidades, expectativas e
restrições dos clientes em soluções de produtos e fornecer suporte a
estas soluções de produtos durante toda a vida do produto.
[FM108.HDA101.HDB105.T101]
Quando você seleciona engenharia de sistemas para o seu modelo,

este conterá as áreas de processos de Gerenciamento de Processos
Gerenciamento de Projetos, Suporte e Engenharia. Definições
ampliadas específicas de disciplinas para engenharia de sistemas são
fornecidas para ajudá-lo a interpretar as práticas específicas para esta
disciplina, quando necessário. (Veja o Capítulo 2 para obter maiores
informações sobre definições ampliadas de disciplinas).
[FM108.HDA101.HDB105.T102]
Engenharia de Software
A engenharia de software cobre o desenvolvimento de sistemas de

software. Engenheiros de software se concentram em aplicar
abordagens sistemáticas, disciplinadas e quantificáveis ao
desenvolvimento, operação e manutenção de software.
[FM108.HDA101.HDB106.T101]
Quando você seleciona engenharia de software para o seu modelo,

este conterá as áreas de processo de Gerenciamento de Processos,
Gerenciamento de Projetos, Suporte e Engenharia. Definições
ampliadas específicas de disciplinas para engenharia de software são
fornecidas para ajudá-lo a interpretar as práticas específicas para a
engenharia de software. [FM108.HDA101.HDB106.T102]
Desenvolvimento Integrado de Produtos e Processos
O Desenvolvimento Integrado de Produtos e Processos (Integrated

Product and Process Development – IPPD) é uma abordagem
sistemática que consegue uma colaboração pontual de stakeholders
relevantes durante toda a vida do produto para melhor satisfazer as
necessidades, expectativas e requisitos do cliente. Os processos que
oferecem suporte a uma abordagem IPPD são integrados com os
outros processos da organização. As áreas de processos, metas
específicas e práticas específicas do IPPD isoladas não conseguem
criar um desenvolvimento integrado de produtos e processos. Se um
projeto ou organização escolhe utilizar o IPPD, tem que executar as
práticas específicas do IPPD juntamente com as outras práticas
específicas utilizadas para produzir os produtos (por exemplo, as áreas
de processos de Engenharia). Isto é, se uma organização ou projeto
deseja utilizar o IPPD, ela escolhe um modelo com uma ou mais
disciplinas além do IPPD. [FM108.HDA101.HDB107.T101]
4 Visão Geral
CMMI-SE/SW, v1.1
Quando você seleciona o IPPD como seu modelo, este conterá as

áreas de processos de Gerenciamento de Processos, Gerenciamento
de Projetos, Suporte e Engenharia que se aplicam tanto ao IPPD como
às outras disciplinas que você tenha selecionado para seu modelo.
Definições ampliadas de disciplinas específicas para o IPPD são
também fornecidas para ajudá-lo a interpretar as práticas específicas
do IPPD. [FM108.HDA101.HDB107.T102]
Uma Recomendação
A Equipe de Produto do CMMI recomenda que você selecione a

engenharia de sistemas e a engenharia de software, se sua intenção
for selecionar uma destas disciplinas. Esta recomendação se baseia no
fato que a única distinção entre os modelos de cada uma destas
disciplinas são as definições ampliadas incluídas. No restante, estes
modelos são exatamente iguais. [FM108.HDA101.HDB110.T101]
O Conteúdo dos Modelos CMMI
Os modelos CMMI com representação em estágios consistem de sete

capítulos e cinco apêndices: [FM108.HDA103.T101]
• Capítulo 1: O capítulo de Introdução (este capítulo) oferece uma

visão geral dos modelos CMMI, sugestões sobre onde procurar
outras informações que não estiverem incluídas nos modelos CMMI
e as convenções tipográficas usadas nos modelos CMMI.
• Capítulo 2: O capítulo dos Componentes do Modelo descreve os
componentes do modelo, incluindo os níveis de maturidade, metas
e práticas.
• Capítulo 3: O capítulo sobre Terminologia do Modelo descreve a
abordagem adotada no uso de termos nos modelos CMMI, bem
como a maneira como os termos foram selecionados e definidos
para o glossário.
• Capítulo 4: O capítulo sobre Características Gerais, Metas
Genéricas e Práticas Genéricas descreve as características gerais
e práticas genéricas que asseguram que a implementação dos
processos associados com as áreas de processos é eficiente,
repetível e durável.
• Capítulo 5: O capítulo sobre Interações do Framework oferece um
entendimento sobre o significado dos processos básicos e
avançados para as áreas de processos de Gerenciamento de
Projetos, Gerenciamento de Processos, Suporte e Engenharia.
• Capítulo 6: O capítulo Utilizando os Modelos CMMI explica as
maneiras como sua organização pode utilizar os modelos CMMI.
Visão Geral 5
CMMI-SE/SW, v1.1
• Capítulo 7: O capítulo sobre as Áreas de Processos contém

descrições dos componentes exigidos, esperados e informativos do
modelo que você selecionou, incluindo metas, práticas, sub-
práticas e produtos de trabalho típicos.
Os Apêndices são os seguintes: [FM108.HDA103.T104]
• Apêndice A: O apêndice de Referências contém informações que

você pode utilizar para encontrar as fontes documentadas, como
relatórios, modelos de melhoria de processos, padrões da indústria
e livros que foram utilizados para criar o conteúdo dos modelos
CMMI.
• Apêndice B: O apêndice de Acrônimos define as siglas utilizadas
nos modelos CMMI.
• Apêndice C: O apêndice do Glossário define os termos utilizados
nos modelos CMMI que não estiverem adequadamente definidos
pelo contexto ou não forem facilmente encontrados em dicionários.
• Apêndice D: O apêndice sobre Elementos Exigidos e Esperados do
Modelo contém os componentes exigidos e esperados para cada
área de processo. Não há outro material informativo além do
objetivo, título e títulos dos componentes de cada área de
processo.
• Apêndice E: O apêndice sobre os Participantes do Projeto CMMI
contém a lista de participantes dos Grupos de Direcionamento, da
Equipe de Produto, do Comitê de Controle de Configuração e da
Equipe de Stakeholders/Revisores do projeto CMMI.
Convenções Tipográficas
As convenções tipográficas utilizadas nos modelos CMMI otimizam sua

legibilidade e utilização. Apresentamos os componentes do modelo em
formatos que permitem que você os encontre rapidamente na página.
As seções seguintes oferecem algumas dicas para localização dos
diversos componentes do modelo nos modelos CMMI. [FM108.HDA105.T101]
Veja o Capítulo 2 para obter definições sobre os componentes do

modelo mencionados. [FM108.HDA105.T102]
6 Visão Geral
CMMI-SE/SW, v1.1
Metas Específicas e Genéricas
Todos os títulos e declarações das metas específicas e genéricas

aparecem em negrito. O número da meta (por exemplo, SG 1 para a
meta específica 1 ou GG 2 para a meta genérica 2) aparece à
esquerda do título da meta. (Veja a seção sobre o Esquema de
Numeração abaixo). A declaração da meta aparece em itálico e negrito
abaixo do título da meta em uma caixa cinza. O título da meta é uma
forma abreviada da declaração da meta que é utilizado para referência.
Os títulos das metas não são utilizados em avaliações ou
classificações de qualquer natureza. Somente as declarações de metas
foram projetadas para serem utilizadas com objetivos de melhoria de
processos e avaliações. [FM108.HDA105.HDB101.T101]
Práticas Específicas e Genéricas
Todos os títulos e declarações das práticas específicas e genéricas

aparecem em negrito e estão recuadas em relação à margem
esquerda. O número da prática aparece à esquerda do título da prática.
(Veja a seção sobre Esquema de Numeração abaixo). As declarações
das práticas aparecem em itálico e negrito dentro de uma caixa cinza
abaixo do título da prática. O título da prática não é utilizado para
avaliações ou classificações de qualquer natureza. A declaração da
prática foi projetada para ser utilizada com objetivos de melhoria de
processos e avaliações. [FM108.HDA105.HDB102.T101]
Referências
Todas as referências a componentes do modelo são identificáveis nos

modelos CMMI porque sempre aparecem em itálico e sempre iniciam
com a frase “Veja em”. [FM108.HDA105.HDB103.T101]
Notas Introdutórias, Produtos de Trabalho Típicos e Sub-práticas
Estes títulos indicam a localização de notas introdutórias, produtos de

trabalho típicos e sub-práticas dentro de uma área de processo.
[FM108.HDA105.HDB104.T101]
Exemplos
Dentro das áreas de processos, todos os exemplos aparecem em

caixas e estão formatados com uma fonte menor e mais estreita que a
maioria dos outros elementos do modelo. [FM108.HDA105.HDB109.T101]
Visão Geral 7
CMMI-SE/SW, v1.1
Elaborações das Práticas Genéricas
Após as práticas específicas, aparecem os títulos e declarações das

práticas genéricas que se aplicam à área de processo. Após cada
declaração de prática genérica, pode aparecer uma elaboração em
texto comum com o título “Elaboração”. A elaboração oferece
informações sobre como a prática genérica deverá ser interpretada
para a área de processo. Se não existir uma elaboração, a aplicação
da prática genérica é considerada óbvia. [FM108.HDA105.HDB105.T101]
Definições Ampliadas de Disciplinas
Os componentes do modelo que oferecem instruções sobre como

interpretar as informações do modelo para disciplinas específicas (por
exemplo, IPPD, engenharia de sistemas ou engenharia de software)
são chamados de “definições ampliadas de disciplinas”. Definições
ampliadas de disciplinas são adicionadas a outros componentes do
modelo onde sejam necessárias. Estas são fáceis de serem localizadas
porque aparecem no lado direito da página e têm um título indicando a
disciplina que tratam (por exemplo, “Para Engenharia de Software”).
[FM108.HDA105.HDB106.T101]
Esquema de Numeração
Na representação em estágios, as metas específicas e genéricas são

numeradas seqüencialmente. Cada meta específica tem um número
começando com SG, do inglês Specific Goal (SG 1, por exemplo).
Cada meta genérica tem um número começando com GG, do inglês
Generic Goal (GG 2, por exemplo). [FM108.HDA105.HDB107.T111]
Práticas específicas começam com SP, do inglês Specific Practice,

seguido por um número no formato x.y. O x é o número da meta
específica à qual a prática corresponde e y é o número de seqüência
da prática. Por exemplo, na área de processo de Gerenciamento de
Requisitos, a primeira prática específica associada com a meta
específica 1 está numerada como SP 1.1 e a segunda como SP 1.2.
[FM108.HDA105.HDB107.T112]
As práticas genéricas estão numeradas de forma semelhante,

começando com GP, do inglês Generic Practice, seguido por um
número no formato x.y, onde x é o número da meta genérica à qual a
prática corresponde e y é o número de seqüência da prática. Um
segundo número é utilizado para as práticas genéricas, indicando o
número de seqüência da prática dentro de uma das quatro categorias
de características comuns à qual ela pertence. Por exemplo, a primeira
prática genérica associada com GG 2 é numerada como GP 2.1 e CO
1. O número CO 1 indica que a prática genérica é a primeira prática
genérica organizada dentro da característica comum Compromisso.
[FM108.HDA105.HDB107.T113]
8 Visão Geral
CMMI-SE/SW, v1.1
Veja o Capítulo 2 para obter maiores informações sobre as

características comuns. [FM108.HDA105.HDB107.T114]
Códigos de Identificação de Parágrafos
No final de um parágrafo ou grupo de parágrafos dentro do modelo,

você encontrará um conjunto único de caracteres entre colchetes (isto
é, [FM108.HDA105.HDB107.T110]). Estes conjuntos de caracteres são
chamados de “códigos de identificação de parágrafos”. Estes códigos
são únicos, mas não aparecem necessariamente em uma seqüência
numérica. Estes códigos não têm nenhum significado especial para os
usuários do modelo, mas permitem a geração de modelos CMMI
específicos a partir do banco de dados do CMMI Framework e
permitem que você identifique de forma exata um texto específico no
modelo. [FM108.HDA105.HDB108.T101]
Visão Geral 9
CMMI-SE/SW, v1.1
2 Componentes do Modelo
Você escolheu a representação em estágios. Os componentes das

representações em estágios e contínua são áreas de processos, metas
específicas, práticas específicas, metas genéricas, práticas genéricas,
produtos de trabalho típicos, sub-práticas, notas, definições ampliadas
de disciplinas, elaborações de práticas genéricas e referências.
[FM103.T102]
A representação em estágios organiza as áreas de processos em cinco

níveis de maturidade para dar suporte e guiar a melhoria dos
processos. A representação em estágios agrupa as áreas de processos
por nível de maturidade, indicando quais áreas de processos
implementar para atingir cada nível de maturidade. Os níveis de
maturidade (descritos mais tarde neste capítulo) representam um
caminho de melhoria de processos ilustrando a evolução da melhoria
para a organização toda que busca a melhoria de processos. [FM103.T104]
Em cada área de processo, as metas e práticas específicas são

listadas em primeiro lugar, seguidas pelas metas e práticas genéricas.
A representação em estágios utiliza quatro características comuns para
organizar as práticas genéricas. [FM103.T106]
Neste capítulo, descrevemos cada componente da representação em

estágios, os relacionamentos entre os componentes e os
relacionamentos entre as duas representações. Muitos dos
componentes descritos aqui também são componentes de modelos
CMMI com a representação contínua. [FM103.T108]
Visão Geral da Estrutura
Um modelo CMMI com uma representação em estágios é ilustrado na

Figura 1. [FM103.HDA101.T102]
10 Visão Geral
CMMI-SE/SW, v1.1
Níveis deLevels
Maturity Maturidade
Process
Área de Processo
Area 1 1 Process
Área de Processo
Area 2 2 Process
Área de Processo
Area n n
Specific
Metas Específicas
Goals Generic
Metas Genéricas
Goals
Características Comuns
Commitment Ability Directing Verifying da

Verificação
Compromisso Habilitação Implementação
to Perform to Perform Implementation
Implementation Implementation
Implementação
Specific
Práticas Practices
Específicas
Generic Practices
Práticas Genéricas
Figura 1: Componentes do Modelo CMMI [FM103.HDA101.T104]
Os modelos CMMI foram projetados para descrever níveis distintos de

melhorias de processos. Na representação em estágios, os níveis de
maturidade oferecem a ordem recomendada para a abordagem da
melhoria de processos em estágios. Como ilustrado na Figura 1, os
níveis de maturidade organizam as áreas de processos. Nas áreas de
processos estão as metas genéricas e específicas, bem como as
práticas genéricas e específicas. As características comuns organizam
as práticas genéricas. [FM103.HDA101.T109]
Esta representação se concentra nas melhores práticas que a sua

organização pode utilizar para melhorar os processos nas áreas de
processos que pertencem ao nível de maturidade que se deseja atingir.
Antes de começar a utilizar um modelo CMMI para melhorar processos,
você deve mapear seus processos com as áreas de processos do
CMMI. Este mapeamento permite o controle da melhoria de processos
na sua organização, ajudando-o a rastrear o nível de conformidade da
sua organização com o modelo CMMI que está sendo utilizado. Não se
pretende que cada área de processo do CMMI se relacione com
exatamente um processo da sua organização. [FM103.HDA101.T110]
Níveis de Maturidade
O nível de maturidade de uma organização é uma maneira de prever o

futuro desempenho de uma organização dentro de dada disciplina ou
conjunto de disciplinas. A experiência mostra que as organizações
funcionam melhor quando concentram seus esforços de melhoria de
processos em um número controlado de áreas de processos que
exigem um esforço cada vez mais sofisticado à medida que a
organização melhora. [FM103.HDA101.HDB101.T101]
Visão Geral 11
CMMI-SE/SW, v1.1
Um nível de maturidade é uma etapa evolucionária definida da

melhoria de processos. Cada nível de maturidade estabiliza uma parte
importante dos processos da organização. [FM103.HDA101.HDB101.T102]
Nos modelos CMMI com representação em estágios, existem cinco

níveis de maturidade, cada um representando uma camada da base da
melhoria de processos, definidos pelos números de 1 a 5:
[FM103.HDA101.HDB101.T103]
1. Inicial
2. Gerenciado
3. Definido
4. Gerenciado Quantitativamente
5. Otimizado
Detalhes dos Níveis de Maturidade
Os níveis de maturidade consistem de um conjunto pré-definido de

áreas de processos. Os níveis de maturidade são medidos pelo
atendimento de metas específicas e genéricas que se aplicam a cada
conjunto pré-definido de áreas de processos. As seções seguintes
descrevem as características de cada nível de maturidade em detalhes.
[FM103.HDA101.HDB103.T101]
Nível de Maturidade 1: Inicial
No nível de maturidade 1, os processos são informais e caóticos. A

organização normalmente não possui um ambiente estável. O sucesso
destas organizações depende da competência e heroísmo das pessoas
e não do uso de processos comprovados. Apesar deste ambiente
informal e caótico, organizações de nível 1 de maturidade muitas vezes
produzem produtos e serviços que funcionam; entretanto, elas
freqüentemente excedem o orçamento e o cronograma de seus
projetos. [FM103.HDA101.HDB104.T101]
As organizações de maturidade nível 1 são caracterizadas por uma

tendência a não cumprir compromissos, abandonar processos em
momentos de crises e não ser capazes de repetir sucessos do
passado. [FM103.HDA101.HDB104.T102]
Nível de Maturidade 2: Gerenciado
No nível de maturidade 2, uma organização atingiu todas as metas

específicas e genéricas das áreas de processos do nível 2 de
maturidade. Em outras palavras, os projetos da organização
asseguraram que os requisitos são gerenciados e que os processos
são planejados, executados, medidos e controlados. [FM103.HDA101.HDB105.T101]
12 Visão Geral
CMMI-SE/SW, v1.1
A disciplina dos processos refletida pelo nível 2 de maturidade ajuda a

assegurar que as práticas existentes são mantidas em momentos de
stress. Quando estas práticas existem, os projetos são executados e
gerenciados de acordo com seus planos documentados.
[FM103.HDA101.HDB105.T102]
No nível 2 de maturidade, os requisitos, processos, produtos de

trabalho e serviços são gerenciados. A situação dos produtos de
trabalho e a entrega dos serviços são visíveis para o gerenciamento
em pontos definidos (por exemplo, nos milestones principais e no
momento em que as principais tarefas são completadas).
[FM103.HDA101.HDB105.T103]
Compromissos são estabelecidos entre os stakeholders relevantes e

são revistos conforme necessário. Os produtos de trabalho são
revisados com os stakeholders e controlados. Os produtos de trabalho
e serviços satisfazem seus requisitos, padrões e objetivos definidos.
[FM103.HDA101.HDB105.T104]
Nível de Maturidade 3: Definido

específicas e genéricas das áreas de processos definidas para os
níveis de maturidade 2 e 3. No nível de maturidade 3, os processos são
bem caracterizados e entendidos e estão descritos em padrões,
procedimentos, ferramentas e métodos. [FM103.HDA101.HDB106.T101]
O conjunto de processos padrão da organização, que é a base para o

nível de maturidade 3, é estabelecido e melhorado ao longo do tempo.
Estes processos padrão são usados para estabelecer a consistência
em toda a organização. Os projetos estabelecem seus processos
definidos adaptando o conjunto de processos padrão da organização
de acordo com as instruções de adaptação. [FM103.HDA101.HDB106.T102]
O gerenciamento da organização estabelece os objetivos dos

processos com base no conjunto de processos padrão da organização
e assegura que estes objetivos estão sendo tratados de forma
adequada. [FM103.HDA101.HDB106.T103]
Visão Geral 13
CMMI-SE/SW, v1.1
Uma diferença crucial entre os níveis de maturidade 2 e 3 é o escopo

de padrões, descrições de processos e procedimentos. No nível de
maturidade 2, os padrões, descrições de processos e procedimentos
podem ser bastante diferentes em cada instância do processo (por
exemplo, em um projeto específico). No nível de maturidade 3, os
padrões, descrições de processos e procedimentos para um projeto
são adaptados do conjunto de processos padrão da organização para
se adequar a um projeto ou unidade organizacional específicos. O
conjunto de processos padrão da organização inclui os processos
tratados nos níveis de maturidade 2 e 3. Conseqüentemente, os
processos que são executados em toda a organização são
consistentes, exceto pelas diferenças permitidas pelas instruções de
adaptação. [FM103.HDA101.HDB106.T104]
Outra diferença crítica é que no nível de maturidade 3, os processos

são geralmente descritos mais detalhadamente e com maior rigor que
no nível de maturidade 2. No nível de maturidade 3, os processos são
gerenciados de forma mais pró-ativa, utilizando um entendimento dos
inter-relacionamentos das atividades de processos e medidas
detalhadas do processo, seus produtos de trabalho e seus serviços.
[FM103.HDA101.HDB106.T105]
Nível de Maturidade 4: Gerenciado Quantitativamente

específicas das áreas de processos atribuídas aos níveis de
maturidade 2, 3 e 4 e as metas genéricas atribuídas aos níveis de
maturidade 2 e 3. São selecionados os subprocessos que contribuem
significativamente para o desempenho geral do processo. Estes
subprocessos selecionados são controlados utilizando estatísticas e
outras técnicas quantitativas. [FM103.HDA101.HDB107.T101]
Os objetivos quantitativos para a qualidade e o desempenho dos

processos são estabelecidos e utilizados como critérios para o
gerenciamento de processos. Os objetivos quantitativos são baseados
nas necessidades dos clientes, usuários finais, da organização e dos
responsáveis pela implementação dos processos. A qualidade e o
desempenho do processo são entendidos em termos estatísticos e são
gerenciados durante toda a vida dos processos. [FM103.HDA101.HDB107.T102]
Para estes processos, são coletadas e analisadas de forma estatística,

medidas detalhadas de desempenho de processos. Causas especiais
de variações de processos2 são identificadas e, quando apropriado, as
fontes das causas especiais são corrigidas para evitar ocorrências
futuras. [FM103.HDA101.HDB107.T103]
2
Veja a definição de “causa especial de variação do processo” no Apêndice C, o glossário.
14 Visão Geral
CMMI-SE/SW, v1.1
Medidas de qualidade e desempenho de processos são incorporadas

ao repositório de medições da organização para dar suporte a futuras
decisões baseadas em fatos ocorridos. [FM103.HDA101.HDB107.T105]
Uma diferença crítica entre os níveis de maturidade 3 e 4 é a

previsibilidade do desempenho do processo. No nível de maturidade 4,
o desempenho dos processos é controlado utilizando estatística e
outras técnicas quantitativas e este é previsível de forma quantitativa.
No nível de maturidade 3, os processos são previsíveis apenas de
forma qualitativa. [FM103.HDA101.HDB107.T106]
Nível de Maturidade 5: Otimizado

específicas das áreas de processos atribuídas aos níveis de
maturidade 2, 3, 4 e 5 e as metas genéricas atribuídas aos níveis de
maturidade 2 e 3. Os processos são continuamente melhorados com
base em um entendimento quantitativo das causas comuns de
variações3 inerentes aos processos. [FM103.HDA101.HDB108.T101]
O nível de maturidade 5 se concentra no melhoramento contínuo do

desempenho de processos através de melhorias tecnológicas
incrementais e inovadoras. Os objetivos quantitativos de melhoria de
processos para a organização são estabelecidos, continuamente
revisados para refletir alterações nos objetivos do negócio e utilizados
como critérios para o gerenciamento da melhoria de processos. Os
efeitos das melhorias de processos aplicadas são medidos e avaliados
contra os objetivos quantitativos de melhoria de processos. Tanto os
processos definidos como o conjunto de processos padrão da
organização são alvos de atividades de melhoria mensuráveis.
[FM103.HDA101.HDB108.T103]
As melhorias de processos que tratam as causas comuns de variações

de processos e melhoram de forma mensurável os processos da
organização são identificadas, avaliadas e aplicadas. As melhorias são
selecionadas com base em um entendimento quantitativo de sua
contribuição esperada para que a organização atinja seus objetivos de
melhoria de processos contra o seu custo e impacto na organização. O
desempenho dos processos da organização é continuamente
melhorado. [FM103.HDA101.HDB108.T104]
3
Veja a definição de “causa comum de variação de processos” no Apêndice C, o glossário.
Visão Geral 15
CMMI-SE/SW, v1.1
Otimizar processos ágeis e inovadores depende da participação de

uma força de trabalho motivada e alinhada com os valores do negócio
e os objetivos da organização. A capacidade da organização de
responder rapidamente a mudanças e oportunidades é aumentada
através da descoberta de caminhos para a aceleração e
compartilhamento do aprendizado. A melhoria dos processos é uma
parte inerente do papel de cada um, resultando em um ciclo de
melhoramento contínuo. [FM103.HDA101.HDB108.T105]
Uma diferença crítica entre os níveis de maturidade 4 e 5 é o tipo de

variação de processos tratado. No nível de maturidade 4, os processos
tratam das causas especiais de variações de processos e da
possibilidade de previsão estatística dos resultados. Embora os
processos possam produzir resultados previsíveis, estes podem ser
insuficientes para atingir os objetivos estabelecidos. No nível de
maturidade 5, os processos tratam as causas comuns de variações de
processos e a mudança de processos (isto é, ampliar o significado do
desempenho do processo) para obter a melhoria do desempenho do
processo (enquanto mantém a previsibilidade estatística), com a
finalidade de alcançar os objetivos quantitativos estabelecidos para a
melhoria de processos. [FM103.HDA101.HDB108.T106]
Avançando Através dos Níveis de Maturidade
As organizações podem conseguir progressivas melhorias em sua

maturidade organizacional atingindo, em primeiro lugar, a estabilidade
dos projetos e continuando em direção a um nível mais avançado de
melhoria contínua de processos da organização como um todo,
utilizando dados quantitativos e qualitativos para a tomada de decisões.
[FM103.HDA101.HDB109.T101]
Uma vez que a maturidade organizacional descreve a gama de

resultados esperados que podem ser alcançados por uma organização,
ela é uma maneira de prever os resultados mais prováveis do próximo
projeto que essa organização executar. Por exemplo, no nível de
maturidade 2, a organização se elevou de um nível informal para um
nível disciplinado estabelecendo um real gerenciamento de projetos.
Conforme sua organização atinge as metas genéricas e específicas
para o conjunto de áreas de processos de um nível de maturidade,
você está aumentando a sua maturidade organizacional e colhendo os
benefícios da melhoria de processos. [FM103.HDA101.HDB109.T102]
16 Visão Geral
CMMI-SE/SW, v1.1
Saltando Níveis de Maturidade
A representação em estágios identifica os níveis de maturidade através

dos quais uma organização deverá evoluir para estabelecer uma
cultura de excelência. Já que cada nível de maturidade forma a base
necessária sobre a qual deve ser construído o próximo nível, tentar
saltar níveis de maturidade normalmente é contraprodutivo.
[FM103.HDA101.HDB110.T101]
Ao mesmo tempo, você deve reconhecer que os esforços de melhoria

de processos deverão se concentrar nas necessidades da organização
no contexto do seu ambiente de negócios e que é possível que áreas
de processos de níveis mais elevados de maturidade atendam as
necessidades atuais de uma organização ou projeto. Por exemplo,
organizações que estão tentando ir do nível de maturidade 1 para o
nível de maturidade 2 muitas vezes recebem a recomendação de
estabelecer um grupo de processos, que é tratado pela área de
processo Foco no Processo Organizacional, que está contida no nível
de maturidade 3. Embora um grupo de processo não seja
necessariamente uma característica de uma organização do nível de
maturidade 2, ele pode ser uma parte útil da caminhada da
organização para atingir o nível de maturidade 2. [FM103.HDA101.HDB110.T102]
Esta situação é algumas vezes caracterizada como “estabelecer um

grupo de engenharia de processo de maturidade nível 1 para alavancar
a organização do nível de maturidade 1 para o 2”. As atividades de
melhoria de processos do nível de maturidade 1 podem depender
principalmente do entendimento e competência dos integrantes do
grupo de processo de engenharia até que seja criada uma infra-
estrutura para dar suporte a melhorias mais disciplinadas e
disseminadas. [FM103.HDA101.HDB110.T103]
As organizações podem instituir melhorias em processos específicos a

qualquer momento, mesmo antes de estarem preparadas para avançar
para o nível de maturidade no qual aquela prática específica é
recomendada. Entretanto, as organizações deverão entender que a
estabilidade destas melhorias corre um grande risco, já que a base
para sua institucionalização bem sucedida ainda não foi completada.
Processos que não têm uma base adequada podem falhar no momento
em que mais se precisa deles: sob stress. [FM103.HDA101.HDB110.T104]
Visão Geral 17
CMMI-SE/SW, v1.1
Um processo definido característico de uma organização de nível de

maturidade 3 pode ser colocado em risco se as práticas de
gerenciamento do nível de maturidade 2 forem deficientes. Por
exemplo, o gerenciamento pode aceitar um compromisso baseado em
um cronograma mal planejado ou falhar em controlar as alterações dos
requisitos pertencentes a uma baseline. Da mesma forma, muitas
organizações coletam dados detalhados característicos do nível de
maturidade 4, somente para descobrir que esses dados não podem ser
interpretados por causa de inconsistências nos processos e nas
definições de medições. [FM103.HDA101.HDB110.T105]
Outro exemplo de utilização de processos associados com áreas de

processos de níveis mais altos de maturidade é o processo de
construção de produtos. Certamente, esperaríamos que organizações
de nível de maturidade 1 executassem análise de requisitos, design,
integração e verificação. Entretanto, estas atividades não estão
descritas até o nível de maturidade 3, onde são descritas como
processos de engenharia coerentes e bem integrados de uma
capacidade de gerenciamento do projeto, implementada de maneira
que as melhorias da engenharia não são perdidas pelo fato de haver
processos informais de gerenciamento. [FM103.HDA101.HDB110.T106]
Componentes Exigidos, Esperados e Informativos
Os componentes de um modelo CMMI são agrupados em três

categorias que refletem como serão interpretados: [FM103.HDA101.HDB111.T101]
• Exigidos: As metas específicas e as metas genéricas são

componentes exigidos do modelo. Estes componentes devem ser
atingidos pelos processos planejados e implementados por uma
organização. Os componentes exigidos são essenciais na
classificação do atendimento de uma área de processo. O
atendimento de uma meta (ou sua satisfação) é utilizado como
base nas avaliações para determinar a satisfação da área de
processo e a maturidade organizacional. Somente a declaração da
meta específica ou genérica é um componente exigido do modelo.
O título de uma meta específica ou genérica e quaisquer notas
associadas a elas são considerados apenas componentes
informativos do modelo.
• Esperados: 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. Os componentes
esperados direcionam os responsáveis pela implementação de
melhorias ou execução de avaliações. Espera-se que estejam
presentes nos processos planejados e implementados pela
organização as próprias práticas, conforme sua descrição, ou
alternativas aceitáveis, para se considerar que as metas foram
satisfeitas. Somente a declaração da prática é um componente
18 Visão Geral
CMMI-SE/SW, v1.1
esperado do modelo. O título da prática e quaisquer notas

associadas a ela são considerados componentes informativos do
modelo.
• Informativos: Sub-práticas, produtos de trabalho típicos, definições
ampliadas de disciplinas, elaborações de práticas genéricas, títulos
de metas e práticas, notas de metas e práticas e referências são
componentes informativos do modelo que auxiliam os usuários do
modelo a entender as metas e práticas e a manera 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.
O glossário de termos do CMMI não é nem um elemento exigido, nem

esperado, nem informativo dos modelos CMMI. Os termos do glossário
deverão ser interpretados dentro do contexto do componente onde
aparecerem. [FM103.HDA101.HDB111.T102]
Quando utiliza um modelo CMMI como guia, você planeja e

implementa processos que atendem os componentes exigidos e
esperados das áreas de processos. A conformidade com uma área de
processo significa que existe um processo (ou processos) associado
aos processos planejados e implementados que atende ou as práticas
genéricas e específicas da área de processo ou alternativas que clara e
inequivocamente atingem um resultado que atende a meta associada
com aquela prática específica ou genérica. [FM103.HDA101.HDB111.T103]
Componentes do Modelo
Áreas de Processos
Uma área de processo é um grupo de práticas relacionadas em uma

área que, quando executadas de forma coletiva, satisfazem um
conjunto de metas consideradas importantes para trazer uma melhoria
significativa naquela área. Todas as áreas de processos do CMMI são
as mesmas tanto na representação contínua como na em estágios. Na
representação em estágios, as áreas de processo estão organizadas
por níveis de maturidade. [FM103.HDA102.HDB101.T101]
Metas Específicas
As metas específicas se aplicam a uma área de processo e tratam de

características únicas que descrevem o que deve ser implementado
para satisfazer a área de processo. Metas específicas são
componentes exigidos do modelo e são utilizadas nas avaliações para
auxiliar a determinar se a área de processo está sendo satisfeita.
[FM103.HDA102.HDB103.T101]
Visão Geral 19
CMMI-SE/SW, v1.1
Práticas Específicas
Uma prática específica é uma atividade que é considerada importante

na satisfação de uma meta específica associada. As práticas
específicas descrevem as atividades que se espera que resultem no
atendimento de metas específicas de uma área de processo. As
práticas específicas são componentes esperados do modelo.
[FM103.HDA102.HDB104.T101]
Quatro características comuns organizam as práticas genéricas de

cada área de processo. As características comuns são componentes
de modelo que não estão classificados. Elas são somente
agrupamentos que oferecem uma maneira de apresentar as práticas
genéricas. Cada característica comum é definida por uma abreviação
como mostrado: [FM103.HDA102.HDB106.T101]
• Compromisso (CO)
• Habilitação (AB)
• Implementação (DI)
• Verificação da Implementação (VE)
Veja o Capítulo 4 para obter uma descrição detalhada das

características comuns. [FM103.HDA102.HDB106.T102]
Produtos de Trabalho Típicos
Produtos de trabalho típicos são componentes informativos do modelo

que oferecem exemplos de saídas de uma prática específica ou
genérica. Estes exemplos são chamados “produtos de trabalho típicos”
porque, muitas vezes, existem outros produtos de trabalho que são tão
eficientes quanto estes, mas que não estão listados. [FM103.HDA102.HDB113.T101]
Sub-práticas
Sub-práticas são descrições detalhadas que fornecem um

direcionamento para a interpretação de práticas específicas ou
genéricas. As sub-práticas podem ser expressas como se fossem
exigidas, mas são, na verdade, componentes informativos dos modelos
CMMI criados somente para fornecerem idéias que podem ser úteis na
melhoria dos processos. [FM103.HDA102.HDB114.T101]
20 Visão Geral
CMMI-SE/SW, v1.1
Definições Ampliadas de Disciplinas
As definições ampliadas de disciplinas são componentes informativos

do modelo que contêm informações relevantes a uma disciplina
específica e estão associados com práticas específicas. Por exemplo,
se no modelo CMMI-SE/SW você desejar encontrar uma definição
ampliada de disciplina para engenharia de software, deverá procurar no
modelo itens com o rótulo “Para Engenharia de Software”. O mesmo é
verdadeiro para as outras disciplinas. [FM103.HDA102.HDB115.T101]
Metas Genéricas
As metas genéricas são chamadas de “genéricas” porque a mesma

declaração de meta aparece em diversas áreas de processos. Na
representação em estágios, cada área de processo tem somente uma
meta genérica. A satisfação de uma meta genérica em uma área de
processo significa um controle melhorado do planejamento e
implementação de processos associados com aquela área de
processo, indicando, portanto, se estes processos parecem ser
eficientes, repetíveis e duráveis. As metas genéricas são componentes
exigidos do modelo e são utilizadas em avaliações para determinar se
uma área de processo está sendo satisfeita. (Somente o título e a
declaração da meta genérica aparecem nas áreas de processos).
[FM103.HDA102.HDB105.T101]
Veja o Capítulo 4 para obter uma descrição detalhada das metas

genéricas. [FM103.HDA102.HDB105.T102]
As práticas genéricas oferecem uma institucionalização que assegura

que os processos associados com a área de processo serão eficientes,
repetíveis e duráveis. As práticas genéricas são categorizadas pelas
metas genéricas e características comuns e são componentes
esperados em modelos CMMI. (Somente o título, a declaração e as
elaborações das práticas genéricas aparecem nas áreas de
processos). [FM103.HDA102.HDB107.T101]
Elaborações de Práticas Genéricas
As elaborações das práticas genéricas são componentes informativos

do modelo que aparecem em cada área de processo para fornecer
instruções sobre como as práticas genéricas deverão ser aplicadas de
forma única naquela área de processo. Por exemplo, quando a prática
genérica “Treinar as pessoas para executar e dar suporte ao processo
planejado, conforme necessário” é incorporada na área de processo de
Gerenciamento de Configurações, são descritos os treinamentos
específicos para a execução do gerenciamento de configurações.
[FM103.HDA102.HDB116.T101]
Visão Geral 21
CMMI-SE/SW, v1.1
Referências
As referências são componentes informativos do modelo que

direcionam o usuário para informações adicionais ou mais detalhadas
sobre áreas de processos relacionadas. As frases mais comuns que
expressam estas indicações são “Veja a área de processo de
Treinamento Organizacional para obter maiores informações sobre
como identificar as necessidades de treinamento e fornecer o
treinamento necessário” ou “Veja a área de processos de Análises de
Decisões e Resoluções para obter maiores informações sobre como
avaliar e selecionar alternativas”. Todas as referências são claramente
marcadas em itálico. [FM103.HDA102.HDB117.T102]
Comparação das Representações de Modelos
A representação contínua utiliza os níveis de capacitação para medir a

melhoria de processos, enquanto que a representação em estágios
utiliza os níveis de maturidade. As principais diferenças entre os níveis
de maturidade e os níveis de capacitação são as representações às
quais pertencem e a maneira como são aplicados: [FM103.HDA103.T101]
• Níveis de capacitação, que pertencem à representação contínua,

aplicam-se à satisfação da melhoria de processos de uma
organização para cada área de processo. Existem seis níveis de
capacitação, numerados de 0 a 5. Cada nível de capacitação
corresponde a uma meta genérica e a um conjunto de práticas
genéricas e específicas.
22 Visão Geral
CMMI-SE/SW, v1.1
Nível de Níveis de Capacitação da

Capacitaçã Representação Contínua
o
0 Incompleto
1 Executado
2 Gerenciado
3 Definido
4 Gerenciado Quantitativamente
5 Otimizado
[FM103.HDA103.T102]
• Níveis de maturidade, que pertencem à representação em estágios,

aplicam-se à maturidade geral de uma organização. Existem cinco
níveis de maturidade, numerados de 1 a 5. Cada nível de
maturidade compreende um conjunto pré-definido de áreas de
processos.
Nível de Níveis de Maturidade da

Maturidade Representação em Estágios
1 Inicial
2 Gerenciado
3 Definido
4 Gerenciado Quantitativamente
5 Otimizado
[FM103.HDA103.T104]
A representação contínua tem mais práticas específicas que a

representação em estágios porque tem dois tipos de práticas
específicas, básicas e avançadas, enquanto a representação em
estágios possui apenas um tipo de prática específica. [FM103.HDA103.T105]
Na representação contínua, as práticas genéricas existem para os

níveis de capacitação de 1 a 5, enquanto que na representação em
estágios somente aparecem práticas genéricas para os níveis de
capacitação 2 e 3; não existem práticas genéricas para os níveis de
capacitação 1, 4 e 5. [FM103.HDA103.T106]
Existe um apêndice adicional, o Apêndice F, na representação

contínua, que discute a equivalência com os estágios. A equivalência
com os estágios possibilita que resultados de avaliações utilizando a
representação contínua sejam traduzidos em níveis de maturidade.
[FM103.HDA103.T107]
Visão Geral 23
CMMI-SE/SW, v1.1
3 Terminologia do Modelo
Em qualquer modelo CMMI, a terminologia utilizada e como ela está

definida são pontos importantes para se entender o conteúdo. Embora
haja um glossário do modelo incluído no Apêndice B, alguns termos
são utilizados de maneira especial dentro dos modelos CMMI. [FM114.T101]
Evolução da Terminologia
No desenvolvimento dos modelos CMMI, a Equipe de Produto

começou com a terminologia utilizada nos modelos fonte. Entretanto,
uma vez que esta terminologia não era consistente e em alguns
momentos os termos entravam em conflito uns com os outros, a Equipe
de Produto teve que decidir quais termos deveriam ser utilizados e
quais deveriam ser abandonados. Isto foi feito durante todo o processo
de desenvolvimento do modelo através de consenso. [FM114.HDA101.T101]
Inevitavelmente, o consenso era conseguido quando os termos

selecionados eram neutros, abrangentes e flexíveis. Quando eram
identificados conflitos entre grupos de usuários potenciais (governo e
indústria) ou áreas de disciplinas (engenharia de software, engenharia
de sistemas e Desenvolvimento Integrado de Produtos e Processos
[IPPD]), era conseguido um compromisso. A equipe escolhia não
utilizar alguns termos que estavam identificados demais com um grupo
de interesse específico e procurava favorecer termos que eram aceitos
de forma mais abrangente. [FM114.HDA101.T102]
Além disso, os termos eram escolhidos para expressar conceitos de

forma consistente em todos os modelos. As definições destes termos
eram comunicadas a toda a Equipe do Produto para encorajar seu uso
consistente. Apesar destes esforços, algumas diferenças de
interpretação são inevitáveis. Você deverá sempre aplicar as instruções
contidas aqui de maneira a obter o melhor para o seu esforço de
melhoria de processos. [FM114.HDA101.T103]
24 Visão Geral
CMMI-SE/SW, v1.1
Terminologia Comum com Significados Especiais
Alguns dos termos utilizados nos modelos CMMI têm ligados a eles
significados que diferem do seu uso normal. Estes termos não estão
incluídos no glossário; explicamos o seu uso nos modelos CMMI neste
capítulo. [FM114.HDA102.T101]
Adequado, Apropriado, Conforme Necessário
Estas palavras são utilizadas de maneira que você possa interpretar as

metas e práticas à luz dos objetivos de negócios da sua organização.
Quando utilizando algum modelo CMMI, você deve interpretar as
práticas da forma que elas funcionam na sua organização. Estes
termos são usados nas metas e práticas quando certas atividades não
precisam ser executadas todo o tempo. [FM114.HDA102.HDB101.T101]
Estabelecer e Manter
Quando você estiver utilizando um modelo CMMI, encontrará metas e

práticas que incluem a frase “estabelecer e manter”. Esta frase tem um
significado além dos termos que a compõem; ela inclui também a
documentação e a utilização. Por exemplo, “Estabelecer e manter uma
política organizacional para o planejamento e execução do processo de
foco no processo organizacional” significa não somente que deve ser
formulada uma política, mas que esta também deve ser documentada e
utilizada em toda a organização. [FM114.HDA102.HDB102.T101]
Cliente
Um “cliente” é a parte (indivíduo, projeto ou organização) responsável

pelo aceite do produto ou pela autorização do pagamento. O cliente é
externo ao projeto, mas não necessariamente externo à organização. O
cliente pode ser um projeto de nível mais alto. Clientes são um
subconjunto dos stakeholders. [FM114.HDA102.HDB103.T101]
Stakeholder
Um “stakeholder” é um grupo ou um indivíduo que é afetado ou de

alguma maneira é responsável pelo resultado de alguma empreitada.
Os stakeholders podem incluir membros do projeto, fornecedores,
clientes, usuários finais e outros. [FM114.HDA102.HDB104.T101]
Visão Geral 25
CMMI-SE/SW, v1.1
Stakeholders relevantes
O termo “stakeholder relevante” é utilizado para definir um stakeholder

que é identificado como envolvido em atividades específicas e está
incluído em um plano apropriado. (Veja a prática específica Planejar o
Envolvimento dos Stakeholders na área de processo Planejamento do
Projeto e a prática genérica Envolver os Stakeholders Relevantes).
[FM114.HDA102.HDB105.T101]
Gerente
Dentro do escopo dos modelos CMMI, a palavra “gerente” refere-se a

uma pessoa que fornece as instruções e controle técnico e
administrativo àqueles que executam as tarefas e atividades dentro da
área de responsabilidade do gerente. As funções tradicionais de um
gerente incluem planejamento, organização, direção e controle do
trabalho dentro de uma área de responsabilidade. [FM114.HDA102.HDB106.T101]
Gerente do Projeto
No CMMI Product Suite, um “gerente de projeto” é a pessoa

responsável pelo planejamento, direção, controle, estrutura e
motivação do projeto. O gerente do projeto é responsável por satisfazer
o cliente. [FM114.HDA102.HDB107.T101]
Gerente Sênior
O termo “gerente sênior”, quando utilizado em um modelo CMMI,

refere-se a um papel de gerência em um nível suficientemente elevado
em uma organização, de forma que o foco principal da pessoa que está
exercendo esse papel é a sobrevivência da organização em longo
prazo e não os projetos de curto prazo ou suas preocupações e
pressões contratuais. Um gerente sênior tem a autoridade de direcionar
a alocação ou realocação de recursos para dar suporte à eficiência da
melhoria do processo organizacional. [FM114.HDA102.HDB108.T101]
Um gerente sênior pode ser qualquer gerente que satisfaça esta

descrição, incluindo a própria presidência da organização. Sinônimos
para “gerente sênior” incluem “executivo” e “gerente de alto nível”.
Entretanto, estes sinônimos não são utilizados nos modelos CMMI para
assegurar a consistência e o uso correto. [FM114.HDA102.HDB108.T102]
26 Visão Geral
CMMI-SE/SW, v1.1
Visão Compartilhada
No CMMI Product Suite, uma “visão compartilhada” é um entendimento

comum de princípios básicos, incluindo a missão, objetivos,
comportamento esperado, valores e resultados finais, que são
desenvolvidos e utilizados por um grupo, como uma organização, um
projeto ou uma equipe. Criar uma visão compartilhada requer que
todas as pessoas do grupo tenham a oportunidade de se expressar e
serem ouvidas sobre o que realmente lhes afeta. [FM114.HDA102.HDB109.T101]
Organização
Uma organização é normalmente uma estrutura administrativa na qual

pessoas gerenciam coletivamente um ou mais projetos como um todo e
cujos projetos compartilham um gerente sênior e operam sob as
mesmas políticas. Entretanto, a palavra “organização”, como é utilizada
nos modelos CMMI, pode ser aplicada a uma única pessoa que
executa uma função em uma pequena organização que, em uma
grande organização, poderia ser exercida por um grupo de pessoas.
Veja a definição de “unidade organizacional” no Apêndice B, o
glossário. [FM114.HDA102.HDB110.T101]
Empreendimento
Quando os modelos CMMI citam uma “empreendimento”, eles se

referem a uma entidade maior que nem sempre é alcançada pela
palavra “organização”. As empresas podem consistir de diversas
organização em diferentes localizações com diferentes clientes. A
palavra “empreendimento” se refere a uma composição de empresas.
[FM114.HDA102.HDB111.T101]
Desenvolvimento
A palavra “desenvolvimento”, quando utilizada no CMMI Product Suite,

implica não somente nas atividades de desenvolvimento, mas também
nas atividades de manutenção. Os projetos que se beneficiam das
melhores práticas do CMMI podem se concentrar em manutenção,
desenvolvimento ou ambos. [FM114.HDA102.HDB112.T101]
Disciplina
A palavra “disciplina”, quando utilizada no CMMI Product Suite, refere-

se a áreas de conhecimento disponíveis para seleção de um modelo
CMMI (por exemplo, engenharia de sistemas). A Equipe de Produto do
CMMI prevê que outras áreas de conhecimento serão integradas no
Framework CMMI. [FM114.HDA102.HDB113.T101]
Visão Geral 27
CMMI-SE/SW, v1.1
Projeto
Nos modelos CMMI, um “projeto” é um conjunto controlado de recursos

interrelacionados que entregam um ou mais produtos a um cliente ou
usuário final. Esse conjunto de recursos tem um início e um fim
definidos e normalmente opera de acordo com um plano. Tal plano é
freqüentemente documentado e especifica o produto a ser entregue ou
implementado, os recursos e fundos a serem usados, o trabalho a ser
feito e o cronograma para se executar o trabalho. Um projeto pode ser
composto de outros projetos. [FM114.HDA102.HDB114.T101]
Produto
A palavra “produto” é utilizada no CMMI Product Suite para expressar

qualquer saída ou serviço tangível que é resultado de um processo e
que se pretende que seja entregue a um cliente ou usuário final. Um
produto é um produto de trabalho que é entregue ao cliente.
[FM114.HDA102.HDB115.T101]
Produto de Trabalho
O termo “produto de trabalho” é utilizado no CMMI Product Suite para

expressar qualquer artefato produzido por um processo. Estes artefatos
podem incluir arquivos, documentos, partes do produto, serviços,
processos, especificações e faturas. Exemplos de processos a serem
considerados como produtos de trabalho incluem um processo de
manufatura, de treinamento ou de descarte do produto. Uma diferença
chave entre um produto de trabalho e um componente do produto é
que o produto de trabalho não precisa passar por um processo de
engenharia ou ser parte do produto final. [FM114.HDA102.HDB116.T101]
Em diversos locais nos modelos CMMI, você encontrará a frase

“produtos de trabalho e serviços”. Embora a definição de produto de
trabalho inclua também os serviços, esta frase é utilizada para enfatizar
a inclusão dos serviços na discussão. [FM114.HDA102.HDB116.T102]
Componente do Produto
O termo “componente do produto” é utilizado como um termo relativo

nos modelos CMMI. No CMMI, os componentes do produto são
componentes de um nível inferior ao produto; os componentes do
produtos são integrados para “construir” o produto. Podem existir
diversos níveis de componentes de produtos. Um componente de
produto é qualquer produto de trabalho que deva passar por um
processo de engenharia (deva ter requisitos definidos e um design
desenvolvido e implementado) para atingir o uso pretendido para o
produto durante toda a sua vida. [FM114.HDA102.HDB117.T101]
28 Visão Geral
CMMI-SE/SW, v1.1
Os componentes do produto são partes do produto entregue ao cliente

e podem servir para a manufatura ou utilização do produto. O motor e o
pistão de um carro são exemplos de componentes de produto de um
carro (o produto). O processo de manufatura utilizado para fabricar o
pistão, se entregue ao cliente, é um componente do produto.
Entretanto, se o processo de manufatura é somente utilizado para
fabricar o pistão a ser entregue ao cliente, o processo de manufatura é
um produto de trabalho, não um componente do produto. O processo
de reparo usado para remover o motor do carro para reparos e o
processo utilizado para treinar o mecânico para consertar o motor são
exemplos típicos de componentes do produto, já que serão entregues
ao cliente. [FM114.HDA102.HDB117.T102]
Avaliação (Appraisal)
No CMMI Product Suite, uma “avaliação” é o exame de um ou mais

processos por uma equipe de profissionais treinados utilizando um
modelo de referência de avaliação como base para determinar os
pontos fortes e os pontos fracos de uma organização.
[FM114.HDA102.HDB118.T101]
Análise (Assessment)
No CMMI Product Suite, uma “análise” é uma avaliação que uma

organização faz para si e por si mesma com objetivos de melhoria do
processo. A palavra “análise” (assessment) também é utilizada no
CMMI Product Suite no seu sentido comum (por exemplo, análise dos
riscos). [FM114.HDA102.HDB119.T101]
Instruções para Adaptação
Adaptar um processo significa refazer, alterar ou adaptar a descrição

de um processo para um uso específico. Por exemplo, um projeto
estabelece o seu processo definido através da adaptação de um
conjunto de processos padrão da organização para satisfazer os
objetivos, restrições e ambiente do projeto. [FM114.HDA102.HDB120.T101]
As “instruções de adaptação” são utilizadas em modelos CMMI para

possibilitar que as organizações implementem processos padrão de
maneira adequada a seus projetos. O conjunto de processos padrão da
organização é descrito em um nível geral que pode não ser
diretamente útil para executar um processo. [FM114.HDA102.HDB120.T102]
Visão Geral 29
CMMI-SE/SW, v1.1
As instruções de adaptação auxiliam aqueles que vão estabelecer os

processos definidos para os projetos. As instruções de adaptação
cobrem (1) selecionar um processo padrão, (2) selecionar um modelo
de ciclo de vida aprovado e (3) adaptar o processo padrão selecionado
e o modelo de ciclo de vida para que se encaixem nas necessidades
do projeto. As instruções de adaptação descrevem o que pode e o que
não pode ser modificado e identifica os componentes do processo que
são candidatos a serem modificados. [FM114.HDA102.HDB120.T103]
Verificação
Embora “verificação” e “validação” pareçam, a primeira vista, muito

semelhantes nos modelos CMMI, com um olhar mais atento você
poderá perceber que elas tratam de assuntos diferentes. A verificação
confirma que os produtos de trabalho refletem de forma apropriada os
requisitos que foram especificados. Em outras palavras, a verificação
assegura que “você construiu certo”. [FM114.HDA102.HDB121.T101]
Validação
A validação confirma que o produto, como fornecido, irá atender o seu

uso pretendido. Em outras palavras, a validação assegura que “você
construiu a coisa certa”. [FM114.HDA102.HDB122.T101]
Meta
Uma “meta” é um componente exigido do CMMI que pode ser uma

meta específica ou genérica. Quando aparecer a palavra “meta” em um
modelo CMMI, ela sempre se refere a componentes do modelo (por
exemplo, meta genérica, meta específica). (No Capítulo 2, veja as
definições de “meta específica” e “meta genérica” e descrições sobre
como estes termos são usados no CMMI Product Suite).
[FM114.HDA102.HDB123.T101]
Objetivo
Quando utilizado no CMMI Product Suite, o termo “objetivo” substitui a

palavra “meta”, da maneira como é utilizada normalmente, uma vez
que a palavra “meta” é reservada para ser utilizada ao se referir a
componentes do modelo CMMI chamados de “metas específicas” e
“metas genéricas”. [FM114.HDA102.HDB124.T101]
30 Visão Geral
CMMI-SE/SW, v1.1
Objetivos de Qualidade e Desempenho do Processo
A frase “objetivos de qualidade e desempenho do processo” cobre os

objetivos e requisitos de qualidade do produto, qualidade do serviço e
desempenho do processo. Os objetivos de desempenho do processo
incluem a qualidade do produto; entretanto, para enfatizar a
importância da qualidade do produto, a frase “objetivos de qualidade e
desempenho do processo” é utilizada no CMMI Product Suite em lugar
de apenas “objetivos de desempenho do processo”. [FM114.HDA102.HDB125.T101]
Padrão
Quando a palavra “padrão” aparece em um modelo CMMI, ela se refere

aos requisitos formais obrigatórios desenvolvidos e utilizados para
definir abordagens consistentes para o desenvolvimento (por exemplo,
padrões ISO, padrões IEEE, padrões organizacionais). Em vez de
utilizar “padrão” no seu sentido comum, escolhemos outros termos que
têm o mesmo significado (por exemplo, típicos, normais, tradicionais,
costumeiros). [FM114.HDA102.HDB126.T101]
Terminologia Específica do CMMI
Os seguintes termos foram criados para os produtos CMMI ou são

críticos para o entendimento dos produtos CMMI. [FM114.HDA103.T101]
CMMI Product Suite
O “CMMI Product Suite” é o conjunto completo de produtos

desenvolvidos ao redor do conceito do CMMI. Estes produtos incluem o
próprio framework, modelos, métodos de avaliação, materiais de
avaliação e diversos tipos de treinamento que foram produzidos a partir
do Framework CMMI. [FM114.HDA103.HDB101.T101]
Framework CMMI
O “Framework CMMI” é a estrutura básica que organiza os

componentes CMMI, incluindo os elementos comuns dos atuais
modelos CMMI, bem como regras e métodos para a geração de
modelos, seus métodos de avaliação (incluindo os artefatos
associados) e materiais de treinamento. O framework permite que
novas disciplinas sejam adicionadas ao CMMI, de maneira que estas
se integrem com as já existentes. [FM114.HDA103.HDB102.T101]
Visão Geral 31
CMMI-SE/SW, v1.1
Modelo CMMI
Uma vez que o Framework CMMI pode gerar diferentes modelos

baseados nas necessidades da organização que o utiliza, existem
diversos modelos CMMI. Conseqüentemente, a frase “modelo CMMI”
pode significar qualquer um destes conjuntos de informações. A frase
“modelos CMMI” refere-se a um, alguns ou o conjunto completo de
modelos que podem ser gerados a partir do Framework CMMI.
[FM114.HDA103.HDB103.T101]
Revisão por Pares
O termo “revisão por pares” é utilizado no CMMI Product Suite no lugar

do termo “inspeção de produtos de trabalho”. Essencialmente, estes
termos têm o mesmo significado. Uma revisão por pares é uma revisão
de produtos de trabalho executada por parceiros, durante o
desenvolvimento dos produtos de trabalho para identificar defeitos a
serem removidos. [FM114.HDA103.HDB104.T101]
Conjunto de Processos Padrão da Organização
Um “conjunto de processos padrão da organização” contém as

definições dos processos que guiam todas as atividades de uma
organização. Estas descrições de processos cobrem os elementos
fundamentais dos processos (e os seus relacionamentos uns com os
outros) que devem ser incorporados aos processos definidos que são
implementados nos projetos em toda a organização. Um processo
padrão permite atividades consistentes de desenvolvimento e
manutenção em toda a organização e é essencial para a melhoria e
estabilidade de longo prazo. [FM114.HDA103.HDB105.T101]
O conjunto de processos padrão da organização descreve os

elementos dos processos fundamentais que deverão fazer parte dos
processos definidos dos projetos. Ele também descreve os
relacionamentos (por exemplo, ordem e interfaces) entre estes
elementos de processo. [FM114.HDA103.HDB105.T102]
Processo
Um “processo”, como é utilizado no CMMI Product Suite, consiste de

atividades que podem ser reconhecidas como implementações de
práticas em um modelo CMMI. Estas atividades podem ser mapeadas
a uma ou mais práticas em áreas de processos CMMI para permitir que
um modelo seja utilizado para melhoria e avaliação de processos. (No
Capítulo 2, veja a definição de “área de processo” e uma descrição de
como este termo é utilizado no CMMI Product Suite).
[FM114.HDA103.HDB106.T101]
32 Visão Geral
CMMI-SE/SW, v1.1
Processo Gerenciado
Um “processo gerenciado” é um processo que é planejado e executado

de acordo com uma política; emprega pessoas treinadas com recursos
adequados para produzir resultados controlados; envolve os
stakeholders relevantes; é monitorado, controlado e revisado e é
avaliado com relação à aderência a sua descrição de processo.
[FM114.HDA103.HDB107.T101]
Processo Definido
Um “processo definido” é um processo gerenciado que é adaptado a

partir do conjunto de processos padrão da organização de acordo com
as instruções de adaptação da organização; tem uma descrição de
processo que é mantida atualizada e contribui com produtos de
trabalho, medidas e outras informações de melhoria de processos para
os ativos de processos organizacionais. (Nos Capítulos 2 e 4, veja as
descrições de como “processo definido” é utilizado no CMMI Product
Suite) [FM114.HDA103.HDB108.T101]
Um processo definido de um projeto fornece uma base para o

planejamento, execução e melhoria das tarefas e atividades do projeto.
Um projeto pode ter mais de um processo definido (por exemplo, um
processo definido para desenvolver o produto e outro para testá-lo).
[FM114.HDA103.HDB108.T102]
Ativos de Processos Organizacionais
Os “ativos de processos organizacionais” são artefatos que se

relacionam à descrição, implementação e melhoria de processos (por
exemplo, políticas, medições, descrições de processos e ferramentas
de suporte à implementação do processo). O termo “ativos de
processos” é utilizado para indicar que estes artefatos são
desenvolvidos ou adquiridos para atender os objetivos de negócio da
organização e representam investimentos feitos por ela, dos quais se
espera que agregem valor ao negócio, no momento ou no futuro.
[FM114.HDA103.HDB109.T101]
Os ativos de processos organizacionais que são descritos nos modelos

CMMI incluem: [FM114.HDA103.HDB109.T102]
• O conjunto de processos padrão da organização, incluindo a

arquitetura e os elementos de cada processo
• Descrições de modelos de ciclo de vida aprovados para uso
• Instruções e critérios de adaptação do conjunto de processos
padrão da organização
• O repositório de medições da organização
• A biblioteca de ativos de processos da organização
Visão Geral 33
CMMI-SE/SW, v1.1
Além disso, algumas áreas de processos mencionam mais dois ativos

de processos organizacionais: as baselines de desempenho dos
processos da organização e os modelos de desempenho dos
processos da organização. [FM114.HDA103.HDB109.T103]
Arquitetura dos Processos
A “arquitetura dos processos” descreve a ordem, interfaces,

interdependências e outros relacionamentos entre os elementos de
processo em um processo padrão. A arquitetura do processo também
descreve as interfaces, interdependências e outros relacionamentos
entre os elementos de processos e processos externos (por exemplo,
gerenciamento de contratos). [FM114.HDA103.HDB110.T101]
Ciclo de Vida do Produto
Um “ciclo de vida do produto” é o período de tempo, composto de

fases, que começa quando o produto é concebido e termina quando
este não estiver mais disponível para uso. Uma vez que uma
organização pode estar produzindo diversos produtos para diversos
clientes, uma única descrição de um ciclo de vida de produto pode não
ser adequada. Portanto, a organização pode definir um conjunto de
modelos de ciclo de vida de produto aprovados. Estes modelos são
normalmente encontrados na literatura e podem ser adaptados para o
uso em uma organização. [FM114.HDA103.HDB111.T101]
Um ciclo de vida de produto consiste das seguintes fases: (1)

concepção/visão, (2) definição da possibilidade de ser produzido, (3)
design/desenvolvimento, (4) produção e (5) descarte.
[FM114.HDA103.HDB111.T102]
Repositório de Medições da Organização
O “repositório de medições da organização” é um repositório usado

para reunir e disponibilizar dados de medições sobre processos e
produtos de trabalho, especialmente os relacionados ao conjunto de
processos padrão da organização. Este repositório contém ou faz
referência a dados reais de medições e a informações relacionadas
necessárias para o entendimento e análise dos dados de medições.
[FM114.HDA103.HDB112.T101]
Exemplos de dados de processos e produtos de trabalho incluem o

tamanho estimado de produtos de trabalho, estimativas de esforço e
custo; tamanho real de produtos de trabalho, esforço real dispendido e
custos reais; estatísticas de eficiência e cobertura de revisões por
pares e a quantidade e gravidade dos defeitos encontrados.
[FM114.HDA103.HDB112.T102]
34 Visão Geral
CMMI-SE/SW, v1.1
Biblioteca de Ativos de Processos da Organização
A “biblioteca dos ativos de processos da organização” é uma biblioteca

de informações utilizada para armazenar e disponibilizar ativos de
processos que são potencialmente úteis para quem estiver definindo,
implementando e gerenciando processos na organização. Esta
biblioteca contém ativos de processos tais como documentos,
fragmentos de documentos, auxiliares de implementação de processos
e outros artefatos. [FM114.HDA103.HDB113.T101]
Exemplos de documentações relacionadas a processos incluem

políticas, processos definidos, checklists, documentos de lições
aprendidas, templates, padrões, procedimentos, planos e materiais de
treinamento. Esta biblioteca é um recurso importante que pode ajudar a
reduzir o esforço na utilização de processos. [FM114.HDA103.HDB113.T102]
Documento
Um “documento” é uma coleção de dados, não importando o meio no

qual estes estiverem gravados, que geralmente é permanente e pode
ser lido por seres humanos ou máquinas. Assim, documentos incluem
tanto documentos em papel como documentos eletrônicos.
[FM114.HDA103.HDB114.T101]
Visão Geral 35
CMMI-SE/SW, v1.1
36 Visão Geral
CMMI-SE/SW, v1.1
4 Características Comuns, Metas Genéricas e

Visão Geral
Este capítulo discute as metas genéricas, práticas genéricas,

características comuns e institucionalização. Uma vez que você tenha
escolhido a representação em estágios, este capítulo fornece as
práticas genéricas organizadas por característica comum. As
características comuns são componentes do modelo que só pertencem
à representação em estágios. [FM122.HDA101.T101]
As metas e práticas genéricas permitem que a organização

institucionalize suas melhores práticas. Portanto, a discussão da
institucionalização também serve como um resumo das metas e
práticas genéricas. [FM122.HDA101.T102]
A organização pode conseguir melhoramentos progressivos na sua

maturidade conseguindo inicialmente estabilidade nos projetos e
continuando para um nível mais avançado, de melhoria contínua de
processos na organização, utilizando dados quantitativos e qualitativos
para a tomada de decisões. [FM122.HDA101.T103]
Características da Institucionalização
A institucionalização é um aspecto crítico da melhoria de processos e é

um conceito importante dentro de cada nível de maturidade. Quando
mencionada abaixo nas descrições de níveis de maturidade, a
institucionalização implica que o processo está embutido na maneira
como o trabalho é executado. [FM122.HDA102.T101]
Um processo gerenciado é institucionalizado fazendo-se o seguinte:

[FM122.HDA102.T102]
• Garantindo a aderência às políticas organizacionais

• Seguindo planos estabelecidos e descrições de processos
• Fornecendo recursos adequados (incluindo recursos financeiros, de
pessoal e de ferramentas)
Visão Geral 37
CMMI-SE/SW, v1.1
• Atribuindo responsabilidades e autoridade para a execução do

processo
• Treinando as pessoas para a execução e suporte ao processo
• Colocando os produtos de trabalho definidos sob os níveis
apropriados de gerenciamento de configurações
• Identificando e envolvendo os stakeholders relevantes
• Monitorando e controlando o desempenho do processo contra os
planos de desempenho do processo e tomando as ações corretivas
• Avaliando objetivamente o processo, seus produtos de trabalho e
seus serviços para identificar a aderência às descrições de
processos, objetivos e padrões e tratando as não-conformidades.
• Revisando as atividades, status e resultados do processo com a
gerência de nível mais alto e tomando as ações corretivas
Um processo definido é institucionalizado fazendo-se o seguinte:

[FM122.HDA102.T103]
• Tratando os itens que institucionalizam um processo gerenciado

• Estabelecendo a descrição do processo definido para o projeto ou
unidade organizacional
• Coletando produtos de trabalho, medidas e informações de
melhoria derivados do planejamento e execução do processo
definido
Um processo quantitativamente gerenciado é institucionalizado

fazendo-se o seguinte: [FM122.HDA102.T104]
• Tratando os itens que institucionalizam um processo definido

• Controlando o processo utilizando estatística e outras técnicas
quantitativas, de tal forma que os atributos de qualidade do
produto, do serviço e do desempenho do processo possam ser
medidos e controlados durante todo o projeto
Um processo otimizado é institucionalizado fazendo-se o seguinte:

[FM122.HDA102.T105]
• Tratando os itens que institucionalizam um processo

quantitativamente gerenciado
• Melhorando o processo com base no entendimento das causas
comuns de variação inerentes ao processo, de tal forma que o
processo se concentre em melhorar continuamente a faixa de
desempenho do processo, através de melhorias incrementais e
inovadoras
38 Visão Geral
CMMI-SE/SW, v1.1
Metas Genéricas
Na representação em estágios, cada área de processo tem somente

uma meta genérica. Uma meta genérica descreve que
institucionalização deve ser atingida para se satisfazer uma área de
processo. A meta genérica que uma área de processo contém depende
do nível de maturidade ao qual a área de processo pertence. Toda área
de processo do nível de maturidade 2 contém a seguinte meta
genérica: [FM122.HDA105.T101]
GG 2 Institucionalizar um Processo Gerenciado
O processo é institucionalizado como um processo gerenciado.
Toda área de processo no nível de maturidade 3 ou superior contém a

seguinte meta genérica: [FM122.HDA105.T102]
GG 3 Institucionalizar um Processo Definido
O processo é institucionalizado como um processo definido.
A numeração atribuída a estas metas genéricas (e também às práticas

genéricas) reflete o nível de capacitação específico ao qual elas estão
associadas na representação contínua. A mesma numeração é
utilizada na representação em estágios para manter a rastreabilidade
entre as duas representações. [FM122.HDA105.T103]
Quando um processo é institucionalizado como um processo definido,

os itens essenciais a um processo gerenciado também são tratados.
Portanto, a GG3 implica na GG2. Nas áreas de processos dos níveis
de maturidade 3 e superiores, somente a GG 3 aparece. Entretanto, as
práticas genéricas que aparecem sob a GG 2 também aparecem sob a
GG 3, bem como as práticas genéricas específicas da GG 3. Todas
estas práticas genéricas aparecem sob a GG 3 agrupadas por
características comuns. [FM122.HDA105.T104]
O conjunto de processos padrão da organização deverá cobrir

coletivamente todos os processos necessários para a organização e
projetos, incluindo aqueles tratados pelo nível de maturidade 2.
Portanto, a GG 3 não é exigida somente no nível de maturidade 2, mas
também no nível de maturidade 3 e superiores. Por exemplo, quando
você atinge o nível de maturidade 3, deve aplicar a GG 3 às áreas de
processos do nível de maturidade 2. [FM122.HDA105.T105]
Visão Geral 39
CMMI-SE/SW, v1.1
As características comuns são atributos pré-definidos que agrupam as

práticas genéricas em categorias. As características comuns são
componentes de modelo que não são avaliados de nenhuma forma.
Elas são simples agrupamentos que oferecem uma maneira de
apresentar as práticas genéricas. [FM122.HDA103.T101]
Existem quatro características comuns utilizadas nos modelos CMMI

com representação em estágios: Compromissos, Habilitações,
Implementações e Verificações da Implementação. [FM122.HDA103.T102]
Os Compromissos (CO) agrupam as práticas genéricas relacionadas à

criação de políticas e à garantia de patrocínio. [FM122.HDA103.T104]
As Habilitações (AB) agrupam as práticas genéricas relacionadas a

assegurar que o projeto e/ou organização possuem os recursos que
necessitam. [FM122.HDA103.T105]
As Implementações (DI) agrupam as práticas genéricas relacionadas

ao gerenciamento do desempenho do processo, gerenciamento da
integridade de seus produtos de trabalho e envolvimento dos
stakeholders relevantes. [FM122.HDA103.T106]
As Verificações de Implementação (VE) agrupam as práticas genéricas

relacionadas a revisões pelo nível mais alto de gerenciamento e a
avaliações objetivas de conformidade a descrições de processos,
procedimentos e padrões. [FM122.HDA103.T107]
Na seção seguinte, as práticas genéricas são listadas agrupadas por

categorias de características comuns. Esta seção também contém sub-
práticas e outros componentes informativos de modelos que ajudam a
esclarecer as declarações de práticas genéricas encontradas nas áreas
de processos. Estes detalhes das práticas genéricas não aparecem
nas áreas de processos. [FM122.HDA103.T103]
Práticas Genéricas Listadas por Características Comuns
As práticas genéricas aparecem no final de cada área de processo,

seguindo a meta genérica e agrupadas por características comuns. As
elaborações das práticas genéricas podem aparecer após as práticas
genéricas, para mostrar como as práticas genéricas deverão ser
aplicadas especificamente naquela área de processo. [FM122.HDA104.T101]
40 Visão Geral
CMMI-SE/SW, v1.1
Embora estas informações sejam aplicadas em todos os modelos

CMMI em diversas áreas de processos, o texto completo de cada
prática genérica não é repetido em todas as áreas de processos (por
exemplo, as sub-práticas e produtos de trabalho são omitidos). Em vez
disso, somente os títulos e declarações das práticas genéricas
aparecem em cada área de processo. Conforme você for aplicar as
práticas genéricas dentro de cada área de processo, veja esta seção
para obter detalhes destas práticas genéricas. [FM122.HDA104.T102]
Dentro das categorias de características comuns abaixo, você

encontrará práticas genéricas com numerações diferentes. Algumas
começam com GP 2 e outras com GP 3. As práticas genéricas que
começam com GP 2 se aplicam às áreas de processos dos níveis de
maturidade de 2 a 5. As práticas genéricas que começam com GP 3
também se aplicam a áreas de processos dos níveis de maturidade de
2 a 5. Entretanto, não se espera que elas sejam executadas antes que
a organização tenha atingido o nível de maturidade 2 e esteja
trabalhando para atingir o nível de maturidade 3 ou superior.
[FM122.HDA104.T104]
Somente as práticas genéricas que se aplicam à representação em

estágios aparecem neste capítulo. Existem outras práticas genéricas
que são utilizadas pela representação contínua. Estas práticas
genéricas estão associadas com os níveis de capacitação 1, 4 e 5 e
são encontradas no capítulo 4 da representação contínua.
[FM122.HDA104.T103]
Compromissos
GP 2.1 Estabelecer uma Política Organizacional

Estabelecer e manter uma política organizacional para o
planejamento e execução do processo.
O objetivo desta prática genérica é definir as expectativas

organizacionais para o processo e tornar visíveis estas expectativas
para aqueles da organização que serão afetados. Em geral, a gerência
sênior é responsável pelo estabelecimento e comunicação de
princípios guias, direcionamento e expectativas para a organização.
[GP103]
Nem todo o direcionamento que vem da gerência sênior deverá levar o

rótulo de “política”. A existência de um direcionamento organizacional
apropriado é a expectativa desta prática genérica, independente de
como for chamada ou qualificada. [GP103.N101]
Visão Geral 41
CMMI-SE/SW, v1.1
Habilitações
GP 2.2 Planejar o Processo

Estabelecer e manter o plano para a execução do processo.
O objetivo desta prática genérica é definir o que é necessário para

executar o processo e atingir os objetivos estabelecidos, preparar um
plano para execução do processo, preparar uma descrição para o
processo e obter um acordo sobre o plano com os stakeholders
relevantes. [GP104]
Os requisitos para os produtos de trabalho específicos do processo e

para executar o trabalho podem ser derivados de outros requisitos. No
caso de processos de um projeto, eles podem vir do processo de
gerenciamento de requisitos do projeto; no caso de um processo da
organização, eles podem vir de fontes organizacionais. [GP104.N101]
Os objetivos do processo podem ser derivados de outros planos (por

exemplo, os planos do projeto). Estão incluídos objetivos para
situações específicas, como qualidade, custo e cronograma. Por
exemplo, um objetivo poderia ser a redução do custo de execução de
um processo para esta implementação comparada com uma
implementação anterior. [GP104.N102]
Embora uma prática genérica, por definição, se aplique a todas as

áreas de processos, as implicações práticas de se aplicar uma prática
genérica varia para cada área de processo. Considere dois exemplos
que ilustram estas diferenças no que se refere ao planejamento do
processo. Inicialmente, o planejamento descrito por esta prática
genérica, conforme aplicada à área de processo de Monitoramento e
Controle do Projeto, pode ser totalmente executado pelos processos
associados com a área de processo de Planejamento do Projeto. Em
tal situação, a prática genérica não impõe outras expectativas ao
planejamento. Em segundo lugar, o planejamento descrito por esta
prática genérica, conforme aplicada à área de processo de
Planejamento do Projeto, normalmente não será tratado pelos
processos associados com outras áreas de processos do modelo.
Portanto, a prática genérica define uma expectativa de que o próprio
processo de planejamento do projeto seja planejado. É importante ficar
atento para a extensão na qual esta prática genérica pode reforçar
expectativas definidas em outras partes do modelo ou definir novas
expectativas que deverão ser tratadas. [GP104.N105]
Estabelecer um plano inclui documentá-lo e fornecer uma descrição do

processo. Manter o plano inclui mudá-lo conforme necessário, em
resposta a ações corretivas ou a alterações nos requisitos e objetivos
do processo. [GP104.N103]
42 Visão Geral
CMMI-SE/SW, v1.1
O plano para execução do processo normalmente inclui: [GP104.N106]
• Descrição do processo
• Padrões para os produtos de trabalho e serviços do processo
• Requisitos dos produtos de trabalho e serviços do processo
• Objetivos específicos para o desempenho do processo (por
exemplo, qualidade, prazo, tempo do ciclo e uso de recursos)
• Dependências entre as atividades, produtos de trabalho e serviços
do processo
• Recursos (incluindo recursos financeiros, de pessoal e de
ferramentas) necessários para a execução do processo
• Atribuição de responsabilidades e autoridade
• Treinamento necessário para execução e suporte ao processo
• Produtos de trabalho a serem colocados sob gerência de
configurações e o nível de gerência de configuração para cada item
• Requisitos de medições para fornecer um entendimento do
desempenho do processo, seus produtos de trabalho e serviços
• Envolvimento dos stakeholders identificados
• Atividades de monitoramento e controle do processo
• Atividades de avaliação objetiva do processo e dos produtos de
trabalho
• Atividades de revisão gerencial para o processo e os produtos de
trabalho
Sub-práticas
1. Obter patrocínio gerencial para a execução do processo.
[GP104.SubP101]
2. Definir e documentar a descrição do processo. [GP104.SubP102]
A descrição do processo, que inclui os padrões e

procedimentos relevantes, pode estar incluída como parte
do plano para execução do processo ou ser referenciada
por ele. [GP104.SubP102.N101]
3. Definir e documentar o plano para a execução do processo.

[GP104.SubP103]
Visão Geral 43
CMMI-SE/SW, v1.1
Este plano pode ser um documento isolado, estar

embutido em um documento mais abrangente ou estar
distribuído em diversos documentos. No caso do plano
estar distribuído em diversos documentos, assegure-se
que há um local onde se diz quem faz o quê. Os
documentos podem estar impressos ou em meio
eletrônico. [GP104.SubP103.N102]
4. Revisar o plano com os stakeholders relevantes e obter sua

concordância. [GP104.SubP104]
Isto inclui revisar se o processo planejado satisfaz as

políticas, planos, requisitos e padrões aplicáveis, para
fornecer garantias para os stakeholders relevantes.
[GP104.SubP104.N101]
5. Revisar o plano conforme necessário. [GP104.SubP105]
GP 2.3 Fornecer Recursos

Fornecer recursos adequados para executar o processo,
desenvolver os produtos de trabalho e fornecer os serviços do
processo.
O objetivo desta prática genérica é assegurar que os recursos

necessários para executar o processo, conforme definido pelo plano,
estarão disponíveis quando forem necessários. Os recursos incluem
recursos financeiros, condições físicas adequadas, pessoal treinado e
ferramentas apropriadas. [GP105]
A interpretação do termo “adequado” depende de muitos fatores e pode

mudar com o tempo. Os recursos inadequados podem ser tratados
adicionando mais recursos ou removendo requisitos, restrições e
compromissos. [GP105.N101]
GP 2.4 Atribuir Responsabilidades

Atribuir responsabilidades e autoridade para a execução do
processo, desenvolvimento dos produtos de trabalho e
fornecimento dos serviços do processo.
O objetivo desta prática genérica é assegurar que existem

responsáveis durante toda a vida do processo pela sua execução e
atendimento dos resultados específicos. As pessoas às quais forem
atribuídas responsabilidades e autoridade devem ter a autoridade
apropriada para executar as responsabilidades atribuídas. [GP106]
44 Visão Geral
CMMI-SE/SW, v1.1
A responsabilidade pode ser atribuída utilizando descrições de trabalho

detalhadas ou em documentos ativos, como o plano de execução do
processo. A atribuição dinâmica de responsabilidades é outra maneira
legítima de executar esta prática genérica, desde que a atribuição e
aceitação das responsabilidades sejam garantidas durante toda a vida
do processo. [GP106.N101]
Sub-práticas
1. Atribuir responsabilidades e autoridades gerais pela execução do
processo. [GP106.SubP101]
2. Atribuir responsabilidades pela execução de tarefas específicas do

3. Confirmar que as pessoas às quais foram atribuídas

responsabilidades e autoridades as entendem e aceitam
completamente. [GP106.SubP103]
GP 2.5 Treinar Pessoas

Treinar as pessoas na execução e suporte do processo,
conforme necessário.
O objetivo desta prática genérica é assegurar que as pessoas tenham

as habilidades e conhecimentos necessários para executar ou dar
suporte ao processo. [GP107]
O treinamento apropriado é fornecido para as pessoas que virão a

executar o trabalho. O treinamento genérico é fornecido para orientar
as pessoas que irão interagir com aqueles que executarão o trabalho.
[GP107.N101]
Exemplos de métodos de fornecimento de treinamentos incluem:

estudo individual; treinamento auto-direcionado; instrução programada
auto-definida; treinamento formal dentro do trabalho; mentoring e
treinamento formal em salas de aula. [GP107.N104]
O treinamento apóia o desempenho bem sucedido do processo

estabelecendo um entendimento comum do processo e qualificando as
habilitações e conhecimento necessários para a execução do
processo. [GP107.N103]
GP 3.1 Estabelecer um Processo Definido

Estabelecer e manter a descrição de um processo definido.
Visão Geral 45
CMMI-SE/SW, v1.1
O objetivo desta prática genérica é estabelecer e manter uma

descrição do processo que é adaptada do conjunto de processos
padrão da organização para atender às necessidades de uma instância
específica. A organização deverá ter processos padrão que cubram a
área de processo, bem como instruções para a adaptação destes
processos padrão para atender as necessidades de um projeto ou
função organizacional. Com um processo definido, a diversidade de
maneiras como estes processos são executados na organização é
reduzida e os ativos, dados e lições aprendidas do processo podem ser
compartilhados de forma eficiente. [GP114]
Veja a área de processo Definição do Processo Organizacional

(Organizational Process Definition) para obter maiores informações
sobre o conjunto de processos padrão da organização e instruções de
adaptação. [GP114.R101]
As descrições dos processos definidos fornecem a base para o

planejamento, execução e gerenciamento das atividades, produtos de
trabalho e serviços associados com o processo. [GP114.N102]
Sub-práticas
1. Selecionar, a partir do conjunto de processos padrão da
organização, aqueles processos que cobrem a área de processo e
melhor atendem as necessidades do projeto ou função
organizacional. [GP114.SubP101]
2. Estabelecer o processo definido através da adaptação dos

processos selecionados de acordo com as instruções de
adaptação da organização. [GP114.SubP102]
3. Assegurar que os objetivos dos processos da organização estão

sendo apropriadamente tratados no processo definido. [GP114.SubP103]
4. Documentar o processo definido e os registros da adaptação.

[GP114.SubP104]
5. Revisar a descrição do processo definido, conforme necessário.

[GP114.SubP106]
Implementações
GP 2.6 Gerenciar Configurações

Colocar os produtos de trabalho definidos para o processo sob
os níveis apropriados de gerenciamento de configurações.
46 Visão Geral
CMMI-SE/SW, v1.1
O objetivo desta prática genérica é estabelecer e manter a integridade

dos produtos de trabalho definidos para o processo (ou suas
descrições) durante toda a sua vida útil. [GP109]
Veja a área de processo Gerenciamento de Configurações

(Configuration Management) para obter maiores informações sobre a
colocação de produtos de trabalho sob gerenciamento de
configurações. [GP109.R101]
Os produtos de trabalho definidos são identificados especificamente no

plano de execução do processo, junto com uma especificação do nível
de gerenciamento de configurações. [GP109.N101]
Diferentes níveis de gerenciamento de configurações são apropriados

para diferentes produtos de trabalho em diferentes momentos. Para
alguns produtos de trabalho, pode ser suficiente manter um controle de
versões (isto é, a versão do produto de trabalho que está em uso em
um dado momento, passado ou presente, é conhecida e as mudanças
são incorporadas de uma maneira controlada). O controle de versões é
normalmente o único controle do dono do produto de trabalho (que
pode ser um indivíduo, um grupo ou uma equipe). [GP109.N102]
Algumas vezes, pode ser crítico que os produtos de trabalho sejam

colocados sob um gerenciamento de configurações formal ou de
“baseline”. Este tipo de gerenciamento de configurações inclui a
definição e estabelecimento de baselines em momentos pré-definidos.
Estas baselines são formalmente revisadas, é feito um acordo sobre
elas e elas servem como base para o posterior desenvolvimento dos
produtos de trabalho definidos. [GP109.N104]
São possíveis outros níveis de gerenciamento de configurações entre o

controle de versões e a gerenciamento de configurações formal. Um
produto de trabalho identificado pode estar sob diversos níveis de
gerenciamento de configurações em diferentes momentos. [GP109.N103]
GP 2.7 Identificar e Envolver os Stakeholders Relevantes

Identificar e envolver os stakeholders relevantes, conforme
planejado.
O objetivo desta prática genérica é estabelecer e manter o

envolvimento esperado dos stakeholders durante a execução do
processo. [GP124]
Envolver os stakeholders relevantes conforme descrito em um plano

apropriado para o envolvimento de stakeholders. Envolvê-los
apropriadamente em atividades tais como: [GP124.N101]
• Planejamento
Visão Geral 47
CMMI-SE/SW, v1.1
• Decisões
• Comunicações
• Coordenação
• Revisões
• Avaliações
• Definições de requisitos
• Resolução de problemas/questões
Veja a área de processo de Planejamento do Projeto (Project Planning)

para obter informações sobre o planejamento do envolvimento de
stakeholders no projeto. [GP124.N101.R101]
O objetivo do planejamento do envolvimento de stakeholders é

assegurar que as interações necessárias ao processo serão
cumpridas, enquanto não se permite que um número excessivo de
grupos ou indivíduos afetados impeça a execução do processo.
[GP124.N102]
Sub-práticas
1. Identificar stakeholders relevantes a este processo e decidir qual o
tipo de envolvimento deverá ser praticado. [GP124.SubP101]
Os stakeholders relevantes são identificados entre os

fornecedores de entradas, os usuários de saídas e os
executores das atividades dentro do processo. Uma vez
que os stakeholders relevantes sejam identificados, o nível
apropriado de seu envolvimento nas atividades do
processo é planejado. [GP124.SubP101.N101]
2. Compartilhar estar definições com os responsáveis pelo

planejamento do projeto e por outros planos, conforme apropriado.
[GP124.SubP102]
3. Envolver os stakeholders relevantes, conforme planejado.

[GP124.SubP103]
GP 2.8 Monitorar e Controlar o Processo

Monitorar e controlar o processo contra o plano de execução
do processo e tomar as ações corretivas apropriadas.
48 Visão Geral
CMMI-SE/SW, v1.1
O objetivo desta prática genérica é fazer o monitoramento e controle

diário do processo. A visibilidade apropriada do processo é mantida, de
maneira que as ações corretivas apropriadas possam ser tomadas
quando necessário. O monitoramento e controle do processo envolve a
medição de atributos apropriados do processo ou de produtos de
trabalho produzidos pelo processo. [GP110]
Veja a área de processo de Monitoramento e Controle do Projeto

(Project Monitoring and Control) para obter maiores informações sobre
o monitoramento e controle do projeto e a tomada de ações corretivas.
[GP110.R102]
Veja a área de processo de Medições e Análises (Measurement and

Analysis) para obter maiores informações sobre medições. [GP110.R101]
Sub-práticas
1. Medir o desempenho real contra o plano para a execução do
As medidas são do processo, de seus produtos de trabalho

e de seus serviços. [GP110.SubP101.N101]
2. Revisar objetivos atingidos e resultados do processo contra o

plano para a execução do processo. [GP110.SubP102]
3. Revisar atividades, status e resultados do processo com o nível de

gerência imediatamente responsável pelo processo e identificar
questões. As revisões pretendem fornecer ao nível de gerência
imediatamente responsável pelo processo a visibilidade apropriada
do processo. As revisões podem ser tanto periódicas como
motivadas por eventos. [GP110.SubP108]
4. Identificar e avaliar os efeitos de desvios significativos do plano

para a execução do processo. [GP110.SubP104]
5. Identificar problemas no plano para a execução do processo e na

própria execução do processo. [GP110.SubP105]
6. Tomar ações corretivas quando os requisitos e objetivos não

estiverem sendo satisfeitos, quando questões forem identificadas
ou quando o progresso do processo tiver uma diferença
significativa do plano para a execução do processo. [GP110.SubP106]
Existem riscos inerentes que deverão ser considerados

antes que qualquer ação corretiva seja tomada.
[GP110.SubP106.N102]
As ações corretivas podem incluir: [GP110.SubP106.N101]
• Tomar uma ação para consertar produtos de trabalho ou

serviços defeituosos
Visão Geral 49
CMMI-SE/SW, v1.1
• Modificar o plano para a execução do processo

• Ajustar recursos, incluindo pessoal, ferramentas e outros
recursos
• Negociar mudanças nos compromissos estabelecidos
• Obter mudanças nos requisitos e objetivos que têm que
ser satisfeitos
• Encerrar o esforço
7. Rastrear a ação corretiva até o encerramento. [GP110.SubP107]
GP 3.2 Coletar Informações de Melhorias

Coletar produtos de trabalho, medidas, resultados de medições
e informações de melhorias derivadas do planejamento e
execução do processo para suportar o uso futuro e a melhoria
dos processos e dos ativos de processos da organização.
O objetivo desta prática genérica é coletar informações e artefatos

derivados do planejamento e execução do processo. Esta prática
genérica é executada de forma que as informações e artefatos possam
ser incluídos nos ativos de processos organizacionais e fiquem
disponíveis para aquele que estão (ou estarão) planejando e
executando o mesmo processo ou processos semelhantes. As
informações e artefatos são armazenados no repositório de medições
da organização e na biblioteca de ativos de processos da organização.
[GP117]
Exemplos de informações relevantes incluem o esforço

dispendido para as diversas atividades, defeitos injetados ou
removidos em uma atividade específica e lições aprendidas.
[GP117.N101]
Veja a área de processo de Definição do Processo Organizacional

(Organizational Process Definition) para obter maiores informações
sobre o repositório de medições e a biblioteca de ativos de processos
da organização e maiores informações sobre os produtos de trabalho,
medidas e informações de melhorias que são incorporados nestes
ativos de processos organizacionais. [GP117.N101.R101]
Sub-práticas
1. Armazenar medidas de processos e produtos no repositório de
medições da organização. [GP117.SubP102]
50 Visão Geral
CMMI-SE/SW, v1.1
As medidas de processos e produtos são basicamente

aquelas que foram definidas no conjunto comum de
medidas para o conjunto de processos padrão da
organização. [GP117.SubP102.N101]
2. Submeter a documentação para inclusão na biblioteca de ativos de

processos da organização. [GP117.SubP103]
3. Documentar as lições aprendidas dos processos para inclusão na

biblioteca de ativos de processos da organização. [GP117.SubP104]
4. Propor melhorias nos ativos de processos organizacionais.

[GP117.SubP101]
Verificações da Implementação
GP 2.9 Avaliar Objetivamente a Aderência

Avaliar objetivamente a aderência do processo contra sua
descrição de processo, padrões e procedimentos e tratar as
não- conformidades.
O objetivo desta prática genérica é fornecer uma garantia confiável que

o processo está implementado como foi planejado e adere a sua
descrição de processo, padrões e procedimentos. Veja a definição de
“avaliar objetivamente” no Apêndice B, o glossário. [GP113]
As pessoas que não são diretamente responsáveis pelo gerenciamento

e execução das atividades do processo normalmente são as que
avaliam a aderência. Em muitos casos, a aderência é avaliada por
pessoas de dentro da organização, mas externas ao processo ou
projeto, ou por pessoas de fora da organização. Como resultado, uma
garantia confiável da aderência pode ser fornecida mesmo durante os
momentos em que o processo esteja sob pressão (por exemplo,
quando o esforço está atrasado no cronograma ou ultrapassou o
orçamento). [GP113.N101]
Veja a área de processo de Garantia da Qualidade do Processo e do

Produto (Process and Product Quality Assurance) para obter maiores
informações sobre como avaliar objetivamente a aderência.
[GP113.N101.R101]
GP 2.10 Revisar a Situação com a Gerência de Mais Alto Nível

Revisar as atividades, status e resultados do processo com a
gerência de mais alto nível e resolver questões.
Visão Geral 51
CMMI-SE/SW, v1.1
O objetivo desta prática genérica é fornecer ao nível mais alto de

gerência a visibilidade apropriada do processo. [GP112]
O nível mais alto de gerência inclui aqueles níveis de gerência da

organização acima do nível de gerência imediatamente responsável
pelo processo. Particularmente, níveis mais altos de gerência incluem a
gerência sênior. Estas revisões são para os gerentes que fornecem as
políticas e as instruções gerais para o processo, não para aqueles que
executam o monitoramento e controle diário do processo. [GP112.N102]
Diferentes gerentes têm diferentes necessidades de informações sobre

o processo. Estas revisões ajudam a assegurar que as decisões bem
informadas sobre o planejamento e execução do processo podem ser
tomadas. Portanto, estas revisões podem ocorrer periodicamente ou
motivadas por eventos. [GP112.N101]
52 Visão Geral
CMMI-SE/SW, v1.1
5 Interações do Framework
O CMMI Product Suite foi desenvolvido utilizando uma abordagem

baseada em consenso para identificar e descrever as melhores
práticas em diversas disciplinas. Iniciativas bem sucedidas de melhoria
de processos devem ser focadas nos objetivos de negócios da
organização. [FM102.T103]
Por exemplo, um objetivo de negócios comum é reduzir o tempo que se

leva para lançar um produto no mercado. O objetivo de melhoria de
processos derivado disto poderia ser melhorar os processos de
Gerenciamento do Projeto para assegurar entregas no momento
correto e seriam aqueles encontrados nas áreas de processos de
Planejamento do Projeto e Monitoramento e Controle do Projeto.
[FM102.T106]
Neste capítulo, são descritas as interações entre as áreas de

processos que o ajudam a ter uma visão do empreendimento das
melhorias de processos. As áreas de processos discutidas e ilustradas
incluem os materiais sobre IPPD que são específicos dos modelos que
incluem a disciplina de IPPD. Se você não estiver utilizando um modelo
que inclua IPPD, pode ignorar esse material específico. Sempre que
possível, foi incluída uma declaração para que você saiba quais
informações são específicas do IPPD. [FM102.T101]
Quando a área de processo de Gerenciamento Integrado de Projetos

(Integrated Project Management) é mencionada neste capítulo, ela se
refere ao IPM para o IPPD. As interações da área de processo de IPM
para IPPD com as áreas de processos de Integração de Equipes
(Integrated Teaming ) e Ambiente Organizacional para Integração
(Organizational Environment for Integration) são descritas neste
capítulo. Estas áreas de processos (IT e OEI) somente são incluídas se
você tiver escolhido o IPPD. [FM102.T102]
Quatro Categorias de Áreas de Processos do CMMI
As áreas de processos podem ser agrupadas em quatro categorias:

[FM102.HDA101.T102]
• Gerenciamento de Processos
• Gerenciamento de Projetos
Visão Geral 53
CMMI-SE/SW, v1.1
• Engenharia
• Suporte
Embora estejamos agrupando as áreas de processos desta maneira

para discutir suas interações, as áreas de processos muitas vezes
interagem e têm efeitos umas nas outras independentemente do seu
grupo definido. Por exemplo, a área de processo de Análises de
Decisões e Resoluções (Decision Analysis and Resolution) fornece
práticas específicas que tratam de avaliações formais que são
utilizadas na área de processo de Soluções Técnicas (Technical
Solution) para a seleção de uma solução técnica a partir de soluções
alternativas. Soluções Técnicas é uma área de processo de
Engenharia e Análises de Decisões e Resoluções é uma área de
processo de Suporte. [FM102.HDA101.T103]
As áreas de processos de Engenharia são escritas numa terminologia

genérica de engenharia, de forma que qualquer disciplina técnica
envolvida no processo de desenvolvimento do produto (por exemplo,
engenharia de software, engenharia mecânica) possa utilizá-las para a
melhoria de processos. As áreas de processos de Gerenciamento de
Processos, Gerenciamento de Projetos e Suporte também se aplicam a
todas estas disciplinas, bem como a outras. [FM102.HDA101.T105]
Você deve estar atento às interações que existem entre os

componentes do modelo CMMI para que possa aplicar o modelo de
uma forma mais útil e produtiva. As seguintes seções descrevem estas
interações. [FM102.HDA101.T106]
Gerenciamento de Processos
O Escopo do Gerenciamento de Processos
As áreas de processos de Gerenciamento de Processos contêm

atividades que percorrem todo o projeto, relativas à definição,
planejamento, distribuição de recursos, aplicação, implementação,
monitoramento, controle, avaliação, medição e melhoria de processos.
[FM102.HDA102.HDB101.T102]
Lembre-se de se concentrar nas informações que são relevantes para

a sua organização e que estão incluídas no modelo que você está
utilizando. [FM102.HDA102.HDB101.T103]
As áreas de processos de Gerenciamento de Processos do CMMI são:

[FM102.HDA102.HDB101.T104]
• Foco no Processo Organizacional (Organizational Process Focus)
54 Visão Geral
CMMI-SE/SW, v1.1
• Definição do Processo Organizacional (Organizational Process

Definition)
• Treinamento Organizacional (Organizational Training)
• Desempenho do Processo Organizacional (Organizational Process
Performance)
• Inovação e Desenvolvimento Organizacional (Organizational
Innovation and Deployment)
Para descrever as interações entre as áreas de processos de

Gerenciamento de Processos, é mais útil tratá-las em dois grupos de
áreas de processos: [FM102.HDA102.HDB101.T105]
• As áreas de processos básicas do Gerenciamento de Processos

são o Foco no Processo Organizacional, a Definição do Processo
Organizacional e o Treinamento Organizacional.
• As áreas de processos avançadas do Gerenciamento de Processos
são o Desempenho do Processo Organizacional e a Inovação e
Desenvolvimento Organizacional.
Áreas de Processos Básicas do Gerenciamento de Processos
As áreas de processos básicas do Gerenciamento de Processos dão à

organização uma capacidade básica de documentar e compartilhar as
melhores práticas, os ativos de processos organizacionais e o
aprendizado em toda a organização. [FM102.HDA102.HDB102.T101]
A Figura 2 oferece uma visão geral das interações entre as áreas de

processos de Gerenciamento de Processos e com outras categorias de
áreas de processos.4 [FM102.HDA102.HDB102.T102]
4
Veja o Apêndice B para uma completa lista de abreviações de áreas de processos.
Visão Geral 55
CMMI-SE/SW, v1.1
Necessidades de
Processos e objetivos
Da organização
Treinamento para grupos
Gerência De projeto e suporte em
Sênior Processos padrão e
ativos
Objetivos de OT Necessidades
Negócios da de treinamento
Organização
Processos padrão
E outros
Ativos
Áreas de processos de
Processos padrão Gerenciamento de Projetos,
E outros
ativos Suporte e Engenharia
OPF OPD
Recursos e
coordenação
Informações de melhorias
(ex., lições aprendidas, dados, artefatos)
Propostas de melhoria
De processos; participação na
definição, declaração e
Desenvolvimento de processos
Figura 2: Áreas de processos básicas do Gerenciamento de

Processos [FM102.HDA102.HDB102.T103]
Como ilustrado na Figura 2, a área de processo de Foco no Processo

Organizacional (OPF) auxilia a organização a planejar e implementar
melhorias nos processos organizacionais baseadas em um
entendimento dos atuais pontos fortes e fracos dos processos e ativos
de processos da organização. Os processos da organização
candidatos a melhorias podem ser obtidos de diversas maneiras. Estas
incluem propostas de melhorias de processos, medições dos
processos, lições aprendidas na implantação de processos e
resultados de atividades de avaliações de processos e de produtos.
[FM102.HDA102.HDB102.T104]
56 Visão Geral
CMMI-SE/SW, v1.1
A área de processo de Definição do Processo Organizacional (OPD)

estabelece e mantém o conjunto de processos padrão da organização
e outros ativos baseados nas necessidades do processo e nos
objetivos da organização. Estes outros ativos incluem descrições de
processos e elementos de processos, descrições de modelos de ciclo
de vida, instruções de adaptação de processos, documentações
relacionadas a processos e dados. Os projetos adaptam o conjunto de
processos padrão da organização para criar seus processos definidos.
Os outros ativos suportam a adaptação bem como a implementação
dos processos definidos. Experiências e produtos de trabalho da
execução destes processos definidos, incluindo dados de medições,
descrições de processos, artefatos de processos e lições aprendidas
são incorporados, conforme apropriado, ao conjunto de processos
padrão e outros ativos da organização. [FM102.HDA102.HDB102.T105]
A área de processo de Treinamento Organizacional (OT) identifica as

necessidades estratégicas de treinamento da organização, bem como
as necessidades táticas de treinamento que são comuns entre projetos
e grupos de suporte. Particularmente, o treinamento é desenvolvido ou
obtido de maneira que desenvolva as habilidades necessárias para
executar o conjunto de processos padrão da organização. Os principais
componentes do treinamento incluem um programa gerenciado de
desenvolvimento de treinamentos, planos documentados, pessoal com
o conhecimento apropriado e mecanismos para a medição da eficiência
do programa de treinamento. [FM102.HDA102.HDB102.T108]
Áreas de Processos Avançadas do Gerenciamento de Processos
As áreas de processos avançadas do Gerenciamento de Processos

dão à organização uma avançada capacidade para atingir seus
objetivos quantitativos de qualidade e desempenho do processo.
[FM102.HDA102.HDB103.T101]

processos avançadas do Gerenciamento de Processos e destas com
outras categorias de áreas de processos.5 Cada uma das áreas de
processos avançadas do Gerenciamento de Processos é fortemente
dependente da capacidade de se desenvolver e implementar
processos e ativos de suporte. As áreas de processos básicas do
Gerenciamento de Processos fornecem esta capacidade. Portanto,
você não deverá tentar atingir um nível de capacitação para uma área
de processo avançada do Gerenciamento de Processos (acima da
capacitação nível 3) antes de atingir o mesmo nível de capacitação
para todas as áreas de processos básicas do Gerenciamento de
Processos. [FM102.HDA102.HDB103.T103]
5
Veja o Apêndice B para uma completa lista de abreviações das áreas de processos.
Visão Geral 57
CMMI-SE/SW, v1.1
Dados de custo e
Benefício das
Melhorias piloto
Organização Melhorias
OID
Objetivos de qualidade e
Desempenho do processo e Objetivos de qualidade e
Medidas, baselines e modelos Desempenho do processo e Áreas de processos de
Medidas, baselines e modelos Gerenciamento de Projetos
Gerência OPP Suporte e Engenharia
Sênior Progresso em direção
A atingir objetivos
De negócios
Medidas
Comuns Dados de capacidade e
Desempenho do processo
Habilitação para desenvolver
E implementar processos
E ativos de suporte
Conjunto Básico de áreas de processos de
Gerenciamento de Processos
Figura 3: Áreas de Processos Avançadas do Gerenciamento de

Processos [FM102.HDA102.HDB103.T105]
Como ilustrado na Figura 3, a área de processo de Desempenho do

Processo Organizacional (OPP) deriva os objetivos quantitativos de
qualidade e desempenho dos processos a partir dos objetivos de
negócios da organização. A organização fornece aos projetos e grupos
de suporte medidas comuns, baselines de desempenho de processos e
modelos de desempenho de processos. Estes outros ativos
organizacionais suportam o gerenciamento quantitativo de projetos e o
gerenciamento estatístico de subprocessos críticos para os projetos e
grupos de suporte. A organização analisa os dados de desempenho do
processo coletados a partir destes processos definidos para
desenvolver um entendimento quantitativo da qualidade do produto, da
qualidade de serviços e do desempenho dos processos do conjunto de
processos padrão da organização. [FM102.HDA102.HDB103.T106]
58 Visão Geral
CMMI-SE/SW, v1.1
A área de processo de Inovação e Desenvolvimento Organizacional

(OID) seleciona e implementa as melhorias incrementais e inovadoras
propostas que melhoram a capacidade da organização em atingir seus
objetivos de qualidade e desempenho de processos. A identificação de
melhorias incrementais e inovadoras promissoras deverá envolver a
participação de uma força de trabalho consciente e alinhada com os
valores de negócios e os objetivos da organização. A seleção das
melhorias a serem implementadas se baseia em um entendimento
quantitativo dos potenciais custos e benefícios da implantação das
melhorias candidatas e da disponibilidade de recursos financeiros para
esta implantação. [FM102.HDA102.HDB103.T107]
Gerenciamento de Projetos
O Escopo do Gerenciamento de Projetos
As áreas de processos de Gerenciamento de Projetos cobrem as

atividades de gerenciamento de projetos relacionadas ao
planejamento, monitoramento e controle do projeto. [FM102.HDA103.HDB101.T107]
Lembre-se de se concentrar nas informações relevantes para sua

organização e que estiverem incluídas no modelo que você estiver
utilizando. [FM102.HDA103.HDB101.T108]
As áreas de processos de Gerenciamento de Projetos do CMMI são:

[FM102.HDA103.HDB101.T110]
• Planejamento de Projetos (Project Planning)

• Monitoramento e Controle de Projetos (Project Monitoring and
Control)
• Gerenciamento de Acordos com Fornecedores (Supplier Agreement
Management)
• Gerenciamento Integrado de Projetos para o IPPD (Integrated
Project Management for IPPD) ou Gerenciamento Integrado de
Projetos (Integrated Project Management)
• Gerenciamento de Riscos (Risk Management)
• Integração de Equipes (Integrated Teaming)
• Gerenciamento Quantitativo de Projetos (Quantitative Project
Management)
Para descrever as interações entre as áreas de processos de

Gerenciamento de Projetos, é mais útil tratá-las em dois grupos de
áreas de processos: [FM102.HDA103.HDB101.T104]
• As áreas de processos básicas de Gerenciamento de Projetos são

Planejamento do Projeto (Project Planning), Monitoramento e
Visão Geral 59
CMMI-SE/SW, v1.1
Controle do Projeto (Project Monitoring and Control) e

Gerenciamento de Acordos com Fornecedores (Supplier Agreement
Management).
• As áreas de processos avançadas de Gerenciamento de Projetos
são Gerenciamento Integrado de Projetos para o IPPD (Integrated
Project Management for IPPD), Gerenciamento de Riscos (Risk
Management), Integração de Equipes (Integrated Teaming) e
Gerenciamento Quantitativo de Projetos (Quantitative Project
Management).
Áreas de Processos Básicas do Gerenciamento de Projetos
As áreas de processos básicas do Gerenciamento de Projetos tratam

das atividades básicas relacionadas ao estabelecimento e manutenção
do plano do projeto, estabelecimento e manutenção de compromissos,
monitoramento do progresso contra o plano, tomada de ações
corretivas e gerenciamento de acordos com fornecedores.
[FM102.HDA103.HDB102.T101]

processos básicas do Gerenciamento de Projetos e com outras
categorias de áreas de processos.6 [FM102.HDA103.HDB102.T102]
Status, questões, resultados

PMC de avaliações do
processo e do produto,
Ação medidas e análises
corretiv a
O que Ação corretiva
Replanejar monitorar
Status, questões, O que construir

resultados
do progresso e
PP O que fazer
revisões de Compromissos áreas de processos de

milestones Engenharia e Suporte
Planos
Necessidades de Medições
SAM
Acordo com
fornecedor
Requisitos de componentes de produtos

questões técnicas,
Fornecedor componentes completos de produtos,
revisões e testes de aceitação
Figura 4: Áreas de Processos Básicas do Gerenciamento de

Projetos [FM102.HDA103.HDB102.T104]
6
Veja o Apêndice B para uma lista completa de abreviações das áreas de processos.
60 Visão Geral
CMMI-SE/SW, v1.1
Como ilustrado na Figura 4, a área de processo de Planejamento do

Projeto (Project Planning) engloba o desenvolvimento do plano do
projeto, o envolvimento adequado dos stakeholders, a obtenção dos
compromissos com o plano e a manutenção do plano. Quando for
utilizada a abordagem IPPD, os stakeholders representam não
somente o conhecimento técnico para o desenvolvimento do produto e
do processo, mas também as implicações de negócios do
desenvolvimento do produto e do processo. [FM102.HDA103.HDB102.T106]
O planejamento começa com os requisitos que definem o produto e o

projeto (“O que construir”, na figura). O plano do projeto cobre as
diversas atividades de gerenciamento de projeto e engenharia que
serão executadas no projeto. O projeto revisará outros planos que
afetam o projeto com diversos stakeholders relevantes e estabelecerá
compromissos com estes stakeholders relevantes com relação a suas
contribuições para o projeto. Por exemplo, estes planos cobrem
avaliações de processos, avaliações de produtos, gerenciamento de
configurações e medições e análises. [FM102.HDA103.HDB102.T107]
A área de processo de Monitoramento e Controle do Projeto (Project

Monitoring and Control) inclui as atividades de monitoramento e
tomada de ações corretivas. O plano do projeto define o nível
apropriado de monitoramento do projeto, a freqüência das revisões de
progresso e as medidas utilizadas para monitorar o progresso. O
progresso é basicamente definido pela comparação do mesmo com o
plano. Quando o status real desvia de forma significativa dos valores
esperados, são tomadas as ações corretivas apropriadas. Estas ações
podem incluir um replanejamento. [FM102.HDA103.HDB102.T108]
A área de processo de Gerenciamento de Acordos com Fornecedores

(Supplier Agreement Management) trata da necessidade do projeto de
adquirir de forma eficiente partes do trabalho que são produzidas por
fornecedores. Uma vez que um componente do produto é identificado e
o fornecedor que o produzirá é selecionado, é estabelecido e mantido
um acordo com o fornecedor que será utilizado para gerenciar a
relação com o fornecedor. O progresso e desempenho do trabalho do
fornecedor são monitorados. Revisões e testes de aceitação são
executados no componente do produto produzido pelo fornecedor.
[FM102.HDA103.HDB102.T109]
Áreas de Processos Avançadas de Gerenciamento de Projetos
As áreas avançadas de Gerenciamento de Projetos tratam de

atividades como o estabelecimento de um processo definido que é
adaptado a partir do conjunto de processos padrão da organização, a
coordenação e colaboração com os stakeholders relevantes, o
gerenciamento de riscos, a formação e sustentação de equipes
integradas para a condução de projetos e o gerenciamento quantitativo
dos processos definidos do projeto. [FM102.HDA103.HDB103.T102]
Visão Geral 61
CMMI-SE/SW, v1.1

processos avançadas do Gerenciamento de Projetos e com outras
categorias de áreas de processos. Cada área de processo avançada
de Gerenciamento de Projetos é fortemente dependente da capacidade
de se planejar, monitorar e controlar o projeto. As áreas de processos
básicas de Gerenciamento de Projetos fornecem essa capacidade.7
[FM102.HDA103.HDB103.T103]
Desempenho, obje tivos, baselines

Exposição a riscos devido a
e modelos do processo
processos instáveis
Dados e statísticos de gerenciamento QPM

Objetivos quantitativos;
Processos padrão da subprocessos para
organização e gerenciar estatisticamente Riscos identificados
ativ os de suporte
IPM RSKM
Coordenação e colaboração e ntre os
for
Lições aprendidas, stakeholders do projeto
dados de planejamento
IPPD
Taxonomia
e desempenho Estrutura de visão & parâmetros
áreas de processos de compartilhada e integração IT de riscos
de e quipes para o proje to
Gerenciamento de
Processos Gerenciamento de Status de
processos equipes integradas riscos
definidos para e xecução
do projeto dos processos de Planos de mitigação de
Processos riscos
engenharia
definidos
Coordenação, Ações corretivas
Arquitetura do projeto
compromissos, Dados de
do produto para
questões para desempenho do
estruturação de
resolver projeto
equipes
Ambiente de trabalho
integrado e práticas
pessoais
áreas de processos
áreas de processos de básicas de
Engenharia e Suporte Gerenciamento de
Projetos
Figura 5: Áreas de Processos Avançadas de Gerenciamento de

Projetos [FM102.HDA103.HDB103.T105]
Ambas as versões da área de processo de Gerenciamento Integrado

de Projetos (IPM e IPM para IPPD) estabelecem e mantêm o processo
definido do projeto que é adaptado a partir do conjunto de processos
padrão da organização. O projeto é gerenciado utilizando o processo
definido do projeto. O projeto utiliza e contribui para os ativos de
processos da organização. [FM102.HDA103.HDB103.T108]
O projeto assegura que os stakeholders relevantes associados com o

projeto coordenam seus esforços de forma pontual. Ele faz isso
providenciando o gerenciamento do envolvimento de stakeholders; a
identificação, negociação e rastreamento de dependências críticas e a
resolução de questões de coordenação dentro do projeto com os
stakeholders relevantes. [FM102.HDA103.HDB103.T110]
O parágrafo seguinte somente é aplicado para os modelos que contêm

o IPPD. [FM102.HDA103.HDB103.T120]
7
62 Visão Geral
CMMI-SE/SW, v1.1
A área de processo de Gerenciamento Integrado de Projeto para o

IPPD (Integrated Project Management for IPPD) também cria a visão
compartilhada do projeto. Esta visão compartilhada deverá alinhar
horizontal e verticalmente as visões compartilhadas da organização e
das equipes integradas, criadas nas áreas de processos de Ambiente
Organizacional para Integração (Organizational Environment for
Integration) e Integração de Equipes (Integrated Teaming),
respectivamente. Estas visões compartilhadas apóiam conjuntamente a
coordenação e a colaboração entre os stakeholders. Finalmente, a
área de processo de Gerenciamento Integrado de Projetos para o IPPD
(Integrated Project Management for IPPD) implementa uma estrutura
de equipes integradas para executar o trabalho do projeto no
desenvolvimento de um produto. Esta estrutura de equipes é
normalmente baseada na decomposição do próprio produto, de forma
semelhante à estrutura de decomposição do trabalho (work breakdown
structure). Esta atividade é cumprida em conjunto com a área de
processo de Integração de Equipes (Integrated Teaming).
[FM102.HDA103.HDB103.T111]
Embora a identificação e monitoramento de riscos sejam cobertos nas

áreas de processos de Planejamento do Projeto e Monitoramento e
Controle do Projeto, a área de processo de Gerenciamento de Riscos
(Risk Management) tem uma abordagem mais continuada e pró-ativa
para o gerenciamento de riscos, com atividades que incluem a
identificação de parâmetros de riscos, atribuição de riscos e tratamento
de riscos. [FM102.HDA103.HDB103.T112]
A área de processo de Gerenciamento Quantitativo do Projeto

(Quantitative Project Management) aplica técnicas quantitativas e
estatísticas para gerenciar o desempenho do processo e a qualidade
do produto. Os objetivos de qualidade e desempenho do processo para
o projeto são baseados naqueles que foram estabelecidos pela
organização. O processo definido do projeto compreende, em parte,
elementos de processos e subprocessos cujo desempenho pode ser
previsto. No mínimo, a variação do processo experimentada por
subprocessos críticos para o atendimento dos objetivos de qualidade e
desempenho de processos do projeto é conhecida. As ações corretivas
são tomadas quando são identificadas causas especiais de variações
de processos. Veja a definição de “causa especial de variação de
processos” no Apêndice B, o glossário. [FM102.HDA103.HDB103.T114]
O parágrafo seguinte somente é aplicado para os modelos que contêm

o IPPD. [FM102.HDA103.HDB103.T121]
Visão Geral 63
CMMI-SE/SW, v1.1
As práticas específicas da área de processo de Integração de Equipes

(Integrated Teaming) garantem a formação e sustentação de cada
equipe integrada. Parte da sustentação da equipe é o desenvolvimento
da visão compartilhada da equipe integrada, que deve se alinhar com
as visões compartilhadas do projeto e da organização, desenvolvidas
nas áreas de processos de Gerenciamento Integrado de Projetos para
o IPPD (Integrated Project Management for IPPD) e Ambiente
Integration), respectivamente. As práticas específicas das áreas de
processos de Ambiente Organizacional para Integração e Integração de
Equipes, então, configuram o ambiente para permitir o trabalho em
equipes integradas. Além disso, a área de processo de Integração de
Equipes (Integrated Teaming) interage com outros processos de
Gerenciamento de Projetos fornecendo os compromissos da equipe,
planos de trabalho e outras informações que formam a base para o
gerenciamento do projeto e o suporte ao gerenciamento de riscos.
[FM102.HDA103.HDB103.T116]
Engenharia
O Escopo da Engenharia
As áreas de processos de Engenharia cobrem as atividades de

desenvolvimento e manutenção que são compartilhadas entre as
disciplinas de engenharia (por exemplo, engenharia de sistemas e
engenharia de software). As seis áreas de processos da categoria de
Engenharia têm interelacionamentos inerentes. Estes
interelacionamentos vêm da aplicação de um processo de
desenvolvimento de produtos em lugar de processos específicos das
disciplinas, como engenharia de software ou engenharia de sistemas.
[FM102.HDA104.HDB101.T101]
Lembre-se de se concentrar nas informações relevantes para a sua

organização e que estiverem incluídas no modelo que você utiliza.
[FM102.HDA104.HDB101.T103]
As áreas de processos de Engenharia do CMMI são:

[FM102.HDA104.HDB101.T102]
• Desenvolvimento de Requisitos (Requirements Development)

• Gerenciamento de Requisitos (Requirements Management)
• Soluções Técnicas (Technical Solution)
• Integração de Produtos (Product Integration)
• Verificação (Verification)
• Validação (Validation)
64 Visão Geral
CMMI-SE/SW, v1.1
Interações Entre as Áreas de Processos de Engenharia
As áreas de processos de Engenharia integram os processos de

engenharia de software e engenharia de sistemas em um cenário de
melhoria de processos orientado ao produto. Melhorar os processos de
desenvolvimento do produto tem como alvo os objetivos essenciais de
negócios, em lugar das disciplinas específicas. Esta abordagem de
processos evita com eficiência a tendência de uma mentalidade
organizacional “canalizada”. [FM102.HDA104.HDB102.T101]
O fundamento técnico para o IPPD está baseado em uma abordagem

robusta de engenharia de sistemas que inclui o desenvolvimento no
contexto de fases da vida do produto, tais como as fornecidas nas
áreas de processos de Engenharia do modelo CMMI-SE/SW. Portanto,
a implementação do IPPD fornece uma ampliação das práticas
específicas das áreas de processos de Engenharia que enfatiza o
desenvolvimento concorrente e se concentra em todas as fases da vida
do produto. [FM102.HDA104.HDB102.T102]
As áreas de processos de Engenharia se aplicam ao desenvolvimento

de qualquer produto ou serviço no domínio do desenvolvimento da
engenharia (por exemplo, produtos de software, produtos de hardware,
serviços ou processos). [FM102.HDA104.HDB102.T103]

processos de Engenharia.8 [FM102.HDA104.HDB102.T104]
8
Visão Geral 65
CMMI-SE/SW, v1.1
Requisitos
REQM
Requisitos do produto
e dos componentes do produto
Soluções
alternativas Componentes do
produto Produto
RD TS PI Cliente
Requisitos-
Componentes do produto, produtos de trabalho,

relatórios de verificação e validação
VER VAL
Necessidades do
cliente
Figura 6: Áreas de Processos de Engenharia [FM102.HDA104.HDB102.T106]
A área de processo de Desenvolvimento de Requisitos (Requirements

Development) identifica as necessidades do cliente e traduz essas
necessidades em requisitos de produtos. Um conjunto de requisitos de
produtos é analisado para produzir uma solução conceitual de alto
nível. Este conjunto de requisitos é então alocado para um conjunto de
requisitos de componentes de produtos. Outros requisitos que ajudam
a definir o produto são derivados e alocados aos componentes do
produto. Este conjunto de requisitos de produtos e de componentes de
produtos descreve claramente o desempenho do produto,
características de design, requisitos de verificação, etc, em termos que
o desenvolvedor entende e utiliza. [FM102.HDA104.HDB102.T124]
A área de processo de Desenvolvimento de Requisitos (Requirements

Development) fornece requisitos para a área de processo de Soluções
Técnicas (Technical Solution), onde os requisitos são convertidos na
arquitetura do produto, design dos componentes do produto e no
próprio componente do produto (por exemplo, a codificação ou
fabricação). Os requisitos também são fornecidos para a área de
processo de Integração de Produtos (Product Integration) onde os
componentes de produtos são combinados e são criadas interfaces
que asseguram o atendimento dos requisitos de interface fornecidos
pelo Desenvolvimento de Requisitos. [FM102.HDA104.HDB102.T111]
66 Visão Geral
CMMI-SE/SW, v1.1
A área de processo de Gerenciamento de Requisitos mantém os

requisitos. Ela descreve as atividades para a obtenção e controle de
mudanças nos requisitos e assegura que os outros planos e dados
relevantes são mantidos atualizados. Ela garante a rastreabilidade dos
requisitos de cliente ao produto e aos componentes do produto.
[FM102.HDA104.HDB102.T112]
O Gerenciamento de Requisitos assegura que as mudanças nos

requisitos se refletirão nos planos de projetos, atividades e produtos de
trabalho. Este ciclo de mudanças pode ter impacto em todas as outras
áreas de processos de Engenharia, portanto, o gerenciamento de
requisitos é uma seqüência dinâmica e, muitas vezes, recursiva de
eventos. O estabelecimento e manutenção da área de processos de
Gerenciamento de Requisitos é fundamental para um processo de
design de engenharia controlado e disciplinado. [FM102.HDA104.HDB102.T113]
A área de processo de Soluções Técnicas desenvolve os pacotes de

dados técnicos para os componentes de produtos que serão utilizados
pela área de processo de Integração de Produtos. Espera-se que seja
feito um exame de soluções alternativas, com a intenção de selecionar
o melhor design com base nos critérios estabelecidos. Estes critérios
podem ter diferenças significativas entre os produtos, dependendo do
tipo de produto, ambiente operacional, requisitos de desempenho,
requisitos de suporte, orçamento e cronograma. A tarefa de selecionar
a solução final utiliza as práticas específicas da área de processo de
Análise de Decisões e Resoluções. [FM102.HDA104.HDB102.T114]
A área de processo de Soluções Técnicas se baseia nas práticas

específicas da área de processo de Verificação para executar a
verificação do design e revisões por pares, durante o design e antes da
construção final. [FM102.HDA104.HDB102.T115]
A área de processo de Verificação assegura que os produtos de

trabalho selecionados atendem os requisitos definidos. A área de
processo de Verificação seleciona produtos de trabalho e métodos de
verificação que serão utilizados para verificar os produtos de trabalho
contra os requisitos especificados. A verificação é normalmente um
processo incremental, começando com a verificação do componente do
produto e, geralmente, concluindo com a verificação de produtos
completamente montados. [FM102.HDA104.HDB102.T116]
A verificação também trata as revisões por pares. As revisões por pares

são um método comprovado para a remoção antecipada de defeitos e
garantem um valioso entendimento dos produtos de trabalho e
componentes de produtos que estão sendo desenvolvidos e mantidos.
[FM102.HDA104.HDB102.T117]
Visão Geral 67
CMMI-SE/SW, v1.1
A área de processo de Validação valida de forma incremental os

produtos contra as necessidades dos clientes. A validação pode ser
executada no ambiente operacional ou em um ambiente simulado de
operação. A coordenação com o cliente na validação de requisitos é um
dos elementos mais essenciais desta área de processo.
[FM102.HDA104.HDB102.T118]
O escopo da área de processo de Validação inclui a validação de

produtos, componentes de produtos, produtos de trabalho
intermediários selecionados e processos. O produto, componente de
produto, produto de trabalho intermediário selecionado ou processo
podem, muitas vezes, exigir reverificação e revalidação. As questões
descobertas durante a validação são normalmente resolvidas nas
áreas de processos de Desenvolvimento de Requisitos (Requirements
Development) e de Soluções Técnicas (Technical Solution).
[FM102.HDA104.HDB102.T119]
A área de processo de Integração de Produtos (Product Integration)

estabelece as práticas específicas esperadas associadas com a
geração da melhor seqüência possível de integração, a integração de
componentes de produtos e a entrega do produto ao cliente.
[FM102.HDA104.HDB102.T120]
A Integração de Produtos (Product Integration) utiliza as práticas

específicas de Verificação e Validação na implementação do processo
de integração do produto. A Verificação verifica as interfaces e os
requisitos de interface entre os componentes de produtos antes da
integração do produto. Este é um evento essencial no processo de
integração. Durante a integração do produto no ambiente operacional,
as práticas específicas da área de processo de Validação são
utilizadas. [FM102.HDA104.HDB102.T121]
Áreas de Processos de Engenharia e Recursão
Todas as áreas de processos de Engenharia foram escritas para

suportar recursão em qualquer ponto da arquitetura do produto. Um
exemplo é a prática específica Estabelecer Procedimentos e Critérios
de Integração de Produtos na área de processo de Integração de
Produtos (Product Integration). Para um produto com muitos
componentes de produtos complexos, esta prática específica seria
aplicada aos componentes de produtos de um produto completo
entregue ao cliente, assim como aos componentes de produtos
montados para formar o produto e assim por diante. Portanto, esta
prática específica é aplicada em quantos níveis forem necessários para
integrar todas as partes compreendidas pelo produto.
[FM102.HDA104.HDB103.T101]
68 Visão Geral
CMMI-SE/SW, v1.1
Não há uma prática específica que force a aplicação recursiva de

processos. Em vez disso, as práticas específicas são escritas de uma
maneira que se “espera” a aplicação do processo em qualquer ponto
da arquitetura do produto. Quando implementar as práticas específicas
de uma área de processo de Engenharia, você deve interpretá-las de
acordo com a maneira como elas atendem as necessidades do seu
produto. Você pode ficar mais confortável vendo esta abordagem como
se ela oferecesse um conjunto suficientemente genérico de
expectativas que podem ser aplicadas em qualquer nível de detalhe do
produto, em vez de possibilitar um comportamento recursivo de um
processo. Qualquer descrição desta abordagem é apropriada.
[FM102.HDA104.HDB103.T103]
Existe uma série de vantagens oferecidas por esta abordagem. Por

exemplo as áreas de processos de Engenharia podem ser aplicada a
um produto que tem diversas camadas de componentes de produtos e
assegurar que as práticas específicas atenderão cada camada.
Portanto, diferentes segmentos de um projeto muito grande podem ser
avaliados segundo o mesmo modelo. [FM102.HDA104.HDB103.T102]
Suporte
O Escopo do Suporte
As áreas de processos de Suporte cobrem as atividades que suportam

o desenvolvimento e manutenção de produtos. As áreas de processos
de Suporte tratam os processos que são utilizados no contexto da
execução de outros processos. Em geral, as áreas de processos de
Suporte tratam os processos que se direcionam ao projeto e podem
tratar processos que se aplicam de forma mais geral à organização.
Por exemplo, a Garantia da Qualidade do Processo e do Produto
(Process and Product Quality Assurance) pode ser utilizada em todas
as áreas de processos para oferecer uma avaliação objetiva dos
processos e produtos de trabalho descritos em todas as áreas de
processos. [FM102.HDA105.HDB101.T101]
Lembre-se de se concentrar nas informações relevantes para a sua

organização e que estão incluídas no modelo que você está utilizando.
[FM102.HDA105.HDB101.T104]
As áreas de processos de Suporte do CMMI são: [FM102.HDA105.HDB101.T106]
• Gerenciamento de Configurações (Configuration Management)

• Garantia da Qualidade do Processo e do Produto (Process and
Product Quality Assurance)
• Medições e Análises (Measurement and Analysis)
Visão Geral 69
CMMI-SE/SW, v1.1
• Ambiente Organizacional para Integração (Organizational

Environment for Integration)
• Análise de Decisões e Resoluções (Decision Analysis and
Resolution)
• Análise de Causas e Resoluções (Causal Analysis and Resolution)
Para descrever as interações entre as áreas de processos de Suporte,

é mais útil tratá-las em dois grupos de áreas de processos:
[FM102.HDA105.HDB101.T109]
• As áreas de processos básicas são Medições e Análises

(Measurement and Analysis), Garantia da Qualidade do Processo e
do Produto (Process and Product Quality Assurance) e
Gerenciamento de Configurações (Configuration Management).
• As áreas de processos avançadas de Suporte são Ambiente
Integration), Análise de Causas e Resoluções (Causal Analysis and
Resolution) e Análise de Decisões e Resoluções (Decision Analysis
and Resolution).
Áreas de Processos Básicas de Suporte
As áreas de processos básicas de Suporte tratam as funções básicas

de suporte que são utilizadas por todas as áreas de processos. Embora
todas as áreas de processos de Suporte se baseiem em outras áreas
de processos para obter entradas, as áreas de processos básicas de
Suporte providenciam as funções de suporte que são cobertas pelas
práticas genéricas. [FM102.HDA105.HDB102.T101]

processos básicas de Suporte e com todas as outras áreas de
processos.9 [FM102.HDA105.HDB102.T102]
9
70 Visão Geral
CMMI-SE/SW, v1.1
M edições,
análises Questões de
qualidade e
Todas as áreas de não-conformidades
MA processos PPQA
Necessidades
de informações
Processos e produtos de trabalho,
padrões e procedimentos
Itens de Baselines,
configuração relatórios de auditorias
solicitações de
mudanças
CM
Figura 7: Áreas de Processos Básicas de Suporte

[FM102.HDA105.HDB102.T104]
A área de processo de Medições e Análises (Measurement and

Analysis) suporta todas as áreas de processos, fornecendo práticas
específicas que direcionam os projetos e organizações no alinhamento
de necessidades e objetivos de medições com uma abordagem que
gerará resultados de medições objetivos. Estes resultados podem ser
utilizados na tomada de decisões bem informadas e tomada das ações
corretivas apropriadas. [FM102.HDA105.HDB102.T105]
A área de processo de Garantia da Qualidade do Processo e do

Produto (Process and Product Quality Assurance) suporta todas as
áreas de processos, fornecendo práticas específicas para avaliar
objetivamente os processos executados, os produtos de trabalho e os
serviços contra as descrições de processos, padrões e procedimentos
aplicáveis e assegurando que todas as questões que surgirem destas
revisões serão tratadas. A Garantia da Qualidade do Processo e do
Produto suporta a entrega de produtos e serviços de alta qualidade,
fornecendo, à equipe do projeto e a todos os níveis de gerência, a
visibilidade apropriada e o feedback dos processos e produtos de
trabalho associados durante toda a vida do projeto. [FM102.HDA105.HDB102.T106]
Visão Geral 71
CMMI-SE/SW, v1.1
A área de processo de Gerenciamento de Configurações (Configuration

Management) suporta todas as áreas de processos, estabelecendo e
mantendo a integridade dos produtos de trabalho, utilizando a
identificação de configurações, controle de configurações,
comunicação de status de configurações e auditorias de configurações.
Os produtos de trabalho colocados sob gerenciamento de
configurações incluem os produtos que são entregues ao cliente,
produtos de trabalho internos definidos, produtos adquiridos,
ferramentas e outros itens, que são utilizados na criação e descrição
destes produtos de trabalho. Exemplos de produtos de trabalho que
podem ser colocados sob gerenciamento de configurações incluem
planos, descrições de processos, requisitos, dados de design,
diagramas, especificações de produtos, código, compiladores, arquivos
de dados de produtos e publicações técnicas do produto.
[FM102.HDA105.HDB102.T107]
Áreas de Processos Avançadas de Suporte
As áreas de processos avançadas de Suporte fornecem, aos projetos e

à organização, uma avançada capacidade de suporte. Cada uma
destas áreas de processos se baseia em entradas ou práticas
específicas de outras áreas de processos. [FM102.HDA105.HDB103.T101]

processos avançadas de Suporte e com todas as outras áreas de
processos.10 [FM102.HDA105.HDB103.T102]
10
72 Visão Geral
CMMI-SE/SW, v1.1
Organização
Infra-estrutura do
IPPD
OEI
Capacidade de desenvolvimento
e implementação de processos IPPD
e de ativos de suporte
CAR
Propostas de melhoria Ambiente de trabalho
de processos necessidades integrado e
de habilidades práticas pessoais
e conhecimentos
Defeitos e para o IPPD
outros problemas
áreas de processos áreas de processos

de Gerenciamento de Gerenciamento
de Processos de Projetos
Todas as áreas de processos Questões

selecionadas
Avaliações
formais
DAR
Figura 8: Áreas de Processos Avançadas de Suporte

[FM102.HDA105.HDB103.T105]
Utilizando a área de processo de Análise de Causas e Resoluções

(Causal Analysis and Resolution), o projeto tenta entender as causas
comuns de variações inerentes aos processos e removê-las dos
processos do projeto, bem como utilizar esse conhecimento para
melhorar continuamente os processos da organização. Os processos
definidos e o conjunto de processos padrão da organização são os
alvos destas atividades de melhorias. [FM102.HDA105.HDB103.T107]
A área de processo de Análise de Decisões e Resoluções (Decision

Analysis and Resolution) suporta todas as áreas de processos,
fornecendo um processo formal de avaliação que assegura que as
alternativas são comparadas e que a melhor é selecionada para
atender as metas das áreas de processos. [FM102.HDA105.HDB103.T108]
O parágrafo seguinte somente é aplicável para os modelos que contêm

IPPD. [FM102.HDA105.HDB103.T110]
Visão Geral 73
CMMI-SE/SW, v1.1
A área de processo de Ambiente Organizacional para Integração

(Organizational Environment for Integration) estabelece a abordagem e
o ambiente para a implementação do IPPD. O ambiente é estabelecido
através da obtenção, adaptação ou desenvolvimento de processos que
facilitam o efetivo comportamento integrado das equipes, bem como a
comunicação e colaboração dos stakeholders, criando a visão
compartilhada da organização e gerenciando as pessoas para
promover o comportamento de integração. As práticas específicas da
área de processo de Ambiente Organizacional para Integração
promovem a excelência individual e da equipe enquanto possibilitam e
recompensam a integração entre todas as funções técnicas e de
negócios na execução dos projetos. [FM102.HDA105.HDB103.T111]
74 Visão Geral
CMMI-SE/SW, v1.1
Visão Geral 75
CMMI-SE/SW, v1.1
6 Utilizando os Modelos CMMI
O projeto do CMMI trabalhou para preservar os investimentos do

governo e da indústria na melhoria de processos e para melhorar e
substituir o uso de múltiplos modelos. Além de melhorar a utilização da
tecnologia do CMM para um conjunto mais amplo de disciplinas, o
conceito do CMMI determina o uso de terminologia comum,
componentes comuns, métodos de avaliação comuns e materiais de
treinamento comuns em todo o CMMI Product Suite. O objetivo do
esforço do projeto CMMI é reduzir o custo do estabelecimento e
manutenção de esforços de melhoria de processos em um
empreendimento, utilizando diversas disciplinas para produzir produtos
ou serviços. Este capítulo descreve como as organizações podem
utilizar os modelos CMMI para a melhoria de processos e para o
estabelecimento de benchmarking. [FM120.T101]
Interpretando os Modelos CMMI
Todo modelo CMMI oferece um conjunto de critérios publicamente

disponíveis que descrevem as características de organizações que
implementaram com sucesso as melhorias de processos. Estes
critérios podem ser utilizados por organizações para melhorar seus
processos de desenvolvimento, aquisição e manutenção de produtos e
serviços. Embora um novo empreendimento possa desejar estabelecer
seus processos utilizando estes conceitos, os modelos são mais
comumente de interesse de organizações que estão procurando
melhorar seus processos. [FM120.HDA101.T101]
Tais organizações devem usar o seu conhecimento profissional para

interpretar as práticas do CMMI. Embora as áreas de processos
definam comportamentos que deveriam ser exibidos em qualquer
organização, as práticas devem ser interpretadas utilizando um
conhecimento profundo do modelo CMMI que está sendo utilizado, da
organização, do ambiente de negócios e das circunstâncias específicas
envolvidas. [FM120.HDA101.T102]
As práticas do CMMI utilizam, propositadamente, frases não

específicas como “stakeholders relevantes”, “conforme apropriado” e
“conforme necessário” para acomodar as necessidades de diferentes
organizações e projetos. As necessidades específicas podem também
diferir em diversos pontos durante a vida de um projeto. [FM120.HDA101.T103]
76 Visão Geral
CMMI-SE/SW, v1.1
Para interpretar as práticas, é importante considerar o contexto geral

no qual elas serão utilizadas e determinar como as práticas satisfazem
as metas de uma área de processo dentro daquele contexto. Os
modelos CMMI não determinam quais processos são corretos para a
organização ou projeto. Em vez disso, os modelos CMMI estabelecem
os critérios mínimos necessários para planejar e implementar
processos selecionados pela organização para a melhoria baseada nos
objetivos de negócios. [FM120.HDA101.T104]
Avaliações e Benchmarking
Avaliações de processos se concentram em identificar as

oportunidades de melhorias. A organização deverá definir suas
prioridades com base nos seus objetivos de negócios e de melhoria de
processos, assim como na sua coleção de processos técnicos e de
negócios. As equipes de avaliações utilizam os modelos CMMI para
guiá-las na identificação e priorização das descobertas. Estas
descobertas, com o direcionamento oferecido pelas práticas dos
modelos CMMI, são utilizadas (por um grupo de processos, por
exemplo) para planejar melhorias para a organização. Além disso,
muitas organizações acham válido executar benchmarkings entre o seu
progresso na melhoria de processos, tanto para objetivos internos
como com clientes e fornecedores externos. [FM120.HDA102.T101]
Para as organizações que desejam avaliar diversas disciplinas, a

abordagem integrada do CMMI permite alguma economia de escala no
treinamento no modelo e na avaliação. Um método de avaliação pode
oferecer resultados isolados ou combinados para diversas disciplinas.
[FM120.HDA102.T102]
Os produtos de avaliação do CMMI também permitem a avaliação de

uma única disciplina (exceto para o Desenvolvimento Integrado de
Produtos e Processos – IPPD), como no passado. Os produtos de
avaliação do CMMI fornecem classificações consistentes para as
representações em estágios e contínua. Os estágios equivalentes
permitem que organizações que utilizam uma representação contínua
convertam suas classificações de avaliação em um nível de
maturidade. [FM120.HDA102.T105]
Os princípios de avaliação para o CMMI Product Suite permanecem os

mesmos utilizados em avaliações anteriores, utilizando muitos outros
modelos de melhoria de processos. Estes princípios são: [FM120.HDA102.T106]
• Patrocínio da gerência sênior

• Um foco nos objetivos de negócios da organização
• Confidencialidade para os entrevistados
Visão Geral 77
CMMI-SE/SW, v1.1
• Uso de um método de avaliação documentado

• Uso de um modelo de referência de processos (por exemplo, um
modelo CMMI) como base
• Uma abordagem de equipes colaborativas
• Um foco nas ações de melhorias de processos
Ao longo do tempo, um conjunto de técnicas de avaliação deve ser

desenvolvido pelos membros da comunidade de usuários do CMMI.
Novas técnicas serão desenvolvidas e as existentes melhoradas para
atender às diversas necessidades de construção de uma melhoria
interna. O projeto CMMI produziu um método para atender à
necessidade de uma ferramenta rigorosa de avaliação para
benchmarking e um conjunto de instruções para futuras avaliações de
melhoria de processos exigindo menos rigor e repetibilidade. Esta
versão mais rigorosa foi chamada de Standard CMMI Appraisal Method
for Process Improvement (SCAMPISM) ou Método Padrão de Avaliação
CMMI para Melhoria de Processos. Detalhes sobre este método estão
disponíveis no site do SEI - Software Engineering Institute em:
<http://www.sei.cmu.edu/cmmi/products/assess.html>. [FM120.HDA102.T107]
Para executar benchmarking contra outras organizações, as avaliações

devem assegurar classificações consistentes. O atendimento de um
nível específico de maturidade ou a satisfação de uma área de
processo deve significar a mesma coisa para as diferentes
organizações avaliadas. Regras para assegurar esta consistência são
fornecidas no documento mencionado acima. O SCAMPI é o único
método de avaliação inicialmente considerado adequado para ajustar
as classificações para benchmarking utilizando os modelos CMMI. O
SEI, como guardião do CMMI Product Suite, assegurará que quaisquer
comentários ou declarações públicas sobre níveis de maturidade ou
classificações resultantes de uma avaliação SCAMPI atenderão os
critérios de qualidade e consistência. [FM120.HDA102.T108]
O SCAMPI foi escrito para suportar a condução de avaliações em

conformidade com o emergente relatório técnico 15504 da International
Organization for Standardization e da International/Electrotechnical
Commission (ISO/IEC). Entretanto, é possível que uma avaliação
SCAMPI possa não estar em conformidade com o 15504. O ISO/IEC
15504 é uma colaboração internacional para desenvolver um conjunto
padrão de relatórios técnicos sobre avaliações de processos de
software, que começou em Junho de 1993 sob os auspícios do
ISO/IEC. Para os patrocinadores interessados em executar uma
avaliação em conformidade com o ISO/IEC 15504, o SCAMPI pode
suportar estas necessidades. [FM120.HDA102.T109]
S M
SCAMPI é uma marca de serviço da Carnegie Mellon University.
78 Visão Geral
CMMI-SE/SW, v1.1
Requisitos de Avaliações para o CMMI
O documento de Requisitos de Avaliações para o CMMI (Appraisal

Requirements for CMMI - ARC) contém um conjunto de critérios para o
desenvolvimento, definição e utilização de métodos de avaliação
baseados nos produtos CMMI. O ARC oferece os requisitos para
diversos tipos de métodos de avaliação com instruções para definir a
adequação de um método específico de avaliação. A adequação trata
da precisão e repetibilidade dos resultados da avaliação.
[FM120.HDA102.HDB101.T101]
O documento ARC utiliza os modelos CMMI como seus modelos de

referência associados. O Framework de Avaliação do CMM (CMM
Appraisal Framework - CAF) v1.0 foi originalmente produzido para
tratar os métodos de avaliação associados somente com o CMM para
Software. Com a incorporação dos CMMs no CMMI Framework, o ARC
foi criado para tratar estes novos modelos e o impacto resultante das
representações em estágios e contínua. [FM120.HDA102.HDB101.T102]
O documento ARC foi projetado para ajudar a melhorar a consistência

entre as diversas disciplinas e métodos de avaliação e para ajudar os
desenvolvedores, patrocinadores e usuários dos métodos de avaliação
a entender a melhor combinação associada aos diversos métodos.
Mais informações e uma matriz detalhando os requisitos do ARC estão
disponíveis no site do SEI. [FM120.HDA102.HDB101.T103]
Outros métodos de avaliação baseados no CMMI podem ser

apropriados para um dado conjunto de necessidades de
patrocinadores, incluindo auto-avaliações, avaliações iniciais, quick-
look ou mini-avaliações, avaliações incrementais e avaliações externas.
Espera-se e encoraja-se que os desenvolvedores de métodos
desenvolvam diversos métodos de avaliação para atender estas
necessidades. [FM120.HDA102.HDB101.T104]
Compatibilidade e Conformidade com o ISO/IEC 15504
Um objetivo para o qual o CMMI Product Suite foi projetado para

atender é a compatibilidade e conformidade com o ISO/IEC 15504.
Existem dois aspectos de conformidade com a versão de 1998 do
Relatório Técnico do ISO/IEC 15504: compatibilidade do modelo e
conformidade da avaliação. Quando a versão internacional completa do
padrão do ISO/IEC 15504 for publicada (prevista para ocorrer em
2003), existirão algumas mudanças para efeitos de conformidade com
o ISO/IEC 15504. [FM120.HDA102.HDB102.T101]
Visão Geral 79
CMMI-SE/SW, v1.1
Para um modelo de avaliação (por exemplo, Bootstrap, CMMI-SE/SW,

entre outros) dizer que está em conformidade com o ISO/IEC 15504
(ou seja, um modelo compatível com o ISO/IEC 15504), um documento
de “demonstração de compatibilidade” precisa mostrar como os
requisitos de compatibilidade do modelo do ISO/IEC 15504-2 foram
tratados. Estes requisitos foram construídos para fornecer uma garantia
razoável que o modelo irá funcionar apropriadamente com o associado
processo de avaliação documentado (método de avaliação).
[FM120.HDA102.HDB102.T102]
Existem também requisitos do ISO/IEC 15504 que são pertinentes à

execução real (planejamento e execução propriamente dita) de uma
avaliação. Se a condução de uma avaliação é feita de tal forma que os
requisitos do ISO/IEC 15504-3 são satisfeitos, então, o método de
avaliação é dito “em conformidade com o ISO/IEC 15504”. Um destes
requisitos é que um modelo de avaliação compatível com o ISO/IEC
15504 seja utilizado. [FM120.HDA102.HDB102.T103]
Fazendo a Transição para o CMMI
Esta seção descreve brevemente três cenários de transição. Os dois

primeiros assumem que a organização já começou seus esforços de
melhoria usando o CMM para Software ou o Electronic Industries
Alliance Interim Standard (EIA/IS) 731. O terceiro cenário assume que
a organização não utilizou um modelo de referência específico para os
esforços atuais de melhoria ou que nenhum esforço de melhoria foi
feito até o momento. [FM120.HDA103.T101]
Organizações com Experiência no CMM para Software
Muitas organizações no início da transição para o CMMI,

provavelmente, procurarão atualizar seus esforços de melhoria de
processos para incorporar as melhorias da Versão 2.0 draft C e obter a
amplitude adicional de cobertura oferecida pelos modelos CMMI.
Muitas destas organizações precisarão decidir o melhor momento da
transição, a fim de preservar os planos que prevêem, por exemplo, a
satisfação de um nível específico de maturidade. [FM120.HDA103.HDB102.T101]
As organizações que já tenham atingido um alto nível de maturidade

podem desejar fazer a transição de forma mais rápida, para se
beneficiarem da cobertura organizacional adicional descrita nos
modelos CMMI. Estas organizações encontrarão muitas coisas em
comum entre os modelos CMMI e o CMM para Software. Além disso,
há uma melhoria significativa na cobertura dos processos de
engenharia, gerenciamento de riscos e de medições e análises,
comparados com o CMM para Software. [FM120.HDA103.HDB102.T102]
80 Visão Geral
CMMI-SE/SW, v1.1
As práticas do CMM para Software nos níveis de maturidade 4 e 5

foram melhoradas com base na experiência obtida desde a publicação
do SW-CMM Versão 2 draft C. Estas práticas têm sido mais refinadas a
partir do modelo fonte, com base em estudos conduzidos pelo SEI, que
analisaram a implementação das práticas dos níveis de maturidade 4 e
5 por organizações de ponta. [FM120.HDA103.HDB102.T103]
As organizações que já começaram um esforço significativo em direção

a uma avaliação dos níveis de maturidade 2, 3 ou 4 devem pesar os
custos de fazer a transição, contra os benefícios de melhoria da
cobertura que um modelo integrado oferece. [FM120.HDA103.HDB102.T104]
As organizações podem desejar considerar a versatilidade oferecida

pelas representações contínua e em estágios no planejamento de suas
abordagens de avaliações e de melhorias de longo prazo. Se os custos
de transição total parecerem altos, uma abordagem intermediária
deveria ser incrementar seu plano atual com áreas de processos
selecionadas que seriam mais valiosas para o negócio.
[FM120.HDA103.HDB102.T105]
Por exemplo, uma empresa com diversos meses restando antes de

uma avaliação de nível de maturidade 4 poderia desejar definir
pequenas equipes para investigar o Gerenciamento de Riscos e as
Medições e Análises e, posteriormente, adicioná-los ao escopo de
avaliação para começar a transição sem afetar os esforços atuais. Esta
abordagem de melhoria de longo prazo permite que os membros da
organização tenham uma “primeira visão” das novas áreas de
processos e, portanto, obtenham um conhecimento que os ajude a
construir valor de negócio nestas duas áreas de processos, bem como
a prepará-las para futuras avaliações do CMMI. [FM120.HDA103.HDB102.T106]
Organizações com Experiência em EIA/IS 731
As organizações que montaram seus esforços de melhoria de

processos em torno de modelos de engenharia de sistemas têm
escolhas semelhantes para fazer, dependendo do seu progresso nos
esforços atuais de melhorias. [FM120.HDA103.HDB107.T101]
A evolução a partir do Electronic Industries Alliance Interim Standard

(EIA/IS) 731 envolve (1) alguma reorganização das práticas específicas
sob metas específicas e áreas de processos e (2) o adicionamento de
materiais informativos. Os passos iniciais da transição, por esse
motivo, poderiam ser comparar os esforços atuais de melhorias contra
os novos esforços esperados nos modelos CMMI. [FM120.HDA103.HDB107.T102]
Visão Geral 81
CMMI-SE/SW, v1.1
Organizações Não Familiarizadas com os Modelos do Tipo CMM
As organizações sem experiência no SW-CMM e no EIA/IS 731 podem

estar em uma entre duas categorias. Podem estar fazendo esforços de
melhoria de processos sob outras iniciativas de qualidade como a ISO
9000 ou Malcolm Baldrige, ou podem estar pensando em fazer estes
esforços por causa de evidências de valores de negócios resultantes
de tal compromisso. [FM120.HDA103.HDB104.T101]
As duas categorias de organizações descobrirão, no CMMI Product

Suite, relacionamentos semelhantes com outros esforços de qualidade.
Elas também obtém modelos de referências de práticas efetivas que
podem ser aplicadas – em toda a cadeia de valores – para melhorar a
qualidade de produtos e de seus processos associados.
[FM120.HDA103.HDB104.T102]
Estas organizações podem abordar a melhoria utilizando a

representação contínua ou em estágios. Uma abordagem é
complementar à outra. Nenhuma delas é mutuamente exclusiva, mas a
escolha irá afetar o cronograma e as necessidades de treinamento e
avaliações da organização. Veja a seção sobre Comparação de
Representação de Modelos no Capítulo 2 para obter maiores
informações sobre como selecionar uma representação do modelo
CMMI. [FM120.HDA103.HDB104.T103]
Uma vez que sua organização decida qual representação melhor se

adapta a ela, deve ser iniciado um planejamento com uma abordagem
de melhoria como o modelo Iniciar, Diagnosticar, Estabelecer, Agir,
Aprender (Initiating, Diagnosing, Establishing, Acting, Learning -
IDEALSM). (Para obter maiores informações sobre o modelo IDEAL,
veja o site <http://www.sei.cmu.edu/ideal/ideal.html>). Pesquisas têm
mostrado que o mais forte passo inicial para a melhoria de processos é
conseguir um forte patrocínio organizacional durante a fase Iniciar
antes de investir em esforços significativos de diagnóstico.
[FM120.HDA103.HDB104.T104]
Dado um patrocínio suficiente da gerência sênior, estabelecer um

grupo específico de processos tecnicamente competente para guiar os
esforços de melhoria de processos tem provado ser a melhor prática.
Para uma organização cuja missão é desenvolver sistemas com uso
intensivo de software, o grupo poderia incluir engenheiros de sistemas
e engenheiros de softwares de projetos de toda a organização e outros
membros selecionados baseados nas necessidades de negócios que
direcionam as melhorias. Por exemplo, um administrador de sistemas
pode se concentrar no suporte da tecnologia de informação, enquanto
um representante de marketing pode se concentrar em necessidades
de integração do cliente. Os dois podem ser grandes aquisições para o
grupo de processos. [FM120.HDA103.HDB104.T105]
S M
IDEAL é uma marca de serviço da Carnegie Mellon University.
82 Visão Geral
CMMI-SE/SW, v1.1
Treinamento
O treinamento é um elemento chave na capacidade das organizações

em adotar o CMMI e é, portanto, uma parte chave do conjunto de
produtos. Embora um conjunto inicial de cursos seja fornecido pelo SEI
e seus parceiros de transição, sua organização pode desejar
complementar estes cursos com uma instrução interna. Esta
abordagem permite que a organização se concentre nas áreas que lhe
trazem o maior valor de negócios. [FM120.HDA103.HDB105.T101]
O treinamento inicial está disponível para as duas representações dos

modelos CMMI. O treinamento também é fornecido para auxiliar quem
planeja direcionar as melhorias como parte de um grupo de processos
e para quem deseja se tornar um avaliador líder. [FM120.HDA103.HDB105.T102]
Perspectivas de Adaptação
Adaptar um modelo CMMI é um processo através do qual somente um

subconjunto de um modelo é utilizado para atender às necessidades de
um domínio específico de aplicação. [FM120.HDA105.T101]
Adaptar o método de avaliação do CMMI envolve a seleção de opções

para o uso em uma avaliação. Em ambos os casos, a intenção da
adaptação é auxiliar uma organização ou projeto no alinhamento dos
produtos CMMI com as necessidades e objetivos de negócios e,
portanto, se concentrar naqueles aspectos dos produtos e serviços que
são mais benéficos à organização. [FM120.HDA105.T102]
A adaptação discutida nesta seção não trata da adaptação de um

conjunto de processos padrão da organização para uso em um projeto
específico. Essa adaptação é guiada pelas instruções de adaptação
definidas pela organização. [FM120.HDA105.T103]
Adaptação do Modelo
A adaptação do modelo somente deverá ser feita sabendo que isto

pode resultar em falhas significativas em esforços para melhorar ou
avaliar a capacitação de uma organização ou projeto. [FM120.HDA104.T101]
Perspectivas de Adaptação do Modelo
A adaptação de um modelo CMMI pode ser vista a partir de duas

perspectivas: [FM120.HDA104.HDB101.T101]
• Adaptação do modelo relacionada ao uso de um modelo para

melhoria de processos
Visão Geral 83
CMMI-SE/SW, v1.1
• Adaptação do modelo relacionada ao uso de um modelo para

benchmarking
Muitas organizações utilizarão um modelo tanto para benchmarking

como para melhoria de processos. Tal adaptação é restringida pela
interseção dos critérios definidos nas duas próximas seções.
[FM120.HDA104.HDB101.T102]
Critérios de Adaptação de Modelos para Melhoria de Processos

Internos
Para melhoria de processos internos, é apropriado restringir ou

expandir o escopo dos esforços de melhoria de uma organização ou
projeto (incluindo avaliações). A adaptação pode tratar disciplinas
específicas, áreas de processos, níveis de maturidade e ou níveis de
capacitação. A adaptação de um modelo deverá se concentrar na
identificação das áreas de processos e práticas que suportam as
necessidade e objetivos de negócios de uma organização.
[FM120.HDA104.HDB102.T101]
Deve-se tomar cuidado quando se considerar excluir partes de um

modelo CMMI. Dado que um modelo CMMI tem o foco nas
características essenciais de um processo eficiente, a maioria das
áreas de processos e práticas de um modelo normalmente serão
tratadas. Na verdade, a exclusão completa de processos ou práticas
específicas fundamentais é desencorajada, uma vez que existem
dados indicando que, seguindo-se os esforços de melhoria baseados
no CMM, melhora-se significativamente o atendimento dos objetivos de
negócios. Melhorias citadas na literatura incluem o aumento da
probabilidade da organização ou projeto atingir seus objetivos de custo
e cronograma. [FM120.HDA104.HDB102.T102]
As organizações e projetos que implementam menos do que o conjunto

completo de áreas de processos, metas e práticas podem ainda obter
significativas melhorias a partir de um modelo CMMI. Entretanto, por
causa do interrelacionamento de componentes do modelo, a exclusão
de um número significativo de áreas de processos, metas ou práticas
pode diminuir os benefícios conseguidos. Além disso, o grau de
comparação de resultados de avaliação está diretamente relacionado
com a extensão em que um modelo e método de avaliação foi
adaptado. [FM120.HDA104.HDB102.T103]
84 Visão Geral
CMMI-SE/SW, v1.1
Critérios de Adaptação de Modelos para Benchmarking
O uso de modelos CMMI com objetivos de benchmarking permite

comparar resultados de avaliações de processos em uma indústria,
através de relatórios de estados de práticas, ou em um grupo de
organizações, como fornecedores potenciais. Qualquer adaptação
aplicada deve, desta forma, assegurar a consistência nas
classificações resultantes do uso de modelos em diversas avaliações.
Como resultado, a adaptação do modelo para benchmarking é
significativamente restrita, especialmente quando os níveis de
maturidade resultantes das avaliações são distribuídos publicamente
com propósitos de marketing. [FM120.HDA104.HDB103.T101]
Tenha em mente que o escopo escolhido para uma avaliação também

afeta o contexto do benchmarking. Se uma organização escolhe avaliar
somente a engenharia de software, enquanto outra escolhe avaliar a
engenharia de software e de sistemas, compará-las não será justo nem
exato. Os critérios de adaptação de modelos para benchmarking são
definidos como: [FM120.HDA104.HDB103.T102]
• As áreas de processos incluem os componentes de modelos

exigidos e esperados e, portanto, não podem ser excluídas, a não
as que estiverem fora do escopo da avaliação. Por exemplo,
quando uma organização utiliza uma representação em estágios,
as áreas de processos dos níveis de maturidade 4 e 5 podem ser
omitidas em uma avaliação com o foco no nível de maturidade 3,
enquanto todas as áreas de processos dos níveis de maturidade 2
e 3 normalmente serão selecionadas. Quando estiver utilizando
uma representação contínua, as áreas de processos fora do
escopo do perfil alvo poderão ser omitidas, mas ao fazer isso
poderão ser comprometidas as oportunidades de benchmarking
oferecidas pela equivalência com os estágios.
• As áreas de processos, em algumas ocasiões, podem ser definidas
como sendo “não aplicáveis” se a área de processo estiver, de fato,
fora do escopo de trabalho da organização. Um exemplo de área
de processo que poderia ser excluída de uma avaliação utilizando
uma representação em estágios seria o Gerenciamento de Acordos
com Fornecedores, uma área de processo que pode não ser
aplicável na ausência de fornecedores de produtos e serviços
externos à organização que sejam críticos para o esforço de
desenvolvimento. Uma classificação de nível de maturidade ainda
pode ser determinada, entretanto, aquela classificação de nível de
maturidade deve também incluir a menção à área “não aplicável”.
De mesma maneira, quando estiver utilizando uma representação
contínua, áreas de processos podem ser selecionadas para
exclusão se não estiverem dentro do escopo de trabalho ou do
esforço de melhoria de processos da organização. Deve-se tomar
cuidado, entretanto, para que as áreas de processos que são a
base para outras áreas de processos da organização não sejam
Visão Geral 85
CMMI-SE/SW, v1.1
excluídas. Além disso, mesmo que uma organização utilize a

representação contínua, se ela desejar utilizar a equivalência de
estágios, deverá aderir às instruções de adaptação praticadas
pelos usuários da representação em estágios.
• Uma área de processo é definida como “não classificada” se estiver
fora do escopo da avaliação ou se houverem dados disponíveis
insuficientes para satisfazer os critérios de cobertura de dados. Um
nível de maturidade não pode ser definido se áreas de processos
daquele nível de maturidade (ou abaixo) estiverem como “não
classificadas”.
• As metas são exigidas e, portanto, não podem ser excluídas das
áreas de processos incluídas no escopo de um esforço de melhoria
de processos ou de avaliação. As metas refletem os requisitos
mínimos para se satisfazer uma área de processo. Se uma área de
processo é aplicável, todas as suas metas são aplicáveis. As metas
trabalham juntas para suportar uma área de processos e não
podem ser individualmente designadas como “não aplicáveis”.
• Espera-se que as práticas específicas e genéricas sejam
implementadas como atividades comuns necessárias para
implementar e institucionalizar as metas da área de processo.
Entretanto, práticas alternativas apropriadas podem ser substitutas
para práticas específicas e/ou genéricas, se as alternativas forem
eficientes na implementação e institucionalização das metas.
• Todos os outros componentes de modelos (sub-práticas, exemplos,
definições ampliadas, elaborações e/ou referências) contidos nos
modelos CMMI são informativos e são fornecidos somente como
direcionamento da implementação.
Adaptação de Modelos para Pequenos Projetos
Os modelos CMMI foram escritos para serem utilizados por todos os

tipos de organizações, entretanto, para pequenas organizações deve
haver uma interpretação do modelo CMMI. No caso de projetos
pequenos, de três a seis meses, normalmente é disponibilizado um
plano de alto nível desenvolvido para um grupo de projetos. Este plano
de alto nível define a organização, recursos, treinamento, participação
da gerência e descrições de relatórios de garantia de qualidade para
todos os projetos. [FM120.HDA104.HDB104.T101]
De forma semelhante, no plano do projeto, é definido o planejamento

detalhado do projeto, como o cronograma, tarefas e recursos. Muitas
vezes, o plano do projeto também contém planos para outras funções
de suporte, como a garantia da qualidade e o gerenciamento de
configurações. Um projeto de quatro pessoas pode ter um plano de
projeto que tenha somente algumas páginas. [FM120.HDA104.HDB104.T102]
86 Visão Geral
CMMI-SE/SW, v1.1
Em pequenos projetos, as reuniões ocorrem com mais freqüência,

levam menos tempo e cobrem mais detalhes. O cronograma pode
conter atividades diárias e ser monitorados em reuniões semanais. O
cronograma pode ser modificado e controlado semanalmente.
[FM120.HDA104.HDB104.T104]
Em uma pequena equipe, o cliente normalmente conhece a equipe

toda e se sente à vontade para chamar qualquer membro da equipe
para propor ou discutir uma mudança . A equipe deve decidir
antecipadamente como tratar essas chamadas informais do cliente.
Uma vez que os membros da equipe tenham decidido por uma
abordagem, esta deverá ser documentada e comunicada ao cliente.
[FM120.HDA104.HDB104.T105]
Adaptação de Avaliações
As principais opções de adaptação de avaliações para o CMMI

incluem: [FM120.HDA104.HDB105.T101]
• Estabelecer o escopo do avaliação, incluindo a entidade

organizacional a ser avaliada, as áreas de processos do CMMI a
serem investigadas e o nível a ser avaliado
• Selecionar o método de avaliação
• Selecionar os membros da equipe de avaliação
• Selecionar os participantes a serem entrevistados na entidade sob
avaliação
• Estabelecer as saídas da avaliação (por exemplo, classificações,
descobertas por instâncias específicas)
• Estabelecer restrições de avaliação (por exemplo, tempo gasto no
local)
Além destas opções de adaptação da avaliação, a descrição do

método de avaliação do CMMI detalha uma série de opções
específicas de adaptação de avaliação direcionadas para considerar os
objetivos de uma avaliação específica e os objetivos de negócios de
uma organização e/ou instância. A documentação dos planos e
resultados de avaliações CMMI devem sempre incluir uma descrição
das opções de adaptação de avaliação selecionadas, bem como o
possível modelo de adaptação. Tal documentação permitirá a
determinação da possibilidade de comparação de resultados de
avaliações entre organizações. [FM120.HDA104.HDB105.T102]
Visão Geral 87
CMMI-SE/SW, v1.1
88 Visão Geral
CMMI-SE/SW, v1.1
7 Áreas de Processos
89
CMMI-SE/SW, v1.1
90
CMMI-SE/SW, v1.1
NÍVEL DE MATURIDADE 2: GERENCIADO
A seção seguinte contém todas as áreas de processos que pertencem

ao nível de maturidade 2. As áreas de processos do nível de
maturidade 2 do CMMI são: [FM109.T101]
• Gerenciamento de Requisitos (Requirements Management)

• Planejamento do Projeto (Project Planning)
• Monitoramento e Controle do Projeto (Project Monitoring and
Control)
• Gerenciamento de Acordos com Fornecedores (Supplier Agreement
Management)
• Medições e Análises (Measurement and Analysis)
• Garantia da Qualidade do Processo e do Produto (Process and
Product Quality Assurance)
• Gerenciamento de Configurações (Configuration Management)
Veja o Capítulo 2 para obter maiores informações sobre os níveis de

maturidade do CMMI. [FM109.T103]
Maturity Level: 2 91
CMMI-SE/SW, v1.1
GERENCIAMENTO DE REQUISITOS
Nível de Maturidade 2
Objetivo
O objetivo do Gerenciamento de Requisitos (Requirements

Management) é 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. [PA146]
Notas Introdutórias
Os processos de gerenciamento de requisitos gerenciam todos os

requisitos recebidos ou gerados pelo projeto, incluindo requisitos
técnicos e não técnicos, bem como os requisitos impostos no projeto
pela organização. Em particular, se a área de processo de
Desenvolvimento de Requisitos estiver implementada, seus processos
gerarão os requisitos de produtos e componentes de produtos que
também serão gerenciados pelos processos de gerenciamento de
requisitos. Quando as áreas de Gerenciamento de Requisitos,
Desenvolvimento de Requisitos e Soluções Técnicas estiverem todas
implementadas, seus processos associados podem estar fortemente
conectados e serem executados de forma concorrente. [PA146.N101]
O projeto executa os passos apropriados para assegurar que o

conjunto de requisitos acordados é gerenciado para suportar as
necessidades de planejamento e execução do projeto. Quando um
projeto recebe requisitos de um gerador aprovado de requisitos, estes
são revisados com o fornecedor de requisitos para resolver questões e
prevenir o mau entendimento, antes que os requisitos sejam
incorporados aos planos do projeto. Uma vez que o fornecedor e o
receptor dos requisitos cheguem a um acordo, é obtido um
compromisso dos participantes do projeto sobre os requisitos. O projeto
gerencia as mudanças feitas nos requisitos conforme eles evoluem e
identifica quaisquer inconsistências que ocorram entre planos, produtos
de trabalho e requisitos. [PA146.N102]
Parte do gerenciamento de requisitos é 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. [PA146.N103]
92 Nível de Maturidade: 2, Gerenciamento de Requisitos

CMMI-SE/SW, v1.1
Áreas de Processos Relacionadas
Veja a área de processo de Desenvolvimento de Requisitos para obter

maiores informações sobre a transformação das necessidades dos
stakeholders em requisitos de produtos e a decisão sobre como alocar
ou distribuir os requisitos entre os componentes de produtos. [PA146.R101]
Veja a área de processo de Soluções Técnicas para obter maiores

informações sobre como transformar requisitos em soluções técnicas.
[PA146.R102]
Veja a área de processo de Planejamento do Projeto para obter

maiores informações sobre como os planos do projeto refletem os
requisitos e a necessidade de revisão conforme os requisitos mudam.
[PA146.R103]
Veja a área de processo de Gerenciamento de Configurações para

obter maiores informações sobre baselines e controle de mudanças na
documentação de configurações para requisitos. [PA146.R104]
Veja a área de processo de Monitoramento e Controle do Projeto para

obter maiores informações sobre o rastreamento e controle das
atividades e produtos de trabalho que são baseados nos requisitos e
sobre a tomada da ação corretiva apropriada. [PA146.R105]
Veja a área de processo de Gerenciamento de Requisitos para obter

maiores informações sobre a identificação e tratamento de riscos
associados com requisitos. [PA146.R106]
SG 1 Gerenciar Requisitos [PA146.IG101]
Os requisitos são gerenciados e as inconsistências com os planos do

projeto e os produtos de trabalho são identificadas.
GG 2 Institucionalizar um Processo Gerenciado [CL103.GL101]
Nível de Maturidade: 2, Gerenciamento de Requisitos 93

CMMI-SE/SW, v1.1
(A meta seguinte não é exigida no nível de maturidade 2, mas é exigida no nível de maturidade
3 e superiores).
GG 3 Institucionalizar um Processo Definido [CL104.GL101]
Tabela de Relacionamentos Práticas-Metas
SG 1 Gerenciar Requisitos [PA146.IG101]
SP 1.1 Obter um Entendimento dos Requisitos

SP 1.2 Obter Compromisso sobre os Requisitos
SP 1.3 Gerenciar Mudanças nos Requisitos
SP 1.4 Manter a Rastreabilidade Bidirecional dos Requisitos
SP 1.5 Identificar Inconsistências entre o Trabalho do Projeto e os Requisitos
GP 2.1 (CO 1) Estabelecer uma Política Organizacional

GP 2.2 (AB 1) Planejar o Processo
GP 2.3 (AB 2) Fornecer Recursos
GP 2.4 (AB 3) Atribuir Responsabilidades
GP 2.5 (AB 4) Treinar as Pessoas
GP 2.6 (DI 1) Gerenciar Configurações
GP 2.7 (DI 2) Identificar e Envolver os Stakeholders Relevantes
GP 2.8 (DI 3) Monitorar e Controlar o Processo
GP 2.9 (VE 1) Avaliar Objetivamente a Aderência
GP 2.10 (VE 2) Revisar o Status com um Nível Mais Alto de Gerência
(A meta seguinte não é exigida e suas práticas não são esperadas para uma classificação de
nível de maturidade 2, mas são exigidas e esperadas para uma classificação de nível de
maturidade 3 e superiores).

Práticas Específicas por Meta
SG 1 Gerenciar Requisitos
Os requisitos são gerenciados e as inconsistências com os planos do

projeto e os produtos de trabalho são identificadas. [PA146.IG101]
O projeto mantém um conjunto atualizado e aprovado de requisitos

durante toda a vida do projeto através de: [PA146.IG101.N101]
• Gerenciamento de todas as mudanças nos requisitos

CMMI-SE/SW, v1.1
• Manutenção dos relacionamentos entre os requisitos, planos de

projeto e produtos de trabalho
• Identificação de inconsistências entre os requisitos, os planos de
projetos e os produtos de trabalho
• Tomada de ações corretivas

informações sobre como determinar a possibilidade de execução dos
requisitos. [PA146.IG101.N101.R101]

maiores informações sobre como assegurar que os requisitos refletem
as necessidades e expectativas do cliente. [PA146.IG101.N101.R102]

obter maiores informações sobre como tomar as ações corretivas.
[PA146.IG101.N101.R103]
Para Engenharia de Software

Os requisitos podem ser um subconjunto dos requisitos gerais
de um produto ou podem constituir os requisitos do produto
como um todo. [PA146.IG101.AMP101]
Para Engenharia de Sistemas

Cada nível de design de componentes do produto (por
exemplo, segmento, subsistema) recebe os requisitos de um
nível mais elevado. [PA146.IG101.AMP102]
SP 1.1 Obter um Entendimento dos Requisitos

Desenvolver um entendimento com os fornecedores dos
requisitos sobre o significado dos requisitos. [PA146.IG101.SP101]
Conforme o projeto amadurece e requisitos são derivados, todas as

atividades ou disciplinas receberão requisitos. Para evitar que os
requisitos cresçam indistintamente, são estabelecidos critérios para
determinar os canais apropriados ou fontes oficiais, a partir dos quais
deve-se receber os requisitos. As atividades de recebimento executam
análises dos requisitos junto ao fornecedor dos requisitos para
assegurar que um entendimento compartilhado e compatível do
significado dos requisitos foi conseguido. O resultado desta análise e
diálogo é um conjunto de requisitos acordados. [PA146.IG101.SP101.N101]

1. Listas de critérios para distinguir os fornecedores apropriados de
requisitos [PA146.IG101.SP101.W101]

CMMI-SE/SW, v1.1
2. Critérios para a avaliação e aceitação dos requisitos

[PA146.IG101.SP101.W102]
3. Resultados de análises contra os critérios [PA146.IG101.SP101.W103]
4. Um conjunto de requisitos acordados [PA146.IG101.SP101.W104]
Sub-práticas
1. Estabelecer critérios para distinguir os fornecedores apropriados
de requisitos. [PA146.IG101.SP101.SubP101]
2. Estabelecer critérios objetivos para a aceitação de requisitos.

[PA146.IG101.SP101.SubP102]
A falta de critérios de aceitação muitas vezes resulta numa

verificação inadequada, um caro retrabalho ou a rejeição
do cliente. [PA146.IG101.SP101.SubP102.N102]
Exemplos de critérios de aceitação são:

[PA146.IG101.SP101.SubP102.N101]
• Clara e apropriadamente declarados

• Completos
• Consistentes uns com os outros
• Identificados de forma única
• Apropriados para serem implementados
• Verificáveis (podem ser testados)
• Rastreáveis
3. Analisar os requisitos para assegurar que os critérios

estabelecidos estão sendo atendidos. [PA146.IG101.SP101.SubP103]
4. Chegar a um entendimento dos requisitos com o fornecedor dos

requisitos, de forma que os participantes do projeto possam
estabelecer compromissos com relação a eles. [PA146.IG101.SP101.SubP104]
SP 1.2 Obter Compromissos com os Requisitos

Obter dos participantes do projeto compromissos com os
requisitos. [PA146.IG101.SP102]

obter maiores informações sobre como monitorar os compromissos
assumidos. [PA146.IG101.SP102.R101]

CMMI-SE/SW, v1.1
Enquanto a prática específica anterior trata de se chegar a um

entendimento com os fornecedores de requisitos, esta prática
específica trata de acordos e compromissos entre aqueles que terão
que executar as atividades necessárias para implementar os requisitos.
Os requisitos evoluem ao longo do projeto, especialmente conforme
descrito pelas práticas específicas das áreas de processos de
Desenvolvimento de Requisitos e de Soluções Técnicas. Conforme os
requisitos evoluem, esta prática específica assegura que os
participantes do projeto se comprometem com os requisitos atuais
aprovados e com as mudanças resultantes nos planos de projeto,
atividades e produtos de trabalho. [PA146.IG101.SP102.N101]

1. Análises de impacto de requisitos [PA146.IG101.SP102.W101]
2. Compromissos documentados com os requisitos e com as

mudanças de requisitos [PA146.IG101.SP102.W102]
Sub-práticas
1. Analisar o impacto dos requisitos nos compromissos existentes.
[PA146.IG101.SP102.SubP101]
O impacto nos participantes do projeto deverá ser avaliado

quando os requisitos mudarem ou no início de um novo
requisito. [PA146.IG101.SP102.SubP101.N101]
2. Negociar e registrar compromissos. [PA146.IG101.SP102.SubP102]
As mudanças nos compromissos existentes deverão ser

negociadas antes dos participantes do projeto assumirem
compromissos com o requisito ou com a mudança de
requisitos. [PA146.IG101.SP102.SubP102.N101]
SP 1.3 Gerenciar as Mudanças de Requisitos

Gerenciar as mudanças nos requisitos conforme estes
evoluem durante o projeto. [PA146.IG101.SP103]

obter maiores informações sobre como manter e controlar a baseline
de requisitos e sobre como tornar disponíveis para o projeto os dados
de requisitos e de mudanças. [PA146.IG101.SP103.R101]

CMMI-SE/SW, v1.1
Durante o projeto, os requisitos mudam por uma série de motivos.

Conforme as necessidades mudam e o trabalho prossegue, requisitos
adicionais são derivados e mudanças podem ter que ser feitas nos
requisitos já existentes. É essencial gerenciar esses acréscimos e
mudanças de forma eficiente e eficaz. Para analisar de forma eficaz o
impacto das mudanças, é necessário que a fonte de cada requisito seja
conhecida e que a justificativa para qualquer mudança seja
documentada. O gerente do projeto pode, entretanto, desejar rastrear
as medidas adequadas de volatilidade de requisitos para julgar se são
necessários novos controles ou a revisão dos já existentes.
[PA146.IG101.SP103.N101]

1. Status de requisitos [PA146.IG101.SP103.W101]
2. Banco de dados de requisitos [PA146.IG101.SP103.W102]
3. Banco de dados de decisões de requisitos [PA146.IG101.SP103.W103]
Sub-práticas
1. Capturar todos os requisitos e mudanças de requisitos que foram
recebidas ou geradas pelo projeto. [PA146.IG101.SP103.SubP101]
2. Manter o histórico das mudanças nos requisitos juntamente com a

justificativa para as mudanças. [PA146.IG101.SP103.SubP102]
Manter o histórico de mudanças auxilia a rastrear a

volatilidade dos requisitos. [PA146.IG101.SP103.SubP102.N101]
3. Avaliar o impacto das mudanças nos requisitos a partir do ponto

de vista dos stakeholders relevantes. [PA146.IG101.SP103.SubP103]
4. Tornar disponíveis para o projeto os dados de requisitos e de

mudanças. [PA146.IG101.SP103.SubP104]
SP 1.4 Manter a Rastreabilidade Bidirecional de Requisitos

Manter a rastreabilidade bidirecional entre os requisitos e os
planos do projeto e produtos de trabalho. [PA146.IG101.SP104]

CMMI-SE/SW, v1.1
A intenção desta prática específica é manter a rastreabilidade

bidirecional dos requisitos para cada nível de decomposição do
produto. Quando os requisitos são bem gerenciados, a rastreabilidade
pode ser estabelecida, desde um requisito fonte até seus requisitos de
mais baixo nível e destes de volta para o seu requisito fonte. Tal
rastreabilidade bidirecional auxilia a determinar se todos os requisitos
fonte foram completamente tratados e se todos os requisitos de mais
baixo nível podem ser rastreados para uma fonte válida. A
rastreabilidade de requisitos pode também cobrir os relacionamentos
com outras entidades, como produtos de trabalho intermediários e
finais, mudanças na documentação de design, planos de testes e
tarefas de trabalho. A rastreabilidade deverá cobrir os relacionamentos
horizontais e verticais, como as interfaces. A rastreabilidade é
particularmente necessária na condução da análise do impacto de
mudanças de requisitos nos planos do projeto, atividades e produtos de
trabalho. [PA146.IG101.SP104.N101]

1. Matriz de rastreabilidade de requisitos [PA146.IG101.SP104.W101]
2. Sistema de rastreamento de requisitos [PA146.IG101.SP104.W102]
Sub-práticas
1. Manter a rastreabilidade dos requisitos para assegurar que a fonte
dos requisitos de mais baixo nível (derivados) está documentada.
[PA146.IG101.SP104.SubP101]
2. Manter a rastreabilidade dos requisitos até seu requisito derivado,

bem como a sua alocação de funções, objetos, pessoas,
processos e produtos de trabalho. [PA146.IG101.SP104.SubP102]
3. Manter a rastreabilidade horizontal de função para função e entre

interfaces. [PA146.IG101.SP104.SubP103]
4. Gerar a matriz de rastreabilidade de requisitos. [PA146.IG101.SP104.SubP104]
SP 1.5 Identificar Inconsistências entre o Trabalho do Projeto e os

Requisitos
Identificar inconsistências entre os planos de projeto e
produtos de trabalho do projeto e os requisitos. [PA146.IG101.SP105]

obter maiores informações sobre como monitorar e controlar os planos
de projeto e produtos de trabalho para a sua consistência com os
requisitos e tomar as ações corretivas quando necessário.
[PA146.IG101.SP105.R101]

CMMI-SE/SW, v1.1
Esta prática específica descobre as inconsistências entre os requisitos

e os planos do projeto e produtos de trabalho e inicia a ação corretiva
para corrigi-las. [PA146.IG101.SP105.N101]

1. Documentação de inconsistências incluindo fontes, condições e
justificativas [PA146.IG101.SP105.W101]
2. Ações corretivas [PA146.IG101.SP105.W102]
Sub-práticas
1. Revisar os planos do projeto, atividades e produtos de trabalho
com relação à consistência com os requisitos e com as mudanças
que foram feitas. [PA146.IG101.SP105.SubP101]
2. Identificar a fonte da inconsistência e sua justificativa.

[PA146.IG101.SP105.SubP102]
3. Identificar as mudanças que precisam ser feitas nos planos e

produtos de trabalho resultantes das mudanças na baseline de
requisitos. [PA146.IG101.SP105.SubP103]
4. Iniciar as ações corretivas. [PA146.IG101.SP105.SubP104]
Compromisso

planejamento e execução do processo de gerenciamento de
requisitos. [GP103]
Elaboração:
Esta política estabelece as expectativas organizacionais para o

gerenciamento de requisitos e identificação de inconsistências entre os
requisitos e os planos do projeto e produtos de trabalho. [PA146.EL101]

CMMI-SE/SW, v1.1
Habilitações

Estabelecer e manter o plano para a execução do processo de
gerenciamento de requisitos. [GP104]
Elaboração:
Normalmente, este plano para a execução do processo de

gerenciamento de requisitos é uma parte do plano do projeto, conforme
descrito na área de processo de Planejamento do Projeto. [PA146.EL102]

Fornecer os recursos adequados para a execução do processo
de gerenciamento de requisitos, desenvolvimento de produtos
de trabalho e fornecimento dos serviços do processo. [GP105]
Elaboração:
Exemplos de recursos fornecidos incluem as seguintes

ferramentas: [PA146.EL113]
• Ferramentas de rastreamento de requisitos

• Ferramentas de rastreabilidade

fornecimento dos serviços do processo de gerenciamento de
requisitos. [GP106]
GP 2.5 (AB 4) Treinar Pessoas

Treinar as pessoas para executar e suportar o processo de
gerenciamento de requisitos, conforme necessário. [GP107]

CMMI-SE/SW, v1.1
Elaboração:
Exemplos de tópicos de treinamento incluem: [PA146.EL105]
• Domínio da aplicação
• Definição, análise, revisão e gerenciamento de requisitos
• Ferramentas de gerenciamento de requisitos
• Gerenciamento de configurações
• Negociação e resolução de conflitos
Implementações

Colocar os produtos de trabalho definidos do processo de
gerenciamento de requisitos sob os níveis apropriados de
gerenciamento de configurações. [GP109]
Elaboração:
Exemplos de produtos de trabalho colocados sob o

gerenciamento de configurações incluem: [PA146.EL108]
• Requisitos
• Matriz de rastreabilidade de requisitos

Identificar e envolver os stakeholders relevantes do processo
de gerenciamento de requisitos, conforme planejado. [GP124]
Elaboração:
Selecionar os stakeholders relevantes entre os clientes, usuários finais,

desenvolvedores, produtores, testadores, fornecedores, pessoal de
marketing, de manutenção, de descarte e outros que possam ser
afetados ou possam afetar o produto ou o processo. [PA146.EL115]

CMMI-SE/SW, v1.1
Exemplos de atividades para envolvimento dos stakeholders

incluem: [PA146.EL116]
• Resolver questões sobre o entendimento dos requisitos

• Analisar o impacto de mudanças nos requisitos
• Comunicar a rastreabilidade bidirecional
• Identificar as inconsistências entre os planos do projeto,
produtos de trabalho e requisitos

Monitorar e controlar o processo de gerenciamento de
requisitos contra o plano de execução do processo e tomar a
ação corretiva apropriada. [GP110]
Elaboração:
Exemplos de medidas utilizadas no monitoramento e

controle incluem: [PA146.EL111]
• Volatilidade dos requisitos (percentual de requisitos

alterados)

Avaliar objetivamente a aderência do processo de
gerenciamento de requisitos contra sua descrição de processo,
padrões e procedimentos e tratar as não conformidades. [GP113]
Elaboração:
Exemplos de atividades revisadas incluem: [PA146.EL112]
• Gerenciar os requisitos
• Identificar as inconsistências entre os planos do projeto,
produtos de trabalho e requisitos

CMMI-SE/SW, v1.1
Exemplos de produtos de trabalho revisados incluem:

[PA146.EL114]
• Requisitos
• Matriz de rastreabilidade de requisitos
GP 2.10 (VE 2) Revisar Status com Nível Mais Alto de Gerência

Revisar as atividades, status e resultados do processo de
gerenciamento de requisitos com o nível mais alto nível de
gerência e resolver questões. [GP112]
Elaboração:
As mudanças propostas a compromissos a serem feitos de forma

externa à organização são revisados com o nível mais alto de
gerenciamento, de forma a assegurar que todos os compromissos
podem ser cumpridos. [PA146.EL117]
(A seguinte meta não é exigida nem suas práticas esperadas para uma classificação de nível de
maturidade 2, mas são exigidas para uma classificação de nível de maturidade 3 e superiores).

Estabelecer e manter a descrição de um processo definido de
gerenciamento de requisitos. [GP114]

e informações de melhorias derivados do planejamento e
execução do processo de gerenciamento de requisitos para
suportar o uso futuro e a melhoria dos processos e ativos de
processos da organização. [GP117]

CMMI-SE/SW, v1.1
PLANEJAMENTO DO PROJETO
Objetivo
O objetivo do Planejamento do Projeto (Project Planning) é estabelecer

e manter planos que definem as atividades do projeto. [PA163]
A área de processo de Planejamento do Projeto (Project Planning)

envolve: [PA163.N101]
• Desenvolver o plano do projeto

• Interagir com os stakeholders de forma apropriada
• Obter compromissos com o plano
• Manter o plano
O planejamento começa com os requisitos que definem o produto e o

projeto. [PA163.N102]
O planejamento inclui estimar os atributos dos produtos de trabalho e

tarefas, determinar os recursos necessários, negociar compromissos,
produzir um cronograma e identificar e analisar os riscos do projeto.
Iterações destas atividades podem ser necessárias para estabelecer o
plano do projeto. O plano do projeto fornece a base para a execução e
controle das atividades de projeto que tratam dos compromissos com o
cliente do projeto. [PA163.N103]
O plano do projeto normalmente precisará ser revisado, conforme o

projeto evolui, para tratar mudanças nos requisitos e compromissos,
estimativas imprecisas, ações corretivas e mudanças no processo. As
práticas específicas que descrevem o planejamento e o replanejamento
estão contidas nesta área de processo. [PA163.N104]
O termo “plano do projeto” é utilizado em todas as práticas genéricas e

específicas desta área de processo para se referir ao plano geral de
controle do projeto. [PA163.N105]
Nível de Maturidade: 2, Planejamento do Projeto 105

CMMI-SE/SW, v1.1

maiores informações sobre o desenvolvimento de requisitos que
definem o produto e os componentes do produto. Os requisitos de
produto e de componentes do produto e mudanças feitas nestes
requisitos servem como base para o planejamento e o replanejamento.
[PA163.R101]

maiores informações sobre o gerenciamento de requisitos necessários
para o planejamento e replanejamento. [PA163.R102]
Veja a área de processo de Gerenciamento de Riscos para obter

maiores informações sobre a identificação e gerenciamento de riscos.
[PA163.R103]

informações sobre a transformação de requisitos em soluções de
produto e de componentes de produtos. [PA163.R104]
SG 1 Estabelecer Estimativas [PA163.IG101]
Estimativas dos parâmetros de planejamento do projeto são estabelecidas

e mantidas.
SG 2 Desenvolver um Plano de Projeto [PA163.IG102]
Um plano de projeto é estabelecido e mantido como base para o

gerenciamento do projeto.
SG 3 Obter Compromissos com o Plano [PA163.IG103]
Compromissos com o plano de projeto são estabelecidos e mantidos.
106 Nível de Maturidade: 2, Planejamento do Projeto

CMMI-SE/SW, v1.1
(A meta seguinte não é exigida para o nível de maturidade 2, mas é exigida para o nível de
Tabela de Relacionamento Prática-Meta
SG 1 Estabelecer Estimativas [PA163.IG101]
SP 1.1 Estimar o Escopo do Projeto

SP 1.2 Estabelecer Estimativas de Atributos de Produtos de Trabalho e Tarefas
SP 1.3 Definir o Ciclo de Vida do Projeto
SP 1.4 Determinar Estimativas de Esforço e Custo
SG 2 Desenvolver um Plano de Projeto [PA163.IG102]
SP 2.1 Estabelecer o Orçamento e o Cronograma

SP 2.2 Identificar os Riscos do Projeto
SP 2.3 Planejar o Gerenciamento de Dados
SP 2.4 Planejar os Recursos do Projeto
SP 2.5 Planejar as Habilidades e Conhecimentos Necessários
SP 2.6 Planejar o Envolvimento dos Stakeholders
SP 2.7 Estabelecer o Plano de Projeto
SG 3 Obter Compromissos com o Plano [PA163.IG103]
SP 3.1 Revisar os Planos que Afetam o Projeto

SP 3.2 Conciliar os Níveis de Trabalho e de Recursos
SP 3.3 Obter Compromissos com o Plano

GP 2.10 (VE 2) Revisar Status com a Gerência de Mais Alto Nível
(A seguinte meta não é exigida e suas práticas não são esperadas para uma classificação de


CMMI-SE/SW, v1.1
SG 1 Estabelecer Estimativas
Estimativas de parâmetros de planejamento do projeto são estabelecidas e

mantidas. [PA163.IG101]
Os parâmetros de planejamento do projeto incluem todas as

informações necessárias pelo projeto para executar o necessário
planejamento, organização, definição de pessoal, direcionamento,
coordenação, comunicação de resultados e acompanhamento do
orçamento. [PA163.IG101.N101]
Estimativas de parâmetros de planejamento deverão ter uma base

firme para garantir que quaisquer planos baseados nestas estimativas
serão capazes de suportar os objetivos do projeto. [PA163.IG101.N102]
Os fatores que normalmente são considerados quando se estima estes

parâmetros incluem: [PA163.IG101.N103]
• Requisitos de projetos, incluindo os requisitos de produtos, os

requisitos impostos pela organização, os requisitos impostos pelo
cliente e outros requisitos que impactem no projeto
• Escopo do projeto
• Tarefas e produtos de trabalho identificados
• Abordagem técnica
• Modelo de ciclo de vida selecionado para o projeto (por exemplo,
cascata, incremental, espiral, etc).
• Atributos dos produtos de trabalho e tarefas (por exemplo, tamanho
ou complexidade)
• Cronograma
• Modelos ou dados históricos para conversão dos atributos dos
produtos de trabalho e tarefas em horas de trabalho e custo
• Metodologia (modelos, dados, algoritmos) utilizada para determinar
material, habilidades, horas de trabalho e custo necessários
É necessário documentar a justificativa para a estimativa e os dados de

suporte para a revisão e compromisso dos stakeholders com o plano e
para a manutenção do plano, conforme o projeto progride. [PA163.IG101.N104]

CMMI-SE/SW, v1.1
SP 1.1 Estimar o Escopo do Projeto

Estabelecer uma estrutura de decomposição de trabalho (work
breakdown structure - WBS) de alto nível para estimar o
escopo do projeto. [PA163.IG101.SP101]
A WBS evolui com o projeto.Inicialmente, uma WBS de alto nível pode

ser para estruturar a estimativa inicial. O desenvolvimento de uma
WBS divide o projeto geral em um conjunto interconectado de
componentes gerenciáveis. A WBS é, geralmente, uma estrutura
orientada para o produto que garante um esquema para identificação e
organização das unidades lógicas de trabalho a serem gerenciadas,
que são chamadas de “pacotes de trabalho” (“work packages”). A WBS
fornece uma referência e um mecanismo organizacional para a
atribuição de esforços, cronograma e responsabilidades e é utilizada
como uma estrutura subjacente para planejar, organizar e controlar o
trabalho executado no projeto. [PA163.IG101.SP101.N101]

1. Descrições de tarefas [PA163.IG101.SP101.W101]
2. Descrições de pacotes de trabalho [PA163.IG101.SP101.W102]
3. WBS [PA163.IG101.SP101.W103]
Sub-práticas
1. Desenvolver uma WBS baseada na arquitetura do produto.
[PA163.IG101.SP101.SubP101]
A WBS fornece um esquema para a organização do

trabalho do projeto de acordo com os produtos que o
trabalho suporta. A WBS deverá permitir a identificação
dos seguintes itens: [PA163.IG101.SP101.SubP101.N101]
• Riscos identificados e suas tarefas de mitigação

• Tarefas para os itens de entrega e para as atividades de
suporte
• Tarefas para aquisição de habilidades e conhecimentos
• Tarefas para o desenvolvimento dos planos de suporte
necessários, como os planos de gerenciamento de
configurações, de garantia da qualidade e de verificação.
• Tarefas para a integração e gerenciamento de itens que
não são de desenvolvimento
2. Identificar os pacotes de trabalho com detalhes suficientes para
especificar as estimativas de tarefas, responsabilidades e
cronograma do projeto. [PA163.IG101.SP101.SubP102]

CMMI-SE/SW, v1.1
A WBS de alto nível pretende auxiliar a medir com

exatidão o esforço de trabalho do projeto, em termos de
tarefas e papéis e responsabilidades organizacionais. A
quantidade de detalhes na WBS, neste nível mais
detalhado, auxilia a desenvolver cronogramas mais
realistas, minimizando, portanto, a necessidade de uma
reserva de gerenciamento. [PA163.IG101.SP101.SubP102.N101]
3. Identificar produtos de trabalho (ou componentes de produtos de

trabalho) que serão adquiridos externamente. [PA163.IG101.SP101.SubP103]
Veja a área de processo de Gerenciamento de Acordos com

Fornecedores para obter maiores informações sobre a aquisição
de produto de trabalho de fontes externas ao projeto.
[PA163.IG101.SP101.SubP103.R101]
4. Identificar produtos de trabalho que serão reutilizados.

[PA163.IG101.SP101.SubP104]
SP 1.2 Estabelecer Estimativas de Atributos de Produtos de Trabalho e

Tarefas
Estabelecer e manter estimativas de atributos de produtos de
trabalho e tarefas. [PA163.IG101.SP102]
O tamanho é a principal entrada de muitos modelos utilizados para

estimar o esforço, custo e cronograma. Os modelos podem também se
basear em entradas como a conectividade, complexidade e estrutura.
[PA163.IG101.SP102.N102]
Exemplos de tipos de produtos de trabalho para os quais são

feitas estimativas de tamanho incluem: [PA163.IG101.SP102.N103]
• Produtos de trabalho que serão entregues e que não

serão entregues
• Documentos
• Software operacional e de suporte

CMMI-SE/SW, v1.1
Exemplos de medidas de tamanho incluem: [PA163.IG101.SP102.N104]
• Quantidade de funções
• Pontos de função
• Linhas de código fonte
• Quantidade de classes e objetos
• Quantidade de requisitos
• Quantidade de interfaces
• Quantidade de páginas
• Quantidade de entradas e saídas
• Quantidade de itens de risco técnico
• Volume de dados
As estimativas deverão ser consistentes com os requisitos do projeto

para determinar o esforço, custo e cronograma do projeto. Um nível
relativo de dificuldade ou complexidade deverá ser atribuído para cada
atributo de tamanho. [PA163.IG101.SP102.N101]

1. Abordagem técnica [PA163.IG101.SP102.W101]
2. Tamanho e complexidade de tarefas e produtos de trabalho

[PA163.IG101.SP102.W102]
3. Modelos de estimativas [PA163.IG101.SP102.W103]
4. Estimativas de atributos [PA163.IG101.SP102.W104]
Sub-práticas
1. Determinar a abordagem técnica para o projeto. [PA163.IG101.SP102.SubP101]
A abordagem técnica define uma estratégia de alto nível

para o desenvolvimento dos produtos. Ela inclui decisões
de características de arquitetura, como arquitetura
distribuída ou cliente-servidor; tecnologias revolucionárias
ou estabelecidas a serem aplicadas, como robótica,
materiais compostos ou inteligência artificial; e a
abrangência esperada das funcionalidades dos produtos
finais, como segurança, confiabilidade e questões
ergonômicas. [PA163.IG101.SP102.SubP101.N101]
2. Usar métodos apropriados para determinar os atributos de

produtos de trabalho e tarefas que serão usados para estimar os
requisitos de recursos. [PA163.IG101.SP102.SubP102]

CMMI-SE/SW, v1.1
Os métodos para se determinar o tamanho e a

complexidade deverão ser baseados em modelos válidos
ou dados históricos. [PA163.IG101.SP102.SubP102.N101]
Os métodos para se determinar os atributos evoluem

conforme aumenta o nosso entendimento do
relacionamento das características do produto com seus
atributos. [PA163.IG101.SP102.SubP102.N102]
Exemplos de métodos atuais incluem:

[PA163.IG101.SP102.SubP102.N103]
• Quantidade de portas lógicas para o design de um

circuito integrado
• Linhas de código ou pontos de função para software
• Quantidade/complexidade de requisitos para engenharia
de sistemas
• Quantidade de metros quadrados para residências
padrão especificadas
3. Estimar os atributos dos produtos de trabalho e tarefas.

[PA163.IG101.SP102.SubP103]
4. Estimar, conforme apropriado, o trabalho, maquinário, materiais e

métodos que serão exigidos pelo projeto. [PA163.IG101.SP102.SubP104]
SP 1.3 Definir o Ciclo de Vida do Projeto

Definir as fases do ciclo de vida do projeto sobre as quais
estimar o escopo do esforço de planejamento. [PA163.IG101.SP103]
A determinação das fases do ciclo de vida do projeto possibilita

períodos planejados de avaliação e de tomada de decisões. Estes são
normalmente definidos para suportar pontos de decisão lógica nos
quais compromissos significativos são feitos com relação a recursos e
abordagem técnica. Tais pontos fornecem os eventos planejados nos
quais as correções de curso e definições de futuro escopo e custo do
projeto podem ser feitas. [PA163.IG101.SP103.N101]

A determinação de fases de projeto para software,
geralmente, inclui a seleção e refinamento de um modelo de
desenvolvimento de software para tratar as interdependências
e seqüência apropriada das atividades do projeto de software.
[PA163.IG101.SP103.N101.AMP101]

CMMI-SE/SW, v1.1

Identificar a fase principal do produto (isto é, exploração do
conceito, desenvolvimento, etc) para o estado atual do
produto, as fases esperadas no futuro e as relações e efeitos
entre as fases. Ajustar os parâmetros de planejamento para
contar com as relações e efeitos entre as fases.
[PA163.IG101.SP103.N101.AMP102]
O ciclo de vida do projeto consiste de fases que precisam ser definidas

de acordo com o escopo de requisitos, as estimativas para os recursos
do projeto e a natureza do projeto. Projetos maiores podem conter
diversas fases, como a exploração do conceito, desenvolvimento,
produção, operação e descarte. Dentro destas fases, pode haver a
necessidade de subfases. Uma fase de desenvolvimento pode incluir
subfases como a análise de requisitos, design, fabricação, integração e
verificação. Dependendo da estratégia de desenvolvimento, podem ser
criadas fases intermediárias para a criação de protótipos, incrementos
na capacitação ou ciclos de modelos espirais. [PA163.IG101.SP103.N102]
O entendimento do ciclo de vida do projeto é crucial na determinação

do escopo do esforço de planejamento e do momento do planejamento
inicial, bem como o momento e os critérios (milestones críticos) para o
replanejamento. [PA163.IG101.SP103.N103]

1. Fases do ciclo de vida do projeto [PA163.IG101.SP103.W101]
SP 1.4 Determinar Estimativas de Esforço e Custo

Estimar o esforço e o custo do projeto para os produtos de
trabalho e tarefas com base na justificativa de estimação.
[PA163.IG101.SP104]
Estimativas de esforço e custo são, normalmente, baseadas nos

resultados de análises utilizando modelos ou dados históricos
aplicados ao tamanho, atividades e outros parâmetros de
planejamento. A confiança nestas estimativas é baseada na justificativa
para o modelo selecionado e na natureza dos dados. Podem existir
ocasiões onde os dados históricos disponíveis não se aplicam, como
quando os esforços são sem precedentes ou quando o tipo de tarefa
não se encaixa nos modelos disponíveis. Um esforço é sem
precedentes (em um determinado grau) se um produto ou componente
semelhante nunca foi construído. Um esforço pode também ser sem
precedentes se o grupo de desenvolvimento nunca construiu um
produto ou componente parecido. [PA163.IG101.SP104.N101]

CMMI-SE/SW, v1.1
Os esforços sem precedentes são mais arriscados, exigem maior

pesquisa para desenvolver bases razoáveis de estimativas e exigem
uma maior reserva de gerenciamento. A natureza única do projeto deve
ser documentada quando forem utilizados estes modelos, para
assegurar um entendimento comum de quaisquer premissas adotadas
nas etapas iniciais do planejamento. [PA163.IG101.SP104.N102]

1. Justificativa de estimação [PA163.IG101.SP104.W101]
2. Estimativas de esforço do projeto [PA163.IG101.SP104.W102]
3. Estimativas de custo do projeto [PA163.IG101.SP104.W104]
Sub-práticas
1. Coletar modelos ou dados históricos que serão utilizados para
transformar os atributos dos produtos de trabalho e tarefas em
estimativas de horas de trabalho e custo. [PA163.IG101.SP104.SubP101]

Dentro da área de engenharia de software, foram
desenvolvidos muitos modelos parametrizados para auxiliar a
estimar o custo e o cronograma. O uso destes modelos como
único recurso de estimação não é recomendado, já que estes
modelos são baseados em dados históricos de projetos que
podem ou não ser pertinentes ao seu projeto. Diversos
modelos e/ou métodos podem ser utilizados para assegurar
um alto nível de confiança na estimativa.
[PA163.IG101.SP104.SubP101.AMP101]
Os dados históricos incluem os dados de custo, esforço e

cronograma de projetos executados anteriormente, além
de dados apropriados de escala para equilibrar as
diferenças de tamanho e complexidade.
[PA163.IG101.SP104.SubP101.N101]
2. Incluir necessidades de infra-estrutura de suporte quando estiver

estimando o esforço e o custo. [PA163.IG101.SP104.SubP102]
A infra-estrutura de suporte inclui itens necessários a

partir da visão do desenvolvimento e sustentação do
produto. [PA163.IG101.SP104.SubP102.N101]

Considerar os recursos computacionais críticos no ambiente
servidor, no ambiente de testes, no ambiente alvo ou em
qualquer combinação destes. A estimação de recursos
computacionais normalmente inclui:
[PA163.IG101.SP104.SubP102.N101.AMP101]

CMMI-SE/SW, v1.1
• identificar os recursos computacionais críticos para o

projeto de software e
• basear estimativas de recursos computacionais críticos
nos requisitos alocados

Exemplos de recursos computacionais críticos
incluem: [PA163.IG101.SP104.SubP102.N101.AMP102]
• Memória, disco e capacidade da rede

• Potência do processador
• Capacidade dos canais de comunicação
• Potência das estações de trabalho
• Capacidade de periféricos

Exemplos de recursos de engenharia de software
• Servidores, periféricos e redes

• Computadores e periféricos de testes de
software
• Ambiente de software do computador alvo
• Ambiente de engenharia de software (isto é,
ferramentas de software)
3. Estimar o esforço e o custo utilizando modelos e/ou dados

históricos. [PA163.IG101.SP104.SubP103]
As entradas de esforço e custo utilizadas para a estimativa

normalmente incluem: [PA163.IG101.SP104.SubP103.N101]
• Estimativas de conhecedores fornecidas por um expert ou

grupo de experts (por exemplo, Método Delphi)
• Riscos, incluindo a extensão na qual o esforço é sem
precedentes
• Competências críticas e papéis necessários para executar
o trabalho
• Requisitos de produtos e componentes de produtos
• Abordagem técnica
• WBS
• Estimativas de tamanho de produtos de trabalho e
mudanças previstas
• Custo de produtos de trabalho adquiridos externamente

CMMI-SE/SW, v1.1
• Modelo selecionado de ciclo de vida de projetos e

processos
• Estimativas de custos de ciclo de vida
• Capacidade das ferramentas fornecidas no ambiente de
engenharia
• Nível de habilitação de gerentes e pessoal necessário
para executar o trabalho
• Conhecimento, habilidades e necessidades de
treinamento
• Recursos necessários (por exemplo, escritórios, espaços
para reuniões e estações de trabalho)
• Recursos necessários de engenharia
• Capacitação de processos de fabricação
• Viagens
• Nível de segurança exigido para as tarefas, produtos de
trabalho, hardware, software, pessoal e ambiente de
trabalho
• Acordos de nível de serviço para call centers e trabalhos
de segurança
• Trabalho direto e horas extras
SG 2 Desenvolver um Plano de Projeto
Um plano de projeto é estabelecido e mantido como base para o

gerenciamento do projeto. [PA163.IG102]
Um plano de projeto é um documento formal aprovado utilizado para

gerenciar e controlar a execução do projeto. Ele é baseado nos
requisitos do projeto e nas estimativas estabelecidas. [PA163.IG102.N101]
O plano do projeto deverá considerar todas as fases do ciclo de vida do

projeto. O planejamento do projeto deverá assegurar que todos os
planos que afetam o projeto estejam consistentes com o plano geral do
projeto. [PA163.IG102.N102]
SP 2.1 Estabelecer o Orçamento e o Cronograma

Estabelecer e manter o orçamento e o cronograma do projeto.
[PA163.IG102.SP101]

CMMI-SE/SW, v1.1
O orçamento e o cronograma do projeto são baseados nas estimativas

desenvolvidas e asseguram que a alocação de orçamento,
complexidade das tarefas e dependências entre as tarefas estão sendo
tratadas apropriadamente. [PA163.IG102.SP101.N101]
Os cronogramas dirigidos a eventos com recursos limitados têm

provado ser eficientes em tratar dos riscos de projetos. A identificação
do que deve ser atingido antes do início do evento oferece alguma
flexibilidade na definição do momento do evento, um entendimento
comum do que é esperado, uma melhor visão do estado do projeto e
um status mais preciso das tarefas do projeto. [PA163.IG102.SP101.N102]

1. Cronogramas do projeto [PA163.IG102.SP101.W101]
2. Dependências do cronograma [PA163.IG102.SP101.W102]
3. Orçamento do projeto [PA163.IG102.SP101.W103]
Sub-práticas
1. Identificar os principais milestones. [PA163.IG102.SP101.SubP101]
Muitas vezes, são impostos milestones para assegurar que

certos itens a serem entregues estarão completos no
momento do milestone. Os milestones podem ser
baseados em eventos ou no calendário. Se for baseado no
calendário, uma vez que as datas dos milestones forem
acordadas, freqüentemente, é muito difícil alterá-las.
[PA163.IG102.SP101.SubP101.N101]
2. Identificar as premissas do cronograma. [PA163.IG102.SP101.SubP102]
Quando os cronogramas são inicialmente desenvolvidos, é

comum fazer algumas premissas sobre a duração de
certas atividades. Estas premissas são freqüentemente
feitas sobre itens para os quais poucos dados de
estimativas estão disponíveis, quando há algum dado
disponível. Identificar estas premissas fornece um
entendimento do nível de confiança (incertezas) do
cronograma geral. [PA163.IG102.SP101.SubP102.N101]
3. Identificar restrições. [PA163.IG102.SP101.SubP103]
Os fatores que limitam a flexibilidade das opções de

gerenciamento precisam ser identificados o mais cedo
possível. O exame dos atributos dos produtos de trabalho
e tarefas, muitas vezes, fazem emergir estas questões.
Tais atributos podem incluir a duração das tarefas,
recursos, entradas e saídas. [PA163.IG102.SP101.SubP103.N101]
4. Identificar dependências de tarefas. [PA163.IG102.SP101.SubP104]

CMMI-SE/SW, v1.1
Normalmente, as tarefas de um projeto podem ser

executadas em uma seqüência ordenada que minimizará a
duração do projeto. Isto envolve a identificação de tarefas
predecessoras e sucessoras para determinar a melhor
ordenação. [PA163.IG102.SP101.SubP104.N101]
Exemplos de ferramentas que podem auxiliar a

determinar a melhor ordenação de atividades de tarefas
incluem: [PA163.IG102.SP101.SubP104.N102]
• Método do Caminho Crítico (Critical Path Method - CPM)

• Técnica de Avaliação e Revisão de Programas (Program
Evaluation and Review Technique - PERT)
• Cronograma de recursos limitados
5. Definir o orçamento e o cronograma. [PA163.IG102.SP101.SubP105]
Estabelecer e manter o orçamento e cronograma do

projeto normalmente inclui: [PA163.IG102.SP101.SubP105.N101]
• Definir a disponibilidade comprometida ou esperada dos

recursos e locais
• Determinar a duração das atividades
• Determinar a explosão de cronogramas subordinados
• Definir as dependências entre as atividades
(relacionamentos de predecessoras e sucessoras)
• Definir as atividades do cronograma e milestones para
suportar a exatidão na medição do progresso
• Identificar milestones para a entrega de produtos ao
cliente
• Definir atividades de duração apropriada
• Definir milestones com os intervalos de tempo adequados
• Definir uma reserva de gerenciamento baseada no nível
de confiança no atendimento do cronograma e do
orçamento
• Usar os dados históricos apropriados para verificar o
cronograma
• Definir os requisitos de fundos incrementais
• Documentar as premissas e justificativas do projeto
6. Estabelecer os critérios de ações corretivas. [PA163.IG102.SP101.SubP106]

CMMI-SE/SW, v1.1
São estabelecidos critérios para determinar o que constitui

um desvio significativo do plano do projeto. Uma base para
avaliar com precisão questões e problemas é necessária
para determinar quando uma ação corretiva deverá ser
tomada. As ações corretivas podem exigir um
replanejamento, que pode incluir a revisão do plano
original, estabelecimento de novos acordos ou inclusão de
atividades de mitigação dentro do plano atual.
[PA163.IG102.SP101.SubP106.N101]
SP 2.2 Identificar os Riscos do Projeto

Identificar e analisar os riscos do projeto. [PA163.IG102.SP103]

maiores informações sobre as atividades de gerenciamento de riscos.
[PA163.IG102.SP103.R101]
Veja a prática específica Monitorar os Riscos do Projeto na área de

processo de Monitoramento e Controle do Projeto para obter maiores
informações sobre as atividades de monitoramento de riscos.
[PA163.IG102.SP103.R102]
Os riscos são identificados ou descobertos e analisados para suportar

o planejamento do projeto. Esta prática específica deverá ser estendida
a todos os planos que afetam o projeto, para assegurar que está
ocorrendo a comunicação apropriada entre todos os stakeholders
relevantes sobre os riscos identificados. A identificação e análise de
riscos no planejamento do projeto normalmente inclui: [PA163.IG102.SP103.N101]
• Identificar riscos
• Analisar os riscos para determinar o impacto, probabilidade de
ocorrência e período de tempo no qual os problemas têm maior
probabilidade de ocorrer
• Priorizar riscos

1. Riscos identificados [PA163.IG102.SP103.W101]
2. Impacto dos riscos e probabilidade de ocorrência [PA163.IG102.SP103.W102]
3. Prioridades de riscos [PA163.IG102.SP103.W103]
Sub-práticas
1. Identificar riscos. [PA163.IG102.SP103.SubP101]

CMMI-SE/SW, v1.1
A identificação dos riscos envolve a identificação de

potenciais questões, perigos, ameaças, vulnerabilidades,
etc que podem afetar negativamente os esforços de
trabalho e planos. Os riscos devem ser identificados e
descritos de uma forma compreensível, antes que possam
ser analisados. Quando estiver identificando riscos, é bom
utilizar um método padrão para a definição de riscos.
Ferramentas de identificação e análise de riscos podem ser
utilizadas para auxiliar a identificar os possíveis
problemas. [PA163.IG102.SP103.SubP101.N101]
Exemplos de ferramentas de identificação e análise de

riscos incluem: [PA163.IG102.SP103.SubP101.N102]
• Taxonomias de riscos
• Análises de riscos
• Checklists
• Entrevistas estruturadas
• Brainstorming
• Modelos de desempenho
• Modelos de custos
• Análise em rede
• Análise de fatores de qualidade
2. Documentar os riscos. [PA163.IG102.SP103.SubP102]
3. Revisar e obter acordos com os stakeholders relevantes sobre a

completitude e correção dos riscos documentados.
[PA163.IG102.SP103.SubP103]
4. Revisar os riscos, conforme apropriado. [PA163.IG102.SP103.SubP104]
Exemplos de quando os riscos identificados podem

precisar ser revisados incluem: [PA163.IG102.SP103.SubP104.N101]
• Quando um novo risco é identificado

• Quando riscos se tornam problemas
• Quando riscos não são mais válidos
• Quando as circunstâncias do projeto mudam
significativamente

CMMI-SE/SW, v1.1
SP 2.3 Planejar o Gerenciamento de Dados

Planejar o gerenciamento dos dados do projeto. [PA163.IG102.SP102]
Os dados são as várias formas de documentação exigidas para

suportar um programa em todas as suas áreas (por exemplo,
administração, engenharia, gerenciamento de configurações, finanças,
logística, qualidade, segurança, fabricação e compras). Os dados
podem estar em qualquer formato (por exemplo, relatórios, manuais,
anotações, gráficos, diagramas, especificações, arquivos ou
correspondências). Os dados podem existir em qualquer meio (por
exemplo, impressos ou desenhados em diversos materiais, fotografias,
meio eletrônico e multimídia). Os dados podem ser produtos a serem
entregues (por exemplo, itens identificados por requisitos de dados
contratuais de um programa) ou os dados podem não ser entregues
(por exemplo, dados informais, troca de estudos e análises, minutas de
reuniões internas, documentação interna de revisão de design, lições
aprendidas e itens de ação). A distribuição pode ocorrer de várias
formas, incluindo a transmissão eletrônica. [PA163.IG102.SP102.N101]
Os requisitos de dados do projeto deverão ser estabelecidos pelos

itens de dados a serem criados e seu conteúdo e forma, baseados em
um conjunto comum ou padrão de requisitos de dados. O conteúdo e
formato uniforme dos requisitos de itens de dados facilitam o
entendimento do conteúdo dos dados e auxiliam o gerenciamento
consistente dos recursos de dados. [PA163.IG102.SP102.N102]
O motivo de coletar cada documento deverá ser bem claro. Esta tarefa
inclui a análise e verificação dos itens do projeto a serem entregues e
que não serão entregues, requisitos de dados contratuais e não
contratuais e dados fornecidos pelos clientes. Muitas vezes, os dados
são coletados sem um entendimento claro de como serão utilizados.
Os dados têm um alto custo e deverão ser coletados somente quando
forem necessários. [PA163.IG102.SP102.N103]

1. Plano de gerenciamento de dados [PA163.IG102.SP102.W101]
2. Lista principal de dados gerenciados [PA163.IG102.SP102.W102]
3. Descrição de conteúdo e formato de dados [PA163.IG102.SP102.W103]
4. Listas de requisitos de dados para aquisidores e fornecedores

[PA163.IG102.SP102.W104]
5. Requisitos de privacidade [PA163.IG102.SP102.W105]
6. Requisitos de segurança [PA163.IG102.SP102.W106]
7. Procedimentos de segurança [PA163.IG102.SP102.W107]

CMMI-SE/SW, v1.1
8. Mecanismos para recuperação de dados, reprodução e

distribuição [PA163.IG102.SP102.W108]
9. Cronograma para coleta de dados do projeto [PA163.IG102.SP102.W109]
10. Listagem dos dados do projeto a serem coletados [PA163.IG102.SP102.W110]
Sub-práticas
1. Estabelecer requisitos e procedimentos para assegurar a
privacidade e a segurança dos dados. [PA163.IG102.SP102.SubP101]
Nem todo mundo terá a necessidade ou a autorização de

acesso necessária para acessar os dados do projeto.
Devem ser estabelecidos procedimentos para identificar
quem tem acesso a quais dados, assim como quando
essas pessoas tiveram acesso aos dados.
[PA163.IG102.SP102.SubP101.N101]
2. Estabelecer um mecanismo para arquivar os dados e para acessar

os dados arquivados. [PA163.IG102.SP102.SubP102]
As informações acessadas deverão estar em uma forma

compreensível (por exemplo, uma saída eletrônica de um
banco de dados) ou representadas como foram
originalmente geradas. [PA163.IG102.SP102.SubP102.N101]
3. Determinar os dados do projeto a serem identificados, coletados e

distribuídos. [PA163.IG102.SP102.SubP103]
SP 2.4 Planejar os Recursos do Projeto

Planejar os recursos necessários para executar o projeto.
[PA163.IG102.SP104]
A definição dos recursos do projeto (trabalho, máquinas/equipamentos,

materiais e métodos) e quantidades necessárias para executar as
atividades do projeto, se baseia nas estimativas iniciais e fornece
informações adicionais que podem ser aplicadas para expandir a WBS
utilizada para gerenciar o projeto. [PA163.IG102.SP104.N101]

CMMI-SE/SW, v1.1
A WBS de alto nível desenvolvida anteriormente como um mecanismo

de estimação é, normalmente, expandida pela decomposição destes
níveis elevados em pacotes de trabalho que representam unidades
simples de trabalho, que podem ser separadamente atribuídas,
executadas e rastreadas. Esta subdivisão é feita para distribuir a
responsabilidade pelo gerenciamento e oferecer um melhor controle do
gerenciamento. A cada pacote de trabalho ou produto de trabalho na
WBS deverá ser atribuído um identificador único (por exemplo, um
número) para permitir o rastreamento. Uma WBS pode ser baseada em
requisitos, atividades, produtos de trabalho ou uma combinação destes
itens. Um dicionário que descreve o trabalho para cada pacote de
trabalho na WBS deverá acompanhar a estrutura de decomposição do
trabalho (WBS). [PA163.IG102.SP104.N102]

1. Pacotes de trabalho da WBS [PA163.IG102.SP104.W101]
2. Dicionário de tarefas da WBS [PA163.IG102.SP104.W102]
3. Requisitos de pessoal baseados no tamanho e escopo do projeto

[PA163.IG102.SP104.W103]
4. Lista de equipamentos/recursos críticos [PA163.IG102.SP104.W104]
5. Definições e diagramas de processos/fluxo de trabalho

[PA163.IG102.SP104.W105]
6. Lista de requisitos de administração do programa [PA163.IG102.SP104.W106]
Sub-práticas
1. Determinar os requisitos do processo. [PA163.IG102.SP104.SubP101]
Os processos utilizados para gerenciar um projeto devem

ser identificados, definidos e coordenados com todos os
stakeholders relevantes para assegurar uma operação
eficiente durante a execução do projeto.
[PA163.IG102.SP104.SubP101.N101]
2. Determinar requisitos de pessoal. [PA163.IG102.SP104.SubP102]
O pessoal de um projeto depende da decomposição dos

requisitos do projeto em tarefas, papéis e
responsabilidades para atender os requisitos do projeto
como estes estão dispostos nos pacotes de trabalho da
WBS. [PA163.IG102.SP104.SubP102.N101]
Os requisitos de pessoal devem considerar os

conhecimentos e habilidades necessários para cada
posição identificada, conforme definido na prática
específica Planejar os Conhecimentos e Habilidades
Necessários. [PA163.IG102.SP104.SubP102.N102]

CMMI-SE/SW, v1.1
3. Determinar requisitos de recursos, equipamentos e componentes.

[PA163.IG102.SP104.SubP103]
A maioria dos projetos são únicos de alguma maneira e

exigem algum conjunto de ativos únicos para atender os
objetivos do projeto. A determinação e aquisição destes
ativos de uma maneira pontual são cruciais para o sucesso
do projeto. [PA163.IG102.SP104.SubP103.N101]
Itens dependentes do tempo precisam ser identificados

antecipadamente para determinar como serão tratados.
Mesmo quando os ativos necessários não são únicos,
compilar uma lista de todos os recursos, equipamentos e
partes (por exemplo, quantidade de computadores para o
pessoal que trabalhará no projeto, aplicações de software,
espaço de trabalho, etc) oferece um entendimento de
aspectos do escopo de um esforço que passam muitas
vezes despercebidos. [PA163.IG102.SP104.SubP103.N102]
SP 2.5 Planejar os Conhecimentos e Habilidades Necessários

Planejar os conhecimentos e habilidades necessários para a
execução do projeto. [PA163.IG102.SP105]
Veja a área de processo de Treinamento Organizacional para obter

maiores informações sobre informações de conhecimentos e
habilidades a serem incorporadas no plano do projeto. [PA163.IG102.SP105.R101]
O conhecimento utilizado nos projetos envolve o treinamento do

pessoal do projeto e a aquisição de conhecimento de fontes externas.
[PA163.IG102.SP105.N101]
Os requisitos de pessoal são dependentes dos conhecimentos e

habilidades disponíveis para suportar a execução do projeto.
[PA163.IG102.SP105.N102]

1. Inventário das habilidades necessárias [PA163.IG102.SP105.W101]
2. Planos de pessoal e de novas contratações [PA163.IG102.SP105.W103]
3. Bancos de dados (por exemplo, habilidades e treinamento)

[PA163.IG102.SP105.W104]
Sub-práticas
1. Identificar os conhecimentos e habilidades necessários pra
executar o projeto. [PA163.IG102.SP105.SubP101]

CMMI-SE/SW, v1.1
2. Analisar os conhecimentos e habilidades disponíveis.

[PA163.IG102.SP105.SubP102]
3. Selecionar mecanismos para fornecer os conhecimentos e

habilidades necessários. [PA163.IG102.SP105.SubP103]
Exemplos de mecanismos incluem: [PA163.IG102.SP105.SubP103.N101]
• Treinamento In-house (organizacional e do projeto)

• Treinamento externo
• Pessoal e novas contratações
• Aquisição de habilidades externas
A escolha do treinamento in-house ou a alocação de

recursos externos para as habilidades e conhecimentos
necessários é determinada pela disponibilidade de
especialização em treinamento, pelo cronograma do
projeto e objetivos de negócios. [PA163.IG102.SP105.SubP103.N102]
4. Incorporar mecanismos selecionados no plano do projeto.

[PA163.IG102.SP105.SubP104]
SP 2.6 Planejar o Envolvimento dos Stakeholders

Planejar o envolvimento dos stakeholders identificados.
[PA163.IG102.SP106]
Stakeholders são identificados em todas as fases do ciclo de vida do

projeto, através da identificação do tipo de pessoas e funções que
necessitam ser representados no projeto e da descrição da sua
relevância e grau de interação com as atividades específicas do
projeto. Uma matriz bidimensional com os stakeholders em um eixo e
as atividades do projeto no outro é um formato conveniente para
conseguir esta identificação. A relevância do stakeholders para a
atividade em uma fase específica do projeto e a quantidade de
interação esperada, deverão ser mostradas na interseção do eixo das
atividades da fase do projeto com o eixo dos stakeholders.
[PA163.IG102.SP106.N101]

CMMI-SE/SW, v1.1
Para que as contribuições dos stakeholders sejam úteis, uma seleção

cuidadosa dos stakeholders relevantes é necessária. Para cada
atividade principal, identificar os stakeholders que são afetados pela
atividade e aqueles que têm especializações que são necessárias para
se executar a atividade. Esta lista de stakeholders relevantes
provavelmente mudará conforme o projeto progredir nas fases do ciclo
de vida do projeto. É importanto, entretanto, assegurar que os
stakeholders relevantes das fases posteriores do ciclo de vida tiveram
participação antecipada nos requisitos e decisões de design que os
afetam. [PA163.IG102.SP106.N102]
Exemplos do tipo de material que deverá ser incluído em um

plano para interação dos stakeholders incluem:
[PA163.IG102.SP106.N103]
• Lista de todos os stakeholders relevantes

• Justificativas para o envolvimento dos stakeholders
• Papéis e responsabilidades dos stakeholders relevantes
com relação ao projeto, por fase do ciclo de vida do
projeto
• Relacionamentos entre stakeholders
• Importância relativa do stakeholder para o sucesso do
projeto, por fase do ciclo de vida do projeto
• Recursos (por exemplo, treinamento, materiais, tempo,
finanças) necessários para assegurar a interação dos
stakeholders
• Cronograma para as fases de interação de stakeholders
A condução desta prática específica se baseia nas informações

compartilhadas ou trocadas com a prática específica anterior Planejar
os Conhecimentos e Habilidades Necessários. [PA163.IG102.SP106.N104]

1. Plano para o envolvimento dos stakeholders [PA163.IG102.SP106.W101]
SP 2.7 Estabelecer o Plano do Projeto

Estabelecer e manter o conteúdo do plano geral do projeto.
[PA163.IG102.SP107]

O planejamento de engenharia de sistemas detalha as
atividades de trabalho e os produtos de trabalho do esforço
técnico integrado em todo o projeto. [PA163.IG102.SP107.AMP101]

CMMI-SE/SW, v1.1

Exemplos de planos que têm sido utilizados na
comunidade do Departamento de Defesa americano
incluem: [PA163.IG102.SP107.AMP103]
• Plano Mestre Integrado – um plano orientado a

eventos que documenta os atendimentos
significativos com critérios de aprovação/falha
para elementos de negócios e técnicos do
projeto e amarra cada atendimento a um evento
chave do programa.
• Cronograma Mestre Integrado – um cronograma
integrado, com múltiplas camadas e em rede,
das tarefas programadas exigidas para
completar o esforço de trabalho documentado
em um Plano Mestre Integrado relacionado.
• Plano de Gerenciamento de Engenharia de
Sistemas – um plano que detalha o esforço
técnico integrado em todo o projeto.
• Cronograma Mestre de Engenharia de Sistemas –
um cronograma orientado a eventos que contém
uma compilação de atendimentos técnicos
chave, cada qual com critérios mensuráveis,
exigindo que eventos identificados sejam
completados com sucesso.
• Cronograma Detalhado de Engenharia de
Sistemas – um cronograma detalhado,
dependente de prazo, orientado a tarefas, que
associa datas e milestones específicos com o
Cronograma Mestre de Engenharia de Sistemas.

Para software, o documento de planejamento é, muitas
vezes, chamado de: [PA163.IG102.SP107.AMP102]
• Plano de desenvolvimento de software

• Plano de projeto de software
• Plano de software

CMMI-SE/SW, v1.1
Um plano documentado que trata todos os itens relevantes de

planejamento é necessário para a se conseguir um entendimento
mútuo, compromissos e desempenho de indivíduos, grupos e
organizações que devem executar ou suportar os planos. O plano
gerado para o projeto define todos os aspectos do esforço, amarrando-
os de uma maneira lógica: considerações de ciclo de vida do projeto;
tarefas técnicas e gerenciais; orçamentos e cronogramas; milestones;
gerenciamento de dados, identificação de riscos, requisitos de recursos
e habilidades e identificação e interação de stakeholders. Descrições
de infra-estrutura incluem as relações de responsabilidade e autoridade
para a equipe do projeto, o gerenciamento e as organizações de
suporte. [PA163.IG102.SP107.N101]

1. Plano geral do projeto [PA163.IG102.SP107.W101]
SG 3 Obter Compromissos com o Plano
Compromissos com o plano do projeto são estabelecidos e mantidos.

[PA163.IG103]
Para serem eficazes, os planos exigem compromissos daqueles que

são responsáveis pela implementação e suporte do plano. [PA163.IG103.N101]
SP 3.1 Revisar Planos que Afetam o Projeto

Revisar todos os planos que afetam o projeto para o
entendimento dos compromissos do projeto. [PA163.IG103.SP103]
Os planos desenvolvidos dentro de outras áreas de processos

conterão, normalmente, informações semelhantes àquelas do plano
geral do projeto. Estes planos podem fornecer um direcionamento
adicional detalhado e deverão ser compatíveis e suportar o plano geral
do projeto para indicar quem tem a autoridade, responsabilidade,
comunicação e controle. Todos os planos que afetam o projeto deverão
ser revisados para assegurar um entendimento comum do escopo,
objetivos, papéis e relacionamentos que são exigidos para o projeto ser
bem sucedido. Muitos destes planos são descritos pela prática
genérica Planejar o Processo em cada uma das áreas de processos.
[PA163.IG103.SP103.N101]

1. Registro das revisões de planos que afetam o projeto
[PA163.IG103.SP103.W101]

CMMI-SE/SW, v1.1
SP 3.2 Conciliar os Níveis de Trabalho e Recursos

Conciliar o plano do projeto para refletir os recursos
disponíveis e estimados. [PA163.IG103.SP101]
Para obter compromissos dos stakeholders relevantes, é importante

conciliar as diferenças existentes entre os recursos estimados e
disponíveis. Esse conciliação é normalmente conseguida diminuindo ou
postecipando os requisitos de desempenho técnico, negociando mais
recursos, encontrando maneiras de aumentar a produtividade,
alocando recursos externos (outsourcing), ajustando a composição de
habilidades da equipe ou revisando todos os planos que afetam o
projeto ou os cronogramas. [PA163.IG103.SP101.N101]

1. Métodos e correspondentes parâmetros de estimativa (por
exemplo, melhores ferramentas, uso de componentes de
prateleira) revisados [PA163.IG103.SP101.W101]
2. Orçamentos renegociados [PA163.IG103.SP101.W102]
3. Cronogramas revisados [PA163.IG103.SP101.W103]
4. Lista de requisitos revisados [PA163.IG103.SP101.W104]
5. Acordos com stakeholders renegociados [PA163.IG103.SP101.W105]
SP 3.3 Obter Compromissos com o Plano

Obter compromissos dos stakeholders relevantes
responsáveis por executar e suportar a execução do plano.
[PA163.IG103.SP102]
Obter o compromisso envolve a interação entre todos os stakeholders

relevantes internos e externos ao projeto. Os indivíduos ou grupos que
se comprometem deverão ter a confiança de que o trabalho pode ser
executado dentro das restrições de custo, cronograma e desempenho.
Muitas vezes, um compromisso provisional é adequado para permitir
que o esforço comece e possibilitar que sejam feitas pesquisas para
aumentar a confiança até o nível apropriado necessário para se obter
um compromisso completo. [PA163.IG103.SP102.N101]

1. Solicitações de compromissos documentadas [PA163.IG103.SP102.W101]
2. Compromissos documentados [PA163.IG103.SP102.W102]
Sub-práticas
1. Identificar o suporte necessário e negociar compromissos com os
stakeholders relevantes. [PA163.IG103.SP102.SubP101]
CMMI-SE/SW, v1.1
A WBS pode ser utilizada como checklist para assegurar

que foram obtidos compromissos para todas as tarefas.
[PA163.IG103.SP102.SubP101.N101]
O plano para a interação dos stakeholders deverá

identificar todas as partes de onde deverão ser obtidos
compromissos. [PA163.IG103.SP102.SubP101.N102]
2. Documentar todos os compromissos organizacionais, completos e

provisionais, assegurando o nível apropriado de signatários.
[PA163.IG103.SP102.SubP102]
Os compromissos devem ser documentados para

assegurar um entendimento mútuo consistente, assim
como a rastreabilidade e manutenção. Os compromissos
provisionais deverão ser acompanhados de uma descrição
dos riscos associados com o relacionamento.
[PA163.IG103.SP102.SubP102.N101]
3. Revisar compromissos internos com a gerência sênior, conforme

apropriado. [PA163.IG103.SP102.SubP103]
4. Revisar compromissos externos com a gerência sênior, conforme

apropriado. [PA163.IG103.SP102.SubP104]
O gerenciamento pode ter o necessário entendimento e

autoridade para reduzir riscos associados com os
compromissos externos. [PA163.IG103.SP102.SubP104.N101]
5. Identificar compromissos nas interfaces entre os elementos do

projeto e com outros projetos e unidades organizacionais, de
maneira que possam ser monitorados. [PA163.IG103.SP102.SubP105]
Especificações bem definidas de interfaces formam a base

para os compromissos. [PA163.IG103.SP102.SubP105.N101]
Compromisso

planejamento e execução do processo de planejamento do
projeto. [GP103]

CMMI-SE/SW, v1.1
Elaboração:
Esta política estabelece as expectativas organizacionais para a

estimativa dos parâmetros de planejamento, obtenção de
compromissos internos e externos e desenvolvimento do plano para o
gerenciamento do projeto. [PA163.EL101]
Habilitações

Estabelecer e manter o plano para execução do processo de
planejamento do projeto. [GP104]
Elaboração:
Este plano para a execução do processo de planejamento do projeto

difere do plano do projeto descrito nas práticas específicas desta área
de processo. O plano descrito nesta prática genérica tratará do
planejamento geral para todas as práticas específicas desta área de
processo, da estimativa do escopo do projeto até a obtenção de
compromissos com o plano do projeto. Em outras palavras, esta prática
genérica solicita “planejar o plano”. Em contraste, o plano do projeto
descrito nas práticas específicas trata do planejamento para o próprio
esforço do projeto de uma maneira abrangente. [PA163.EL103]

Fornecer recursos adequados para a execução do processo de
planejamento do projeto, desenvolvimento dos produtos de
trabalho e fornecimento dos serviços do processo. [GP105]
Elaboração:
Especializações específicas, equipamentos e recursos podem ser

exigidos para o planejamento do projeto. Especialização específica em
planejamento de projetos pode incluir: [PA163.EL104]
• Pessoal experiente em estimativas

• Pessoal experiente em cronogramas
• Especialistas técnicos nas áreas aplicáveis (por exemplo, domínio
do produto e tecnologia)

CMMI-SE/SW, v1.1
Exemplos de outros recursos fornecidos incluem as seguintes

• Programas de planilhas
• Modelos de estimativas
• Pacotes de planejamento e programação de projetos

fornecimento dos serviços do processo de planejamento do
projeto. [GP106]

Treinar as pessoas na execução e suporte ao processo de
planejamento do projeto, conforme necessário. [GP107]
Elaboração:
• Estimativas
• Orçamentos
• Negociação
• Identificação e análise de riscos
• Gerenciamento de dados
• Planejamento
• Cronogramas
Implementações

planejamento do projeto sob os níveis apropriados de

CMMI-SE/SW, v1.1
Elaboração:
Exemplos de produtos de trabalho colocados sob

• Estrutura de decomposição do trabalho (Work breakdown

structure)
• Plano do projeto
• Plano de gerenciamento de dados
• Plano de envolvimento de stakeholders

de planejamento do projeto, conforme planejado. [GP124]
Elaboração:
Esta prática genérica é diferente do desenvolvimento do plano para o

envolvimento de stakeholders para o próprio projeto, que é coberto
numa prática específica desta área de processo. [PA163.EL111]
Selecionar os stakeholders relevantes a partir dos gerentes sênior,

gerentes de projetos, gerentes funcionais do projeto (por exemplo,
engenharia de sistemas, engenharia de software e outras disciplinas),
engenheiros de software, engenheiros de sistemas, engenheiros de
fábrica, responsáveis pela logística, fornecedores, clientes e outros que
podem ser afetados ou afetar o projeto. [PA163.EL118]
Exemplos de atividades para o envolvimento de stakeholders

• Estabelecer estimativas
• Revisar e resolver questões sobre a completitude e
correção dos riscos do projeto
• Revisar os planos de gerenciamento de dados
• Estabelecer planos de projeto
• Revisar os planos de projeto e resolver as questões sobre
trabalho e recursos

CMMI-SE/SW, v1.1

Monitorar e controlar o processo de planejamento do projeto
contra o plano para execução do processo e tomar as ações
corretivas apropriadas. [GP110]
Elaboração:

• Número de revisões do plano

• Variação de custo, cronograma e esforço por revisão de
plano
Verificações

planejamento do projeto contra sua descrição de processo,
padrões e procedimentos e tratar as não conformidades. [GP113]
Elaboração:
• Estabelecer estimativas
• Desenvolver um plano de projeto
• Obter compromissos ao plano do projeto

[PA163.EL117]
• WBS
• Plano do projeto
• Plano de gerenciamento de dados
• Plano de envolvimento de stakeholders

CMMI-SE/SW, v1.1
GP 2.10 (VE 2) Revisar o Status com o Nível Mais Alto de Gerência

planejamento do projeto com o nível mais alto de gerência e
resolver questões. [GP112]
nível de maturidade 2, mas são exigidas para uma classificação de nível de maturidade 3 e
superiores).

planejamento do projeto. [GP114]

execução do processo de planejamento do projeto para
suportar o uso futuro e a melhoria dos processos e ativos de
processos da organização. [GP117]

CMMI-SE/SW, v1.1
MONITORAMENTO E CONTROLE DO PROJETO

Objetivo
O objetivo do Monitoramento e Controle do Projeto (Project Monitoring

and Control) é 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. [PA162]
Um plano de projeto documentado é a base para 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 nos milestones ou níveis de controle pré-definidos dentro
do cronograma do projeto ou da estrutura de decomposição de trabalho
(WBS). A visibilidade apropriada possibilita a ação corretiva pontual a
ser tomada quando o desempenho desvia significativamente do plano.
Um desvio é significativo se, quando deixado sem resolução, impede
que o projeto atinja seus objetivos. [PA162.N101]
O termo “plano do projeto” é utilizados em todas estas práticas para se

referir ao plano geral para o controle do projeto. [PA162.N102]
Quando o status real se desvia significativamente dos valores

esperados, as ações corretivas são tomadas conforme apropriado.
Estas ações podem exigir o replanejamento, que pode incluir a revisão
do plano original, estabelecimento de novos acordos ou inclusão de
atividades de mitigação de riscos adicionais dentro do plano atual.
[PA162.N103]

maiores informações sobre o plano do projeto, incluindo como ele
especifica o nível apropriado de monitoramento do projeto, as medidas
utilizadas para monitorar o progresso e os riscos conhecidos. [PA162.R101]
Veja a área de processo de Medições e Análises para obter maiores

informações sobre o processo de medição, análise e registro de
informações. [PA162.R102]
136 Nível de Maturidade: 2, Monitoramento e Controle do Projeto

CMMI-SE/SW, v1.1
SG 1 Monitorar o Projeto Contra o Plano [PA162.IG101]
O desempenho e o progresso real do projeto são monitorados contra o

plano do projeto.
SG 2 Gerenciar as Ações Corretivas até o Encerramento [PA162.IG102]
As ações corretivas são gerenciadas até o seu encerramento, quando o

desempenho ou resultados do projeto se desviarem significativamente do
plano.
(A seguinte meta não é exigida para o nível de maturidade 2, mas é exigida para o nível de
SG 1 Monitorar o Projeto Contra o Plano [PA162.IG101]
SP 1.1 Monitorar os Parâmetros de Planejamento do Projeto

SP 1.2 Monitorar os Compromissos
SP 1.3 Monitorar os Riscos do Projeto
SP 1.4 Monitorar o Gerenciamento de Dados
SP 1.5 Monitorar o Envolvimento dos Stakeholders
SP 1.6 Conduzir Revisões de Progresso
SP 1.7 Conduzir Revisões nos Milestones
SG 2 Gerenciar a Ação Corretiva até o Encerramento [PA162.IG102]
SP 2.1 Analisar Questões

SP 2.2 Tomar Ações Corretivas
SP 2.3 Gerenciar as Ações Corretivas

Nível de Maturidade: 2, Monitoramento e Controle do Projeto 137

CMMI-SE/SW, v1.1

GP 2.10 (VE 2) Revisar Status com o Nível Mais Alto de Gerência

SG 1 Monitorar o Projeto Contra o Plano
O desempenho e o progresso real do projeto são monitorados contra o

plano do projeto. [PA162.IG101]
SP 1.1 Monitorar os Parâmetros de Planejamento do Projeto

Monitorar os valores reais dos parâmetros de planejamento do
projeto contra o plano do projeto. [PA162.IG101.SP101]
Os parâmetros de planejamento do projeto constituem os indicadores

típicos do desempenho e progresso do projeto e incluem os atributos
dos produtos de trabalho e tarefas, custo, esforço e cronograma.
Atributos dos produtos de trabalho e tarefas incluem itens como
tamanho, complexidade, peso, formato, encaixe ou funções.
[PA162.IG101.SP101.N101]
O monitoramento normalmente envolve medir os valores reais dos

parâmetros de planejamento do projeto, comparar os valores reais com
os estimados no plano e identificar os desvios significativos. Registrar
os valores reais dos parâmetros de planejamento do projeto inclui
registrar as informações contextuais associadas para auxiliar no
entendimento das medidas. Uma análise do impacto dos desvios
significativos na determinação de quais ações corretivas devem ser
tomadas é feita na segunda meta específica e suas práticas
específicas nesta área de processo. [PA162.IG101.SP101.N102]

1. Registros de desempenho do projeto [PA162.IG101.SP101.W101]
2. Registros de desvios significativos [PA162.IG101.SP101.W102]

CMMI-SE/SW, v1.1
Sub-práticas
1. Monitorar o progresso contra o cronograma. [PA162.IG101.SP101.SubP101]
O monitoramento do progresso normalmente inclui:

[PA162.IG101.SP101.SubP101.N101]
• Medir periodicamente o nível real de atividades e

milestones completados
• Comparar o nível real de atividades e milestones
completados contra o cronograma documentado no plano
do projeto
• Identificar os desvios significativos das estimativas de
cronograma no plano do projeto
2. Monitorar os custos e esforços dispendidos no projeto.
[PA162.IG101.SP101.SubP102]
Monitorar o esforço e o custo normalmente inclui:

[PA162.IG101.SP101.SubP102.N101]
• Medir periodicamente o esforço e custo real dispendido e

o pessoal designado
• Comparar o esforço, custo, pessoal e treinamento reais
com as estimativas e orçamentos documentados no plano
do projeto
• Identificar desvios significativos dos orçamentos no plano
do projeto
3. Monitorar os atributos dos produtos de trabalho e tarefas.
[PA162.IG101.SP101.SubP103]

informações sobre os atributos de produtos de trabalho e tarefas.
[PA162.IG101.SP101.SubP103.R101]
Monitorar os atributos de produtos de trabalho e tarefas

normalmente inclui: [PA162.IG101.SP101.SubP103.N101]
• Medir periodicamente os atributos reais de produtos de

trabalho e tarefas, como tamanho e complexidade (e as
mudanças nestes atributos)
• Comparar os atributos reais de produtos de trabalho e
tarefas (e as mudanças nestes atributos) com as
estimativas documentadas no plano do projeto
• Identificar desvios significativos das estimativas do plano
do projeto
4. Monitorar recursos fornecidos e utilizados. [PA162.IG101.SP101.SubP104]
Veja a área de processo de Planejamento do Projeto para

informações sobre os recursos planejados. [PA162.IG101.SP101.SubP104.R101]

CMMI-SE/SW, v1.1

Exemplos de recursos de engenharia de software
incluem: [PA162.IG101.SP101.SubP104.AMP101]
• Servidores e periféricos
• Redes
• Computadores e periféricos para teste de
software
• Software do ambiente do computador alvo
• Ambiente de engenharia de software (por
exemplo,ferramentas de software)
Exemplos de recursos incluem: [PA162.IG101.SP101.SubP104.N101]
• Recursos físicos
• Computadores, periféricos e software utilizado no
design, manufatura, testes e operação
• Redes
• Ambiente de segurança
• Pessoal do projeto
• Processos
5. Monitorar o conhecimento e habilidades do pessoal do projeto.

[PA162.IG101.SP101.SubP105]

informações sobre o planejamento do conhecimento e habilidades
necessárias para a execução do projeto. [PA162.IG101.SP101.SubP105.R101]
Monitorar o conhecimento e habilidades do pessoal do

projeto normalmente inclui: [PA162.IG101.SP101.SubP105.N101]
• Medir periodicamente a aquisição de conhecimentos e

habilidades pelo pessoal do projeto
• Comparar o treinamento real obtido com o documentado
no plano do projeto
• Identificar desvios significativos das estimativas do plano
do projeto
6. Documentar os desvios significativos dos parâmetros de
planejamento do projeto. [PA162.IG101.SP101.SubP106]

CMMI-SE/SW, v1.1
SP 1.2 Monitorar Compromissos

Monitorar os compromissos contra os identificados no plano
do projeto. [PA162.IG101.SP102]

1. Registros de revisões de compromissos [PA162.IG101.SP102.W101]
Sub-práticas
1. Revisar regularmente os compromissos (externos e internos).
[PA162.IG101.SP102.SubP101]
2. Identificar compromissos que não foram cumpridos ou que correm

um risco significativo de não serem cumpridos. [PA162.IG101.SP102.SubP102]
3. Documentar os resultados das revisões de compromissos.

[PA162.IG101.SP102.SubP103]
SP 1.3 Monitorar os Riscos do Projeto

Monitorar os riscos contra os que foram identificados no plano

maiores informações sobre a identificação de riscos do projeto.
[PA162.IG101.SP103.R101]

maiores informações sobre as atividades de gerenciamento de riscos.
[PA162.IG101.SP103.R102]

1. Registros de monitoramento dos riscos do projeto [PA162.IG101.SP103.W101]
Sub-práticas
1. Revisar periodicamente a documentação dos riscos no contexto do
status atual e circunstâncias do projeto. [PA162.IG101.SP103.SubP101]
2. Revisar a documentação dos riscos, conforme novas informações

se tornem disponíveis, para incorporar as mudanças.
[PA162.IG101.SP103.SubP102]
3. Comunicar o status dos riscos aos stakeholders relevantes.

[PA162.IG101.SP103.SubP103]

CMMI-SE/SW, v1.1
Exemplos de status de riscos incluem:

[PA162.IG101.SP103.SubP103.N101]
• Uma mudança na probabilidade daquele risco ocorrer

• Uma mudança na prioridade dos riscos
SP 1.4 Monitorar o Gerenciamento de Dados

Monitorar o gerenciamento dos dados do projeto contra o
plano do projeto. [PA162.IG101.SP106]
Veja a prática específica Planejar o Gerenciamento de Dados na área

de processo de Planejamento do Projeto para obter maiores
informações sobre como identificar os tipos de dados que deverão ser
gerenciados e como planejar seu gerenciamento. [PA162.IG101.SP106.R101]
Uma vez que os planos para o gerenciamento dos dados do projeto

tenham sido feitos, o gerenciamento daqueles dados deve ser
monitorado para assegurar que os planos sejam cumpridos.
[PA162.IG101.SP106.N101]

1. Registros de gerenciamento de dados [PA162.IG101.SP106.W101]
Sub-práticas
1. Revisar periodicamente as atividades de gerenciamento de dados
contra sua descrição no plano do projeto. [PA162.IG101.SP106.SubP101]
2. Identificar e documentar questões significativas e seus impactos.

[PA162.IG101.SP106.SubP102]
3. Documentar os resultados das revisões das atividades de

gerenciamento de dados. [PA162.IG101.SP106.SubP103]
SP 1.5 Monitorar o Envolvimento dos Stakeholders

Monitorar o envolvimento dos stakeholders contra o plano do
projeto. [PA162.IG101.SP107]
Veja a prática específica Planejar o Envolvimento dos Stakeholders na

área de processo de Planejamento do Projeto para obter maiores
informações sobre como identificar os stakeholders relevantes e
planejar o seu envolvimento apropriado. [PA162.IG101.SP107.R101]

CMMI-SE/SW, v1.1
Uma vez que os stakeholders sejam identificados e a extensão do seu

envolvimento no projeto esteja especificada no planejamento do
projeto, este envolvimento deve ser monitorado para assegurar que as
interações apropriadas estão ocorrendo. [PA162.IG101.SP107.N101]

1. Registros do envolvimento dos stakeholders [PA162.IG101.SP107.W101]
Sub-práticas
1. Revisar periodicamente o status do envolvimento dos
stakeholders. [PA162.IG101.SP107.SubP101]

[PA162.IG101.SP107.SubP102]
3. Documentar os resultados das revisões de status do envolvimento

dos stakeholders. [PA162.IG101.SP107.SubP103]
SP 1.6 Conduzir Revisões de Progresso

Revisar periodicamente o progresso, desempenho e questões
Revisões de progresso são revisões do projeto para manter os

stakeholders informados. Estas revisões de projeto podem ser revisões
informais e não precisam estar explicitamente especificadas nos planos
do projeto. [PA162.IG101.SP104.N101]
Exemplos destas revisões incluem: [PA162.IG101.SP104.N102]
• Revisões com o pessoal

• Revisões com os engenheiros de projeto e de suporte
• Revisões com o gerenciamento

1. Resultados documentados das revisões de projeto
[PA162.IG101.SP104.W101]
Sub-práticas
1. Comunicar regularmente o status de atividades atribuídas e
produtos de trabalho aos stakeholders relevantes.
[PA162.IG101.SP104.SubP101]
Gerentes, membros da equipe, clientes, usuários finais,

fornecedores e outros stakeholders relevantes dentro da
organização são incluídos nas revisões, conforme
apropriado. [PA162.IG101.SP104.SubP101.N101]

CMMI-SE/SW, v1.1
2. Revisar os resultados da coleta e análise de medidas para o

controle do projeto. [PA162.IG101.SP104.SubP102]
Veja a área de processo de Medições e Análises para obter

maiores informações sobre como medir e analisar os dados de
desempenho do projeto. [PA162.IG101.SP104.SubP102.R101]
3. Identificar e documentar questões e desvios significativos do

plano. [PA162.IG101.SP104.SubP103]
4. Documentar solicitações de mudanças e problemas identificados

em quaisquer produtos de trabalho e processos.
[PA162.IG101.SP104.SubP104]

obter maiores informações sobre como as mudanças são
gerenciadas. [PA162.IG101.SP104.SubP104.R101]
5. Documentar os resultados das revisões. [PA162.IG101.SP104.SubP105]
6. Rastrear as solicitações de mudanças e os relatórios de problemas

até o encerramento. [PA162.IG101.SP104.SubP106]
SP 1.7 Conduzir Revisões nos Milestones

Revisar o cumprimento e resultados do projeto nos milestones
selecionados do projeto. [PA162.IG101.SP105]

maiores informações sobre o planejamento de milestones.
[PA162.IG101.SP105.R101]
Revisões de milestones são planejadas durante o planejamento do

projeto e, geralmente, são revisões formais. [PA162.IG101.SP105.N101]

1. Resultados documentados de revisões de milestones
[PA162.IG101.SP105.W101]
Sub-práticas
1. Conduzir revisões em pontos significativos do cronograma do
projeto, como no momento em que etapas selecionadas são
completadas, com os stakeholders relevantes. [PA162.IG101.SP105.SubP101]
Gerentes, membros da equipe, clientes, usuários finais,

fornecedores e outros stakeholders relevantes dentro da
organização são incluídos nas revisões de milestones,
conforme apropriado. [PA162.IG101.SP105.SubP101.N101]

CMMI-SE/SW, v1.1
2. Revisar os compromissos, planos, status e riscos do projeto.

[PA162.IG101.SP105.SubP102]

[PA162.IG101.SP105.SubP103]
4. Documentar os resultados da revisão, itens de ação e decisões.

[PA162.IG101.SP105.SubP104]
5. Rastrear itens de ação até o encerramento. [PA162.IG101.SP105.SubP105]
SG 2 Gerenciar Ações Corretivas até o Encerramento
As ações corretivas são gerenciadas até o encerramento quando o

desempenho ou os resultados do projeto desviarem significativamente do
plano. [PA162.IG102]
SP 2.1 Analisar questões

Coletar e analisar questões e determinar as ações corretivas
necessárias para tratar estas questões. [PA162.IG102.SP101]

1. Lista de questões que precisam de ações corretivas
[PA162.IG102.SP101.W101]
Sub-práticas
1. Reunir questões para análise. [PA162.IG102.SP101.SubP101]
Questões são coletadas a partir de revisões e da execução

de outros processos. [PA162.IG102.SP101.SubP101.N101]

CMMI-SE/SW, v1.1
Exemplos de questões a serem reunidas incluem:

[PA162.IG102.SP101.SubP101.N102]
• Questões descobertas durante a execução de atividades

de verificação e validação
• Desvios significativos nos parâmetros de planejamento
do projeto com relação às estimativas do plano do
projeto
• Compromissos (internos e externos) que não foram
cumpridos
• Mudanças significativas nos status de riscos
• Questões de acesso a dados, coleta, privacidade e
segurança
• Questões de representação ou envolvimento de
stakeholders
2. Analisar as questões para determinar a necessidade de ações

corretivas. [PA162.IG102.SP101.SubP102]

informações sobre critérios de ações corretivas.
[PA162.IG102.SP101.SubP102.R101]
A ação corretiva é exigida quando a questão, se deixada

sem ser resolvida, pode impedir que o projeto atinja seus
objetivos. [PA162.IG102.SP101.SubP102.N101]
SP 2.2 Tomar Ações Corretivas

Tomar ações corretivas sobre as questões identificadas.
[PA162.IG102.SP102]

1. Plano de ações corretivas [PA162.IG102.SP102.W101]
Sub-práticas
1. Determinar e documentar as ações apropriadas necessárias para
tratar as questões identificadas. [PA162.IG102.SP102.SubP101]

maiores informações sobre o plano do projeto, quando o
replanejamento é necessário. [PA162.IG102.SP102.SubP101.R101]

CMMI-SE/SW, v1.1
Exemplos de ações potenciais incluem:

[PA162.IG102.SP102.SubP101.N101]
• Modificar a declaração de trabalho

• Modificar os requisitos
• Revisar estimativas e planos
• Renegociar compromissos
• Adicionar recursos
• Mudar processos
• Revisar riscos do projeto
2. Revisar e obter acordos com os stakeholders relevantes sobre as

ações a serem tomadas. [PA162.IG102.SP102.SubP102]
3. Negociar mudanças nos compromissos internos e externos.

[PA162.IG102.SP102.SubP103]
SP 2.3 Gerenciar as Ações Corretivas

Gerenciar as ações corretivas até o encerramento. [PA162.IG102.SP103]

1. Resultados de ações corretivas [PA162.IG102.SP103.W101]
Sub-práticas
1. Monitorar ações corretivas até que sejam completadas.
[PA162.IG102.SP103.SubP101]
2. Analisar os resultados de ações corretivas para determinar a

eficácia das ações corretivas. [PA162.IG102.SP103.SubP102]
3. Determinar e documentar as ações apropriadas para corrigir os

desvios dos resultados planejados para as ações corretivas.
[PA162.IG102.SP103.SubP103]
Lições aprendidas como resultado da tomada de ações

corretivas podem ser entradas para os processos de
planejamento e de gerenciamento de riscos.
[PA162.IG102.SP103.SubP103.N101]

CMMI-SE/SW, v1.1
Compromisso

planejamento e execução do processo de monitoramento e
controle do projeto. [GP103]
Elaboração:
Esta política estabelece as expectativas organizacionais para monitorar

o desempenho contra o plano do projeto e gerenciar as ações
corretivas até o encerramento, quando o desempenho ou resultados
reais desviarem significativamente do plano. [PA162.EL101]
Habilitações

monitoramento e controle do projeto. [GP104]
Elaboração:
Este plano para execução do processo de monitoramento e controle do

projeto é, normalmente, uma parte do plano do projeto, conforme
descrito na área de processo de Planejamento do Projeto. [PA162.EL102]

monitoramento e controle do projeto, desenvolvimento dos
produtos de trabalho e fornecimento dos serviços do processo.
[GP105]

CMMI-SE/SW, v1.1
Elaboração:

• Sistemas de rastreamento de custos

• Sistemas de relatórios de esforços
• Sistemas de rastreamento de itens de ações
• Programas de gerenciamento de projeto e cronogramas

Atribuir responsabilidades e autoridade para execução do
fornecimento dos serviços do processo de monitoramento e
controle do projeto. [GP106]

Treinar as pessoas para a execução e suporte do processo de
monitoramento e controle do projeto, conforme necessário.
[GP107]
Elaboração:
• Monitoramento e controle de projetos

• Gerenciamento de riscos
• Gerenciamento de dados
Implementações

monitoramento e controle do projeto sob os níveis apropriados
de gerenciamento de configurações. [GP109]

CMMI-SE/SW, v1.1

de monitoramento e controle do projeto, conforme planejado.
[GP124]
Elaboração:
Esta prática genérica é diferente do monitoramento da interação dos

stakeholders do projeto, que é coberta por uma prática específica desta
área de processo. [PA162.EL107]

relevantes incluem: [PA162.EL108]
• Analisar o projeto contra o plano

• Revisar compromissos e resolver questões
• Revisar os riscos do projeto
• Revisar as atividades de gerenciamento de dados
• Revisar o progresso do projeto
• Gerenciar ações corretivas até o encerramento

Monitorar e controlar o processo de monitoramento e controle
do projeto contra o plano para a execução do processo e tomar
as ações corretivas apropriadas. [GP110]
Elaboração:

• Quantidade de ações corretivas abertas e encerradas

• Datas dos milestones do projeto (por exemplo, planejadas
versus reais e milestones que não foram cumpridos)
• Quantidade e tipos de revisões executadas
• Revisar o cronograma (planejado versus real e datas alvo
que não foram cumpridas)

CMMI-SE/SW, v1.1

monitoramento e controle do projeto contra sua descrição de
processo, padrões, procedimentos e tratar as não
conformidades. [GP113]
Elaboração:
• Monitorar o desempenho do projeto contra o plano do

projeto
• Gerenciar as ações corretivas até o encerramento

[PA162.EL109]
• Registros de desempenho do projeto

• Resultados de revisões do projeto
GP 2.10 (VE 2) Revisar Status com o Nível Mais Alto de Gerência

monitoramento e controle do projeto com o nível mais alto de
gerência e resolver questões. [GP112]
superiores).

monitoramento e controle do projeto. [GP114]

CMMI-SE/SW, v1.1

e informações de melhorias derivadas do planejamento e
execução do processo de monitoramento e controle do projeto
para suportar o uso futuro e melhorias nos processos e ativos
de processos da organização. [GP117]

CMMI-SE/SW, v1.1
GERENCIAMENTO DE ACORDOS COM FORNECEDORES

Objetivo
O objetivo do Gerenciamento de Acordos com Fornecedores (Supplier

Agreement Management) é gerenciar a aquisição de produtos de
fornecedores para os quais existe um acordo formal. [PA166]
A área de processo de Gerenciamento de Acordos com Fornecedores

envolve: [PA166.N104]
• 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
Esta área de processo basicamente se aplica à aquisição de produtos

e componentes de produtos que são entregues ao cliente do projeto.
Para minimizar os riscos do projeto, esta área de processo também
pode ser aplicada à aquisição de produtos e componentes de produtos
significativos que não serão entregues ao cliente do projeto (por
exemplo, ferramentas de desenvolvimento e ambientes de testes).
[PA166.N105]
Esta área de processo não trata diretamente as situações nas quais o

fornecedor está integrado à equipe do projeto (por exemplo, equipes
integradas de produtos). Normalmente, estas situações são tratadas
por outros processos ou funções, possivelmente externos ao projeto,
embora algumas das práticas específicas desta área de processo
possam ser úteis no gerenciamento do acordo formal com este tipo de
fornecedor. [PA166.N106]
Fornecedores podem tomar diferentes formas, dependendo das

necessidades do negócio, incluindo fornecedores in-house (isto é,
fornecedores que pertencem à mesma organização, mas são externos
ao projeto), fábricas e laboratórios e fornecedores comerciais. [PA166.N103]
Veja a definição de “fornecedor” no Apêndice B, o glossário. [PA166.N107]
Nível de Maturidade: 2, Gerenciamento de Acordos com Fornecedores 153

CMMI-SE/SW, v1.1
Um acordo formal é qualquer acordo legal entre a organização

(representando o projeto) e o fornecedor. Este acordo pode ser um
contrato, uma licença ou uma minuta de acordo. O produto adquirido é
entregue ao projeto pelo fornecedor e se torna parte dos produtos
entregues ao cliente. [PA166.N101]
Veja no Capítulo 3 uma explicação sobre como a palavra “produto” é

utilizada no CMMI Product Suite. [PA166.N108]

obter maiores informações sobre como monitorar projetos e tomar as
ações corretivas. [PA166.R101]

maiores informações sobre como definir requisitos. [PA166.R102]

maiores informações sobre como gerenciar requisitos, incluindo a
rastreabilidade dos requisitos para produtos adquiridos de
fornecedores. [PA166.R103]

informações sobre como determinar os produtos e componentes de
produtos que podem ser adquiridos de fornecedores. [PA166.R104]
SG 1 Estabelecer Acordos com os Fornecedores [PA166.IG101]
Acordos com os fornecedores são estabelecidos e mantidos.
SG 2 Satisfazer os Acordos com Fornecedores [PA166.IG102]
Acordos com fornecedores são satisfeitos pelo projeto e pelo fornecedor.
154 Nível de Maturidade: 2, Gerenciamento de Acordos com Fornecedores

CMMI-SE/SW, v1.1
SG 1 Estabelecer Acordos com Fornecedores [PA166.IG101]
SP 1.1 Determinar o Tipo de Aquisição

SP 1.2 Selecionar Fornecedores
SP 1.3 Estabelecer Acordos com Fornecedores
SG 2 Satisfazer Acordos com Fornecedores [PA166.IG102]
SP 2.1 Revisar Produtos de Prateleira

SP 2.2 Executar o Acordo com o Fornecedor
SP 2.3 Aceitar o Produto Adquirido
SP 2.4 Fazer a Transição dos Produtos


SG 1 Estabelecer Acordos com Fornecedores
Acordos com fornecedores são estabelecidos e mantidos. [PA166.IG101]

CMMI-SE/SW, v1.1
SP 1.1 Determinar o Tipo de Aquisição

Determinar o tipo de aquisição para cada produto ou
componente de produto a ser adquirido. [PA166.IG101.SP101]

informações sobre como identificar os produtos e componentes de
produtos a serem adquiridos. [PA166.IG101.SP101.R101]
Existem muitos tipos diferentes de aquisições que podem ser utilizados

para adquirir produtos e componentes de produtos que serão utilizados
por um projeto. [PA166.IG101.SP101.N106]
Exemplos de tipos de aquisições incluem: [PA166.IG101.SP101.N107]
• Compra de produtos comerciais “de prateleira”

(commercial off-the-shelf - COTS)
• Obtenção de produtos através de um acordo contratual
• Obter produtos de um fornecedor interno
• Obter produtos do cliente
• Combinar algumas das alternativas anteriores (por
exemplo, contratar uma modificação em um produto “de
prateleira” ou fazer com que outra parte do
empreendimento de negócios desenvolva os produtos em
cooperação com um fornecedor externo)

1. Lista dos tipos de aquisições que serão utilizados por todos os
produtos e componentes de produtos a serem adquiridos
[PA166.IG101.SP101.W101]
SP 1.2 Selecionar Fornecedores

Selecionar fornecedores com base na avaliação de sua
capacidade de atender os requisitos especificados e os
critérios estabelecidos. [PA166.IG101.SP102]
Veja a área de processo de Análise de Decisões e Resoluções para

obter maiores informações sobre abordagens formais de avaliação que
podem ser utilizadas para selecionar fornecedores. [PA166.IG101.SP102.R101]

maiores informações sobre requisitos especificados. [PA166.IG101.SP102.R102]
Critérios deverão ser estabelecidos para tratar os fatores que são

importantes para o projeto. [PA166.IG101.SP102.N101]

CMMI-SE/SW, v1.1
Exemplos de fatores incluem: [PA166.IG101.SP102.N103]
• Localização geográfica do fornecedor

• Registros de desempenho do fornecedor em trabalho
semelhante
• Habilitações de engenharia
• Pessoal e recursos disponíveis para executar o trabalho
• Experiência anterior em aplicações semelhantes

1. Lista de fornecedores candidatos [PA166.IG101.SP102.W101]
2. Lista de fornecedores preferenciais [PA166.IG101.SP102.W102]
3. Justificativa para a seleção dos fornecedores [PA166.IG101.SP102.W103]
4. Vantagens e desvantagens dos fornecedores candidatos

[PA166.IG101.SP102.W104]
5. Critérios de avaliação [PA166.IG101.SP102.W105]
6. Materiais de solicitação e requisitos [PA166.IG101.SP102.W106]
Sub-práticas
1. Estabelecer e documentar os critérios para a avaliação dos
fornecedores potenciais. [PA166.IG101.SP102.SubP101]
2. Identificar os fornecedores potenciais e distribuir os materiais de

solicitação e requisitos para eles. [PA166.IG101.SP102.SubP102]
3. Avaliar as propostas de acordo com os critérios de avaliação.

[PA166.IG101.SP102.SubP103]
4. Avaliar os riscos associados com cada fornecedor proposto.

[PA166.IG101.SP102.SubP104]

maiores informações sobre como avaliar os riscos do projeto.
[PA166.IG101.SP102.SubP104.R101]
5. Avaliar a capacidade dos fornecedores propostos em executar o

trabalho. [PA166.IG101.SP102.SubP105]

CMMI-SE/SW, v1.1
Exemplos de métodos para avaliar a capacidade dos

fornecedores propostos em executar o trabalho incluem:
[PA166.IG101.SP102.SubP105.N101]
• Avaliação da experiência anterior em aplicações

semelhantes
• Avaliação de desempenho anterior em trabalho
semelhante
• Avaliação das habilidades de gerenciamento
• Avaliações de habilidades
• Avaliação de pessoal disponível para executar o trabalho
• Avaliação de locais e recursos disponíveis
• Avaliação da capacidade do projeto em trabalhar com o
fornecedor proposto
6. Selecionar o fornecedor. [PA166.IG101.SP102.SubP106]
SP 1.3 Estabelecer Acordos com Fornecedores

Estabelecer e manter acordos formais com o fornecedor.
[PA166.IG101.SP103]
Um acordo formal é qualquer acordo legal entre a organização

(representando o projeto) e o fornecedor. Este acordo pode ser um
contrato, uma licença ou uma minuta de acordo. [PA166.IG101.SP103.N101]

1. Declarações de trabalho [PA166.IG101.SP103.W101]
2. Contratos [PA166.IG101.SP103.W102]
3. Minutas de acordos [PA166.IG101.SP103.W103]
4. Acordos de licenciamento [PA166.IG101.SP103.W104]
Sub-práticas
1. Revisar os requisitos a serem atendidos pelo fornecedor para
refletir as negociações feitas com o fornecedor, quando
necessário. [PA166.IG101.SP103.SubP101]
Veja a área de processo de Desenvolvimento de Requisitos para

obter maiores informações sobre como revisar requisitos.
[PA166.IG101.SP103.SubP101.R101]

CMMI-SE/SW, v1.1
Veja a área de processo de Gerenciamento de Requisitos para

obter maiores informações sobre como gerenciar as mudanças
nos requisitos. [PA166.IG101.SP103.SubP101.R102]
2. Documentar o que o projeto fornecerá para o fornecedor.

[PA166.IG101.SP103.SubP102]
Inclui: [PA166.IG101.SP103.SubP102.N101]
• Recursos preparados para o projeto

• Documentação
• Serviços
3. Documentar o acordo com o fornecedor. [PA166.IG101.SP103.SubP103]
O acordo com o fornecedor deverá incluir uma declaração

de trabalho, uma especificação, termos e condições, uma
lista de itens a serem entregues, um cronograma, um
orçamento e um processo definido de aceitação.
[PA166.IG101.SP103.SubP103.N101]
Esta sub-prática normalmente inclui: [PA166.IG101.SP103.SubP103.N102]
• Estabelecer a declaração de trabalho, a especificação,

termos e condições, lista de itens a serem entregues,
cronograma, orçamento e o processo de aceitação
• Identificar quem serão, pelo projeto e pelo fornecedor, os
responsáveis e autorizados a fazer mudanças no acordo
com o fornecedor
• Identificar como as mudanças nos requisitos e mudanças
no acordo com o fornecedor são determinadas,
comunicadas e tratadas
• Identificar padrões e procedimentos que serão seguidos
• Identificar dependências críticas entre o projeto e o
fornecedor
• Identificar o tipo e profundidade de supervisão de projeto
do fornecedor, procedimentos e critérios de avaliação que
serão utilizados no monitoramento do desempenho do
fornecedor
• Identificar os tipos de revisões que serão conduzidas com
o fornecedor
• Identificar as responsabilidades do fornecedor pela
execução da manutenção e suporte dos produtos
adquiridos
• Identificar a garantia, propriedade e direitos de uso dos
produtos adquiridos
• Identificar os critérios de aceitação

CMMI-SE/SW, v1.1
4. Assegurar que todas as partes do acordo entendem e concordam

com todos os requisitos antes de implementar o acordo.
[PA166.IG101.SP103.SubP104]
5. Revisar o acordo com o fornecedor, conforme necessário.

[PA166.IG101.SP103.SubP105]
6. Revisar os planos e compromissos do projeto, conforme

necessário, para refletir o acordo com o fornecedor.
[PA166.IG101.SP103.SubP106]

para obter maiores informações sobre como revisar o plano do
projeto. [PA166.IG101.SP103.SubP106.R101]
SG 2 Satisfazer os Acordos com Fornecedores
Acordos com os fornecedores são satisfeitos pelo projeto e pelo

fornecedor. [PA166.IG102]
SP 2.1 Revisar Produtos de Prateleira

Revisar produtos de prateleira candidatos para assegurar que
eles satisfazem os requisitos especificados que estão cobertos
por um acordo com o fornecedor. [PA166.IG102.SP101]
No caso de serem desejados produtos de prateleira, o cuidado na

avaliação e seleção destes produtos e do fornecedor pode ser crítico
para o projeto. [PA166.IG102.SP101.N101]

1. Estudos comerciais [PA166.IG102.SP101.W101]
2. Listas de preços [PA166.IG102.SP101.W102]
3. Critérios de avaliação [PA166.IG102.SP101.W103]
4. Relatórios de desempenho do fornecedor [PA166.IG102.SP101.W104]
5. Revisões de produtos de prateleira [PA166.IG102.SP101.W105]
Sub-práticas
1. Desenvolver critérios para a avaliação de produtos de prateleira.
[PA166.IG102.SP101.SubP101]
2. Avaliar os produtos de prateleira candidatos contra os requisitos e

critérios associados. [PA166.IG102.SP101.SubP102]

CMMI-SE/SW, v1.1
Veja a área de processo de Desenvolvimento de Requisitos para

obter maiores informações sobre os requisitos que serão utilizados
para avaliar os produtos candidatos. [PA166.IG102.SP101.SubP102.R101]
Estes requisitos tratam o seguinte: [PA166.IG102.SP101.SubP102.N101]
• Funcionalidade, desempenho, qualidade e confiabilidade

• Termos e condições de garantias para os produtos
• Riscos
• Responsabilidades dos fornecedores pela execução de
manutenção e suporte para os produtos
3. Avaliar o impacto dos produtos de prateleira candidatos nos planos
e compromissos do projeto. [PA166.IG102.SP101.SubP103]
Avaliar de acordo com: [PA166.IG102.SP101.SubP103.N101]
• Custo dos produtos de prateleira

• Custo e esforço para incorporar os produtos de prateleira
ao projeto
• Requisitos de segurança
• Benefícios e impactos que podem resultar de futuras
liberações do produto
Futuras liberações do produto podem fornecer recursos

adicionais que suportam as melhorias planejadas ou
previstas para o projeto, mas pode também ocorrer que o
fornecedor deixe de fornecer suporte para a versão do
produto que está sendo adquirida pelo projeto.
[PA166.IG102.SP101.SubP103.N102]
4. Analisar o desempenho e capacidade de entrega do fornecedor.

[PA166.IG102.SP101.SubP104]
5. Identificar riscos associados com o produto de prateleira

selecionado e o acordo com o fornecedor. [PA166.IG102.SP101.SubP105]

maiores informações sobre como identificar os riscos do projeto.
[PA166.IG102.SP101.SubP105.R102]

maiores informações sobre como identificar os riscos do projeto.
[PA166.IG102.SP101.SubP105.R101]
6. Selecionar o produto de prateleira a ser adquirido.

[PA166.IG102.SP101.SubP106]

CMMI-SE/SW, v1.1
Em alguns casos, a seleção de produtos de prateleira pode

exigir um acordo com o fornecedor, além dos acordos de
licença do produto. [PA166.IG102.SP101.SubP106.N101]
Exemplos de acordos com fornecedores de produtos de

prateleira incluem: [PA166.IG102.SP101.SubP106.N102]
• Descontos para compras em grandes quantidades

• Cobertura dos stakeholders relevantes sob o acordo de
licença, incluindo os fornecedores do projeto, membros
da equipe e clientes do projeto
• Planos para futuras melhorias
• Suporte on-site, como respostas a questionamentos e a
problemas relatados
• Habilidades adicionais que não estão no produto
• Suporte de manutenção, incluindo suporte após o
produto não estar mais disponível para venda
7. Planejar a manutenção do produto de prateleira.

[PA166.IG102.SP101.SubP107]
SP 2.2 Executar o Acordo com o Fornecedor

Executar atividades com o fornecedor conforme especificado
no acordo com o fornecedor. [PA166.IG102.SP102]

obter maiores informações sobre como monitorar projetos e tomar as
ações corretivas. [PA166.IG102.SP102.R101]

1. Relatórios de progresso e medidas de desempenho do fornecedor
[PA166.IG102.SP102.W101]
2. Materiais de revisão e relatórios do fornecedor [PA166.IG102.SP102.W103]
3. Itens de ação rastreados até o encerramento [PA166.IG102.SP102.W104]
4. Documentação de entregas de produtos e documentos

[PA166.IG102.SP102.W105]
Sub-práticas
1. Monitorar o progresso e desempenho do fornecedor (cronograma,
esforço, custo e desempenho técnico), conforme definido no
acordo com o fornecedor. [PA166.IG102.SP102.SubP101]

CMMI-SE/SW, v1.1
2. Monitorar processos selecionados do fornecedor e tomar as ações

corretivas quando necessário. [PA166.IG102.SP102.SubP102]
Exemplos de processos a serem monitorados são a

garantia da qualidade e o gerenciamento de
configurações. [PA166.IG102.SP102.SubP102.N101]
3. Conduzir revisões com o fornecedor conforme especificado no


para obter maiores informações sobre como conduzir revisões.
[PA166.IG102.SP102.SubP103.R101]
Revisões cobrem revisões formais e informais e incluem:

[PA166.IG102.SP102.SubP103.N101]
• Preparar para a revisão

• Assegurar que os stakeholders relevantes participarão
• Conduzir a revisão
• Identificar, documentar e rastrear todos os itens de ação
até o encerramento
• Preparar e distribuir aos stakeholders relevantes um
relatório de resumo da revisão
4. Conduzir revisões técnicas com o fornecedor conforme definido no
Revisões técnicas normalmente incluem:

[PA166.IG102.SP102.SubP104.N101]
• Fornecer ao fornecedor a visibilidade das necessidades e

desejos dos clientes e usuários finais do projeto, conforme
apropriado
• Revisar as atividades técnicas do fornecedor e verificar se
a interpretação e implementação do fornecedor dos
requisitos estão consistentes com a interpretação do
projeto
• Assegurar que os compromissos técnicos estão sendo
atendidos e que as questões técnicas estão sendo
comunicadas e resolvidas de uma maneira pontual
• Obter informações técnicas sobre os produtos do
fornecedor
• Fornecer informações técnicas apropriadas e suporte ao
fornecedor
5. Conduzir revisões de gerenciamento com o fornecedor conforme
definido no acordo com o fornecedor. [PA166.IG102.SP102.SubP105]

CMMI-SE/SW, v1.1
Revisões de gerenciamento normalmente incluem:

[PA166.IG102.SP102.SubP105.N101]
• Revisar dependências críticas

• Revisar os riscos do projeto que envolvem o fornecedor
• Revisar o cronograma e o orçamento
Revisões técnicas e de gerenciamento podem ser

coordenadas e feitas conjuntamente. [PA166.IG102.SP102.SubP105.N102]
6. Usar os resultados de revisões para melhorar o desempenho do

fornecedor e estabelecer e apoiar relacionamentos de longo prazo
com os fornecedores preferenciais. [PA166.IG102.SP102.SubP106]
7. Monitorar os riscos que envolvem o fornecedor e tomar as ações

corretivas, conforme necessário. [PA166.IG102.SP102.SubP107]

para obter maiores informações sobre monitoramento dos riscos
do projeto. [PA166.IG102.SP102.SubP107.R101]
8. Revisar o acordo com o fornecedor e os planos do projeto e

cronogramas, conforme necessário. [PA166.IG102.SP102.SubP108]
SP 2.3 Aceitar o Produto Adquirido

Assegurar que o acordo com o fornecedor foi satisfeito antes
de aceitar o produto adquirido. [PA166.IG102.SP103]
Revisões e testes de aceitação e auditorias de configuração deverão

ser executadas antes de se aceitar o produto, conforme definido no
acordo com o fornecedor. [PA166.IG102.SP103.N101]

1. Procedimentos de testes de aceitação [PA166.IG102.SP103.W101]
2. Resultados de testes de aceitação [PA166.IG102.SP103.W102]
3. Relatórios de discrepâncias ou planos de ações corretivas

[PA166.IG102.SP103.W103]
Sub-práticas
1. Definir os procedimentos de aceitação. [PA166.IG102.SP103.SubP101]
2. Revisar e obter o acordo com os stakeholders relevantes sobre os

procedimentos de aceitação antes da revisão ou teste de
aceitação. [PA166.IG102.SP103.SubP102]
3. Verificar se os produtos adquiridos satisfazem seus requisitos.

[PA166.IG102.SP103.SubP103]

CMMI-SE/SW, v1.1
Veja a área de processo de Verificação para obter maiores

informações sobre a verificação de produtos.
[PA166.IG102.SP103.SubP103.R101]
4. Confirmar se os compromissos não técnicos associados com o

produto de trabalho adquirido foram satisfeitos. [PA166.IG102.SP103.SubP104]
Isto pode incluir confirmar se a licença, garantia,

propriedade, direito de uso e acordos de suporte e
manutenção apropriados estão presentes e se todos os
materiais de suporte foram recebidos.
[PA166.IG102.SP103.SubP104.N101]
5. Documentar os resultados da revisão ou teste de aceitação.

[PA166.IG102.SP103.SubP105]
6. Estabelecer e obter o acordo do fornecedor sobre um plano de

ação para quaisquer produtos de trabalho adquiridos que não
passem na revisão ou teste de aceitação. [PA166.IG102.SP103.SubP106]
7. Identificar, documentar e rastrear os itens de ação até seu

encerramento. [PA166.IG102.SP103.SubP107]

para obter maiores informações sobre o rastreamento de itens de
ação. [PA166.IG102.SP103.SubP107.R101]
SP 2.4 Fazer a Transição dos Produtos

Fazer a transição dos produtos adquiridos do fornecedor para
o projeto. [PA166.IG102.SP104]
Antes que os produtos adquiridos sejam transferidos para o projeto

para integração, um planejamento e avaliação apropriados deverão
ocorrer para assegurar uma transição tranqüila. [PA166.IG102.SP104.N101]
Veja a área de processo de Integração de Produtos para obter maiores

informações sobre a integração dos produtos adquiridos.
[PA166.IG102.SP104.N101.R101]

1. Planos de transição [PA166.IG102.SP104.W101]
2. Relatórios de treinamento [PA166.IG102.SP104.W102]
3. Relatórios de suporte e manutenção [PA166.IG102.SP104.W103]

CMMI-SE/SW, v1.1
Sub-práticas
1. Assegurar que existem recursos apropriados para receber,
armazenar, utilizar e manter os produtos adquiridos.
[PA166.IG102.SP104.SubP101]
2. Assegurar que o treinamento apropriado foi fornecido para os

envolvidos em receber, armazenar, utilizar e manter os produtos
adquiridos. [PA166.IG102.SP104.SubP102]
3. Assegurar que a armazenagem, distribuição e utilização dos

produtos adquiridos estão sendo feitas de acordo com os termos e
condições especificados no acordo com o fornecedor ou na licença
de uso. [PA166.IG102.SP104.SubP103]
Compromisso

planejamento e execução do processo de gerenciamento de
acordos com fornecedores. [GP103]
Elaboração:

estabelecimento, manutenção e satisfação dos acordos com os
fornecedores. [PA166.EL101]
Habilitações

gerenciamento de acordos com fornecedores. [GP104]

CMMI-SE/SW, v1.1
Elaboração:
Normalmente, partes deste plano para a execução do processo de

gerenciamento de acordos com fornecedores são parte do plano do
projeto, conforme descrito na área de processo de Planejamento do
Projeto. Entretanto, muitas vezes, algumas partes do plano residem
fora do projeto com um grupo independente, como um gerenciamento
de contratos. [PA166.EL110]

gerenciamento de acordos com fornecedores,
desenvolvimento dos produtos de trabalho e fornecimento dos
serviços do processo. [GP105]
Elaboração:

• Listas de fornecedores preferenciais

• Programas de rastreamento de requisitos
• Programas de gerenciamento de projetos e cronogramas

fornecimento dos serviços do processo de gerenciamento de
acordos com fornecedores. [GP106]

gerenciamento de acordos com fornecedores, conforme
necessário. [GP107]

CMMI-SE/SW, v1.1
Elaboração:
• Regulamentos e práticas de negócios relacionadas com a

negociação e o trabalho com fornecedores
• Planejamento e preparação da aquisição
• Aquisição de produtos de prateleira
• Avaliação e seleção de fornecedores
• Negociação e resolução de conflitos
• Gerenciamento de fornecedores
• Teste e transição de produtos adquiridos
• Recebimento, armazenagem, utilização e manutenção de
produtos adquiridos
Implementações

gerenciamento de acordos com fornecedores sob os níveis
apropriados de gerenciamento de configurações. [GP109]
Elaboração:
Exemplos de produtos de trabalho sob gerenciamento de

configurações incluem: [PA166.EL104]
• Declarações de trabalho
• Acordos com fornecedores
• Minutas de acordos
• Sub-contratos
• Listas de fornecedores preferenciais

de gerenciamento de acordos com fornecedores, conforme
planejado. [GP124]

CMMI-SE/SW, v1.1
Elaboração:
Exemplos de atividades de envolvimento de stakeholders

• Estabelecimento de critérios para a avaliação de

fornecedores potenciais
• Revisão de fornecedores potenciais
• Estabelecimento de acordos com fornecedores
• Resolução de questões com fornecedores
• Revisão do desempenho de fornecedores

Monitorar e controlar o processo de gerenciamento de acordos
com fornecedores contra o plano para a execução do processo
e tomar as ações corretivas apropriadas. [GP110]
Elaboração:

• Quantidade de mudanças feitas nos requisitos para o

fornecedor
• Variação de custo e cronograma por acordo com
fornecedor
Verificações

gerenciamento de acordos com fornecedores contra sua
descrição de processo, padrões e procedimentos e tratar as
não conformidades. [GP113]

CMMI-SE/SW, v1.1
Elaboração:
• Estabelecimento e manutenção de acordos com

fornecedores
• Satisfação de acordos com fornecedores

[PA166.EL108]
• Plano de Gerenciamento de Acordos com Fornecedores

• Acordos com Fornecedores

gerenciamento de acordos com fornecedores com o nível mais
alto de gerência e resolver questões. [GP112]
superiores).
O processo é institucionalizado com um processo definido.

gerenciamento de acordos com fornecedores. [GP114]

execução do processo de gerenciamento de acordos com
fornecedores para suportar o uso futuro e a melhoria dos
processos e ativos de processos da organização. [GP117]

CMMI-SE/SW, v1.1
MEDIÇÕES E ANÁLISES
Objetivo
O objetivo das Medições e Análises é desenvolver e sustentar a

capacidade de medições que é utilizada para suportar as necessidades
de gerenciamento de informações. [PA154]
A área de processo de Medições e Análises envolve o seguinte:

[PA154.N101]
• Especificar os objetivos de medições e análises, de forma que

estes estejam alinhados com as necessidades e objetivos de
informações identificados
• 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
A integração das atividades de medições e análises nos processos do

projeto suportam o seguinte: [PA154.N102]
• Planejamento e estimativas objetivos

• Rastreamento do desempenho real contra os planos e objetivos
estabelecidos
• Identificação e resolução de questões relacionadas a processos
• Fornecimento de uma base para a incorporação das medições em
outros processos no futuro
A equipe necessária para implementar uma capacidade de medições

pode pertencer ou não a um programa separado da organização. A
capacidade de medições pode estar integrada em projetos individuais
ou outras funções organizacionais (como por exemplo, a Garantia da
Qualidade). [PA154.N103]
Nível de Maturidade: 2, Medições e Análises 171

CMMI-SE/SW, v1.1
O foco inicial das atividades de medições é o projeto. Entretanto, uma

capacidade de medições pode se provar útil para tratar as
necessidades de informações de toda a organização ou
empreendimento. [PA154.N104]
Os projetos pode decidir armazenar dados e resultados específicos do

projeto em um repositório específico. Quando os dados são
compartilhados mais amplamente entre projetos, estes dados podem
ficar residentes em um repositório de medições da organização.
[PA154.N105]

maiores informações sobre estimativa de atributos do projeto e outras
necessidades de informações de planejamento. [PA154.R101]

obter maiores informações sobre monitoramento das necessidades de
informações do desempenho do projeto. [PA154.R102]

obter maiores informações sobre o gerenciamento de produtos de
trabalho de medições. [PA154.R103]

maiores informações sobre o atendimento dos requisitos de clientes e
necessidades de informações relacionadas. [PA154.R104]

maiores informações sobre a manutenção da rastreabilidade dos
requisitos e necessidades de informações relacionadas. [PA154.R105]
Veja a área de processo de Definição do Processo Organizacional para

obter maiores informações sobre o estabelecimento do repositório de
medições da organização. [PA154.R106]
Veja a área de processo de Gerenciamento Quantitativo do Projeto

para obter maiores informações sobre o entendimento das variações e
o uso apropriado de técnicas de análises estatísticas. [PA154.R107]
SG 1 Alinhar as Atividades de Medições e Análises [PA154.IG101]
Os objetivos e atividades de medições são alinhados com as necessidades

e objetivos de informações identificados.
172 Nível de Maturidade: 2, Medições e Análises

CMMI-SE/SW, v1.1
SG 2 Fornecer Resultados de Medições [PA154.IG102]
Os resultados de medições que tratam as necessidades e objetivos de

informações identificados são fornecidos.
SG 1 Alinhar as Atividades de Medições e Análises [PA154.IG101]
SP 1.1 Estabelecer Objetivos de Medições

SP 1.2 Especificar Medidas
SP 1.3 Especificar Procedimentos de Coleta e Armazenagem de Dados
SP 1.4 Especificar Procedimento de Análises
SG 2 Fornecer Resultados de Medições [PA154.IG102]
SP 2.1 Coletar Dados de Medições

SP 2.2 Analisar Dados de Medições
SP 2.3 Armazenar Dados e Resultados
SP 2.4 Comunicar Resultados


CMMI-SE/SW, v1.1

SG 1 Alinhar Atividade de Medições e Análises
Os objetivos e atividades de medições são alinhados com as necessidades

e objetivos de informações identificados. [PA154.IG101]
As práticas específicas cobertas por esta meta específica podem ser

atendidas ao mesmo tempo ou em qualquer ordem: [PA154.IG101.N101]
• Quando estão estabelecendo os objetivos de medições, os experts

muitas vezes pensam antecipadamente nos critérios necessários
para especificar procedimentos de medições e análises. Eles
também pensam, ao mesmo tempo, nas restrições impostas pelos
procedimentos de coleta e armazenagem de dados.
• Freqüentemente, é importante especificar as análises essenciais
que serão feitas antes de tratar os detalhes da especificação de
medições, coleta de dados e armazenagem.
SP 1.1 Estabelecer Objetivos de Medições

Estabelecer e manter os objetivos de medições que são
derivados das necessidades e objetivos de informações
identificados. [PA154.IG101.SP101]
Os objetivos de medições documentam os propósitos para os quais as

medições e análises são feitas, e especificam os tipos de ações que
podem ser tomadas com base nos resultados das análises dos dados.
[PA154.IG101.SP101.N101]
As fontes para os objetivos de medições podem ser as necessidades

de gerenciamento, técnicas, do projeto, do produto ou de
implementação do processo. [PA154.IG101.SP101.N102]
Os objetivos de medições podem ser restringidos pelos processos

existentes, recursos disponíveis ou outras considerações de medições.
É necessário julgar se o valor dos resultados será proporcional aos
recursos dedicados a este trabalho. [PA154.IG101.SP101.N103]

CMMI-SE/SW, v1.1
Modificações em necessidades e objetivos de informações

identificados podem, por sua vez, ser indicadas em conseqüência do
processo e dos resultados das medições e análises. [PA154.IG101.SP101.N104]
Fontes de necessidades de informações e objetivos podem incluir:

[PA154.IG101.SP101.N105]
• Planos de projeto
• Monitoramento do desempenho do projeto
• Entrevistas com gerentes e outros que tenham necessidades de
informações
• Objetivos de gerenciamento estabelecidos
• Planos estratégicos
• Planos de negócios
• Requisitos formais ou obrigações contratuais
• Problemas técnicos ou de gerenciamento recorrentes ou
perturbadores de outra forma
• Experiência de outros projetos ou entidades organizacionais
• Benchmarks de outras indústrias
• Planos de melhoria de processos

maiores informações sobre estimativa de atributos do projeto e outras
necessidades de informações de planejamento. [PA154.IG101.SP101.N105.R101]

obter maiores informações sobre necessidades de informações sobre o
desempenho do projeto. [PA154.IG101.SP101.N105.R102]

maiores informações sobre o atendimento dos requisitos de clientes e
necessidades de informações relacionadas. [PA154.IG101.SP101.N105.R103]

maiores informações sobre a manutenção da rastreabilidade dos
requisitos e necessidades de informações relacionadas.
[PA154.IG101.SP101.N105.R104]

1. Objetivos de medições [PA154.IG101.SP101.W101]
Sub-práticas
1. Documentar as necessidades e objetivos de informações.
[PA154.IG101.SP101.SubP101]

CMMI-SE/SW, v1.1
As necessidades e objetivos de informações são

documentadas para permitir a rastreabilidade para as
atividades de medições e análises subseqüentes.
[PA154.IG101.SP101.SubP101.N101]
2. Priorizar as necessidades e objetivos de informações.

[PA154.IG101.SP101.SubP102]
Pode não ser possível nem desejável submeter todas as

necessidades de informações inicialmente identificadas a
medições e análises. Prioridades também precisam ser
definidas, dentro dos limites dos recursos disponíveis.
[PA154.IG101.SP101.SubP102.N101]
3. Documentar, revisar e atualizar os objetivos das medições.

[PA154.IG101.SP101.SubP103]
É importante considerar com cuidado os objetivos e usos

pretendidos das medições e análises. [PA154.IG101.SP101.SubP103.N101]
Os objetivos de medições são documentados, revisados

pelos gerentes e outros stakeholders relevantes e
atualizados, conforme necessário. Fazer isso possibilita a
rastreabilidade das atividades subseqüentes de medições
e análises e ajuda a assegurar que as análises irão tratar,
apropriadamente, das necessidades e objetivos de
informações identificados. [PA154.IG101.SP101.SubP103.N102]
É importante que os usuários dos resultados de medições

e análises sejam envolvidos na definição dos objetivos das
medições e na decisão sobre planos de ação. Pode
também ser apropriado envolver aqueles que fornecerão
os dados de medições. [PA154.IG101.SP101.SubP103.N103]
4. Fornecer feedback para o refinamento e esclarecimento das

necessidades e objetivos de informações, conforme necessário.
[PA154.IG101.SP101.SubP104]
As necessidades e objetivos de informações identificados

podem precisar ser refinados e esclarecidos, como
resultado da definição dos objetivos das medições. As
descrições iniciais das necessidades de informações
podem ser pouco claras ou ambíguas. Podem surgir
conflitos entre as necessidades e objetivos existentes.
Objetivos precisos sobre uma medida já existente podem
ser irreais. [PA154.IG101.SP101.SubP104.N101]
5. Manter a rastreabilidade dos objetivos de medições com as

necessidades e objetivos de informações identificados.
[PA154.IG101.SP101.SubP105]

CMMI-SE/SW, v1.1
Sempre deve haver uma boa resposta para a pergunta:

“Por que estamos medindo isto?” [PA154.IG101.SP101.SubP105.N101]
É claro que os objetivos das medições podem também

mudar para refletir a evolução das necessidades e
objetivos de informações. [PA154.IG101.SP101.SubP105.N102]
SP 1.2 Especificar Medidas

Especificar medidas para tratar os objetivos de medições.
[PA154.IG101.SP102]
Os objetivos de medições são refinados em medidas precisas e

quantificáveis. [PA154.IG101.SP102.N101]
As medidas podem ser “básicas” ou “derivadas”. Os dados para as

medidas básicas são obtidos através de medição direta. Os dados para
medidas derivadas provêm de outros dados, normalmente, através da
combinação de duas ou mais medidas básicas. [PA154.IG101.SP102.N102]
Exemplos de medidas básicas normalmente utilizadas

incluem: [PA154.IG101.SP102.N103]
• Medidas reais e estimadas de tamanho de produtos de

trabalho (por exemplo, quantidade de páginas)
• Medidas reais e estimadas de esforço e custo (por
exemplo, quantidade de horas homem)
• Medidas de qualidade (por exemplo, quantidade de
defeitos, quantidade de defeitos por gravidade)
Exemplos de medidas derivadas normalmente utilizadas

incluem: [PA154.IG101.SP102.N104]
• Valor Agregado
• êndice de Desempenho do Cronograma
• Densidade de defeitos
• Cobertura de revisões por pares
• Cobertura de testes e verificações
• Medidas de confiabilidade (por exemplo, intervalo de
tempo até ocorrer uma falha)
• Medidas de qualidade (por exemplo, quantidade de
defeitos por gravidade/quantidade total de defeitos)

CMMI-SE/SW, v1.1
As medidas derivadas normalmente são expressas como razões,

índices compostos e outras medidas de resumo agregadas. Elas são,
normalmente, mais confiáveis quantitativamente e sua interpretação
tem mais sentido que as medidas básicas utilizadas para gerá-las.
[PA154.IG101.SP102.N105]

1. Especificações de medidas básicas e derivadas [PA154.IG101.SP102.W101]
Sub-práticas
1. Identificar medidas candidatas com base nos objetivos
documentados de medições. [PA154.IG101.SP102.SubP101]
Os objetivos de medições são refinados em medidas

específicas. As medidas candidatas identificadas são
classificadas e especificadas por nome e unidade de
medida. [PA154.IG101.SP102.SubP101.N101]
2. Identificar medidas existentes que já atendem aos objetivos de

medições. [PA154.IG101.SP102.SubP102]
As especificações para as medidas podem já existir, talvez

estabelecidas anteriormente com outros objetivos ou em
outra parte da organização. [PA154.IG101.SP102.SubP102.N101]
3. Especificar as definições operacionais para as medidas.

[PA154.IG101.SP102.SubP103]
As definições operacionais são declaradas em termos

precisos e não ambíguos. Elas tratam de dois importantes
critérios, como segue: [PA154.IG101.SP102.SubP103.N101]
• Comunicação: O que está sendo medido, como foi

medido, quais as unidades de medida e o que foi incluído
ou excluído?
• Repetibilidade: A medição pode ser repetida, dada a
mesma definição, para obter os mesmos resultados?
4. Priorizar, revisar e atualizar medidas. [PA154.IG101.SP102.SubP104]
As especificações propostas das medidas são revisadas

para verificar sua adequação com os potenciais usuários
finais e outros stakeholders relevantes. As prioridades são
definidas ou modificadas e as especificações das medidas
são atualizadas, conforme necessário.
[PA154.IG101.SP102.SubP104.N101]

CMMI-SE/SW, v1.1
SP 1.3 Especificar Procedimentos de Coleta e Armazenagem de Dados

Especificar como os dados de medições serão obtidos e
armazenados. [PA154.IG101.SP103]
A especificação explícita de métodos de coleta ajuda a assegurar que

os dados corretos estão sendo coletados de forma apropriada. Ela
também auxilia a esclarecer ainda mais as necessidades de
informações e os objetivos das medições. [PA154.IG101.SP103.N101]
A atenção apropriada aos procedimentos de armazenagem e

recuperação ajuda a assegurar que os dados estarão disponíveis e
acessíveis para uso futuro. [PA154.IG101.SP103.N102]

1. Procedimentos de coleta e armazenagem de dados
[PA154.IG101.SP103.W101]
2. Ferramentas de coleta de dados [PA154.IG101.SP103.W102]
Sub-práticas
1. Identificar as fontes de dados existentes que são geradas a partir
dos atuais produtos de trabalho, processos ou transações.
[PA154.IG101.SP103.SubP101]
As fontes de dados existentes podem já ter sido

identificadas quando as medidas foram especificadas.
Mecanismos apropriados de coleta podem existir mesmo
que dados relevantes ainda não tenham sido coletados.
[PA154.IG101.SP103.SubP101.N101]
2. Identificar medidas para as quais dados são necessários, mas que

não estão atualmente disponíveis. [PA154.IG101.SP103.SubP102]
3. Especificar como coletar e armazenar os dados para cada medida

necessária. [PA154.IG101.SP103.SubP103]
Especificações explícitas são feitas sobre como, onde e

quando os dados serão coletados. Procedimentos para a
coleta de dados válidos são especificados. Os dados são
armazenados de maneira acessível para a análise e é
definido se eles devem ser gravados para uma possível
reanálise ou para fins de documentação.
[PA154.IG101.SP103.SubP103.N101]
Questões a serem consideradas geralmente incluem:

[PA154.IG101.SP103.SubP103.N102]
• A freqüência da coleta e os pontos do processo onde as

medições serão feitas foram definidos?

CMMI-SE/SW, v1.1
• O cronograma que será necessário para mover os

resultados das medições dos pontos de coleta para os
repositórios, outros bancos de dados ou para os usuários
finais foi estabelecido?
• Quem é responsável pela obtenção dos dados?
• Quem é responsável pela armazenagem, recuperação e
segurança dos dados?
• As ferramentas de suporte necessárias foram
desenvolvidas ou adquiridas?
4. Criar mecanismos de coleta de dados e direcionamento do
processo. [PA154.IG101.SP103.SubP104]
Os mecanismos de coleta e armazenagem de dados são

bem integrados com outros processos de trabalho
normais. Os mecanismos de coleta de dados podem incluir
formulários e templates manuais ou automatizados. Um
direcionamento claro e conciso sobre os procedimentos
corretos está disponível para os responsáveis pela
execução do trabalho. O treinamento é fornecido,
conforme necessário, para esclarecer os processos
necessários para a coleta de dados completos e precisos e
para minimizar a carga dos que devem fornecer e registrar
os dados. [PA154.IG101.SP103.SubP104.N101]
5. Estabelecer suporte à coleta automática de dados onde for

apropriado e possível. [PA154.IG101.SP103.SubP105]
O suporte automático pode auxiliar na coleta de dados

mais completos e precisos. [PA154.IG101.SP103.SubP105.N101]
Exemplos de tais suportes automáticos incluem:

[PA154.IG101.SP103.SubP105.N102]
• Logs de atividades com horário registrado

• Análises estáticas ou dinâmicas de artefatos
Entretanto, alguns dados não podem ser coletados sem

intervenção humana (por exemplo, satisfação do cliente
ou outras opiniões pessoais) e criar a infra-estrutura
necessária para as outras automações pode ser muito
caro. [PA154.IG101.SP103.SubP105.N103]
6. Priorizar, revisar e atualizar os procedimentos de coleta e

armanezagem de dados. [PA154.IG101.SP103.SubP106]

CMMI-SE/SW, v1.1
Os procedimentos propostos são revisados com relação a

sua adequação e possibilidade de execução com os
responsáveis pelo fornecimento, coleta e armazenagem
dos dados. Eles também podem ter sugestões úteis sobre
como melhorar os processos existentes ou podem sugerir
outras medidas e análises úteis. [PA154.IG101.SP103.SubP106.N101]
7. Atualizar as medidas e os objetivos das medições, conforme

Devem ser revisadas as prioridades com base no seguinte:

[PA154.IG101.SP103.SubP107.N101]
• A importância das medidas

• A quantidade de esforço exigido para obter os dados
As considerações incluem se serão necessários novos

formulários, ferramentas ou treinamento para obter os
dados. [PA154.IG101.SP103.SubP107.N102]
SP 1.4 Especificar os Procedimentos de Análises

Especificar como os dados de medições serão analisados e
comunicados. [PA154.IG101.SP104]
Especificar antecipadamente os procedimentos de análise assegura

que as análises apropriadas serão executadas e comunicadas para
atender aos objetivos documentados das medições (e, portanto, as
necessidades e objetivos de informações nos quais eles foram
baseados). Esta abordagem também garante uma conferência se os
dados necessários serão de fato coletados. [PA154.IG101.SP104.N101]

1. Especificação e procedimentos de análises [PA154.IG101.SP104.W101]
2. Ferramentas de análises de dados [PA154.IG101.SP104.W102]
Sub-práticas
1. Especificar e priorizar as análises que serão executadas e os
relatórios que serão preparados. [PA154.IG101.SP104.SubP101]
Uma atenção antecipada deverá ser dada às análises que

serão executadas e à maneira como os resultados serão
relatados. Estes deverão atender os seguintes critérios:
[PA154.IG101.SP104.SubP101.N101]
• As análises atendem explicitamente os objetivos

documentados das medições

CMMI-SE/SW, v1.1
• A apresentação dos resultados é claramente

compreendida pelas audiências a quem os resultados são
endereçados
As prioridades podem ter que ser definidas dentro dos

recursos disponíveis. [PA154.IG101.SP104.SubP101.N102]
2. Selecionar os métodos e ferramentas de análises de dados

adequados. [PA154.IG101.SP104.SubP102]
Veja as práticas específicas Selecionar Medidas e Técnicas de

Análises e Aplicar Métodos Estatísticos para Entender Variações
da área de processo de Gerenciamento Quantitativo do Projeto
para obter maiores informações sobre o uso apropriado de
técnicas de análises estatísticas e sobre o entendimento de
variações, respectivamente. [PA154.IG101.SP104.SubP102.R101]
Questões a serem consideradas normalmente incluem:

[PA154.IG101.SP104.SubP102.N101]
• Escolha do layout e outras técnicas de apresentação (por

exemplo, gráficos de pizza, gráficos de barra,
histogramas, gráficos de radar, gráficos de linha, gráficos
de dispersão ou tabelas)
• Escolha das estatísticas descritivas apropriadas (por
exemplo, média aritmética, mediana ou modo)
• Decisões sobre os critérios de amostragem estatística
quando for impossível ou desnecessário examinar todos
os elementos de dados
• Decisões sobre como tratar a análise na falta de
elementos de dados
• Seleção das ferramentas de análises adequadas
Estatísticas descritivas são normalmente utilizadas na

análise de dados para fazer o seguinte:
[PA154.IG101.SP104.SubP102.N102]
• Examinar a distribuição de medidas específicas (por

exemplo, tendência central, extensão da variação, pontos
de dados que exibem uma variação fora do comum)
• Examinar os interrelacionamentos entre as medidas
especificadas (por exemplo, comparação de defeitos por
fase do ciclo de vida do produto ou por componente do
produto)
• Mostrar as mudanças ao longo do tempo
3. Especificar os procedimentos administrativos para a análise dos
dados e comunicação dos resultados. [PA154.IG101.SP104.SubP103]

CMMI-SE/SW, v1.1
Questões a serem consideradas normalmente incluem:

[PA154.IG101.SP104.SubP103.N101]
• Identificar as pessoas e grupos responsáveis por analisar

os dados e apresentar os resultados
• Determinar o cronograma para analisar os dados e
apresentar os resultados
• Determinar os locais para a comunicação dos resultados
(por exemplo, relatório de progresso, memorandos
transmitidos, relatórios escritos ou reuniões com a
equipe)
4. Revisar e atualizar o conteúdo e formato propostos das análises e
relatórios especificados. [PA154.IG101.SP104.SubP104]
Todo o conteúdo e formato proposto está sujeito a ser

revisto e revisado, incluindo os métodos e ferramentas de
análises, procedimentos administrativos e prioridades. Os
stakeholders relevantes consultados deverão incluir os
usuários finais pretendidos, os patrocinadores, analistas e
fornecedores de dados. [PA154.IG101.SP104.SubP104.N101]
5. Atualizar as medidas e objetivos de medições, conforme

Da mesma maneira que as necessidades de medições

dirigem as análises de dados, o esclarecimento dos
critérios de análises pode afetar a medição. As
especificações de algumas medidas podem ser mais
refinadas com base nas especificações estabelecidas para
os procedimentos de análise de dados. Outras medidas
podem provar ser desnecessárias ou a necessidade de
medidas adicionais pode ser percebida.
[PA154.IG101.SP104.SubP105.N101]
O exercício de especificar como as medidas serão

analisadas e comunicadas também pode sugerir a
necessidade de refinamento dos próprios objetivos das
medições. [PA154.IG101.SP104.SubP105.N102]
6. Especificar os critérios para avaliação da utilidade dos resultados

de análises e para a execução das atividades de medições e
análises. [PA154.IG101.SP104.SubP106]
Os critérios para avaliar a utilidade da análise poderiam

tratar a extensão na qual se aplica o seguinte:
[PA154.IG101.SP104.SubP106.N101]
• Os resultados são (1) fornecidos pontualmente, (2)

compreendidos e (3) utilizados para a tomada de
decisões.

CMMI-SE/SW, v1.1
• O trabalho não custa mais para ser executado do que se

justifica pelos benefícios que ele proporciona.
Os critérios para avaliar a execução das medições e

análises poderia incluir a extensão na qual se aplica o
seguinte: [PA154.IG101.SP104.SubP106.N102]
• A quantidade de dados faltando ou de inconsistências

identificadas está além dos limites especificados.
• Há uma seleção tendenciosa na amostragem (por
exemplo, somente os usuários finais satisfeitos foram
pesquisados para avaliar a satisfação do usuário final ou
somente os projetos mal sucedidos foram avaliados para
determinar a produtividade geral).
• Os dados de medições são repetíveis (isto é,
estatisticamente confiáveis).
• As premissas estatísticas foram satisfeitas (isto é, sobre a
distribuição dos dados ou sobre escalas apropriadas de
medições).
SG 2 Fornecer Resultados de Medições
Resultados de medições que tratam as necessidades e objetivos de

informações identificados são fornecidos. [PA154.IG102]
O motivo básico para se fazer medições e análises é tratar as

necessidades e objetivos de informações identificados. Os resultados
das medições baseados em evidências objetivas podem ajudar a
monitorar o desempenho, cumprir obrigações contratuais, tomar
decisões técnicas e de gerenciamento bem informadas e possibilitar
que sejam tomadas ações corretivas. [PA154.IG102.N101]
SP 2.1 Coletar Dados de Medições

Obter os dados de medições especificados. [PA154.IG102.SP101]
Os dados necessários para a análise são obtidos e conferidos quanto a

sua completitude e integridade. [PA154.IG102.SP101.N101]

1. Conjuntos de dados de medições básicas e derivadas
[PA154.IG102.SP101.W101]
2. Resultados de testes de integridade de dados [PA154.IG102.SP101.W102]
Sub-práticas
1. Obter os dados da medidas básicas. [PA154.IG102.SP101.SubP101]

CMMI-SE/SW, v1.1
Os dados são coletados, conforme necessário, para

medidas básicas já utilizadas ou recém-especificadas. Os
dados existentes são reunidos dos registros do projeto ou
de outros locais da organização. [PA154.IG102.SP101.SubP101.N101]
Note que os dados que foram coletados anteriormente

podem não estar mais disponíveis para reutilização em
bancos de dados, registros em papel ou repositórios
formais. [PA154.IG102.SP101.SubP101.N102]
2. Gerar os dados para as medidas derivadas. [PA154.IG102.SP101.SubP102]
Os valores são novamente calculados para todas as

medidas derivadas. [PA154.IG102.SP101.SubP102.N101]
3. Executar conferência da integridade de dados o mais próximo

possível da fonte dos dados. [PA154.IG102.SP101.SubP103]
Todas as medições estão sujeitas a erros na especificação

ou na gravação dos dados. É sempre melhor identificar
tais erros e identificar as fontes dos dados que faltam o
mais cedo possível no ciclo de medições e análises.
[PA154.IG102.SP101.SubP103.N101]
As conferências podem incluem checagem dos dados que

estão faltando, valores de dados fora dos limites e padrões
e correlações não usuais entre medidas.
[PA154.IG102.SP101.SubP103.N102]
É particularmente importante fazer o seguinte:

[PA154.IG102.SP101.SubP103.N103]
• Testar e corrigir inconsistências de classificações feitas por

pessoas (isto é, determinar com que freqüência pessoas
tomam diferentes decisões de classificações com base
nas mesmas informações, também conhecido como
“confiabilidade entre codificadores”).
• Examinar empiricamente as relações entre as medidas
que são usadas para calcular as medidas derivadas
adicionais. Fazer isso pode assegurar que importantes
distinções não passem despercebidas e que as medidas
derivadas transmitam os significados pretendidos
(também conhecido como “validação de critérios”).
SP 2.2 Analisar os Dados das Medições

Analisar e interpretar os dados de medições. [PA154.IG102.SP102]

CMMI-SE/SW, v1.1
Os dados de medições são analisados conforme planejado, análises

adicionais são conduzidas, conforme necessário, os resultados são
revisados com os stakeholders relevantes e revisões necessárias para
análises futuras são anotadas. [PA154.IG102.SP102.N101]

1. Resultados de análises e relatórios preliminares [PA154.IG102.SP102.W101]
Sub-práticas
1. Conduzir análises iniciais, interpretar os resultados e escrever
conclusões preliminares. [PA154.IG102.SP102.SubP101]
Os resultados das análises de dados raramente são

evidentes por si só. Devem ser estabelecidos
explicitamente critérios para a interpretação dos
resultados e para a definição de conclusões.
[PA154.IG102.SP102.SubP101.N101]
2. Conduzir medições e análises adicionais, conforme necessário, e

preparar os resultados para a apresentação. [PA154.IG102.SP102.SubP102]
Os resultados das análises planejadas podem sugerir (ou

exigir) análises adicionais não previstas. Além disso,
podem identificar necessidades de refinar as medidas
existentes, calcular medidas derivadas adicionais ou
mesmo coletar dados para medidas primitivas adicionais
para completar, de forma apropriada, a análise planejada.
De maneira semelhante, preparar os resultados iniciais
para a apresentação pode identificar a necessidade de
análises adicionais não previstas. [PA154.IG102.SP102.SubP102.N101]
3. Revisar os resultados iniciais com os stakeholders relevantes.

[PA154.IG102.SP102.SubP103]
Pode ser apropriado rever as interpretações iniciais dos

resultados e a maneira como elas serão apresentadas,
antes de disseminá-las e comunicá-las de forma mais
abrangente. [PA154.IG102.SP102.SubP103.N101]
Revisar os resultados iniciais antes de sua liberação pode

evitar mal entendidos desnecessários e levar a melhorias
na análise e apresentação dos dados. [PA154.IG102.SP102.SubP103.N102]
Os stakeholders relevantes com os quais as revisões

podem ser feitas incluem os usuários finais pretendidos e
os patrocinadores, bem como os analistas e fornecedores
de dados. [PA154.IG102.SP102.SubP103.N103]
4. Refinar os critérios para análises futuras. [PA154.IG102.SP102.SubP104]

CMMI-SE/SW, v1.1
Lições valiosas que podem melhorar os futuros esforços

são, muitas vezes, aprendidas na condução de análises de
dados e na preparação dos resultados. Da mesma forma,
maneiras de melhorar as especificações de medições e os
procedimentos de coleta de dados podem se tornar
aparentes, bem como idéias para refinar as necessidades
[PA154.IG102.SP102.SubP104.N101]
SP 2.3 Armazenar os Dados e Resultados

Gerenciar e armazenar os dados de medições, especificações
de medições e resultados de análises. [PA154.IG102.SP103]
Armazenar informações relacionadas a medições possibilita o uso

futuro pontual e eficiente, em termos de custos, dos dados históricos e
resultados. As informações também são necessárias para fornecer um
contexto suficiente para a interpretação dos dados, critérios de
medições e resultados das análises. [PA154.IG102.SP103.N101]
As informações armazenadas normalmente incluem: [PA154.IG102.SP103.N102]
• Planos de medições
• Especificações de medidas
• Conjuntos de dados que foram coletados
• Relatórios de análises e apresentações
As informações armazenadas contêm ou fazem referência às

informações necessárias para entender e interpretar as medidas e
analisá-las com relação à motivação e aplicabilidade (por exemplo,
especificações de medições usadas em diferentes projetos para a
comparação entre projetos). [PA154.IG102.SP103.N103]
Conjuntos de dados para medidas derivadas, normalmente, podem ser

recalculados e não precisam ser armazenados. Entretanto, pode ser
apropriado armazenar resumos baseados nas medidas derivadas (por
exemplo, gráficos, tabelas de resultados ou relatórios descritivos).
[PA154.IG102.SP103.N104]
Resultados intermediários das análises não precisam ser armazenados

separadamente, se puderem ser eficientemente reconstruídos.
[PA154.IG102.SP103.N105]
Os projetos podem decidir armazenar dados e resultados específicos

do projeto em um repositório específico. Quando os dados são
compartilhados de forma mais abrangente entre projetos, os dados
podem residir no repositório de medições da organização.
[PA154.IG102.SP103.N106]

CMMI-SE/SW, v1.1
Veja a prática específica Estabelecer o Repositório de Medições da

Organização da área de processo de Definição do Processo
Organizacional para obter maiores informações sobre como
estabelecer o repositório de medições da organização.
[PA154.IG102.SP103.N106.R101]

obter maiores informações sobre o gerenciamento dos produtos de
trabalho de medições. [PA154.IG102.SP103.N106.R102]

1. Inventário dos dados armazenados [PA154.IG102.SP103.W101]
Sub-práticas
1. Revisar os dados para assegurar sua completitude, integridade,
exatidão e atualização. [PA154.IG102.SP103.SubP101]
2. Tornar o conteúdo armazenado disponível para uso somente dos

grupos e pessoal autorizados. [PA154.IG102.SP103.SubP102]
3. Impedir que as informações armazenadas sejam utilizadas de

forma inadequada. [PA154.IG102.SP103.SubP103]
Exemplos de maneiras de impedir o uso inadequado dos

dados e informações relacionadas incluem o controle do
acesso aos dados e a educação das pessoas sobre o uso
apropriado dos dados. [PA154.IG102.SP103.SubP103.N101]
Exemplos de uso inadequado incluem:

[PA154.IG102.SP103.SubP103.N102]
• Exposição de informações que foram fornecidas

confidencialmente
• Interpretações falhas baseadas em informações
incompletas, fora do contexto ou, ainda, distorcidas
• Medidas utilizadas para avaliar inadequadamente o
desempenho de pessoas ou classificar projetos
• Gerar dúvidas sobre a integridade de indivíduos
específicos
SP 2.4 Comunicar os Resultados

Relatar os resultados das atividades de medições e análises
para todos os stakeholders relevantes. [PA154.IG102.SP104]

CMMI-SE/SW, v1.1
Os resultados do processo de medições e análises são comunicados

aos stakeholders relevantes, de uma maneira pontual e fácil de se
utilizar, para suportar a tomada de decisões e auxiliar na tomada das
ações corretivas. [PA154.IG102.SP104.N101]
Os stakeholders relevantes incluem os usuários pretendidos,

patrocinadores e analistas e fornecedores de dados. [PA154.IG102.SP104.N102]

1. Relatórios entregues e resultados de análises relacionados
[PA154.IG102.SP104.W101]
2. Informações de contexto ou direcionamento para auxiliar na

interpretação dos resultados das análises [PA154.IG102.SP104.W102]
Sub-práticas
1. Manter os stakeholders relevantes pontualmente informados dos
resultados das medições. [PA154.IG102.SP104.SubP101]
Os resultados das medições são comunicados a tempo de

serem utilizados para seus propósitos pretendidos. Os
relatórios possivelmente não serão utilizados se forem
distribuídos com pouco esforço em seguir aqueles que
precisam saber dos resultados. [PA154.IG102.SP104.SubP101.N101]
Na extensão que for possível e como parte da maneira

normal como trabalham, os usuários dos resultados de
medições são mantidos pessoalmente envolvidos na
definição de objetivos e decisão sobre os planos de ação
para medições e análises. Os usuários são mantidos
regularmente informados do progresso e dos resultados
intermediários. [PA154.IG102.SP104.SubP101.N102]

para obter maiores informações sobre o uso de resultados de
medições. [PA154.IG102.SP104.SubP101.N102.R101]
2. Auxiliar os stakeholders relevantes no entendimento dos

resultados. [PA154.IG102.SP104.SubP102]
Os resultados são relatados de uma maneira clara e

concisa, apropriada à sofisticação metodológica dos
stakeholders relevantes. Eles são fáceis de entender,
fáceis de interpretar e claramente ligados a necessidades
[PA154.IG102.SP104.SubP102.N101]

CMMI-SE/SW, v1.1
Os dados, muitas vezes, não são evidentes para quem não

é um expert em medições. As escolhas das medições
deverão ser explicitamente claras sobre o seguinte:
[PA154.IG102.SP104.SubP102.N102]
• Como e por que as medidas básicas e derivadas foram

especificadas
• Como os dados foram obtidos
• Como interpretar os resultados com base nos métodos de
análises de dados que foram utilizados
• Como os resultados tratam as suas necessidades de
informações
Exemplos de ações para auxiliar o entendimento dos

resultados incluem: [PA154.IG102.SP104.SubP102.N103]
• Discutir os resultados com os stakeholders relevantes

• Fornecer um memorando que contenha uma
fundamentação e uma explicação para os resultados
• Fornecer informações detalhadas sobre os resultados
antecipadamente para os usuários
• Fornecer treinamento para o uso e entendimento
apropriados dos resultados de medições
Compromisso

planejamento e execução do processo de medições e análises.
[GP103]
Elaboração:

alinhamento dos objetivos e atividades de medições com as
necessidades e objetivos de informações identificados e para o
fornecimento dos resultados de medições. [PA154.EL101]

CMMI-SE/SW, v1.1
Habilitações

medições e análises. [GP104]
Elaboração:
Normalmente, este plano para a execução do processo de medições e

análises está incluído no (ou é referenciado pelo) plano do projeto, que
é descrito na área de processo de Planejamento do Projeto. [PA154.EL115]

de medições e análises, desenvolvimento dos produtos de
trabalho e fornecimento dos serviços do processo. [GP105]
Elaboração:
O pessoal que executa as medições pode trabalhar em período integral

ou em meio período. Um grupo de medições pode ou não existir para
suportar as atividades de medições em diversos projetos. [PA154.EL104]
Exemplos de outros recursos fornecidos incluem as seguintes

• Pacotes estatísticos
• Pacotes que apóiam a coleta de dados entre redes

fornecimento dos serviços do processo de medições e
análises. [GP106]

Treinar as pessoas na execução e suporte do processo de
medições e análises, conforme necessário. [GP107]

CMMI-SE/SW, v1.1
Elaboração:
• Técnicas estatísticas
• Processos de coleta de dados, análise e criação de
relatórios
• Desenvolvimento de medições relacionadas a metas (por
exemplo, Métrica de Questionamento de Metas - Goal
Question Metric)
Implementações

medições e análises sob os níveis apropriados de
Elaboração:

• Especificações de medidas básicas e derivadas

• Procedimentos de coleta e armazenagem de dados
• Conjuntos de dados de medições básicas e derivadas
• Resultados de análises e relatórios preliminares
• Ferramentas de análises de dados

de medições e análises, conforme planejado. [GP124]

CMMI-SE/SW, v1.1
Elaboração:

• Estabelecimento de objetivos e procedimentos de

medições
• Análise de dados de medições
• Fornecimento de feedback significativo para os
responsáveis pelo fornecimento de dados iniciais dos
quais dependem a análise e os resultados

Monitorar e controlar o processo de medições e análises
contra o plano para a execução do processo e tomar as ações
corretivas apropriadas. [GP110]
Elaboração:

• Percentual de projetos utilizando medidas de progresso e

desempenho
• Percentual de objetivos de medições tratados
Verificações

Avaliar objetivamente a aderência do processo de medições e
análises contra sua descrição de processo, padrões e
procedimentos e tratar as não conformidades. [GP113]
Elaboração:
• Alinhamento das atividades de medições e análises

• Fornecimento de resultados de medições

CMMI-SE/SW, v1.1

[PA154.EL113]
• Especificações de medidas básicas e derivadas

• Procedimentos de coleta e armazenagem de dados
• Resultados das análises e relatórios preliminares

medições e análises com o nível mais alto de gerência e
resolver questões. [GP112]
superiores).

medições e análises. [GP114]

e informações de melhoria derivados do planejamento e
execução do processo de medições e análises para suportar o
uso futuro e a melhoria dos processos e ativos de processos
da organização. [GP117]

CMMI-SE/SW, v1.1
GARANTIA DA QUALIDADE DO PROCESSO E DO PRODUTO

Objetivo
O objetivo da Garantia da Qualidade do Processo e do Produto

(Process and Product Quality Assurance) é fornecer à equipe e à
gerência um entendimento objetivo dos processos e seus produtos de
trabalho associados. [PA145]

Produto envolve o seguinte: [PA145.N101]
• 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

Produto suporta a entrega de produtos e serviços de alta qualidade,
fornecendo, à equipe do projeto e gerentes de todos os níveis, a
visibilidade apropriada e o feedback sobre os processos e produtos de
trabalho associados durante todo o ciclo de vida do projeto. [PA145.N102]
As práticas da área de processo de Garantia da Qualidade do

Processo e do Produto asseguram que os processos planejados estão
implementados, enquanto que as práticas da área de processo de
Verificação garantem que os requisitos especificados estão sendo
satisfeitos. Estas duas áreas de processos podem, ocasionalmente,
tratar o mesmo produto de trabalho, mas a partir de diferentes
perspectivas. Os projetos deverão tomar cuidado para minimizar a
duplicidade de esforços. [PA145.N103]
Nível de Maturidade: 2, Garantia da Qualidade do Processo e do Produto 195

CMMI-SE/SW, v1.1
A objetividade nas avaliações da garantia da qualidade do processo e

do produto é crítica para o sucesso do projeto. (Veja a definição de
“avaliar objetivamente” no Apêndice B, o glossário). A objetividade é
conseguida através da independência e do uso de critérios.
Tradicionalmente, um grupo de garantia da qualidade independente do
projeto consegue esta objetividade. Pode ser apropriado em algumas
organizações, entretanto, implementar o papel da garantia da
qualidade do processo e do produto sem este tipo de independência.
Por exemplo, em uma organização com uma cultura aberta e orientada
para a qualidade, o papel da garantia da qualidade do processo e do
produto pode ser executado, parcial ou completamente, por parceiros;
e a função da garantia da qualidade pode estar embutida no processo.
[PA145.N104]
Se a garantia da qualidade está embutida no processo, diversas

questões devem ser tratadas para garantir a objetividade. Todos os que
exercerem atividades de garantia da qualidade deverão ser treinados
no assunto. Quem executa atividades de garantia da qualidade para
um produto de trabalho deverá estar separado dos que estão
diretamente envolvidos no desenvolvimento ou manutenção do produto
de trabalho. Um canal de comunicação independente para o nível
apropriado de gerenciamento organizacional deve estar disponível, de
forma que as questões de não conformidades possam passar para
níveis mais elevados, conforme necessário. [PA145.N105]
A garantia da qualidade deverá começar nas fases iniciais de um

projeto a estabelecer planos, processos, padrões e procedimentos que
adicionarão valor ao projeto e atenderão os requisitos do projeto e as
políticas organizacionais. Aqueles que executam a garantia da
qualidade participam no estabelecimento dos planos, processos,
padrões e procedimentos, para assegurar que eles se encaixam nas
necessidades do projeto e que poderão ser utilizados para a execução
de avaliações de garantia da qualidade. Além disso, os processos
específicos e produtos de trabalho associados que serão avaliados
durante o projeto são definidos. Esta definição pode ser baseada em
amostragem ou em critérios objetivos, que estejam consistentes com
as políticas organizacionais e com os requisitos e necessidades do
projeto. [PA145.N106]
Quando são identificadas questões de não conformidades, elas são

primeiramente tratadas dentro do projeto e, se possível, resolvidas.
Quaisquer questões de não conformidades que não possam ser
resolvidas dentro do projeto são levadas para um nível apropriado de
gerenciamento para resolução. [PA145.N107]
196 Nível de Maturidade: 2, Garantia da Qualidade do Processo e do Produto

CMMI-SE/SW, v1.1
Esta área de processo basicamente aplica-se a avaliações de produtos

e serviços, mas também se aplica a avaliações de atividades e
produtos de trabalho que não pertencem ao projeto, como as
atividades de treinamento. Para estas atividades e produtos de
trabalho, o termo “projeto” deverá ser apropriadamente interpretado.
[PA145.N108]

maiores informações sobre a identificação de processos e produtos de
trabalho associados que serão objetivamente avaliados. [PA145.R101]
Veja a área de processo de Verificação para obter maiores informações

sobre como satisfazer os requisitos especificados. [PA145.R102]
SG 1 Avaliar Objetivamente Processos e Produtos de Trabalho [PA145.IG101]
A aderência do processo executado e dos produtos de trabalho e serviços

associados às descrições de processo, padrões e procedimentos
aplicáveis é objetivamente avaliada.
SG 2 Fornecer um Entendimento Objetivo [PA145.IG102]
Questões de não conformidades são objetivamente rastreadas e

comunicadas e a resolução é assegurada.

CMMI-SE/SW, v1.1
SG 1 Avaliar Objetivamente Processos e Produtos de Trabalho [PA145.IG101]
SP 1.1 Avaliar Objetivamente os Processos

SP 1.2 Avaliar Objetivamente os Produtos de Trabalho e Serviços
SG 2 Fornecer um Entendimento Objetivo [PA145.IG102]
SP 2.1 Comunicar e Assegurar a Resolução das Questões de Não

Conformidades
SP 2.2 Estabelecer Registros


SG 1 Avaliar Objetivamente os Processos e Produtos de Trabalho
A aderência do processo executado e dos produtos de trabalho e serviços

associados às descrições de processo, padrões e procedimentos
aplicáveis é objetivamente avaliada. [PA145.IG101]
SP 1.1 Avaliar Objetivamente os Processos

Avaliar objetivamente os processos definidos executados
contra as descrições de processo, padrões e procedimentos
aplicáveis. [PA145.IG101.SP101]

CMMI-SE/SW, v1.1
A objetividade nas avaliações de garantia da qualidade é crítica para o

sucesso do projeto. Deverá ser definida uma descrição da cadeia de
relatórios de garantia da qualidade e de como ela assegura a
objetividade. [PA145.IG101.SP101.N101]

1. Relatórios de avaliações [PA145.IG101.SP101.W101]
2. Relatórios de não conformidades [PA145.IG101.SP101.W102]
Sub-práticas
1. Promover um ambiente (criado como parte do gerenciamento do
projeto) que encoraje a participação dos empregados na
identificação e comunicação de questões de qualidade.
[PA145.IG101.SP101.SubP101]
2. Estabelecer e manter critérios claramente declarados para as

avaliações. [PA145.IG101.SP101.SubP102]
O propósito desta sub-prática é fornecer critérios,

baseados nas necessidades do negócio, como os
seguintes: [PA145.IG101.SP101.SubP102.N101]
• O que será avaliado

• Quando ou com que freqüência um processo será avaliado
• Como a avaliação será conduzida
• Quem deve estar envolvido na avaliação
3. Utilizar os critérios declarados para avaliar os processos
executados com relação à aderência às descrições de processo,
padrões e procedimentos. [PA145.IG101.SP101.SubP103]
4. Identificar todas as não conformidades encontradas durante a

avaliação. [PA145.IG101.SP101.SubP104]
5. Identificar as lições aprendidas que poderão melhorar processos

para futuros produtos e serviços. [PA145.IG101.SP101.SubP105]
SP 1.2 Avaliar Objetivamente Produtos de Trabalho e Serviços

Avaliar objetivamente os produtos de trabalho e serviços
definidos contra as descrições de processo, padrões e
procedimentos aplicáveis. [PA145.IG101.SP102]


CMMI-SE/SW, v1.1
2. Relatórios de não conformidades [PA145.IG101.SP102.W102]
Sub-práticas
1. Selecionar produtos de trabalho a serem avaliados, com base nos
critérios de amostragem documentados, se esta estiver sendo
utilizada. [PA145.IG101.SP102.SubP101]
2. Estabelecer e manter critérios claramente declarados para a

avaliação de produtos de trabalho. [PA145.IG101.SP102.SubP102]
O propósito desta sub-prática é fornecer critérios, com

base nas necessidades de negócios, como os que seguem:
[PA145.IG101.SP102.SubP102.N101]
• O que será avaliado durante a avaliação de um produto

de trabalho
• Quando ou com que freqüência um produto de trabalho
será avaliado
• Como a avaliação será conduzida
• Quem deve ser envolvido na avaliação
3. Utilizar os critérios declarados durante as avaliações de produtos
de trabalho. [PA145.IG101.SP102.SubP103]
4. Avaliar os produtos de trabalho antes que sejam entregues ao

cliente. [PA145.IG101.SP102.SubP104]
5. Avaliar os produtos de trabalho em milestones selecionados

durante o seu desenvolvimento. [PA145.IG101.SP102.SubP105]
6. Executar avaliações durante o progresso ou incrementais de

produtos de trabalho e serviços contra as descrições de processo,
padrões e procedimentos. [PA145.IG101.SP102.SubP106]
7. Identificar todos os casos de não conformidades encontrados

durante as avaliações. [PA145.IG101.SP102.SubP107]
8. Identificar lições aprendidas que poderiam melhorar os processos

para futuros produtos e serviços. [PA145.IG101.SP102.SubP108]
SG 2 Fornecer um Entendimento Objetivo
As questões de não conformidades são objetivamente rastreadas e

comunicadas e a resolução é assegurada. [PA145.IG102]

CMMI-SE/SW, v1.1
SP 2.1 Comunicar e Assegurar a Resolução de Questões de Não

Conformidades
Comunicar questões de qualidade e assegurar a resolução de
questões de não conformidades com a equipe e os gerentes.
[PA145.IG102.SP101]
Questões de não conformidades são problemas identificados nas

avaliações que refletem a falta de aderência a padrões, descrições de
processos ou procedimentos aplicáveis. O status das questões de não
conformidades fornece uma indicação das tendências de qualidade. As
questões de qualidade incluem as questões de não conformidades e os
resultados de análises de tendências. [PA145.IG102.SP101.N101]
Quando a resolução local das questões de não conformidades não

pode ser conseguida, utilizar os mecanismos estabelecidos de
elevação do problema, para assegurar que o nível apropriado de
gerenciamento possa resolver a questão. Rastrear as questões de não
conformidades até a sua resolução. [PA145.IG102.SP101.N102]

1. Relatórios de ações corretivas [PA145.IG102.SP101.W101]
3. Tendências de qualidade [PA145.IG102.SP101.W103]
Sub-práticas
1. Resolver todas as não conformidades com os membros
apropriados da equipe, quando for possível. [PA145.IG102.SP101.SubP101]
2. Documentar as questões de não conformidades que não podem

ser resolvidas dentro do projeto. [PA145.IG102.SP101.SubP102]
Exemplos de maneiras de resolver não conformidades

dentro do projeto incluem: [PA145.IG102.SP101.SubP102.N101]
• Consertar a não conformidade

• Modificar as descrições de processos, padrões ou
procedimentos que foram violados
• Obter uma dispensa para cobrir a questão de não
conformidade
3. Elevar as questões de não conformidades que não podem ser

resolvidas dentro do projeto, para o nível apropriado de
gerenciamento designado para receber e atuar sobre as questões
de não conformidades. [PA145.IG102.SP101.SubP103]

CMMI-SE/SW, v1.1
4. Analisar as questões de não conformidades para verificar se

existem tendências de qualidade que podem ser identificadas e
tratadas. [PA145.IG102.SP101.SubP104]
5. Assegurar que os stakeholders relevantes estão cientes dos

resultados das avaliações e das tendências de qualidade, de uma
maneira oportuna. [PA145.IG102.SP101.SubP105]
6. Revisar periodicamente as questões de não conformidades e

tendências em aberto, com o gerente designado para receber e
atuar sobre as questões de não conformidades. [PA145.IG102.SP101.SubP106]
7. Rastrear as questões de não conformidades até a sua resolução.

[PA145.IG102.SP101.SubP107]
SP 2.2 Estabelecer Registros

Estabelecer e manter registros das atividades de garantia da
qualidade. [PA145.IG102.SP102]

1. Logs de avaliações [PA145.IG102.SP102.W101]
2. Relatórios de garantia da qualidade [PA145.IG102.SP102.W102]
3. Relatórios de status de ações corretivas [PA145.IG102.SP102.W103]
4. Relatórios de tendências de qualidade [PA145.IG102.SP102.W104]
Sub-práticas
1. Registrar as atividades de garantia da qualidade do processo e do
produto com detalhes suficientes para que o status e os resultados
sejam conhecidos. [PA145.IG102.SP102.SubP101]
2. Revisar o status e o histórico das atividades de garantia da

qualidade, conforme necessário. [PA145.IG102.SP102.SubP102]
GG 2 Institucionalizar um Processo Gerenciado 103.GL101]

CMMI-SE/SW, v1.1
Compromissos

planejamento e execução do processo de garantia da qualidade
do processo e do produto. [GP103]
Elaboração:
Esta política estabelece as expectativas organizacionais para avaliar

objetivamente se os processos e produtos de trabalho associados
aderem às descrições de processos, padrões e procedimentos
aplicáveis e assegurar que as não conformidades são tratadas.
[PA145.EL101]
Esta política também estabelece as expectativas organizacionais para

que a garantia da qualidade do processo e do produto seja feita para
todos os projetos. A garantia da qualidade do processo e do produto
deve possuir suficiente independência do gerenciamento do projeto
para garantir a objetividade na identificação e comunicação das
questões de não conformidades. [PA145.EL102]
Habilitações

garantia da qualidade do processo e do produto. [GP104]
Elaboração:
Este plano para a execução do processo de garantia da qualidade do

processo e do produto pode estar incluído no (ou ser referenciado pelo)
plano do projeto, que é descrito na área de processo de Planejamento
do Projeto. [PA145.EL114]

de garantia da qualidade do processo e do produto,
desenvolvimento dos produtos de trabalho e fornecimento dos
serviços do processo. [GP105]

CMMI-SE/SW, v1.1
Elaboração:

• Ferramentas de avaliação
• Ferramentas de rastreamento de não conformidades

fornecimento dos serviços do processo de garantia da
qualidade do processo e do produto. [GP106]
Elaboração:
Para evitar subjetividade ou ser tendencioso, assegure que as

pessoas, às quais foram atribuídas responsabilidades e autoridade
sobre a garantia da qualidade do processo e do produto, podem
executar suas avaliações com suficiente independência e objetividade.
[PA145.EL115]

garantia da qualidade do processo e do produto, conforme
necessário. [GP107]
Elaboração:
• Domínio da aplicação
• Relações com clientes
• Descrições de processos, padrões, procedimentos e
métodos para o projeto
• Objetivos, descrições de processos, padrões,
procedimentos, métodos e ferramentas de garantia da
qualidade

CMMI-SE/SW, v1.1
Implementações

garantia da qualidade do processo e do produto sob os níveis
apropriados de gerenciamento de configurações. [GP109]
Elaboração:

• Relatórios de não conformidades

• Logs e relatórios de avaliações

de garantia da qualidade do processo e do produto, conforme
planejado. [GP124]
Elaboração:
Exemplos de atividades de envolvimento de stakeholder

• Estabelecimento de critérios para avaliações objetivas de

processos e produtos de trabalho
• Avaliação de processos e produtos de trabalho
• Resolução de questões de não conformidades
• Rastreamento das questões de não conformidades até
seu encerramento

Monitorar e controlar o processo de garantia da qualidade do
processo e do produto contra o plano para execução do
processo e tomar as ações corretivas apropriadas. [GP110]

CMMI-SE/SW, v1.1
Elaboração:

• Variação de avaliações objetivas de processos planejadas

e executadas
• Variação de avaliações objetivas de produtos de trabalho
planejadas e executadas
Verificações

Avaliar objetivamente a aderência do processo de garantia da
qualidade do processo e do produto contra sua descrição de
processo, padrões e procedimentos e tratar as não
conformidades. [GP113]
Elaboração:
• Avaliar objetivamente processos e produtos de trabalho

• Rastrear e comunicar questões de não conformidades

[PA145.EL112]
• Relatórios de não conformidades

• Logs e relatórios de avaliações

garantia da qualidade do processo e do produto com o nível
mais alto de gerência e resolver questões. [GP112]

CMMI-SE/SW, v1.1
superiores).

garantia da qualidade do processo e do produto. [GP114]

execução do processo de garantia da qualidade do processo e
do produto para suportar o uso futuro e a melhoria dos
processos e dos ativos de processos da organização [GP117]

CMMI-SE/SW, v1.1
GERENCIAMENTO DE CONFIGURAÇÕES
Objetivo
O objetivo do Gerenciamento de Configurações (Configuration

Management) é 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. [PA159]
A área de processo de Gerenciamento de Configurações envolve:

[PA159.N101]
• 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
Os produtos de trabalho colocados sob gerenciamento de

configurações incluem os produtos que são entregues ao cliente,
produtos de trabalho internos definidos, produtos adquiridos,
ferramentas e outros itens que são utilizados na criação e descrição
destes produtos de trabalho. Veja a definição de “gerenciamento de
configurações” no Apêndice B, o glossário. [PA159.N102]
208 Nível de Maturidade: 2, Gerenciamento de Configurações

CMMI-SE/SW, v1.1
Exemplos de produtos de trabalho que podem ser colocados

sob gerenciamento de configurações incluem: [PA159.N109]
• Planos
• Descrições de processos
• Requisitos
• Dados de design
• Diagramas
• Especificações de produtos
• Código
• Compiladores
• Arquivos de dados de produtos
• Publicações técnicas de produtos
O gerenciamento de configurações de produtos de trabalho pode ser

feito em diversos níveis de granularidade. Veja a definição de “item de
configuração” no Apêndice B, o glossário. Os itens de configuração
podem ser decompostos em componentes de configuração e unidades
de configuração. Somente o termo “item de configuração” é utilizado
nesta área de processo. Portanto, nestas práticas, “item de
configuração” pode ser interpretado como um “componente de
configuração” ou “unidade de configuração”, conforme for apropriado.
[PA159.N103]
As baselines fornecem uma base estável para a evolução contínua dos

itens de configuração. Veja a definição para “baseline” no Apêndice B,
o glossário. [PA159.N104]
Um exemplo de uma baseline é uma descrição de produto

aprovada que inclui versões internamente consistentes de
requisitos, matrizes de rastreabilidade de requisitos, design,
itens específicos da disciplina e documentação para o
usuário final. [PA159.N110]
As baselines são acrescentadas ao sistema de gerenciamento de

configurações conforme são desenvolvidas. As mudanças nas
baselines e a liberação de produtos de trabalho construídos a partir do
sistema de gerenciamento de configurações são sistematicamente
controladas através do controle de configurações, gerenciamento de
mudanças e funções de auditoria de configurações do gerenciamento
de configurações. [PA159.N105]
Nível de Maturidade: 2, Gerenciamento de Configurações 209

CMMI-SE/SW, v1.1
Esta área de processo se aplica não somente ao gerenciamento de

configurações em projetos, mas também ao gerenciamento de
configurações dos produtos de trabalho da organização como os
padrões, procedimentos e bibliotecas de reutilização. [PA159.N106]
O gerenciamento de configurações está focado no controle rigoroso

dos aspectos gerenciais e técnicos dos produtos de trabalho, incluindo
o sistema entregue. [PA159.N107]
Esta área de processo cobre as práticas para a execução da função de

gerenciamento de configurações e é aplicável a todos os produtos de
trabalho que são colocados sob o gerenciamento de configurações.
[PA159.N108]

maiores informações sobre o desenvolvimento de planos e estruturas
de decomposição de trabalho (WBS), que podem ser úteis na definição
de itens de configurações. [PA159.R101]
Veja a área de processo de Análises de Causas e Resoluções para

obter maiores informações sobre o método a ser utilizado para analisar
o impacto das solicitações de mudanças e o método a ser utilizado
para avaliar as mudanças. [PA159.R102]

obter maiores informações sobre análises de desempenho e ações
corretivas. [PA159.R103]
SG 1 Estabelecer Baselines [PA159.IG101]
Baselines de produtos de trabalho identificados são estabelecidas.
SG 2 Rastrear e Controlar Mudanças [PA159.IG102]
As mudanças nos produtos de trabalho sob gerenciamento de

configurações são rastreadas e controladas.
SG 3 Estabelecer a Integridade [PA159.IG103]
A integridade das baselines é estabelecida e mantida.

CMMI-SE/SW, v1.1
SG 1 Estabelecer Baselines [PA159.IG101]
SP 1.1 Identificar Itens de Configurações

SP 1.2 Estabelecer um Sistema de Gerenciamento de Configurações
SP 1.3 Criar ou Liberar Baselines
SG 2 Rastrear e Controlar Mudanças [PA159.IG102]
SP 2.1 Rastrear Solicitações de Mudanças

SP 2.2 Controlar Itens de Configurações
SG 3 Estabelecer a Integridade [PA159.IG103]
SP 3.1 Estabelecer os Registros de Gerenciamento de Configurações

SP 3.2 Executar Auditorias de Configurações



CMMI-SE/SW, v1.1
SG 1 Estabelecer Baselines
Baselines dos produtos de trabalho identificados são estabelecidas.

[PA159.IG101]
As práticas específicas para o estabelecimento de baselines são

cobertas por esta meta específica. As práticas específicas sob a meta
específica Rastrear e Controlar Mudanças servem para manter as
baselines. As práticas específicas da meta específica Estabelecer a
Integridade documentam e fazem a auditoria da integridade das
baselines. [PA159.IG101.N101]
SP 1.1 Identificar Itens de Configurações

Identificar os itens de configurações, componentes e produtos
de trabalho relacionados que serão colocados sob o
gerenciamento de configurações. [PA159.IG101.SP101]
A identificação de configurações é a seleção, criação e especificação

do seguinte: [PA159.IG101.SP101.N101]
• Produtos que serão entregues ao cliente

• Produtos de trabalho internos definidos
• Produtos adquiridos
• Ferramentas
• Outros itens que são utilizados na criação e descrição destes
produtos de trabalho
Os itens sob gerenciamento de configurações incluirão os documentos

de especificações e interfaces que definem os requisitos para o
produto. Outros documentos, como resultados de testes, também
podem ser incluídos, dependendo de sua criticidade na definição do
produto. [PA159.IG101.SP101.N104]
Um “item de configuração” é uma entidade definida para

gerenciamento de configurações, que pode consistir de diversos
produtos de trabalho relacionados que formam uma baseline. Este
agrupamento lógico oferece uma fácil identificação e acesso
controlado. A seleção de produtos de trabalho para gerenciamento de
configurações deverá ser baseada nos critérios estabelecidos durante
o planejamento. [PA159.IG101.SP101.N102]

CMMI-SE/SW, v1.1

Em um sistema que inclui hardware e software, onde o
software representa uma pequena parte do sistema, todo o
software pode ser definido como sendo um único item de
configuração. Em outros casos, o software pode ser
decomposto em diversos itens de configurações.
[PA159.IG101.SP101.N102.AMP101]
Os itens de configurações podem ser decompostos em componentes

de configurações e unidades de configurações. Somente o termo “item
de configuração” é utilizado nesta área de processo. Nestas práticas,
“item de configuração” pode ser interpretado como um “componente de
configuração” ou uma “unidade de configuração”, conforme for
apropriado. Por exemplo, itens de configurações na área de
gerenciamento de requisitos poderiam variar de um requisito individual
a um conjunto de requisitos. [PA159.IG101.SP101.N103]

1. Itens de configurações identificados [PA159.IG101.SP101.W101]
Sub-práticas
1. Selecionar os itens de configurações e os produtos de trabalho
que os compõem com base nos critérios documentados.
[PA159.IG101.SP101.SubP101]
Exemplos de critérios para selecionar os itens de

configurações no nível apropriado de produtos de
trabalho incluem: [PA159.IG101.SP101.SubP101.N102]
• Produtos de trabalho que podem ser utilizados por dois

ou mais grupos
• Produtos de trabalho que se espera que sofram
mudanças ao longo do tempo, seja por causa de erros
ou mudanças nos requisitos
• Produtos de trabalho que são dependentes de outros em
que uma mudança em um obrigará uma mudança nos
outros
• Produtos de trabalho que são críticos para o projeto

CMMI-SE/SW, v1.1
Exemplos de produtos de trabalho que podem ser parte

de um item de configuração incluem:
[PA159.IG101.SP101.SubP101.N101]
• Descrições de processos
• Requisitos
• Design
• Planos e procedimentos de testes
• Resultados de testes
• Descrições de interfaces

Exemplos de produtos de trabalho de software que
podem ser parte de um item de configuração
• Código/módulo
• Ferramentas (por exemplo, compiladores)
2. Atribuir identificadores únicos para os itens de configurações.

[PA159.IG101.SP101.SubP102]
3. Especificar as características importantes de cada item de

configuração. [PA159.IG101.SP101.SubP103]
Exemplos de características de itens de configurações

incluem o autor, o tipo de arquivo ou documento e a
linguagem de programação para os arquivos de código
de software. [PA159.IG101.SP101.SubP103.N101]
4. Especificar quando cada item de configuração será colocado sob

gerenciamento de configurações. [PA159.IG101.SP101.SubP104]
Exemplos de critérios para a definição de quando os

produtos de trabalho serão colocados sob gerenciamento
de configurações incluem: [PA159.IG101.SP101.SubP104.N101]
• Etapa do ciclo de vida do projeto

• Quando o produto de trabalho estiver pronto para ser
testado
• Grau de controle desejado para o produto de trabalho
• Limitações de custo e cronograma
• Requisitos de clientes

CMMI-SE/SW, v1.1
5. Identificar o proprietário responsável por cada item de

configuração. [PA159.IG101.SP101.SubP105]
SP 1.2 Estabelecer um Sistema de Gerenciamento de Configurações

Estabelecer e manter um sistema de gerenciamento de
configurações e gerenciamento de mudanças para controlar os
produtos de trabalho. [PA159.IG101.SP102]
Um sistema de gerenciamento de configurações inclui o meio de

armazenagem, os procedimentos e as ferramentas para acesso ao
sistema de configurações. [PA159.IG101.SP102.N101]
Um sistema de gerenciamento de mudanças inclui o meio de

armazenagem, os procedimentos e as ferramentas para o registro e
acesso às solicitações de mudanças. [PA159.IG101.SP102.N102]

1. Sistema de gerenciamento de configurações com os produtos de
trabalho controlados [PA159.IG101.SP102.W101]
2. Procedimentos de controle de acesso ao sistema de

gerenciamento de configurações [PA159.IG101.SP102.W102]
3. Banco de dados de solicitações de mudanças [PA159.IG101.SP102.W103]
Sub-práticas
1. Estabelecer um mecanismo para gerenciar diversos níveis de
controle de gerenciamento de configurações. [PA159.IG101.SP102.SubP101]
Exemplos de situações que levam a múltiplos níveis de

controle incluem: [PA159.IG101.SP102.SubP101.N101]
• Diferenças nos níveis de controle necessários em

diferentes momentos no ciclo de vida do projeto (por
exemplo, um controle mais forte conforme o produto
amadurece)
• Diferenças nos níveis de controle necessários para
diferentes tipos de sistemas (por exemplo, sistemas
somente de software versus sistemas que incluem
hardware e software)
• Diferenças nos níveis de controle necessários para
satisfazer os requisitos de privacidade e segurança para
os itens de configurações
2. Armazenar e recuperar itens de configurações no sistema de

gerenciamento de configurações. [PA159.IG101.SP102.SubP102]

CMMI-SE/SW, v1.1
Exemplos de sistemas de gerenciamento de configurações

• Sistemas dinâmicos (ou do desenvolvedor) contêm

componentes atualmente sendo criados ou revisados. Eles
estão no espaço de trabalho do desenvolvedor e são
controlados por ele. Os itens de configurações em um
sistema dinâmico estão sob controle de versões.
• Sistemas mestres (ou controlados) contêm baselines
atuais e mudanças feitas a elas. Os itens de configurações
em um sistema mestre estão sob gerenciamento
completo de configurações, conforme descrito nesta área
de processo.
• Sistemas estáticos contêm arquivos de diversas baselines
liberadas para uso. Sistemas estáticos estão sob
gerenciamento completo de configurações, conforme
descrito nesta área de processo.
3. Compartilhar e transferir itens de configurações entre níveis de
controle dentro do sistema de gerenciamento de configurações.
[PA159.IG101.SP102.SubP103]
4. Armazenar e recuperar versões arquivadas de itens de

configurações. [PA159.IG101.SP102.SubP104]
5. Armazenar, atualizar e recuperar registros de gerenciamento de

6. Criar relatórios de gerenciamento de configurações a partir do

sistema de gerenciamento de configurações. [PA159.IG101.SP102.SubP106]
7. Preservar o conteúdo do sistema de gerenciamento de

Exemplos de funções de preservação do sistema de

gerenciamento de configurações incluem:
[PA159.IG101.SP102.SubP107.N101]
• Backups e restaurações de arquivos de gerenciamento

de configurações
• Arquivamento de arquivos de gerenciamento de
configurações
• Recuperação de erros de gerenciamento de
configurações
8. Revisar a estrutura de gerenciamento de configurações, conforme


CMMI-SE/SW, v1.1
SP 1.3 Criar ou Liberar Baselines

Criar ou liberar baselines para uso interno e para entrega ao
cliente. [PA159.IG101.SP103]
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. [PA159.IG101.SP103.N101]

Liberar uma baseline envolver 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”. [PA159.IG101.SP103.N101.AMP101]

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”.
[PA159.IG101.SP103.N101.AMP102]

1. Baselines [PA159.IG101.SP103.W101]
2. Descrições de baselines [PA159.IG101.SP103.W102]
Sub-práticas
1. Obter autorização do comitê de controle de configurações
(configuration control board - CCB) antes de criar ou liberar
baselines de itens de configurações. [PA159.IG101.SP103.SubP101]

CMMI-SE/SW, v1.1
2. Criar ou liberar baselines somente a partir de itens de

configurações do sistema de gerenciamento de configurações.
[PA159.IG101.SP103.SubP102]

Assegurar que os itens de configurações são construídos no
desenho correto. [PA159.IG101.SP103.SubP102.AMP101]
3. Documentar o conjunto de itens de configurações que estão

contidos em uma baseline. [PA159.IG101.SP103.SubP103]
4. Tornar o conjunto atual de baselines prontamente disponível.

[PA159.IG101.SP103.SubP104]
SG 2 Rastrear e Controlar Mudanças
As mudanças nos produtos de trabalho sob gerenciamento de

configurações são rastreadas e controladas. [PA159.IG102]
As práticas específicas sob esta meta específica servem para manter

as baselines, depois que estas foram estabelecidas pelas práticas
específicas sob a meta específica Estabelecer Baselines. [PA159.IG102.N101]
SP 2.1 Rastrear Solicitações de Mudanças

Rastrear as solicitações de mudanças para os itens de
configurações. [PA159.IG102.SP101]
As solicitações de mudanças tratam não somente dos requisitos novos

ou modificados, mas também de falhas e defeitos nos produtos de
trabalho. [PA159.IG102.SP101.N101]
As solicitações de mudanças são analisadas para determinar o impacto

que a mudança terá no produto de trabalho, produtos de trabalho
relacionados e cronograma e orçamento. [PA159.IG102.SP101.N102]

1. Solicitações de mudanças [PA159.IG102.SP101.W101]
Sub-práticas
1. Iniciar e registrar as solicitações de mudanças no banco de dados
de solicitações de mudanças. [PA159.IG102.SP101.SubP101]
2. Analisar o impacto das mudanças e correções propostas nas

solicitações de mudanças. [PA159.IG102.SP101.SubP102]

CMMI-SE/SW, v1.1
As mudanças são avaliadas através de atividades que

asseguram que elas estejam consistentes com todos os
requisitos técnicos e do projeto. [PA159.IG102.SP101.SubP102.N101]
As mudanças são avaliadas com relação ao seu impacto

além dos requisitos do projeto ou contrato imediatos.
Mudanças em um item utilizado em múltiplos produtos
podem resolver uma questão imediata e, ao mesmo
tempo, causar um problema em outras aplicações.
[PA159.IG102.SP101.SubP102.N102]
3. Revisar as solicitações de mudanças que serão tratadas na

próxima baseline com os que serão afetados pelas mudanças e
obter a sua concordância. [PA159.IG102.SP101.SubP103]
Conduzir a revisão da solicitação de mudança com os

participantes apropriados. Registrar a disposição de cada
solicitação de mudança e a justificativa para a decisão,
incluindo os critérios de sucesso, um breve plano de ação
se for apropriado e as necessidades atendidas ou não
atendidas pela mudança. Executar as ações exigidas na
disposição e relatar os resultados para os stakeholders
relevantes. [PA159.IG102.SP101.SubP103.N101]
4. Rastrear os status das solicitações de mudanças até o

encerramento. [PA159.IG102.SP101.SubP104]
As solicitações de mudanças trazidas para o sistema

precisam ser tratadas de maneira profissional e oportuna.
Uma vez que uma solicitação de mudança tenha sido
processada, é crítico fechar a solicitação com a ação
apropriada aprovada, o mais rápido possível. As ações
deixadas em aberto resultam em listas de status maiores
que o necessário, que por sua vez resultam em custos e
confusão adicionais. [PA159.IG102.SP101.SubP104.N101]
SP 2.2 Controlar Itens de Configurações

Controlar mudanças nos itens de configurações. [PA159.IG102.SP102]
O controle é mantido sobre a configuração da baseline de produtos de

trabalho. Este controle inclui rastrear a configuração de cada item de
configuração, aprovar uma nova configuração se necessário e atualizar
a baseline. [PA159.IG102.SP102.N101]

1. Histórico de revisões de itens de configurações [PA159.IG102.SP102.W101]
2. Arquivos das baselines [PA159.IG102.SP102.W102]

CMMI-SE/SW, v1.1
Sub-práticas
1. Controlar mudanças nos itens de configuração durante toda a vida
do produto. [PA159.IG102.SP102.SubP101]
2. Obter a autorização apropriada antes que os itens de

configurações modificados entrem no sistema de gerenciamento
de configurações. [PA159.IG102.SP102.SubP102]
Por exemplo, a autorização pode vir do CCB, do gerente

do projeto ou do cliente. [PA159.IG102.SP102.SubP102.N101]
3. Executar o “check in” e “check out” dos itens de configurações a

partir do sistema de gerenciamento de configurações, para a
incorporação das mudanças de uma maneira que mantenha a
correção e integridade dos itens de configurações.
[PA159.IG102.SP102.SubP103]
Exemplos de etapas de “check-in” e “check-out”

• Confirmar que as revisões foram autorizadas

• Atualizar os itens de configurações
• Arquivar a baseline substituída e recuperar a nova
baseline
4. Executar revisões para assegurar que as mudanças não causaram

efeitos não pretendidos nas baselines (por exemplo, assegurar
que as mudanças não comprometeram a segurança e/ou proteção
do sistema). [PA159.IG102.SP102.SubP104]
5. Registrar as mudanças nos itens de configurações e os motivos

das mudanças, conforme apropriado. [PA159.IG102.SP102.SubP105]
Se uma mudança proposta no produto de trabalho é

aceita, um cronograma é definido para a incorporação da
mudança no produto de trabalho e outras áreas afetadas.
[PA159.IG102.SP102.SubP105.N101]
Mecanismos de controle de configurações podem ser

adaptados para categorias de mudanças. Por exemplo, as
considerações de aprovação podem ser menos estritas
para mudanças de componentes que não afetam outros
componentes. [PA159.IG102.SP102.SubP105.N102]
Itens de configurações modificados são liberados após

revisão e aprovação das mudanças de configurações. As
mudanças não são oficiais até que tenham sido liberadas.
[PA159.IG102.SP102.SubP105.N103]

CMMI-SE/SW, v1.1
SG 3 Estabelecer a Integridade
A integridade das baselines é estabelecida e mantida. [PA159.IG103]
A integridade das baselines, estabelecida pelos processos associados

com a meta específica Estabelecer Baselines e mantida pelos
processos associados com a meta específica Rastrear e Controlar
Mudanças, é garantida pelas práticas específicas sob esta meta
específica. [PA159.IG103.N101]
SP 3.1 Estabelecer Registros de Gerenciamento de Configurações

Estabelecer e manter registros descrevendo os itens de
configurações. [PA159.IG103.SP101]

1. Histórico de revisões de itens de configurações [PA159.IG103.SP101.W101]
2. Log de mudanças [PA159.IG103.SP101.W102]
3. Cópia das solicitações de mudanças [PA159.IG103.SP101.W103]
4. Status de itens de configurações [PA159.IG103.SP101.W104]
5. Diferenças entre baselines [PA159.IG103.SP101.W105]
Sub-práticas
1. Registrar ações de gerenciamento de configurações com detalhes
suficientes, de forma que o conteúdo e status de cada item de
configuração é conhecido e versões anteriores podem ser
recuperadas. [PA159.IG103.SP101.SubP101]
2. Assegurar que os stakeholders relevantes têm acesso e

conhecimento do status da configuração dos itens de
Exemplos de atividades para comunicação de status de

configurações incluem: [PA159.IG103.SP101.SubP102.N101]
• Garantir permissões de acesso aos usuários finais

autorizados
• Tornar cópias de baselines prontamente disponíveis para
usuários finais autorizados
3. Especificar a versão mais atual das baselines. [PA159.IG103.SP101.SubP103]
4. Identificar a versão dos itens de configurações que constituem

uma baseline específica. [PA159.IG103.SP101.SubP104]
Nível de Maturidade: 2, Gerenciamento de Co

Sprache

Willkommen bei Scribd!

CMMI em Português

Hochgeladen von

Dokumentinformationen

Datum des Uploads

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Beschreibung:

Copyright:

Verfügbare Formate

CMMI em Português

Hochgeladen von

Beschreibung:

Copyright:

Verfügbare Formate

Verwandte Titel

em

O projeto Capability Maturity Model Integration (CMMISM) envolveu

O trabalho do projeto CMMI é patrocinado pelo Departamento de

Organizações da indústria e do governo e o Instituto de Engenharia de

A equipe do projeto CMMI trabalhou para oferecer um direcionamento

Desde 1991, têm sido desenvolvidos CMMs para uma grande

Embora estes modelos tenham provado ser úteis para muitas

O projeto do CMM IntegrationSM foi montado para solucionar o

Desenvolver um conjunto de modelos integrados envolveu mais que

Usando como material fonte informações de modelos populares e bem

Durante a fase de desenvolvimento do projeto CMMI, a missão da

O CMMI versão 0.2 foi publicamente revisado e utilizado em atividades

Muitas pessoas talentosas estiveram envolvidas como parte da equipe

O Grupo de Direcionamento direciona e aprova os planos da Equipe de

A Equipe de Produto escreve, revisa, reexamina, discute e chega a

O Comitê de Controle de Configuração tem sido o mecanismo oficial

O grupo de organizações de Stakeholders/Revisores forneceu valiosas

No Apêndice E estão listados os membros atuais e eméritos dos quatro

Onde Procurar Informações Adicionais

Você pode encontrar informações adicionais, como o público alvo,

Sugestões para melhorar o CMMI Product Suite são bem-vindas. Veja

Se tiver perguntas, envie um e-mail para cmmi-

Nível de Maturidade 4: Gerenciado Quantitativamente 14

4 Características Comuns, Metas Genéricas e Práticas Genéricas 37

6 Utilizando os Modelos CMMI 76

C. Elementos Exigidos e Esperados do Modelo 498

Um modelo é uma representação simplificada do mundo real. Os

Como os outros CMMs, os modelos integrados de maturidade de

Sobre os Modelos CMMI

Um processo é um ponto de apoio da melhoria sustentada de uma

O conjunto de produtos CMMI (CMMI Product Suite) contém e é

Sua organização pode utilizar um modelo CMMI para ajudar a definir os

Utilize uma opinião profissional para interpretar as práticas específicas

Selecionando um Modelo CMMI

Existem diversos modelos CMMI disponíveis, gerados a partir do CMMI

Você deve selecionar uma representação, contínua ou em estágios, e

Representações: Contínua ou em Estágios?

Existem muitas razões válidas para selecionar uma representação ou

Se você escolher a representação contínua para sua organização,

• Permitirá que você selecione a seqüência de melhorias que melhor

• Suportará uma fácil comparação de melhoria de processos para a

Se você escolher a representação em estágios para a sua organização,

• Oferecerá uma seqüência comprovada de melhorias, começando

Quer sejam utilizadas para melhoria de processos ou avaliações,

Que Modelo Integrado Escolher?

Atualmente existem três áreas de conhecimento disponíveis, quando

Este texto fará referências a estas áreas de conhecimento como

Disciplinas: Qual é a Diferença?

Dependendo da disciplina que selecionar para seu modelo CMMI, leia

A engenharia de sistemas cobre o desenvolvimento de sistemas

Quando você seleciona engenharia de sistemas para o seu modelo,

A engenharia de software cobre o desenvolvimento de sistemas de

Quando você seleciona engenharia de software para o seu modelo,

Desenvolvimento Integrado de Produtos e Processos

O Desenvolvimento Integrado de Produtos e Processos (Integrated

Quando você seleciona o IPPD como seu modelo, este conterá as

A Equipe de Produto do CMMI recomenda que você selecione a

O Conteúdo dos Modelos CMMI