Você está na página 1de 591

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
Representação em Estágios

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
Representação em Estágios

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
Representação em Estágios

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
Representação em Estágios

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
Representação em Estágios

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
Representação em Estágios

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
Representação em Estágios

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
Representação em Estágios

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
Representação em Estágios

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
Representação em Estágios

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
Representação em Estágios

• 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

Representação em Estágios

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
Representação em Estágios

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
Representação em Estágios

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
Representação em Estágios

• 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
Representação em Estágios

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
Representação em Estágios

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
Representação em Estágios

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
Representação em Estágios

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
Representação em Estágios

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
Representação em Estágios

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
Representação em Estágios

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

No nível de maturidade 3, uma organização atingiu todas as metas


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
Representação em Estágios

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

No nível de maturidade 4, uma organização atingiu todas as metas


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
Representação em Estágios

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

No nível de maturidade 5, uma organização atingiu todas as metas


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
Representação em Estágios

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
Representação em Estágios

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
Representação em Estágios

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
Representação em Estágios

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
Representação em Estágios

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]

Características Comuns

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
Representação em Estágios

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]

Práticas Genéricas

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
Representação em Estágios

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
Representação em Estágios

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
Representação em Estágios

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
Representação em Estágios

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
Representação em Estágios

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
Representação em Estágios

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
Representação em Estágios

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
Representação em Estágios

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
Representação em Estágios

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
Representação em Estágios

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
Representação em Estágios

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
Representação em Estágios

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
Representação em Estágios

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
Representação em Estágios

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
Representação em Estágios

36 Visão Geral
CMMI-SE/SW, v1.1
Representação em Estágios

4 Características Comuns, Metas Genéricas e


Práticas Genéricas

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
Representação em Estágios

• 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
Representação em Estágios

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
Representação em Estágios

Características Comuns

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
Representação em Estágios

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
Representação em Estágios

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
Representação em Estágios

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
Representação em Estágios

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
Representação em Estágios

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


processo. [GP106.SubP102]

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
Representação em Estágios

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
Representação em Estágios

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
Representação em Estágios

• 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
Representação em Estágios

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
processo. [GP110.SubP101]

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
Representação em Estágios

• 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
Representação em Estágios

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
Representação em Estágios

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
Representação em Estágios

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
Representação em Estágios

• 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
Representação em Estágios

• 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
Representação em Estágios

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
Representação em Estágios

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]

A Figura 3 oferece uma visão geral das interações entre as áreas de


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
Representação em Estágios

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
Representação em Estágios

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
Representação em Estágios

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]

A Figura 4 oferece uma visão geral das interações entre as áreas de


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
Representação em Estágios

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
Representação em Estágios

A Figura 5 oferece uma visão geral das interações entre as áreas de


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
Veja o Apêndice B para uma lista completa de abreviações das áreas de processos.
62 Visão Geral
CMMI-SE/SW, v1.1
Representação em Estágios

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
Representação em Estágios

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
Organizacional para Integração (Organizational Environment for
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
Representação em Estágios

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]

A Figura 6 oferece uma visão geral das interações entre as áreas de


processos de Engenharia.8 [FM102.HDA104.HDB102.T104]

8
Veja o Apêndice B para uma lista completa de abreviações das áreas de processos.
Visão Geral 65
CMMI-SE/SW, v1.1
Representação em Estágios

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
Representação em Estágios

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
Representação em Estágios

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
Representação em Estágios

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
Representação em Estágios

• 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
Organizacional para Integração (Organizational Environment for
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]

A Figura 7 oferece uma visão geral das interações entre as áreas de


processos básicas de Suporte e com todas as outras áreas de
processos.9 [FM102.HDA105.HDB102.T102]

9
Veja o Apêndice B para uma lista completa de abreviações das áreas de processos.
70 Visão Geral
CMMI-SE/SW, v1.1
Representação em Estágios

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
Representação em Estágios

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]

A Figura 8 oferece uma visão geral das interações entre as áreas de


processos avançadas de Suporte e com todas as outras áreas de
processos.10 [FM102.HDA105.HDB103.T102]

10
Veja o Apêndice B para uma lista completa de abreviações das áreas de processos.
72 Visão Geral
CMMI-SE/SW, v1.1
Representação em Estágios

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
Representação em Estágios

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
Representação em Estágios

Visão Geral 75
CMMI-SE/SW, v1.1
Representação em Estágios

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
Representação em Estágios

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
Representação em Estágios

• 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
Representação em Estágios

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
Representação em Estágios

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
Representação em Estágios

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
Representação em Estágios

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
Representação em Estágios

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
Representação em Estágios

• 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
Representação em Estágios

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
Representação em Estágios

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
Representação em Estágios

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
Representação em Estágios

88 Visão Geral
CMMI-SE/SW, v1.1
Representação em Estágios

7 Áreas de Processos

89
CMMI-SE/SW, v1.1
Representação em Estágios

90
CMMI-SE/SW, v1.1
Representação em Estágios

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
Representação em Estágios

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
Representação em Estágios

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

Metas Específicas e Genéricas

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]

O processo é institucionalizado como um processo gerenciado.

Nível de Maturidade: 2, Gerenciamento de Requisitos 93


CMMI-SE/SW, v1.1
Representação em Estágios

(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]

O processo é institucionalizado como um processo definido.

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
GG 2 Institucionalizar um Processo Gerenciado [CL103.GL101]

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).
GG 3 Institucionalizar um Processo Definido [CL104.GL101]

GP 3.1 Estabelecer um Processo Definido


GP 3.2 Coletar Informações de Melhorias

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

94 Nível de Maturidade: 2, Gerenciamento de Requisitos


CMMI-SE/SW, v1.1
Representação em Estágios

• 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

Veja a área de processo de Soluções Técnicas para obter maiores


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

Veja a área de processo de Desenvolvimento de Requisitos para obter


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

Veja a área de processo de Monitoramento e Controle do Projeto para


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]

Produtos de Trabalho Típicos


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

Nível de Maturidade: 2, Gerenciamento de Requisitos 95


CMMI-SE/SW, v1.1
Representação em Estágios

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]

Veja a área de processo de Monitoramento e Controle do Projeto para


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

96 Nível de Maturidade: 2, Gerenciamento de Requisitos


CMMI-SE/SW, v1.1
Representação em Estágios

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]

Produtos de Trabalho Típicos


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]

Veja a área de processo de Gerenciamento de Configurações para


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]

Nível de Maturidade: 2, Gerenciamento de Requisitos 97


CMMI-SE/SW, v1.1
Representação em Estágios

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]

Produtos de Trabalho Típicos


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]

98 Nível de Maturidade: 2, Gerenciamento de Requisitos


CMMI-SE/SW, v1.1
Representação em Estágios

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]

Produtos de Trabalho Típicos


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]

Veja a área de processo de Monitoramento e Controle do Projeto para


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]

Nível de Maturidade: 2, Gerenciamento de Requisitos 99


CMMI-SE/SW, v1.1
Representação em Estágios

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]

Produtos de Trabalho Típicos


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]

GG 2 Institucionalizar um Processo Gerenciado [CL103.GL101]

O processo é institucionalizado como um processo gerenciado.

Compromisso

GP 2.1 (CO 1) Estabelecer uma Política Organizacional


Estabelecer e manter uma política organizacional para o
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]

100 Nível de Maturidade: 2, Gerenciamento de Requisitos


CMMI-SE/SW, v1.1
Representação em Estágios

Habilitações

GP 2.2 (AB 1) Planejar o Processo


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]

GP 2.3 (AB 2) Fornecer Recursos


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

GP 2.4 (AB 3) Atribuir Responsabilidades


Atribuir responsabilidades e autoridade para a execução do
processo, desenvolvimento dos produtos de trabalho e
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]

Nível de Maturidade: 2, Gerenciamento de Requisitos 101


CMMI-SE/SW, v1.1
Representação em Estágios

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

GP 2.6 (DI 1) Gerenciar Configuraçõ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

GP 2.7 (DI 2) Identificar e Envolver os Stakeholders Relevantes


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]

102 Nível de Maturidade: 2, Gerenciamento de Requisitos


CMMI-SE/SW, v1.1
Representação em Estágios

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

GP 2.8 (DI 3) Monitorar e Controlar o Processo


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)

Verificações da Implementação

GP 2.9 (VE 1) Avaliar Objetivamente a Aderência


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

Nível de Maturidade: 2, Gerenciamento de Requisitos 103


CMMI-SE/SW, v1.1
Representação em Estágios

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

GG 3 Institucionalizar um Processo Definido [CL104.GL101]

O processo é institucionalizado como um processo definido.

GP 3.1 Estabelecer um Processo Definido


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

GP 3.2 Coletar Informações de Melhorias


Coletar produtos de trabalho, medidas, resultados de medições
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]

104 Nível de Maturidade: 2, Gerenciamento de Requisitos


CMMI-SE/SW, v1.1
Representação em Estágios

PLANEJAMENTO DO PROJETO
Nível de Maturidade 2

Objetivo

O objetivo do Planejamento do Projeto (Project Planning) é estabelecer


e manter planos que definem as atividades do projeto. [PA163]

Notas Introdutórias

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
Representação em Estágios

Áreas de Processos Relacionadas

Veja a área de processo de Desenvolvimento de Requisitos para obter


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]

Veja a área de processo de Gerenciamento de Requisitos para obter


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]

Veja a área de processo de Soluções Técnicas para obter maiores


informações sobre a transformação de requisitos em soluções de
produto e de componentes de produtos. [PA163.R104]

Metas Específicas e Genéricas

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.

GG 2 Institucionalizar um Processo Gerenciado [CL103.GL101]

O processo é institucionalizado como um processo gerenciado.

106 Nível de Maturidade: 2, Planejamento do Projeto


CMMI-SE/SW, v1.1
Representação em Estágios

(A meta seguinte não é exigida para o nível de maturidade 2, mas é exigida para o nível de
maturidade 3 e superiores).

GG 3 Institucionalizar um Processo Definido [CL104.GL101]

O processo é institucionalizado como um processo definido.

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
GG 2 Institucionalizar um Processo Gerenciado [CL103.GL101]

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 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 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
nível de maturidade 2, mas são exigidas e esperadas para uma classificação de nível de
maturidade 3 e superiores).
GG 3 Institucionalizar um Processo Definido [CL104.GL101]

GP 3.1 Estabelecer um Processo Definido


GP 3.2 Coletar Informações de Melhorias

Nível de Maturidade: 2, Planejamento do Projeto 107


CMMI-SE/SW, v1.1
Representação em Estágios

Práticas Específicas por Meta

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]

108 Nível de Maturidade: 2, Planejamento do Projeto


CMMI-SE/SW, v1.1
Representação em Estágios

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]

Produtos de Trabalho Típicos


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]

Nível de Maturidade: 2, Planejamento do Projeto 109


CMMI-SE/SW, v1.1
Representação em Estágios

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

110 Nível de Maturidade: 2, Planejamento do Projeto


CMMI-SE/SW, v1.1
Representação em Estágios

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]

Produtos de Trabalho Típicos


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]

Nível de Maturidade: 2, Planejamento do Projeto 111


CMMI-SE/SW, v1.1
Representação em Estágios

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]

Para Engenharia de Software


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]

112 Nível de Maturidade: 2, Planejamento do Projeto


CMMI-SE/SW, v1.1
Representação em Estágios

Para Engenharia de Sistemas


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]

Produtos de Trabalho Típicos


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]

Nível de Maturidade: 2, Planejamento do Projeto 113


CMMI-SE/SW, v1.1
Representação em Estágios

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]

Produtos de Trabalho Típicos


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]

Para Engenharia de Software


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]

Para Engenharia de Software


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]

114 Nível de Maturidade: 2, Planejamento do Projeto


CMMI-SE/SW, v1.1
Representação em Estágios

• identificar os recursos computacionais críticos para o


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

Para Engenharia de Software


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

Para Engenharia de Software


Exemplos de recursos de engenharia de software
incluem: [PA163.IG101.SP104.SubP102.N101.AMP103]

• 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

Nível de Maturidade: 2, Planejamento do Projeto 115


CMMI-SE/SW, v1.1
Representação em Estágios

• 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]

116 Nível de Maturidade: 2, Planejamento do Projeto


CMMI-SE/SW, v1.1
Representação em Estágios

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]

Produtos de Trabalho Típicos


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]

Nível de Maturidade: 2, Planejamento do Projeto 117


CMMI-SE/SW, v1.1
Representação em Estágios

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]

118 Nível de Maturidade: 2, Planejamento do Projeto


CMMI-SE/SW, v1.1
Representação em Estágios

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]

Veja a área de processo de Gerenciamento de Riscos para obter


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

Produtos de Trabalho Típicos


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]

Nível de Maturidade: 2, Planejamento do Projeto 119


CMMI-SE/SW, v1.1
Representação em Estágios

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

120 Nível de Maturidade: 2, Planejamento do Projeto


CMMI-SE/SW, v1.1
Representação em Estágios

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]

Produtos de Trabalho Típicos


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]

Nível de Maturidade: 2, Planejamento do Projeto 121


CMMI-SE/SW, v1.1
Representação em Estágios

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]

122 Nível de Maturidade: 2, Planejamento do Projeto


CMMI-SE/SW, v1.1
Representação em Estágios

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]

Produtos de Trabalho Típicos


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]

Nível de Maturidade: 2, Planejamento do Projeto 123


CMMI-SE/SW, v1.1
Representação em Estágios

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]

Produtos de Trabalho Típicos


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]

124 Nível de Maturidade: 2, Planejamento do Projeto


CMMI-SE/SW, v1.1
Representação em Estágios

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]

Nível de Maturidade: 2, Planejamento do Projeto 125


CMMI-SE/SW, v1.1
Representação em Estágios

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]

Produtos de Trabalho Típicos


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]

Para Engenharia de Sistemas


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]

126 Nível de Maturidade: 2, Planejamento do Projeto


CMMI-SE/SW, v1.1
Representação em Estágios

Para Engenharia de Sistemas


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 Engenharia de Software


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

Nível de Maturidade: 2, Planejamento do Projeto 127


CMMI-SE/SW, v1.1
Representação em Estágios

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]

Produtos de Trabalho Típicos


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]

Produtos de Trabalho Típicos


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

128 Nível de Maturidade: 2, Planejamento do Projeto


CMMI-SE/SW, v1.1
Representação em Estágios

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]

Produtos de Trabalho Típicos


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]

Produtos de Trabalho Típicos


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]
Nível de Maturidade: 2, Planejamento do Projeto 129
CMMI-SE/SW, v1.1
Representação em Estágios

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]

GG 2 Institucionalizar um Processo Gerenciado [CL103.GL101]

O processo é institucionalizado como um processo gerenciado.

Compromisso

GP 2.1 (CO 1) Estabelecer uma Política Organizacional


Estabelecer e manter uma política organizacional para o
planejamento e execução do processo de planejamento do
projeto. [GP103]

130 Nível de Maturidade: 2, Planejamento do Projeto


CMMI-SE/SW, v1.1
Representação em Estágios

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

GP 2.2 (AB 1) Planejar o Processo


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]

GP 2.3 (AB 2) Fornecer Recursos


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)

Nível de Maturidade: 2, Planejamento do Projeto 131


CMMI-SE/SW, v1.1
Representação em Estágios

Exemplos de outros recursos fornecidos incluem as seguintes


ferramentas: [PA163.EL106]

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

GP 2.4 (AB 3) Atribuir Responsabilidades


Atribuir responsabilidades e autoridade para a execução do
processo, desenvolvimento dos produtos de trabalho e
fornecimento dos serviços do processo de planejamento do
projeto. [GP106]

GP 2.5 (AB 4) Treinar as Pessoas


Treinar as pessoas na execução e suporte ao processo de
planejamento do projeto, conforme necessário. [GP107]

Elaboração:

Exemplos de tópicos de treinamento incluem: [PA163.EL108]

• Estimativas
• Orçamentos
• Negociação
• Identificação e análise de riscos
• Gerenciamento de dados
• Planejamento
• Cronogramas

Implementações

GP 2.6 (DI 1) Gerenciar Configurações


Colocar os produtos de trabalho definidos do processo de
planejamento do projeto sob os níveis apropriados de
gerenciamento de configurações. [GP109]

132 Nível de Maturidade: 2, Planejamento do Projeto


CMMI-SE/SW, v1.1
Representação em Estágios

Elaboração:

Exemplos de produtos de trabalho colocados sob


gerenciamento de configurações incluem: [PA163.EL110]

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


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

GP 2.7 (DI 2) Identificar e Envolver os Stakeholders Relevantes


Identificar e envolver os stakeholders relevantes do processo
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


incluem: [PA163.EL119]

• 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

Nível de Maturidade: 2, Planejamento do Projeto 133


CMMI-SE/SW, v1.1
Representação em Estágios

GP 2.8 (DI 3) Monitorar e Controlar o Processo


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:

Exemplos de medidas utilizadas no monitoramento e


controle incluem: [PA163.EL113]

• Número de revisões do plano


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

Verificações

GP 2.9 (VE 1) Avaliar Objetivamente a Aderência


Avaliar objetivamente a aderência do processo de
planejamento do projeto contra sua descrição de processo,
padrões e procedimentos e tratar as não conformidades. [GP113]

Elaboração:

Exemplos de atividades revisadas incluem: [PA163.EL115]

• Estabelecer estimativas
• Desenvolver um plano de projeto
• Obter compromissos ao plano do projeto

Exemplos de produtos de trabalho revisados incluem:


[PA163.EL117]

• WBS
• Plano do projeto
• Plano de gerenciamento de dados
• Plano de envolvimento de stakeholders

134 Nível de Maturidade: 2, Planejamento do Projeto


CMMI-SE/SW, v1.1
Representação em Estágios

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


Revisar as atividades, status e resultados do processo de
planejamento do projeto com o nível mais alto de gerência e
resolver questões. [GP112]

(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 para uma classificação de nível de maturidade 3 e
superiores).

GG 3 Institucionalizar um Processo Definido [CL104.GL101]

O processo é institucionalizado como um processo definido.

GP 3.1 Estabelecer um Processo Definido


Estabelecer e manter a descrição de um processo definido de
planejamento do projeto. [GP114]

GP 3.2 Coletar Informações de Melhorias


Coletar produtos de trabalho, medidas, resultados de medições
e informações de melhorias derivados do planejamento e
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]

Nível de Maturidade: 2, Planejamento do Projeto 135


CMMI-SE/SW, v1.1
Representação em Estágios

MONITORAMENTO E CONTROLE DO PROJETO


Nível de Maturidade 2

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]

Notas Introdutórias

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]

Áreas de Processos Relacionadas

Veja a área de processo de Planejamento do Projeto para obter


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
Representação em Estágios

Metas Específicas e Genéricas

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.

GG 2 Institucionalizar um Processo Gerenciado [CL103.GL101]

O processo é institucionalizado como um processo gerenciado.

(A seguinte meta não é exigida para o nível de maturidade 2, mas é exigida para o nível de
maturidade 3 e superiores).

GG 3 Institucionalizar um Processo Definido [CL104.GL101]

O processo é institucionalizado como um processo definido.

Tabela de Relacionamentos Práticas-Metas

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
GG 2 Institucionalizar um Processo Gerenciado [CL103.GL101]

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

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


CMMI-SE/SW, v1.1
Representação em Estágios

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 Status com o Nível Mais Alto de Gerência

(A seguinte meta 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).
GG 3 Institucionalizar um Processo Definido [CL104.GL101]

GP 3.1 Estabelecer um Processo Definido


GP 3.2 Coletar Informações de Melhorias

Práticas Específicas por Meta

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]

Produtos de Trabalho Típicos


1. Registros de desempenho do projeto [PA162.IG101.SP101.W101]

2. Registros de desvios significativos [PA162.IG101.SP101.W102]

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


CMMI-SE/SW, v1.1
Representação em Estágios

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]

Veja a área de processo de Planejamento do Projeto para obter


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]

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


CMMI-SE/SW, v1.1
Representação em Estágios

Para Engenharia de Software


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]

Veja a área de processo de Planejamento do Projeto para obter


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]

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


CMMI-SE/SW, v1.1
Representação em Estágios

SP 1.2 Monitorar Compromissos


Monitorar os compromissos contra os identificados no plano
do projeto. [PA162.IG101.SP102]

Produtos de Trabalho Típicos


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
do projeto. [PA162.IG101.SP103]

Veja a área de processo de Planejamento do Projeto para obter


maiores informações sobre a identificação de riscos do projeto.
[PA162.IG101.SP103.R101]

Veja a área de processo de Gerenciamento de Riscos para obter


maiores informações sobre as atividades de gerenciamento de riscos.
[PA162.IG101.SP103.R102]

Produtos de Trabalho Típicos


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]

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


CMMI-SE/SW, v1.1
Representação em Estágios

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]

Produtos de Trabalho Típicos


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]

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


CMMI-SE/SW, v1.1
Representação em Estágios

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]

Produtos de Trabalho Típicos


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]

2. Identificar e documentar questões significativas e seus impactos.


[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
do projeto. [PA162.IG101.SP104]

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

Produtos de Trabalho Típicos


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]

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


CMMI-SE/SW, v1.1
Representação em Estágios

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]

Veja a área de processo de Gerenciamento de Configurações para


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]

Veja a área de processo de Planejamento do Projeto para obter


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]

Produtos de Trabalho Típicos


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]

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


CMMI-SE/SW, v1.1
Representação em Estágios

2. Revisar os compromissos, planos, status e riscos do projeto.


[PA162.IG101.SP105.SubP102]

3. Identificar e documentar questões significativas e seus impactos.


[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]

Produtos de Trabalho Típicos


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]

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


CMMI-SE/SW, v1.1
Representação em Estágios

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]

Veja a área de processo de Planejamento do Projeto para obter


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]

Produtos de Trabalho Típicos


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]

Veja a área de processo de Planejamento do Projeto para obter


maiores informações sobre o plano do projeto, quando o
replanejamento é necessário. [PA162.IG102.SP102.SubP101.R101]

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


CMMI-SE/SW, v1.1
Representação em Estágios

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]

Produtos de Trabalho Típicos


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]

GG 2 Institucionalizar um Processo Gerenciado [CL103.GL101]

O processo é institucionalizado como um processo gerenciado.

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


CMMI-SE/SW, v1.1
Representação em Estágios

Compromisso

GP 2.1 (CO 1) Estabelecer uma Política Organizacional


Estabelecer e manter uma política organizacional para o
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

GP 2.2 (AB 1) Planejar o Processo


Estabelecer e manter o plano para execução do processo de
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]

GP 2.3 (AB 2) Fornecer Recursos


Fornecer recursos adequados para a execução do processo de
monitoramento e controle do projeto, desenvolvimento dos
produtos de trabalho e fornecimento dos serviços do processo.
[GP105]

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


CMMI-SE/SW, v1.1
Representação em Estágios

Elaboração:

Exemplos de recursos fornecidos incluem as seguintes


ferramentas: [PA162.EL103]

• 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

GP 2.4 (AB 3) Atribuir Responsabilidades


Atribuir responsabilidades e autoridade para execução do
processo, desenvolvimento dos produtos de trabalho e
fornecimento dos serviços do processo de monitoramento e
controle do projeto. [GP106]

GP 2.5 (AB 4) Treinar as Pessoas


Treinar as pessoas para a execução e suporte do processo de
monitoramento e controle do projeto, conforme necessário.
[GP107]

Elaboração:

Exemplos de tópicos de treinamento incluem: [PA162.EL104]

• Monitoramento e controle de projetos


• Gerenciamento de riscos
• Gerenciamento de dados

Implementações

GP 2.6 (DI 1) Gerenciar Configurações


Colocar os produtos de trabalho definidos do processo de
monitoramento e controle do projeto sob os níveis apropriados
de gerenciamento de configurações. [GP109]

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


CMMI-SE/SW, v1.1
Representação em Estágios

GP 2.7 (DI 2) Identificar e Envolver os Stakeholders Relevantes


Identificar e envolver os stakeholders relevantes do processo
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]

Exemplos de atividades para o envolvimento de stakeholders


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

GP 2.8 (DI 3) Monitorar e Controlar o Processo


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:

Exemplos de medidas utilizadas no monitoramento e


controle incluem: [PA162.EL105]

• 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)

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


CMMI-SE/SW, v1.1
Representação em Estágios

Verificações da Implementação

GP 2.9 (VE 1) Avaliar Objetivamente a Aderência


Avaliar objetivamente a aderência do processo de
monitoramento e controle do projeto contra sua descrição de
processo, padrões, procedimentos e tratar as não
conformidades. [GP113]

Elaboração:

Exemplos de atividades revisadas incluem: [PA162.EL106]

• Monitorar o desempenho do projeto contra o plano do


projeto
• Gerenciar as ações corretivas até o encerramento

Exemplos de produtos de trabalho revisados incluem:


[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


Revisar as atividades, status e resultados do processo de
monitoramento e controle do projeto com o nível mais alto de
gerência e resolver questões. [GP112]

(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 para uma classificação de nível de maturidade 3 e
superiores).

GG 3 Institucionalizar um Processo Definido [CL104.GL101]

O processo é institucionalizado como um processo definido.

GP 3.1 Estabelecer um Processo Definido


Estabelecer e manter a descrição de um processo definido de
monitoramento e controle do projeto. [GP114]

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


CMMI-SE/SW, v1.1
Representação em Estágios

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 de monitoramento e controle do projeto
para suportar o uso futuro e melhorias nos processos e ativos
de processos da organização. [GP117]

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


CMMI-SE/SW, v1.1
Representação em Estágios

GERENCIAMENTO DE ACORDOS COM FORNECEDORES


Nível de Maturidade 2

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]

Notas Introdutórias

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
Representação em Estágios

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]

Áreas de Processos Relacionadas

Veja a área de processo de Monitoramento e Controle do Projeto para


obter maiores informações sobre como monitorar projetos e tomar as
ações corretivas. [PA166.R101]

Veja a área de processo de Desenvolvimento de Requisitos para obter


maiores informações sobre como definir requisitos. [PA166.R102]

Veja a área de processo de Gerenciamento de Requisitos para obter


maiores informações sobre como gerenciar requisitos, incluindo a
rastreabilidade dos requisitos para produtos adquiridos de
fornecedores. [PA166.R103]

Veja a área de processo de Soluções Técnicas para obter maiores


informações sobre como determinar os produtos e componentes de
produtos que podem ser adquiridos de fornecedores. [PA166.R104]

Metas Específicas e Genéricas

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.

GG 2 Institucionalizar um Processo Gerenciado [CL103.GL101]

O processo é institucionalizado como um processo gerenciado.

154 Nível de Maturidade: 2, Gerenciamento de Acordos com Fornecedores


CMMI-SE/SW, v1.1
Representação em Estágios

(A seguinte meta não é exigida para o nível de maturidade 2, mas é exigida para o nível de
maturidade 3 e superiores).

GG 3 Institucionalizar um Processo Definido [CL104.GL101]

O processo é institucionalizado como um processo definido.

Tabela de Relacionamentos Práticas-Metas

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
GG 2 Institucionalizar um Processo Gerenciado [CL103.GL101]

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 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 Status com 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).
GG 3 Institucionalizar um Processo Definido [CL104.GL101]

GP 3.1 Estabelecer um Processo Definido


GP 3.2 Coletar Informações de Melhorias

Práticas Específicas por Meta

SG 1 Estabelecer Acordos com Fornecedores

Acordos com fornecedores são estabelecidos e mantidos. [PA166.IG101]

Nível de Maturidade: 2, Gerenciamento de Acordos com Fornecedores 155


CMMI-SE/SW, v1.1
Representação em Estágios

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]

Veja a área de processo de Soluções Técnicas para obter maiores


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)

Produtos de Trabalho Típicos


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]

Veja a área de processo de Gerenciamento de Requisitos para obter


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]

156 Nível de Maturidade: 2, Gerenciamento de Acordos com Fornecedores


CMMI-SE/SW, v1.1
Representação em Estágios

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

Produtos de Trabalho Típicos


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]

Veja a área de processo de Gerenciamento de Riscos para obter


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]

Nível de Maturidade: 2, Gerenciamento de Acordos com Fornecedores 157


CMMI-SE/SW, v1.1
Representação em Estágios

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]

Produtos de Trabalho Típicos


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]

158 Nível de Maturidade: 2, Gerenciamento de Acordos com Fornecedores


CMMI-SE/SW, v1.1
Representação em Estágios

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

Nível de Maturidade: 2, Gerenciamento de Acordos com Fornecedores 159


CMMI-SE/SW, v1.1
Representação em Estágios

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]

Veja a área de processo de Monitoramento e Controle do Projeto


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]

Produtos de Trabalho Típicos


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]

160 Nível de Maturidade: 2, Gerenciamento de Acordos com Fornecedores


CMMI-SE/SW, v1.1
Representação em Estágios

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]

Veja a área de processo de Planejamento do Projeto para obter


maiores informações sobre como identificar os riscos do projeto.
[PA166.IG102.SP101.SubP105.R102]

Veja a área de processo de Gerenciamento de Riscos para obter


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]

Nível de Maturidade: 2, Gerenciamento de Acordos com Fornecedores 161


CMMI-SE/SW, v1.1
Representação em Estágios

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]

Veja a área de processo de Monitoramento e Controle do Projeto para


obter maiores informações sobre como monitorar projetos e tomar as
ações corretivas. [PA166.IG102.SP102.R101]

Produtos de Trabalho Típicos


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]

162 Nível de Maturidade: 2, Gerenciamento de Acordos com Fornecedores


CMMI-SE/SW, v1.1
Representação em Estágios

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


acordo com o fornecedor. [PA166.IG102.SP102.SubP103]

Veja a área de processo de Monitoramento e Controle do Projeto


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
acordo com o fornecedor. [PA166.IG102.SP102.SubP104]

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]

Nível de Maturidade: 2, Gerenciamento de Acordos com Fornecedores 163


CMMI-SE/SW, v1.1
Representação em Estágios

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]

Veja a área de processo de Monitoramento e Controle do Projeto


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]

Produtos de Trabalho Típicos


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]

164 Nível de Maturidade: 2, Gerenciamento de Acordos com Fornecedores


CMMI-SE/SW, v1.1
Representação em Estágios

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]

Veja a área de processo de Monitoramento e Controle do Projeto


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]

Produtos de Trabalho Típicos


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]

Nível de Maturidade: 2, Gerenciamento de Acordos com Fornecedores 165


CMMI-SE/SW, v1.1
Representação em Estágios

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]

GG 2 Institucionalizar um Processo Gerenciado [CL103.GL101]

O processo é institucionalizado como um processo gerenciado.

Compromisso

GP 2.1 (CO 1) Estabelecer uma Política Organizacional


Estabelecer e manter uma política organizacional para o
planejamento e execução do processo de gerenciamento de
acordos com fornecedores. [GP103]

Elaboração:

Esta política estabelece as expectativas organizacionais para o


estabelecimento, manutenção e satisfação dos acordos com os
fornecedores. [PA166.EL101]

Habilitações

GP 2.2 (AB 1) Planejar o Processo


Estabelecer e manter o plano para a execução do processo de
gerenciamento de acordos com fornecedores. [GP104]

166 Nível de Maturidade: 2, Gerenciamento de Acordos com Fornecedores


CMMI-SE/SW, v1.1
Representação em Estágios

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]

GP 2.3 (AB 2) Fornecer Recursos


Fornecer recursos adequados para a execução do processo de
gerenciamento de acordos com fornecedores,
desenvolvimento dos produtos de trabalho e fornecimento dos
serviços do processo. [GP105]

Elaboração:

Exemplos de recursos fornecidos incluem as seguintes


ferramentas: [PA166.EL102]

• Listas de fornecedores preferenciais


• Programas de rastreamento de requisitos
• Programas de gerenciamento de projetos e cronogramas

GP 2.4 (AB 3) Atribuir Responsabilidades


Atribuir responsabilidades e autoridade para a execução do
processo, desenvolvimento dos produtos de trabalho e
fornecimento dos serviços do processo de gerenciamento de
acordos com fornecedores. [GP106]

GP 2.5 (AB 4) Treinar as Pessoas


Treinar as pessoas na execução e suporte ao processo de
gerenciamento de acordos com fornecedores, conforme
necessário. [GP107]

Nível de Maturidade: 2, Gerenciamento de Acordos com Fornecedores 167


CMMI-SE/SW, v1.1
Representação em Estágios

Elaboração:

Exemplos de tópicos de treinamento incluem: [PA166.EL103]

• 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

GP 2.6 (DI 1) Gerenciar Configurações


Colocar os produtos de trabalho definidos do processo de
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

GP 2.7 (DI 2) Identificar e Envolver os Stakeholders Relevantes


Identificar e envolver os stakeholders relevantes do processo
de gerenciamento de acordos com fornecedores, conforme
planejado. [GP124]

168 Nível de Maturidade: 2, Gerenciamento de Acordos com Fornecedores


CMMI-SE/SW, v1.1
Representação em Estágios

Elaboração:

Exemplos de atividades de envolvimento de stakeholders


incluem: [PA166.EL109]

• 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

GP 2.8 (DI 3) Monitorar e Controlar o Processo


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:

Exemplos de medidas utilizadas no monitoramento e


controle incluem: [PA166.EL105]

• Quantidade de mudanças feitas nos requisitos para o


fornecedor
• Variação de custo e cronograma por acordo com
fornecedor

Verificações

GP 2.9 (VE 1) Avaliar Objetivamente a Aderência


Avaliar objetivamente a aderência do processo de
gerenciamento de acordos com fornecedores contra sua
descrição de processo, padrões e procedimentos e tratar as
não conformidades. [GP113]

Nível de Maturidade: 2, Gerenciamento de Acordos com Fornecedores 169


CMMI-SE/SW, v1.1
Representação em Estágios

Elaboração:

Exemplos de atividades revisadas incluem: [PA166.EL106]

• Estabelecimento e manutenção de acordos com


fornecedores
• Satisfação de acordos com fornecedores

Exemplos de produtos de trabalho revisados incluem:


[PA166.EL108]

• Plano de Gerenciamento de Acordos com Fornecedores


• Acordos com Fornecedores

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 acordos com fornecedores com o nível mais
alto de gerência e resolver questões. [GP112]

(A seguinte meta 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 para uma classificação de nível de maturidade 3 e
superiores).

GG 3 Institucionalizar um Processo Definido [CL104.GL101]

O processo é institucionalizado com um processo definido.

GP 3.1 Estabelecer um Processo Definido


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

GP 3.2 Coletar Informações de Melhorias


Coletar produtos de trabalho, medidas, resultados de medições
e informações de melhorias derivados do planejamento e
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]

170 Nível de Maturidade: 2, Gerenciamento de Acordos com Fornecedores


CMMI-SE/SW, v1.1
Representação em Estágios

MEDIÇÕES E ANÁLISES
Nível de Maturidade 2

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]

Notas Introdutórias

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
Representação em Estágios

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]

Áreas de Processos Relacionadas

Veja a área de processo de Planejamento do Projeto para obter


maiores informações sobre estimativa de atributos do projeto e outras
necessidades de informações de planejamento. [PA154.R101]

Veja a área de processo de Monitoramento e Controle do Projeto para


obter maiores informações sobre monitoramento das necessidades de
informações do desempenho do projeto. [PA154.R102]

Veja a área de processo de Gerenciamento de Configurações para


obter maiores informações sobre o gerenciamento de produtos de
trabalho de medições. [PA154.R103]

Veja a área de processo de Desenvolvimento de Requisitos para obter


maiores informações sobre o atendimento dos requisitos de clientes e
necessidades de informações relacionadas. [PA154.R104]

Veja a área de processo de Gerenciamento de Requisitos para obter


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]

Metas Específicas e Genéricas

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
Representação em Estágios

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.

GG 2 Institucionalizar um Processo Gerenciado [CL103.GL101]

O processo é institucionalizado como um processo gerenciado.

(A seguinte meta não é exigida para o nível de maturidade 2, mas é exigida para o nível de
maturidade 3 e superiores).

GG 3 Institucionalizar um Processo Definido [CL104.GL101]

O processo é institucionalizado como um processo definido.

Tabela de Relacionamentos Práticas-Metas

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
GG 2 Institucionalizar um Processo Gerenciado [CL103.GL101]

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 o Nível Mais Alto de Gerência

Nível de Maturidade: 2, Medições e Análises 173


CMMI-SE/SW, v1.1
Representação em Estágios

(A seguinte meta 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).
GG 3 Institucionalizar um Processo Definido [CL104.GL101]

GP 3.1 Estabelecer um Processo Definido


GP 3.2 Coletar Informações de Melhorias

Práticas Específicas por Meta

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]

174 Nível de Maturidade: 2, Medições e Análises


CMMI-SE/SW, v1.1
Representação em Estágios

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

Veja a área de processo de Planejamento do Projeto para obter


maiores informações sobre estimativa de atributos do projeto e outras
necessidades de informações de planejamento. [PA154.IG101.SP101.N105.R101]

Veja a área de processo de Monitoramento e Controle do Projeto para


obter maiores informações sobre necessidades de informações sobre o
desempenho do projeto. [PA154.IG101.SP101.N105.R102]

Veja a área de processo de Desenvolvimento de Requisitos para obter


maiores informações sobre o atendimento dos requisitos de clientes e
necessidades de informações relacionadas. [PA154.IG101.SP101.N105.R103]

Veja a área de processo de Gerenciamento de Requisitos para obter


maiores informações sobre a manutenção da rastreabilidade dos
requisitos e necessidades de informações relacionadas.
[PA154.IG101.SP101.N105.R104]

Produtos de Trabalho Típicos


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]

Nível de Maturidade: 2, Medições e Análises 175


CMMI-SE/SW, v1.1
Representação em Estágios

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]

176 Nível de Maturidade: 2, Medições e Análises


CMMI-SE/SW, v1.1
Representação em Estágios

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)

Nível de Maturidade: 2, Medições e Análises 177


CMMI-SE/SW, v1.1
Representação em Estágios

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]

Produtos de Trabalho Típicos


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]

178 Nível de Maturidade: 2, Medições e Análises


CMMI-SE/SW, v1.1
Representação em Estágios

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]

Produtos de Trabalho Típicos


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?

Nível de Maturidade: 2, Medições e Análises 179


CMMI-SE/SW, v1.1
Representação em Estágios

• 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]

180 Nível de Maturidade: 2, Medições e Análises


CMMI-SE/SW, v1.1
Representação em Estágios

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


necessário. [PA154.IG101.SP103.SubP107]

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]

Produtos de Trabalho Típicos


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

Nível de Maturidade: 2, Medições e Análises 181


CMMI-SE/SW, v1.1
Representação em Estágios

• 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]

182 Nível de Maturidade: 2, Medições e Análises


CMMI-SE/SW, v1.1
Representação em Estágios

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


necessário. [PA154.IG101.SP104.SubP105]

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.

Nível de Maturidade: 2, Medições e Análises 183


CMMI-SE/SW, v1.1
Representação em Estágios

• 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]

Produtos de Trabalho Típicos


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]

184 Nível de Maturidade: 2, Medições e Análises


CMMI-SE/SW, v1.1
Representação em Estágios

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]

Nível de Maturidade: 2, Medições e Análises 185


CMMI-SE/SW, v1.1
Representação em Estágios

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]

Produtos de Trabalho Típicos


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]

186 Nível de Maturidade: 2, Medições e Análises


CMMI-SE/SW, v1.1
Representação em Estágios

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
e objetivos de informações identificados.
[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]

Nível de Maturidade: 2, Medições e Análises 187


CMMI-SE/SW, v1.1
Representação em Estágios

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]

Veja a área de processo de Gerenciamento de Configurações para


obter maiores informações sobre o gerenciamento dos produtos de
trabalho de medições. [PA154.IG102.SP103.N106.R102]

Produtos de Trabalho Típicos


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]

188 Nível de Maturidade: 2, Medições e Análises


CMMI-SE/SW, v1.1
Representação em Estágios

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]

Produtos de Trabalho Típicos


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]

Veja a área de processo de Monitoramento e Controle do Projeto


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
e objetivos de informações identificados.
[PA154.IG102.SP104.SubP102.N101]

Nível de Maturidade: 2, Medições e Análises 189


CMMI-SE/SW, v1.1
Representação em Estágios

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

GG 2 Institucionalizar um Processo Gerenciado [CL103.GL101]

O processo é institucionalizado como um processo gerenciado.

Compromisso

GP 2.1 (CO 1) Estabelecer uma Política Organizacional


Estabelecer e manter uma política organizacional para o
planejamento e execução do processo de medições e análises.
[GP103]

Elaboração:

Esta política estabelece as expectativas organizacionais para 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]

190 Nível de Maturidade: 2, Medições e Análises


CMMI-SE/SW, v1.1
Representação em Estágios

Habilitações

GP 2.2 (AB 1) Planejar o Processo


Estabelecer e manter o plano para a execução do processo de
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]

GP 2.3 (AB 2) Fornecer Recursos


Fornecer os recursos adequados para a execução do processo
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


ferramentas: [PA154.EL105]

• Pacotes estatísticos
• Pacotes que apóiam a coleta de dados entre redes

GP 2.4 (AB 3) Atribuir Responsabilidades


Atribuir responsabilidades e autoridade para a execução do
processo, desenvolvimento dos produtos de trabalho e
fornecimento dos serviços do processo de medições e
análises. [GP106]

GP 2.5 (AB 4) Treinar as Pessoas


Treinar as pessoas na execução e suporte do processo de
medições e análises, conforme necessário. [GP107]

Nível de Maturidade: 2, Medições e Análises 191


CMMI-SE/SW, v1.1
Representação em Estágios

Elaboração:

Exemplos de tópicos de treinamento incluem: [PA154.EL107]

• 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

GP 2.6 (DI 1) Gerenciar Configurações


Colocar os produtos de trabalho definidos do processo de
medições e análises sob os níveis apropriados de
gerenciamento de configurações. [GP109]

Elaboração:

Exemplos de produtos de trabalho colocados sob


gerenciamento de configurações incluem: [PA154.EL108]

• 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

GP 2.7 (DI 2) Identificar e Envolver os Stakeholders Relevantes


Identificar e envolver os stakeholders relevantes do processo
de medições e análises, conforme planejado. [GP124]

192 Nível de Maturidade: 2, Medições e Análises


CMMI-SE/SW, v1.1
Representação em Estágios

Elaboração:

Exemplos de atividades para o envolvimento de stakeholders


incluem: [PA154.EL114]

• 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

GP 2.8 (DI 3) Monitorar e Controlar o Processo


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:

Exemplos de medidas utilizadas no monitoramento e


controle incluem: [PA154.EL111]

• Percentual de projetos utilizando medidas de progresso e


desempenho
• Percentual de objetivos de medições tratados

Verificações

GP 2.9 (VE 1) Avaliar Objetivamente a Aderência


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:

Exemplos de atividades revisadas incluem: [PA154.EL112]

• Alinhamento das atividades de medições e análises


• Fornecimento de resultados de medições

Nível de Maturidade: 2, Medições e Análises 193


CMMI-SE/SW, v1.1
Representação em Estágios

Exemplos de produtos de trabalho revisados incluem:


[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

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


Revisar as atividades, status e resultados do processo de
medições e análises com o nível mais alto de gerência e
resolver questões. [GP112]

(A seguinte meta 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 para uma classificação de nível de maturidade 3 e
superiores).

GG 3 Institucionalizar um Processo Definido [CL104.GL101]

O processo é institucionalizado como um processo definido.

GP 3.1 Estabelecer um Processo Definido


Estabelecer e manter a descrição de um processo definido de
medições e análises. [GP114]

GP 3.2 Coletar Informações de Melhorias


Coletar produtos de trabalho, medidas, resultados de medições
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]

194 Nível de Maturidade: 2, Medições e Análises


CMMI-SE/SW, v1.1
Representação em Estágios

GARANTIA DA QUALIDADE DO PROCESSO E DO PRODUTO


Nível de Maturidade 2

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]

Notas Introdutórias

A área de processo de Garantia da Qualidade do Processo e do


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

A área de processo de Garantia da Qualidade do Processo e do


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
Representação em Estágios

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
Representação em Estágios

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]

Áreas de Processos Relacionadas

Veja a área de processo de Planejamento do Projeto para obter


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]

Metas Específicas e Genéricas

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.

GG 2 Institucionalizar um Processo Gerenciado [CL103.GL101]

O processo é institucionalizado como um processo gerenciado.

(A seguinte meta não é exigida para o nível de maturidade 2, mas é exigida para o nível de
maturidade 3 e superiores).

GG 3 Institucionalizar um Processo Definido [CL104.GL101]

O processo é institucionalizado como um processo definido.

Nível de Maturidade: 2, Garantia da Qualidade do Processo e do Produto 197


CMMI-SE/SW, v1.1
Representação em Estágios

Tabela de Relacionamentos Práticas-Metas

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
GG 2 Institucionalizar um Processo Gerenciado [CL103.GL101]

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 o Nível Mais Alto de Gerência

(A seguinte meta 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).
GG 3 Institucionalizar um Processo Definido [CL104.GL101]

GP 3.1 Estabelecer um Processo Definido


GP 3.2 Coletar Informações de Melhorias

Práticas Específicas por Meta

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]

198 Nível de Maturidade: 2, Garantia da Qualidade do Processo e do Produto


CMMI-SE/SW, v1.1
Representação em Estágios

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]

Produtos de Trabalho Típicos


1. Relatórios de avaliações [PA145.IG101.SP101.W101]

2. Relatórios de não conformidades [PA145.IG101.SP101.W102]

3. Ações corretivas [PA145.IG101.SP101.W103]

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]

Produtos de Trabalho Típicos


1. Relatórios de avaliações [PA145.IG101.SP102.W101]

Nível de Maturidade: 2, Garantia da Qualidade do Processo e do Produto 199


CMMI-SE/SW, v1.1
Representação em Estágios

2. Relatórios de não conformidades [PA145.IG101.SP102.W102]

3. Ações corretivas [PA145.IG101.SP102.W103]

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]

200 Nível de Maturidade: 2, Garantia da Qualidade do Processo e do Produto


CMMI-SE/SW, v1.1
Representação em Estágios

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]

Produtos de Trabalho Típicos


1. Relatórios de ações corretivas [PA145.IG102.SP101.W101]

2. Relatórios de avaliações [PA145.IG102.SP101.W102]

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]

Nível de Maturidade: 2, Garantia da Qualidade do Processo e do Produto 201


CMMI-SE/SW, v1.1
Representação em Estágios

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]

Produtos de Trabalho Típicos


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]

O processo é institucionalizado como um processo gerenciado.

202 Nível de Maturidade: 2, Garantia da Qualidade do Processo e do Produto


CMMI-SE/SW, v1.1
Representação em Estágios

Compromissos

GP 2.1 (CO 1) Estabelecer uma Política Organizacional


Estabelecer e manter uma política organizacional para o
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

GP 2.2 (AB 1) Planejar o Processo


Estabelecer e manter o plano para execução do processo de
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]

GP 2.3 (AB 2) Fornecer Recursos


Fornecer os recursos adequados para a execução do processo
de garantia da qualidade do processo e do produto,
desenvolvimento dos produtos de trabalho e fornecimento dos
serviços do processo. [GP105]

Nível de Maturidade: 2, Garantia da Qualidade do Processo e do Produto 203


CMMI-SE/SW, v1.1
Representação em Estágios

Elaboração:

Exemplos de recursos fornecidos incluem as seguintes


ferramentas: [PA145.EL105]

• Ferramentas de avaliação
• Ferramentas de rastreamento de não conformidades

GP 2.4 (AB 3) Atribuir Responsabilidades


Atribuir responsabilidades e autoridade para a execução do
processo, desenvolvimento dos produtos de trabalho e
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]

GP 2.5 (AB 4) Treinar as Pessoas


Treinar as pessoas na execução e suporte ao processo de
garantia da qualidade do processo e do produto, conforme
necessário. [GP107]

Elaboração:

Exemplos de tópicos de treinamento incluem: [PA145.EL106]

• 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

204 Nível de Maturidade: 2, Garantia da Qualidade do Processo e do Produto


CMMI-SE/SW, v1.1
Representação em Estágios

Implementações

GP 2.6 (DI 1) Gerenciar Configurações


Colocar os produtos de trabalho definidos do processo de
garantia da qualidade do processo e do produto sob os níveis
apropriados de gerenciamento de configurações. [GP109]

Elaboração:

Exemplos de produtos de trabalho colocados sob


gerenciamento de configurações incluem: [PA145.EL111]

• Relatórios de não conformidades


• Logs e relatórios de avaliações

GP 2.7 (DI 2) Identificar e Envolver os Stakeholders Relevantes


Identificar e envolver os stakeholders relevantes do processo
de garantia da qualidade do processo e do produto, conforme
planejado. [GP124]

Elaboração:

Exemplos de atividades de envolvimento de stakeholder


incluem: [PA145.EL113]

• 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

GP 2.8 (DI 3) Monitorar e Controlar o Processo


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]

Nível de Maturidade: 2, Garantia da Qualidade do Processo e do Produto 205


CMMI-SE/SW, v1.1
Representação em Estágios

Elaboração:

Exemplos de medidas utilizadas no monitoramento e


controle incluem: [PA145.EL108]

• 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

GP 2.9 (VE 1) Avaliar Objetivamente a Aderência


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:

Exemplos de atividades revisadas incluem: [PA145.EL109]

• Avaliar objetivamente processos e produtos de trabalho


• Rastrear e comunicar questões de não conformidades

Exemplos de produtos de trabalho revisados incluem:


[PA145.EL112]

• Relatórios de não conformidades


• Logs e relatórios de avaliações

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


Revisar as atividades, status e resultados do processo de
garantia da qualidade do processo e do produto com o nível
mais alto de gerência e resolver questões. [GP112]

206 Nível de Maturidade: 2, Garantia da Qualidade do Processo e do Produto


CMMI-SE/SW, v1.1
Representação em Estágios

(A seguinte meta 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 para uma classificação de nível de maturidade 3 e
superiores).

GG 3 Institucionalizar um Processo Definido [CL104.GL101]

O processo é institucionalizado como um processo definido.

GP 3.1 Estabelecer um Processo Definido


Estabelecer e manter a descrição de um processo definido de
garantia da qualidade do processo e do produto. [GP114]

GP 3.2 Coletar Informações de Melhorias


Coletar produtos de trabalho, medidas, resultados de medições
e informações de melhorias derivados do planejamento e
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]

Nível de Maturidade: 2, Garantia da Qualidade do Processo e do Produto 207


CMMI-SE/SW, v1.1
Representação em Estágios

GERENCIAMENTO DE CONFIGURAÇÕES
Nível de Maturidade 2

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]

Notas Introdutórias

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
Representação em Estágios

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
Representação em Estágios

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]

Áreas de Processos Relacionadas

Veja a área de processo de Planejamento do Projeto para obter


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]

Veja a área de processo de Monitoramento e Controle do Projeto para


obter maiores informações sobre análises de desempenho e ações
corretivas. [PA159.R103]

Metas Específicas e Genéricas

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.

210 Nível de Maturidade: 2, Gerenciamento de Configurações


CMMI-SE/SW, v1.1
Representação em Estágios

GG 2 Institucionalizar um Processo Gerenciado [CL103.GL101]

O processo é institucionalizado como um processo gerenciado.

(A seguinte meta não é exigida para o nível de maturidade 2, mas é exigida para o nível de
maturidade 3 e superiores).

GG 3 Institucionalizar um Processo Definido [CL104.GL101]

O processo é institucionalizado como um processo definido.

Tabela de Relacionamentos Práticas-Metas

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
GG 2 Institucionalizar um Processo Gerenciado [CL103.GL101]

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 o Nível Mais Alto de Gerência

(A seguinte meta 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).
GG 3 Institucionalizar um Processo Definido [CL104.GL101]

GP 3.1 Estabelecer um Processo Definido


GP 3.2 Coletar Informações de Melhorias

Nível de Maturidade: 2, Gerenciamento de Configurações 211


CMMI-SE/SW, v1.1
Representação em Estágios

Práticas Específicas por Meta

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]

212 Nível de Maturidade: 2, Gerenciamento de Configurações


CMMI-SE/SW, v1.1
Representação em Estágios

Para Engenharia de Sistemas


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]

Produtos de Trabalho Típicos


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

Nível de Maturidade: 2, Gerenciamento de Configurações 213


CMMI-SE/SW, v1.1
Representação em Estágios

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

Para Engenharia de Software


Exemplos de produtos de trabalho de software que
podem ser parte de um item de configuração
incluem: [PA159.IG101.SP101.SubP101.N101.AMP101]

• 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

214 Nível de Maturidade: 2, Gerenciamento de Configurações


CMMI-SE/SW, v1.1
Representação em Estágios

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]

Produtos de Trabalho Típicos


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]

Nível de Maturidade: 2, Gerenciamento de Configurações 215


CMMI-SE/SW, v1.1
Representação em Estágios

Exemplos de sistemas de gerenciamento de configurações


incluem: [PA159.IG101.SP102.SubP102.N101]

• 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


configurações. [PA159.IG101.SP102.SubP105]

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


configurações. [PA159.IG101.SP102.SubP107]

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


necessário. [PA159.IG101.SP102.SubP108]

216 Nível de Maturidade: 2, Gerenciamento de Configurações


CMMI-SE/SW, v1.1
Representação em Estágios

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]

Para Engenharia de Sistemas


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]

Para Engenharia de Software


Um conjunto de requisitos, design, arquivos de código fonte e
o código executável associado, arquivos de construção e
documentação do usuário (entidades associadas) aos quais
tenha sido atribuído um identificador único, pode ser
considerado como sendo uma baseline. Liberar uma baseline
consiste na recuperação dos arquivos de código fonte (itens
de configurações) a partir do sistema de gerenciamento de
configurações e geração dos arquivos executáveis. Uma
baseline que é entregue a um cliente é normalmente
chamada de “release”, enquanto que uma baseline para uso
interno é normalmente chamada de “build”.
[PA159.IG101.SP103.N101.AMP102]

Produtos de Trabalho Típicos


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]

Nível de Maturidade: 2, Gerenciamento de Configurações 217


CMMI-SE/SW, v1.1
Representação em Estágios

2. Criar ou liberar baselines somente a partir de itens de


configurações do sistema de gerenciamento de configurações.
[PA159.IG101.SP103.SubP102]

Para Engenharia de Sistemas


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]

Produtos de Trabalho Típicos


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]

218 Nível de Maturidade: 2, Gerenciamento de Configurações


CMMI-SE/SW, v1.1
Representação em Estágios

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]

Produtos de Trabalho Típicos


1. Histórico de revisões de itens de configurações [PA159.IG102.SP102.W101]

2. Arquivos das baselines [PA159.IG102.SP102.W102]

Nível de Maturidade: 2, Gerenciamento de Configurações 219


CMMI-SE/SW, v1.1
Representação em Estágios

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”


incluem: [PA159.IG102.SP102.SubP103.N101]

• 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]

220 Nível de Maturidade: 2, Gerenciamento de Configurações


CMMI-SE/SW, v1.1
Representação em Estágios

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]

Produtos de Trabalho Típicos


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
configurações. [PA159.IG103.SP101.SubP102]

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 Configurações 221


CMMI-SE/SW, v1.1
Representação em Estágios

5. Descrever as diferenças entre baselines sucessivas.


[PA159.IG103.SP101.SubP105]

6. Revisar o status e o histórico (isto é, mudanças e outras ações) de


cada item de configuração, conforme necessário.
[PA159.IG103.SP101.SubP106]

SP 3.2 Executar Auditorias de Configurações


Executar auditorias de configurações para manter a integridade
das baselines de configurações. [PA159.IG103.SP102]

Executar auditorias nas atividades e processos de gerenciamento de


configurações para confirmar que as baselines e documentações
resultantes são precisas e registrar os resultados das auditorias,
conforme apropriado. [PA159.IG103.SP102.N101]

Produtos de Trabalho Típicos


1. Resultados de auditorias de configurações [PA159.IG103.SP102.W101]

2. Itens de ação [PA159.IG103.SP102.W102]

Sub-práticas
1. Analisar a integridade das baselines. [PA159.IG103.SP102.SubP101]

2. Confirmar que os registros de configurações identificam


corretamente a configuração dos itens de configurações.
[PA159.IG103.SP102.SubP102]

3. Revisar a estrutura e integridade dos itens do sistema de


gerenciamento de configurações. [PA159.IG103.SP102.SubP103]

4. Confirmar a completitude e correção dos itens do sistema de


gerenciamento de configurações. [PA159.IG103.SP102.SubP104]

A completitude e correção do conteúdo são baseadas nos


requisitos conforme declarados no plano e a disposição de
solicitações de mudanças aprovadas. [PA159.IG103.SP102.SubP104.N101]

5. Confirmar a conformidade com os padrões e procedimentos de


gerenciamento de configurações aplicáveis. [PA159.IG103.SP102.SubP105]

6. Rastrear os itens de ação da auditoria até o encerramento.


[PA159.IG103.SP102.SubP106]

GG 2 Institucionalizar um Processo Gerenciado [CL103.GL101]

O processo é institucionalizado como um processo gerenciado.

222 Nível de Maturidade: 2, Gerenciamento de Configurações


CMMI-SE/SW, v1.1
Representação em Estágios

Compromisso

GP 2.1 (CO 1) Estabelecer uma Política Organizacional


Estabelecer e manter uma política organizacional para o
planejamento e execução do processo de gerenciamento de
configurações. [GP103]

Elaboração:

Esta política estabelece as expectativas organizacionais para o


estabelecimento e manutenção de baselines, rastreamento e controle
de mudanças nos produtos de trabalho (sob gerenciamento de
configurações) e estabelecimento e manutenção da integridade das
baselines. [PA159.EL101]

Habilitações

GP 2.2 (AB 1) Planejar o Processo


Estabelecer e manter o plano para execução do processo de
gerenciamento de configurações. [GP104]

Elaboração:

Este plano para execução do processo de gerenciamento de


configurações pode estar incluído no (ou ser referenciado pelo) plano
do projeto, que é descrito na área de processo de Planejamento do
Projeto. [PA159.EL112]

GP 2.3 (AB 2) Fornecer Recursos


Fornecer recursos adequados para executar o processo de
gerenciamento de configurações, desenvolver os produtos de
trabalho e fornecer os serviços do processo. [GP105]

Nível de Maturidade: 2, Gerenciamento de Configurações 223


CMMI-SE/SW, v1.1
Representação em Estágios

Elaboração:

Exemplos de recursos fornecidos incluem as seguintes


ferramentas: [PA159.EL104]

• Ferramentas de gerenciamento de configurações


• Ferramentas de gerenciamento de dados
• Ferramentas de arquivamento e reprodução
• Programas de bancos de dados

GP 2.4 (AB 3) Atribuir Responsabilidades


Atribuir responsabilidades e autoridade para a execução do
processo, desenvolvimento dos produtos de trabalho e
fornecimento dos serviços do processo de gerenciamento de
configurações. [GP106]

GP 2.5 (AB 4) Treinar as Pessoas


Treinar as pessoas na execução e suporte ao processo de
gerenciamento de configurações, conforme necessário. [GP107]

Elaboração:

Exemplos de tópicos de treinamento incluem: [PA159.EL105]

• Papéis, responsabilidades e autoridade da equipe de


gerenciamento de configurações
• Padrões, procedimentos e métodos de gerenciamento de
configurações
• Sistema de biblioteca de configurações

Implementações

GP 2.6 (DI 1) Gerenciar Configurações


Colocar os produtos de trabalho definidos do processo de
gerenciamento de configurações sob os níveis apropriados de
gerenciamento de configurações. [GP109]

224 Nível de Maturidade: 2, Gerenciamento de Configurações


CMMI-SE/SW, v1.1
Representação em Estágios

Elaboração:

Exemplos de produtos de trabalho colocados sob


gerenciamento de configurações incluem: [PA159.EL106]

• Listas de acessos
• Relatórios de status de mudanças
• Banco de dados de solicitações de mudanças
• Atas de reuniões do CCB
• Baselines arquivadas

GP 2.7 (DI 2) Identificar e Envolver os Stakeholders Relevantes


Identificar e envolver os stakeholders relevantes do processo
de gerenciamento de configurações, conforme planejado. [GP124]

Elaboração:

Exemplos de atividades de envolvimento de stakeholders


incluem: [PA159.EL111]

• Estabelecer baselines
• Revisar os relatórios do sistema de gerenciamento de
configurações e resolver questões
• Analisar o impacto das mudanças nos itens de
configurações
• Executar auditorias de configurações
• Revisar os resultados das auditorias de gerenciamento de
configurações

GP 2.8 (DI 3) Monitorar e Controlar o Processo


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

Elaboração:

Exemplos de medidas utilizadas no monitoramento e


controle incluem: [PA159.EL108]

• Quantidade de mudanças nos itens de configurações


• Quantidade de auditorias de configurações conduzidas

Nível de Maturidade: 2, Gerenciamento de Configurações 225


CMMI-SE/SW, v1.1
Representação em Estágios

Verificações

GP 2.9 (VE 1) Avaliar Objetivamente a Aderência


Avaliar objetivamente a aderência do processo de
gerenciamento de configurações contra sua descrição de
processo, padrões e procedimentos e tratar as não
conformidades. [GP113]

Elaboração:

Exemplos de atividades revisadas incluem: [PA159.EL109]

• Estabelecer baselines
• Rastrear e controlar mudanças
• Estabelecer e manter a integridade das baselines

Exemplos de produtos de trabalho revisados incluem:


[PA159.EL110]

• Arquivos das baselines


• Bancos de dados de solicitações de mudanças

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


Revisar as atividades, status e resultados do processo de
gerenciamento de configurações com o nível mais alto de
gerência e resolver questões. [GP112]

(A seguinte meta 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 para uma classificação de nível de maturidade 3 e
superiores).

GG 3 Institucionalizar um Processo Definido [CL104.GL101]

O processo é institucionalizado como um processo definido.

GP 3.1 Estabelecer um Processo Definido


Estabelecer e manter a descrição do processo definido de
gerenciamento de configurações. [GP114]

226 Nível de Maturidade: 2, Gerenciamento de Configurações


CMMI-SE/SW, v1.1
Representação em Estágios

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 de gerenciamento de configurações
para suportar o uso futuro e melhorias nos processos e ativos
de processos da organização. [GP117]

Nível de Maturidade: 2, Gerenciamento de Configurações 227


CMMI-SE/SW, v1.1
Representação em Estágios

228 Nível de Maturidade: 2, Gerenciamento de Configurações


CMMI-SE/SW, v1.1
Representação em Estágios

NÍVEL DE MATURIDADE 3: DEFINIDO

A seguinte seção contém todas as áreas de processos que pertencem


ao nível de maturidade 3. As áreas de processos do nível de
maturidade 3 do CMMI são as seguintes: [FM110.T103]

• Desenvolvimento de Requisitos (Requirements Development)


• Soluções Técnicas (Technical Solution)
• Integração de Produtos (Product Integration)
• Verificação (Verification)
• Validação (Validation)
• Foco no Processo Organizacional (Organizational Process Focus)
• Definição do Processo Organizacional (Organizational Process
Definition)
• Treinamento Organizacional (Organizational Training)
• Gerenciamento Integrado do Projeto (Integrated Project
Management)
• Gerenciamento de Riscos (Risk Management)
• Análises de Decisões e Resoluções (Decision Analysis and
Resolution)

Veja o Capítulo 2 para obter maiores informações sobre os níveis de


maturidade do CMMI. [FM110.T105]

Nível de Maturidade: 3 229


CMMI-SE/SW, v1.1
Representação em Estágios

DESENVOLVIMENTO DE REQUISITOS
Nível de Maturidade 3

Objetivo

O objetivo do Desenvolvimento de Requisitos (Requirements


Development) é produzir e analisar requisitos de clientes, produtos e
componentes de produtos. [PA157]

Notas Introdutórias

Esta área de processo descreve três tipos de requisitos: requisitos de


clientes, requisitos de produtos e requisitos de componentes de
produtos. Juntos, estes requisitos tratam as necessidades dos
stakeholders relevantes, incluindo aquelas pertinentes às diversas
fases do ciclo de vida do produto (por exemplo, critérios de testes de
aceitação) e atributos do produto (por exemplo, segurança,
confiabilidade e possibilidade de manutenção). Os requisitos também
tratam as restrições causadas pela seleção de soluções de design (por
exemplo, integração de produtos comerciais de prateleira). [PA157.N101]

Os requisitos são a base do design. O desenvolvimento de requisitos


inclui as seguintes atividades: [PA157.N102]

• Elicitação, análise, validação e comunicação das necessidades dos


clientes, expectativas e restrições para obter requisitos de clientes
que constituem um entendimento do que satisfará os stakeholders
• Coleta e coordenação das necessidades dos stakeholders
• Desenvolvimento dos requisitos do ciclo de vida do produto
• Estabelecimento dos requisitos de clientes
• Estabelecimento dos requisitos iniciais de produtos e de
componentes de produtos consistentes com os requisitos de
clientes

Esta área de processo trata todos os requisitos de clientes, e não


somente os requisitos de produto, porque o cliente pode também
fornecer requisitos específicos de design. [PA157.N103]

Os requisitos de clientes são melhor refinados em requisitos de


produtos e de componentes de produtos. Além dos requisitos de
clientes, requisitos de produtos e de componentes de produtos são
derivados a partir das soluções de design selecionadas. [PA157.N104]

230 Nível de Maturidade: 3, Desenvolvimento de Requisitos


CMMI-SE/SW, v1.1
Representação em Estágios

Os requisitos são identificados e refinados em todas as fases do ciclo


de vida do produto. As decisões de design, ações corretivas
subseqüentes e feedback durante cada fase do ciclo de vida do
produto são analisados com relação ao impacto nos requisitos
derivados e alocados. [PA157.N105]

A área de processo de Desenvolvimento de Requisitos inclui três metas


específicas. A meta específica Desenvolver Requisitos de Clientes trata
da definição de um conjunto de requisitos do cliente para uso no
desenvolvimento dos requisitos de produtos. A meta específica
Desenvolver Requisitos de Produtos trata da definição de um conjunto
de requisitos de produtos ou de componentes de produtos para uso no
design de produtos e componentes de produtos. A meta específica
Analisar e Validar Requisitos trata da necessária análise dos requisitos
de clientes, produtos e componentes de produtos para definir, derivar e
entender os requisitos. As práticas específicas da terceira meta
específica pretendem auxiliar as práticas específicas das duas
primeiras metas específicas. Os processos associados com a área de
processo de Desenvolvimento de Requisitos e aqueles associados com
a área de processo de Soluções Técnicas podem interagir
recursivamente uns com os outros. [PA157.N111]

As análises são utilizadas para entender, definir e selecionar os


requisitos em todos os níveis a partir de alternativas. Estas análises
incluem: [PA157.N106]

• Análise das necessidades e requisitos para cada fase do ciclo de


vida do produto, incluindo as necessidades dos stakeholders
relevantes, o ambiente operacional e fatores que refletem as
expectativas e satisfação geral do cliente e dos usuários finais,
como segurança, proteção e preço
• Desenvolvimento de um conceito operacional
• Definição da funcionalidade exigida

A definição da funcionalidade, também chamada de “análise funcional”,


não é a mesma análise estruturada do desenvolvimento de software e
não presume um design de software orientado a funcionalidades. No
design de software orientado a objetos, ela se relaciona com a
definição dos serviços. A definição de funções, seus agrupamentos
lógicos e sua associação com requisitos é chamada de “arquitetura
funcional”. [PA157.N107]

Nível de Maturidade: 3, Desenvolvimento de Requisitos 231


CMMI-SE/SW, v1.1
Representação em Estágios

As análises ocorrem recursivamente em camadas sucessivas, cada


vez mais detalhadas, da arquitetura de um produto até que detalhes
suficientes estejam disponíveis para possibilitar o design detalhado,
aquisição e teste do produto a ser executado. Como resultado da
análise de requisitos e do conceito operacional (incluindo
funcionalidade, suporte, manutenção e descarte), o conceito de
manufatura ou produção produz requisitos mais derivados, incluindo as
seguintes considerações: [PA157.N108]

• Restrições de diversos tipos


• Limitações tecnológicas
• Custo e direcionadores de custo
• Restrições de tempo e direcionadores de cronograma
• Riscos
• Consideração de questões citadas, mas não explicitamente
declaradas pelo cliente ou usuário final
• Fatores introduzidos por considerações únicas de negócios do
desenvolvedor, regulamentações e leis

Uma hierarquia de entidades lógicas (funções e subfunções, classes e


subclasses de objetos) é estabelecida através de iterações com o
conceito operacional em evolução. Os requisitos são refinados,
derivados e alocados a estas entidades lógicas. Os requisitos e
entidades lógicas são alocados a produtos, componentes de produtos,
pessoas, processos associados ou serviços. [PA157.N109]

O envolvimento dos stakeholders relevantes no desenvolvimento e


análise de requisitos lhes dá a visibilidade da evolução dos requisitos.
Esta atividade continuamente assegura a eles que os requisitos estão
sendo apropriadamente definidos. [PA157.N110]

Áreas de Processos Relacionadas

Veja a área de processo de Gerenciamento de Requisitos para obter


maiores informações sobre o gerenciamento de requisitos de clientes e
produtos, obtenção de acordos com o fornecedor dos requisitos,
obtenção de compromissos com quem está implementando os
requisitos e a manutenção da rastreabilidade. [PA157.R101]

Veja a área de processo de Soluções Técnicas para obter maiores


informações sobre como as saídas dos processos de desenvolvimento
de requisitos são utilizadas e como o desenvolvimento de soluções e
designs alternativos é utilizado no refinamento e derivação de
requisitos. [PA157.R102]

232 Nível de Maturidade: 3, Desenvolvimento de Requisitos


CMMI-SE/SW, v1.1
Representação em Estágios

Veja a área de processo de Integração de Produtos para obter maiores


informações sobre requisitos de interface e gerenciamento de
interfaces. [PA157.R103]

Veja a área de processo de Verificação para obter maiores informações


sobre como verificar se o produto resultante atende seus requisitos.
[PA157.R104]

Veja a área de processo de Validação para obter maiores informações


sobre como o produto construído será validado contra as necessidades
do cliente. [PA157.R105]

Veja a área de processo de Gerenciamento de Riscos para obter


maiores informações sobre a identificação e gerenciamento de riscos
que estão relacionados aos requisitos. [PA157.R106]

Veja a área de processo de Gerenciamento de Configurações para


obter maiores informações sobre como assegurar que os produtos de
trabalho chave estão sendo controlados e gerenciados. [PA157.R107]

Metas Específicas e Genéricas

SG 1 Desenvolver Requisitos do Cliente [PA157.IG101]

As necessidades, expectativas, restrições e interfaces dos stakeholders


são coletadas e traduzidas em requisitos do cliente.

SG 2 Desenvolver Requisitos de Produtos [PA157.IG103]

Os requisitos de clientes são refinados e elaborados para desenvolver


requisitos de produtos e componentes de produtos.

SG 3 Analisar e Validar os Requisitos [PA157.IG102]

Os requisitos são analisados e validados e uma definição da funcionalidade


exigida é desenvolvida.

GG 3 Institucionalizar um Processo Definido [CL104.GL101]

O processo é institucionalizado como um processo definido.

Nível de Maturidade: 3, Desenvolvimento de Requisitos 233


CMMI-SE/SW, v1.1
Representação em Estágios

Tabela de Relacionamentos Práticas-Metas

SG 1 Desenvolver Requisitos do Cliente [PA157.IG101]

SP 1.1 Elicitar Necessidades


SP 1.2 Desenvolver os Requisitos do Cliente
SG 2 Desenvolver Requisitos do Produto [PA157.IG103]

SP 2.1 Estabelecer os Requisitos de Produtos e Componentes de Produtos


SP 2.2 Alocar Requisitos de Componentes de Produtos
SP 2.3 Identificar Requisitos de Interfaces
SG 3 Analisar e Validar os Requisitos [PA157.IG102]
SP 3.1 Estabelecer Conceitos e Cenários Operacionais
SP 3.2 Estabelecer uma Definição da Funcionalidade Necessária
SP 3.3 Analisar Requisitos
SP 3.4 Analisar Requisitos para Alcançar o Equilíbrio
SP 3.5 Validar Requisitos com Métodos Abrangentes
GG 3 Institucionalizar um Processo Definido [CL104.GL101]

GP 2.1 (CO 1) Estabelecer uma Política Organizacional


GP 3.1 (AB 1) Estabelecer um Processo Definido
GP 2.2 (AB 2) Planejar o Processo
GP 2.3 (AB 3) Fornecer Recursos
GP 2.4 (AB 4) Atribuir Responsabilidades
GP 2.5 (AB 5) 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 3.2 (DI 4) Coletar Informações de Melhorias
GP 2.9 (VE 1) Avaliar Objetivamente a Aderência
GP 2.10 (VE 2) Revisar o Status com o Nível Mais Alto de Gerência

Práticas Específicas por Meta

SG 1 Desenvolver Requisitos de Clientes

As necessidades, expectativas, restrições e interfaces dos stakeholders


são coletadas e traduzidas em requisitos de clientes. [PA157.IG101]

As necessidades dos stakeholders (por exemplo, clientes, usuários


finais, fornecedores, construtores e testadores) são a base para
determinar os requisitos de clientes. As necessidades dos
stakeholders, expectativas, restrições, interfaces, conceitos
operacionais e conceitos do produto são analisados, harmonizados,
refinados e elaborados para serem traduzidos em um conjunto de
requisitos de clientes. [PA157.IG101.N101]

234 Nível de Maturidade: 3, Desenvolvimento de Requisitos


CMMI-SE/SW, v1.1
Representação em Estágios

Muitas vezes, as necessidades, expectativas, restrições e interfaces


dos stakeholders são pobremente identificadas ou são conflitantes.
Uma vez que as necessidades, expectativas, restrições e limitações
dos stakeholders deverão estar claramente identificadas e entendidas,
um processo iterativo é usado durante toda a vida do projeto para
atingir este objetivo. Para facilitar a necessária interação, um substituto
do usuário final ou cliente é freqüentemente envolvido para representar
suas necessidades e ajudar a resolver conflitos. A área de relações
com o cliente ou de marketing da organização, assim como membros
da equipe de desenvolvimento de disciplinas como a de engenharia
humana ou suporte podem ser utilizados como substitutos. Restrições
ambientais, legais e outras deverão ser consideradas quando da
criação e resolução do conjunto de requisitos do cliente. [PA157.IG101.N102]

SP 1.1 Elicitar Necessidades


Elicitar as necessidades, expectativas, restrições e interfaces
dos stakeholders para todas as fases do ciclo de vida do
produto. [PA157.IG101.SP102]

Elicitar vai além de coletar requisitos, envolvendo identificar de forma


pró-ativa requisitos adicionais que não foram explicitamente fornecidos
pelos clientes. Os requisitos adicionais deverão tratar as diversas
atividades do ciclo de vida do produto e seu impacto no produto.
[PA157.IG101.SP102.N102]

Nível de Maturidade: 3, Desenvolvimento de Requisitos 235


CMMI-SE/SW, v1.1
Representação em Estágios

Exemplos de técnicas para elicitar necessidades incluem:


[PA157.IG101.SP102.N103]

• Demonstrações tecnológicas
• Grupos de trabalho de controle de interfaces
• Grupos de trabalho de controle técnico
• Revisões intermediárias do projeto
• Questionários, entrevistas e cenários operacionais obtidos
dos usuários finais
• Walkthroughs operacionais e análise de tarefas de
usuários finais
• Protótipos e modelos
• Brainstorming
• Implementação de Funções de Qualidade (Quality
Function Deployment)
• Pesquisas de mercado
• Testes beta
• Extração de fontes como documentos, padrões ou
especificações
• Observação de produtos existentes, ambientes e padrões
de fluxo de trabalho
• Use cases
• Análises de casos de negócios
• Engenharia reversa (para produtos legados)

Sub-práticas
1. Engajar os stakeholders relevantes utilizando métodos para elicitar
as necessidades, expectativas, restrições e interfaces externas.
[PA157.IG101.SP102.SubP101]

236 Nível de Maturidade: 3, Desenvolvimento de Requisitos


CMMI-SE/SW, v1.1
Representação em Estágios

A seguinte prática específica aparece na representação contínua como SP 1.1-1,


mas está categorizada na representação em estágios como SP 1.1, Elicitar
Necessidades. A prática específica é apresentada aqui em cinza somente como
material informativo.

SP 1.1-1 Coletar as Necessidades dos Stakeholders


Identificar e coletar as necessidades, expectativas, restrições e
interfaces dos stakeholders para todas as fases do ciclo de
vida do produto. [PA157.IG101.SP101]

A atividade básica trata o recebimento dos requisitos que um cliente


fornece para definir o que é necessário ou desejado. Estes requisitos
podem ou não ser declarados em termos técnicos. Eles deverão tratar
as diversas atividades do ciclo de vida do produto e seu impacto no
produto. [PA157.IG101.SP101.N101]

SP 1.2 Desenvolver os Requisitos de Clientes


Transformar as necessidades, expectativas, restrições e
interfaces dos stakeholders em requisitos de clientes.
[PA157.IG101.SP103]

As várias entradas vindas do cliente devem ser consolidadas, as


informações que faltarem devem ser obtidas e os conflitos devem ser
resolvidos na documentação do conjunto reconhecido de requisitos de
clientes. Os requisitos de clientes podem incluir necessidades,
expectativas e restrições com relação a verificação e validação.
[PA157.IG101.SP103.N101]

Produtos de Trabalho Típicos


1. Requisitos de clientes [PA157.IG101.SP103.W101]

2. Restrições de clientes na condução da verificação [PA157.IG101.SP103.W102]

3. Restrições de clientes na condução da validação [PA157.IG101.SP103.W103]

Sub-práticas
1. Traduzir as necessidades, expectativas, restrições e interfaces dos
stakeholders em requisitos de clientes documentados.
[PA157.IG101.SP103.SubP101]

2. Definir restrições para verificação e validação. [PA157.IG101.SP103.SubP102]

Nível de Maturidade: 3, Desenvolvimento de Requisitos 237


CMMI-SE/SW, v1.1
Representação em Estágios

SG 2 Desenvolver Requisitos de Produtos

Os requisitos de clientes são refinados e elaborados para desenvolver


requisitos de produtos e de componentes de produtos. [PA157.IG103]

Os requisitos de clientes são analisados em conjunto com o


desenvolvimento do conceito operacional para derivar conjuntos de
requisitos mais detalhados e precisos chamados de “requisitos de
produtos e de componentes de produtos”. Os requisitos de produtos e
de componentes de produtos tratam as necessidades associadas com
cada fase do ciclo de vida do produto. Requisitos derivados provêm
das restrições, consideração das questões citadas mas não
explicitamente declaradas na baseline de requisitos de clientes e
fatores introduzidos pela arquitetura selecionada, o design e as
considerações únicas de negócios dos desenvolvedores. Os requisitos
são reexaminados com cada nível sucessivo mais baixo do conjunto de
requisitos e arquitetura funcional e o conceito preferencial do produto é
refinado. [PA157.IG103.N101]

Os requisitos são alocados a funções de produtos e componentes de


produtos incluindo objetos, pessoas e processos. A rastreabilidade dos
requisitos a funções, objetos, testes, questões e outras entidades é
documentada. Os requisitos e funções alocados são a base para a
síntese da solução técnica. Conforme os componentes internos são
desenvolvidos, interfaces adicionais são definidas e requisitos de
interfaces são estabelecidos. [PA157.IG103.N102]

Veja a prática específica Manter a Rastreabilidade Bidirecional dos


Requisitos da área de processo de Gerenciamento de Requisitos para
obter maiores informações sobre a manutenção da rastreabilidade
bidirecional. [PA157.IG103.N102.R101]

SP 2.1 Estabelecer Requisitos de Produtos e de Componentes de


Produtos
Estabelecer e manter os requisitos de produtos e componentes
de produtos, que são baseados nos requisitos de clientes.
[PA157.IG103.SP101]

Os requisitos de clientes podem ser expressos nos termos do cliente e


podem ser descrições não técnicas. Os requisitos de produtos são a
expressão destes requisitos em termos técnicos que podem ser
utilizados para decisões de design. Um exemplo desta tradução é
encontrado na primeira Casa de Implementação de Qualidade
Funcional (The first House of Quality Functional Deployment), que
mapeia os desejos do cliente em parâmetros técnicos. Por exemplo,
“uma porta sólida e sonora” pode ser mapeada com o tamanho, peso,
formato, umidade e freqüências de ressonância. [PA157.IG103.SP101.N101]

238 Nível de Maturidade: 3, Desenvolvimento de Requisitos


CMMI-SE/SW, v1.1
Representação em Estágios

Requisitos de produtos e de componentes de produtos tratam a


satisfação dos clientes, negócios e objetivos do projeto e atributos
associados, como eficiência e custo. [PA157.IG103.SP101.N104]

Restrições de design incluem especificações sobre componentes de


produtos que são derivados de decisões de design, e não de requisitos
de nível mais elevado. [PA157.IG103.SP101.N102]

Para Engenharia de Software


Por exemplo, os componentes da aplicação que
devem ter interface com componentes de bancos de
dados “de prateleira” devem obedecer aos
requisitos de interface impostos pelo banco de
dados selecionado. Tais requisitos de componentes
de produtos não são, geralmente, rastreáveis a
níveis de requisitos mais elevados.
[PA157.IG103.SP101.N102.AMP101]

Requisitos derivados também tratam o custo e o desempenho de


outras fases do ciclo de vida (por exemplo, produção, operação e
descarte) na medida compatível com os objetivos de negócios.
[PA157.IG103.SP101.N103]

A modificação dos requisitos devido a mudanças de requisitos é


coberta pela função de “manutenção” desta prática específica,
enquanto a administração de mudanças de requisitos é coberta pela
área de processo de Gerenciamento de Requisitos. [PA157.IG103.SP101.N105]

Veja a área de processo de Gerenciamento de Requisitos para obter


maiores informações sobre gerenciamento de mudanças de requisitos.
[PA157.IG103.SP101.N105.R101]

Produtos de Trabalho Típicos


1. Requisitos derivados [PA157.IG103.SP101.W101]

2. Requisitos de produtos [PA157.IG103.SP101.W102]

3. Requisitos de componentes de produtos [PA157.IG103.SP101.W103]

Sub-práticas
1. Desenvolver requisitos nos termos técnicos necessários para o
design dos produtos e componentes de produtos.
[PA157.IG103.SP101.SubP101]

Desenvolver os requisitos de arquitetura trata das


qualidades críticas do produto e do desempenho
necessário para o design da arquitetura do produto.
[PA157.IG103.SP101.SubP101.N101]

Nível de Maturidade: 3, Desenvolvimento de Requisitos 239


CMMI-SE/SW, v1.1
Representação em Estágios

2. Derivar requisitos que resultam de decisões de design.


[PA157.IG103.SP101.SubP102]

Veja a área de processo de Soluções Técnicas para obter maiores


informações sobre o desenvolvimento de soluções que geram
requisitos derivados adicionais. [PA157.IG103.SP101.SubP102.R101]

A seleção de uma tecnologia traz requisitos adicionais. Por


exemplo, o uso de eletrônica exige requisitos tecnológicos
específicos adicionais, tais como os limites da interferência
eletromagnética. [PA157.IG103.SP101.SubP102.N101]

3. Estabelecer e manter os relacionamentos entre os requisitos para


consideração durante o gerenciamento de mudanças e alocação
de requisitos. [PA157.IG103.SP101.SubP103]

Veja a área de processo de Gerenciamento de Requisitos para


obter maiores informações sobre a manutenção da rastreabilidade
dos requisitos. [PA157.IG103.SP101.SubP103.R101]

Relacionamentos entre os requisitos podem auxiliar na


avaliação do impacto das mudanças. [PA157.IG103.SP101.SubP103.N101]

SP 2.2 Alocar Requisitos de Componentes de Produtos


Alocar os requisitos para cada componente de produto.
[PA157.IG103.SP102]

Veja a área de processo de Soluções Técnicas para obter maiores


informações sobre alocação de requisitos a produtos e componentes
de produtos. Esta prática específica fornece informações para a
definição da alocação de requisitos, mas deve interagir com as práticas
específicas da área de processo de Soluções Técnicas para
estabelecer soluções para as quais os requisitos são alocados.
[PA157.IG103.SP102.R101]

Os requisitos para os componentes de produtos da solução definida


incluem a alocação do desempenho do produto; restrições de design e
encaixe, formato e funções para atender os requisitos e facilitar a
produção. Em casos onde um nível mais elevado de requisitos
especifica um desempenho que será de responsabilidade de dois ou
mais componentes de produtos, o desempenho deve ser particionado
para alocação única a cada componente de produto como um requisito
derivado. [PA157.IG103.SP102.N101]

Produtos de Trabalho Típicos


1. Planilhas de alocação de requisitos [PA157.IG103.SP102.W101]

2. Alocações provisionais de requisitos [PA157.IG103.SP102.W102]

240 Nível de Maturidade: 3, Desenvolvimento de Requisitos


CMMI-SE/SW, v1.1
Representação em Estágios

3. Restrições de design [PA157.IG103.SP102.W103]

4. Requisitos derivados [PA157.IG103.SP102.W104]

5. Relacionamentos entre os requisitos derivados [PA157.IG103.SP102.W105]

Sub-práticas
1. Alocar requisitos a funções. [PA157.IG103.SP102.SubP101]

2. Alocar requisitos a componentes de produtos. [PA157.IG103.SP102.SubP102]

3. Alocar restrições de design a componentes de produtos.


[PA157.IG103.SP102.SubP103]

4. Documentar relacionamentos entre os requisitos alocados.


[PA157.IG103.SP102.SubP104]

Relacionamentos incluem as dependências nas quais uma


mudança em um requisito pode afetar outros requisitos.
[PA157.IG103.SP102.SubP104.N101]

SP 2.3 Identificar Requisitos de Interface


Identificar requisitos de interface. [PA157.IG103.SP103]

Interfaces entre funções (ou entre objetos) são identificadas. As


interfaces funcionais podem direcionar o desenvolvimento de soluções
alternativas descritas na área de processo de Soluções Técnicas.
[PA157.IG103.SP103.N101]

Veja a área de processo de Integração de Produtos para obter maiores


informações sobre o gerenciamento de interfaces e a integração de
produtos e componentes de produtos. [PA157.IG103.SP103.N101.R101]

Requisitos de interfaces entre produtos e componentes de produtos


identificados na arquitetura do produto são definidos. Eles são
controlados como parte da integração do produto e dos componentes
do produto e são parte integral da definição da arquitetura.
[PA157.IG103.SP103.N102]

Produtos de Trabalho Típicos


1. Requisitos de interfaces [PA157.IG103.SP103.W101]

Sub-práticas
1. Identificar interfaces externas e internas ao produto (isto é, entre
partes funcionais ou objetos). [PA157.IG103.SP103.SubP101]

Nível de Maturidade: 3, Desenvolvimento de Requisitos 241


CMMI-SE/SW, v1.1
Representação em Estágios

Conforme o design progride, a arquitetura do produto será


alterada pelos processos de soluções técnicas, criando
novas interfaces entre os componentes de produtos e
componentes externos ao produto. [PA157.IG103.SP103.SubP101.N101]

As interfaces com os processos do ciclo de vida


relacionado ao produto deverão também ser identificadas.
[PA157.IG103.SP103.SubP101.N102]

Exemplos destas interfaces incluem interfaces com


equipamento de teste, sistemas de transporte, sistemas
de suporte e recursos de fabricação.
[PA157.IG103.SP103.SubP101.N103]

2. Desenvolver os requisitos para as interfaces identificadas.


[PA157.IG103.SP103.SubP102]

Veja a área de processo de Soluções Técnicas para obter maiores


informações sobre a geração de novas interfaces durante o
processo de design. [PA157.IG103.SP103.SubP102.R101]

Os requisitos das interfaces são definidos em termos de


características de origem, destino, estímulo e de dados
para o software e características elétricas e mecânicas
para o hardware. [PA157.IG103.SP103.SubP102.N102]

SG 3 Analisar e Validar os Requisitos

Os requisitos são analisados e validados e uma definição da funcionalidade


necessária é desenvolvida. [PA157.IG102]

As práticas específicas da meta específica Analisar e Validar Requisitos


suportam o desenvolvimento dos requisitos nas metas específicas
Desenvolver Requisitos do Cliente e Desenvolver Requisitos de
Produtos. As práticas específicas associadas com esta meta específica
cobrem a análise e validação dos requisitos com relação ao ambiente
pretendido para o usuário. [PA157.IG102.N104]

242 Nível de Maturidade: 3, Desenvolvimento de Requisitos


CMMI-SE/SW, v1.1
Representação em Estágios

As análises são executadas para determinar o impacto que o ambiente


operacional pretendido terá na capacidade de satisfazer as
necessidades, expectativas, restrições e interfaces dos stakeholders.
Considerações sobre a facilidade de construção, necessidades da
missão, restrições de custo, tamanho potencial do mercado e
estratégia de aquisição devem ser levadas em conta, dependendo do
contexto do produto. Uma definição da funcionalidade exigida é
também estabelecida. Todos os modos de utilização especificados para
o produto são considerados e uma análise de tempo é gerada para o
sequenciamento de funções criticamente dependentes do tempo.
[PA157.IG102.N101]

Os objetivos das análises são determinar os requisitos candidatos para


os conceitos de produtos que satisfarão as necessidades, expectativas
e restrições dos stakeholders e, então, traduzir estes conceitos em
requisitos. Em paralelo com esta atividade, os parâmetros que serão
utilizados para avaliar a eficiência do produto são determinados, com
base nas entradas do cliente e no conceito preliminar do produto.
[PA157.IG102.N102]

Os requisitos são validados para aumentar a probabilidade do produto


resultante funcionar como previsto no ambiente de uso. [PA157.IG102.N103]

SP 3.1 Estabelecer Conceitos e Cenários Operacionais


Estabelecer e manter conceitos e cenários operacionais
associados. [PA157.IG102.SP101]

Veja a área de processo de Soluções Técnicas para obter maiores


informações sobre o desenvolvimento detalhado de conceitos
operacionais que dependem dos designs selecionados.
[PA157.IG102.SP101.R101]

Um cenário é uma seqüência de eventos que podem ocorrer no uso do


produto, que é utilizado para tornar explícitas algumas das
necessidades dos stakeholders. Em contraste, um conceito operacional
para um produto normalmente depende da solução de design e do
cenário. Por exemplo, o conceito operacional para um produto de
comunicação por satélite é bastante diferente de outro baseado em
meridianos. Uma vez que as soluções alternativas normalmente ainda
não foram definidas quando se está preparando os conceitos
operacionais iniciais, as soluções conceituais são desenvolvidas para
serem utilizadas quando da análise dos requisitos. Os conceitos
operacionais são refinados conforme as decisões de soluções são
tomadas e requisitos detalhados de nível mais baixo são
desenvolvidos. [PA157.IG102.SP101.N101]

Nível de Maturidade: 3, Desenvolvimento de Requisitos 243


CMMI-SE/SW, v1.1
Representação em Estágios

Da mesma forma que uma decisão de design para um produto pode se


tornar um requisito para os componentes do produto, o conceito
operacional pode se tornar o cenário (requisitos) para os componentes
do produto. [PA157.IG102.SP101.N102]

Os cenários podem incluir seqüências operacionais, desde que essas


seqüências sejam uma expressão dos requisitos do cliente e não
conceitos operacionais. [PA157.IG102.SP101.N103]

Produtos de Trabalho Típicos


1. Conceito operacional [PA157.IG102.SP101.W101]

2. Conceitos de instalação do produto, operacionais, de manutenção


e de suporte [PA157.IG102.SP101.W102]

3. Conceitos de descarte [PA157.IG102.SP101.W103]

4. Use cases [PA157.IG102.SP101.W104]

5. Cenários dependentes do tempo [PA157.IG102.SP101.W105]

6. Novos requisitos [PA157.IG102.SP101.W106]

Sub-práticas
1. Desenvolver conceitos operacionais e cenários que incluem a
funcionalidade, desempenho, manutenção, suporte e descarte,
conforme apropriado. [PA157.IG102.SP101.SubP101]

Identificar e desenvolver cenários, consistentes com o


nível de detalhes nas necessidades, expectativas e
restrições dos stakeholders, sob os quais o produto
proposto deverá operar. [PA157.IG102.SP101.SubP101.N101]

2. Definir o ambiente no qual o produto irá operar, incluindo limites e


restrições. [PA157.IG102.SP101.SubP102]

3. Revisar os conceitos operacionais e cenários para refinar e


descobrir requisitos. [PA157.IG102.SP101.SubP103]

O desenvolvimento de conceitos operacionais e cenários é


um processo iterativo. As revisões deverão ocorrer
periodicamente para assegurar que estes atendem os
requisitos. A revisão pode tomar a forma de um
walkthrough. [PA157.IG102.SP101.SubP103.N101]

4. Desenvolver um detalhado conceito operacional, conforme os


produtos e componentes de produtos são selecionados, que define
a interação do produto, usuário final e ambiente e que satisfaz as
necessidades operacionais, de manutenção, de suporte e de
descarte. [PA157.IG102.SP101.SubP104]

244 Nível de Maturidade: 3, Desenvolvimento de Requisitos


CMMI-SE/SW, v1.1
Representação em Estágios

SP 3.2 Estabelecer uma Definição da Funcionalidade Exigida


Estabelecer e manter uma definição da funcionalidade exigida.
[PA157.IG102.SP102]

A definição da funcionalidade, também chamada de “análise funcional”,


é a descrição do que o produto deve fazer. A descrição da
funcionalidade pode incluir ações, seqüência, entradas, saídas e outras
informações que transmitem a maneira pela qual o produto será
utilizado. [PA157.IG102.SP102.N101]

A análise funcional não é a mesma coisa que a análise estruturada do


desenvolvimento de software e não presume um design de software
orientado a funcionalidades. No design de software orientado a objetos,
ela se relaciona com a definição dos serviços. A definição das funções,
seus agrupamentos lógicos e suas associações com os requisitos são
referenciados como uma arquitetura funcional. Veja a definição de
“arquitetura funcional” no Apêndice B, o glossário. [PA157.IG102.SP102.N102]

Produtos de Trabalho Típicos


1. Arquitetura funcional [PA157.IG102.SP102.W101]

2. Diagramas de atividades e use cases [PA157.IG102.SP102.W102]

3. Análise orientada a objetos com os serviços identificados


[PA157.IG102.SP102.W103]

Sub-práticas
1. Analisar e quantificar as funcionalidades exigidas pelos usuários
finais. [PA157.IG102.SP102.SubP101]

2. Analisar os requisitos para identificar particionamentos lógicos ou


funcionais (por exemplo, subfunções). [PA157.IG102.SP102.SubP102]

3. Particionar os requisitos em grupos com base em critérios


estabelecidos (por exemplo, funcionalidades semelhantes,
desempenho ou acoplamento), para facilitar e concentrar a análise
de requisitos. [PA157.IG102.SP102.SubP103]

4. Considerar a seqüência das funções críticas de tempo, tanto no


momento inicial como durante o desenvolvimento dos
componentes do produto. [PA157.IG102.SP102.SubP104]

5. Alocar os requisitos de clientes às partições funcionais, objetos,


pessoas ou elementos de suporte para suportar a síntese de
soluções. [PA157.IG102.SP102.SubP105]

6. Alocar requisitos funcionais e de desempenho a funções e


subfunções. [PA157.IG102.SP102.SubP106]

Nível de Maturidade: 3, Desenvolvimento de Requisitos 245


CMMI-SE/SW, v1.1
Representação em Estágios

SP 3.3 Analisar os Requisitos


Analisar os requisitos para assegurar que eles são necessários
e suficientes. [PA157.IG102.SP103]

À luz do conceito operacional e dos cenários, os requisitos para um


nível de hierarquia de produto são analisados para determinar se eles
são necessários e suficientes para atender os objetivos dos níveis mais
elevados da hierarquia do produto. Os requisitos analisados, então,
fornecem a base para requisitos mais precisos e detalhados para os
nível mais baixos da hierarquia do produto. [PA157.IG102.SP103.N102]

Conforme os requisitos são definidos, seus relacionamentos com


requisitos e funcionalidades de mais alto nível devem ser entendidos.
Uma outra ação é a determinação dos requisitos chave que serão
utilizados para rastrear o progresso técnico. Por exemplo, o peso de
um produto ou tamanho de um produto de software podem ser
monitorados através do desenvolvimento baseado no seu risco.
[PA157.IG102.SP103.N101]

Produtos de Trabalho Típicos


1. Relatórios de defeitos em requisitos [PA157.IG102.SP103.W101]

2. Mudanças propostas nos requisitos para resolver defeitos


[PA157.IG102.SP103.W102]

3. Requisitos chave [PA157.IG102.SP103.W103]

4. Medidas de desempenho técnico [PA157.IG102.SP103.W104]

Sub-práticas
1. Analisar as necessidades, expectativas e interfaces externas dos
stakeholders para remover conflitos e organizá-las em assuntos
relacionados. [PA157.IG102.SP103.SubP101]

2. Analisar requisitos para determinar se eles satisfazem os objetivos


de requisitos de nível mais alto. [PA157.IG102.SP103.SubP102]

3. Analisar requisitos para assegurar que eles são completos,


possíveis de serem executados, percebidos e verificados.
[PA157.IG102.SP103.SubP103]

Embora o design determine a possibilidade de se construir


uma solução específica, esta sub-prática trata da
descoberta de quais requisitos afetam esta possibilidade.
[PA157.IG102.SP103.SubP103.N101]

4. Identificar requisitos chave que têm uma forte influência no custo,


cronograma, funcionalidade, risco ou desempenho.
[PA157.IG102.SP103.SubP104]

246 Nível de Maturidade: 3, Desenvolvimento de Requisitos


CMMI-SE/SW, v1.1
Representação em Estágios

5. Identificar medidas de desempenho técnico que serão rastreadas


durante o esforço de desenvolvimento. [PA157.IG102.SP103.SubP105]

Veja a área de processo de Medições e Análises para obter


maiores informações sobre o uso de medições.
[PA157.IG102.SP103.SubP105.R101]

6. Analisar os conceitos operacionais e cenários para refinar as


necessidades, restrições e interfaces dos clientes e descobrir
novos requisitos. [PA157.IG102.SP103.SubP106]

Esta análise pode resultar em conceitos operacionais e


cenários mais detalhados, bem como suportar a derivação
de novos requisitos. [PA157.IG102.SP103.SubP106.N101]

SP 3.4 Analisar os Requisitos para Alcançar o Equilíbrio


Analisar os requisitos para equilibrar as necessidades e as
restrições dos stakeholders. [PA157.IG102.SP104]

As necessidades dos stakeholders e as restrições podem tratar de


custos, cronograma, desempenho, funcionalidade, componentes
reusáveis, possibilidade de manutenção e riscos. [PA157.IG102.SP104.N102]

Produtos de Trabalho Típicos


1. Análise de riscos relacionados a requisitos [PA157.IG102.SP104.W101]

Sub-práticas
1. Usar modelos comprovados, simulações e protótipos para analisar
o equilíbrio entre as necessidades dos stakeholders e as
restrições. [PA157.IG102.SP104.SubP103]

Os resultados das análises podem ser usados para reduzir


o custo do produto e o risco do desenvolvimento do
produto. [PA157.IG102.SP104.SubP103.N101]

2. Executar uma análise dos riscos sobre os requisitos e a arquitetura


funcional. [PA157.IG102.SP104.SubP101]

Veja a área de processo de Gerenciamento de Riscos para obter


maiores informações sobre como executar uma análise de riscos
sobre os requisitos de clientes e do produto e a arquitetura
funcional. [PA157.IG102.SP104.SubP101.R101]

3. Examinar os conceitos do ciclo de vida do produto com relação ao


impacto dos requisitos nos riscos. [PA157.IG102.SP104.SubP102]

Nível de Maturidade: 3, Desenvolvimento de Requisitos 247


CMMI-SE/SW, v1.1
Representação em Estágios

SP 3.5 Validar os Requisitos com Métodos Abrangentes


Validar os requisitos para assegurar que o produto resultante
funcionará como previsto no ambiente do usuário utilizando
diversas técnicas, conforme necessário. [PA157.IG102.SP106]

A validação dos requisitos é executada antecipadamente ao esforço de


desenvolvimento para se adquirir a confiança de que os requisitos são
capazes de guiar um desenvolvimento que resultará numa validação
final bem sucedida. Esta atividade deverá estar integrada com as
atividades de gerenciamento de riscos. Organizações maduras
normalmente farão a validação dos requisitos de forma mais sofisticada
e irão ampliar a base de validação para incluir outras necessidades e
expectativas dos stakeholders. Estas organizações geralmente farão
análises, simulações ou protótipos para assegurar que os requisitos
satisfarão as necessidades e expectativas dos stakeholders.
[PA157.IG102.SP106.N102]

Produtos de Trabalho Típicos


1. Registro dos métodos e resultados da análise [PA157.IG102.SP106.W101]

Sub-práticas
1. Analisar os requisitos para determinar o risco do produto resultante
não funcionar apropriadamente no seu ambiente de uso previsto.
[PA157.IG102.SP106.SubP101]

2. Explorar a adequação e a completitude dos requisitos através do


desenvolvimento de representações do produto (por exemplo,
protótipos, simulações, modelos, cenários e storyboards) e da
obtenção de feedback sobre eles dos stakeholders relevantes.
[PA157.IG102.SP106.SubP102]

3. Analisar o design, conforme ele amadurece, no contexto do


ambiente de validação dos requisitos para identificar questões de
validação e expor necessidades e requisitos de clientes não
declarados. [PA157.IG102.SP106.SubP103]

A seguinte prática específica aparece na representação contínua como SP 3.5-1,


mas está categorizada na representação em estágios como SP 3.5, Validar os
Requisitos com Métodos Abrangentes. A prática específica está apresentada aqui
em cinza somente como material informativo.

SP 3.5-1 Validar Requisitos


Validar os requisitos para assegurar que o produto resultante
funcionará adequadamente no seu ambiente de uso previsto.
[PA157.IG102.SP105]

248 Nível de Maturidade: 3, Desenvolvimento de Requisitos


CMMI-SE/SW, v1.1
Representação em Estágios

Produtos de Trabalho Típicos


1. Resultados da validação de requisitos [PA157.IG102.SP105.W101]

Sub-práticas
1. Analisar os requisitos para determinar o risco do produto resultante
não funcionar apropriadamente no seu ambiente de uso previsto.
[PA157.IG102.SP105.SubP101]

GG 3 Institucionalizar um Processo Definido [CL104.GL101]

O processo é institucionalizado como um processo definido.

Compromisso

GP 2.1 (CO 1) Estabelecer uma Política Organizacional


Estabelecer e manter uma política organizacional para o
planejamento e execução do processo de desenvolvimento de
requisitos. [GP103]

Elaboração:

Esta política estabelece as expectativas organizacionais para a coleta


das necessidades dos stakeholders, formulação dos requisitos de
produtos e componentes de produtos e análise e validação destes
requisitos. [PA157.EL101]

Habilitações

GP 3.1 (AB 1) Estabelecer um Processo Definido


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

GP 2.2 (AB 2) Planejar o Processo


Estabelecer e manter o plano para a execução do processo de
desenvolvimento de requisitos. [GP104]

Nível de Maturidade: 3, Desenvolvimento de Requisitos 249


CMMI-SE/SW, v1.1
Representação em Estágios

Elaboração:

Normalmente, este plano para a execução do processo de


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

GP 2.3 (AB 3) Fornecer Recursos


Fornecer recursos adequados para a execução do processo de
desenvolvimento de requisitos, desenvolvimento dos produtos
de trabalho e fornecimento dos serviços do processo. [GP105]

Elaboração:

Especialização no domínio da aplicação, métodos para a elicitação de


necessidades dos stakeholders e métodos e ferramentas para
especificar e analisar requisitos de clientes, produtos e componentes
de produtos podem ser necessários. [PA157.EL103]

Exemplos de outros recursos fornecidos incluem as seguintes


ferramentas: [PA157.EL104]

• Ferramentas de especificação de requisitos


• Ferramentas de simulação e modelagem
• Ferramentas de prototipação
• Ferramentas de definição e gerenciamento de cenários
• Ferramentas de rastreamento de requisitos

GP 2.4 (AB 4) Atribuir Responsabilidades


Atribuir responsabilidades e autoridade pela execução do
processo, desenvolvimento dos produtos de trabalho e
fornecimento dos serviços do processo de desenvolvimento de
requisitos. [GP106]

GP 2.5 (AB 5) Treinar as Pessoas


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

250 Nível de Maturidade: 3, Desenvolvimento de Requisitos


CMMI-SE/SW, v1.1
Representação em Estágios

Elaboração:

Exemplos de tópicos de treinamento incluem: [PA157.EL105]

• Domínio da aplicação
• Definição e análise de requisitos
• Elicitação de requisitos
• Especificação e modelagem de requisitos
• Rastreamento de requisitos

Implementações

GP 2.6 (DI 1) Gerenciar Configurações


Colocar os produtos de trabalho definidos do processo de
desenvolvimento de requisitos sob os níveis apropriados de
gerenciamento de configurações. [GP109]

Elaboração:

Exemplos de produtos de trabalho colocados sob


gerenciamento de configurações incluem: [PA157.EL106]

• Requisitos de clientes
• Arquitetura funcional
• Requisitos de produtos e componentes de produtos
• Requisitos de interfaces

GP 2.7 (DI 2) Identificar e Envolver os Stakeholders Relevantes


Identificar e envolver os stakeholders relevantes do processo
de desenvolvimento de requisitos, conforme planejado. [GP124]

Elaboração:

Selecionar stakeholders relevantes a partir de clientes, usuários finais,


desenvolvedores, produtores, testadores, fornecedores, pessoal de
marketing, manutenção, descarte e outros que podem ser afetados ou
afetar o produto, bem como o processo. [PA157.EL113]

Nível de Maturidade: 3, Desenvolvimento de Requisitos 251


CMMI-SE/SW, v1.1
Representação em Estágios

Exemplos de atividades de envolvimento de stakeholders


incluem: [PA157.EL114]

• Revisar a adequação dos requisitos no atendimento das


necessidades, expectativas, restrições e interfaces
• Estabelecer conceitos operacionais e cenários
• Analisar a adequação dos requisitos
• Estabelecer os requisitos de produtos e componentes de
produtos
• Analisar o custo do produto, cronograma e riscos

GP 2.8 (DI 3) Monitorar e Controlar o Processo


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

Elaboração:

Exemplos de medidas utilizadas no monitoramento e


controle incluem: [PA157.EL110]

• Custo, cronograma e esforço dispendido para retrabalho


• Densidade de defeitos por especificações de requisitos

GP 3.2 (DI 4) Coletar Informações de Melhorias


Coletar produtos de trabalho, medidas, resultados de medições
e informações de melhorias derivados do planejamento e
execução do processo de desenvolvimento de requisitos para
suportar o uso futuro e a melhoria dos processo e ativos de
processos da organização. [GP117]

Verificações

GP 2.9 (VE 1) Avaliar Objetivamente a Aderência


Avaliar objetivamente a aderência do processo de
desenvolvimento de requisitos contra sua descrição de
processo, padrões, procedimentos e tratar as não
conformidades. [GP113]

252 Nível de Maturidade: 3, Desenvolvimento de Requisitos


CMMI-SE/SW, v1.1
Representação em Estágios

Elaboração:

Exemplos de atividades revisadas incluem: [PA157.EL111]

• Coletar as necessidades dos stakeholders


• Formular requisitos de produtos e de componentes de
produtos
• Analisar e validar os requisitos de produtos e de
componentes de produtos

Exemplos de produtos de trabalho revisados incluem:


[PA157.EL112]

• Requisitos de produtos
• Requisitos de componentes de produtos
• Requisitos de interfaces
• Arquitetura funcional

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


Revisar as atividades, status e resultados do processo de
desenvolvimento de requisitos com o nível mais elevado de
gerência e resolver questões. [GP112]

Nível de Maturidade: 3, Desenvolvimento de Requisitos 253


CMMI-SE/SW, v1.1
Representação em Estágios

SOLUÇÕES TÉCNICAS
Nível de Maturidade 3

Objetivo

O objetivo das Soluções Técnicas (Technical Solution) é criar o design,


desenvolver e implementar soluções para os requisitos. Soluções,
designs e implementações englobam produtos, componentes de
produtos e processos relacionados com o ciclo de vida do produto,
isoladamente ou combinados, conforme apropriado. [PA160]

Notas Introdutórias

A área de processo de Soluções Técnicas é aplicável em qualquer


nível da arquitetura do produto e a todos os produtos, componentes de
produtos, processos relacionados com o ciclo de vida do produto e
serviços. A área de processo se concentra no seguinte: [PA160.N101]

• Avaliar e selecionar soluções (algumas vezes referenciadas como


“abordagens de design”, “conceitos de design” ou “designs
preliminares”) que potencialmente satisfazem um conjunto
apropriado de requisitos alocados
• Desenvolver designs detalhados para as soluções selecionadas
(detalhados no contexto de conter todas as informações
necessárias para a construção, codificação ou outro tipo de
implementação do design como um produto ou componente de
produto).
• Implementar os designs como um produto ou componente de
produto

Geralmente, estas atividades suportam interativamente umas às


outras. Algum nível de design, às vezes moderadamente detalhado,
pode ser necessário para selecionar soluções. Protótipos de
componentes de produtos podem ser utilizados como meios de obter
um conhecimento suficiente para desenvolver um pacote de dados
técnicos ou um conjunto completo de requisitos. [PA160.N102]

As práticas específicas de Soluções Técnicas se aplicam não somente


ao produto e componentes do produto, mas também aos serviços e
processos relacionados com o ciclo de vida do produto. Os processos
relacionados com o ciclo de vida do produto são desenvolvidos
conjuntamente com o produto ou componente do produto. Tal
desenvolvimento pode incluir selecionar e adaptar processos existentes
(incluindo processos padrão) para o uso, bem como desenvolver novos
processos. [PA160.N103]

254 Nível de Maturidade: 3, Soluções Técnicas


CMMI-SE/SW, v1.1
Representação em Estágios

Os processos associados com a área de processo de Soluções


Técnicas recebem os requisitos do produto e dos componentes de
produtos dos processos de gerenciamento de requisitos. Os processos
de gerenciamento de requisitos colocam os requisitos, que se originam
dos processos de desenvolvimento de requisitos, sob o gerenciamento
de configurações apropriado e mantêm sua rastreabilidade aos
requisitos anteriores. [PA160.N104]

Para uma organização de manutenção ou sustentação, os requisitos


que precisam de ações de manutenção ou redesign podem ser
direcionados pelas necessidades dos usuários ou defeitos latentes nos
componentes do produto. Novos requisitos podem surgir de mudanças
no ambiente operacional. Tais requisitos podem ser descobertos
durante a verificação de produto(s), onde o desempenho real possa ser
comparado contra o desempenho especificado e uma degradação
inaceitável possa ser identificada. Os processos associados com a
área de processo de Soluções Técnicas deverão ser utilizados para
executar os esforços de manutenção ou sustentação do design.
[PA160.N105]

Áreas de Processos Relacionadas

Veja a área de processo de Desenvolvimento de Requisitos para obter


maiores informações sobre alocação de requisitos, estabelecimento de
um conceito operacional e definição de requisitos de interface. [PA160.R101]

Veja a área de processo de Verificação para obter maiores informações


sobre a condução de revisões por pares e verificação se o produto e os
componentes do produto atendem os requisitos. [PA160.R102]

Veja a área de processo de Análise de Decisões e Resoluções para


obter maiores informações sobre avaliação formal. [PA160.R103]

Veja a área de processo de Gerenciamento de Requisitos para obter


maiores informações sobre o gerenciamento de requisitos. As práticas
específicas da área de processo de Gerenciamento de Requisitos são
executadas de forma interativa com as da área de processo de
Soluções Técnicas. [PA160.R104]

Veja a área de processo de Inovação e Desenvolvimento


Organizacional para obter maiores informações sobre como melhorar a
tecnologia da organização. [PA160.R105]

Nível de Maturidade: 3, Soluções Técnicas 255


CMMI-SE/SW, v1.1
Representação em Estágios

Metas Específicas e Genéricas

SG 1 Selecionar Soluções de Componentes de Produtos [PA160.IG101]

Soluções de produtos ou componentes de produtos são selecionadas a


partir de soluções alternativas.

SG 2 Desenvolver o Design [PA160.IG102]

O design dos produtos e componentes de produtos é desenvolvido.

SG 3 Implementar o Design do Produto [PA160.IG103]

Os componentes de produto e documentação de suporte associada são


implementados a partir de seus designs.

GG 3 Institucionalizar um Processo Definido [CL104.GL101]

O processo é institucionalizado como um processo definido.

Tabela de Relacionamentos Práticas-Metas

SG 1 Selecionar Soluções de Componentes de Produtos [PA160.IG101]

SP 1.1 Desenvolver Soluções Alternativas Detalhadas e Critérios de Seleção


SP 1.2 Evoluir Conceitos Operacionais e Cenários
SP 1.3 Selecionar Soluções de Componentes de Produtos
SG 2 Desenvolver o Design [PA160.IG102]

SP 2.1 Criar o Design do Produto ou Componente do Produto


SP 2.2 Estabelecer um Pacote de Dados Técnicos
SP 2.3 Criar o Design das Interfaces Utilizando os Critérios
SP 2.4 Executar Análises de Construção, Compra ou Reuso
SG 3 Implementar o Design do Produto [PA160.IG103]

SP 3.1 Implementar o Design


SP 3.2 Desenvolver a Documentação de Suporte do Produto
GG 3 Institucionalizar um Processo Definido [CL104.GL101]

GP 2.1 (CO 1) Estabelecer uma Política Organizacional


GP 3.1 (AB 1) Estabelecer um Processo Definido
GP 2.2 (AB 2) Planejar o Processo
GP 2.3 (AB 3) Fornecer Recursos
GP 2.4 (AB 4) Atribuir Responsabilidades
GP 2.5 (AB 5) Treinar as Pessoas
GP 2.6 (DI 1) Gerenciar Configurações

256 Nível de Maturidade: 3, Soluções Técnicas


CMMI-SE/SW, v1.1
Representação em Estágios

GP 2.7 (DI 2) Identificar e Envolver os Stakeholders Relevantes


GP 2.8 (DI 3) Monitorar e Controlar o Processo
GP 3.2 (DI 4) Coletar Informações de Melhorias
GP 2.9 (VE 1) Avaliar Objetivamente a Aderência
GP 2.10 (VE 2) Revisar o Status com o Nível Mais Alto de Gerência

Práticas Específicas por Meta

SG 1 Selecionar Soluções de Componentes de Produto

Soluções de produtos ou componentes de produtos são selecionadas a


partir de soluções alternativas. [PA160.IG101]

As soluções alternativas e seus méritos relativos são considerados


antes de selecionar uma solução. Requisitos chave, questões de
design e restrições são estabelecidos para o uso na análise de
soluções alternativas. Recursos de arquitetura que fornecem uma
fundação para a melhoria e evolução do produto são considerados. O
uso de componentes de produto “de prateleira” é considerado com
relação ao custo, cronograma, desempenho e riscos. As alternativas de
prateleira podem ser utilizadas com ou sem modificações. Algumas
vezes, tais itens podem exigir modificações em aspectos como
interfaces ou uma customização de alguns de seus recursos para
melhor atender os requisitos de produtos. [PA160.IG101.N101]

Um indicador de um bom processo de design é que o design foi


escolhido após ter sido comparado e avaliado contra soluções
alternativas. Decisões sobre arquitetura, desenvolvimento
customizados versus compra de produto de prateleira e modularização
de componentes de produtos são as opções típicas de design que são
tratadas. [PA160.IG101.N102]

Algumas vezes, a pesquisa por soluções examina instâncias


alternativas dos mesmos requisitos, sem precisar de alocações a um
nível mais baixo de componentes do produto. Este é o caso na base da
arquitetura do produto. Existem também casos onde uma ou mais
soluções são estabelecidas (por exemplo, uma solução específica é
direcionada ou componentes de produtos disponíveis, como os de
prateleira, são examinados para serem utilizados). [PA160.IG101.N103]

Nível de Maturidade: 3, Soluções Técnicas 257


CMMI-SE/SW, v1.1
Representação em Estágios

No caso geral, as soluções são definidas como um conjunto. Isto é,


quando se está definindo a próxima camada de componentes de
produtos, a solução para cada componente de produto do conjunto é
estabelecida. As soluções alternativas são, não somente diferentes
maneiras de se tratar os mesmos requisitos, mas elas também refletem
uma diferente alocação de requisitos entre os componentes de produto
que compõem o conjunto da solução. O objetivo é otimizar o conjunto
como um todo e não as peças individuais. Existirá uma interação
significativa com os processos associados com a área de processo de
Desenvolvimento de Requisitos para suporte às alocações provisionais
de componentes de produtos, até que um conjunto de soluções seja
selecionado e as alocações finais estabelecidas. [PA160.IG101.N104]

Processos relacionados com o ciclo de vida do produto estão entre as


soluções de componentes de produtos que são selecionadas entre as
soluções alternativas. Exemplos destes processos relacionados com o
ciclo de vida do produto estão os processos de construção e de
suporte. [PA160.IG101.N105]

SP 1.1 Desenvolver Soluções Alternativas Detalhadas e Critérios de


Seleção
Desenvolver soluções alternativas detalhadas e critérios de
seleção. [PA160.IG101.SP102]

Veja a área de processo de Análises de Decisões e Resoluções para


obter maiores informações sobre como estabelecer critérios utilizados
na tomada de decisões. [PA160.IG101.SP102.R101]

As soluções alternativas detalhadas são um conceito essencial da área


de processo de Soluções Técnicas. Elas fornecem informações mais
precisas e abrangentes sobre a solução que alternativas não
detalhadas. Por exemplo, a caracterização do desempenho baseada
no conteúdo do design, em lugar de uma simples estimativa possibilita
uma efetiva avaliação e entendimento dos impactos do ambiente e do
conceito operacional. Soluções alternativas precisam ser identificadas
e analisadas para possibilitar a seleção de uma solução balanceada
durante toda a vida do produto em termos de custo, cronograma e
desempenho técnico. Estas soluções se baseiam nas arquiteturas de
produto propostas que tratam das qualidades críticas do produto. As
práticas específicas associadas com a meta específica Desenvolver o
Design fornecem maiores informações sobre o desenvolvimento de
arquiteturas potenciais de produtos que podem ser incorporadas em
soluções alternativas para o produto. [PA160.IG101.SP102.N104]

258 Nível de Maturidade: 3, Soluções Técnicas


CMMI-SE/SW, v1.1
Representação em Estágios

Soluções alternativas estendem a faixa aceitável de custo, cronograma


e desempenho. Os requisitos de componentes de produtos são
recebidos e utilizados com as questões de design, restrições e critérios
para desenvolver as soluções alternativas. Os critérios de seleção
normalmente tratarão de custos (por exemplo, tempo, pessoas,
dinheiro), benefícios (por exemplo, desempenho, capacidade,
eficiência) e riscos (por exemplo, técnicos, de custo, de cronograma).
Considerações sobre as soluções alternativas detalhadas e os critérios
de seleção incluem: [PA160.IG101.SP102.N102]

• Custo (desenvolvimento, compras, suporte, ciclo de vida do


produto)
• Desempenho técnico
• Complexidade dos componentes do produto e dos processos
relacionados com o ciclo de vida do produto
• Robustez das condições de operação e uso do produto, modos de
operação, ambientes e variações nos processos relacionados com
o ciclo de vida do produto
• Expansão e crescimento do produto
• Limitações tecnológicas
• Sensibilidade aos métodos e materiais de construção
• Riscos
• Evolução dos requisitos e tecnologia
• Descarte
• Capacitação e limitações dos usuários finais e operadores

As considerações listadas acima são um conjunto básico; as


organizações deverão desenvolver critérios de avaliação para restringir
a lista de alternativas que são consistentes com seus objetivos de
negócios. Custo do ciclo de vida do produto, embora seja um
parâmetro que se deseja minimizar, pode estar fora do controle das
organizações de desenvolvimento. Um cliente pode não desejar pagar
por recursos que custam mais no curto prazo, mas que fazem o custo
ao longo da vida do produto decrescer. Em tais casos, os clientes
deverão, pelo menos, ser avisados de potenciais reduções dos custos
do ciclo de vida. Os critérios utilizados na seleção de soluções finais
deverão fornecer uma abordagem balanceada de custos, benefícios e
riscos. [PA160.IG101.SP102.N103]

Produtos de Trabalho Típicos


1. Critérios de avaliação de soluções alternativas [PA160.IG101.SP102.W103]

2. Avaliações de novas tecnologias [PA160.IG101.SP102.W104]

3. Soluções alternativas [PA160.IG101.SP102.W101]

Nível de Maturidade: 3, Soluções Técnicas 259


CMMI-SE/SW, v1.1
Representação em Estágios

4. Critérios de seleção para a seleç