CMMI em Português

EM EM PORTUGUPORTUGU

ÊSÊS

CMMI-SE/SW, v1.1Representaçã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


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.

Prefácioii


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


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 [email protected]. [FM101.HDA104.T103]

Prefácioiv


Conteúdo

Prefácio iHistórico do Desenvolvimento iAgradecimentos iiiOnde Procurar Informações Adicionais ivFeedback iv

1 Introdução 1Sobre os Modelos CMMI 1Selecionando 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 5Convençõ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 10Visã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


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 16

Componentes Exigidos, Esperados e Informativos 18

Componentes do Modelo 19Áreas de Processos 19

Metas Específicas 19

Práticas Específicas 19

Características Comuns 20

Produtos de Trabalho Típicos 20

Sub-práticas 20

Definições Ampliadas de Disciplinas 20

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 24Evolução da Terminologia 24Terminologia 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

Prefáciovi


Validação 30

Meta 30

Objetivo 30

Objetivos de Qualidade e Desempenho do Processo 31

Padrão 31

Terminologia Específica do CMMI 31CMMI 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 37Visão Geral 37Características da Institucionalização 37Metas Genéricas 39Características Comuns 40Práticas Genéricas Listadas por Características Comuns 40

5 Interações do Framework 52Quatro Categorias de Áreas de Processos do CMMI 52Gerenciamento de Processos 53

O Escopo do Gerenciamento de Processos 53

Áreas de Processos Básicas do Gerenciamento de Processos 54

Áreas de Processos Avançadas do Gerenciamento de Processos 56

Gerenciamento de Projetos 58O Escopo do Gerenciamento de Projetos 58

Áreas de Processos Básicas do Gerenciamento de Projetos 59

Áreas de Processos Avançadas de Gerenciamento de Projetos 60

Engenharia 63O Escopo da Engenharia 63

Interações Entre as Áreas de Processos de Engenharia 64

Áreas de Processos de Engenharia e Recursão 67

Suporte 68

Prefácio vii


O Escopo do Suporte 68

Áreas de Processos Básicas de Suporte 69

Áreas de Processos Avançadas de Suporte 71

6 Utilizando os Modelos CMMI 75Interpretando os Modelos CMMI 75Avaliações e Benchmarking 76

Requisitos de Avaliações para o CMMI 78

Compatibilidade e Conformidade com o ISO/IEC 15504 78

Fazendo a Transição para o CMMI 79Organizações com Experiência no CMM para Software 79

Organizações com Experiência em EIA/IS 731 80

Organizações Não Familiarizadas com os Modelos do Tipo CMM 81

Treinamento 82

Perspectivas de Adaptação 82Adaptação do Modelo 82

Perspectivas de Adaptação do Modelo 82

Critérios de Adaptação de Modelos para Melhoria de Processos Internos 83

Critérios de Adaptação de Modelos para Benchmarking 84

Adaptação de Modelos para Pequenos Projetos 85

Adaptação de Avaliações 86

7 Áreas de Processos 88Nível de Maturidade 2: Gerenciado 90

Gerenciamento de Requisitos 91

Planejamento do Projeto 103

Monitoramento e Controle do Projeto 132

Gerenciamento de Acordos com Fornecedores 147

Medições e Análises 164

Garantia da Qualidade do Processo e do Produto 186

Gerenciamento de Configurações 198

Nível de Maturidade 3: Definido 218Desenvolvimento de Requisitos 219

Soluções Técnicas 242

Integração de Produtos 275

Verificação 297

Validação 316

Foco no Processo Organizacional 329

Definição do Processo Organizacional 347

Treinamento Organizacional 364

Gerenciamento Integrado do Projeto 381

Gerenciamento de Riscos 403

Análises de Decisões e Resoluções 424

Prefácioviii


A. Acrônimos 438

B. Glossário 443

C. Elementos Exigidos e Esperados do Modelo 473Nível de Maturidade: 2 474

Gerenciamento de Requisitos 475

Planejamento do Projeto 478

Monitoramento e Controle do Projeto 483

Gerenciamento de Acordos com Fornecedores 487

Medições e Análises 491

Garantia da Qualidade do Processo e do Produto 495

Gerenciamento de Configurações 499

Nível de Maturidade: 3 504Desenvolvimento de Requisitos 505

Soluções Técnicas 510

Integração de Produtos 515

Verificação 520

Validação 524

Foco no Processo Organizacional 528

Definição do Processo Organizacional 532

Treinamento Organizacional 536

Gerenciamento Integrado do Projeto 540

Gerenciamento de Riscos 544

Análises de Decisões e Resoluções 548

Prefácio ix


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


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

Visão Geral2


Oferecerá uma migração fácil do Electronic Industries Alliance Interim Standard (EIA/IS) 731 para o CMMI

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


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]

Visão Geral4


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


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]

Visão Geral6


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


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]

Visão Geral8


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


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]

Visão Geral10


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


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]

Visão Geral12


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


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.

Visão Geral14


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


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]

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]

Visão Geral16


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]

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]

Visão Geral 17


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

Visão Geral18


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]

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]

Visão Geral 19


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]

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]

Visão Geral20


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


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.

Visão Geral22


Nível de Capacitação

Níveis de Capacitação da Representação Contínua

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 Maturidade

Níveis de Maturidade da 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


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]

Visão Geral24


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


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]

Visão Geral26


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


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]

Visão Geral28


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


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]

Visão Geral30


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


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]

Visão Geral32


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


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]

Visão Geral34


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


Visão Geral36


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


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

Visão Geral38


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


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]

Visão Geral40


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


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]

Visão Geral42


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]

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]

Visão Geral 43


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]

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]

Visão Geral44


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.

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]

Visão Geral 45


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.

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]

Visão Geral46


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

Decisões

Comunicações

Coordenação

Revisões

Avaliações

Definições de requisitos

Resolução de problemas/questões

Visão Geral 47


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.

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]

Visão Geral48


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

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.

Visão Geral 49


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]

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.

Visão Geral50


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.

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]

Visão Geral 51


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 Geral52


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)

Definição do Processo Organizacional (Organizational Process Definition)

Visão Geral 53


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 Geral54


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]

Visão Geral 55


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 Geral56


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]

Visão Geral 57


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 Geral58


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]

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.

Visão Geral 59


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 Geral60


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]

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]


Visão Geral 61


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 Geral62


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)

Visão Geral 63


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]


Visão Geral64


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]

Visão Geral 65


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 Geral66


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]

Visão Geral 67


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 Geral68


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]


Visão Geral 69


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 Geral70


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]


Visão Geral 71


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 Geral72


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]

Visão Geral 73


Visão Geral74


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]

Visão Geral 75


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

Uso de um método de avaliação documentado

Visão Geral76


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.

Visão Geral 77


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 Geral78


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]

Visão Geral 79


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 Geral80


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.

Visão Geral 81


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 Geral82


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]

Visão Geral 83


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 excluídas. Além disso,

Visão Geral84


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]

Visão Geral 85


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 Geral86


Visão Geral 87


7 Áreas de Processos

88


89


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]

Nível de Maturidade: 290


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]

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


Áreas de Processos Relacionadas

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

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

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

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

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

Veja a área de processo de Gerenciamento de Requisitos para obter maiores informações sobre a identificação e tratamento de riscos associados com requisitos. [PA146.R106]


SG 1 Gerenciar Requisitos [PA146.IG101]

Os requisitos são gerenciados e as inconsistências com os planos do projeto e os produtos de trabalho são identificadas.

GG 2 Institucionalizar um Processo Gerenciado [CL103.GL101]


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


Nível de Maturidade: 2, Gerenciamento de Requisitos92


Tabela de Relacionamentos Práticas-Metas

SG 1 Gerenciar Requisitos [PA146.IG101]

SP 1.1 Obter um Entendimento dos RequisitosSP 1.2 Obter Compromisso sobre os RequisitosSP 1.3 Gerenciar Mudanças nos RequisitosSP 1.4 Manter a Rastreabilidade Bidirecional dos RequisitosSP 1.5 Identificar Inconsistências entre o Trabalho do Projeto e os Requisitos


GP 2.1 (CO 1) Estabelecer uma Política OrganizacionalGP 2.2 (AB 1) Planejar o ProcessoGP 2.3 (AB 2) Fornecer RecursosGP 2.4 (AB 3) Atribuir ResponsabilidadesGP 2.5 (AB 4) Treinar as PessoasGP 2.6 (DI 1) Gerenciar ConfiguraçõesGP 2.7 (DI 2) Identificar e Envolver os Stakeholders RelevantesGP 2.8 (DI 3) Monitorar e Controlar o ProcessoGP 2.9 (VE 1) Avaliar Objetivamente a AderênciaGP 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).


GP 3.1 Estabelecer um Processo DefinidoGP 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

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]


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

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]

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


1. Análises de impacto de requisitos [PA146.IG101.SP102.W101]

2. Compromissos documentados com os requisitos e com as mudanças de requisitos [PA146.IG101.SP102.W102]



Sub-práticas

1. Analisar o impacto dos requisitos nos compromissos existentes. [PA146.IG101.SP102.SubP101]

O impacto nos participantes do projeto deverá ser avaliado quando os requisitos mudarem ou no início de um novo requisito. [PA146.IG101.SP102.SubP101.N101]

2. Negociar e registrar compromissos. [PA146.IG101.SP102.SubP102]

As mudanças nos compromissos existentes deverão ser negociadas antes dos participantes do projeto assumirem compromissos com o requisito ou com a mudança de requisitos. [PA146.IG101.SP102.SubP102.N101]

SP 1.3 Gerenciar as Mudanças de Requisitos

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

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]

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


1. Status de requisitos [PA146.IG101.SP103.W101]

2. Banco de dados de requisitos [PA146.IG101.SP103.W102]

3. Banco de dados de decisões de requisitos [PA146.IG101.SP103.W103]

Sub-práticas

1. Capturar todos os requisitos e mudanças de requisitos que foram recebidas ou geradas pelo projeto. [PA146.IG101.SP103.SubP101]

2. Manter o histórico das mudanças nos requisitos juntamente com a justificativa para as mudanças. [PA146.IG101.SP103.SubP102]



Manter o histórico de mudanças auxilia a rastrear a volatilidade dos requisitos. [PA146.IG101.SP103.SubP102.N101]

3. Avaliar o impacto das mudanças nos requisitos a partir do ponto de vista dos stakeholders relevantes. [PA146.IG101.SP103.SubP103]

4. Tornar disponíveis para o projeto os dados de requisitos e de mudanças. [PA146.IG101.SP103.SubP104]

SP 1.4 Manter a Rastreabilidade Bidirecional de Requisitos

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

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


1. Matriz de rastreabilidade de requisitos [PA146.IG101.SP104.W101]

2. Sistema de rastreamento de requisitos [PA146.IG101.SP104.W102]

Sub-práticas

1. Manter a rastreabilidade dos requisitos para assegurar que a fonte dos requisitos de mais baixo nível (derivados) está documentada. [PA146.IG101.SP104.SubP101]

2. Manter a rastreabilidade dos requisitos até seu requisito derivado, bem como a sua alocação de funções, objetos, pessoas, processos e produtos de trabalho. [PA146.IG101.SP104.SubP102]

3. Manter a rastreabilidade horizontal de função para função e entre interfaces. [PA146.IG101.SP104.SubP103]

4. Gerar a matriz de rastreabilidade de requisitos. [PA146.IG101.SP104.SubP104]



SP 1.5 Identificar Inconsistências entre o Trabalho do Projeto e os Requisitos

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

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]

Esta prática específica descobre as inconsistências entre os requisitos e os planos do projeto e produtos de trabalho e inicia a ação corretiva para corrigi-las. [PA146.IG101.SP105.N101]


1. Documentação de inconsistências incluindo fontes, condições e justificativas [PA146.IG101.SP105.W101]

2. Ações corretivas [PA146.IG101.SP105.W102]

Sub-práticas

1. Revisar os planos do projeto, atividades e produtos de trabalho com relação à consistência com os requisitos e com as mudanças que foram feitas. [PA146.IG101.SP105.SubP101]

2. Identificar a fonte da inconsistência e sua justificativa. [PA146.IG101.SP105.SubP102]

3. Identificar as mudanças que precisam ser feitas nos planos e produtos de trabalho resultantes das mudanças na baseline de requisitos. [PA146.IG101.SP105.SubP103]

4. Iniciar as ações corretivas. [PA146.IG101.SP105.SubP104]



Compromisso

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]

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]



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]



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)


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

Exemplos de produtos de trabalho revisados incluem: [PA146.EL114]

Requisitos

Matriz de rastreabilidade de requisitos



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

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

Elaboração:

As mudanças propostas a compromissos a serem feitos de forma externa à organização são revisados com o nível mais alto de gerenciamento, de forma a assegurar que todos os compromissos podem ser cumpridos. [PA146.EL117]

(A seguinte meta não é exigida nem suas práticas esperadas para uma classificação de nível de maturidade 2, mas são exigidas para uma classificação de nível de maturidade 3 e superiores).




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


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]



PLANEJAMENTO DO PROJETO


Objetivo

O objetivo do Planejamento do Projeto (Project Planning) é estabelecer e manter planos que definem as atividades do projeto. [PA163]


A área de processo de Planejamento do Projeto (Project Planning) envolve: [PA163.N101]

Desenvolver o plano do projeto

Interagir com os stakeholders de forma apropriada

Obter compromissos com o plano

Manter o plano

O planejamento começa com os requisitos que definem o produto e o projeto. [PA163.N102]

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

O plano do projeto normalmente precisará ser revisado, conforme o projeto evolui, para tratar mudanças nos requisitos e compromissos, estimativas imprecisas, ações corretivas e mudanças no processo. As práticas específicas que descrevem o planejamento e o replanejamento estão contidas nesta área de processo. [PA163.N104]

O termo “plano do projeto” é utilizado em todas as práticas genéricas e específicas desta área de processo para se referir ao plano geral de controle do projeto. [PA163.N105]

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



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]


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.



Nível de Maturidade: 2, Planejamento do Projeto104


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



Tabela de Relacionamento Prática-Meta

SG 1 Estabelecer Estimativas [PA163.IG101]

SP 1.1 Estimar o Escopo do ProjetoSP 1.2 Estabelecer Estimativas de Atributos de Produtos de Trabalho e

TarefasSP 1.3 Definir o Ciclo de Vida do ProjetoSP 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 CronogramaSP 2.2 Identificar os Riscos do ProjetoSP 2.3 Planejar o Gerenciamento de DadosSP 2.4 Planejar os Recursos do ProjetoSP 2.5 Planejar as Habilidades e Conhecimentos NecessáriosSP 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 ProjetoSP 3.2 Conciliar os Níveis de Trabalho e de RecursosSP 3.3 Obter Compromissos com o Plano


GP 2.1 (CO 1) Estabelecer uma Política OrganizacionalGP 2.2 (AB 1) Planejar o ProcessoGP 2.3 (AB 2) Fornecer RecursosGP 2.4 (AB 3) Atribuir ResponsabilidadesGP 2.5 (AB 4) Treinar PessoasGP 2.6 (DI 1) Gerenciar ConfiguraçõesGP 2.7 (DI 2) Identificar e Envolver os Stakeholders RelevantesGP 2.8 (DI 3) Monitorar e Controlar o ProcessoGP 2.9 (VE 1) Avaliar Objetivamente a AderênciaGP 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).






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]



SP 1.1 Estimar o Escopo do Projeto

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

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


1. Descrições de tarefas [PA163.IG101.SP101.W101]

2. Descrições de pacotes de trabalho [PA163.IG101.SP101.W102]

3. WBS [PA163.IG101.SP101.W103]

Sub-práticas

1. Desenvolver uma WBS baseada na arquitetura do produto. [PA163.IG101.SP101.SubP101]

A WBS fornece um esquema para a organização do trabalho do projeto de acordo com os produtos que o trabalho suporta. A WBS deverá permitir a identificação dos seguintes itens: [PA163.IG101.SP101.SubP101.N101]

Riscos identificados e suas tarefas de mitigação

Tarefas para os itens de entrega e para as atividades de suporte

Tarefas para aquisição de habilidades e conhecimentos

Tarefas para o desenvolvimento dos planos de suporte necessários, como os planos de gerenciamento de configurações, de garantia da qualidade e de verificação.

Tarefas para a integração e gerenciamento de itens que não são de desenvolvimento

2. Identificar os pacotes de trabalho com detalhes suficientes para especificar as estimativas de tarefas, responsabilidades e cronograma do projeto. [PA163.IG101.SP101.SubP102]

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

Exemplos de medidas de tamanho incluem: [PA163.IG101.SP102.N104]

Quantidade de funções

Pontos de função

Linhas de código fonte

Quantidade de classes e objetos

Quantidade de requisitos

Quantidade de interfaces

Quantidade de páginas

Quantidade de entradas e saídas

Quantidade de itens de risco técnico

Volume de dados



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


1. Abordagem técnica [PA163.IG101.SP102.W101]

2. Tamanho e complexidade de tarefas e produtos de trabalho [PA163.IG101.SP102.W102]

3. Modelos de estimativas [PA163.IG101.SP102.W103]

4. Estimativas de atributos [PA163.IG101.SP102.W104]

Sub-práticas

1. Determinar a abordagem técnica para o projeto. [PA163.IG101.SP102.SubP101]

A abordagem técnica define uma estratégia de alto nível para o desenvolvimento dos produtos. Ela inclui decisões de características de arquitetura, como arquitetura distribuída ou cliente-servidor; tecnologias revolucionárias ou estabelecidas a serem aplicadas, como robótica, materiais compostos ou inteligência artificial; e a abrangência esperada das funcionalidades dos produtos finais, como segurança, confiabilidade e questões ergonômicas. [PA163.IG101.SP102.SubP101.N101]

2. Usar métodos apropriados para determinar os atributos de produtos de trabalho e tarefas que serão usados para estimar os requisitos de recursos. [PA163.IG101.SP102.SubP102]

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

Os métodos para se determinar os atributos evoluem conforme aumenta o nosso entendimento do relacionamento das características do produto com seus atributos. [PA163.IG101.SP102.SubP102.N102]

Exemplos de métodos atuais incluem: [PA163.IG101.SP102.SubP102.N103]

Quantidade de portas lógicas para o design de um circuito integrado

Linhas de código ou pontos de função para software

Quantidade/complexidade de requisitos para engenharia de sistemas

Quantidade de metros quadrados para residências padrão especificadas

3. Estimar os atributos dos produtos de trabalho e tarefas. [PA163.IG101.SP102.SubP103]

4. Estimar, conforme apropriado, o trabalho, maquinário, materiais e métodos que serão exigidos pelo projeto. [PA163.IG101.SP102.SubP104]



SP 1.3 Definir o Ciclo de Vida do Projeto

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

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


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


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

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

O entendimento do ciclo de vida do projeto é crucial na determinação do escopo do esforço de planejamento e do momento do planejamento inicial, bem como o momento e os critérios (milestones críticos) para o replanejamento. [PA163.IG101.SP103.N103]


1. Fases do ciclo de vida do projeto [PA163.IG101.SP103.W101]



SP 1.4 Determinar Estimativas de Esforço e Custo

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

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

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


1. Justificativa de estimação [PA163.IG101.SP104.W101]

2. Estimativas de esforço do projeto [PA163.IG101.SP104.W102]

3. Estimativas de custo do projeto [PA163.IG101.SP104.W104]

Sub-práticas

1. Coletar modelos ou dados históricos que serão utilizados para transformar os atributos dos produtos de trabalho e tarefas em estimativas de horas de trabalho e custo. [PA163.IG101.SP104.SubP101]


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



Os dados históricos incluem os dados de custo, esforço e cronograma de projetos executados anteriormente, além de dados apropriados de escala para equilibrar as diferenças de tamanho e complexidade. [PA163.IG101.SP104.SubP101.N101]

2. Incluir necessidades de infra-estrutura de suporte quando estiver estimando o esforço e o custo. [PA163.IG101.SP104.SubP102]

A infra-estrutura de suporte inclui itens necessários a partir da visão do desenvolvimento e sustentação do produto. [PA163.IG101.SP104.SubP102.N101]


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

identificar os recursos computacionais críticos para o projeto de software e

basear estimativas de recursos computacionais críticos nos requisitos alocados


Exemplos de recursos computacionais críticos incluem: [PA163.IG101.SP104.SubP102.N101.AMP102]

Memória, disco e capacidade da rede

Potência do processador

Capacidade dos canais de comunicação

Potência das estações de trabalho

Capacidade de periféricos


Exemplos de recursos de engenharia de software 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

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]



O orçamento e o cronograma do projeto são baseados nas estimativas desenvolvidas e asseguram que a alocação de orçamento, complexidade das tarefas e dependências entre as tarefas estão sendo tratadas apropriadamente. [PA163.IG102.SP101.N101]

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


1. Cronogramas do projeto [PA163.IG102.SP101.W101]

2. Dependências do cronograma [PA163.IG102.SP101.W102]

3. Orçamento do projeto [PA163.IG102.SP101.W103]

Sub-práticas

1. Identificar os principais milestones. [PA163.IG102.SP101.SubP101]

Muitas vezes, são impostos milestones para assegurar que certos itens a serem entregues estarão completos no momento do milestone. Os milestones podem ser baseados em eventos ou no calendário. Se for baseado no calendário, uma vez que as datas dos milestones forem acordadas, freqüentemente, é muito difícil alterá-las. [PA163.IG102.SP101.SubP101.N101]

2. Identificar as premissas do cronograma. [PA163.IG102.SP101.SubP102]

Quando os cronogramas são inicialmente desenvolvidos, é comum fazer algumas premissas sobre a duração de certas atividades. Estas premissas são freqüentemente feitas sobre itens para os quais poucos dados de estimativas estão disponíveis, quando há algum dado disponível. Identificar estas premissas fornece um entendimento do nível de confiança (incertezas) do cronograma geral. [PA163.IG102.SP101.SubP102.N101]

3. Identificar restrições. [PA163.IG102.SP101.SubP103]

Os fatores que limitam a flexibilidade das opções de gerenciamento precisam ser identificados o mais cedo possível. O exame dos atributos dos produtos de trabalho e tarefas, muitas vezes, fazem emergir estas questões. Tais atributos podem incluir a duração das tarefas, recursos, entradas e saídas. [PA163.IG102.SP101.SubP103.N101]

4. Identificar dependências de tarefas. [PA163.IG102.SP101.SubP104]

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]

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


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]

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

SP 2.3 Planejar o Gerenciamento de Dados

Planejar o gerenciamento dos dados do projeto. [PA163.IG102.SP102]



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

Os requisitos de dados do projeto deverão ser estabelecidos pelos itens de dados a serem criados e seu conteúdo e forma, baseados em um conjunto comum ou padrão de requisitos de dados. O conteúdo e formato uniforme dos requisitos de itens de dados facilitam o entendimento do conteúdo dos dados e auxiliam o gerenciamento consistente dos recursos de dados. [PA163.IG102.SP102.N102]

O motivo de coletar cada documento deverá ser bem claro. Esta tarefa inclui a análise e verificação dos itens do projeto a serem entregues e que não serão entregues, requisitos de dados contratuais e não contratuais e dados fornecidos pelos clientes. Muitas vezes, os dados são coletados sem um entendimento claro de como serão utilizados. Os dados têm um alto custo e deverão ser coletados somente quando forem necessários. [PA163.IG102.SP102.N103]


1. Plano de gerenciamento de dados [PA163.IG102.SP102.W101]

2. Lista principal de dados gerenciados [PA163.IG102.SP102.W102]

3. Descrição de conteúdo e formato de dados [PA163.IG102.SP102.W103]

4. Listas de requisitos de dados para aquisidores e fornecedores [PA163.IG102.SP102.W104]

5. Requisitos de privacidade [PA163.IG102.SP102.W105]

6. Requisitos de segurança [PA163.IG102.SP102.W106]

7. Procedimentos de segurança [PA163.IG102.SP102.W107]

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]

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


1. Pacotes de trabalho da WBS [PA163.IG102.SP104.W101]



2. Dicionário de tarefas da WBS [PA163.IG102.SP104.W102]

3. Requisitos de pessoal baseados no tamanho e escopo do projeto [PA163.IG102.SP104.W103]

4. Lista de equipamentos/recursos críticos [PA163.IG102.SP104.W104]

5. Definições e diagramas de processos/fluxo de trabalho [PA163.IG102.SP104.W105]

6. Lista de requisitos de administração do programa [PA163.IG102.SP104.W106]

Sub-práticas

1. Determinar os requisitos do processo. [PA163.IG102.SP104.SubP101]

Os processos utilizados para gerenciar um projeto devem ser identificados, definidos e coordenados com todos os stakeholders relevantes para assegurar uma operação eficiente durante a execução do projeto. [PA163.IG102.SP104.SubP101.N101]

2. Determinar requisitos de pessoal. [PA163.IG102.SP104.SubP102]

O pessoal de um projeto depende da decomposição dos requisitos do projeto em tarefas, papéis e responsabilidades para atender os requisitos do projeto como estes estão dispostos nos pacotes de trabalho da WBS. [PA163.IG102.SP104.SubP102.N101]

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

3. Determinar requisitos de recursos, equipamentos e componentes. [PA163.IG102.SP104.SubP103]

A maioria dos projetos são únicos de alguma maneira e exigem algum conjunto de ativos únicos para atender os objetivos do projeto. A determinação e aquisição destes ativos de uma maneira pontual são cruciais para o sucesso do projeto. [PA163.IG102.SP104.SubP103.N101]

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

SP 2.5 Planejar os Conhecimentos e Habilidades Necessários

Planejar os conhecimentos e habilidades necessários para a execução do projeto. [PA163.IG102.SP105]



Veja a área de processo de Treinamento Organizacional para obter maiores informações sobre informações de conhecimentos e habilidades a serem incorporadas no plano do projeto. [PA163.IG102.SP105.R101]

O conhecimento utilizado nos projetos envolve o treinamento do pessoal do projeto e a aquisição de conhecimento de fontes externas. [PA163.IG102.SP105.N101]

Os requisitos de pessoal são dependentes dos conhecimentos e habilidades disponíveis para suportar a execução do projeto. [PA163.IG102.SP105.N102]


1. Inventário das habilidades necessárias [PA163.IG102.SP105.W101]

2. Planos de pessoal e de novas contratações [PA163.IG102.SP105.W103]

3. Bancos de dados (por exemplo, habilidades e treinamento) [PA163.IG102.SP105.W104]

Sub-práticas

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

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]

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

Exemplos do tipo de material que deverá ser incluído em um plano para interação dos stakeholders incluem: [PA163.IG102.SP106.N103]

Lista de todos os stakeholders relevantes

Justificativas para o envolvimento dos stakeholders

Papéis e responsabilidades dos stakeholders relevantes com relação ao projeto, por fase do ciclo de vida do projeto

Relacionamentos entre stakeholders

Importância relativa do stakeholder para o sucesso do projeto, por fase do ciclo de vida do projeto

Recursos (por exemplo, treinamento, materiais, tempo, finanças) necessários para assegurar a interação dos stakeholders

Cronograma para as fases de interação de stakeholders

A condução desta prática específica se baseia nas informações compartilhadas ou trocadas com a prática específica anterior Planejar os Conhecimentos e Habilidades Necessários. [PA163.IG102.SP106.N104]


1. Plano para o envolvimento dos stakeholders [PA163.IG102.SP106.W101]



SP 2.7 Estabelecer o Plano do Projeto

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


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


Exemplos de planos que têm sido utilizados na comunidade do Departamento de Defesa americano incluem: [PA163.IG102.SP107.AMP103]

Plano Mestre Integrado – um plano orientado a eventos que documenta os atendimentos significativos com critérios de aprovação/falha para elementos de negócios e técnicos do projeto e amarra cada atendimento a um evento chave do programa.

Cronograma Mestre Integrado – um cronograma integrado, com múltiplas camadas e em rede, das tarefas programadas exigidas para completar o esforço de trabalho documentado em um Plano Mestre Integrado relacionado.

Plano de Gerenciamento de Engenharia de Sistemas – um plano que detalha o esforço técnico integrado em todo o projeto.

Cronograma Mestre de Engenharia de Sistemas – um cronograma orientado a eventos que contém uma compilação de atendimentos técnicos chave, cada qual com critérios mensuráveis, exigindo que eventos identificados sejam completados com sucesso.

Cronograma Detalhado de Engenharia de Sistemas – um cronograma detalhado, dependente de prazo, orientado a tarefas, que associa datas e milestones específicos com o Cronograma Mestre de Engenharia de Sistemas.


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

Plano de desenvolvimento de software

Plano de projeto de software

Plano de software



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


1. Plano geral do projeto [PA163.IG102.SP107.W101]

SG 3 Obter Compromissos com o Plano

Compromissos com o plano do projeto são estabelecidos e mantidos. [PA163.IG103]

Para serem eficazes, os planos exigem compromissos daqueles que são responsáveis pela implementação e suporte do plano. [PA163.IG103.N101]

SP 3.1 Revisar Planos que Afetam o Projeto

Revisar todos os planos que afetam o projeto para o entendimento dos compromissos do projeto. [PA163.IG103.SP103]

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


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



SP 3.2 Conciliar os Níveis de Trabalho e Recursos

Conciliar o plano do projeto para refletir os recursos disponíveis e estimados. [PA163.IG103.SP101]

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


1. Métodos e correspondentes parâmetros de estimativa (por exemplo, melhores ferramentas, uso de componentes de prateleira) revisados [PA163.IG103.SP101.W101]

2. Orçamentos renegociados [PA163.IG103.SP101.W102]

3. Cronogramas revisados [PA163.IG103.SP101.W103]

4. Lista de requisitos revisados [PA163.IG103.SP101.W104]

5. Acordos com stakeholders renegociados [PA163.IG103.SP101.W105]

SP 3.3 Obter Compromissos com o Plano

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

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


1. Solicitações de compromissos documentadas [PA163.IG103.SP102.W101]

2. Compromissos documentados [PA163.IG103.SP102.W102]

Sub-práticas

1. Identificar o suporte necessário e negociar compromissos com os stakeholders relevantes. [PA163.IG103.SP102.SubP101]



A WBS pode ser utilizada como checklist para assegurar que foram obtidos compromissos para todas as tarefas. [PA163.IG103.SP102.SubP101.N101]

O plano para a interação dos stakeholders deverá identificar todas as partes de onde deverão ser obtidos compromissos. [PA163.IG103.SP102.SubP101.N102]

2. Documentar todos os compromissos organizacionais, completos e provisionais, assegurando o nível apropriado de signatários. [PA163.IG103.SP102.SubP102]

Os compromissos devem ser documentados para assegurar um entendimento mútuo consistente, assim como a rastreabilidade e manutenção. Os compromissos provisionais deverão ser acompanhados de uma descrição dos riscos associados com o relacionamento. [PA163.IG103.SP102.SubP102.N101]

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

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

O gerenciamento pode ter o necessário entendimento e autoridade para reduzir riscos associados com os compromissos externos. [PA163.IG103.SP102.SubP104.N101]

5. Identificar compromissos nas interfaces entre os elementos do projeto e com outros projetos e unidades organizacionais, de maneira que possam ser monitorados. [PA163.IG103.SP102.SubP105]

Especificações bem definidas de interfaces formam a base para os compromissos. [PA163.IG103.SP102.SubP105.N101]



Compromisso


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



Elaboração:

Esta política estabelece as expectativas organizacionais para a estimativa dos parâmetros de planejamento, obtenção de compromissos internos e externos e desenvolvimento do plano para o gerenciamento do projeto. [PA163.EL101]

Habilitações


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

Elaboração:

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


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

Elaboração:

Especializações específicas, equipamentos e recursos podem ser exigidos para o planejamento do projeto. Especialização específica em planejamento de projetos pode incluir: [PA163.EL104]

Pessoal experiente em estimativas

Pessoal experiente em cronogramas

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



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


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:


Estimativas

Orçamentos

Negociação

Identificação e análise de riscos

Gerenciamento de dados

Planejamento

Cronogramas

Implementações


Colocar os produtos de trabalho definidos do processo de planejamento do projeto 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: [PA163.EL110]

Estrutura de decomposição do trabalho (Work breakdown structure)

Plano do projeto

Plano de gerenciamento de dados

Plano de envolvimento de stakeholders


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


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



Elaboração:


Número de revisões do plano

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

Verificações


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:


Estabelecer estimativas

Desenvolver um plano de projeto

Obter compromissos ao plano do projeto


WBS

Plano do projeto

Plano de gerenciamento de dados

Plano de envolvimento de stakeholders

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




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


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]



MONITORAMENTO E CONTROLE DO PROJETO


Objetivo

O objetivo do Monitoramento e Controle do Projeto (Project Monitoring and Control) é oferecer um entendimento do progresso do projeto, de maneira que as ações corretivas apropriadas possam ser tomadas quando o desempenho do projeto se desviar significativamente do plano. [PA162]


Um plano de projeto documentado é a base para monitorar atividades, comunicar status e tomar as ações corretivas. O progresso é basicamente determinado pela comparação dos atributos reais de produtos de trabalho e tarefas, esforço, custo e cronograma com o que foi planejado nos milestones ou níveis de controle pré-definidos dentro do cronograma do projeto ou da estrutura de decomposição de trabalho (WBS). A visibilidade apropriada possibilita a ação corretiva pontual a ser tomada quando o desempenho desvia significativamente do plano. Um desvio é significativo se, quando deixado sem resolução, impede que o projeto atinja seus objetivos. [PA162.N101]

O termo “plano do projeto” é utilizados em todas estas práticas para se referir ao plano geral para o controle do projeto. [PA162.N102]

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


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]

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



SG 1 Monitorar o Projeto Contra o Plano [PA162.IG101]

O desempenho e o progresso real do projeto são monitorados contra o plano do projeto.

SG 2 Gerenciar as Ações Corretivas até o Encerramento [PA162.IG102]

As ações corretivas são gerenciadas até o seu encerramento, quando o desempenho ou resultados do projeto se desviarem significativamente do plano.



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




SG 1 Monitorar o Projeto Contra o Plano [PA162.IG101]

SP 1.1 Monitorar os Parâmetros de Planejamento do ProjetoSP 1.2 Monitorar os CompromissosSP 1.3 Monitorar os Riscos do ProjetoSP 1.4 Monitorar o Gerenciamento de DadosSP 1.5 Monitorar o Envolvimento dos StakeholdersSP 1.6 Conduzir Revisões de ProgressoSP 1.7 Conduzir Revisões nos Milestones

SG 2 Gerenciar a Ação Corretiva até o Encerramento [PA162.IG102]

SP 2.1 Analisar QuestõesSP 2.2 Tomar Ações CorretivasSP 2.3 Gerenciar as Ações Corretivas


GP 2.1 (CO 1) Estabelecer uma Política OrganizacionalGP 2.2 (AB 1) Planejar o ProcessoGP 2.3 (AB 2) Fornecer RecursosGP 2.4 (AB 3) Atribuir ResponsabilidadesGP 2.5 (AB 4) Treinar as PessoasGP 2.6 (DI 1) Gerenciar ConfiguraçõesGP 2.7 (DI 2) Identificar e Envolver os Stakeholders RelevantesGP 2.8 (DI 3) Monitorar e Controlar o Processo

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


GP 2.9 (VE 1) Avaliar Objetivamente a AderênciaGP 2.10 (VE 2) Revisar Status com o Nível Mais Alto de Gerência





SG 1 Monitorar o Projeto Contra o Plano

O desempenho e o progresso real do projeto são monitorados contra o plano do projeto. [PA162.IG101]

SP 1.1 Monitorar os Parâmetros de Planejamento do Projeto

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

Os parâmetros de planejamento do projeto constituem os indicadores típicos do desempenho e progresso do projeto e incluem os atributos dos produtos de trabalho e tarefas, custo, esforço e cronograma. Atributos dos produtos de trabalho e tarefas incluem itens como tamanho, complexidade, peso, formato, encaixe ou funções. [PA162.IG101.SP101.N101]

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


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

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

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]


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]

SP 1.2 Monitorar Compromissos

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


1. Registros de revisões de compromissos [PA162.IG101.SP102.W101]

Sub-práticas

1. Revisar regularmente os compromissos (externos e internos). [PA162.IG101.SP102.SubP101]

2. Identificar compromissos que não foram cumpridos ou que correm um risco significativo de não serem cumpridos. [PA162.IG101.SP102.SubP102]

3. Documentar os resultados das revisões de compromissos. [PA162.IG101.SP102.SubP103]



SP 1.3 Monitorar os Riscos do Projeto

Monitorar os riscos contra os que foram identificados no plano 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]


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]

Exemplos de status de riscos incluem: [PA162.IG101.SP103.SubP103.N101]

Uma mudança na probabilidade daquele risco ocorrer

Uma mudança na prioridade dos riscos

SP 1.4 Monitorar o Gerenciamento de Dados

Monitorar o gerenciamento dos dados do projeto contra o plano do projeto. [PA162.IG101.SP106]

Veja a prática específica Planejar o Gerenciamento de Dados na área de processo de Planejamento do Projeto para obter maiores informações sobre como identificar os tipos de dados que deverão ser gerenciados e como planejar seu gerenciamento. [PA162.IG101.SP106.R101]

Uma vez que os planos para o gerenciamento dos dados do projeto tenham sido feitos, o gerenciamento daqueles dados deve ser monitorado para assegurar que os planos sejam cumpridos. [PA162.IG101.SP106.N101]


1. Registros de gerenciamento de dados [PA162.IG101.SP106.W101]



Sub-práticas

1. Revisar periodicamente as atividades de gerenciamento de dados contra sua descrição no plano do projeto. [PA162.IG101.SP106.SubP101]

2. Identificar e documentar questões significativas e seus impactos. [PA162.IG101.SP106.SubP102]

3. Documentar os resultados das revisões das atividades de gerenciamento de dados. [PA162.IG101.SP106.SubP103]

SP 1.5 Monitorar o Envolvimento dos Stakeholders

Monitorar o envolvimento dos stakeholders contra o plano do projeto. [PA162.IG101.SP107]

Veja a prática específica Planejar o Envolvimento dos Stakeholders na área de processo de Planejamento do Projeto para obter maiores informações sobre como identificar os stakeholders relevantes e planejar o seu envolvimento apropriado. [PA162.IG101.SP107.R101]

Uma vez que os stakeholders sejam identificados e a extensão do seu envolvimento no projeto esteja especificada no planejamento do projeto, este envolvimento deve ser monitorado para assegurar que as interações apropriadas estão ocorrendo. [PA162.IG101.SP107.N101]


1. Registros do envolvimento dos stakeholders [PA162.IG101.SP107.W101]

Sub-práticas

1. Revisar periodicamente o status do envolvimento dos stakeholders. [PA162.IG101.SP107.SubP101]


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


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]

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]


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]

2. Revisar os compromissos, planos, status e riscos do projeto. [PA162.IG101.SP105.SubP102]


4. Documentar os resultados da revisão, itens de ação e decisões. [PA162.IG101.SP105.SubP104]

5. Rastrear itens de ação até o encerramento. [PA162.IG101.SP105.SubP105]

SG 2 Gerenciar Ações Corretivas até o Encerramento

As ações corretivas são gerenciadas até o encerramento quando o desempenho ou os resultados do projeto desviarem significativamente do plano. [PA162.IG102]

SP 2.1 Analisar questões

Coletar e analisar questões e determinar as ações corretivas necessárias para tratar estas questões. [PA162.IG102.SP101]


1. Lista de questões que precisam de ações corretivas [PA162.IG102.SP101.W101]

Sub-práticas

1. Reunir questões para análise. [PA162.IG102.SP101.SubP101]



Questões são coletadas a partir de revisões e da execução de outros processos. [PA162.IG102.SP101.SubP101.N101]

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]


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]



Exemplos de ações potenciais incluem: [PA162.IG102.SP102.SubP101.N101]

Modificar a declaração de trabalho

Modificar os requisitos

Revisar estimativas e planos

Renegociar compromissos

Adicionar recursos

Mudar processos

Revisar riscos do projeto

2. Revisar e obter acordos com os stakeholders relevantes sobre as ações a serem tomadas. [PA162.IG102.SP102.SubP102]

3. Negociar mudanças nos compromissos internos e externos. [PA162.IG102.SP102.SubP103]

SP 2.3 Gerenciar as Ações Corretivas

Gerenciar as ações corretivas até o encerramento. [PA162.IG102.SP103]


1. Resultados de ações corretivas [PA162.IG102.SP103.W101]

Sub-práticas

1. Monitorar ações corretivas até que sejam completadas. [PA162.IG102.SP103.SubP101]

2. Analisar os resultados de ações corretivas para determinar a eficácia das ações corretivas. [PA162.IG102.SP103.SubP102]

3. Determinar e documentar as ações apropriadas para corrigir os desvios dos resultados planejados para as ações corretivas. [PA162.IG102.SP103.SubP103]

Lições aprendidas como resultado da tomada de ações corretivas podem ser entradas para os processos de planejamento e de gerenciamento de riscos. [PA162.IG102.SP103.SubP103.N101]





Compromisso


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


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]


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]

Elaboração:


Sistemas de rastreamento de custos

Sistemas de relatórios de esforços

Sistemas de rastreamento de itens de ações

Programas de gerenciamento de projeto e cronogramas




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


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

Elaboração:


Monitoramento e controle de projetos

Gerenciamento de riscos

Gerenciamento de dados

Implementações


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]


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


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

Elaboração:


Quantidade de ações corretivas abertas e encerradas

Datas dos milestones do projeto (por exemplo, planejadas versus reais e milestones que não foram cumpridos)

Quantidade e tipos de revisões executadas

Revisar o cronograma (planejado versus real e datas alvo que não foram cumpridas)



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:


Monitorar o desempenho do projeto contra o plano do projeto

Gerenciar as ações corretivas até o encerramento




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




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


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]



GERENCIAMENTO DE ACORDOS COM FORNECEDORES


Objetivo

O objetivo do Gerenciamento de Acordos com Fornecedores (Supplier Agreement Management) é gerenciar a aquisição de produtos de fornecedores para os quais existe um acordo formal. [PA166]


A área de processo de Gerenciamento de Acordos com Fornecedores envolve: [PA166.N104]

Determinar o tipo de aquisição que será utilizada para os produtos a serem adquiridos

Selecionar os fornecedores

Estabelecer e manter acordos com fornecedores

Executar o acordo com o fornecedor

Aceitar a entrega dos produtos adquiridos

Fazer a transição dos produtos adquiridos para o projeto

Esta área de processo basicamente se aplica à aquisição de produtos e componentes de produtos que são entregues ao cliente do projeto. Para minimizar os riscos do projeto, esta área de processo também pode ser aplicada à aquisição de produtos e componentes de produtos significativos que não serão entregues ao cliente do projeto (por exemplo, ferramentas de desenvolvimento e ambientes de testes). [PA166.N105]

Esta área de processo não trata diretamente as situações nas quais o fornecedor está integrado à equipe do projeto (por exemplo, equipes integradas de produtos). Normalmente, estas situações são tratadas por outros processos ou funções, possivelmente externos ao projeto, embora algumas das práticas específicas desta área de processo possam ser úteis no gerenciamento do acordo formal com este tipo de fornecedor. [PA166.N106]

Fornecedores podem tomar diferentes formas, dependendo das necessidades do negócio, incluindo fornecedores in-house (isto é, fornecedores que pertencem à mesma organização, mas são externos ao projeto), fábricas e laboratórios e fornecedores comerciais. [PA166.N103]

Veja a definição de “fornecedor” no Apêndice B, o glossário. [PA166.N107]

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


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]


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]


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.



Nível de Maturidade: 2, Gerenciamento de Acordos com Fornecedores148






SG 1 Estabelecer Acordos com Fornecedores [PA166.IG101]

SP 1.1 Determinar o Tipo de AquisiçãoSP 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 FornecedorSP 2.3 Aceitar o Produto AdquiridoSP 2.4 Fazer a Transição dos Produtos


GP 2.1 (CO 1) Estabelecer uma Política OrganizacionalGP 2.2 (AB 1) Planejar o Processo GP 2.3 (AB 2) Fornecer RecursosGP 2.4 (AB 3) Atribuir ResponsabilidadesGP 2.5 (AB 4) Treinar PessoasGP 2.6 (DI 1) Gerenciar ConfiguraçõesGP 2.7 (DI 2) Identificar e Envolver os Stakeholders RelevantesGP 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).




SG 1 Estabelecer Acordos com Fornecedores

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

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)


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]



Exemplos de fatores incluem: [PA166.IG101.SP102.N103]

Localização geográfica do fornecedor

Registros de desempenho do fornecedor em trabalho semelhante

Habilitações de engenharia

Pessoal e recursos disponíveis para executar o trabalho

Experiência anterior em aplicações semelhantes


1. Lista de fornecedores candidatos [PA166.IG101.SP102.W101]

2. Lista de fornecedores preferenciais [PA166.IG101.SP102.W102]

3. Justificativa para a seleção dos fornecedores [PA166.IG101.SP102.W103]

4. Vantagens e desvantagens dos fornecedores candidatos [PA166.IG101.SP102.W104]

5. Critérios de avaliação [PA166.IG101.SP102.W105]

6. Materiais de solicitação e requisitos [PA166.IG101.SP102.W106]

Sub-práticas

1. Estabelecer e documentar os critérios para a avaliação dos fornecedores potenciais. [PA166.IG101.SP102.SubP101]

2. Identificar os fornecedores potenciais e distribuir os materiais de solicitação e requisitos para eles. [PA166.IG101.SP102.SubP102]

3. Avaliar as propostas de acordo com os critérios de avaliação. [PA166.IG101.SP102.SubP103]

4. Avaliar os riscos associados com cada fornecedor proposto. [PA166.IG101.SP102.SubP104]

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]



Exemplos de métodos para avaliar a capacidade dos fornecedores propostos em executar o trabalho incluem: [PA166.IG101.SP102.SubP105.N101]

Avaliação da experiência anterior em aplicações semelhantes

Avaliação de desempenho anterior em trabalho semelhante

Avaliação das habilidades de gerenciamento

Avaliações de habilidades

Avaliação de pessoal disponível para executar o trabalho

Avaliação de locais e recursos disponíveis

Avaliação da capacidade do projeto em trabalhar com o fornecedor proposto

6. Selecionar o fornecedor. [PA166.IG101.SP102.SubP106]

SP 1.3 Estabelecer Acordos com Fornecedores

Estabelecer e manter acordos formais com o fornecedor. [PA166.IG101.SP103]

Um acordo formal é qualquer acordo legal entre a organização (representando o projeto) e o fornecedor. Este acordo pode ser um contrato, uma licença ou uma minuta de acordo. [PA166.IG101.SP103.N101]


1. Declarações de trabalho [PA166.IG101.SP103.W101]

2. Contratos [PA166.IG101.SP103.W102]

3. Minutas de acordos [PA166.IG101.SP103.W103]

4. Acordos de licenciamento [PA166.IG101.SP103.W104]

Sub-práticas

1. Revisar os requisitos a serem atendidos pelo fornecedor para refletir as negociações feitas com o fornecedor, quando necessário. [PA166.IG101.SP103.SubP101]

Veja a área de processo de Desenvolvimento de Requisitos para obter maiores informações sobre como revisar requisitos. [PA166.IG101.SP103.SubP101.R101]

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

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]


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]

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]

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]




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]

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]

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]


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]

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]


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]



Sub-práticas

1. Assegurar que existem recursos apropriados para receber, armazenar, utilizar e manter os produtos adquiridos. [PA166.IG102.SP104.SubP101]

2. Assegurar que o treinamento apropriado foi fornecido para os envolvidos em receber, armazenar, utilizar e manter os produtos adquiridos. [PA166.IG102.SP104.SubP102]

3. Assegurar que a armazenagem, distribuição e utilização dos produtos adquiridos estão sendo feitas de acordo com os termos e condições especificados no acordo com o fornecedor ou na licença de uso. [PA166.IG102.SP104.SubP103]



Compromisso


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


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



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]


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:


Listas de fornecedores preferenciais

Programas de rastreamento de requisitos

Programas de gerenciamento de projetos e cronogramas


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]


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



Elaboração:


Regulamentos e práticas de negócios relacionadas com a negociação e o trabalho com fornecedores

Planejamento e preparação da aquisição

Aquisição de produtos de prateleira

Avaliação e seleção de fornecedores

Negociação e resolução de conflitos

Gerenciamento de fornecedores

Teste e transição de produtos adquiridos

Recebimento, armazenagem, utilização e manutenção de produtos adquiridos

Implementações


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


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



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


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

Elaboração:


Quantidade de mudanças feitas nos requisitos para o fornecedor

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

Verificações


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]

Elaboração:


Estabelecimento e manutenção de acordos com fornecedores

Satisfação de acordos com fornecedores


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


O processo é institucionalizado com um processo definido.


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


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]



MEDIÇÕES E ANÁLISES


Objetivo

O objetivo das Medições e Análises é desenvolver e sustentar a capacidade de medições que é utilizada para suportar as necessidades de gerenciamento de informações. [PA154]


A área de processo de Medições e Análises envolve o seguinte: [PA154.N101]

Especificar os objetivos de medições e análises, de forma que estes estejam alinhados com as necessidades e objetivos de informações identificados

Especificar as medidas, mecanismos de coleta de dados e armazenamento, técnicas de análises e mecanismos de comunicação e de feedback

Implementar a coleta, armazenagem, análise e relatórios sobre os dados

Fornecer resultados objetivos que possam ser utilizados na tomada de decisões bem informadas e na tomada das ações corretivas apropriadas

A integração das atividades de medições e análises nos processos do projeto suportam o seguinte: [PA154.N102]

Planejamento e estimativas objetivos

Rastreamento do desempenho real contra os planos e objetivos estabelecidos

Identificação e resolução de questões relacionadas a processos

Fornecimento de uma base para a incorporação das medições em outros processos no futuro

A equipe necessária para implementar uma capacidade de medições pode pertencer ou não a um programa separado da organização. A capacidade de medições pode estar integrada em projetos individuais ou outras funções organizacionais (como por exemplo, a Garantia da Qualidade). [PA154.N103]

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


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]


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]


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.

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


SG 2 Fornecer Resultados de Medições [PA154.IG102]

Os resultados de medições que tratam as necessidades e objetivos de informações identificados são fornecidos.







SG 1 Alinhar as Atividades de Medições e Análises [PA154.IG101]

SP 1.1 Estabelecer Objetivos de MediçõesSP 1.2 Especificar MedidasSP 1.3 Especificar Procedimentos de Coleta e Armazenagem de DadosSP 1.4 Especificar Procedimento de Análises

SG 2 Fornecer Resultados de Medições [PA154.IG102]

SP 2.1 Coletar Dados de MediçõesSP 2.2 Analisar Dados de MediçõesSP 2.3 Armazenar Dados e ResultadosSP 2.4 Comunicar Resultados


GP 2.1 (CO 1) Estabelecer uma Política OrganizacionalGP 2.2 (AB 1) Planejar o Processo GP 2.3 (AB 2) Fornecer RecursosGP 2.4 (AB 3) Atribuir ResponsabilidadesGP 2.5 (AB 4) Treinar as PessoasGP 2.6 (DI 1) Gerenciar ConfiguraçõesGP 2.7 (DI 2) Identificar e Envolver os Stakeholders RelevantesGP 2.8 (DI 3) Monitorar e Controlar o ProcessoGP 2.9 (VE 1) Avaliar Objetivamente a AderênciaGP 2.10 (VE 2) Revisar o Status com o Nível Mais Alto de Gerência







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]

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]


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]

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]

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)

As medidas derivadas normalmente são expressas como razões, índices compostos e outras medidas de resumo agregadas. Elas são, normalmente, mais confiáveis quantitativamente e sua interpretação tem mais sentido que as medidas básicas utilizadas para gerá-las. [PA154.IG101.SP102.N105]


1. Especificações de medidas básicas e derivadas [PA154.IG101.SP102.W101]

Sub-práticas

1. Identificar medidas candidatas com base nos objetivos documentados de medições. [PA154.IG101.SP102.SubP101]

Os objetivos de medições são refinados em medidas específicas. As medidas candidatas identificadas são classificadas e especificadas por nome e unidade de medida. [PA154.IG101.SP102.SubP101.N101]

2. Identificar medidas existentes que já atendem aos objetivos de medições. [PA154.IG101.SP102.SubP102]



As especificações para as medidas podem já existir, talvez estabelecidas anteriormente com outros objetivos ou em outra parte da organização. [PA154.IG101.SP102.SubP102.N101]

3. Especificar as definições operacionais para as medidas. [PA154.IG101.SP102.SubP103]

As definições operacionais são declaradas em termos precisos e não ambíguos. Elas tratam de dois importantes critérios, como segue: [PA154.IG101.SP102.SubP103.N101]

Comunicação: O que está sendo medido, como foi medido, quais as unidades de medida e o que foi incluído ou excluído?

Repetibilidade: A medição pode ser repetida, dada a mesma definição, para obter os mesmos resultados?

4. Priorizar, revisar e atualizar medidas. [PA154.IG101.SP102.SubP104]

As especificações propostas das medidas são revisadas para verificar sua adequação com os potenciais usuários finais e outros stakeholders relevantes. As prioridades são definidas ou modificadas e as especificações das medidas são atualizadas, conforme necessário. [PA154.IG101.SP102.SubP104.N101]

SP 1.3 Especificar Procedimentos de Coleta e Armazenagem de Dados

Especificar como os dados de medições serão obtidos e armazenados. [PA154.IG101.SP103]

A especificação explícita de métodos de coleta ajuda a assegurar que os dados corretos estão sendo coletados de forma apropriada. Ela também auxilia a esclarecer ainda mais as necessidades de informações e os objetivos das medições. [PA154.IG101.SP103.N101]

A atenção apropriada aos procedimentos de armazenagem e recuperação ajuda a assegurar que os dados estarão disponíveis e acessíveis para uso futuro. [PA154.IG101.SP103.N102]


1. Procedimentos de coleta e armazenagem de dados [PA154.IG101.SP103.W101]

2. Ferramentas de coleta de dados [PA154.IG101.SP103.W102]

Sub-práticas

1. Identificar as fontes de dados existentes que são geradas a partir dos atuais produtos de trabalho, processos ou transações. [PA154.IG101.SP103.SubP101]

As fontes de dados existentes podem já ter sido identificadas quando as medidas foram especificadas. Mecanismos apropriados de coleta podem existir mesmo que dados relevantes ainda não tenham sido coletados. [PA154.IG101.SP103.SubP101.N101]



2. Identificar medidas para as quais dados são necessários, mas que não estão atualmente disponíveis. [PA154.IG101.SP103.SubP102]

3. Especificar como coletar e armazenar os dados para cada medida necessária. [PA154.IG101.SP103.SubP103]

Especificações explícitas são feitas sobre como, onde e quando os dados serão coletados. Procedimentos para a coleta de dados válidos são especificados. Os dados são armazenados de maneira acessível para a análise e é definido se eles devem ser gravados para uma possível reanálise ou para fins de documentação. [PA154.IG101.SP103.SubP103.N101]

Questões a serem consideradas geralmente incluem: [PA154.IG101.SP103.SubP103.N102]

A freqüência da coleta e os pontos do processo onde as medições serão feitas foram definidos?

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]

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]


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

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]

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.

O trabalho não custa mais para ser executado do que se justifica pelos benefícios que ele proporciona.

Os critérios para avaliar a execução das medições e análises poderia incluir a extensão na qual se aplica o seguinte: [PA154.IG101.SP104.SubP106.N102]

A quantidade de dados faltando ou de inconsistências identificadas está além dos limites especificados.

Há uma seleção tendenciosa na amostragem (por exemplo, somente os usuários finais satisfeitos foram pesquisados para avaliar a satisfação do usuário final ou somente os projetos mal sucedidos foram avaliados para determinar a produtividade geral).

Os dados de medições são repetíveis (isto é, estatisticamente confiáveis).

As premissas estatísticas foram satisfeitas (isto é, sobre a distribuição dos dados ou sobre escalas apropriadas de medições).

SG 2 Fornecer Resultados de Medições

Resultados de medições que tratam as necessidades e objetivos de informações identificados são fornecidos. [PA154.IG102]



O motivo básico para se fazer medições e análises é tratar as necessidades e objetivos de informações identificados. Os resultados das medições baseados em evidências objetivas podem ajudar a monitorar o desempenho, cumprir obrigações contratuais, tomar decisões técnicas e de gerenciamento bem informadas e possibilitar que sejam tomadas ações corretivas. [PA154.IG102.N101]

SP 2.1 Coletar Dados de Medições

Obter os dados de medições especificados. [PA154.IG102.SP101]

Os dados necessários para a análise são obtidos e conferidos quanto a sua completitude e integridade. [PA154.IG102.SP101.N101]


1. Conjuntos de dados de medições básicas e derivadas [PA154.IG102.SP101.W101]

2. Resultados de testes de integridade de dados [PA154.IG102.SP101.W102]

Sub-práticas

1. Obter os dados da medidas básicas. [PA154.IG102.SP101.SubP101]

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]

Os dados de medições são analisados conforme planejado, análises adicionais são conduzidas, conforme necessário, os resultados são revisados com os stakeholders relevantes e revisões necessárias para análises futuras são anotadas. [PA154.IG102.SP102.N101]


1. Resultados de análises e relatórios preliminares [PA154.IG102.SP102.W101]

Sub-práticas

1. Conduzir análises iniciais, interpretar os resultados e escrever conclusões preliminares. [PA154.IG102.SP102.SubP101]

Os resultados das análises de dados raramente são evidentes por si só. Devem ser estabelecidos explicitamente critérios para a interpretação dos resultados e para a definição de conclusões. [PA154.IG102.SP102.SubP101.N101]

2. Conduzir medições e análises adicionais, conforme necessário, e preparar os resultados para a apresentação. [PA154.IG102.SP102.SubP102]

Os resultados das análises planejadas podem sugerir (ou exigir) análises adicionais não previstas. Além disso, podem identificar necessidades de refinar as medidas existentes, calcular medidas derivadas adicionais ou mesmo coletar dados para medidas primitivas adicionais para completar, de forma apropriada, a análise planejada. De maneira semelhante, preparar os resultados iniciais para a apresentação pode identificar a necessidade de análises adicionais não previstas. [PA154.IG102.SP102.SubP102.N101]

3. Revisar os resultados iniciais com os stakeholders relevantes. [PA154.IG102.SP102.SubP103]

Pode ser apropriado rever as interpretações iniciais dos resultados e a maneira como elas serão apresentadas, antes de disseminá-las e comunicá-las de forma mais abrangente. [PA154.IG102.SP102.SubP103.N101]



Revisar os resultados iniciais antes de sua liberação pode evitar mal entendidos desnecessários e levar a melhorias na análise e apresentação dos dados. [PA154.IG102.SP102.SubP103.N102]

Os stakeholders relevantes com os quais as revisões podem ser feitas incluem os usuários finais pretendidos e os patrocinadores, bem como os analistas e fornecedores de dados. [PA154.IG102.SP102.SubP103.N103]

4. Refinar os critérios para análises futuras. [PA154.IG102.SP102.SubP104]

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]

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]


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]

Os resultados do processo de medições e análises são comunicados aos stakeholders relevantes, de uma maneira pontual e fácil de se utilizar, para suportar a tomada de decisões e auxiliar na tomada das ações corretivas. [PA154.IG102.SP104.N101]

Os stakeholders relevantes incluem os usuários pretendidos, patrocinadores e analistas e fornecedores de dados. [PA154.IG102.SP104.N102]


1. Relatórios entregues e resultados de análises relacionados [PA154.IG102.SP104.W101]

2. Informações de contexto ou direcionamento para auxiliar na interpretação dos resultados das análises [PA154.IG102.SP104.W102]

Sub-práticas

1. Manter os stakeholders relevantes pontualmente informados dos resultados das medições. [PA154.IG102.SP104.SubP101]

Os resultados das medições são comunicados a tempo de serem utilizados para seus propósitos pretendidos. Os relatórios possivelmente não serão utilizados se forem distribuídos com pouco esforço em seguir aqueles que precisam saber dos resultados. [PA154.IG102.SP104.SubP101.N101]

Na extensão que for possível e como parte da maneira normal como trabalham, os usuários dos resultados de medições são mantidos pessoalmente envolvidos na definição de objetivos e decisão sobre os planos de ação para medições e análises. Os usuários são mantidos regularmente informados do progresso e dos resultados intermediários. [PA154.IG102.SP104.SubP101.N102]

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]

Os dados, muitas vezes, não são evidentes para quem não é um expert em medições. As escolhas das medições deverão ser explicitamente claras sobre o seguinte: [PA154.IG102.SP104.SubP102.N102]



Como e por que as medidas básicas e derivadas foram especificadas

Como os dados foram obtidos

Como interpretar os resultados com base nos métodos de análises de dados que foram utilizados

Como os resultados tratam as suas necessidades de informações

Exemplos de ações para auxiliar o entendimento dos resultados incluem: [PA154.IG102.SP104.SubP102.N103]

Discutir os resultados com os stakeholders relevantes

Fornecer um memorando que contenha uma fundamentação e uma explicação para os resultados

Fornecer informações detalhadas sobre os resultados antecipadamente para os usuários

Fornecer treinamento para o uso e entendimento apropriados dos resultados de medições



Compromisso


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]

Habilitações


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]


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]


Pacotes estatísticos

Pacotes que apóiam a coleta de dados entre redes


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]


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

Elaboração:


Técnicas estatísticas

Processos de coleta de dados, análise e criação de relatórios

Desenvolvimento de medições relacionadas a metas (por exemplo, Métrica de Questionamento de Metas - Goal Question Metric)



Implementações


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:


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


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

Elaboração:


Estabelecimento de objetivos e procedimentos de medições

Análise de dados de medições

Fornecimento de feedback significativo para os responsáveis pelo fornecimento de dados iniciais dos quais dependem a análise e os resultados


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



Elaboração:


Percentual de projetos utilizando medidas de progresso e desempenho

Percentual de objetivos de medições tratados

Verificações


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

Elaboração:


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

Fornecimento de resultados de medições


Especificações de medidas básicas e derivadas

Procedimentos de coleta e armazenagem de dados

Resultados das análises e relatórios preliminares


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]







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


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]



GARANTIA DA QUALIDADE DO PROCESSO E DO PRODUTO


Objetivo

O objetivo da Garantia da Qualidade do Processo e do Produto (Process and Product Quality Assurance) é fornecer à equipe e à gerência um entendimento objetivo dos processos e seus produtos de trabalho associados. [PA145]


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 Produto186


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]

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


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]


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]


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.







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


GP 2.1 (CO 1) Estabelecer uma Política OrganizacionalGP 2.2 (AB 1) Planejar o Processo GP 2.3 (AB 2) Fornecer RecursosGP 2.4 (AB 3) Atribuir ResponsabilidadesGP 2.5 (AB 4) Treinar as PessoasGP 2.6 (DI 1) Gerenciar ConfiguraçõesGP 2.7 (DI 2) Identificar e Envolver os Stakeholders RelevantesGP 2.8 (DI 3) Monitorar e Controlar o Processo GP 2.9 (VE 1) Avaliar Objetivamente a AderênciaGP 2.10 (VE 2) Revisar o Status com o Nível Mais Alto de Gerência





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]

A objetividade nas avaliações de garantia da qualidade é crítica para o sucesso do projeto. Deverá ser definida uma descrição da cadeia de relatórios de garantia da qualidade e de como ela assegura a objetividade. [PA145.IG101.SP101.N101]


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

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




Sub-práticas

1. Promover um ambiente (criado como parte do gerenciamento do projeto) que encoraje a participação dos empregados na identificação e comunicação de questões de qualidade. [PA145.IG101.SP101.SubP101]

2. Estabelecer e manter critérios claramente declarados para as avaliações. [PA145.IG101.SP101.SubP102]

O propósito desta sub-prática é fornecer critérios, baseados nas necessidades do negócio, como os seguintes: [PA145.IG101.SP101.SubP102.N101]

O que será avaliado

Quando ou com que freqüência um processo será avaliado

Como a avaliação será conduzida

Quem deve estar envolvido na avaliação

3. Utilizar os critérios declarados para avaliar os processos executados com relação à aderência às descrições de processo, padrões e procedimentos. [PA145.IG101.SP101.SubP103]

4. Identificar todas as não conformidades encontradas durante a avaliação. [PA145.IG101.SP101.SubP104]

5. Identificar as lições aprendidas que poderão melhorar processos para futuros produtos e serviços. [PA145.IG101.SP101.SubP105]

SP 1.2 Avaliar Objetivamente Produtos de Trabalho e Serviços

Avaliar objetivamente os produtos de trabalho e serviços definidos contra as descrições de processo, padrões e procedimentos aplicáveis. [PA145.IG101.SP102]



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


Sub-práticas

1. Selecionar produtos de trabalho a serem avaliados, com base nos critérios de amostragem documentados, se esta estiver sendo utilizada. [PA145.IG101.SP102.SubP101]

2. Estabelecer e manter critérios claramente declarados para a avaliação de produtos de trabalho. [PA145.IG101.SP102.SubP102]

O propósito desta sub-prática é fornecer critérios, com base nas necessidades de negócios, como os que seguem: [PA145.IG101.SP102.SubP102.N101]



O que será avaliado durante a avaliação de um produto de trabalho

Quando ou com que freqüência um produto de trabalho será avaliado

Como a avaliação será conduzida

Quem deve ser envolvido na avaliação

3. Utilizar os critérios declarados durante as avaliações de produtos de trabalho. [PA145.IG101.SP102.SubP103]

4. Avaliar os produtos de trabalho antes que sejam entregues ao cliente. [PA145.IG101.SP102.SubP104]

5. Avaliar os produtos de trabalho em milestones selecionados durante o seu desenvolvimento. [PA145.IG101.SP102.SubP105]

6. Executar avaliações durante o progresso ou incrementais de produtos de trabalho e serviços contra as descrições de processo, padrões e procedimentos. [PA145.IG101.SP102.SubP106]

7. Identificar todos os casos de não conformidades encontrados durante as avaliações. [PA145.IG101.SP102.SubP107]

8. Identificar lições aprendidas que poderiam melhorar os processos para futuros produtos e serviços. [PA145.IG101.SP102.SubP108]

SG 2 Fornecer um Entendimento Objetivo

As questões de não conformidades são objetivamente rastreadas e comunicadas e a resolução é assegurada. [PA145.IG102]

SP 2.1 Comunicar e Assegurar a Resolução de Questões de Não Conformidades

Comunicar questões de qualidade e assegurar a resolução de questões de não conformidades com a equipe e os gerentes. [PA145.IG102.SP101]

Questões de não conformidades são problemas identificados nas avaliações que refletem a falta de aderência a padrões, descrições de processos ou procedimentos aplicáveis. O status das questões de não conformidades fornece uma indicação das tendências de qualidade. As questões de qualidade incluem as questões de não conformidades e os resultados de análises de tendências. [PA145.IG102.SP101.N101]

Quando a resolução local das questões de não conformidades não pode ser conseguida, utilizar os mecanismos estabelecidos de elevação do problema, para assegurar que o nível apropriado de gerenciamento possa resolver a questão. Rastrear as questões de não conformidades até a sua resolução. [PA145.IG102.SP101.N102]




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


3. Tendências de qualidade [PA145.IG102.SP101.W103]

Sub-práticas

1. Resolver todas as não conformidades com os membros apropriados da equipe, quando for possível. [PA145.IG102.SP101.SubP101]

2. Documentar as questões de não conformidades que não podem ser resolvidas dentro do projeto. [PA145.IG102.SP101.SubP102]

Exemplos de maneiras de resolver não conformidades dentro do projeto incluem: [PA145.IG102.SP101.SubP102.N101]

Consertar a não conformidade

Modificar as descrições de processos, padrões ou procedimentos que foram violados

Obter uma dispensa para cobrir a questão de não conformidade

3. Elevar as questões de não conformidades que não podem ser resolvidas dentro do projeto, para o nível apropriado de gerenciamento designado para receber e atuar sobre as questões de não conformidades. [PA145.IG102.SP101.SubP103]

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]


Estabelecer e manter registros das atividades de garantia da qualidade. [PA145.IG102.SP102]


1. Logs de avaliações [PA145.IG102.SP102.W101]



2. Relatórios de garantia da qualidade [PA145.IG102.SP102.W102]

3. Relatórios de status de ações corretivas [PA145.IG102.SP102.W103]

4. Relatórios de tendências de qualidade [PA145.IG102.SP102.W104]

Sub-práticas

1. Registrar as atividades de garantia da qualidade do processo e do produto com detalhes suficientes para que o status e os resultados sejam conhecidos. [PA145.IG102.SP102.SubP101]

2. Revisar o status e o histórico das atividades de garantia da qualidade, conforme necessário. [PA145.IG102.SP102.SubP102]

GG 2 Institucionalizar um Processo Gerenciado 103.GL101]


Compromissos


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


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]


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]

Elaboração:


Ferramentas de avaliação

Ferramentas de rastreamento de não conformidades


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]




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:



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

Implementaçõ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:


Relatórios de não conformidades

Logs e relatórios de avaliações


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


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]

Elaboração:


Variação de avaliações objetivas de processos planejadas e executadas

Variação de avaliações objetivas de produtos de trabalho planejadas e executadas

Verificações


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

Elaboração:


Avaliar objetivamente processos e produtos de trabalho

Rastrear e comunicar questões de não conformidades




Relatórios de não conformidades

Logs e relatórios de avaliações


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]





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


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]



GERENCIAMENTO DE CONFIGURAÇÕES


Objetivo

O objetivo do Gerenciamento de Configurações (Configuration Management) é estabelecer e manter a integridade dos produtos de trabalho, utilizando a identificação da configuração, controle da configuração, comunicação do status da configuração e auditorias de configurações. [PA159]


A área de processo de Gerenciamento de Configurações envolve: [PA159.N101]

Identificar a configuração de produtos de trabalho selecionados que compõem as baselines em determinados momentos no tempo

Controlar as mudanças nos itens de configuração

Construir ou fornecer especificações para construir produtos de trabalho a partir do sistema de gerenciamento de configurações

Manter a integridade das baselines

Fornecer um status preciso e os dados atuais de configurações para desenvolvedores, usuários finais e clientes

Os produtos de trabalho colocados sob gerenciamento de configurações incluem os produtos que são entregues ao cliente, produtos de trabalho internos definidos, produtos adquiridos, ferramentas e outros itens que são utilizados na criação e descrição destes produtos de trabalho. Veja a definição de “gerenciamento de configurações” no Apêndice B, o glossário. [PA159.N102]

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


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]

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]

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


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]


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]


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.









SG 1 Estabelecer Baselines [PA159.IG101]

SP 1.1 Identificar Itens de ConfiguraçõesSP 1.2 Estabelecer um Sistema de Gerenciamento de ConfiguraçõesSP 1.3 Criar ou Liberar Baselines

SG 2 Rastrear e Controlar Mudanças [PA159.IG102]

SP 2.1 Rastrear Solicitações de MudançasSP 2.2 Controlar Itens de Configurações

SG 3 Estabelecer a Integridade [PA159.IG103]

SP 3.1 Estabelecer os Registros de Gerenciamento de ConfiguraçõesSP 3.2 Executar Auditorias de Configurações


GP 2.1 (CO 1) Estabelecer uma Política OrganizacionalGP 2.2 (AB 1) Planejar o Processo GP 2.3 (AB 2) Fornecer RecursosGP 2.4 (AB 3) Atribuir ResponsabilidadesGP 2.5 (AB 4) Treinar as PessoasGP 2.6 (DI 1) Gerenciar ConfiguraçõesGP 2.7 (DI 2) Identificar e Envolver os Stakeholders RelevantesGP 2.8 (DI 3) Monitorar e Controlar o Processo GP 2.9 (VE 1) Avaliar Objetivamente a AderênciaGP 2.10 (VE 2) Revisar o Status com o Nível Mais Alto de Gerência





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]


Em um sistema que inclui hardware e software, onde o software representa uma pequena parte do sistema, todo o software pode ser definido como sendo um único item de configuração. Em outros casos, o software pode ser decomposto em diversos itens de configurações. [PA159.IG101.SP101.N102.AMP101]



Os itens de configurações podem ser decompostos em componentes de configurações e unidades de configurações. Somente o termo “item de configuração” é utilizado nesta área de processo. Nestas práticas, “item de configuração” pode ser interpretado como um “componente de configuração” ou uma “unidade de configuração”, conforme for apropriado. Por exemplo, itens de configurações na área de gerenciamento de requisitos poderiam variar de um requisito individual a um conjunto de requisitos. [PA159.IG101.SP101.N103]


1. Itens de configurações identificados [PA159.IG101.SP101.W101]

Sub-práticas

1. Selecionar os itens de configurações e os produtos de trabalho que os compõem com base nos critérios documentados. [PA159.IG101.SP101.SubP101]

Exemplos de critérios para selecionar os itens de configurações no nível apropriado de produtos de trabalho incluem: [PA159.IG101.SP101.SubP101.N102]

Produtos de trabalho que podem ser utilizados por dois ou mais grupos

Produtos de trabalho que se espera que sofram mudanças ao longo do tempo, seja por causa de erros ou mudanças nos requisitos

Produtos de trabalho que são dependentes de outros em que uma mudança em um obrigará uma mudança nos outros

Produtos de trabalho que são críticos para o projeto

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

Descrições de processos

Requisitos

Design

Planos e procedimentos de testes

Resultados de testes

Descrições de interfaces


Exemplos de produtos de trabalho de software que podem ser parte de um item de configuração 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

5. Identificar o proprietário responsável por cada item de configuração. [PA159.IG101.SP101.SubP105]

SP 1.2 Estabelecer um Sistema de Gerenciamento de Configurações

Estabelecer e manter um sistema de gerenciamento de configurações e gerenciamento de mudanças para controlar os produtos de trabalho. [PA159.IG101.SP102]

Um sistema de gerenciamento de configurações inclui o meio de armazenagem, os procedimentos e as ferramentas para acesso ao sistema de configurações. [PA159.IG101.SP102.N101]

Um sistema de gerenciamento de mudanças inclui o meio de armazenagem, os procedimentos e as ferramentas para o registro e acesso às solicitações de mudanças. [PA159.IG101.SP102.N102]


1. Sistema de gerenciamento de configurações com os produtos de trabalho controlados [PA159.IG101.SP102.W101]

2. Procedimentos de controle de acesso ao sistema de gerenciamento de configurações [PA159.IG101.SP102.W102]

3. Banco de dados de solicitações de mudanças [PA159.IG101.SP102.W103]

Sub-práticas

1. Estabelecer um mecanismo para gerenciar diversos níveis de controle de gerenciamento de configurações. [PA159.IG101.SP102.SubP101]



Exemplos de situações que levam a múltiplos níveis de controle incluem: [PA159.IG101.SP102.SubP101.N101]

Diferenças nos níveis de controle necessários em diferentes momentos no ciclo de vida do projeto (por exemplo, um controle mais forte conforme o produto amadurece)

Diferenças nos níveis de controle necessários para diferentes tipos de sistemas (por exemplo, sistemas somente de software versus sistemas que incluem hardware e software)

Diferenças nos níveis de controle necessários para satisfazer os requisitos de privacidade e segurança para os itens de configurações

2. Armazenar e recuperar itens de configurações no sistema de gerenciamento de configurações. [PA159.IG101.SP102.SubP102]

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]

SP 1.3 Criar ou Liberar Baselines

Criar ou liberar baselines para uso interno e para entrega ao cliente. [PA159.IG101.SP103]

Uma baseline é um conjunto de especificações ou produtos de trabalho que foram formalmente revisados e sobre os quais foi feito um acordo, que serve como base para desenvolvimento posterior e que pode ser modificado somente através dos procedimentos de controle de mudanças. Uma baseline representa a atribuição de um identificador a um item de configuração e suas entidades associadas. [PA159.IG101.SP103.N101]


Liberar uma baseline envolver aprovar um conjunto de dados de configurações para o conjunto acordado de itens de configurações, a partir do sistema de gerenciamento de configurações e liberar a baseline para posterior desenvolvimento. Múltiplas baselines podem ser utilizadas para definir um produto que está evoluindo no seu ciclo de desenvolvimento. Um conjunto comum inclui os requisitos no nível do sistema, requisitos de design no nível de elementos do sistema e a definição do produto no final do desenvolvimento/início da produção. Estes são referenciados como a “baseline funcional”, “baseline alocada” e “baseline do produto”. [PA159.IG101.SP103.N101.AMP101]


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


1. Baselines [PA159.IG101.SP103.W101]

2. Descrições de baselines [PA159.IG101.SP103.W102]



Sub-práticas

1. Obter autorização do comitê de controle de configurações (configuration control board - CCB) antes de criar ou liberar baselines de itens de configurações. [PA159.IG101.SP103.SubP101]

2. Criar ou liberar baselines somente a partir de itens de configurações do sistema de gerenciamento de configurações. [PA159.IG101.SP103.SubP102]


Assegurar que os itens de configurações são construídos no desenho correto. [PA159.IG101.SP103.SubP102.AMP101]

3. Documentar o conjunto de itens de configurações que estão contidos em uma baseline. [PA159.IG101.SP103.SubP103]

4. Tornar o conjunto atual de baselines prontamente disponível. [PA159.IG101.SP103.SubP104]

SG 2 Rastrear e Controlar Mudanças

As mudanças nos produtos de trabalho sob gerenciamento de configurações são rastreadas e controladas. [PA159.IG102]

As práticas específicas sob esta meta específica servem para manter as baselines, depois que estas foram estabelecidas pelas práticas específicas sob a meta específica Estabelecer Baselines. [PA159.IG102.N101]

SP 2.1 Rastrear Solicitações de Mudanças

Rastrear as solicitações de mudanças para os itens de configurações. [PA159.IG102.SP101]

As solicitações de mudanças tratam não somente dos requisitos novos ou modificados, mas também de falhas e defeitos nos produtos de trabalho. [PA159.IG102.SP101.N101]

As solicitações de mudanças são analisadas para determinar o impacto que a mudança terá no produto de trabalho, produtos de trabalho relacionados e cronograma e orçamento. [PA159.IG102.SP101.N102]


1. Solicitações de mudanças [PA159.IG102.SP101.W101]

Sub-práticas

1. Iniciar e registrar as solicitações de mudanças no banco de dados de solicitações de mudanças. [PA159.IG102.SP101.SubP101]



2. Analisar o impacto das mudanças e correções propostas nas solicitações de mudanças. [PA159.IG102.SP101.SubP102]

As mudanças são avaliadas através de atividades que asseguram que elas estejam consistentes com todos os requisitos técnicos e do projeto. [PA159.IG102.SP101.SubP102.N101]

As mudanças são avaliadas com relação ao seu impacto além dos requisitos do projeto ou contrato imediatos. Mudanças em um item utilizado em múltiplos produtos podem resolver uma questão imediata e, ao mesmo tempo, causar um problema em outras aplicações. [PA159.IG102.SP101.SubP102.N102]

3. Revisar as solicitações de mudanças que serão tratadas na próxima baseline com os que serão afetados pelas mudanças e obter a sua concordância. [PA159.IG102.SP101.SubP103]

Conduzir a revisão da solicitação de mudança com os participantes apropriados. Registrar a disposição de cada solicitação de mudança e a justificativa para a decisão, incluindo os critérios de sucesso, um breve plano de ação se for apropriado e as necessidades atendidas ou não atendidas pela mudança. Executar as ações exigidas na disposição e relatar os resultados para os stakeholders relevantes. [PA159.IG102.SP101.SubP103.N101]

4. Rastrear os status das solicitações de mudanças até o encerramento. [PA159.IG102.SP101.SubP104]

As solicitações de mudanças trazidas para o sistema precisam ser tratadas de maneira profissional e oportuna. Uma vez que uma solicitação de mudança tenha sido processada, é crítico fechar a solicitação com a ação apropriada aprovada, o mais rápido possível. As ações deixadas em aberto resultam em listas de status maiores que o necessário, que por sua vez resultam em custos e confusão adicionais. [PA159.IG102.SP101.SubP104.N101]

SP 2.2 Controlar Itens de Configurações

Controlar mudanças nos itens de configurações. [PA159.IG102.SP102]

O controle é mantido sobre a configuração da baseline de produtos de trabalho. Este controle inclui rastrear a configuração de cada item de configuração, aprovar uma nova configuração se necessário e atualizar a baseline. [PA159.IG102.SP102.N101]


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

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



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]

SG 3 Estabelecer a Integridade

A integridade das baselines é estabelecida e mantida. [PA159.IG103]



A integridade das baselines, estabelecida pelos processos associados com a meta específica Estabelecer Baselines e mantida pelos processos associados com a meta específica Rastrear e Controlar Mudanças, é garantida pelas práticas específicas sob esta meta específica. [PA159.IG103.N101]

SP 3.1 Estabelecer Registros de Gerenciamento de Configurações

Estabelecer e manter registros descrevendo os itens de configurações. [PA159.IG103.SP101]


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

2. Log de mudanças [PA159.IG103.SP101.W102]

3. Cópia das solicitações de mudanças [PA159.IG103.SP101.W103]

4. Status de itens de configurações [PA159.IG103.SP101.W104]

5. Diferenças entre baselines [PA159.IG103.SP101.W105]

Sub-práticas

1. Registrar ações de gerenciamento de configurações com detalhes suficientes, de forma que o conteúdo e status de cada item de configuração é conhecido e versões anteriores podem ser recuperadas. [PA159.IG103.SP101.SubP101]

2. Assegurar que os stakeholders relevantes têm acesso e conhecimento do status da configuração dos itens de 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]

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]


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]





Compromisso


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


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]


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]

Elaboração:


Ferramentas de gerenciamento de configurações

Ferramentas de gerenciamento de dados

Ferramentas de arquivamento e reprodução

Programas de bancos de dados




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]


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

Elaboração:


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


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

Elaboração:


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




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

Elaboração:


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


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:


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

Quantidade de auditorias de configurações conduzidas

Verificações


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:


Estabelecer baselines

Rastrear e controlar mudanças

Estabelecer e manter a integridade das baselines


Arquivos das baselines

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


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]





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


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 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 217


DESENVOLVIMENTO DE REQUISITOS


Objetivo

O objetivo do Desenvolvimento de Requisitos (Requirements Development) é produzir e analisar requisitos de clientes, produtos e componentes de produtos. [PA157]


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]

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


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]



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]


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]



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]


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.




SG 1 Desenvolver Requisitos do Cliente [PA157.IG101]

SP 1.1 Elicitar NecessidadesSP 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 OperacionaisSP 3.2 Estabelecer uma Definição da Funcionalidade NecessáriaSP 3.3 Analisar Requisitos SP 3.4 Analisar Requisitos para Alcançar o EquilíbrioSP 3.5 Validar Requisitos com Métodos Abrangentes


GP 2.1 (CO 1) Estabelecer uma Política OrganizacionalGP 3.1 (AB 1) Estabelecer um Processo DefinidoGP 2.2 (AB 2) Planejar o ProcessoGP 2.3 (AB 3) Fornecer RecursosGP 2.4 (AB 4) Atribuir ResponsabilidadesGP 2.5 (AB 5) Treinar as PessoasGP 2.6 (DI 1) Gerenciar ConfiguraçõesGP 2.7 (DI 2) Identificar e Envolver os Stakeholders RelevantesGP 2.8 (DI 3) Monitorar e Controlar o ProcessoGP 3.2 (DI 4) Coletar Informações de MelhoriasGP 2.9 (VE 1) Avaliar Objetivamente a AderênciaGP 2.10 (VE 2) Revisar o Status com o Nível Mais Alto de Gerência


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]



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]



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]

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]


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]

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]

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]


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]


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]

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]


1. Planilhas de alocação de requisitos [PA157.IG103.SP102.W101]

2. Alocações provisionais de requisitos [PA157.IG103.SP102.W102]

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]


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]

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]

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]

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]


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]

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]


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]

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]


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]

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]


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]

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]


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]


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]



Compromisso


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]


Estabelecer e manter o plano para a execução do processo de desenvolvimento de requisitos. [GP104]

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]


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]


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





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]


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

Elaboração:



Definição e análise de requisitos

Elicitação de requisitos

Especificação e modelagem de requisitos

Rastreamento de requisitos

Implementaçõ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:


Requisitos de clientes

Arquitetura funcional


Requisitos de interfaces




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]


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


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:


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


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]

Elaboração:


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


Requisitos de produtos

Requisitos de componentes de produtos


Arquitetura funcional


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]



SOLUÇÕES TÉCNICAS


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]


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]

Nível de Maturidade: 3, Soluções Técnicas 241


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]


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]




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.




SG 1 Selecionar Soluções de Componentes de Produtos [PA160.IG101]

SP 1.1 Desenvolver Soluções Alternativas Detalhadas e Critérios de SeleçãoSP 1.2 Evoluir Conceitos Operacionais e CenáriosSP 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écnicosSP 2.3 Criar o Design das Interfaces Utilizando os CritériosSP 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 DesignSP 3.2 Desenvolver a Documentação de Suporte do Produto


GP 2.1 (CO 1) Estabelecer uma Política OrganizacionalGP 3.1 (AB 1) Estabelecer um Processo DefinidoGP 2.2 (AB 2) Planejar o ProcessoGP 2.3 (AB 3) Fornecer RecursosGP 2.4 (AB 4) Atribuir ResponsabilidadesGP 2.5 (AB 5) Treinar as PessoasGP 2.6 (DI 1) Gerenciar ConfiguraçõesGP 2.7 (DI 2) Identificar e Envolver os Stakeholders RelevantesGP 2.8 (DI 3) Monitorar e Controlar o ProcessoGP 3.2 (DI 4) Coletar Informações de MelhoriasGP 2.9 (VE 1) Avaliar Objetivamente a Aderência





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]

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]

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


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]


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]

4. Critérios de seleção para a seleção final [PA160.IG101.SP102.W102]

Sub-práticas

1. Identificar critérios de avaliação para selecionar um conjunto de soluções alternativas para serem consideradas. [PA160.IG101.SP102.SubP101]

2. Identificar tecnologias atualmente em uso e novas tecnologias de produto para uma vantagem competitiva. [PA160.IG101.SP102.SubP102]

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.IG101.SP102.SubP102.R101]



O projeto deverá identificar as tecnologias aplicadas aos atuais produtos e processos e monitorar o progresso das tecnologias atualmente utilizadas, ao longo da vida do projeto. O projeto deverá identificar, selecionar, avaliar e investir em novas tecnologias para conseguir vantagens competitivas. As soluções alternativas poderiam incluir tecnologias recém-desenvolvidas, mas também poderiam incluir a aplicação de tecnologias maduras em aplicações diferentes ou manter os métodos atuais. [PA160.IG101.SP102.SubP102.N101]

3. Gerar soluções alternativas. [PA160.IG101.SP102.SubP103]

4. Obter uma completa alocação de requisitos para cada alternativa. [PA160.IG101.SP102.SubP104]

5. Desenvolver os critérios para seleção da melhor solução alternativa. [PA160.IG101.SP102.SubP105]

Critérios deverão ser incluídos para tratar questões de design para a vida do produto, como provisões para inserir mais facilmente novas tecnologias ou a capacidade de melhor explorar produtos comerciais. Exemplos incluem critérios relacionados a conceitos de design e arquitetura abertos para as alternativas que estão sendo avaliadas. [PA160.IG101.SP102.SubP105.N101]

6. Desenvolver cenários ao longo do tempo para a operação do produto e interação do usuário para cada solução alternativa. [PA160.IG101.SP102.SubP106]

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, Desenvolver Soluções Alternativas Detalhadas e Critérios de Seleção. A prática específica é apresentada aqui em cinza somente como material informativo.

SP 1.1-1 Desenvolver Soluções Alternativas e Critérios de Seleção

Desenvolver soluções alternativas e critérios de seleção. [PA160.IG101.SP101]

Veja a prática específica Alocar Requisitos de Componentes de Produtos na área de processo de Desenvolvimento de Requisitos para obter maiores informações sobre a obtenção de alocações provisionais de requisitos para soluções alternativas de componentes de produtos. [PA160.IG101.SP101.R101]

Veja a área de processo de Análises de Decisões e Resoluções para obter maiores informações sobre como estabelecer critérios de seleção e identificar alternativas. [PA160.IG101.SP101.R102]

Veja a área de processo de Gerenciamento de Requisitos para obter maiores informações sobre como gerenciar os requisitos alocados de forma provisional e os requisitos estabelecidos. [PA160.IG101.SP101.R103]



As alternativas são baseadas nas arquiteturas potenciais de produtos e estendem as soluções possíveis de design. A prática específica Criar o Design do Produto ou Componente do Produto da meta específica Desenvolver o Design, contém maiores informações sobre o desenvolvimento de arquiteturas potenciais de produtos para serem incorporadas às soluções alternativas para o produto. [PA160.IG101.SP101.N101]

Conforme são feitas seleções, o espaço de design pode ser restringido e outras alternativas examinadas até que as soluções mais promissoras (isto é, ótimas) que atendem os requisitos e critérios sejam identificadas. Os critérios de seleção identificam os fatores chave que fornecem a base para a seleção da solução. Estes critérios deverão fornecer uma distinção clara e uma indicação do sucesso em se chegar a uma solução balanceada durante a vida do produto. Eles normalmente incluem medidas de custo, cronograma, desempenho e risco. [PA160.IG101.SP101.N102]

As soluções alternativas avaliadas, freqüentemente, englobam alocações alternativas de requisitos a diferentes componentes de produtos. Estas alternativas também podem ser estruturadas para avaliar o uso de soluções de prateleira na arquitetura do produto. Os processos associados com a área de processo de Desenvolvimento de Requisitos seriam, então, empregados para fornecer uma alocação provisional de requisitos mais completa e robusta para as soluções alternativas. [PA160.IG101.SP101.N103]

A seleção da melhor solução estabelece os requisitos provisionalmente alocados àquela solução como o conjunto de requisitos alocados. As circunstâncias nas quais não seria útil examinar soluções alternativas não são comuns em novos desenvolvimentos. Entretanto, desenvolvimentos de componentes de produtos com precedentes são candidatos para não se examinar, ou examinar o mínimo possível, as soluções alternativas. [PA160.IG101.SP101.N104]


1. Soluções alternativas [PA160.IG101.SP101.W101]

2. Critérios de seleção [PA160.IG101.SP101.W102]

Sub-práticas

1. Estabelecer e manter um processo ou processos de identificação de alternativas de solução, critérios de seleção e questões de design. [PA160.IG101.SP101.SubP101]



Os critérios de seleção são influenciados por uma ampla variedade de fatores, desde os requisitos impostos no projeto até o ciclo de vida do produto. Por exemplo, critérios relacionados à mitigação de riscos de custos e cronograma podem influenciar uma maior preferência por soluções de prateleira, desde que estas seleções não resultem em riscos inaceitáveis para os demais componentes de produtos a serem desenvolvidos. Quando se utiliza itens já existentes, como os de prateleira, com ou sem modificações, os critérios que tratam da diminuição de fontes de obsolescência de fornecimento ou tecnologia deverão ser examinados, assim como critérios que capturam os benefícios da padronização, manutenção de relacionamentos com fornecedores e assim por diante. Os critérios utilizados nas seleções deverão fornecer uma abordagem balanceada de custos, benefícios e riscos. [PA160.IG101.SP101.SubP101.N101]

2. Identificar agrupamentos alternativos de requisitos que caracterizam conjuntos de soluções alternativas que expandem o espaço do design possível. [PA160.IG101.SP101.SubP102]

O efetivo emprego de alternativas de prateleira pode oferecer desafios especiais. Designers especialistas conhecedores das alternativas de prateleira candidatas podem explorar as oportunidades de arquitetura para explorar os potenciais benefícios das alternativas de prateleira. [PA160.IG101.SP101.SubP102.N101]

3. Identificar questões de design para cada alternativa de solução em cada conjunto de alternativas. [PA160.IG101.SP101.SubP103]

4. Caracterizar as questões de design e tomar as ações apropriadas. [PA160.IG101.SP101.SubP104]

As ações apropriadas poderiam ser caracterizar as questões como um risco no gerenciamento de riscos, ajustar a solução alternativa para prever as questões ou rejeitar a solução alternativa e substituí-la com uma diferente alternativa. [PA160.IG101.SP101.SubP104.N101]

5. Obter uma alocação completa de requisitos para cada alternativa. [PA160.IG101.SP101.SubP105]

6. Documentar a justificativa para cada conjunto alternativo de soluções. [PA160.IG101.SP101.SubP106]

SP 1.2 Evoluir os Conceitos Operacionais e Cenários

Evoluir o conceito operacional, cenários e ambientes para descrever as condições, modos de operação e estados operacionais para cada componente do produto. [PA160.IG101.SP103]

Veja a prática específica Estabelecer Conceitos Operacionais e Cenários da área de processo de Desenvolvimento de Requisitos para obter maiores informações sobre influências e implicações no nível do produto das operações de componentes de produtos. [PA160.IG101.SP103.R101]




Integrar os conceitos operacionais e cenários produzidos por diversos indivíduos e grupos para cada nível de decomposição física do produto. [PA160.IG101.SP103.AMP101]

Deve-se evoluir os conceitos operacionais e cenários para facilitar a seleção de soluções de componentes de produtos que, quando implementadas, satisfarão o uso pretendido do produto. Conceitos operacionais e cenários documentam a interação dos componentes de produtos com o ambiente, usuários e outros componentes de produtos, independente da disciplina de engenharia. Eles deverão ser documentados para operação, implementação do produto, entrega, suporte (incluindo manutenção e sustentação), treinamento e descarte e para todos os modos e estados. [PA160.IG101.SP103.N101]

Os ambientes (operacional, de suporte, de treinamento, etc.) também precisam evoluir. O ambiente de um dado componente de produto será influenciado por outros componentes de produtos, assim como pelo ambiente externo. [PA160.IG101.SP103.N102]


1. Conceitos operacionais de componentes de produtos, cenários e ambientes para todos os processos relacionados com o ciclo de vida do produto (por exemplo, operação, suporte, treinamento, construção, implementação, campo, entrega e descarte) [PA160.IG101.SP103.W101]

2. Análises de tempo para as interações de componentes de produtos [PA160.IG101.SP103.W102]

3. Use cases [PA160.IG101.SP103.W104]

Sub-práticas

1. Evoluir os conceitos operacionais e cenários a um grau apropriado de detalhes para o componente de produto. [PA160.IG101.SP103.SubP101]

2. Evoluir os ambientes operacionais para os componentes de produtos. [PA160.IG101.SP103.SubP102]

Os ambientes podem incluir elementos térmicos, stress, eletromagnéticos e outros que precisem ser documentados. [PA160.IG101.SP103.SubP102.N101]

SP 1.3 Selecionar Soluções de Componentes de Produtos

Selecionar as soluções de componentes de produtos que melhor satisfazem os critérios estabelecidos. [PA160.IG101.SP104]



Veja as práticas específicas Alocar Requisitos de Componentes de Produtos e Identificar Requisitos de Interfaces, da área de processo de Desenvolvimento de Requisitos para obter maiores informações sobre como estabelecer os requisitos alocados para os componentes de produtos e os requisitos de interface entre os componentes do produto. [PA160.IG101.SP104.R101]

Veja a área de processo de Análises de Decisões e Resoluções para obter maiores informações sobre avaliações formais. [PA160.IG101.SP104.R102]

Selecionar componentes de produtos que melhor satisfazem os critérios estabelece as alocações de requisitos aos componentes de produtos. Requisitos de mais baixo nível são gerados a partir da alternativa selecionada e utilizados para desenvolver o design dos componentes do produto. Os requisitos de interface entre os componentes do produto são descritos, inicialmente apenas funcionalmente. Descrições de interfaces físicas são incluídas na documentação para a interface com itens e atividades externos ao produto. [PA160.IG101.SP104.N101]

A descrição das soluções e a justificativa para a seleção são documentadas. A documentação evolui ao longo do desenvolvimento, conforme as soluções e designs detalhados são desenvolvidos e estes designs implementados. Manter um registro das justificativas é crítico para a tomada das decisões seguintes. Tais registros impedem que os stakeholders seguintes da cadeia de decisões tenham um retrabalho e fornecem entendimentos sobre como aplicar a tecnologia, conforme ela se torna disponível, em circunstâncias aplicáveis. [PA160.IG101.SP104.N102]


1. Decisões e justificativa da seleção de componentes de produtos [PA160.IG101.SP104.W101]

2. Relacionamentos documentados entre requisitos e componentes de produtos [PA160.IG101.SP104.W102]

3. Soluções, avaliações e justificativas documentadas [PA160.IG101.SP104.W103]

Sub-práticas

1. Avaliar cada solução/conjunto de soluções alternativos contra os critérios de seleção estabelecidos no contexto dos conceitos operacionais, modos de operação e estados operacionais. [PA160.IG101.SP104.SubP101]

2. Com base na avaliação das alternativas, analisar a adequação dos critérios de seleção e atualizar estes critérios, conforme necessário. [PA160.IG101.SP104.SubP102]



3. Identificar e resolver questões com as soluções alternativas e requisitos. [PA160.IG101.SP104.SubP103]

4. Selecionar o melhor conjunto de soluções alternativas que satisfazem os critérios de seleção estabelecidos. [PA160.IG101.SP104.SubP104]

5. Estabelecer os requisitos associados com o conjunto selecionado de alternativas como sendo o conjunto de requisitos alocados àqueles componentes de produtos. [PA160.IG101.SP104.SubP105]

6. Identificar as soluções de componentes de produtos que serão reusadas ou adquiridas. [PA160.IG101.SP104.SubP107]

Veja a área de processo de Gerenciamento de Acordos com Fornecedores para obter maiores informações sobre como adquirir produtos e componentes de produtos. [PA160.IG101.SP104.SubP107.R101]

7. Estabelecer e manter a documentação das soluções, avaliações e justificativas. [PA160.IG101.SP104.SubP106]

SG 2 Desenvolver o Design

Designs de produtos ou componentes de produto são desenvolvidos. [PA160.IG102]

Os designs de produtos e componentes de produtos devem fornecer o conteúdo apropriado não somente para a implementação, mas também para outras fases do ciclo de vida do produto, como modificações, recompra, manutenção, sustentação e instalação. A documentação do design fornece uma referência para suportar o entendimento mútuo do design pelos stakeholders relevantes e apoiar futuras mudanças no design, tanto durante o desenvolvimento como nas fases subseqüentes do ciclo de vida do produto. Uma descrição completa do design é documentada em um pacote de dados técnicos, que inclui uma gama completa de recursos e parâmetros incluindo formato, encaixe, funções, interfaces, características do processo de construção e outros parâmetros. Padrões organizacionais estabelecidos ou de design de projetos (por exemplo, checklists, templates, frameworks de objetos) formam a base para atingir um alto nível de definição e completitude na documentação do design. [PA160.IG102.N101]

SP 2.1 Criar o Design do Produto ou Componente do Produto

Desenvolver um design para o produto ou componente do produto. [PA160.IG102.SP101]



O design do produto consiste de duas grandes fases que podem se sobrepor na execução: design preliminar e detalhado. O design preliminar estabelece as capacidades do produto e a arquitetura do produto, incluindo partições de produto, identificações de componentes de produtos, estados e modos do sistema, principais interfaces entre os componentes e interfaces com produtos externos. O design detalhado define completamente a estrutura e capacidades dos componentes do produto. [PA160.IG102.SP101.N101]

Veja a área de processo de Desenvolvimento de Requisitos para obter maiores informações sobre o desenvolvimento de requisitos de arquitetura. [PA160.IG102.SP101.N101.R101]

A definição da arquitetura é feita a partir de um conjunto de requisitos de arquitetura, desenvolvidos durante os processos de desenvolvimento de requisitos. Estes requisitos expressam as qualidades e pontos de desempenho que são críticos para o sucesso do produto. A arquitetura define os elementos estruturais e mecanismos de coordenação que satisfazem diretamente os requisitos ou suportam o atendimento dos requisitos, conforme os detalhes do design do produto são estabelecidos. As arquiteturas podem incluir padrões e regras de design que governam o desenvolvimento de componentes de produtos e suas interfaces, bem como um direcionamento para auxiliar os desenvolvedores do produto. As práticas específicas da meta específica Selecionar Soluções de Componentes de Produtos contêm maiores informações sobre como utilizar a arquitetura do produto como base para as soluções alternativas. [PA160.IG102.SP101.N102]

Os arquitetos postulam e desenvolvem um modelo do produto, tomando decisões sobre a alocação de requisitos a componentes do produto, incluindo hardware e software. Diversas arquiteturas, suportando soluções alternativas, podem ser desenvolvidas e analisadas para definir as vantagens e desvantagens no contexto dos requisitos de arquitetura. [PA160.IG102.SP101.N103]

Os conceitos operacionais e cenários são utilizados para gerar use cases e cenários de qualidade que são utilizados para refinar a arquitetura. Eles também são utilizados como meios para avaliar a adequação da arquitetura com relação ao seu objetivo pretendido, durante as avaliações de arquitetura que são conduzidas periodicamente durante o design do produto. A prática específica Evoluir Conceitos Operacionais e Cenários traz maiores informações sobre como elaborar conceitos operacionais e cenários utilizados na avaliação da arquitetura. [PA160.IG102.SP101.N104]



Veja a prática específica Estabelecer Conceitos Operacionais e Cenários da área de processo de Desenvolvimento de Requisitos para obter maiores informações sobre como desenvolver conceitos operacionais e cenários utilizados na avaliação da arquitetura. [PA160.IG102.SP101.N104.R101]


Além das tarefas identificadas acima, a definição da arquitetura de software pode incluir: [PA160.IG102.SP101.N104.AMP101]

Estabelecer as relações estruturais de partições e regras com relação a interfaces entre elementos dentro de partições e entre partições

Identificar as principais interfaces internas e todas as interfaces externas do software

Identificar componentes de produtos de software

Definir mecanismos de coordenação de software

Estabelecer capacidades e serviços de infra-estrutura

Desenvolver templates de componentes de produtos ou classes e frameworks

Estabelecer regras de design e autoridade para a tomada de decisões

Definir um processo/modelo a ser seguido

Definir a implantação física do software no hardware

Identificar principais abordagens e fontes de reuso

Durante o design detalhado, os detalhes da arquitetura do produto são finalizados, os componentes do produto são completamente definidos e as interfaces são totalmente caracterizadas. Os designs dos componentes dos produtos podem ser otimizados para certas qualidades ou características de desempenho. Os designers podem avaliar o uso de produtos legados ou de prateleira para os componentes de produtos. Conforme o design amadurece, os requisitos atribuídos a componentes de produtos de nível mais baixo são rastreados para assegurar que estes requisitos estão sendo satisfeitos. [PA160.IG102.SP101.N105]

Veja a área de processo de Gerenciamento de Requisitos para obter maiores informações sobre como rastrear requisitos para componentes de produtos. [PA160.IG102.SP101.N105.R101]


O design detalhado está concentrado no desenvolvimento do componente de produto de software. A estrutura interna dos componentes de produtos é definida, o modelo de dados é gerado, os algoritmos são desenvolvidos e heurísticas são estabelecidas para fornecer capacidades de componentes de produtos que satisfazem os requisitos alocados. [PA160.IG102.SP101.N105.AMP101]




1. Arquitetura do produto [PA160.IG102.SP101.W101]

2. Designs dos componentes de produtos [PA160.IG102.SP101.W102]

Sub-práticas

1. Estabelecer e manter critérios contra os quais o design pode ser avaliado. [PA160.IG102.SP101.SubP101]

Exemplos de atributos, além do desempenho esperado, para os quais podem ser estabelecidos critérios de design incluem: [PA160.IG102.SP101.SubP101.N101]

Modular

Claro

Simples

Possível de ser mantido

Verificável

Portável

Confiável

Preciso

Seguro

Possível de ser expandido

Usável

2. Identificar, desenvolver ou adquirir os métodos de design apropriados para o produto. [PA160.IG102.SP101.SubP102]

Métodos de design eficientes podem incorporar uma ampla gama de atividades, ferramentas e técnicas descritivas. Se um dado método é eficiente ou não depende da situação. Duas empresas podem ter métodos de design muito eficientes para os produtos nos quais elas são especializadas, mas estes métodos podem não ser eficientes em empreendimentos de cooperação. Métodos altamente sofisticados não são necessariamente eficientes nas mãos de designers que não tenham sido treinados no uso destes métodos. [PA160.IG102.SP101.SubP102.N101]



Se um método é eficiente ou não também depende da quantidade de auxílio que este fornece ao designer e da eficiência de custo deste auxílio. Por exemplo, um recurso de prototipação de multicamadas pode não ser apropriado para um simples componente de produto, mas poderia ser a coisa certa a ser feita para um desenvolvimento de um produto complexo, sem precedentes e caro. Técnicas rápidas de prototipação, entretanto, podem ser altamente eficientes para muitos componentes de produtos. Métodos que utilizam ferramentas para assegurar que um design tratará todos os atributos necessários para implementar o design do componente do produto podem ser muito eficientes. Por exemplo, uma ferramenta de design que “conhece” as capacidades dos processos de fabricação pode permitir que a variação no processo de construção seja considerada na tolerância do design. [PA160.IG102.SP101.SubP102.N102]

Exemplos de técnicas e métodos que facilitam o design eficiente incluem: [PA160.IG102.SP101.SubP102.N103]

Protótipos

Modelos estruturais

Design orientado a objetos

Análise essencial de sistemas

Modelos de Entidades Relacionamentos

Reuso do design

Design patterns (padrões de design)

3. Assegurar que o design adere aos padrões e critérios de design aplicáveis. [PA160.IG102.SP101.SubP103]

Exemplos de padrões de design incluem (alguns ou todos estes padrões podem ser critérios de design, particularmente em circunstâncias onde os padrões não tenham sido estabelecidos): [PA160.IG102.SP101.SubP103.N101]

Padrões de interface com o operador

Padrões de segurança

Restrições de produção

Tolerâncias do design

Padrões de partes (por exemplo, particionamento e desperdício da produção)

4. Assegurar que o design adere aos requisitos alocados. [PA160.IG102.SP101.SubP104]

Os componentes de produtos de prateleira identificados devem ser levados em conta. Por exemplo, colocar componentes de produtos existentes na arquitetura do produto poderia modificar os requisitos e a alocação dos requisitos. [PA160.IG102.SP101.SubP104.N101]

5. Documentar o design. [PA160.IG102.SP101.SubP105]



SP 2.2 Estabelecer um Pacote de Dados Técnicos

Estabelecer e manter um pacote de dados técnicos. [PA160.IG102.SP103]

Um pacote de dados técnicos oferece ao desenvolvedor uma descrição abrangente do produto ou do componente de produto, conforme ele é desenvolvido. Tal pacote também fornece flexibilidade na aquisição de suprimentos em várias ocasiões, como em contratação baseada em desempenho ou de construir para receber. [PA160.IG102.SP103.N102]

O design é registrado em um pacote de dados técnicos que é criado durante o design preliminar para documentar a definição da arquitetura. Este pacote de dados técnicos é mantido durante toda a vida do produto para registrar os detalhes essenciais do design do produto. O pacote de dados técnicos fornece a descrição de um produto ou componente de produto (incluindo processos relacionados ao ciclo de vida do produto, se não forem tratados como componentes de produtos separados) que suporta uma estratégia de aquisição ou as fases de implementação, produção, engenharia e suporte logístico do ciclo de vida do produto. A descrição inclui a definição da configuração de design necessária e dos procedimentos para assegurar a adequação do desempenho do produto ou componente de produto. Isto inclui todos os dados técnicos disponíveis, como diagramas, listas associadas, especificações, descrições de design, bancos de dados de design, padrões, requisitos de desempenho, provisões de garantia da qualidade e detalhes de empacotamento. O pacote de dados técnicos inclui uma descrição da solução alternativa que foi escolhida para implementação. [PA160.IG102.SP103.N106]

Um pacote de dados técnicos deverá incluir o seguinte, se tais informações forem apropriadas para o tipo de produto ou componente de produto (por exemplo, requisitos de material e de manufatura podem não ser úteis para componentes de produtos associados com serviços ou processos de software): [PA160.IG102.SP103.N103]

Descrição da arquitetura do produto

Requisitos alocados

Descrições de componentes de produtos

Descrições de processos relacionados com o ciclo de vida do produto, se não estiverem descritos como componentes de produtos separados

Características dos produtos chave

Características físicas exigidas e restrições

Requisitos de interface

Requisitos de materiais (listas e características de materiais)

Requisitos de fabricação e manufatura (para o equipamento original de fabricação e para o suporte de campo)



Os critérios de verificação utilizados para assegurar que os requisitos foram atendidos

Condições de uso (ambientes) e cenários operacionais/de uso, modos e estados de operações, suporte, treinamento, manufatura, descarte e verificações durante toda a vida do produto

Justificativas para decisões e características (requisitos, alocações de requisitos e opções de design)

Uma vez que descrições de design podem envolver um volume muito grande de dados e ser cruciais para o desenvolvimento bem sucedido do componente de produto, é recomendável estabelecer critérios para organizar e selecionar o conteúdo dos dados. É particularmente útil utilizar a arquitetura do produto como um meio de organizar esses dados e abstrair visões que sejam claras e relevantes para uma questão ou característica de interesse. Estas visões incluem: [PA160.IG102.SP103.N104]

Clientes

Requisitos

O ambiente

Funcional

Lógica

Segurança

Dados

Estados/modos

Construção

Gerenciamento

Estas visões estão documentadas em um pacote de dados técnicos. [PA160.IG102.SP103.N105]


1. Pacote de dados técnicos [PA160.IG102.SP103.W101]

Sub-práticas

1. Determinar a quantidade de níveis de design e o nível apropriado de documentação para cada nível de design. [PA160.IG102.SP103.SubP101]

Determinar o número de níveis de componentes de produtos (por exemplo, subsistema, item de configuração de hardware, placa de circuito, item de configuração de software do computador [CSCI], componente de produto de software do computador, unidade de software de computador) que exigem documentação e rastreabilidade de requisitos, é importante para gerenciar os custos de documentação e para suportar os planos de integração e verificação [PA160.IG102.SP103.SubP101.N101]



2. Basear as descrições detalhadas de design nos requisitos alocados de componentes de produto, arquitetura e níveis mais altos de design. [PA160.IG102.SP103.SubP102]

3. Documentar o design no pacote de dados técnicos. [PA160.IG102.SP103.SubP103]

4. Documentar a justificativa para as decisões chave (isto é, que têm um efeito significativo no custo, cronograma ou desempenho técnico) tomadas ou definidas. [PA160.IG102.SP103.SubP104]

5. Revisar o pacote de dados técnicos, conforme necessário. [PA160.IG102.SP103.SubP105]

SP 2.3 Criar Design de Interfaces Utilizando Critérios

Criar design de interfaces abrangentes de componentes de produtos, em termos dos critérios estabelecidos e mantidos. [PA160.IG102.SP105]

Os designs de interface incluem: [PA160.IG102.SP105.N101]

Origem

Destino

Estímulos e características de dados para software

Características elétricas, mecânicas e funcionais para hardware

Os critérios para as interfaces, muitas vezes, refletem uma lista abrangente de parâmetros críticos que devem ser definidos ou, pelo menos, investigados, para assegurar sua aplicabilidade. Estes parâmetros são, muitas vezes, específicos de um dado tipo de produto (por exemplo, software, mecânico, elétrico) e são freqüentemente associados com características de segurança, proteção, durabilidade e missão crítica. [PA160.IG102.SP105.N102]


1. Especificações de design de interfaces [PA160.IG102.SP105.W101]

2. Documentos de controle de interfaces [PA160.IG102.SP105.W102]

3. Critérios de especificação de interfaces [PA160.IG102.SP105.W103]

4. Justificativa para o design de interface selecionado [PA160.IG102.SP105.W104]

Sub-práticas

1. Definir critérios de interfaces. [PA160.IG102.SP105.SubP101]



Estes critérios podem ser uma parte dos ativos de processos da organização. [PA160.IG102.SP105.SubP101.N101]

Veja a área de processo de Definição do Processo Organizacional para obter maiores informações sobre o estabelecimento e manutenção dos ativos de processos organizacionais. [PA160.IG102.SP105.SubP101.N101.R101]

2. Aplicar os critérios às alternativas de design das interfaces. [PA160.IG102.SP105.SubP102]

Veja a área de processo de Análises de Decisões e Resoluções para obter maiores informações sobre identificação de critérios e seleção de alternativas com base naqueles critérios. [PA160.IG102.SP105.SubP102.R101]

3. Documentar os designs de interfaces selecionados e a justificativa para a seleção. [PA160.IG102.SP105.SubP103]

A seguinte prática específica aparece na representação contínua como SP 2.3-1, mas é categorizada na representação em estágios como SP 2.3, Criar Design das Interfaces Utilizando Critérios. A prática específica é apresentada aqui em cinza somente como material informativo.

SP 2.3-1 Estabelecer Descrições de Interfaces

Estabelecer e manter a soluções para as interfaces dos componentes de produtos. [PA160.IG102.SP104]

A descrição das interfaces de componentes de produto cobre as interfaces entre: [PA160.IG102.SP104.N101]

Componentes de produto e componentes de produto

Componentes de produto de baixo nível e componentes de produto de alto nível

Componentes de produto e processos relacionados com o ciclo de vida do produto

Componentes de produtos e itens externos


1. Design da interface [PA160.IG102.SP104.W101]

2. Documentos do design da interface [PA160.IG102.SP104.W102]

Sub-práticas

1. Identificar e documentar as interfaces associadas com outros componentes de produtos. [PA160.IG102.SP104.SubP101]



2. Identificar interfaces associadas com itens externos. [PA160.IG102.SP104.SubP102]

3. Identificar interfaces entre componentes de produtos e processos relacionados com o ciclo de vida do produto. [PA160.IG102.SP104.SubP103]

Por exemplo, tais interfaces poderiam incluir aquelas entre um componente de produto a ser fabricado e os equipamentos e máquinas utilizados para possibilitar a fabricação durante o processo de manufatura. [PA160.IG102.SP104.SubP103.N101]

4. Assegurar que a solução inclui os requisitos de interface desenvolvidos nos processos de desenvolvimento de requisitos. [PA160.IG102.SP104.SubP104]

Veja a prática específica Identificar os Requisitos de Interfaces na área de processo de Desenvolvimento de Requisitos para obter maiores informações sobre a identificação dos requisitos de interface dos produtos e componentes de produtos. [PA160.IG102.SP104.SubP104.R101]

SP 2.4 Executar Análises de Fabricação, Compra ou Reuso

Avaliar se os componentes do produto deverão ser desenvolvidos, comprados ou reutilizados, com base nos critérios estabelecidos. [PA160.IG102.SP106]

A determinação de quais produtos ou componentes de produtos serão adquiridos é freqüentemente chamada de “análise de fabricação ou compra” (make-or-buy analysis). Esta é baseada em uma análise das necessidades do projeto. Esta análise de fabricação ou compra começa bem cedo no projeto durante a primeira iteração de design, continua durante o processo de design e se completa com a decisão de desenvolver, adquirir ou reutilizar o produto. [PA160.IG102.SP106.N103]

Veja a área de processo de Desenvolvimento de Requisitos para obter maiores informações sobre como determinar os requisitos de produtos e componentes de produtos. [PA160.IG102.SP106.N103.R101]

Veja a área de processo de Gerenciamento de Requisitos para obter maiores informações sobre como gerenciar requisitos. [PA160.IG102.SP106.N103.R102]

Fatores que afetam a decisão de fabricação ou compra incluem: [PA160.IG102.SP106.N104]

Funções que os produtos ou serviços fornecerão e como estas funções se encaixam no projeto

Recursos e habilidades disponíveis para o projeto

Custos de aquisição versus desenvolvimento interno



Datas críticas de entrega e integração

Alianças estratégicas de negócios, incluindo requisitos de negócios de alto nível

Pesquisa de mercado dos produtos disponíveis, inclusive os de prateleira

Funcionalidade e qualidade dos produtos disponíveis

Conhecimento e capacitação dos fornecedores potenciais

Impacto nas competências principais

Licenças, garantias, responsabilidades e limitações associadas com os produtos que estão sendo adquiridos

Disponibilidade do produto

Questões de propriedade

Redução de riscos

Muitos destes fatores são tratados pelo projeto. [PA160.IG102.SP106.N105]

A decisão de fabricar ou comprar pode ser conduzida utilizando uma abordagem de avaliação formal. [PA160.IG102.SP106.N106]

Veja a área de processo de Análises de Decisões e Resoluções para obter maiores informações sobre como definir critérios e alternativas e como executar avaliações formais. [PA160.IG102.SP106.N106.R101]

Da mesma forma que a tecnologia evolui, as justificativas para a escolha entre desenvolver ou comprar um componente de produto também evoluem. Embora esforços complexos de desenvolvimento possam favorecer a compra de um componente de produto de prateleira, avanços na produtividade e nas ferramentas podem oferecer uma justificativa oposta. Produtos de prateleira podem ter documentações incompletas ou imprecisas e podem não ter suporte no futuro. [PA160.IG102.SP106.N101]



Uma vez que tenha sido tomada a decisão de se adquirir um componente de produto de prateleira, os requisitos são utilizados para se estabelecer um acordo com o fornecedor. Existem momentos em que “de prateleira” se refere a um item já existente que pode não estar prontamente disponível no mercado. Por exemplo, alguns itens de aviação e motores não são realmente “de prateleira”, mas podem ser prontamente adquiridos. Em alguns casos, o uso de tais itens não desenvolvidos se faz em situações onde as especificidades de desempenho e outras características esperadas do produto precisam estar dentro de limites definidos. Nestes casos, os requisitos e critérios de aceitação podem precisar ser incluídos no acordo com o fornecedor e ser gerenciados. Em outros casos, o produto de prateleira é literalmente de prateleira (software de processamento de texto, por exemplo) e não há um acordo com o fornecedor que precise ser gerenciado. [PA160.IG102.SP106.N102]

Veja a área de processo de Gerenciamento de Acordos com Fornecedores para obter maiores informações sobre como tratar a aquisição de componentes de produtos que serão comprados. [PA160.IG102.SP106.N102.R101]


1. Critérios para design e reuso de componentes de produtos [PA160.IG102.SP106.W101]

2. Análises de fabricar ou comprar (Make-or-buy analyses) [PA160.IG102.SP106.W102]

3. Instruções para a escolha de componentes de produtos de prateleira [PA160.IG102.SP106.W103]

Sub-práticas

1. Desenvolver critérios para o reuso de designs de componentes de produtos. [PA160.IG102.SP106.SubP102]

2. Analisar os designs para determinar se os componentes do produto deverão ser desenvolvidos, reutilizados ou comprados. [PA160.IG102.SP106.SubP103]

3. Quando itens comprados ou não desenvolvidos (de prateleira, de prateleira governamentais e reuso) forem selecionados, planejar a sua manutenção. [PA160.IG102.SP106.SubP101]


Considerar como será tratada a compatibilidade de futuros releases de um sistema operacional ou de um gerenciador de banco de dados. [PA160.IG102.SP106.SubP101.AMP101]



SG 3 Implementar o Design do Produto

Componentes de produtos e a documentação de suporte associada são implementados a partir dos seus designs. [PA160.IG103]

Componentes de produtos são implementados a partir dos designs estabelecidos pelas práticas específicas da meta específica Desenvolver o Design. A implementação normalmente inclui testes de unidade dos componentes do produto, antes de enviá-los para a integração do produto e desenvolvimento da documentação do usuário final. [PA160.IG103.N101]

SP 3.1 Implementar o Design

Implementar os designs dos componentes de produtos. [PA160.IG103.SP101]


Código de software é um típico componente de produto de software. [PA160.IG103.SP101.AMP101]

Uma vez que o design tenha sido completado, ele é implementado como um componente de produto. As características desta implementação dependem do tipo de componente de produto. [PA160.IG103.SP101.N101]

A implementação do design no nível mais alto da hierarquia do produto envolve a especificação de cada um dos componentes de produtos no próximo nível da hierarquia do produto. Esta atividade inclui a alocação, refinamento e verificação de cada componente de produto. Ela também envolve a coordenação entre os diversos esforços de desenvolvimento de componentes de produtos. [PA160.IG103.SP101.N103]

Veja a área de processo de Desenvolvimento de Requisitos para obter maiores informações sobre a alocação e refinamento de requisitos. [PA160.IG103.SP101.N103.R101]

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. [PA160.IG103.SP101.N103.R102]



Exemplos de características desta implementação são: [PA160.IG103.SP101.N102]

O software é codificado.

Os dados são documentados.

Os serviços são documentados.

As partes elétricas e mecânicas são fabricadas.

Processos de manufatura específicos do produto são colocados em operação.

Os processos são documentados.

Os recursos são construídos.

Os materiais são produzidos (por exemplo, um material específico de um produto poderia ser um tipo de petróleo, óleo, lubrificante ou uma nova liga).


1. Design implementado [PA160.IG103.SP101.W101]

Sub-práticas

1. Usar métodos eficientes para implementar os componentes dos produtos. [PA160.IG103.SP101.SubP101]


Exemplos de métodos de codificação de software incluem: [PA160.IG103.SP101.SubP101.AMP101]

Programação estruturada

Programação orientada a objetos

Geração automática de códigos

Reuso de código de software

Uso de padrões de design (design patterns) aplicáveis


Exemplos de métodos de fabricação apropriados incluem: [PA160.IG103.SP101.SubP101.AMP102]

Prensa

Modelagem

Formas

Combinação

Corte

Ferramental

Solda

Extrusão

2. Aderir aos padrões e critérios aplicáveis. [PA160.IG103.SP101.SubP102]




Exemplos de padrões para codificação de software incluem: [PA160.IG103.SP101.SubP102.AMP101]

Padrões de linguagens

Convenções de nomes de variáveis

Estruturas de linguagem aceitáveis

Estrutura e hierarquia de componentes de produtos de software

Formato do código e comentários


Exemplos de critérios de codificação de software incluem: [PA160.IG103.SP101.SubP102.AMP102]

Modularização

Clareza

Simplicidade

Estrutura (por exemplo, sem GOTOs, uma entrada, uma saída)

Possibilidade de manutenção


Exemplos de padrões incluem: [PA160.IG103.SP101.SubP102.AMP103]

Listas de Partes Padrão (Standard Parts Lists)

Requisitos de diagramação padrão

Padrões da International Organization for Standardization (ISO) T3303 para as partes manufaturadas


Exemplos de critérios incluem: [PA160.IG103.SP101.SubP102.AMP104]


Confiabilidade

Segurança

3. Conduzir revisões por pares dos componentes de produtos selecionados. [PA160.IG103.SP101.SubP103]

Veja a área de processo de Verificação para obter maiores informações sobre como conduzir revisões por pares. [PA160.IG103.SP101.SubP103.R101]

4. Executar testes de unidade do componente de produto, conforme apropriado. [PA160.IG103.SP101.SubP104]



Note que o teste de unidade não está limitado ao software. Testes de unidade envolvem o teste de unidades individuais de hardware ou software ou grupos de itens relacionados antes da sua integração. [PA160.IG103.SP101.SubP104.N101]

Veja a área de processo de Verificação para obter maiores informações sobre métodos e procedimentos de verificação e sobre como verificar os produtos de trabalho contra seus requisitos especificados. [PA160.IG103.SP101.SubP104.N101.R101]


Exemplos de métodos de testes de unidade incluem: [PA160.IG103.SP101.SubP104.N101.AMP101]

Teste de avaliação de cobertura

Teste de cobertura de ramos

Teste de cobertura de predicados

Teste de cobertura de caminhos

Teste de valores de fronteira

Teste de valores especiais

5. Revisar o componente de produto, conforme necessário. [PA160.IG103.SP101.SubP105]

Um exemplo de quando o componente do produto precisa ser revisado é quando aparecem problemas durante a implementação que não poderiam ser previstos durante o design. [PA160.IG103.SP101.SubP105.N101]

SP 3.2 Desenvolver Documentação de Suporte ao Produto

Desenvolver e manter a documentação do usuário final. [PA160.IG103.SP102]

Esta prática específica desenvolve e mantém a documentação que será utilizada para instalar, operar e manter o produto. [PA160.IG103.SP102.N101]


1. Materiais de treinamento do usuário final [PA160.IG103.SP102.W101]

2. Manual do usuário [PA160.IG103.SP102.W102]

3. Manual de operação [PA160.IG103.SP102.W103]

4. Manual de manutenção [PA160.IG103.SP102.W104]

5. Help Online [PA160.IG103.SP102.W105]



Sub-práticas

1. Revisar os requisitos, design, produto e resultados de testes para assegurar que as questões que afetam a documentação de instalação, operação e manutenção foram identificadas e resolvidas. [PA160.IG103.SP102.SubP101]

2. Usar métodos eficientes para desenvolver a documentação de instalação, operação e manutenção. [PA160.IG103.SP102.SubP102]

3. Aderir aos padrões aplicáveis de documentação. [PA160.IG103.SP102.SubP103]

Exemplos de padrões de documentação incluem: [PA160.IG103.SP102.SubP103.N101]

Compatibilidade com os processadores de texto definidos

Fontes aceitáveis

Numeração de páginas, seções e parágrafos

Consistência com um estilo definido de manual

Uso de abreviações

Marcações de classificações de segurança

Requisitos de internacionalização

4. Desenvolver versões preliminares da documentação de instalação, operação e manutenção nas fases iniciais do ciclo de vida do projeto, para revisão com os stakeholders relevantes. [PA160.IG103.SP102.SubP104]

5. Conduzir revisões por pares da documentação de instalação, operação e manutenção. [PA160.IG103.SP102.SubP105]

Veja a área de processo de Verificação para obter maiores informações sobre a condução de revisões por pares. [PA160.IG103.SP102.SubP105.R101]

6. Revisar a documentação de instalação, operação e manutenção, conforme necessário. [PA160.IG103.SP102.SubP106]

Exemplos de quando a documentação pode precisar ser revisada incluem quando os seguintes eventos ocorrem: [PA160.IG103.SP102.SubP106.N101]

Mudanças de requisitos

São feitas mudanças no design

São feitas mudanças no produto

Erros são identificados na documentação

Consertos provisórios são identificados





Compromissos


Estabelecer e manter uma política organizacional para planejamento e execução do processo de soluções técnicas. [GP103]

Elaboração:

Esta política estabelece as expectativas organizacionais para tratar o ciclo iterativo no qual as soluções de componentes de produtos são selecionadas, designs de produtos e componentes de produtos são desenvolvidos e designs dos componentes de produtos são implementados. [PA160.EL101]

Habilitações


Estabelecer e manter a descrição de um processo definido de soluções técnicas. [GP114]


Estabelecer e manter o plano para a execução do processo de soluções técnicas. [GP104]

Elaboração:

Normalmente, este plano para a execução do processo de soluções técnicas é uma parte do plano do projeto, como descrito na área de processo de Planejamento do Projeto. [PA160.EL102]


Fornecer recursos adequados para a execução do processo de soluções técnicas, desenvolvimento dos produtos de trabalho e fornecimento dos serviços do processo. [GP105]



Elaboração:

Recursos especiais podem ser exigidos para o desenvolvimento, design e implementação de soluções para requisitos. Quando necessário, os recursos exigidos para as atividades da área de processo de Soluções Técnicas são desenvolvidos ou comprados. [PA160.EL111]


Ferramentas de especificação de design

Simuladores e ferramentas de modelagem


Ferramentas de definição e gerenciamento de cenários


Ferramentas de documentação interativa


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


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

Elaboração:


Domínio da aplicação do produto e dos componentes do produto

Métodos de design

Design de interfaces

Técnicas de testes de unidade

Padrões (por exemplo, produto, segurança, fatores humanos, ambientais)



Implementações


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

Elaboração:


Design de produtos, componentes de produtos, processos, serviços e interfaces

Pacotes de dados técnicos

Documentos de design de interfaces

Critérios para reuso de design e componentes de produtos

Designs implementados (por exemplo, código de software, componentes de produtos fabricados)

Documentação do usuário, de instalação, operação e manutenção


Identificar e envolver os stakeholders relevantes do processo de soluções técnicas, conforme planejado. [GP124]

Elaboração:

Selecionar stakeholders relevantes a partir de clientes, usuários finais, desenvolvedores, produtores, testadores, fornecedores, pessoal de marketing, manutenção e descarte e outros que podem ser afetados ou afetar o produto, assim como o processo. [PA160.EL113]


Desenvolver soluções alternativas e critérios de seleção

Evoluir o conceito operacional e os cenários

Obter aprovação sobre as especificações de interfaces externas e descrições de design

Desenvolver os pacotes de dados técnicos

Avaliar as alternativas de fabricação, compra ou reuso de componentes de produtos

Implementar o design




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

Elaboração:


Custo, cronograma e esforço dispendido no retrabalho

Percentual de requisitos tratados no design do produto ou do componente do produto

Tamanho e complexidade do produto, componentes de produtos, interfaces e documentação

Densidade de defeitos dos produtos de trabalho das soluções técnicas


Coletar produtos de trabalho, medidas, resultados de medições e informações de melhoria derivadas do planejamento e execução do processo de soluções técnicas para suportar o uso futuro e melhoria dos processos e ativos de processos da organização. [GP117]

Verificações


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

Elaboração:


Selecionar soluções de componentes de produtos

Desenvolver designs de produtos e de componentes de produtos

Implementar designs de componentes de produtos




Pacotes de dados técnicos

Designs de produtos, componentes de produtos e interfaces

Designs implementados (por exemplo, código de software, componentes de produtos fabricados)

Documentação do usuário, de instalação, operação e manutenção


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



INTEGRAÇÃO DE PRODUTOS


Objetivo

O objetivo da Integração de Produtos (Product Integration) é montar o produto a partir dos componentes de produtos, assegurar que o produto, uma vez integrado, funciona apropriadamente e entregar o produto. [PA147]


Esta área de processo trata da integração de componentes de produtos em componentes de produtos mais complexos ou em produtos completos. O termo “integração” é utilizado neste sentido em toda esta área de processo e não deve ser confundido com a integração de pessoas ou atividades que possa estar descrita em outra parte do modelo. [PA147.N101]

O escopo desta área de processo é alcançar a completa integração do produto, através da progressiva montagem de componentes de produtos, em uma única etapa ou em etapas incrementais, de acordo com uma seqüência e um procedimento de integração definidos. [PA147.N102]

Um aspecto crítico da integração do produto é o gerenciamento das interfaces internas e externas dos produtos e dos componentes de produtos para assegurar a compatibilidade entre as interfaces. Deverá ser dada atenção ao gerenciamento das interfaces em todo o projeto. [PA147.N103]

Nível de Maturidade: 3, Integração de Produtos 274


A integração de produtos é mais que apenas uma única montagem dos componentes do produto na conclusão do design e fabricação. A integração de produtos pode ser conduzida de forma incremental, utilizando um processo iterativo de montagem de componentes de produtos, sua avaliação e, em seguida, montagem de mais componentes de produtos. Este processo pode começar com análises e simulações (por exemplo, seqüências, protótipos rápidos, protótipo virtuais e protótipos físicos) e progredir de forma estável para uma funcionalidade incremental mais realista até que o produto final seja conseguido. Em cada construção (build) sucessiva, protótipos (virtuais, rápidos ou físicos) são construídos, avaliados, aprovados e reconstruídos com base no conhecimento adquirido no processo de avaliação. O grau de prototipagem virtual versus física exigido depende da funcionalidade das ferramentas de design, da complexidade do produto e dos seus riscos associados. Há uma alta probabilidade de que o produto, integrado desta maneira, passará pela verificação e validação do produto. Para alguns produtos, a última fase de integração ocorrerá quando o produto for implantado no seu ambiente operacional pretendido. [PA147.N104]


Veja a área de processo de Desenvolvimento de Requisitos para obter maiores informações sobre a identificação de requisitos de interfaces. [PA147.R101]

Veja a área de processo de Soluções Técnicas para obter maiores informações sobre como definir as interfaces e o ambiente de integração (quando o ambiente de integração precisar ser desenvolvido). [PA147.R102]

Veja a área de processo de Verificação para obter maiores informações sobre como verificar as interfaces, o ambiente de integração e os componentes de produtos progressivamente montados. [PA147.R103]

Veja a área de processo de Validação para obter maiores informações sobre como executar a validação dos componentes de produtos e do produto integrado. [PA147.R104]

Veja a área de processo de Gerenciamento de Riscos para obter maiores informações sobre a identificação de riscos e o uso de protótipos na mitigação de riscos para a compatibilidade das interfaces e para a integração de componentes de produtos.. [PA147.R105]

Veja a área de processo de Análises de Decisões e Resoluções para obter maiores informações sobre como utilizar um processo formal de avaliação para selecionar a seqüência e procedimentos apropriados de integração e para decidir se o ambiente de integração deverá ser adquirido ou desenvolvido. [PA147.R106]



Veja a área de processo de Gerenciamento de Configurações para obter maiores informações sobre o gerenciamento de mudanças nas definições de interfaces e sobre a distribuição de informações. [PA147.R107]

Veja a área de processo de Gerenciamento de Acordos com Fornecedores para obter maiores informações sobre como adquirir componentes de produtos ou partes do ambiente de integração. [PA147.R108]


SG 1 Preparar para a Integração do Produto [PA147.IG101]

A preparação para a integração do produto é conduzida.

SG 2 Assegurar a Compatibilidade das Interfaces [PA147.IG102]

As interfaces, internas e externas, dos componentes de produtos estão compatíveis.

SG 3 Montar os Componentes de Produtos e Entregar o Produto [PA147.IG103]

Os componentes de produtos verificados são montados e o produto integrado, verificado e validado é entregue.




SG 1 Preparar para a Integração do Produto [PA147.IG101]

SP 1.1 Determinar a Seqüência de IntegraçãoSP 1.2 Estabelecer o Ambiente de Integração do Produto SP 1.3 Estabelecer os Procedimentos e Critérios de Integração do Produto

SG 2 Assegurar a Compatibilidade das Interfaces [PA147.IG102]

SP 2.1 Revisar as Descrições das Interfaces quanto a sua CompletitudeSP 2.2 Gerenciar as Interfaces

SG 3 Montar os Componentes do Produto e Entregar o Produto [PA147.IG103]

SP 3.1 Confirmar que os Componentes do Produto estão Prontos para Integração

SP 3.2 Montar os Componentes do Produto SP 3.3 Avaliar os Componentes do Produto MontadosSP 3.4 Empacotar e Entregar o Produto ou Componente do Produto





GP 3.1 (AB 1) Estabelecer um Processo DefinidoGP 2.2 (AB 2) Planejar o ProcessoGP 2.3 (AB 3) Fornecer RecursosGP 2.4 (AB 4) Atribuir ResponsabilidadesGP 2.5 (AB 5) Treinar as PessoasGP 2.6 (DI 1) Gerenciar ConfiguraçõesGP 2.7 (DI 2) Identificar e Envolver os Stakeholders RelevantesGP 2.8 (DI 3) Monitorar e Controlar o ProcessoGP 3.2 (DI 4) Coletar Informações de MelhoriasGP 2.9 (VE 1) Avaliar Objetivamente a AderênciaGP 2.10 (VE 2) Revisar o Status com o Nível Mais Alto de Gerência


SG 1 Preparar para a Integração do Produto

A preparação para a integração do produto é conduzida. [PA147.IG101]

Preparar para a integração dos componentes do produto envolve estabelecer e manter uma seqüência de integração, o ambiente para se efetuar a integração e os procedimentos de integração. As práticas específicas da meta específica Preparar para a Integração do Produto se baseiam uma na outra da seguinte forma. A primeira prática específica determina a seqüência para a integração do produto e dos componentes do produto. A segunda determina o ambiente que será utilizado para se executar a integração do produto e dos componentes do produto. A terceira desenvolve procedimentos e critérios para a integração do produto e dos componentes do produto. A preparação para a integração começa bem cedo no projeto e a seqüência de integração é desenvolvida paralelamente com as práticas da área de processo de Soluções Técnicas. [PA147.IG101.N101]

SP 1.1 Determinar a Seqüência de Integração

Determinar a seqüência de integração de componentes do produto. [PA147.IG101.SP101]

Os componentes do produto que são integrados podem incluir aqueles que são parte do produto a ser entregue, juntamente com equipamento de teste, software de teste e outros itens de integração como circuitos elétricos. Uma vez que você tenha analisado as alternativas de seqüências de integração da montagem e do teste, selecione a melhor seqüência de integração. [PA147.IG101.SP101.N101]



A seqüência de integração do produto pode servir de base para uma montagem incremental e para a avaliação dos componentes do produto que oferecem uma base livre de problemas para a incorporação de outros componentes de produtos, conforme eles se tornem disponíveis, ou para a prototipação de componentes de produtos de alto risco. [PA147.IG101.SP101.N103]

A seqüência de integração deverá estar em harmonia com a seleção de soluções e o design do produto e dos componentes do produto na área de processo de Soluções Técnicas. [PA147.IG101.SP101.N104]

Veja a área de processo de Análises de Decisões e Resoluções para obter maiores informações sobre o uso de um processo formal de avaliação para selecionar a seqüência apropriada de integração de produtos. [PA147.IG101.SP101.N104.R101]

Veja a área de processo de Gerenciamento de Riscos para obter maiores informações sobre como identificar e tratar riscos associados com a seqüência de integração. [PA147.IG101.SP101.N104.R102]

Veja a área de processo de Gerenciamento de Acordos com Fornecedores para obter maiores informações sobre como fazer a transição de componentes de produtos adquiridos e sobre a necessidade de tratar estes componentes de produtos na seqüência de integração de produtos. [PA147.IG101.SP101.N104.R103]


1. Seqüência de integração de produtos [PA147.IG101.SP101.W101]

2. Justificativa para selecionar ou rejeitar seqüências de integração [PA147.IG101.SP101.W102]

Sub-práticas

1. Identificar os componentes de produtos a serem integrados. [PA147.IG101.SP101.SubP101]

2. Identificar as verificações da integração do produto a serem executadas, utilizando a definição das interfaces entre os componentes de produtos. [PA147.IG101.SP101.SubP102]

3. Identificar seqüências alternativas de integração de componentes de produtos. [PA147.IG101.SP101.SubP103]

Isto pode incluir definir as ferramentas e equipamentos de testes específicos para suportar a integração do produto. [PA147.IG101.SP101.SubP103.N101]

4. Selecionar a melhor seqüência de integração. [PA147.IG101.SP101.SubP105]

5. Periodicamente rever a seqüência de integração do produto e revisá-la, conforme necessário. [PA147.IG101.SP101.SubP106]



Avaliar a seqüência de integração do produto para assegurar que as variações nos cronogramas de produção e entrega não tiveram um impacto adverso na seqüência ou comprometeram os fatores sobre os quais as decisões anteriores foram tomadas. [PA147.IG101.SP101.SubP106.N101]

6. Registrar a justificativa para as decisões tomadas e postecipadas. [PA147.IG101.SP101.SubP107]

SP 1.2 Estabelecer o Ambiente para a Integração do Produto

Estabelecer e manter o ambiente necessário para suportar a integração dos componentes do produto. [PA147.IG101.SP102]

Veja a área de processo de Soluções Técnicas para obter maiores informações sobre decisões de comprar ou fabricar (make-or-buy decisions). [PA147.IG101.SP102.R101]

O ambiente para a integração do produto pode ser adquirido ou desenvolvido. Para estabelecer um ambiente, requisitos para a compra ou desenvolvimento de equipamentos, software ou outros recursos precisarão ser desenvolvidos. Estes requisitos são reunidos quando se implementa os processos associados com a área de processo de Desenvolvimento de Requisitos. O ambiente de integração de produtos pode incluir a reutilização de recursos organizacionais já existentes. A decisão de adquirir ou desenvolver o ambiente de integração do produto é tratada nos processos associados com a área de processo de Soluções Técnicas. [PA147.IG101.SP102.N101]

O ambiente necessário em cada etapa do processo de integração do produto pode incluir equipamento de testes, simuladores (tomando o lugar de componentes de produtos não disponíveis), peças de equipamento real e dispositivos de gravação. [PA147.IG101.SP102.N102]


1. Ambiente verificado para integração de produtos [PA147.IG101.SP102.W101]

2. Documentação de suporte para o ambiente de integração do produto [PA147.IG101.SP102.W102]

Sub-práticas

1. Identificar os requisitos para o ambiente de integração do produto. [PA147.IG101.SP102.SubP101]

2. Identificar critérios e procedimentos de verificação para o ambiente de integração do produto. [PA147.IG101.SP102.SubP102]

3. Decidir entre construir ou comprar o ambiente necessário para a integração do produto. [PA147.IG101.SP102.SubP103]



Veja a área de processo de Gerenciamento de Acordos com Fornecedores para obter maiores informações sobre como adquirir partes do ambiente de integração. [PA147.IG101.SP102.SubP103.R101]

4. Desenvolver um ambiente de integração, se um ambiente adequado não puder ser adquirido. [PA147.IG101.SP102.SubP104]

Para projetos complexos e sem precedentes, o ambiente de integração do produto pode ser um grande desenvolvimento. Em tal caso, ele envolveria um planejamento do projeto, desenvolvimento de requisitos, soluções técnicas, verificação, validação e gerenciamento de riscos. [PA147.IG101.SP102.SubP104.N101]

5. Manter o ambiente de integração do produto durante todo o projeto. [PA147.IG101.SP102.SubP105]

6. Descartar as partes do ambiente que não são mais úteis. [PA147.IG101.SP102.SubP106]

SP 1.3 Estabelecer Procedimentos e Critérios de Integração do Produto

Estabelecer e manter procedimentos e critérios para integração dos componentes do produto. [PA147.IG101.SP103]

Os procedimentos para a integração dos componentes do produto podem incluir coisas como o número de iterações incrementais a serem executadas e detalhes dos testes esperados e outras avaliações a serem efetuadas em cada etapa. [PA147.IG101.SP103.N102]

Os critérios podem indicar se um componente do produto está pronto para a integração ou sua aceitabilidade. [PA147.IG101.SP103.N103]

Procedimentos e critérios para integração de produtos tratam do seguinte: [PA147.IG101.SP103.N105]

Nível de testes dos componentes da versão (build)

Verificação de interfaces

Limites de desvio de desempenho

Requisitos derivados para a montagem e suas interfaces externas

Substituições permitidas de componentes

Parâmetros do ambiente de testes

Limites do custo do teste

Equilíbrio de qualidade/custo para operações de integração

Probabilidade de funcionamento correto

Taxa de entrega e suas variações

Intervalo de tempo do pedido até a entrega



Disponibilidade de pessoal

Disponibilidade dos recursos/linhas/ambientes de integração

Critérios podem ser definidos sobre como os componentes do produto serão verificados e as funções que se espera que eles tenham. Critérios podem ser definidos para como os componentes montados do produto e o produto integrado final será validado e entregue. [PA147.IG101.SP103.N106]

Critérios também podem restringir o grau de simulação permitida para que um componente de produto passe em um teste ou podem restringir o ambiente a ser utilizado para o teste de integração. [PA147.IG101.SP103.N104]


1. Procedimentos de integração de produtos [PA147.IG101.SP103.W101]

2. Critérios de integração de produtos [PA147.IG101.SP103.W102]

Sub-práticas

1. Estabelecer e manter os procedimentos de integração do produto para os componentes do produto. [PA147.IG101.SP103.SubP101]

2. Estabelecer e manter critérios para a integração e avaliação dos componentes do produto. [PA147.IG101.SP103.SubP102]

3. Estabelecer e manter critérios para a validação e entrega do produto integrado. [PA147.IG101.SP103.SubP103]

SG 2 Assegurar Compatibilidade das Interfaces

As interfaces, internas e externas, dos componentes do produto são compatíveis. [PA147.IG102]

Muitos problemas de integração de produtos surgem de aspectos desconhecidos ou fora de controle de interfaces internas e externas. Um gerenciamento eficiente dos requisitos de interfaces de componentes de produtos, especificações e designs ajuda a assegurar que as interfaces implementadas estarão completas e compatíveis. [PA147.IG102.N101]

SP 2.1 Revisar as Descrições de Interfaces quanto a sua Completitude

Revisar as descrições de interfaces quanto a sua cobertura e completitude. [PA147.IG102.SP101]

As interfaces deverão incluir, além das interfaces dos componentes do produto, todas as interfaces com o ambiente de integração do produto. [PA147.IG102.SP101.N101]




1. Categorias de interfaces [PA147.IG102.SP101.W101]

2. Lista de interfaces por categoria [PA147.IG102.SP101.W102]

3. Mapeamento das interfaces com os componentes do produto e com o ambiente de integração do produto [PA147.IG102.SP101.W103]

Sub-práticas

1. Revisar os dados de interfaces quanto à completitude e assegurar completa cobertura de todas as interfaces. [PA147.IG102.SP101.SubP101]

Considerar todos os componentes do produto e preparar uma tabela de relacionamentos. As interfaces são normalmente classificadas em três classes principais: ambientais, físicas e funcionais. As categorias comuns para estas classes incluem as seguintes: mecânicas, fluídas, sonoras, elétricas, climáticas, eletromagnéticas, térmicas, mensagens e homem-máquina ou interface humana. [PA147.IG102.SP101.SubP101.N101]


Na categoria mensagem para software, as interfaces incluem: [PA147.IG102.SP101.SubP101.N101.AMP101]

Origem

Destino

Estímulo

Protocolos e características de dados


Para componentes mecânicos ou eletrônicos, os dados de interfaces deverão incluir: [PA147.IG102.SP101.SubP101.N101.AMP102]

Interfaces mecânicas (por exemplo, peso e tamanho, centro de gravidade, distanciamento das partes na operação, espaço exigido para manutenção, ligações fixas, ligações móveis, choques e vibrações recebidas da estrutura de suporte)

Interfaces de ruído (por exemplo, ruído transmitido pela estrutura, ruído transmitido através do ar, acústica)

Interfaces climáticas (por exemplo, temperatura, umidade, pressão, salinidade)

Interfaces térmicas (por exemplo, dissipação de calor, transmissão de calor para a estrutura de suporte, características do ar condicionado)

Interfaces fluidas (por exemplo, água fresca entrando ou saindo, água do mar entrando ou saindo para um produto naval / costeiro, ar condicionado, ar comprimido, nitrogênio, combustível, óleo lubrificante, saída de gás)



Interfaces elétricas (por exemplo, consumo de suprimento de energia pela rede com valores transientes e de pico; controle não sensitivo de sinais para suprimento de energia, comunicações, etc; sinais sensitivos [links analógicos]; sinal de perturbação [microondas, etc]; sinal do solo em conformidade com o padrão TEMPEST)

Interfaces eletromagnéticas (por exemplo, campo magnético, links de rádio e radar, guias de ondas de links de banda ótica, fibras óticas e coaxiais)

Interfaces homem-máquina (por exemplo, síntese de áudio ou voz, reconhecimento de áudio ou voz, display [dial analógico, tela de TV ou display de cristal líquido, luzes indicativas emitindo diodos], controles manuais [pedais, joystick, bola, chaves, botões, touch screen])

2. Assegurar que os componentes do produto e interfaces estão marcados para assegurar uma fácil e correta conexão com o componente de produto. [PA147.IG102.SP101.SubP102]

3. Periodicamente revisar a adequação das descrições de interfaces. [PA147.IG102.SP101.SubP103]

Uma vez estabelecidas, as descrições de interfaces devem ser periodicamente revisadas para assegurar que não há desvio entre as descrições existentes e os produtos que estão sendo desenvolvidos, processados, produzidos ou comprados. [PA147.IG102.SP101.SubP103.N101]

SP 2.2 Gerenciar Interfaces

Gerenciar as definições de interfaces internas e externas, os designs e as mudanças em produtos e componentes de produtos. [PA147.IG102.SP102]

Os requisitos de interface dirigem o desenvolvimento das interfaces necessárias para integrar componentes de produtos. O gerenciamento das interfaces do produto e dos componentes do produto começa bem cedo no desenvolvimento do produto. As definições e designs para as interfaces afetam não somente os componentes do produto e sistemas externos, mas também afetam os ambientes de verificação e validação. [PA147.IG102.SP102.N104]

Veja a área de processo de Desenvolvimento de Requisitos para obter maiores informações sobre requisitos de interfaces. [PA147.IG102.SP102.N104.R101]

Veja a área de processo de Soluções Técnicas para obter maiores informações sobre o design de interfaces entre componentes de produtos. [PA147.IG102.SP102.N104.R102]



Veja a área de processo de Gerenciamento de Requisitos para obter maiores informações sobre como gerenciar as mudanças nos requisitos de interfaces. [PA147.IG102.SP102.N104.R103]

Veja a área de processo de Gerenciamento de Configurações para obter maiores informações sobre como distribuir mudanças nas descrições (especificações) de interfaces, de maneira que todos possam saber o atual estado das interfaces. [PA147.IG102.SP102.N104.R104]

O gerenciamento das interfaces inclui a manutenção da consistência das interfaces durante toda a vida do produto e a resolução de conflitos, não conformidades e questões relativas a mudanças. [PA147.IG102.SP102.N101]

As interfaces deverão incluir, além das interfaces de componentes do produto, todas as interfaces com o ambiente, bem como outros ambientes de verificação, validação, operação e suporte. [PA147.IG102.SP102.N102]

As mudanças na interface são documentadas, mantidas e estão prontamente acessíveis. [PA147.IG102.SP102.N103]


1. Tabela de relacionamentos entre os componentes do produto e o ambiente externo (por exemplo, suprimento mestre de energia, produto de conexão, sistema de bus do computador) [PA147.IG102.SP102.W101]

2. Tabela de relacionamentos entre os diferentes componentes do produto [PA147.IG102.SP102.W102]

3. Lista de interfaces aprovadas definidas para cada par de componentes do produto, quando aplicável [PA147.IG102.SP102.W103]

4. Relatórios das reuniões do grupo de trabalho de controle de interfaces [PA147.IG102.SP102.W104]

5. Itens de ação para atualizar interfaces [PA147.IG102.SP102.W105]

6. Interface de programas de aplicação (Application program interface - API) [PA147.IG102.SP102.W106]

7. Descrição ou acordo de interfaces atualizado [PA147.IG102.SP102.W107]

Sub-práticas

1. Assegurar a compatibilidade das interfaces durante toda a vida do produto. [PA147.IG102.SP102.SubP101]

2. Resolver conflitos, não conformidades e questões de mudanças. [PA147.IG102.SP102.SubP102]



3. Manter um repositório de dados de interfaces acessível a todos os participantes do projeto. [PA147.IG102.SP102.SubP103]

Um repositório único para os dados de interface oferece um mecanismo para assegurar que todos sabem onde estão os dados atuais de interfaces e podem acessá-los para uso. [PA147.IG102.SP102.SubP103.N101]

SG 3 Montar os Componentes do Produto e Entregar o Produto

Os componentes do produto verificados são montados e o produto integrado, verificado e validado é entregue. [PA147.IG103]

A integração dos componentes do produto se dá de acordo com a seqüência de integração do produto e os procedimentos disponíveis. Antes da integração, cada componente do produto deverá ser confirmado como estando em conformidade com seus requisitos de interface. Os componentes do produto são montados em componentes do produto maiores e mais complexos. Estes componentes do produto montados são verificados quanto a sua correta interoperação. Este processo continua até que a integração do produto esteja completa. Se, durante este processo, forem identificados problemas, o problema deverá ser documentado e um processo de ação corretiva iniciado. [PA147.IG103.N101]

Assegurar que a montagem dos componentes do produto em componentes do produto maiores e mais complexos é conduzida de acordo com a seqüência de integração do produto e os procedimentos disponíveis. A imediata recepção dos componentes do produto necessários e o envolvimento das pessoas certas contribui para a integração bem sucedida dos componentes do produto que compõem o produto. [PA147.IG103.N102]

SP 3.1 Confirmar que os Componentes do Produto estão Prontos para a Integração

Confirmar, antes da montagem, que cada componente do produto exigido para montar o produto foi apropriadamente identificado, funciona de acordo com sua descrição e que as interfaces do componente do produto estão em conformidade com as descrições de interfaces. [PA147.IG103.SP101]

Veja a área de processo de Verificação para obter maiores informações sobre como verificar os componentes de produtos. [PA147.IG103.SP101.R101]

Veja a área de processo de Soluções Técnicas para obter maiores informações sobre testes de unidade de componentes de produtos. [PA147.IG103.SP101.R102]



O objetivo desta prática específica é assegurar que o componente do produto apropriadamente identificado, que atende a sua descrição, pode realmente ser montado de acordo com a seqüência de integração do produto e os procedimentos disponíveis. Os componentes do produto são verificados quanto à quantidade, danos óbvios e consistência entre o componente do produto e as descrições de interfaces. [PA147.IG103.SP101.N101]

Os que conduzem a integração do produto são, em última análise, responsáveis por verificar se tudo está certo com os componentes do produto antes da montagem. [PA147.IG103.SP101.N102]


1. Documentos de aceitação para os componentes do produto recebidos [PA147.IG103.SP101.W101]

2. Recibos de entrega [PA147.IG103.SP101.W102]

3. Listas de pacotes verificados [PA147.IG103.SP101.W103]

4. Relatórios de exceção [PA147.IG103.SP101.W104]

5. Dispensas [PA147.IG103.SP101.W105]

Sub-práticas

1. Rastrear o status de todos os componentes do produto, a partir do momento em que ficam disponíveis para integração. [PA147.IG103.SP101.SubP101]

2. Assegurar que os componentes do produto são entregues no ambiente de integração do produto em concordância com a seqüência de integração do produto e procedimentos disponíveis. [PA147.IG103.SP101.SubP102]

3. Confirmar o recebimento de cada componente do produto apropriadamente identificado. [PA147.IG103.SP101.SubP103]

4. Assegurar que cada componente do produto recebido atende sua descrição. [PA147.IG103.SP101.SubP104]

5. Verificar o status da configuração contra a configuração esperada. [PA147.IG103.SP101.SubP105]

6. Executar uma pré-verificação (por exemplo, por inspeção visual e utilizando medidas básicas) de todas as interfaces físicas, antes de conectar os componentes do produto. [PA147.IG103.SP101.SubP106]

SP 3.2 Montar os Componentes do Produto

Montar os componentes do produto de acordo com a seqüência de integração e procedimentos disponíveis. [PA147.IG103.SP102]



Veja a área de processo de Verificação para obter maiores informações sobre como verificar os componentes de produtos montados. [PA147.IG103.SP102.R101]

Veja a área de processo de Validação para obter maiores informações sobre como validar os componentes de produtos montados. [PA147.IG103.SP102.R102]

(Para os usuários da representação contínua, esta é uma prática específica da capacitação de nível 1. Os processos de integração de produtos nos níveis de capacitação 1 e 2 podem não incluir procedimentos e critérios, que são criados na prática específica Estabelecer Procedimentos e Critérios para Integração de Produtos na capacitação nível 3. Quando não há procedimentos ou critérios estabelecidos, utilize a seqüência estabelecida na prática específica Determinar a Seqüência de Integração para cumprir o desempenho da capacitação de nível 1). [PA147.IG103.SP102.N102]

As atividades de montagem desta prática específica e as atividades de avaliação da próxima prática específica são conduzidas de forma iterativa, desde os componentes iniciais do produto, passando por uma série de montagens de componentes do produto intermediários até o produto como um todo. [PA147.IG103.SP102.N101]


1. Produto ou componentes do produto montados [PA147.IG103.SP102.W101]

Sub-práticas

1. Assegurar que o ambiente de integração do produto está pronto. [PA147.IG103.SP102.SubP101]

2. Assegurar que a seqüência de montagem está sendo executada de forma apropriada. [PA147.IG103.SP102.SubP102]

Registrar todas as informações apropriadas (por exemplo, status da configuração, números de série dos componentes do produto, tipos e datas de calibração dos instrumentos de medição). [PA147.IG103.SP102.SubP102.N101]

3. Revisar a seqüência de integração do produto e procedimentos disponíveis, conforme apropriado. [PA147.IG103.SP102.SubP104]

SP 3.3 Avaliar os Componentes do Produto Montados

Avaliar os componentes do produto montados com relação à compatibilidade da interface. [PA147.IG103.SP103]



Esta avaliação envolve o exame e o teste dos componentes do produto montados com relação ao desempenho, adequação e prontidão utilizando os procedimentos e ambiente disponíveis. Isto é feito, conforme apropriado, em diferentes etapas da montagem de componentes do produto, conforme identificado na seqüência de integração do produto e procedimentos disponíveis. A seqüência de integração do produto e procedimentos disponíveis podem definir uma seqüência de integração e avaliação mais refinada do que a que pode ser prevista apenas examinando a arquitetura do produto. Por exemplo, se uma montagem de componentes do produto é composta de quatro componentes do produto menos complexos, a seqüência de integração não necessariamente fará uma integração e avaliação simultânea das quatro unidades como se fossem uma. Em vez disso, as quatro unidades menos complexas podem ser integradas progressivamente, uma de cada vez, com uma avaliação após cada operação de montagem antes de chegar ao componente do produto mais complexo que atende a especificação da arquitetura do produto. Alternativamente, a seqüência de integração e procedimentos disponíveis poderiam determinar que somente uma avaliação final seria a melhor forma de fazer o serviço. [PA147.IG103.SP103.N101]


1. Relatórios de exceção [PA147.IG103.SP103.W102]

2. Relatórios de avaliação de interfaces [PA147.IG103.SP103.W103]

3. Relatórios de resumo de integração do produto [PA147.IG103.SP103.W104]

Sub-práticas

1. Conduzir a avaliação dos componentes do produto montados, seguindo a seqüência de integração do produto e procedimentos disponíveis. [PA147.IG103.SP103.SubP101]

2. Registrar os resultados da avaliação. [PA147.IG103.SP103.SubP102]

Exemplos de resultados incluem: [PA147.IG103.SP103.SubP102.N101]

Qualquer adaptação necessária nos procedimentos de integração

Qualquer mudança na configuração do produto (peças de reposição, novo release)

Avaliação de desvios de procedimentos

SP 3.4 Empacotar e Entregar o Produto ou Componente do Produto

Empacotar o produto ou componente do produto montado e entregá-lo ao cliente apropriado. [PA147.IG103.SP104]



Veja a área de processo de Verificação para obter maiores informações sobre como verificar o produto ou uma montagem de componentes de produtos antes de empacotá-los. [PA147.IG103.SP104.R101]

Veja a área de processo de Validação para obter maiores informações sobre como validar o produto ou uma montagem de componentes de produtos antes de empacotá-los. [PA147.IG103.SP104.R102]

Os requisitos de empacotamento para alguns produtos podem ser tratados em suas especificações e critérios de verificação. Isto é especialmente importante quando os itens são armazenados e transportados pelo cliente. Em tais casos, pode haver uma série de condições ambientais e de stress definidas para o pacote. Em outras circunstâncias, fatores como os seguintes podem se tornar importantes: [PA147.IG103.SP104.N101]

Economia e facilidade de transporte (por exemplo, uso de containers)

Comunicação (por exemplo, utilizando filmes plásticos)

Facilidade e segurança no desempacotamento (por exemplo, bordas afiadas, a força da cola utilizada, cuidados com crianças, o cuidado ambiental no material de empacotamento, peso)

O ajuste necessário para encaixar os componentes do produto na fábrica poderia ser diferente do necessário para encaixar os componentes do produto quando instalados no local operacional. Neste caso, o registro de log do produto para o cliente deverá ser utilizado para registrar tais parâmetros específicos. [PA147.IG103.SP104.N102]


1. Produto ou componentes do produto empacotados [PA147.IG103.SP104.W101]

2. Documentação de entrega [PA147.IG103.SP104.W102]

Sub-práticas

1. Revisar os requisitos, design, produto, resultados de verificação e documentação para assegurar que as questões que afetam o empacotamento e a entrega do produto foram identificadas e resolvidas. [PA147.IG103.SP104.SubP101]

2. Usar métodos eficientes para empacotar e entregar o produto montado. [PA147.IG103.SP104.SubP102]




Exemplos de métodos de empacotamento e entrega de software incluem: [PA147.IG103.SP104.SubP102.AMP101]

Fita magnética

Disquetes

Documentos impressos

Compact disks (CDs)

Outros tipos de distribuição eletrônica como a Internet

3. Satisfazer os requisitos e padrões aplicáveis para o empacotamento e entrega do produto. [PA147.IG103.SP104.SubP103]


Exemplos de requisitos e padrões para empacotamento e entrega do software incluem: [PA147.IG103.SP104.SubP103.AMP101]

Tipo de mídia de armazenamento e entrega

Custódia das cópias mestre e backup do software

Documentação exigida

Copyrights

Licenças provisionais

Proteção do software


Exemplos de requisitos e padrões incluem aqueles referentes a segurança, o ambiente, a proteção e a portabilidade. [PA147.IG103.SP104.SubP103.AMP102]

4. Preparar o local operacional para a instalação do produto. [PA147.IG103.SP104.SubP104]

Preparar o local operacional pode ser responsabilidade do cliente ou usuários finais. [PA147.IG103.SP104.SubP104.N101]

5. Entregar o produto e documentação relacionada e confirmar o recebimento. [PA147.IG103.SP104.SubP105]

6. Instalar o produto no local operacional e confirmar a correta operação. [PA147.IG103.SP104.SubP106]

Instalar o produto pode ser responsabilidade do cliente ou usuários finais. Em algumas circunstâncias, muito pouco pode precisar ser feito para confirmar a correta operação. Em outras circunstâncias, a verificação final do produto integrado ocorre no local operacional. [PA147.IG103.SP104.SubP106.N101]





Compromissos


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

Elaboração:

Esta política estabelece as expectativas organizacionais para o desenvolvimento das seqüências de integração do produto, procedimentos e um ambiente, assegurando compatibilidade de interfaces entre componentes do produto; a montagem dos componentes do produto e a entrega do produto e componentes do produto. [PA147.EL101]

Habilitações


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


Estabelecer e manter o plano para execução do processo de integração do produto. [GP104]

Elaboração:

Este plano para executar o processo de integração do produto trata o planejamento abrangente para todas as práticas específicas desta área de processo, da preparação para a integração do produto até a entrega do produto final. [PA147.EL102]




Fornecer recursos adequados para executar o processo de integração do produto, desenvolver os produtos de trabalho e fornecer os serviços do processo. [GP105]

Elaboração:

A coordenação das interfaces de componentes do produto pode ser conseguida com um Grupo de Trabalho de Controle de Interfaces, consistindo de pessoas que representam interfaces externas e internas. Tais grupos podem ser utilizados para elicitar as necessidades para o desenvolvimento de requisitos de interface. [PA147.EL115]

Recursos especiais podem ser necessários para montar e entregar o produto. Quando necessário, os recursos exigidos pelas atividades da área de processo de Integração de Produtos são desenvolvidos ou comprados. [PA147.EL116]



Ferramentas de análises

Ferramentas de simulação

Ferramentas de gerenciamento de interfaces

Ferramentas de montagem (por exemplo, compiladores, arquivos de construção, ferramentas de combinação, suportes e itens fixos)


Atribuir responsabilidades e autoridade para executar o processo, desenvolver os produtos de trabalho e fornecer os serviços do processo de integração do produto. [GP106]


Treinar as pessoas para executar e suportar o processo de integração do produto, conforme necessário. [GP107]



Elaboração:



Procedimentos e critérios de integração do produto

Recursos da organização para a integração e montagem

Métodos de montagem

Padrões de empacotamento

Implementações


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

Elaboração:


Documentos de aceitação para os componentes de produtos recebidos

Produtos e componentes de produtos montados e avaliados

Seqüência de integração de produtos


Descrição ou acordo de interfaces atualizados


Identificar e envolver os stakeholders relevantes do processo de integração do produto, conforme planejado. [GP124]

Elaboração:

Selecionar stakeholders relevantes entre clientes, usuários finais, desenvolvedores, produtores, testadores, fornecedores, pessoal de marketing, de manutenção e de descarte e outros que possam ser afetados ou possam afetar o produto, bem como o processo. [PA147.EL120]




Revisar as descrições das interfaces com relação a sua completitude

Estabelecer a seqüência de integração do produto

Estabelecer os procedimentos e critérios de integração do produto

Montar e entregar o produto e os componentes do produto

Comunicar os resultados após a avaliação

Comunicar os novos e eficientes processos da integração do produto para dar às pessoas afetadas a oportunidade de melhorar seu desempenho


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

Elaboração:


Perfil de integração de componentes do produto (por exemplo, montagens de componentes do produto planejadas e executadas e número de exceções encontradas)

Tendências de problemas relatados na avaliação da integração (por exemplo, quantidade de ocorrências abertas e fechadas)

Duração dos problemas relatados na avaliação da integração (por exemplo, por quanto tempo cada problema relatado ficou aberto)


Coletar produtos de trabalho, medidas, resultados de medições e informações de melhorias derivadas do planejamento e execução do processo de integração do produto para suportar o uso futuro e a melhoria dos processos e ativos de processos da organização. [GP117]



Verificações


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

Elaboração:


Estabelecer e manter uma seqüência de integração do produto

Assegurar a compatibilidade das interfaces

Montar os componentes do produto e entregar o produto


Seqüência de integração do produto


Documentos de aceitação dos componentes de produtos recebidos

Produto e componentes do produto montados


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



VERIFICAÇÃO


Objetivo

O objetivo da Verificação (Verification) é assegurar que os produtos de trabalho selecionados atenderão seus requisitos específicos. [PA150]


A área de processo de Verificação envolve: a preparação da verificação, a execução da verificação e a identificação das ações corretivas. [PA150.N101]

A Verificação inclui a verificação do produto final e dos produtos de trabalho intermediários contra todos os requisitos selecionados, incluindo os requisitos de clientes, de produtos e de componentes do produto. [PA150.N102]

A Verificação é naturalmente um processo incremental, porque ocorre durante todo o desenvolvimento do produto e dos produtos de trabalho, começando com a verificação dos requisitos, em seguida passando para a verificação dos produtos de trabalho em desenvolvimento e culminando na verificação do produto completo. [PA150.N103]

As práticas específicas desta área de processo se baseiam umas nas outras da seguinte maneira: a prática específica Selecionar Produtos de Trabalho para Verificação permite a identificação dos produtos de trabalho a serem verificados, os métodos a serem utilizados para executar a verificação e os requisitos a serem satisfeitos por cada produto de trabalho selecionado. A prática específica Estabelecer o Ambiente de Verificação permite a definição do ambiente que será usado para se executar a verificação. A prática específica Estabelecer os Procedimentos e Critérios da Verificação, por sua vez, possibilita o desenvolvimento de procedimentos e critérios de verificação que estejam alinhados com os produtos de trabalho selecionados e com os requisitos, métodos e características do ambiente de verificação. A prática específica Executar a Verificação conduz a verificação de acordo com os métodos, procedimentos e critérios disponíveis. [PA150.N110]

A verificação dos produtos de trabalho aumenta substancialmente a probabilidade do produto atender os requisitos do cliente, do produto e dos componentes do produto. [PA150.N104]

Nível de Maturidade: 3, Verificação296


As áreas de processos de Verificação e Validação são semelhantes, mas tratam de assuntos diferentes. A validação demonstra que o produto, da maneira como está sendo fornecido (ou da maneira que será fornecido), atenderá o uso pretendido, enquanto que a verificação observa se o produto de trabalho reflete de forma adequada os seus requisitos específicos. Em outras palavras, a verificação assegura que “você construiu da forma correta”, enquanto que a validação assegura que “você construiu a coisa certa”. [PA150.N105]

As revisões por pares (Peer reviews) são uma parte importante da verificação e são um mecanismo comprovado para a eficaz remoção de defeitos. Uma importante conseqüência disso é o desenvolvimento um melhor entendimento dos produtos de trabalho e dos processos que os produzem, de maneira que os defeitos possam ser evitados e as oportunidades de melhoria de processos possam ser identificadas. [PA150.N106]

As revisões por pares consistem de um exame metódico dos produtos de trabalho por pares (ou parceiros) dos envolvidos na produção, para identificar defeitos e outras mudanças que sejam necessárias. [PA150.N107]

Exemplos de métodos de revisões por pares incluem: [PA150.N109]

Inspeções

Walkthroughs estruturados


Veja a área de processo de Validação para obter maiores informações sobre como confirmar que o produto ou os componentes do produto atenderão ao seu uso pretendido quando colocados no seu ambiente pretendido. [PA150.R102]

Veja a área de processo de Desenvolvimento de Requisitos para obter maiores informações sobre a geração e desenvolvimento de requisitos de clientes, produtos e componentes de produtos. [PA150.R103]

Veja a área de processos de Gerenciamento de Requisitos para obter maiores informações sobre o gerenciamento de requisitos. [PA150.R104]


SG 1 Preparar para Verificação [PA150.IG101]

É feita a preparação para a verificação.

Nível de Maturidade: 3, Verificação 297


SG 2 Executar Revisões por Pares [PA150.IG102]

São executadas revisões por pares em produtos de trabalho selecionados.

SG 3 Verificar Produtos de Trabalho Selecionados [PA150.IG103]

Produtos de trabalho selecionados são verificados contra seus requisitos específicos.




SG 1 Preparar para Verificação [PA150.IG101]

SP 1.1 Selecionar Produtos de Trabalho para VerificaçãoSP 1.2 Estabelecer o Ambiente de VerificaçãoSP 1.3 Estabelecer os Procedimentos e Critérios de Verificação

SG 2 Executar Revisões por Pares [PA150.IG102]

SP 2.1 Preparar para as Revisões por ParesSP 2.2 Conduzir as Revisões por ParesSP 2.3 Analisar os Dados das Revisões por Pares

SG 3 Verificar Produtos de Trabalho Selecionados [PA150.IG103]

SP 3.1 Executar a VerificaçãoSP 3.2 Analisar os Resultados da Verificação e Identificar Ações Corretivas


GP 2.1 (CO 1) Estabelecer uma Política OrganizacionalGP 3.1 (AB 1) Estabelecer um Processo DefinidoGP 2.2 (AB 2) Planejar o ProcessoGP 2.3 (AB 3) Fornecer RecursosGP 2.4 (AB 4) Atribuir ResponsabilidadesGP 2.5 (AB 5) Treinar as PessoasGP 2.6 (DI 1) Gerenciar as ConfiguraçõesGP 2.7 (DI 2) Identificar e Envolver os Stakeholders RelevantesGP 2.8 (DI 3) Monitorar e Controlar o ProcessoGP 3.2 (DI 4) Coletar Informações de MelhoriasGP 2.9 (VE 1) Avaliar Objetivamente a AderênciaGP 2.10 (VE 2) Revisar a Situação com a Gerência de Nível Mais Alto


SG 1 Preparar para Verificação

A preparação para a verificação é executada. [PA150.IG101]



A preparação prévia é necessária para assegurar que os itens necessários para a verificação estão incluídos nos requisitos de produtos e componentes de produtos, no design, nos planos de desenvolvimento e cronogramas. A verificação inclui a seleção, inspeção, teste, análise e demonstração dos produtos de trabalho. [PA150.IG101.N101]

Os métodos de verificação incluem, embora não estejam limitados a, inspeções, revisões por pares, auditorias, walkthroughs, análises, simulações, testes e demonstrações. [PA150.IG101.N102]

A preparação também inclui a definição de ferramentas de suporte, equipamentos e software para testes, simulações, protótipos e outros itens auxiliares. [PA150.IG101.N103]

SP 1.1 Selecionar Produtos de Trabalho para Verificação

Selecionar os produtos de trabalho a serem verificados e os métodos de verificação que serão usados para cada um deles. [PA150.IG101.SP101]

Os produtos de trabalho são selecionados com base na sua contribuição para o atendimento dos objetivos e requisitos do projeto e na sua participação nos riscos do projeto. [PA150.IG101.SP101.N104]

Os produtos de trabalho a serem verificados podem incluir os que estão associados com a manutenção, o treinamento e serviços de suporte. Os requisitos de verificação dos produtos de trabalho estão ligados aos métodos de verificação. Os métodos de verificação utilizam uma abordagem técnica para a verificação dos produtos de trabalho e abordagens específicas para verificar se produtos de trabalho específicos atendem os seus requisitos [PA150.IG101.SP101.N102]


Exemplos de métodos de verificação incluem: [PA150.IG101.SP101.N102.AMP101]

Teste de cobertura de caminhos

Testes de carregamento, stress e desempenho

Testes baseados em tabelas de decisões

Testes baseados em decomposição funcional

Reutilização de casos de testes

Testes de aceitação



A seleção dos métodos de verificação normalmente começa com o envolvimento na definição dos requisitos de produtos e de componentes de produtos, para assegurar que estes requisitos são verificáveis. Uma nova verificação deverá ser prevista pelos métodos de verificação para assegurar que qualquer retrabalho executado nos produtos de trabalho não causou defeitos inesperados. [PA150.IG101.SP101.N103]


1. Listas de produtos de trabalho selecionados para verificação [PA150.IG101.SP101.W101]

2. Métodos de verificação para cada produto de trabalho selecionado [PA150.IG101.SP101.W102]

Sub-práticas

1. Identificar produtos de trabalho para verificação. [PA150.IG101.SP101.SubP102]

2. Identificar os requisitos a serem atendidos por cada produto de trabalho selecionado. [PA150.IG101.SP101.SubP103]

Veja a prática específica Manter Rastreabilidade Bidirecional de Requisitos na área de processo de Gerenciamento de Requisitos para obter ajuda sobre como identificar os requisitos de cada produto de trabalho. [PA150.IG101.SP101.SubP103.R101]

3. Identificar os métodos de verificação que estão disponíveis para uso. [PA150.IG101.SP101.SubP104]

4. Definir os métodos de verificação a serem utilizados para cada produto de trabalho selecionado. [PA150.IG101.SP101.SubP105]

5. Submeter a identificação dos produtos de trabalho a serem verificados, os requisitos a serem atendidos e os métodos a serem utilizados para a integração com o plano de projeto. [PA150.IG101.SP101.SubP106]

Veja a área de processo de Planejamento do Projeto para obter informações sobre a coordenação com o planejamento do projeto. [PA150.IG101.SP101.SubP106.R101]

SP 1.2 Estabelecer o Ambiente de Verificação

Estabelecer e manter o ambiente necessário para suportar a verificação. [PA150.IG101.SP102]



Um ambiente deve ser estabelecido para possibilitar a execução da verificação. O ambiente de verificação pode ser adquirido, desenvolvido, reutilizado, modificado ou uma combinação das alternativas anteriores, dependendo das necessidades do projeto. [PA150.IG101.SP102.N101]

O tipo de ambiente necessário dependerá dos produtos de trabalho selecionados para a verificação e dos métodos de verificação utilizados. Uma revisão por pares pode exigir pouco mais que alguns materiais, revisores e uma sala. Um teste de produto pode exigir a utilização de simuladores, emuladores, geradores de cenários, ferramentas de redução de dados, controles ambientais e interfaces como outros sistemas. [PA150.IG101.SP102.N102]


1. Ambiente de verificação [PA150.IG101.SP102.W102]

Sub-práticas

1. Identificar os requisitos do ambiente de verificação. [PA150.IG101.SP102.SubP101]

2. Identificar os recursos de verificação disponíveis para reutilização e modificação. [PA150.IG101.SP102.SubP102]

3. Identificar equipamentos e ferramentas de verificação. [PA150.IG101.SP102.SubP103]

4. Adquirir equipamento de suporte e ambiente de verificação, tais como equipamentos e software de teste. [PA150.IG101.SP102.SubP104]

SP 1.3 Estabelecer Procedimentos e Critérios de Verificação

Estabelecer e manter os procedimentos e critérios de verificação para os produtos de trabalho selecionados. [PA150.IG101.SP103]

Os critérios de verificação são definidos para assegurar que os produtos de trabalho atendem seus requisitos. [PA150.IG101.SP103.N101]



Exemplos de fontes de critérios de verificação incluem: [PA150.IG101.SP103.N102]

Requisitos de produtos e de componentes de produtos

Padrões

Políticas organizacionais

Tipos de testes

Parâmetros de testes

Parâmetros de equilíbrio entre a qualidade e os custos dos testes

Tipos de produtos de trabalho


1. Procedimentos de verificação [PA150.IG101.SP103.W101]

2. Critérios de verificação [PA150.IG101.SP103.W102]

Sub-práticas

1. Gerar o conjunto de procedimentos de verificação abrangentes e integrados para os produtos de trabalho e produtos comerciais prontos, conforme necessário. [PA150.IG101.SP103.SubP101]

2. Desenvolver e refinar os critérios de verificação, quando necessário. [PA150.IG101.SP103.SubP102]

3. Identificar os resultados esperados, possíveis tolerâncias permitidas na observação e outros critérios para atender os requisitos. [PA150.IG101.SP103.SubP104]

4. Identificar quaisquer equipamentos e componentes de ambiente necessários para suportar a verificação. [PA150.IG101.SP103.SubP105]

SG 2 Executar Revisões por Pares

Revisões por pares são executadas em produtos de trabalho selecionados. [PA150.IG102]

As revisões por pares envolvem um exame metódico dos produtos de trabalho por pares dos envolvidos na produção, para identificar defeitos a serem removidos e recomendar outras modificações que sejam necessárias. [PA150.IG102.N101]

A revisão por pares é um importante e eficiente método de engenharia implementado através de inspeções, walkthroughs estruturados ou uma série de outros métodos acadêmicos de revisão. [PA150.IG102.N102]



As revisões por pares são basicamente aplicadas aos produtos de trabalho desenvolvidos pelos projetos, mas também podem ser aplicadas a outros produtos de trabalho, como documentação e material de treinamento que são normalmente desenvolvidos por grupos de suporte. [PA150.IG102.N103]

SP 2.1 Preparar para as Revisões por Pares

Preparar para as revisões por pares dos produtos de trabalho selecionados. [PA150.IG102.SP101]

As atividades de preparação para as revisões por pares normalmente incluem a identificação do pessoal que será convidado para participar da revisão por pares de cada produto de trabalho, identificar os revisores chave que devem participar da revisão por pares, preparar e atualizar os materiais que serão utilizados durante as revisões por pares (como checklists e critérios de revisão) e criar um cronograma para as revisões por pares. [PA150.IG102.SP101.N101]


1. Cronograma da revisão por pares [PA150.IG102.SP101.W101]

2. Checklist da revisão por pares [PA150.IG102.SP101.W102]

3. Critérios de entrada e saída para produtos de trabalho [PA150.IG102.SP101.W103]

4. Critérios para requisição de uma nova revisão por pares [PA150.IG102.SP101.W104]

5. Material de treinamento da revisão por pares [PA150.IG102.SP101.W105]

6. Produtos de trabalho selecionados para ser revisados [PA150.IG102.SP101.W106]

Sub-práticas

1. Determinar que tipo de revisão por pares será executada. [PA150.IG102.SP101.SubP101]

Exemplos de tipos de revisões por pares incluem: [PA150.IG102.SP101.SubP101.N101]

Inspeções

Walkthroughs estruturados

Revisões ativas

2. Definir requisitos para a coleta de dados durante a revisão por pares. [PA150.IG102.SP101.SubP102]



Veja a área de processo de Medições e Análises para obter informações sobre a identificação e coleta de dados. [PA150.IG102.SP101.SubP102.R101]

3. Estabelecer e manter os critérios de entrada e saída para a revisão por pares. [PA150.IG102.SP101.SubP103]

4. Estabelecer e manter os critérios para requisitar uma nova revisão por pares. [PA150.IG102.SP101.SubP104]

5. Estabelecer e manter checklists para assegurar que os produtos de trabalho sejam revisados de forma consistente. [PA150.IG102.SP101.SubP105]

Exemplos de itens tratados pelos checklists incluem: [PA150.IG102.SP101.SubP105.N102]

Regras de construção

Instruções de design

Integridade

Correção


Tipos comuns de defeitos

Os checklists são modificados, conforme necessário, para tratar o tipo específico de produto de trabalho e de revisão por pares. Os pares dos desenvolvedores dos checklists e potenciais usuários revisam os checklists. [PA150.IG102.SP101.SubP105.N101]

6. Desenvolver um cronograma detalhado das revisões por pares, incluindo as datas de treinamento e o momento em que os materiais para as revisões por pares estarão disponíveis. [PA150.IG102.SP101.SubP106]

7. Assegurar que o produto de trabalho satisfaz os critérios de entrada na revisão por pares antes da sua distribuição. [PA150.IG102.SP101.SubP107]

8. Distribuir, para os participantes da revisão, os produtos de trabalho a serem revisados e as informações relacionadas, com antecedência suficiente para permitir que eles se preparem adequadamente para a revisão por pares. [PA150.IG102.SP101.SubP108]

9. Atribuir papéis para a revisão por pares, conforme apropriado. [PA150.IG102.SP101.SubP109]



Exemplos de papéis incluem: [PA150.IG102.SP101.SubP109.N101]

Líder

Leitor

Responsável pelos registros

Autor

10. Preparar para a revisão por pares revisando o produto de trabalho antes de executar a revisão por pares. [PA150.IG102.SP101.SubP110]

SP 2.2 Executar Revisões por Pares

Executar revisões por pares em produtos de trabalho selecionados e identificar as questões resultantes da revisão por pares. [PA150.IG102.SP102]

Um dos objetivos de executar uma revisão por pares é encontrar e remover defeitos com antecedência. As revisões por pares são feitas de forma incremental, conforme os produtos de trabalho vão sendo desenvolvidos. Estas revisões são estruturadas e não se confundem com revisões de gerenciamento. [PA150.IG102.SP102.N101]

As revisões por pares podem ser feitas sobre produtos de trabalho chave de atividades de especificação, design, teste e implementação e sobre produtos de trabalho específicos de planejamento. [PA150.IG102.SP102.N102]

O foco da revisão por pares deverá ser o produto de trabalho em revisão, não a pessoa que o produziu. [PA150.IG102.SP102.N103]

Quando surgirem questões durante a revisão por pares, elas deverão ser comunicadas ao desenvolvedor do produto de trabalho para sua correção. [PA150.IG102.SP102.N104]

Veja a área de processo de Monitoramento e Controle do Projeto para obter informações sobre o rastreamento de questões surgidas durante uma revisão por pares. [PA150.IG102.SP102.N104.R101]

As revisões por pares deverão tratar os seguintes pontos principais: deve haver uma preparação suficiente, a execução deve ser gerenciada e controlada, dados suficientes e consistentes devem ser registrados (um exemplo é a condução de uma inspeção formal) e os itens de ação devem ser registrados. [PA150.IG102.SP102.N105]


1. Resultados da revisão por pares [PA150.IG102.SP102.W101]

2. Questões da revisão por pares [PA150.IG102.SP102.W102]



3. Dados da revisão por pares [PA150.IG102.SP102.W103]

Sub-práticas

1. Executar os papéis atribuídos na revisão por pares. [PA150.IG102.SP102.SubP101]

2. Identificar e documentar os defeitos e outras questões sobre o produto de trabalho. [PA150.IG102.SP102.SubP102]

3. Registrar os resultados da revisão por pares, incluindo os itens de ação. [PA150.IG102.SP102.SubP103]

4. Coletar dados da revisão por pares. [PA150.IG102.SP102.SubP104]

Veja a área de processo de Medições e Análises para obter maiores informações sobre a coleta de dados. [PA150.IG102.SP102.SubP104.R101]

5. Identificar itens de ação e comunicar as questões aos stakeholders relevantes. [PA150.IG102.SP102.SubP105]

6. Executar uma nova revisão por pares, se os critérios definidos indicarem essa necessidade. [PA150.IG102.SP102.SubP106]

7. Assegurar que os critérios de saída para a revisão por pares estão sendo satisfeitos. [PA150.IG102.SP102.SubP107]

SP 2.3 Analisar Dados da Revisão por Pares

Analisar dados sobre preparação, execução e resultados das revisões por pares. [PA150.IG102.SP103]

Veja a área de processo de Medições e Análises para obter maiores informações sobre a obtenção e análise de dados. [PA150.IG102.SP103.R101]


1. Dados de revisões por pares [PA150.IG102.SP103.W101]

2. Itens de ação de revisões por pares [PA150.IG102.SP103.W102]

Sub-práticas

1. Registrar os dados relacionados à preparação, execução e resultados das revisões por pares. [PA150.IG102.SP103.SubP101]



Os dados mais comuns são o nome e tamanho do produto, composição da equipe de revisão por pares, tipo de revisão por pares, tempo de preparação por revisor, duração da reunião de revisão, número de defeitos encontrados, tipo e origem dos defeitos, etc. Informações adicionais sobre o produto de trabalho que está sendo revisado podem ser coletadas, como tamanho, etapa de desenvolvimento, modos de operação examinados e requisitos que estão sendo avaliados. [PA150.IG102.SP103.SubP101.N101]

2. Armazenar os dados para futura referência e análise. [PA150.IG102.SP103.SubP102]

3. Proteger os dados para assegurar que os dados da revisão por pares não sejam utilizados de forma inadequada. [PA150.IG102.SP103.SubP103]

Exemplos de uso inadequado dos dados de revisões por pares incluem o uso dos dados para avaliar o desempenho das pessoas e para atribuir responsabilidades. [PA150.IG102.SP103.SubP103.N101]

4. Analisar os dados da revisão por pares. [PA150.IG102.SP103.SubP104]

SG 3 Verificar os Produtos de Trabalho Selecionados

Os produtos de trabalho selecionados são verificados contra seus requisitos especificados. [PA150.IG103]

SP 3.1 Executar a Verificação

Executar a verificação dos produtos de trabalho selecionados. [PA150.IG103.SP101]

A verificação de produtos e produtos de trabalho de forma incremental promove a detecção antecipada de problemas e pode resultar em uma remoção antecipada de defeitos. Estes resultados da verificação reduzem consideravelmente o custo do isolamento das falhas e do retrabalho associados com a solução de problemas. [PA150.IG103.SP101.N101]

(Para os usuários da representação contínua, esta é uma prática específica da capacitação de nível 1. Os processos de verificação das capacitações de nível 1 e 2 podem não incluir procedimentos e critérios, que são criados na prática específica Estabelecer Procedimentos e Critérios de Verificação na capacitação de nível 3. Quando não existirem procedimentos ou critérios estabelecidos, utilize os métodos estabelecidos pela prática específica Selecionar Produtos de Trabalho para Verificação para atender à execução da capacitação de nível 1.) [PA150.IG103.SP101.N102]




1. Resultados da verificação [PA150.IG103.SP101.W101]

2. Relatórios de verificação [PA150.IG103.SP101.W102]

3. Demonstrações [PA150.IG103.SP101.W103]

4. Logs de procedimentos de execução (As-run) [PA150.IG103.SP101.W104]

Sub-práticas

1. Executar a verificação de produtos de trabalho contra seus requisitos. [PA150.IG103.SP101.SubP102]

2. Registrar os resultados das atividades de verificação. [PA150.IG103.SP101.SubP103]

3. Identificar itens de ação resultantes da verificação dos produtos de trabalho. [PA150.IG103.SP101.SubP104]

4. Documentar o método de verificação de execução (“as-run”) e os desvios dos métodos e procedimentos disponíveis descobertos durante a sua execução. [PA150.IG103.SP101.SubP105]

SP 3.2 Analisar os Resultados das Verificações e Identificar Ações Corretivas

Analisar os resultados de todas as atividades de verificação e identificar as ações corretivas. [PA150.IG103.SP102]

Os resultados reais devem ser comparados com os critérios de verificação estabelecidos para determinar a aceitação. [PA150.IG103.SP102.N101]

Os resultados das análises são registrados como evidências de que a verificação foi executada. [PA150.IG103.SP102.N102]

Para cada produto de trabalho, todos os resultados de verificações disponíveis são analisados de forma incremental e as ações corretivas são iniciadas para assegurar que os requisitos sejam atendidos. Uma vez que uma revisão por pares é apenas um entre os diversos métodos de verificação, os dados das revisões por pares deverão ser incluídos nesta atividade de análise, para assegurar que os resultados da verificação são suficientemente analisados. Os relatórios de análises ou a documentação do método de execução (“as-run”) podem também indicar que os maus resultados da verificação ocorreram devido a problemas no método, problemas nos critérios ou um problema no ambiente de verificação. [PA150.IG103.SP102.N103]

Veja as práticas de ações corretivas na área de processo de Monitoramento e Controle do Projeto para obter maiores informações sobre como implementar ações corretivas. [PA150.IG103.SP102.N103.R101]




1. Relatórios de análises (como estatísticas de desempenho, análises de causas de não conformidades, comparações de comportamento entre produtos reais e modelos e tendências) [PA150.IG103.SP102.W101]

2. Relatórios de problemas identificados [PA150.IG103.SP102.W102]

3. Solicitações de mudanças para os métodos de verificação, critérios e ambiente [PA150.IG103.SP102.W103]

4. Ações corretivas para métodos de verificação, critérios e/ou ambiente [PA150.IG103.SP102.W104]

Sub-práticas

1. Comparar os resultados reais com os esperados. [PA150.IG103.SP102.SubP101]

2. Baseado nos critérios de verificação estabelecidos, identificar produtos que não atenderam seus requisitos ou identificar problemas com os métodos, procedimentos, critérios e ambiente de verificação. [PA150.IG103.SP102.SubP102]

3. Analisar os dados de verificações sobre defeitos. [PA150.IG103.SP102.SubP103]

4. Registrar todos os resultados da análise em um relatório. [PA150.IG103.SP102.SubP104]

5. Utilizar os resultados de verificações para comparar medições e desempenho reais com os parâmetros técnicos de desempenho. [PA150.IG103.SP102.SubP105]

6. Fornecer informações sobre como os defeitos podem ser resolvidos (incluindo os métodos de verificação, critérios e ambiente de verificação) e formalizar isto em um plano. [PA150.IG103.SP102.SubP106]



Compromisso


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



Elaboração:

Esta política estabelece as expectativas organizacionais para o estabelecimento e manutenção dos métodos, procedimentos, critérios e ambiente de verificação, execução de revisões por pares e verificação de produtos de trabalho selecionados. [PA150.EL101]

Habilitações


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


Estabelecer e manter o plano para a execução do processo de verificação. [GP104]

Elaboração:

De forma geral, este plano para a execução do processo de verificação está incluído no (ou é referenciado pelo) plano do projeto, que é descrito na área de processo de Planejamento do Projeto. [PA150.EL102]


Fornecer recursos adequados para executar o processo de verificação, desenvolver os produtos de trabalho e fornecer os serviços do processo. [GP105]

Elaboração:

Condições especiais podem ser necessárias para a verificação dos produtos de trabalho selecionados. Quando necessário, as condições exigidas pelas atividades da área de processo de Verificação podem ser desenvolvidas ou adquiridas. [PA150.EL110]

Certos métodos de verificação podem exigir ferramentas, equipamentos, condições e treinamentos especiais (por exemplo, as revisões por pares podem exigir salas de reuniões e moderadores treinados; certos testes de verificação podem exigir equipamentos especiais de testes e pessoas capacitadas no uso do equipamento). [PA150.EL104]




Ferramentas de gerenciamento de testes

Geradores de casos de testes

Analisadores de cobertura de testes

Simuladores


Atribuir responsabilidades e autoridades para executar o processo, desenvolver os produtos de trabalho e fornecer os serviços do processo de verificação. [GP106]


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

Elaboração:



Princípios, padrões e métodos de verificação (isto é, análises, demonstrações, inspeções, testes)

Ferramentas e condições de verificação

Preparação e procedimentos de revisões por pares

Facilitação de reuniões

Implementações


Colocar os produtos de trabalho definidos do processo de verificação sob os níveis apropriados de gerência de configurações. [GP109]



Elaboração:

Exemplos de produtos de trabalho colocados sob gerência de configurações incluem: [PA150.EL106]

Procedimentos e critérios de verificação

Material de treinamento de revisões por pares

Dados de revisões por pares

Relatórios de verificações


Identificar e envolver os stakeholders relevantes do processo de verificação, conforme planejado. [GP124]

Elaboração:

Selecionar stakeholders relevantes entre clientes, usuários finais, desenvolvedores, produtores, testadores, fornecedores, pessoal de marketing, de manutenção, de descarte e outros que possam ser afetados ou afetar o produto, bem como o processo. [PA150.EL113]


Selecionar produtos de trabalho e métodos para verificação

Estabelecer procedimentos e critérios de verificação

Executar revisões por pares

Analisar os resultados das verificações e identificar as ações corretivas


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



Elaboração:


Perfil da verificação (por exemplo, a quantidade de verificações planejadas e executadas e os defeitos encontrados, talvez classificados por método de verificação ou tipo de defeito)

Quantidade de defeitos detectados por categoria de defeito

Tendências de problemas de verificação relatados (por exemplo, a quantidade de problemas abertos e encerrados)

Status de problemas de verificação relatados (isto é, por quanto tempo cada problema relatado ficou aberto)


Coletar produtos de trabalho, medidas, resultados de medições e informações de melhoria derivadas do planejamento e da execução do processo de verificação para suportar o uso futuro e a melhoria dos processos e dos ativos de processos da organização. [GP117]

Verificação de Implementação


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

Elaboração:


Seleção de produtos de trabalho para verificação

Estabelecimento e manutenção de procedimentos e critérios de verificação

Execução de revisões por pares

Verificação de produtos de trabalho selecionados




Verificação de procedimentos e critérios

Checklists de revisões por pares

Relatórios de verificação

GP 2.10 (VE 2) Revisar Situação com a Gerência de Mais Alto Nível

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



VALIDAÇÃO


Objetivo

O objetivo da Validação (Validation) é demonstrar que o produto ou componente do produto atende plenamente seu uso pretendido, quando colocado no seu ambiente pretendido. [PA149]


As atividades de validação podem ser aplicadas a todos os aspectos do produto, em qualquer dos seus ambientes pretendidos, como operação, treinamento, manufatura, manutenção e serviços de suporte. Os métodos empregados para executar a validação podem ser aplicados a produtos de trabalho, bem como a produtos e componentes de produtos. Os produtos de trabalho (por exemplo, requisitos, designs, protótipos) deverão ser selecionados com base nos que poderão fornecer uma melhor previsão de como o produto ou componente de produto irá satisfazer as necessidades do usuário. [PA149.N105]

O ambiente de validação deverá representar o ambiente pretendido do produto e componentes do produto, bem como representar o ambiente pretendido adequado para as atividades de validação com os produtos de trabalho. [PA149.N106]

A validação demonstra que o produto, conforme fornecido, irá atender plenamente seu uso pretendido; enquanto isso, a verificação trata de saber se o produto de trabalho reflete de forma apropriada os requisitos especificados. Em outras palavras, a verificação assegura que “você construir certo”; enquanto isso, a validação garante que “você construiu a coisa certa”. As atividades de validação utilizam abordagens semelhantes às de verificação (isto é, testes, análises, inspeções, demonstrações ou simulações). Freqüentemente, os usuários finais são envolvidos nas atividades de validação. As atividades de validação e as de verificação, freqüentemente, ocorrem em paralelo e podem utilizar partes do mesmo ambiente. [PA149.N102]

Veja a área de processo de Verificação para obter maiores informações sobre as atividades de verificação. [PA149.N102.R101]

Nível de Maturidade: 3, Validação 315


Quando possível, a validação deverá ser executada utilizando o produto ou componente do produto operando no seu ambiente pretendido. O ambiente completo pode ser utilizado ou somente parte dele. Entretanto, as questões de validação podem ser descobertas antecipadamente na vida do projeto utilizando os produtos de trabalho. [PA149.N103]

Quando questões de validação são identificadas, elas são referenciadas aos processos associados com as áreas de processos de Desenvolvimento de Requisitos, Soluções Técnicas ou Monitoramento e Controle do Projeto para a resolução. [PA149.N104]

As práticas específicas desta área de processo se baseiam umas nas outras da seguinte forma. A prática específica Selecionar Produtos para Validação permite a identificação do produto ou componente do produto a ser validado e os métodos a serem utilizados para executar a validação. A prática específica Estabelecer o Ambiente de Validação permite a determinação do ambiente que será utilizado para conduzir a validação. A prática específica Estabelecer Procedimentos e Critérios de Validação permite o desenvolvimento de procedimentos e critérios de validação que estejam alinhados com as características de produtos selecionados, restrições do cliente sobre a validação, métodos e ambiente de validação. A prática específica Executar a Validação permite a execução da validação de acordo com os métodos, procedimentos e critérios. [PA149.N107]


Veja a área de processo de Desenvolvimento de Requisitos para obter maiores informações sobre validações de requisitos. [PA149.R101]

Veja a área de processo de Soluções Técnicas para obter maiores informações sobre como transformar requisitos em especificações de produtos e sobre como tomar ações corretivas, quando são identificadas questões de validação que afetam o design do produto ou dos componentes do produto. [PA149.R102]

Veja a área de processo de Verificação para obter maiores informações sobre como verificar se o produto ou componente do produto atende seus requisitos. [PA149.R103]


SG 1 Preparar para a Validação [PA149.IG101]

A preparação para a validação é conduzida.

Nível de Maturidade: 3, Validação316


SG 2 Validar Produtos ou Componentes de Produtos[PA149.IG102]

O produto ou componentes do produto são validados para assegurar que eles são adequados para o uso no seu ambiente de operação pretendido.

GG 3 Institucionalizar um Processo Definido[CL104.GL101]



SG 1 Preparar para a Validação [PA149.IG101]

SP 1.1 Selecionar Produtos para ValidaçãoSP 1.2 Estabelecer o Ambiente de ValidaçãoSP 1.3 Estabelecer Procedimentos e Critérios de Validação

SG 2 Validar Produtos ou Componentes de Produtos[PA149.IG102]

SP 2.1 Executar a ValidaçãoSP 2.2 Analisar os Resultados da Validação




SG 1 Preparar para a Validação

A preparação para a validação é conduzida. [PA149.IG101]

As atividades de preparação incluem selecionar produtos e componentes de produtos para validação e estabelecer e manter o ambiente de validação, procedimentos e critérios. Os itens selecionados para validação podem incluir somente o produto ou podem incluir níveis apropriados de componentes do produto que serão utilizados para construir o produto. Qualquer produto ou componente de produto pode estar sujeito à validação, incluindo produtos de reposição, manutenção e treinamento, somente para citar alguns. [PA149.IG101.N101]



O ambiente exigido para validar o produto ou componente do produto é preparado. O ambiente pode ser comprado ou pode ser especificado, projetado e construído. Os ambientes utilizados para a integração e verificação do produto podem ser pensados em colaboração com o ambiente de validação, de forma a reduzir custos e aumentar a eficiência ou a produtividade. [PA149.IG101.N102]

SP 1.1 Selecionar Produtos para Validação

Selecionar produtos e componentes de produtos a serem validados e os métodos de validação que serão utilizados para cada um deles. [PA149.IG101.SP101]

Produtos e componentes de produtos são selecionados para validação com base na sua relação com as necessidades do usuário. Para cada componente do produto, o escopo da validação (por exemplo, o ambiente operacional, de manutenção, treinamento e interface com o usuário) deverá ser definido. [PA149.IG101.SP101.N104]

Os requisitos e restrições para a execução da validação são coletados. Então, os métodos de validação são selecionados com base na sua capacidade de demonstrar que as necessidades do usuário estão sendo satisfeitas. Os métodos de validação não somente definem a abordagem técnica da validação do produto, mas também dirigem as necessidades de recursos, equipamentos e ambientes. Isto pode resultar na geração de requisitos de componentes de produtos de baixo nível, que são tratados pelos processos de desenvolvimento de requisitos. Os requisitos derivados, como os requisitos de interface para os conjuntos e equipamentos de testes, podem ser gerados. Estes requisitos também passam pelos processos de desenvolvimento de requisitos, de forma a assegurar que o produto ou componentes do produto podem ser validados em um ambiente que suporta os métodos. [PA149.IG101.SP101.N101]

Os métodos de validação deverão ser selecionados antecipadamente na vida do projeto, de forma que eles estejam claramente entendidos e acordados pelos stakeholders relevantes. [PA149.IG101.SP101.N102]

Os métodos de validação tratam o desenvolvimento, manutenção, suporte e treinamento para o produto e componentes do produto, conforme apropriado. [PA149.IG101.SP101.N103]


1. Listas de produtos e componentes de produtos selecionados para validação [PA149.IG101.SP101.W101]

2. Métodos de validação para cada produto ou componente de produto [PA149.IG101.SP101.W102]



3. Requisitos para executar a validação para cada produto ou componente de produto [PA149.IG101.SP101.W103]

4. Restrições de validação para cada produto ou componente de produto [PA149.IG101.SP101.W104]

Sub-práticas

1. Identificar os princípios chaves, os recursos e fases para a validação do produto ou componente de produto durante toda a vida do projeto. [PA149.IG101.SP101.SubP101]

2. Determinar quais categorias de necessidades do usuário (operacionais, de manutenção, treinamento ou suporte) serão validadas. [PA149.IG101.SP101.SubP102]

O produto ou componente de produto deve podem ser mantido e suportado no seu ambiente operacional pretendido. Esta prática específica também trata os serviços reais de manutenção, treinamento e suporte que podem ser entregues juntamente com o produto. [PA149.IG101.SP101.SubP102.N101]

Um exemplo de avaliação de conceitos de manutenção no ambiente operacional é uma demonstração que as ferramentas de manutenção são operacionais com o produto real. [PA149.IG101.SP101.SubP102.N102]

3. Selecionar o produto e componentes do produto a serem validados. [PA149.IG101.SP101.SubP105]

4. Selecionar os métodos de avaliação para a validação do produto ou componente do produto. [PA149.IG101.SP101.SubP103]

5. Revisar a seleção, restrições e métodos de validação com os stakeholders relevantes. [PA149.IG101.SP101.SubP104]

SP 1.2 Estabelecer o Ambiente de Validação

Estabelecer e manter o ambiente necessário para suportar a validação. [PA149.IG101.SP102]

Os requisitos para o ambiente de validação são dirigidos pelo produto ou componentes de produtos selecionados, pelo tipo de produtos de trabalho (por exemplo, design, protótipo, versão final) e pelos métodos de validação. Estes podem gerar requisitos para a compra ou desenvolvimento de equipamentos, software ou outros recursos. Estes requisitos são fornecidos para os processos de desenvolvimento de requisitos para serem desenvolvidos. O ambiente de validação pode incluir a reutilização de recursos existentes. Neste caso, devem ser feitos arranjos para o uso destes recursos. Exemplos dos tipos de elementos em um ambiente de validação incluem: [PA149.IG101.SP102.N101]



Ferramentas de testes que fazem interface com o produto que está sendo validado (por exemplo, escopo, dispositivos eletrônicos, inspeções)

Softwares de testes temporariamente embutidos

Ferramentas de gravação para transferência de dados ou análises posteriores e reexecução

Sub-sistemas ou componentes simulados (por software, dispositivos eletrônicos ou mecânicos)

Sistemas de interfaces simuladas (por exemplo, um navio de guerra falso para testar um radar naval)

Sistemas de interfaces reais (por exemplo, aeronaves para testar um radar com recursos de rastreamento de trajetória)

Recursos e produtos fornecidos pelo cliente

Pessoas habilitadas para operar e utilizar todos os elementos acima

Ambiente de teste dedicado isolado ou em rede (por exemplo, ambientes de testes de redes de telecomunicações pseudo-operacionais ou recursos com troncos reais, switches e sistemas estabelecidos para integração realista e tentativas de validação)

A seleção antecipada dos produtos ou componentes de produtos a serem validados, dos produtos de trabalho a serem utilizados na validação e dos métodos de validação é necessária para assegurar que o ambiente de validação estará disponível quando necessário. [PA149.IG101.SP102.N102]

O ambiente de validação deverá ser cuidadosamente controlado para ser útil para a replicação, análises de resultados e revalidação de áreas com problemas. [PA149.IG101.SP102.N103]


1. Ambiente de validação [PA149.IG101.SP102.W101]

Sub-práticas

1. Identificar requisitos do ambiente de validação. [PA149.IG101.SP102.SubP101]

2. Identificar produtos fornecidos pelo cliente. [PA149.IG101.SP102.SubP102]

3. Identificar itens de reuso. [PA149.IG101.SP102.SubP103]

4. Identificar equipamentos e ferramentas de testes. [PA149.IG101.SP102.SubP104]

5. Identificar recursos de validação que estão disponíveis para reuso e modificação. [PA149.IG101.SP102.SubP105]



6. Planejar a disponibilidade dos recursos em detalhes. [PA149.IG101.SP102.SubP106]

SP 1.3 Estabelecer Procedimentos e Critérios de Validação

Estabelecer e manter procedimentos e critérios para validação. [PA149.IG101.SP103]

Os procedimentos e critérios de validação são definidos para assegurar que o produto ou componente do produto irá atender plenamente seu uso pretendido quando colocado no seu ambiente pretendido. Casos de testes e procedimentos de aceitação podem atender a necessidade de procedimentos de validação. [PA149.IG101.SP103.N101]

Os procedimentos e critérios de validação incluem o teste e avaliação de serviços de manutenção, treinamento e suporte. [PA149.IG101.SP103.N102]

Exemplos de fontes de critérios de validação incluem: [PA149.IG101.SP103.N103]


Padrões

Critérios de aceitação do cliente

Desempenho ambiental

Limites de desvios de desempenho


1. Procedimentos de validação [PA149.IG101.SP103.W101]

2. Critérios de validação [PA149.IG101.SP103.W102]

3. Procedimentos de testes e avaliação para manutenção, treinamento e suporte [PA149.IG101.SP103.W103]

Sub-práticas

1. Revisar os requisitos do produto para assegurar que as questões que afetam a validação do produto ou componente de produto foram identificadas e resolvidas. [PA149.IG101.SP103.SubP101]

2. Documentar o ambiente, cenário operacional, procedimentos, entradas, saídas e critérios para a validação do produto ou componente de produto selecionado. [PA149.IG101.SP103.SubP102]

3. Analisar o design conforme ele amadurece no contexto do ambiente de validação para identificar questões de validação. [PA149.IG101.SP103.SubP103]



SG 2 Validar o Produto ou Componentes do Produto

O produto ou componentes do produto são validados para assegurar que eles são adequados para o uso no seu ambiente de operação pretendido. [PA149.IG102]

Os métodos, procedimentos e critérios de validação são utilizados para validar os produtos e componentes de produtos selecionados e quaisquer serviços de manutenção, treinamento e suporte associados utilizando o ambiente de validação apropriado. [PA149.IG102.N102]

SP 2.1 Executar a Validação

Executar a validação dos produtos e componentes de produtos selecionados. [PA149.IG102.SP101]

Para ser aceitável para os usuários, um produto ou componente de produto deve ter o desempenho esperado no seu ambiente operacional pretendido. [PA149.IG102.SP101.N101]

As atividades de validação são executadas e os dados resultantes são coletados de acordo com os métodos, procedimentos e critérios estabelecidos. [PA149.IG102.SP101.N102]

Os procedimentos de validação da execução (“as-run”) deverão ser documentados e os desvios ocorridos durante a execução deverão ser anotados, conforme apropriado. [PA149.IG102.SP101.N103]

(Para usuários da representação contínua, esta é uma prática específica da capacitação nível 1. Os processos de validação nas capacitações nível 1 ou 2 podem não incluir procedimentos e critérios, que são criados na prática específica Estabelecer Procedimentos e Critérios de Validação na capacitação nível 3. Quando não houver procedimentos ou critérios estabelecidos, utilize os métodos estabelecidos pela prática específica Selecionar Produtos para Validação para atender a execução da capacitação nível 1). [PA149.IG102.SP101.N104]


1. Relatórios de validação [PA149.IG102.SP101.W101]

2. Resultados de validação [PA149.IG102.SP101.W102]

3. Matriz de referência cruzada de validação [PA149.IG102.SP101.W103]

4. Log de procedimentos de execução (“as-run”) [PA149.IG102.SP101.W104]

5. Demonstrações operacionais [PA149.IG102.SP101.W105]



SP 2.2 Analisar os Resultados da Validação

Analisar os resultados das atividades de validação e identificar questões. [PA149.IG102.SP102]

Os dados resultantes dos testes de validação, inspeções, demonstrações ou avaliações são analisados contra os critérios de validação definidos. Os relatórios de análises indicam se as necessidades foram atendidas; no caso de deficiências, estes relatórios documentam o grau de sucesso ou falha e categorizam as prováveis causas da falha. Os resultados coletados de testes, inspeções e revisões são comparados com os critérios de avaliação estabelecidos para determinar se a validação deve prosseguir ou tratar as questões de requisitos ou design nos processos de desenvolvimento de requisitos ou soluções técnicas. [PA149.IG102.SP102.N101]

Os relatórios de análises ou documentação da validação de execução (“as-run”) podem também indicar que os maus resultados de testes são devido a um problema no procedimento de validação ou no ambiente de validação. [PA149.IG102.SP102.N102]


1. Relatórios de deficiências da validação [PA149.IG102.SP102.W101]

2. Questões da validação [PA149.IG102.SP102.W102]

3. Solicitações de mudanças nos procedimentos [PA149.IG102.SP102.W103]

Sub-práticas

1. Comparar resultados reais com os resultados esperados. [PA149.IG102.SP102.SubP101]

2. Com base nos critérios de validação estabelecidos, identificar produtos e componentes de produto que não rodam adequadamente nos seus ambientes operacionais pretendidos ou identificar problemas com os métodos, critérios e/ou ambiente. [PA149.IG102.SP102.SubP102]

3. Analisar os dados de validação com relação a defeitos. [PA149.IG102.SP102.SubP103]

4. Registrar os resultados das análises e identificar questões. [PA149.IG102.SP102.SubP104]

5. Usar os resultados da validação para comparar medições e desempenho reais com o uso pretendido ou necessidade operacional. [PA149.IG102.SP102.SubP105]





Compromissos


Estabelecer e manter uma política organizacional para planejar e executar o processo de validação. [GP103]

Elaboração:

Esta política estabelece as expectativas organizacionais para selecionar produtos e componentes de produtos para validação; para selecionar métodos de validação e para estabelecer e manter os procedimentos, critérios e ambientes de validação que asseguram que os produtos e componentes de produtos satisfazem as necessidades do usuário no seu ambiente operacional pretendido. [PA149.EL101]

Habilitações


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


Estabelecer e manter o plano para execução do processo de validação. [GP104]

Elaboração:

Normalmente, este plano para execução do processo de validação está incluído no (ou é referenciado pelo) plano do projeto, que é descrito na área de processo de Planejamento do Projeto. [PA149.EL116]


Fornecer os recursos adequados para executar o processo de validação, desenvolver os produtos de trabalho e fornecer os serviços do processo. [GP105]

Elaboração:

Recursos especiais podem ser exigidos para validar o produto ou componentes do produto. Quando necessário, os recursos exigidos pela validação são desenvolvidos ou comprados. [PA149.EL111]




Ferramentas de gerenciamento de testes

Geradores de casos de testes

Analisadores de cobertura de testes

Simuladores

Ferramentas de carga, stress e desempenho


Atribuir responsabilidades e autoridade para executar o processo, desenvolver os produtos de trabalho e fornecer os serviços do processo de validação. [GP106]


Treinar as pessoas para executar e suportar o processo de validação, conforme necessário. [GP107]

Elaboração:



Princípios, padrões e métodos de validação

Ambiente de uso pretendido

Implementações


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



Elaboração:


Listas de produtos e componentes de produtos selecionados para validação

Métodos, procedimentos e critérios de validação

Relatórios de validação


Identificar e envolver os stakeholders relevantes do processo de validação, conforme planejado. [GP124]

Elaboração:

Selecionar os stakeholders relevantes a partir dos clientes, usuários finais, desenvolvedores, produtores, testadores, fornecedores, pessoal de marketing, de manutenção, de descarte e outros que possam ser afetados ou afetar o produto, bem como o processo. [PA149.EL113]

Exemplos de atividades para envolvimento de stakeholders incluem: [PA149.EL114]

Selecionar os produtos e componentes de produtos a serem validados

Estabelecer os métodos, procedimentos e critérios de validação

Revisar os resultados da validação do produto e componentes do produto e resolver questões

Resolver questões com os clientes ou usuários finais

Questões com os clientes ou usuários finais são resolvidas especialmente quando existem desvios significativos das necessidades de baselines com relação ao seguinte: [PA149.EL115]

Dispensas no contrato ou acordo (o quê, quando e para quais produtos, serviços ou produtos manufaturados)

Estudos aprofundados adicionais, tentativas, testes ou avaliações

Possíveis mudanças nos contratos ou acordos


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



Elaboração:


Quantidade de atividades de validação completadas (planejadas versus reais)

Tendências de problemas de validação relatados (por exemplo, quantidade de problemas abertos e fechados)

Duração de problemas de validação reportados (isto é, por quanto tempo cada problema relatado ficou aberto)


Coletar produtos de trabalho, medidas, resultados de medições e informações de melhorias derivados do planejamento e execução do processo de validação para suportar o uso futuro e a melhoria dos processos e ativos de processos da organização. [GP117]

Verificações


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

Elaboração:


Selecionar os produtos e componentes de produto a serem validados

Estabelecer e manter métodos, procedimentos e critérios de validação

Validar produtos ou componentes de produtos


Métodos, procedimentos e critérios de validação


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



FOCO NO PROCESSO ORGANIZACIONAL


Objetivo

O objetivo do Foco no Processo Organizacional (Organizational Process Focus) é planejar e implementar uma melhoria no processo organizacional baseada em um entendimento abrangente dos pontos fortes e fracos dos atuais processos e ativos de processos da organização. [PA152]


Os processos da organização incluem o conjunto de processos padrão da organização e os processos definidos que são adaptados a partir deles. Os ativos de processos organizacionais são utilizados para estabelecer, manter, implementar e melhorar os processos definidos. Veja o Capítulo 3 para uma explicação de como a frase “ativos de processos organizacionais” é utilizada no CMMI Product Suite. [PA152.N101]

Melhorias candidatas para os ativos de processos organizacionais são obtidas a partir de diversas fontes, incluindo medições de processos, lições aprendidas na implementação de processos, resultados de avaliações de processos, resultados de atividades de avaliação de produtos, resultados de benchmarking contra processos de outras organizações e recomendações a partir de outras iniciativas de melhorias da organização. [PA152.N102]

A melhoria de processos ocorre dentro do contexto das necessidades da organização e é utilizada para tratar os objetivos da organização. A organização encoraja a participação daqueles que irão executar o processo nas atividades de melhoria de processos. A responsabilidade por facilitar e gerenciar as atividades de melhoria de processos da organização, inclusive coordenando a participação de outros, é normalmente atribuída a um grupo de processos. A organização fornece o compromisso de longo prazo e os recursos necessários para patrocinar este grupo. [PA152.N103]

Nível de Maturidade: 3, Foco no Processo Organizacional328


Um planejamento cuidadoso é necessário para que os esforços de melhoria de processos em toda a organização sejam adequadamente gerenciados e implementados. O planejamento da organização para a melhoria de processos resulta em um plano de melhoria de processos. O plano de melhoria de processos da organização irá tratar do planejamento de avaliações, planejamento de ações do processo, planejamento de pilotos e planejamento de implantação. Planos de avaliação descrevem o prazo e cronograma da avaliação, o escopo da avaliação, os recursos necessários para executar a avaliação, o modelo de referência contra o qual a avaliação será executada e a logística para a avaliação. Planos de ações de processos normalmente resultam de avaliações e documentam como serão implementadas melhorias específicas que tratarão as fraquezas descobertas por uma avaliação. Nos casos nos quais é definido que uma melhoria, descrita num plano de ação de processo, deverá ser testada em um pequeno grupo antes de ser implantada em toda a organização, um plano de piloto é gerado. Finalmente, quando a melhoria está para ser implantada, um plano de implantação é utilizado. Este plano descreve quando e como a melhoria será implantada em toda a organização. [PA152.N104]


Veja a área de processo de Definição do Processo Organizacional para obter maiores informações sobre os ativos de processos organizacionais. [PA152.R101]


SG 1 Determinar Oportunidades de Melhorias de Processos[PA152.IG101]

Pontos fortes e fracos e oportunidades de melhorias para os processos da organização são identificados periodicamente e tratados, conforme necessário.

SG 2 Planejar e Implementar Atividades de Melhorias de Processos[PA152.IG102]

Melhorias são planejadas e implementadas, ativos de processos organizacionais são implantados e experiências relacionadas a processos são incorporadas aos ativos de processos organizacionais.



Nível de Maturidade: 3, Foco no Processo Organizacional 329



SG 1 Determinar Oportunidades de Melhorias de Processos[PA152.IG101]

SP 1.1 Estabelecer Necessidades de Processos OrganizacionaisSP 1.2 Avaliar os Processos da OrganizaçãoSP 1.3 Identificar as Melhorias de Processos da Organização

SG 2 Planejar e Implementar Atividades de Melhorias de Processos[PA152.IG102]

SP 2.1 Estabelecer Planos de Ações de ProcessosSP 2.2 Implementar Planos de Ações de ProcessosSP 2.3 Implantar Ativos de Processos OrganizacionaisSP 2.4 Incorporar Experiências Relacionadas a Processos nos Ativos de

Processos Organizacionais




SG 1 Determinar Oportunidades de Melhorias de Processos

Pontos fortes e fracos e oportunidades de melhorias para os processos da organização são identificados periodicamente e tratados, conforme necessário. [PA152.IG101]

Pontos fortes e fracos e oportunidades de melhorias podem ser determinados com relação a um processo padrão ou modelo, como o modelo CMMI ou o padrão da International Organization for Standardization (ISO). As melhorias de processos deverão ser selecionadas especificamente para tratar as necessidades da organização. [PA152.IG101.N101]

SP 1.1 Estabelecer Necessidades de Processos Organizacionais

Estabelecer e manter a descrição das necessidades e objetivos do processo para a organização. [PA152.IG101.SP101]



Os processos da organização operam em um contexto de negócios que deve ser entendido. Os objetivos, necessidades e restrições de negócios da organização determinam as necessidades e objetivos para os processos da organização. Normalmente, as questões relacionadas a aspectos financeiros, tecnológicos, de qualidade, de recursos humanos e de marketing são importantes considerações de processos. [PA152.IG101.SP101.N101]

As necessidades e objetivos dos processos da organização cobrem aspectos que incluem: [PA152.IG101.SP101.N102]

Características dos processos

Objetivos de desempenho do processo, como tempo para entrada no mercado e qualidade do produto

Eficiência do processo


1. Necessidades e objetivos dos processos da organização [PA152.IG101.SP101.W101]

Sub-práticas

1. Identificar as políticas, padrões e objetivos de negócios que são aplicáveis aos processos da organização. [PA152.IG101.SP101.SubP101]

2. Examinar padrões de processos e modelos relevantes para as melhores práticas. [PA152.IG101.SP101.SubP102]

3. Determinar os objetivos de desempenho dos processos da organização. [PA152.IG101.SP101.SubP103]

Os objetivos de desempenho do processo podem ser expressos em termos quantitativos ou qualitativos. [PA152.IG101.SP101.SubP103.N101]

Exemplos de objetivos de desempenho de processos incluem: [PA152.IG101.SP101.SubP103.N102]

Prazo do ciclo

Taxas de remoção de defeitos

Produtividade

4. Definir as características essenciais dos processos da organização. [PA152.IG101.SP101.SubP104]

As características essenciais dos processos da organização são determinadas com base em: [PA152.IG101.SP101.SubP104.N101]

Processos que estão sendo atualmente utilizados na organização

Padrões de processos e produtos impostos pela organização



Padrões de processos e produtos normalmente impostos pelos clientes da organização

Exemplos de características de processos incluem: [PA152.IG101.SP101.SubP104.N102]

Nível de detalhe utilizado para descrever os processos

Notação de processos utilizada

Granularidade dos processos

5. Documentar as necessidades e objetivos dos processos da organização. [PA152.IG101.SP101.SubP105]

6. Revisar as necessidades e objetivos dos processos da organização, conforme necessário. [PA152.IG101.SP101.SubP106]

SP 1.2 Avaliar os Processos da Organização

Avaliar os processos da organização periodicamente e conforme necessário para manter um conhecimento de seus pontos fortes e fracos. [PA152.IG101.SP102]

Avaliações de processos podem ser executadas pelos seguintes motivos: [PA152.IG101.SP102.N101]

Para identificar processos que deverão ser melhorados

Para confirmar o progresso e tornar os benefícios das melhorias de processos visíveis

Para satisfazer as necessidades de um relacionamento entre cliente-fornecedor

Para motivar e facilitar a aceitação do processo (buy-in)

A aceitação obtida durante uma avaliação de processo pode ser significativamente enfraquecida, se esta não for seguida por um plano de ação baseado na avaliação. [PA152.IG101.SP102.N102]


1. Planos para avaliações de processos da organização [PA152.IG101.SP102.W101]

2. Descobertas de avaliações que tratam dos pontos fortes e fracos dos processos da organização [PA152.IG101.SP102.W102]

3. Recomendações de melhorias para os processos da organização [PA152.IG101.SP102.W103]

Sub-práticas

1. Obter patrocínio para a avaliação de processos por parte da gerência sênior. [PA152.IG101.SP102.SubP101]



O patrocínio da gerência sênior inclui o compromisso de ter gerentes e equipe da organização participando na avaliação do processo e fornecer os recursos e finanças necessários para analisar e comunicar as descobertas da avaliação. [PA152.IG101.SP102.SubP101.N101]

2. Definir o escopo da avaliação de processos. [PA152.IG101.SP102.SubP102]

Avaliações de processos podem ser executadas na organização como um todo ou em uma pequena parte da organização, como em um único projeto ou área de negócios. [PA152.IG101.SP102.SubP102.N101]

O escopo do processo de avaliação trata do seguinte: [PA152.IG101.SP102.SubP102.N102]

Definição da organização (por exemplo, locais ou áreas de negócios) que será coberta pela avaliação

Identificação do projeto e funções de suporte que representarão a organização na avaliação

Processos que serão avaliados

3. Determinar o método e critérios para a avaliação de processos. [PA152.IG101.SP102.SubP103]

Avaliações de processos podem ocorrer de diversas formas. Avaliações de processos deverão tratar as necessidades e objetivos da organização, que podem mudar com o tempo. Por exemplo, a avaliação pode ser baseada em um modelo de processos, como o modelo CMMI, ou em um padrão nacional ou internacional, como o ISO 9001. As avaliações também podem ser baseadas em comparações do tipo benchmarking com outras organizações. O método de avaliação pode assumir uma diversidade de características em termos de tempo e esforço gastos, formação da equipe de avaliação e o método e profundidade da investigação. [PA152.IG101.SP102.SubP103.N101]

4. Planejar, criar o cronograma e preparar para a avaliação do processo. [PA152.IG101.SP102.SubP104]

5. Conduzir a avaliação do processo. [PA152.IG101.SP102.SubP105]

6. Documentar e entregar as atividades e descobertas da avaliação. [PA152.IG101.SP102.SubP106]

SP 1.3 Identificar as Melhorias de Processos da Organização

Identificar melhorias para os processos e ativos de processos da organização. [PA152.IG101.SP103]


1. Análise de melhorias de processos candidatas [PA152.IG101.SP103.W101]

2. Identificação de melhorias para os processos da organização [PA152.IG101.SP103.W102]



Sub-práticas

1. Determinar melhorias de processos candidatas. [PA152.IG101.SP103.SubP101]

Melhorias de processos candidatas são normalmente determinadas fazendo-se o seguinte: [PA152.IG101.SP103.SubP101.N101]

Medir os processos e analisar os resultados das medições

Revisar os processos quanto à eficiência e adequação

Revisar as lições aprendidas na adaptação do conjunto de processos padrão da organização

Revisar as lições aprendidas a partir da implementação dos processos

Revisar propostas de melhoria de processos submetidas pelos gerentes e equipe da organização e outros stakeholders relevantes

Solicitar entradas nas melhorias de processos a partir da gerência sênior e dos líderes da organização

Examinar os resultados das avaliações de processos e outras revisões relacionadas a processos

Revisar resultados de atividades de melhorias de outras organizações

2. Priorizar as melhorias de processos candidatas. [PA152.IG101.SP103.SubP102]

Os critérios para priorização são: [PA152.IG101.SP103.SubP102.N101]

Considerar o custo e esforço estimados para implementar as melhorias de processos

Avaliar a melhoria esperada contra os objetivos e prioridades de melhorias da organização

Determinar as barreiras potenciais às melhorias de processos e desenvolver estratégias para sobrepor estas barreiras

Exemplos de técnicas para ajudar a determinar e priorizar as possíveis melhorias a serem implementadas incluem: [PA152.IG101.SP103.SubP102.N102]

Uma análise de distância (gap analysis) que compare as condições atuais da organização com as condições ótimas

Análises de força de campo (force-field analysis) de potenciais melhorias para identificar potenciais barreiras e as estratégias para sobrepô-las

Análises de causa e efeito para fornecer informações sobre efeitos potenciais de diferentes melhorias que podem, então, ser comparadas

3. Identificar e documentar as melhorias de processos que serão implementadas. [PA152.IG101.SP103.SubP103]

4. Revisar a lista de melhorias planejadas de processos para mantê-la atualizada. [PA152.IG101.SP103.SubP104]



SG 2 Planejar e Implementar Atividades de Melhorias de Processos

Melhorias são planejadas e implementadas, ativos de processos organizacionais são implantados e experiências relacionadas a processos são incorporadas nos ativos de processos organizacionais. [PA152.IG102]

A implementação bem sucedida de melhorias requer a participação dos proprietários do processo, daqueles que o executam e das organizações de suporte, nas atividades de definição e melhoria do processo. [PA152.IG102.N101]

SP 2.1 Estabelecer Planos de Ações de Processos

Estabelecer e manter planos de ações de processos para tratar melhorias nos processos e ativos de processos da organização. [PA152.IG102.SP101]

Estabelecer e manter planos de ações de processos, normalmente, envolvem os seguintes papéis: [PA152.IG102.SP101.N101]

Comitês gerenciais de direcionamento para definir estratégias e prever atividades de melhorias de processos

Equipe de grupo de processos para facilitar e gerenciar as atividades de melhorias de processos

Equipes de ações de processos para definir e implementar as melhorias

Proprietários dos processos para gerenciar a implantação

Praticantes para executar o processo

Este envolvimento ajuda a obter a aceitação das melhorias dos processos e aumenta a possibilidade de uma implantação efetiva. [PA152.IG102.SP101.N102]

Planos de ações de processos são planos detalhados de implementação. Estes planos diferem do plano de melhoria de processos da organização, já que são planos que tratam melhorias específicas que foram definidas para tratar pontos fracos que, normalmente, são descobertos por avaliações. [PA152.IG102.SP101.N103]


1. Planos de ações de processos da organização aprovados [PA152.IG102.SP101.W101]

Sub-práticas

1. Identificar estratégias, abordagens e ações para tratar as melhorias identificadas de processos. [PA152.IG102.SP101.SubP101]



Mudanças recentes, grandes e ainda não provadas, são executadas como pilotos antes de serem incorporadas ao uso normal. [PA152.IG102.SP101.SubP101.N101]

2. Estabelecer equipes de ações de processos para implementar as ações. [PA152.IG102.SP101.SubP102]

As equipes e pessoas que executam as ações de melhorias de processos são chamadas de “equipes de ações de processos”. As equipes de ações de processos normalmente incluem os proprietários dos processos e aqueles que executam os processos. [PA152.IG102.SP101.SubP102.N101]

3. Documentar os planos de ações de processos. [PA152.IG102.SP101.SubP103]

Os planos de ações de processos normalmente cobrem o seguinte: [PA152.IG102.SP101.SubP103.N101]

Infra-estrutura de melhorias de processos

Objetivos de melhorias de processos

Melhorias de processos que serão tratadas

Procedimentos para o planejamento e rastreamento de ações de processos

Estratégias para criação de pilotos e implementação de ações de processos

Responsabilidades e autoridade para implementar as ações de processos

Recursos, cronogramas e atribuições para a implementação das ações de processos

Métodos para determinar a eficiência das ações de processos

Riscos associados com os planos de ações de processos

4. Revisar e negociar planos de ações de processos com os stakeholders relevantes. [PA152.IG102.SP101.SubP104]

5. Revisar os planos de ações de processos, conforme necessário. [PA152.IG102.SP101.SubP105]

SP 2.2 Implementar Planos de Ações de Processos

Implementar planos de ações de processos em toda a organização. [PA152.IG102.SP102]


1. Compromissos entre as diversas equipes de ações de processos [PA152.IG102.SP102.W101]

2. Status e resultados da implementação de planos de ações de processos [PA152.IG102.SP102.W102]

3. Planos para pilotos [PA152.IG102.SP102.W103]



Sub-práticas

1. Tornar os planos de ações de processos prontamente disponíveis para os stakeholders relevantes. [PA152.IG102.SP102.SubP101]

2. Negociar e documentar compromissos entre as equipes de ações de processos e revisar seus planos de ações de processos, conforme necessário. [PA152.IG102.SP102.SubP102]

3. Rastrear o progresso e os compromissos contra os planos de ações de processos. [PA152.IG102.SP102.SubP103]

4. Conduzir revisões conjuntas com as equipes de ações de processos e os stakeholders relevantes, para monitorar o progresso e os resultados das ações de processos. [PA152.IG102.SP102.SubP104]

5. Planejar pilotos necessários para testar as melhorias de processos selecionadas. [PA152.IG102.SP102.SubP105]

6. Revisar as atividades e produtos de trabalho das equipes de ações de processos. [PA152.IG102.SP102.SubP106]

7. Identificar, documentar e rastrear até o encerramento as questões de implementação dos planos de ações de processos. [PA152.IG102.SP102.SubP107]

8. Assegurar que os resultados da implementação dos planos de ações de processos satisfazem os objetivos de melhorias de processos da organização. [PA152.IG102.SP102.SubP108]

SP 2.3 Implantar Ativos de Processos Organizacionais

Implantar ativos de processos organizacionais em toda a organização. [PA152.IG102.SP103]

A implantação de ativos de processos organizacionais ou de mudanças nos ativos de processos organizacionais deverão ser executadas de uma maneira ordenada. Alguns ativos de processos organizacionais ou mudanças nos ativos de processos organizacionais podem não ser apropriados para a implementação em determinadas partes da organização (por causa dos requisitos do cliente ou da atual fase do ciclo de vida que está sendo implementada, por exemplo). Por isso, é importante que aqueles que estão ou estarão executando o processo, bem como outras funções da organização (como treinamento e garantia da qualidade) sejam envolvidos na implantação, conforme necessário. [PA152.IG102.SP103.N101]

Veja a área de processo de Definição do Processo Organizacional para obter maiores informações sobre como a implantação dos ativos de processos organizacionais é suportada e possibilitada pela biblioteca de ativos de processos da organização. [PA152.IG102.SP103.N101.R101]




1. Planos para a implantação dos ativos de processos organizacionais e mudanças nos ativos de processos organizacionais [PA152.IG102.SP103.W101]

2. Materiais de treinamento para a implantação de ativos de processos organizacionais e mudanças nos ativos de processos organizacionais [PA152.IG102.SP103.W102]

3. Documentação das mudanças nos ativos de processos organizacionais [PA152.IG102.SP103.W103]

4. Materiais de suporte para implantação dos ativos de processos organizacionais e mudanças nos ativos de processos organizacionais [PA152.IG102.SP103.W104]

Sub-práticas

1. Implantar ativos de processos organizacionais e métodos e ferramentas associados. [PA152.IG102.SP103.SubP101]

Atividades típicas executadas como parte desta implantação incluem: [PA152.IG102.SP103.SubP101.N101]

Planejar a implantação

Identificar os ativos de processos organizacionais que deverão ser adotados por aqueles que executarão o processo

Assegurar que está disponível treinamento para os ativos de processos organizacionais que estão sendo implantados

Identificar os recursos de suporte (por exemplo, ferramentas) necessários para a transição do ativos de processos organizacionais implantados

Determinar o cronograma para a implantação dos ativos de processos organizacionais

Veja a área de processo de Treinamento Organizacional para obter maiores informações sobre coordenação de treinamentos. [PA152.IG102.SP103.SubP101.N101.R101]

2. Implantar as mudanças que foram feitas nos ativos de processos organizacionais. [PA152.IG102.SP103.SubP102]

Atividades comuns executadas como parte desta implantação incluem: [PA152.IG102.SP103.SubP102.N101]

Planejar a implantação

Determinar quais mudanças são apropriadas para aqueles que estão ou estarão executando o processo

Determinar o período de tempo para implantação das mudanças

Arranjar o suporte associado necessário para uma transição bem sucedida das mudanças



3. Documentar as mudanças nos ativos de processos organizacionais. [PA152.IG102.SP103.SubP103]

A documentação das mudanças é utilizada para entender o relacionamento das mudanças com as mudanças resultantes no desempenho e resultados do processo. [PA152.IG102.SP103.SubP103.N101]

4. Fornecer instruções e consultoria sobre o uso dos ativos de processos organizacionais. [PA152.IG102.SP103.SubP104]

SP 2.4 Incorporar Experiências Relacionadas a Processos nos Ativos de Processos Organizacionais

Incorporar produtos de trabalho relacionados a processos, medidas e informações de melhorias derivadas do planejamento e execução do processo nos ativos de processos organizacionais. [PA152.IG102.SP104]


1. Propostas de melhorias de processos [PA152.IG102.SP104.W101]

2. Lições aprendidas nos processos [PA152.IG102.SP104.W102]

3. Medições dos ativos de processos organizacionais [PA152.IG102.SP104.W103]

4. Recomendações de melhorias para os ativos de processos organizacionais [PA152.IG102.SP104.W104]

5. Registros de atividades de melhorias dos processos da organização [PA152.IG102.SP104.W105]

6. Informações sobre os ativos de processos organizacionais e melhorias a eles [PA152.IG102.SP104.W106]

Sub-práticas

1. Conduzir revisões periódicas da eficiência e adequação do conjunto padrão de processos da organização e ativos de processos organizacionais relacionados com relação aos objetivos de negócios da organização. [PA152.IG102.SP104.SubP101]

2. Obter feedback sobre o uso dos ativos de processos organizacionais. [PA152.IG102.SP104.SubP102]

3. Derivar lições aprendidas a partir da definição, criação de pilotos, implementação e implantação dos ativos de processos organizacionais. [PA152.IG102.SP104.SubP103]

4. Tornar disponíveis as lições aprendidas para as pessoas da organização, conforme apropriado. [PA152.IG102.SP104.SubP104]



Ações podem ter que ser tomadas para assegurar que as lições aprendidas sejam utilizadas apropriadamente. [PA152.IG102.SP104.SubP104.N101]

Exemplos de uso inadequado de lições aprendidas incluem: [PA152.IG102.SP104.SubP104.N102]

Avaliar o desempenho das pessoas

Julgar o desempenho ou resultados dos processos

Exemplos de maneiras de evitar o uso inadequado de lições aprendidas incluem: [PA152.IG102.SP104.SubP104.N103]

Controlar o acesso às lições aprendidas

Educar as pessoas sobre o uso apropriado das lições aprendidas

5. Analisar o conjunto comum de medidas da organização. [PA152.IG102.SP104.SubP105]

Veja a área de processo de Medições e Análises para obter maiores informações sobre como analisar medidas. [PA152.IG102.SP104.SubP105.R101]

Veja a área de processo de Definição do Processo Organizacional para obter maiores informações sobre como estabelecer um repositório organizacional de medições, incluindo as medidas comuns. [PA152.IG102.SP104.SubP105.R102]

6. Avaliar os processos, métodos e ferramentas em uso na organização e desenvolver recomendações para melhorar os ativos de processos organizacionais. [PA152.IG102.SP104.SubP106]

Esta avaliação normalmente inclui: [PA152.IG102.SP104.SubP106.N101]

Determinar quais os processos, métodos e ferramentas são de uso potencial para outras partes da organização

Avaliar a qualidade e eficiência dos ativos de processos organizacionais

Identificar melhorias candidatas para os ativos de processos organizacionais

Determinar a conformidade com o conjunto padrão de processos da organização e instruções de adaptação

7. Fazer o melhor uso dos processos da organização, métodos e ferramentas disponíveis para as pessoas na organização, conforme apropriado. [PA152.IG102.SP104.SubP107]

8. Gerenciar propostas de melhorias de processos. [PA152.IG102.SP104.SubP108]

As atividades de gerenciamento de propostas de melhorias de processos normalmente incluem: [PA152.IG102.SP104.SubP108.N101]

Solicitar propostas de melhorias de processos



Coletar propostas de melhorias de processos

Revisar as propostas de melhorias de processos

Selecionar as propostas de melhorias de processos que serão implementadas

Rastrear a implementação das propostas de melhorias de processos

Propostas de melhorias de processos são documentadas como solicitações de mudanças de processos ou problemas relatados, conforme apropriado. [PA152.IG102.SP104.SubP108.N102]

Algumas propostas de melhorias de processos podem ser incorporadas nos planos de ações de processos da organização. [PA152.IG102.SP104.SubP108.N103]

9. Estabelecer e manter registros das atividades de melhorias de processos da organização. [PA152.IG102.SP104.SubP109]



Compromissos


Estabelecer e manter uma política organizacional para planejar e executar o processo de foco no processo organizacional. [GP103]

Elaboração:

Esta política estabelece as expectativas organizacionais para determinar as oportunidades de melhorias de processos para os processos que estão sendo utilizados e para o planejamento e implementação de atividades de melhorias de processos em toda a organização. [PA152.EL101]

Habilitações


Estabelecer e manter a descrição de um processo definido de foco no processo organizacional. [GP114]




Estabelecer e manter o plano para execução do processo de foco no processo organizacional. [GP104]

Elaboração:

O plano para executar o processo de foco no processo organizacional, que muitas vezes é chamado de “plano de melhorias de processos”, difere dos planos de ações de processos descritos nas práticas específicas nesta área de processo. O plano tratado por esta prática genérica trata o planejamento abrangente de todas as práticas específicas desta área de processo, do estabelecimento das necessidades do processo organizacional até a incorporação das experiências relativas a processos nos ativos de processos organizacionais. [PA152.EL103]


Fornecer os recursos adequados para executar o processo de foco no processo organizacional, desenvolver os produtos de trabalho e fornecer os serviços do processo. [GP105]

Elaboração:


Sistemas de gerenciamento de bancos de dados

Ferramentas de melhorias de processos

Construtores de páginas da Web e browsers

Ferramentas de colaboração em grupo (groupware)

Ferramentas de melhoria da qualidade (por exemplo, ferramentas de melhoria da qualidade, diagramas de causa e efeito, diagramas de afinidade, gráfico de Pareto)


Atribuir responsabilidades e autoridade para executar o processo, desenvolver os produtos de trabalho e fornecer os serviços do processo de foco no processo organizacional. [GP106]



Elaboração:

Dois grupos são normalmente estabelecidos e a eles é atribuída responsabilidade pela melhoria de processos: (1) um comitê gerencial de direcionamento para a melhoria de processos para fornecer o patrocínio da gerência sênior e (2) um grupo de processo para facilitar e gerenciar as atividades de melhoria de processos. [PA152.EL120]


Treinar as pessoas para executar e suportar o processo de foco no processo organizacional, conforme necessário. [GP107]

Elaboração:


CMMI e outros modelos de referência de processos e de melhorias de processos

Planejamento e gerenciamento de melhorias de processos

Ferramentas, métodos e técnicas de análises

Modelagem de processos

Técnicas de facilitação

Gerenciamento de mudanças

Implementações


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

Elaboração:


Propostas de melhorias de processos

Planos de ações de processos aprovados na organização

Materiais de treinamento para a implantação de ativos de processos organizacionais

Planos para as avaliações de processos da organização




Identificar e envolver os stakeholders relevantes do processo de foco no processo organizacional, conforme planejado. [GP124]

Elaboração:


Coordenar e colaborar nas atividades de melhorias de processos com os proprietários dos processos, aqueles que estão ou estarão executando o processo e organizações de suporte (por exemplo, equipe de treinamento e representantes da garantia da qualidade)

Estabelecer as necessidades e objetivos do processo organizacional

Avaliar os processos da organização

Implementar os planos de ações de processos

Coordenar e colaborar na execução de pilotos para testar as melhorias selecionadas

Implantar os ativos de processos organizacionais e mudanças nos ativos de processos organizacionais

Comunicar os planos, status, atividades e resultados relacionados à implementação das atividades de melhorias de processos


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

Elaboração:


Quantidade de propostas de melhorias de processos submetidas, aceitas ou implementadas

Nível de maturidade ou de capacitação CMMI


Coletar produtos de trabalho, medidas, resultados de medições e informações de melhorias derivados do planejamento e execução do processo de foco no processo organizacional para suportar o uso futuro e a melhoria dos processos e ativos de processos da organização. [GP117]



Verificações


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

Elaboração:


Determinar as oportunidades de melhorias de processos

Planejar e coordenar atividades de melhorias de processos


Planos de melhorias de processos

Planos de ações de processos

Planos para as avaliações de processos da organização


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

Elaboração:

Estas revisões ocorrem, normalmente, na forma de um resumo apresentado ao comitê gerencial de direcionamento pelo grupo de processo e pelas equipes de ações de processos. [PA152.EL116]

Exemplos de tópicos de apresentação incluem: [PA152.EL121]

Status de melhorias que estão sendo desenvolvidas pelas equipes de ações de processos

Resultados de pilotos

Resultados de implantações

Status do cronograma para alcançar milestones significativos (por exemplo, estar pronto para uma avaliação ou o progresso em direção ao alcance de um nível de maturidade organizacional ou de um perfil de nível de capacitação)



DEFINIÇÃO DO PROCESSO ORGANIZACIONAL


Objetivo

O objetivo da Definição do Processo Organizacional (Organizational Process Definition) é estabelecer e manter um conjunto útil de ativos de processos organizacionais. [PA153]


Os ativos de processos organizacionais possibilitam uma execução consistente do processo em toda a organização e oferecem uma base para os benefícios cumulativos de longo prazo para a organização. Veja o Capítulo 3 para uma explicação de como a frase “ativos de processos organizacionais” é utilizada no CMMI Product Suite. [PA153.N101]

A biblioteca de ativos de processos da organização é uma coleção de itens mantidos pela organização para uso pelas pessoas e projetos da organização. Esta coleção de itens inclui descrições de processos e elementos de processos, descrições de modelos de ciclo de vida, instruções de adaptação de processos, documentação relacionada a processos e dados. A biblioteca de ativos de processos da organização suporta a aprendizagem organizacional e a melhoria de processos, permitindo o compartilhamento das melhores práticas e lições aprendidas em toda a organização. [PA153.N103]

O conjunto de processos padrão da organização é adaptado pelos projetos para criar seus processos definidos. Os outros ativos de processos organizacionais são utilizados para suportar a adaptação, bem como a implementação dos processos definidos. [PA153.N104]

Um processo padrão é composto de outros processos ou elementos de processos. Um elemento de processo é uma unidade fundamental (isto é, atômica) da definição do processo e descreve as atividades e tarefas para se executar de forma consistente o trabalho. A arquitetura de processos fornece as regras para a conexão dos elementos de processos de um processo padrão. O conjunto de processos padrão da organização pode incluir diversas arquiteturas de processos. [PA153.N105]

Veja as definições de “processo padrão” e “elemento de processo” no Apêndice B, o glossário. Veja o Capítulo 3 para uma explicação de como “arquitetura de processos” é utilizada na CMMI Product Suite. [PA153.N107]

Nível de Maturidade: 3, Definição do Processo Organizacional346


Os ativos de processos organizacionais podem ser organizados de diversas formas, dependendo da implementação da área de processo de Definição do Processo Organizacional. Exemplos incluem: [PA153.N106]

Descrições de modelos de ciclo de vida podem ser documentadas como parte do conjunto de processos padrão da organização ou podem ser documentadas separadamente.

O conjunto de processos padrão da organização pode estar armazenado na biblioteca de ativos de processos da organização ou pode estar armazenado separadamente.

Um único repositório pode conter as medições e as documentações relacionadas a processos ou estas podem ser armazenadas separadamente..


Veja a área de processo de Foco no Processo Organizacional para obter maiores informações sobre assuntos relacionados aos processos organizacionais. [PA153.R101]


SG 1 Estabelecer os Ativos de Processos Organizacionais [PA153.IG101]

Um conjunto de ativos de processos organizacionais é estabelecido e mantido.




SG 1 Estabelecer os Ativos de Processos Organizacionais [PA153.IG101]

SP 1.1 Estabelecer Processos PadrãoSP 1.2 Estabelecer Descrições de Modelos de Ciclo de VidaSP 1.3 Estabelecer Critérios e Instruções de AdaptaçãoSP 1.4 Estabelecer o Repositório de Medições da OrganizaçãoSP 1.5 Estabelecer a Biblioteca de Ativos de Processos da Organização


GP 2.1 (CO 1) Estabelecer uma Política OrganizacionalGP 3.1 (AB 1) Estabelecer um Processo DefinidoGP 2.2 (AB 2) Planejar o ProcessoGP 2.3 (AB 3) Fornecer RecursosGP 2.4 (AB 4) Atribuir ResponsabilidadesGP 2.5 (AB 5) Treinar as Pessoas

Nível de Maturidade: 3, Definição do Processo Organizacional 347


GP 2.6 (DI 1) Gerenciar ConfiguraçõesGP 2.7 (DI 2) Identificar e Envolver os Stakeholders RelevantesGP 2.8 (DI 3) Monitorar e Controlar o ProcessoGP 3.2 (DI 4) Coletar Informações de MelhoriasGP 2.9 (VE 1) Avaliar Objetivamente a AderênciaGP 2.10 (VE 2) Revisar o Status com o Nível Mais Alto de Gerência


SG 1 Estabelecer os Ativos de Processos Organizacionais

Um conjunto de ativos de processos organizacionais é estabelecido e mantido. [PA153.IG101]

SP 1.1 Estabelecer Processos Padrão

Estabelecer e manter o conjunto de processos padrão da organização. [PA153.IG101.SP101]

Processos padrão podem ser definidos em diversos níveis em um empreendimento e podem estar relacionados de uma forma hierárquica. Por exemplo, um empreendimento pode ter um conjunto de processos padrão que é adaptado pelas organizações específicas (por exemplo, uma divisão ou localização) do empreendimento para estabelecer o seu conjunto de processos padrão. O conjunto de processos padrão pode também ser adaptado para cada uma das áreas de negócios ou linhas de produto da organização. Portanto, “o conjunto de processos padrão da organização” pode se referir aos processos padrão estabelecidos na organização e processos padrão que podem ser estabelecidos em níveis mais baixos, embora algumas organizações possam ter somente um único nível de processos padrão. Veja a definição de “processo padrão” no Apêndice B, o glossário. Veja no Capítulo 3 uma explicação de como o “conjunto de processos padrão da organização” é utilizado no CMMI Product Suite. [PA153.IG101.SP101.N101]

Diversos processos padrão podem ser necessários para tratar as necessidades de diferentes domínios de aplicação, modelos de ciclo de vida, metodologias e ferramentas. O conjunto de processos padrão da organização contém elementos de processos (por exemplo, um elemento de estimativa de tamanho de produto de trabalho) que podem ser interconectados, de acordo com uma ou mais arquiteturas de processos que descrevem as relações entre estes elementos de processos. Os processos podem ser compostos de outros processos ou elementos de processos. [PA153.IG101.SP101.N102]

O conjunto de processos padrão da organização normalmente inclui os processos técnicos, de gerenciamento, administrativos, de suporte e organizacionais. [PA153.IG101.SP101.N103]



O conjunto de processos padrão da organização deverá cobrir coletivamente todos os processos necessários pela organização e projetos, incluindo aqueles processos tratados pelas áreas de processos no Nível de Maturidade 2. [PA153.IG101.SP101.N104]


1. Conjunto de processos padrão da organização [PA153.IG101.SP101.W101]

Sub-práticas

1. Decompor cada processo padrão nos seus elementos de processos constituintes com os detalhes necessários para entender e descrever o processo. [PA153.IG101.SP101.SubP101]

Cada elemento de processo cobre um conjunto de atividades ligadas e fortemente relacionadas. As descrições dos elementos de processos podem ser templates a serem preenchidos, fragmentos a serem completados, abstrações a serem refinadas ou descrições completas a serem adaptadas ou utilizadas sem modificações. Estes elementos são descritos em detalhes suficientes de forma que o processo, quando totalmente definido, possa ser consistentemente executado pelas pessoas apropriadamente treinadas e habilitadas. [PA153.IG101.SP101.SubP101.N101]

Exemplos de elementos de processos incluem: [PA153.IG101.SP101.SubP101.N102]

Template para geração de estimativas de tamanho de produtos de trabalho

Descrição da metodologia de design do produto de trabalho

Metodologia adaptável de revisões por pares

Template para condução de revisões de gerenciamento

2. Especificar os atributos críticos de cada elemento de processo. [PA153.IG101.SP101.SubP102]

Exemplos de atributos críticos incluem: [PA153.IG101.SP101.SubP102.N101]

Papéis de processos

Processos e padrões de produtos aplicáveis

Procedimentos, métodos, ferramentas e recursos aplicáveis

Objetivos de desempenho de processos

Critérios de entradas (pré-condições)

Entradas (Inputs)

Medidas de produtos e processos a serem coletadas e utilizadas

Pontos de verificação (por exemplo, revisões por pares)

Saídas (Outputs)

Interfaces

Critérios de saída (pós-condições)



3. Especificar os relacionamentos entre os elementos de processos. [PA153.IG101.SP101.SubP103]

Exemplos de relacionamentos incluem: [PA153.IG101.SP101.SubP103.N101]

Ordem dos elementos de processos

Interfaces entre os elementos de processos

Interfaces com processos externos

Interdependências entre os elementos de processos

As regras para descrever os relacionamentos entre os elementos de processos são chamadas de “arquitetura de processo”. A arquitetura de processo cobre os requisitos essenciais e instruções. As especificações detalhadas destes relacionamentos são cobertos nas descrições dos processos definidos, que são adaptados a partir do conjunto de processos padrão da organização. [PA153.IG101.SP101.SubP103.N102]

4. Assegurar que o conjunto de processos padrão da organização adere às políticas aplicáveis; padrões e modelos de processos e padrões de produtos. [PA153.IG101.SP101.SubP104]

A aderência aos padrões e modelos de processos aplicáveis é normalmente demonstrada pelo desenvolvimento de um mapeamento do conjunto de processos padrão da organização com os padrões e modelos de processos relevantes. Além disso, este mapeamento será uma entrada útil para futuras avaliações. [PA153.IG101.SP101.SubP104.N101]

5. Assegurar que o conjunto de processos padrão da organização satisfaz as necessidades e objetivos de processos da organização. [PA153.IG101.SP101.SubP105]

Veja a área de processo de Foco no Processo Organizacional para obter maiores informações sobre o estabelecimento e a manutenção das necessidades e objetivos de processos da organização. [PA153.IG101.SP101.SubP105.R101]

6. Assegurar que há uma integração apropriada entre os processos que estão incluídos no conjunto de processos padrão da organização. [PA153.IG101.SP101.SubP106]

7. Documentar o conjunto de processos padrão da organização. [PA153.IG101.SP101.SubP107]

8. Conduzir revisões por pares no conjunto de processos padrão da organização. [PA153.IG101.SP101.SubP108]

Veja a área de processo de Verificação para obter maiores informações sobre revisões por pares. [PA153.IG101.SP101.SubP108.R101]

9. Revisar o conjunto de processos padrão da organização, conforme necessário. [PA153.IG101.SP101.SubP109]



SP 1.2 Estabelecer Descrições de Modelos de Ciclo de Vida

Estabelecer e manter descrições de modelos de ciclo de vida aprovadas para uso na organização. [PA153.IG101.SP102]

Modelos de ciclo de vida podem ser desenvolvidos para diversos clientes ou em diversas situações, uma vez que um modelo de ciclo de vida pode não ser apropriado para todas as situações. A organização pode identificar mais de um modelo de ciclo de vida para utilização. Normalmente, a organização precisa de modelos de ciclo de vida de para produtos e projetos, para os tipos de produtos que ela produz e para a definição de fases do projeto. [PA153.IG101.SP102.N101]

Modelos de ciclo de vida do produto particionam o ciclo de vida do produto em fases, para as quais as atividades e requisitos podem ser definidos para promover uma solução completa, desde o início do desenvolvimento do produto até o seu descarte final. [PA153.IG101.SP102.N102]


1. Descrições de modelos de ciclo de vida [PA153.IG101.SP102.W101]

Sub-práticas

1. Selecionar modelos de ciclo de vida baseados nas necessidades de projetos e da organização. [PA153.IG101.SP102.SubP101]

Por exemplo, no caso de um projeto de desenvolvimento, os modelos de ciclo de vida de projeto incluem: [PA153.IG101.SP102.SubP101.N101]

Cascata

Espiral

Evolucionário

Incremental

Iterativo

Exemplos de características de projetos que poderiam afetar os modelos de ciclo de vida incluem: [PA153.IG101.SP102.SubP101.N102]

Tamanho do projeto

Experiência e familiaridade da equipe do projeto na implementação do processo

Restrições como o tempo do ciclo e os níveis aceitáveis de defeitos

2. Documentar as descrições de modelos de ciclo de vida. [PA153.IG101.SP102.SubP102]

Os modelos de ciclo de vida podem ser documentados como parte do conjunto de processos padrão da organização ou podem ser documentados separadamente. [PA153.IG101.SP102.SubP102.N101]



3. Conduzir revisões por pares nos modelos de ciclo de vida. [PA153.IG101.SP102.SubP103]

Veja a área de processo de Verificação para obter maiores informações sobre como conduzir revisões por pares. [PA153.IG101.SP102.SubP103.R101]

4. Revisar as descrições de modelos de ciclo de vida, conforme necessário. [PA153.IG101.SP102.SubP104]

SP 1.3 Estabelecer Critérios e Instruções de Adaptação

Estabelecer e manter os critérios e instruções de adaptação para o conjunto de processos padrão da organização. [PA153.IG101.SP103]

Os critérios e instruções de adaptação descrevem o seguinte: [PA153.IG101.SP103.N101]

Como o conjunto de processos padrão da organização e os ativos de processos organizacionais são utilizados para criar os processos definidos

Requisitos obrigatórios que devem ser satisfeitos pelos processos definidos (por exemplo, o subconjunto dos ativos de processos organizacionais que é considerado essencial para qualquer processo definido)

Opções que podem ser exercitadas e critérios para a seleção entre as opções

Procedimentos que devem ser seguidos na execução e documentação da adaptação do processo

Exemplos de motivos para adaptação incluem: [PA153.IG101.SP103.N102]

Adaptar o processo para uma nova linha de produtos ou um novo ambiente

Customizar o processo para uma aplicação ou classe de aplicações específica (por exemplo, desenvolvimento inicial, manutenção ou criação de protótipos)

Elaborar a descrição do processo de forma que o processo definido resultante possa ser executado



A flexibilidade na adaptação e definição de processos é equilibrada assegurando a consistência apropriada dos processos em toda a organização. A flexibilidade é necessária para tratar as variáveis de contexto como o domínio; tipo de cliente; limitações de custo, cronograma e qualidade; dificuldades técnicas do trabalho e experiência das pessoas que estão implementando o processo. A consistência em toda a organização é necessária, de forma que os padrões organizacionais, objetivos e estratégias sejam apropriadamente tratados e os dados e lições aprendidas dos processos possam ser compartilhados. [PA153.IG101.SP103.N103]

Critérios e instruções de adaptação podem permitir o uso de um processo padrão “como está” (“as is”), sem adaptação. [PA153.IG101.SP103.N104]


1. Instruções de adaptação para o conjunto de processos padrão da organização [PA153.IG101.SP103.W101]

Sub-práticas

1. Especificar os critérios de seleção e procedimentos de adaptação do conjunto de processos padrão da organização. [PA153.IG101.SP103.SubP101]

Exemplos de critérios e procedimentos incluem: [PA153.IG101.SP103.SubP101.N101]

Critérios para selecionar modelos de ciclo de vida, a partir dos que foram aprovados pela organização

Critérios para selecionar elementos de processos, a partir do conjunto de processos padrão da organização

Procedimentos para adaptação de modelos de ciclo de vida e elementos de processos selecionados para acomodar características e necessidades específicas de processos

Exemplos de ações de adaptação incluem: [PA153.IG101.SP103.SubP101.N102]

Modificar um modelo de ciclo de vida

Combinar elementos de diferentes modelos de ciclo de vida

Modificar elementos de processos

Substituir elementos de processos

Reordenar elementos de processos

2. Especificar os padrões para documentar os processos definidos. [PA153.IG101.SP103.SubP102]

3. Especificar os procedimentos para submeter e obter a aprovação de dispensas de requisitos do conjunto de processos padrão da organização. [PA153.IG101.SP103.SubP103]



4. Documentar as instruções de adaptação para o conjunto de processos padrão da organização. [PA153.IG101.SP103.SubP104]

5. Conduzir revisões por pares nas instruções de adaptação. [PA153.IG101.SP103.SubP105]


6. Revisar as instruções de adaptação, conforme necessário. [PA153.IG101.SP103.SubP106]

SP 1.4 Estabelecer o Repositório de Medições da Organização

Estabelecer e manter o repositório de medições da organização. [PA153.IG101.SP104]

Veja a prática específica Utilizar os Ativos de Processos Organizacionais para Planejar as Atividades do Projeto da área de processo de Gerenciamento Integrado do Projeto para obter maiores informações sobre o uso do repositório de medições da organização nas atividades de planejamento do projeto. [PA153.IG101.SP104.R101]

O repositório contém medidas de produtos e processos que estão relacionadas ao conjunto de processos padrão da organização. Ele também contém ou faz referências às informações necessárias para entender e interpretar as medidas e avaliá-las com relação a sua motivação e aplicabilidade. Por exemplo, as definições de medidas são utilizadas para comparar medidas semelhantes, a partir de diferentes processos. [PA153.IG101.SP104.N101]


1. Definição do conjunto comum de medidas de produtos e processos para o conjunto de processos padrão da organização [PA153.IG101.SP104.W101]

2. Design do repositório de medições da organização [PA153.IG101.SP104.W102]

3. Repositório de medições da organização (isto é, a estrutura do repositório e o ambiente de suporte) [PA153.IG101.SP104.W103]

4. Dados de medições da organização [PA153.IG101.SP104.W104]

Sub-práticas

1. Determinar as necessidades da organização com relação ao armazenamento, recuperação e análise de medições. [PA153.IG101.SP104.SubP101]



2. Definir um conjunto comum de medidas de processos e produtos para o conjunto de processos padrão da organização. [PA153.IG101.SP104.SubP102]

As medidas no conjunto comum são selecionadas com base no conjunto de processos padrão da organização. O conjunto comum de medidas pode variar para diferentes processos padrão. [PA153.IG101.SP104.SubP102.N101]

Definições operacionais para as medidas especificam os procedimentos para coletar dados válidos e o ponto no processo onde os dados serão coletados. [PA153.IG101.SP104.SubP102.N102]

Exemplos de classes de medidas comumente utilizadas incluem: [PA153.IG101.SP104.SubP102.N103]

Estimativas de tamanho de produtos de trabalho (por exemplo, páginas)

Estimativas de esforço e custo (por exemplo, horas-homem)

Medidas reais de tamanho, esforço e custo

Medidas de qualidade (por exemplo, quantidade de defeitos encontrados, gravidade dos defeitos)

Cobertura das revisões por pares

Cobertura dos testes

Medidas de confiabilidade (por exemplo, intervalo de tempo até uma falha)

Veja a área de processo de Medições e Análises para obter maiores informações sobre como definir medidas. [PA153.IG101.SP104.SubP102.N103.R101]

3. Criar o design e implementar o repositório de medições. [PA153.IG101.SP104.SubP103]

4. Especificar os procedimentos para armazenagem, atualização e recuperação de medidas. [PA153.IG101.SP104.SubP104]

5. Conduzir revisões por pares nas definições do conjunto comum de medidas e nos procedimentos para armazenagem e recuperação de medidas. [PA153.IG101.SP104.SubP105]


6. Entrar com as medidas especificadas no repositório. [PA153.IG101.SP104.SubP106]

Veja a área de processo de Medições e Análises para obter maiores informações sobre como coletar e analisar dados. [PA153.IG101.SP104.SubP106.R101]



7. Tornar disponível o conteúdo do repositório de medições para uso da organização e dos projetos, conforme apropriado. [PA153.IG101.SP104.SubP107]

8. Revisar o repositório de medições, conjunto comum de medidas e procedimentos, conforme as necessidades da organização se modificam. [PA153.IG101.SP104.SubP108]

Exemplos de quando o conjunto comum de medidas pode precisar ser revisado incluem: [PA153.IG101.SP104.SubP108.N101]

Novos processos são adicionados

Processos são revisados e novas medidas de produtos ou processos são necessárias

Refinamento da granularidade dos dados é necessário

Maior visibilidade do processo é exigida

Medidas são descartadas

SP 1.5 Estabelecer a Biblioteca de Ativos de Processos da Organização

Estabelecer e manter a biblioteca de ativos de processos da organização. [PA153.IG101.SP105]

Exemplos de itens a serem armazenados na biblioteca de ativos de processos da organização incluem: [PA153.IG101.SP105.N101]

Políticas organizacionais

Descrições de processos definidos

Procedimentos (por exemplo, procedimentos de estimação)

Planos de desenvolvimento

Planos de garantia da qualidade

Materiais de treinamento

Auxiliares de processos (por exemplo, checklists)

Relatórios de lições aprendidas


1. Design da biblioteca de ativos de processos da organização [PA153.IG101.SP105.W101]

2. Biblioteca de ativos de processos da organização [PA153.IG101.SP105.W102]

3. Itens selecionados para serem incluídos na biblioteca de ativos de processos da organização [PA153.IG101.SP105.W103]

4. Catálogo de itens da biblioteca de ativos de processos da organização [PA153.IG101.SP105.W104]



Sub-práticas

1. Criar o design e implementar a biblioteca de ativos de processos da organização, incluindo a estrutura da biblioteca e o ambiente de suporte. [PA153.IG101.SP105.SubP101]

2. Especificar os critérios para incluir itens na biblioteca. [PA153.IG101.SP105.SubP102]

Os itens são selecionados baseados principalmente no seu relacionamento com o conjunto de processos padrão da organização. [PA153.IG101.SP105.SubP102.N101]

3. Especificar os procedimentos para armazenamento e recuperação de itens. [PA153.IG101.SP105.SubP103]

4. Entrar com os itens selecionados na biblioteca e catalogá-los para uma fácil referência e recuperação. [PA153.IG101.SP105.SubP104]

5. Tornar os itens disponíveis para utilização pelos projetos. [PA153.IG101.SP105.SubP105]

6. Periodicamente revisar a utilização de cada item e utilizar os resultados para manter o conteúdo da biblioteca. [PA153.IG101.SP105.SubP106]

7. Revisar a biblioteca de ativos de processos da organização, conforme necessário. [PA153.IG101.SP105.SubP107]

Exemplos de quando a biblioteca pode precisar ser revisada incluem: [PA153.IG101.SP105.SubP107.N101]

Novos itens são adicionados

Itens são descartados

As versões atuais de itens são modificadas



Compromissos


Estabelecer e manter uma política organizacional para planejar e executar o processo de definição do processo organizacional. [GP103]



Elaboração:

Esta política estabelece as expectativas organizacionais para estabelecer e manter um conjunto de processos padrão para utilização pela organização e tornar os ativos de processos organizacionais disponíveis em toda a organização. [PA153.EL101]

Habilitações


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


Estabelecer e manter o plano para execução do processo de definição do processo organizacional. [GP104]

Elaboração:

Normalmente, este plano para execução do processo de definição do processo organizacional é uma parte do plano de melhorias de processos da organização. [PA153.EL102]


Fornecer os recursos adequados para executar o processo de definição do processo organizacional, desenvolver os produtos de trabalho e fornecer os serviços do processo. [GP105]

Elaboração:

Um grupo de processos normalmente gerencia as atividades de definição do processo organizacional. Este grupo é normalmente formado por um núcleo de profissionais, cuja principal responsabilidade é coordenar a melhoria dos processos organizacionais. Este grupo é suportado pelos proprietários dos processos e pessoas com especialização em diversas disciplinas, tais como: [PA153.EL108]

Gerenciamento de projetos

As disciplinas de engenharia apropriadas


Garantia da qualidade




Sistemas de gerenciamento de banco de dados

Ferramentas de modelagem de processos

Construtores de páginas Web e browsers


Atribuir responsabilidades e autoridade para executar o processo, desenvolver os produtos de trabalho e fornecer os serviços do processo de definição do processo organizacional. [GP106]


Treinar as pessoas para executar e suportar o processo de definição do processo organizacional, conforme necessário. [GP107]

Elaboração:


CMMI e outros modelos de referência de processos e melhoria de processos

Processos de planejamento, gerenciamento e monitoramento

Modelagem e definição de processos

Desenvolvimento de um processo padrão adaptável

Implementações


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



Elaboração:


Conjunto de processos padrão da organização

Descrições de modelos de ciclos de vida

Instruções de adaptação para o conjunto de processos padrão da organização

Definições do conjunto comum de medidas de produtos e processos

Dados de medições da organização


Identificar e envolver os stakeholders relevantes do processo de definição do processo organizacional, conforme planejado. [GP124]

Elaboração:


Revisar o conjunto de processos padrão da organização

Revisar os modelos de ciclos de vida da organização

Resolver questões sobre as instruções de adaptação

Analisar as definições do conjunto comum de medidas de processos e produtos


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

Elaboração:


Percentual de projetos utilizando as arquiteturas de processos e elementos de processos do conjunto de processos padrão da organização

Densidade de defeitos de cada elemento de processo do conjunto de processos padrão da organização




Coletar produtos de trabalho, medidas, resultados de medições e informações de melhorias derivados do planejamento e execução do processo de definição do processo organizacional para suportar o uso futuro e a melhoria dos processos e ativos de processos da organização. [GP117]

Verificações


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

Elaboração:


Estabelecer ativos de processos organizacionais


Conjunto de processos padrão da organização

Descrições de modelos de ciclos de vida

Instruções de adaptação para o conjunto de processos padrão da organização

Dados de medições da organização


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



TREINAMENTO ORGANIZACIONAL


Objetivo

O objetivo do Treinamento Organizacional (Organizational Training) é desenvolver as habilidades e conhecimentos das pessoas, de forma que elas possam desempenhar seus papéis de maneira efetiva e eficiente. [PA158]


O Treinamento Organizacional inclui treinamento para suportar os objetivos estratégicos de negócios da organização e para atender as necessidades táticas de treinamento que são comuns entre projetos e grupos de suporte. Necessidades específicas de treinamento identificadas por projetos individuais e grupos de suporte são tratadas no projeto ou no grupo de suporte e estão fora do escopo do Treinamento Organizacional. O projeto e os grupos de suporte são responsável pela identificação e tratamento de suas necessidades específicas de treinamento. [PA158.N101]

Veja a área de processo de Planejamento do Projeto para obter maiores informações sobre as necessidades de treinamento específico identificadas pelos projetos. [PA158.N101.R101]

Um programa de treinamento organizacional envolve o seguinte: [PA158.N102]

Identificar o treinamento necessário pela organização

Obter e fornecer treinamento para atender aquelas necessidades

Estabelecer e manter a capacidade de treinamento

Estabelecer e manter registros de treinamento

Analisar a eficiência do treinamento

O treinamento efetivo requer a análise de necessidades, planejamento, projeto instrucional e mídia apropriada de treinamento (por exemplo, livros de trabalho, software), bem como um repositório de dados de processos de treinamento. Como um processo organizacional, os principais componentes do treinamento incluem um programa gerenciado de desenvolvimento do treinamento, planos documentados, pessoal com a especialização apropriada de disciplinas específicas e outras áreas de conhecimento e mecanismos para medição da eficiência do programa de treinamento. [PA158.N103]

Nível de Maturidade: 3, Treinamento Organizacional362


A identificação das necessidades de treinamento do processo é feita com base, principalmente, nas habilidades que são necessárias para executar o conjunto de processos padrão da organização. [PA158.N104]

Veja a área de processo de Definição do Processo Organizacional para obter maiores informações sobre o conjunto de processos padrão da organização. [PA158.N104.R101]

Certas habilidades podem ser efetiva e eficientemente distribuídas através de veículos diferentes das experiências normais de treinamento em classe (por exemplo, um mentoring informal). Outras habilidades exigem veículos de treinamento mais formais, como uma sala de aula, treinamento através da Web, auto-estudo dirigido ou através de um programa de treinamento formal on-the-job. Os veículos de treinamento formais e informais empregados para cada situação deverão ser baseados em uma análise da necessidade de treinamento e da deficiência de desempenho a ser tratada. O termo “treinamento” usado em toda esta área de processo é utilizado de forma abrangente para incluir todas estas opções de aprendizagem. [PA158.N105]

O sucesso no treinamento pode ser medido em termos da disponibilidade de oportunidades para adquirir as habilidades e conhecimentos necessários para executar novas atividades na empresa ou mesmo as atividades já existentes. [PA158.N106]

Habilidades e conhecimentos podem ser técnicos, organizacionais ou contextuais. Habilidades técnicas são pertinentes às habilidades no uso de equipamentos, ferramentas, materiais, dados e processos exigidos por um projeto ou processo. Habilidades organizacionais são pertinentes ao comportamento do empregado dentro e de acordo com a estrutura da organização, papéis e responsabilidades e princípios e métodos gerais de operação. Habilidades contextuais são o auto-gerenciamento, comunicação e as habilidades interpessoais necessárias para ter um bom desempenho no contexto organizacional e social do projeto e grupos de suporte. [PA158.N107]

A frase “projeto e grupos de suporte” é utilizada freqüentemente no texto da descrição desta área de processo para indicar uma perspectiva organizacional. [PA158.N108]


Veja a área de processo de Definição do Processo Organizacional para obter maiores informações sobre os ativos de processos da organização. [PA158.R101]

Veja a área de processo de Planejamento do Projeto para obter maiores informações sobre as necessidades de treinamento específico identificadas pelos projetos. [PA158.R102]

Nível de Maturidade: 3, Treinamento Organizacional 363


Veja a área de processo de Análises de Decisões e Resoluções para saber como aplicar critérios de tomada de decisões quando estiver definindo abordagens de treinamento. [PA158.R103]


SG 1 Estabelecer uma Capacidade de Treinamento Organizacional [PA158.IG101]

Uma capacidade de treinamento que suporta o gerenciamento e os papéis técnicos da organização é estabelecida e mantida.

SG 2 Fornecer o Treinamento Necessário[PA158.IG102]

O treinamento necessário para os indivíduos executarem seus papéis de forma eficiente é fornecido.




SG 1 Estabelecer uma Capacidade de Treinamento Organizacional [PA158.IG101]

SP 1.1 Estabelecer as Necessidades Estratégicas de TreinamentoSP 1.2 Determinar quais as Necessidades de Treinamento são de

Responsabilidade da OrganizaçãoSP 1.3 Estabelecer um Plano Tático de Treinamento OrganizacionalSP 1.4 Estabelecer a Capacidade de Treinamento

SG 2 Fornecer o Treinamento Necessário [PA158.IG102]

SP 2.1 Entregar o TreinamentoSP 2.2 Estabelecer Registros de TreinamentoSP 2.3 Analisar a Eficácia do Treinamento






SG 1 Estabelecer uma Capacidade de Treinamento Organizacional

Uma capacidade de treinamento que suporta os papéis técnicos e de gerenciamento da organização é estabelecida e mantida. [PA158.IG101]

A organização identifica o treinamento exigido para desenvolver as habilidades e conhecimentos necessários para desempenhar as atividades do empreendimento. Uma vez que as necessidades sejam identificadas, um programa de treinamento que trata estas necessidades é desenvolvido. [PA158.IG101.N101]

SP 1.1 Estabelecer as Necessidades Estratégicas de Treinamento

Estabelecer e manter as necessidades estratégicas de treinamento da organização. [PA158.IG101.SP101]

Exemplos de fontes de necessidades de treinamento estratégico incluem: [PA158.IG101.SP101.N101]

Processos padrão da organização

Plano estratégico de negócios da organização

Plano de melhoria de processos da organização

Iniciativas do empreendimento

Avaliações de habilidades

Análises de riscos


1. Necessidades de treinamento [PA158.IG101.SP101.W101]

2. Análises de avaliações [PA158.IG101.SP101.W102]

Sub-práticas

1. Analisar os objetivos estratégicos de negócios da organização e o plano de melhoria de processos para identificar futuras necessidades potenciais de treinamento. [PA158.IG101.SP101.SubP101]

2. Documentar as necessidades estratégicas de treinamento da organização. [PA158.IG101.SP101.SubP102]



Exemplos de categorias de necessidades de treinamento incluem (mas não estão limitados a): [PA158.IG101.SP101.SubP102.N101]

Análises e documentação de processos

Engenharia (por exemplo, análise de requisitos, design, testes, gerenciamento de configurações e garantia da qualidade)

Seleção e gerenciamento de fornecedores

Gerenciamento (por exemplo, estimativa, rastreamento e gerenciamento de riscos)

3. Determinar os papéis e habilidades necessários para executar o conjunto de processos padrão da organização. [PA158.IG101.SP101.SubP103]

4. Documentar o treinamento necessário para desempenhar os papéis no conjunto de processos padrão da organização. [PA158.IG101.SP101.SubP104]

5. Revisar as necessidades estratégicas da organização e o treinamento exigido, conforme necessário. [PA158.IG101.SP101.SubP105]

SP 1.2 Determinar quais as Necessidades de Treinamento são de Responsabilidade da Organização

Determinar quais necessidades de treinamento são de responsabilidade da organização e quais serão deixadas para o projeto individual ou grupo de suporte. [PA158.IG101.SP102]

Veja a área de processo de Planejamento do Projeto para obter maiores informações sobre planos de treinamento específicos do projeto e de grupos de suporte. [PA158.IG101.SP102.R101]

Além das necessidades estratégicas de treinamento, o treinamento organizacional trata dos requisitos de treinamento que são comuns em todos os projetos e grupos de suporte. Os projetos e grupos de suporte têm a responsabilidade principal de identificar e tratar suas necessidades específicas de treinamento. A equipe de treinamento da organização somente é responsável por tratar as necessidades de treinamento entre projetos e grupos de suporte. Em alguns casos, entretanto, a equipe de treinamento da organização pode tratar necessidades adicionais de treinamento de projetos e grupos de suporte, conforme for negociado, dentro do contexto dos recursos de treinamento disponíveis e das prioridades de treinamento da organização. [PA158.IG101.SP102.N101]


1. Necessidades de treinamento comuns dos projetos e dos grupos de suporte [PA158.IG101.SP102.W101]

2. Compromissos de treinamento [PA158.IG101.SP102.W102]



Sub-práticas

1. Analisar as necessidades de treinamento identificadas pelos diversos projetos e grupos de suporte. [PA158.IG101.SP102.SubP101]

Análises das necessidades dos projetos e grupos de suporte pretendem identificar necessidades comuns de treinamento que podem ser mais eficientemente tratadas com uma abrangência organizacional. Estas atividades de análises de necessidades são utilizadas para antecipar futuras necessidades de treinamento que são inicialmente visíveis no nível do projeto ou do grupo de suporte. [PA158.IG101.SP102.SubP101.N101]

2. Negociar com os diversos projetos e grupos de suporte sobre como suas necessidades específicas de treinamento serão satisfeitas. [PA158.IG101.SP102.SubP102]

O suporte fornecido pela equipe de treinamento da organização depende dos recursos de treinamento disponíveis e das prioridades de treinamento da organização. [PA158.IG101.SP102.SubP102.N101]

Exemplos de treinamentos executados apropriadamente pelo projeto ou pelo grupo de suporte incluem: [PA158.IG101.SP102.SubP102.N102]

Treinamento no domínio da aplicação do projeto

Treinamento nas ferramentas e métodos únicos utilizados pelo projeto ou grupo de suporte

3. Documentar os compromissos para o fornecimento de suporte de treinamento para os projetos e grupos de suporte. [PA158.IG101.SP102.SubP103]

SP 1.3 Estabelecer um Plano Tático de Treinamento Organizacional

Estabelecer e manter um plano tático de treinamento organizacional. [PA158.IG101.SP103]

O plano tático de treinamento organizacional é o plano para entregar o treinamento que é responsabilidade da organização. Este plano é ajustado periodicamente como resposta a mudanças (por exemplo, em necessidades ou recursos) e para avaliar a sua eficiência. [PA158.IG101.SP103.N101]


1. Plano tático de treinamento organizacional [PA158.IG101.SP103.W101]

Sub-práticas

1. Estabelecer o conteúdo do plano. [PA158.IG101.SP103.SubP101]

Os planos táticos de treinamento organizacional normalmente contêm: [PA158.IG101.SP103.SubP101.N101]



Necessidades de treinamento

Tópicos de treinamento

Cronogramas baseados nas atividades de treinamento e suas dependências

Métodos utilizados para o treinamento

Requisitos e padrões de qualidade para os materiais de treinamento

Tarefas, papéis e responsabilidades de treinamento

Recursos necessários incluindo ferramentas, recursos, ambientes, equipes, habilidades e conhecimentos

2. Estabelecer compromissos com o plano. [PA158.IG101.SP103.SubP102]

Compromissos documentados por aqueles que são responsáveis por implementar e suportar o plano são essenciais para que o plano seja eficiente. [PA158.IG101.SP103.SubP102.N101]

3. Revisar o plano e compromissos, conforme necessário. [PA158.IG101.SP103.SubP103]

SP 1.4 Estabelecer a Capacidade de Treinamento

Estabelecer e manter a capacidade de treinamento para atender as necessidades de treinamento organizacional. [PA158.IG101.SP104]

Veja a área de processo de Análises de Decisões e Resoluções para saber como aplicar critérios de tomada de decisões quando estiver selecionando abordagens de treinamento e desenvolvendo materiais de treinamento. [PA158.IG101.SP104.R101]


1. Materiais de treinamento e artefatos de suporte [PA158.IG101.SP104.W101]

Sub-práticas

1. Selecionar as abordagens apropriadas para satisfazer necessidades específicas de treinamento organizacional. [PA158.IG101.SP104.SubP101]

Muitos fatores podem afetar a seleção de abordagens de treinamento, incluindo o conhecimento de uma audiência específica, custos e cronograma, ambiente de trabalho, entre outros. A seleção de uma abordagem exige a consideração dos meios para fornecimento de habilidades e conhecimento da forma mais eficiente possível, consideradas as restrições. [PA158.IG101.SP104.SubP101.N101]



Exemplos de abordagens de treinamento incluem: [PA158.IG101.SP104.SubP101.N102]

Treinamento em sala de aula

Instrução auxiliada por computador

Auto-estudo dirigido

Programas formais de aprendizes e mentoring

Vídeos de facilitação

Conversas informais (Chalk talks)

Seminários em locais de almoço (Brown-bag lunch seminars)

Treinamento estruturado on-the-job

2. Determinar se os materiais de treinamento serão desenvolvidos internamente ou adquiridos externamente. [PA158.IG101.SP104.SubP102]

Determinar os custos e benefícios do desenvolvimento interno do treinamento ou da obtenção do treinamento externamente. [PA158.IG101.SP104.SubP102.N101]

Exemplos de critérios que podem ser utilizados para determinar o modo mais eficiente de aquisição de conhecimentos e habilidades incluem[PA158.IG101.SP104.SubP102.N102]

Objetivos de desempenho

Tempo disponível para preparar a execução do projeto

Objetivos de negócios

Disponibilidade de especialização interna

Disponibilidade do treinamento em fontes externas

Exemplos de fontes externas de treinamento incluem: [PA158.IG101.SP104.SubP102.N103]

Treinamento fornecido pelo cliente

Cursos de treinamento disponíveis comercialmente

Programas acadêmicos

Conferências profissionais

Seminários

3. Desenvolver ou obter materiais de treinamento. [PA158.IG101.SP104.SubP103]

O treinamento pode ser fornecido pelo projeto, por grupos de suporte, pela organização ou por uma organização externa. A equipe de treinamento da organização coordena a aquisição e entrega do treinamento, independente de sua fonte. [PA158.IG101.SP104.SubP103.N101]



Exemplos de materiais de treinamento incluem: [PA158.IG101.SP104.SubP103.N102]

Cursos

Instrução auxiliada por computador

Vídeos

4. Desenvolver ou obter instrutores qualificados. [PA158.IG101.SP104.SubP106]

Para assegurar que os instrutores de treinamento obtidos internamente possuem as habilidades necessárias e conhecimentos de treinamento, critérios podem ser definidos para identificá-los, desenvolvê-los e qualificá-los. No caso de treinamento obtido externamente, a equipe de treinamento da organização pode investigar como o fornecedor do treinamento determina quais instrutores estarão fornecendo o treinamento. Isto também pode ser um fator na seleção e continuidade de uso de um fornecedor de treinamento específico. [PA158.IG101.SP104.SubP106.N101]

5. Descrever o treinamento no currículo de treinamentos da organização. [PA158.IG101.SP104.SubP104]

Exemplos de informações fornecidas nas descrições de treinamento para cada curso incluem: [PA158.IG101.SP104.SubP104.N101]

Tópicos cobertos no treinamento

Audiência pretendida

Pré-requisitos e preparação para a participação

Objetivos do treinamento

Duração do treinamento

Planos de lições

Critérios para completar o curso

Critérios para fornecer dispensas do treinamento

6. Revisar os materiais de treinamento e artefatos de suporte, conforme necessário. [PA158.IG101.SP104.SubP105]

Exemplos de situações nas quais os materiais de treinamento e artefatos de suporte podem precisar ser revisados incluem: [PA158.IG101.SP104.SubP105.N101]

Mudanças de necessidades de treinamento (por exemplo, quando novas tecnologias associadas com o tópico de treinamento são disponibilizadas)

Uma avaliação do treinamento identifica a necessidade de mudanças (por exemplo, avaliações de pesquisas de eficiência do treinamento, avaliações de desempenho de programas de treinamento ou formulários de avaliação de instrutores)



SG 2 Fornecer o Treinamento Necessário

O treinamento necessário para os indivíduos executarem seus papéis de forma eficiente é fornecido. [PA158.IG102]

Na seleção das pessoas a serem treinadas, o seguinte deverá ser levado em conta: [PA158.IG102.N101]

Histórico da população alvo de participantes do treinamento

Pré-requisitos de histórico para receber treinamento

Habilidades e habilitações necessárias pelas pessoas para desempenhar seus papéis

Necessidade de treinamento técnico-gerencial entre disciplinas para todas as disciplinas, incluindo gerenciamento de projetos

Necessidade de gerentes terem treinamento nos processos organizacionais apropriados

Necessidade para treinamento nos princípios básicos da engenharia de disciplinas específicas para apoiar o pessoal no gerenciamento da qualidade, gerenciamento de configurações e outras funções de suporte relacionadas

Necessidade de fornecer desenvolvimento de competências para áreas funcionais críticas

SP 2.1 Entregar o Treinamento

Entregar o treinamento seguindo o plano tático de treinamento organizacional. [PA158.IG102.SP101]


1. Curso de treinamento entregue [PA158.IG102.SP101.W101]

Sub-práticas

1. Selecionar as pessoas que irão receber o treinamento. [PA158.IG102.SP101.SubP101]

O treinamento pretende distribuir conhecimentos e habilidades para as pessoas que desempenham diversos papéis dentro da organização. Algumas pessoas já possuem o conhecimento e habilidades necessárias para desempenhar bem os papéis que lhe foram designados. O treinamento pode ser dispensado para estas pessoas, mas deverá se tomar cuidado para que estas dispensas de treinamento não sejam abusivas. [PA158.IG102.SP101.SubP101.N101]

2. Criar o cronograma do treinamento, incluindo os recursos, conforme necessário (por exemplo, locais e instrutores). [PA158.IG102.SP101.SubP102]



O treinamento deverá ser planejado e deverá ser criado um cronograma. O treinamento é fornecido de forma que tenha uma visibilidade direta nas expectativas de desempenho do trabalho. Portanto, um treinamento ótimo ocorre de uma maneira pontual com relação às expectativas iminentes de desempenho do trabalho. Estas expectativas freqüentemente incluem: [PA158.IG102.SP101.SubP102.N101]

Treinamento no uso de ferramentas especializadas

Treinamento em procedimentos que são novidade para os indivíduos que irão desempenhá-los

3. Conduzir o treinamento. [PA158.IG102.SP101.SubP103]

Instrutores experientes deverão executar o treinamento. Quando possível, o treinamento é conduzido em conjuntos que demonstrem de forma aproximada as condições reais de desempenho e incluam atividades para simular situações reais de trabalho. Esta abordagem inclui a integração de ferramentas, métodos e procedimentos para o desenvolvimento de competências. O treinamento está ligado às responsabilidades do trabalho, de forma que atividades on-the-job ou outras experiências de fora irão reforçar o treinamento, dentro de um prazo razoável após o treinamento. [PA158.IG102.SP101.SubP103.N101]

4. Rastrear a entrega do treinamento contra o plano. [PA158.IG102.SP101.SubP104]

SP 2.2 Estabelecer Registros de Treinamento

Estabelecer e manter registros do treinamento organizacional. [PA158.IG102.SP102]

Veja a área de processo de Monitoramento e Controle do Projeto para obter informações sobre como os registros de treinamento do projeto e dos grupos de suporte são mantidos. [PA158.IG102.SP102.R101]

O escopo desta prática é o do treinamento executado no nível da organização. O estabelecimento e manutenção de registros de treinamento para treinamentos patrocinados pelo projeto ou por grupos de suporte é de responsabilidade de cada projeto individual ou grupo de suporte. [PA158.IG102.SP102.N101]


1. Registros de treinamento [PA158.IG102.SP102.W101]

2. Atualizações de treinamento no repositório organizacional [PA158.IG102.SP102.W102]

Sub-práticas

1. Manter registros de todos os estudantes que completaram com sucesso cada curso do treinamento ou outras atividades de treinamento aprovadas, bem como daqueles que não foram bem sucedidos. [PA158.IG102.SP102.SubP101]



2. Manter registros de toda a equipe que foi dispensada de um treinamento específico. [PA158.IG102.SP102.SubP102]

A justificativa para obter uma dispensa deverá ser documentada e tanto o gerente responsável como o gerente do indivíduo dispensado deverão aprovar a dispensa do treinamento organizacional. [PA158.IG102.SP102.SubP102.N101]

3. Manter registros de todos os estudantes que completaram com sucesso seus treinamentos necessários exigidos. [PA158.IG102.SP102.SubP103]

4. Tornar disponíveis registros de treinamento para as pessoas apropriadas para considerações em atribuições. [PA158.IG102.SP102.SubP104]

Registros de treinamento podem ser parte da matriz de habilidades desenvolvida pela organização do treinamento, de forma a fornecer um resumo da experiência e educação das pessoas, bem como do treinamento patrocinado pela organização. [PA158.IG102.SP102.SubP104.N101]

SP 2.3 Analisar a Eficácia do Treinamento

Analisar a eficácia do programa de treinamento da organização. [PA158.IG102.SP103]

Deverá existir um processo para determinar a eficácia do treinamento (isto é, se o treinamento está atendendo as necessidades da organização). [PA158.IG102.SP103.N101]

Exemplos de métodos utilizados para analisar a eficácia do treinamento incluem: [PA158.IG102.SP103.N103]

Testes no contexto do treinamento

Pesquisas após o treinamento com os participantes

Pesquisas de satisfação dos gerentes com relação aos efeitos após o treinamento

Mecanismos de avaliação embutidos no material do curso

Medidas devem ser tomadas para analisar o valor agregado pelo treinamento contra os objetivos do projeto e da organização. Atenção particular deverá ser tomada com relação à necessidade de diversos métodos de treinamento, como equipes de treinamento em tempo integral. Quando utilizados, os objetivos de desempenho deverão ser compartilhados com os participantes do curso e deverão ser não ambíguos, observáveis e verificáveis. Os resultados da avaliação da eficácia do treinamento deverá ser utilizado para revisar materiais de treinamento, conforme descrito acima na prática específica Estabelecer a Capacidade de Treinamento. [PA158.IG102.SP103.N102]




1. Pesquisas de eficácia do treinamento [PA158.IG102.SP103.W101]

2. Avaliações de desempenho do programa de treinamento [PA158.IG102.SP103.W102]

3. Formulários de avaliação do instrutor [PA158.IG102.SP103.W103]

4. Exames de treinamento [PA158.IG102.SP103.W104]

Sub-práticas

1. Analisar projetos em progresso ou completados para determinar se o conhecimento da equipe é adequado para executar as tarefas do projeto. [PA158.IG102.SP103.SubP101]

2. Fornecer um mecanismo para analisar a eficácia de cada curso de treinamento com relação aos objetivos organizacionais, do projeto ou de aprendizagem (ou desempenho) individual estabelecidos. [PA158.IG102.SP103.SubP102]

3. Obter avaliações dos estudantes com relação a se as atividades de treinamento satisfizeram suas necessidades. [PA158.IG102.SP103.SubP103]



Compromissos


Estabelecer e manter uma política organizacional para planejar e executar o processo de treinamento organizacional. [GP103]

Elaboração:

Esta política estabelece as expectativas organizacionais para identificar as necessidades estratégicas de treinamento da organização e fornecer o treinamento necessário. [PA158.EL101]



Habilitações


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


Estabelecer e manter o plano para execução do processo de treinamento organizacional. [GP104]

Elaboração:

Este plano para executar o processo de treinamento organizacional difere do plano tático de treinamento organizacional descrito em uma prática específica desta área de processo. O plano tratado nesta prática genérica trata do planejamento abrangente para todas as práticas específicas desta área de processo, do estabelecimento de necessidades estratégicas de treinamento até a avaliação da eficácia do esforço de treinamento organizacional. Em contraste, o plano tático de treinamento organizacional tratado na prática específica trata do planejamento periódico para a entrega de ofertas individuais de treinamento. [PA158.EL102]


Fornecer os recursos adequados para executar o processo de treinamento organizacional, desenvolver os produtos de trabalho e fornecer os serviços do processo. [GP105]

Elaboração:

Exemplos de pessoas (de tempo integral ou parcial, internos ou externos) e habilidades necessárias incluem: [PA158.EL104]

Experts no assunto

Projetistas de currículos

Projetistas instrucionais

Instrutores

Administradores de treinamento



Recursos especiais podem ser exigidos para o treinamento. Quando necessário, os recursos exigidos pelas atividades da área de processo de Treinamento Organizacional são desenvolvidos ou comprados. [PA158.EL118]


Instrumentos para a análise de necessidades de treinamento

Estações de trabalho para serem utilizadas no treinamento

Ferramentas de design instrucional

Pacotes para o desenvolvimento de materiais de apresentação


Atribuir responsabilidades e autoridade para executar o processo, desenvolver os produtos de trabalho e fornecer os serviços do processo de treinamento organizacional. [GP106]


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

Elaboração:


Análises de necessidades de conhecimentos e habilidades

Design instrucional

Técnicas instrucionais (por exemplo, treinar o treinador)

Atualizar o treinamento no assunto

Implementações


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



Elaboração:


Plano tático de treinamento organizacional

Registros do treinamento

Materiais de treinamento e artefatos de suporte

Formulários de avaliação do instrutor


Identificar e envolver os stakeholders relevantes do processo de treinamento organizacional, conforme planejado. [GP124]

Elaboração:


Estabelecer um ambiente colaborativo para a discussão das necessidades e eficácia do treinamento, para assegurar que as necessidades de treinamento da organização estão sendo atendidas

Identificar necessidades de treinamento

Revisar o plano tático de treinamento organizacional

Analisar a eficácia do treinamento


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

Elaboração:


Quantidade de cursos de treinamento entregues (por exemplo, planejados versus reais)

Classificações de avaliações pós-treinamento

Classificações de pesquisas de qualidade do programa de treinamento




Coletar produtos de trabalho, medidas, resultados de medições e informações de melhorias derivados do planejamento e execução do processo de treinamento organizacional para suportar o uso futuro e a melhoria dos processos e ativos de processos da organização. [GP117]

Verificações


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

Elaboração:


Identificar necessidades de treinamento e tornar os treinamentos disponíveis

Fornecer o treinamento necessário


Plano tático de treinamento organizacional

Materiais de treinamento e artefatos de suporte

Formulários de avaliação de instrutores


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



GERENCIAMENTO INTEGRADO DO PROJETO


Objetivo

O objetivo do Gerenciamento Integrado do Projeto (Integrated Project Management) é estabelecer e gerenciar o projeto e o envolvimento dos stakeholders relevantes, de acordo com um processo integrado e definido que é adaptado a partir do conjunto de processos padrão da organização. [PA167]


O Gerenciamento Integrado do Projeto envolve o seguinte: [PA167.N102]

Estabelecer o processo definido do projeto através da adaptação do conjunto de processos padrão da organização

Gerenciar o projeto utilizando o processo definido do projeto

Utilizar e contribuir para os ativos de processos organizacionais

Possibilitar que as preocupações dos stakeholders relevantes sejam identificadas, consideradas e, quando apropriado, tratadas durante o desenvolvimento do produto

Assegurar que os stakeholders relevantes executem suas tarefas de uma maneira coordenada e pontual (1) para tratar os requisitos do produto e dos componentes do produto, planos, objetivos, questões e riscos; (2) cumprir seus compromissos; e (3) identificar, rastrear e resolver questões

O processo integrado e definido que é adaptado a partir do conjunto de processos padrão da organização é chamado de processo definido do projeto. [PA167.N110]

O gerenciamento dos esforços, custo, cronograma, pessoal, riscos e outros fatores do projeto está ligado aos processos definidos do projeto. A implementação e gerenciamento do processo definido do projeto são normalmente descritos no plano do projeto. Certas atividades podem ser cobertas em outros planos que afetam o projeto, tais como o plano de garantia da qualidade, a estratégia de gerenciamento de riscos e o plano de gerenciamento de configurações. [PA167.N103]

Nível de Maturidade: 3, Gerenciamento Integrado do Projeto 379


Uma vez que o processo definido para cada projeto é adaptado a partir do conjunto de processos padrão da organização, a variabilidade entre os projetos é normalmente reduzida e os projetos podem mais facilmente compartilhar ativos de processos, dados e lições aprendidas. [PA167.N104]

Esta área de processo também trata da coordenação de todas as atividades associadas com o projeto, incluindo: [PA167.N105]

Atividades técnicas como o desenvolvimento de requisitos, o design e a verificação

Atividades de suporte como o gerenciamento de configurações, documentação, marketing e treinamento

As interfaces e interações do trabalho entre os stakeholders relevantes internos e externos ao projeto são planejadas e gerenciadas para assegurar a qualidade e integridade do produto como um todo. Os stakeholders relevantes participam, conforme apropriado, na definição do processo definido do projeto e do plano do projeto. Revisões e trocas são regularmente conduzidas com os stakeholders relevantes e questões de coordenação recebem a apropriada atenção. Revisões e trocas são regularmente conduzidas com os stakeholders relevantes para assegurar que as questões de coordenação recebem a atenção apropriada e que todos os envolvidos com o projeto estão adequadamente cientes dos status, planos e atividades. Na definição do processo definido do projeto, interfaces formais são criadas, conforme necessário, para assegurar que a coordenação e colaboração apropriadas ocorram. [PA167.N107]

Veja o Capítulo 3 para uma explicação de como o termo “stakeholder relevante” é utilizado no CMMI Product Suite. [PA167.N106]

Esta área de processo se aplica a qualquer estrutura organizacional, incluindo projetos que são estruturados como organizações em linha, organizações matriciais ou equipes integradas. A terminologia deverá ser apropriadamente interpretada para a estrutura organizacional utilizada. [PA167.N108]


Veja a área de processo de Planejamento do Projeto para obter maiores informações sobre o planejamento do projeto. [PA167.R101]

Veja a área de processo de Monitoramento e Controle do Projeto para obter maiores informações sobre o monitoramento e controle do projeto. [PA167.R102]



Veja a área de processo de Planejamento do Projeto para obter maiores informações sobre a identificação de stakeholders relevantes e seu envolvimento apropriado no projeto. [PA167.R103]

Veja a área de processo de Verificação para obter maiores informações sobre revisões por pares. [PA167.R104]

Veja a área de processo de Definição do Processo Organizacional para obter maiores informações sobre os ativos organizacionais de processos. [PA167.R105]

Veja a área de processo de Medições e Análises para obter maiores informações sobre a definição de um processo para os processos de medições e análises. [PA167.R106]


SG 1 Utilizar o Processo Definido do Projeto [PA167.IG101]

O projeto é conduzido utilizando um processo definido que é adaptado a partir do conjunto de processos padrão da organização.

SG 2 Coordenar e Colaborar com os Stakeholders Relevantes[PA167.IG102]

A coordenação e colaboração do projeto com os stakeholders relevantes é conduzida.




SG 1 Utilizar o Processo Definido do Projeto [PA167.IG101]

SP 1.1 Estabelecer o Processo Definido do ProjetoSP 1.2 Utilizar os Ativos de Processos Organizacionais para o Planejamento

das Atividades do ProjetoSP 1.3 Integrar os PlanosSP 1.4 Gerenciar o Projeto Utilizando os Planos IntegradosSP 1.5 Contribuir para os Ativos de Processos Organizacionais

SG 2 Coordenar e Colaborar com os Stakeholders Relevantes[PA167.IG102]

SP 2.1 Gerenciar o Envolvimento dos StakeholdersSP 2.2 Gerenciar DependênciasSP 2.3 Resolver Questões de Coordenação


GP 2.1 (CO 1) Estabelecer uma Política OrganizacionalGP 3.1 (AB 1) Estabelecer um Processo Definido



GP 2.2 (AB 2) Planejar o ProcessoGP 2.3 (AB 3) Fornecer RecursosGP 2.4 (AB 4) Atribuir ResponsabilidadesGP 2.5 (AB 5) Treinar as PessoasGP 2.6 (DI 1) Gerenciar ConfiguraçõesGP 2.7 (DI 2) Identificar e Envolver os Stakeholders RelevantesGP 2.8 (DI 3) Monitorar e Controlar o ProcessoGP 3.2 (DI 4) Coletar Informações de MelhoriasGP 2.9 (VE 1) Avaliar Objetivamente a AderênciaGP 2.10 (VE 2) Revisar o Status com o Nível Mais Alto de Gerência


SG 1 Utilizar o Processo Definido do Projeto

O projeto é conduzido utilizando um processo definido que é adaptado a partir do conjunto de processos padrão da organização. [PA167.IG101]

O processo definido do projeto deve incluir aqueles processos do conjunto de processos padrão da organização que tratam todos os processos necessários para desenvolver e manter o produto. Os processos de ciclo de vida relativos aos produtos, como os processos de manufatura e suporte, são desenvolvidos de forma paralela com o produto. [PA167.IG101.N101]

SP 1.1 Estabelecer o Processo Definido do Projeto

Estabelecer e manter o processo definido do projeto. [PA167.IG101.SP101]

Veja a área de processo de Definição do Processo Organizacional para obter maiores informações sobre os ativos de processos organizacionais. [PA167.IG101.SP101.R101]

Veja a área de processo de Foco no Processo Organizacional para obter maiores informações sobre as necessidades e objetivos do processo organizacional. [PA167.IG101.SP101.R102]

O processo definido do projeto consiste de processos definidos que formam um ciclo de vida integrado e coerente para o projeto. [PA167.IG101.SP101.N101]

O processo definido do projeto cobre todos os processos necessários para o projeto, incluindo aqueles processos tratados pelas áreas de processos do nível de maturidade 2. [PA167.IG101.SP101.N103]



O processo definido do projeto deverá satisfazer as necessidades contratuais e operacionais do projeto, suas oportunidades e restrições. Ele é projetado para fornecer um melhor atendimento às necessidades do projeto. Um processo definido do projeto é baseado no seguinte: [PA167.IG101.SP101.N102]

Requisitos do cliente


Compromissos

Necessidades e objetivos de processos organizacionais

Ambiente operacional

Ambiente de negócios


1. O processo definido do projeto [PA167.IG101.SP101.W101]

Sub-práticas

1. Selecionar um modelo de ciclo de vida entre aqueles que estão disponíveis nos ativos de processos organizacionais. [PA167.IG101.SP101.SubP101]

2. Selecionar os processos padrão do conjunto de processos padrão da organização que melhor atendem as necessidades do projeto. [PA167.IG101.SP101.SubP102]

3. Adaptar o conjunto de processos padrão da organização e outros ativos de processos organizacionais, de acordo com as instruções de adaptação, para produzir o processo definido do projeto. [PA167.IG101.SP101.SubP103]

Algumas vezes, os modelos de ciclo de vida e processos padrão disponíveis são inadequados para atender necessidades de um projeto específico. Algumas vezes, o projeto será incapaz de produzir os produtos de trabalho ou medidas exigidos. Em tais circunstâncias, o projeto precisará obter a aprovação para se desviar do que é exigido pela organização. As dispensas são fornecidas com este propósito. [PA167.IG101.SP101.SubP103.N101]

4. Utilizar outros artefatos da biblioteca de ativos de processos da organização, conforme apropriado. [PA167.IG101.SP101.SubP104]

Outros artefatos podem incluir: [PA167.IG101.SP101.SubP104.N101]

Documentos de lições aprendidas

Templates

Documentos exemplo

Modelos de estimação

5. Documentar o processo definido do projeto. [PA167.IG101.SP101.SubP105]



O processo definido do projeto cobre todas as atividades de engenharia, gerenciamento e de suporte para o projeto e suas interfaces com os stakeholders relevantes. [PA167.IG101.SP101.SubP105.N101]

Exemplos de atividades do projeto incluem: [PA167.IG101.SP101.SubP105.N102]

Planejamento do projeto

Monitoramento e controle do projeto

Desenvolvimento de requisitos

Gerenciamento de requisitos

Design e implementação

Verificação e validação

Integração do produto

Gerenciamento de aquisição


Garantia da qualidade

6. Conduzir revisões por pares no processo definido do projeto. [PA167.IG101.SP101.SubP106]


7. Revisar o processo definido do projeto, conforme necessário. [PA167.IG101.SP101.SubP107]

SP 1.2 Utilizar os Ativos de Processos Organizacionais para o Planejamento das Atividades do Projeto

Utilizar os ativos de processos organizacionais e o repositório de medições para estimar e planejar as atividades do projeto. [PA167.IG101.SP102]

Veja a área de processo de Definição do Processo Organizacional para obter maiores informações sobre os ativos de processos organizacionais e o repositório de medições da organização. [PA167.IG101.SP102.R101]


1. Estimativas do projeto [PA167.IG101.SP102.W101]

2. Planos do projeto [PA167.IG101.SP102.W102]



Sub-práticas

1. Basear as atividades de estimativa e planejamento em tarefas e produtos de trabalho do processo definido do projeto. [PA167.IG101.SP102.SubP101]

Um entendimento das relações entre as diversas tarefas e produtos de trabalho do processo definido do projeto e dos papéis a serem desempenhados pelos stakeholders relevantes é a base para o desenvolvimento de um plano realista. [PA167.IG101.SP102.SubP101.N101]

2. Utilizar o repositório de medições da organização na estimativa dos parâmetros de planejamento do projeto. [PA167.IG101.SP102.SubP102]

Esta estimativa normalmente inclui: [PA167.IG101.SP102.SubP102.N101]

Utilizar dados históricos apropriados deste projeto ou de projetos semelhantes

Comunicar e registrar semelhanças e diferenças entre o projeto atual e aqueles projetos cujos dados históricos serão utilizados

Validar de forma independente os dados históricos

Registrar o motivo, premissas e justificativas utilizadas para selecionar os dados históricos

Exemplos de parâmetros que são considerados com relação a similaridades e diferenças incluem: [PA167.IG101.SP102.SubP102.N102]

Atributos de produtos de trabalho e tarefas


Abordagem de design

Ambiente operacional

Experiência das pessoas

Exemplos de dados contidos no repositório de medições da organização incluem: [PA167.IG101.SP102.SubP102.N103]

Tamanho e outros atributos dos produtos de trabalho

Esforço

Custo

Cronograma

Pessoal

Defeitos

SP 1.3 Integrar os Planos

Integrar o plano do projeto e outros planos que afetam o projeto para descrever o processo definido do projeto. [PA167.IG101.SP103]



Veja a área de processo de Planejamento do Projeto para obter maiores informações sobre o estabelecimento e manutenção de um plano de projeto. [PA167.IG101.SP103.R101]

Veja a área de processo de Definição do Processo Organizacional para obter maiores informações sobre os ativos de processos organizacionais e, em particular, o repositório de medições da organização. [PA167.IG101.SP103.R102]

Veja a área de processo de Medições e Análises para obter maiores informações sobre a definição de medidas e atividades de medições e utilização de técnicas analíticas. [PA167.IG101.SP103.R103]

Veja a área de processo de Gerenciamento de Riscos para obter maiores informações sobre a identificação e análise de riscos. [PA167.IG101.SP103.R104]

Veja a área de processo de Foco no Processo Organizacional para obter maiores informações sobre as necessidades e objetivos do processo organizacional. [PA167.IG101.SP103.R105]

Esta prática específica estende as práticas específicas para o estabelecimento e manutenção de um plano de projeto, para que tratem atividades adicionais de planejamento, tais como incorporar o processo definido do projeto, coordenar com os stakeholders relevantes, utilizar os ativos de processos organizacionais, incorporar planos para revisões por pares e estabelecer critérios objetivos de entrada e saída para as tarefas. [PA167.IG101.SP103.N101]

O desenvolvimento do plano do projeto deverá comunicar as necessidades atuais e projetadas, os objetivos e requisitos da organização, do cliente e dos usuários finais, conforme apropriado. [PA167.IG101.SP103.N102]


1. Planos integrados [PA167.IG101.SP103.W101]

Sub-práticas

1. Integrar outros planos que afetam o projeto com o plano do projeto. [PA167.IG101.SP103.SubP101]

Outros planos que afetam o projeto podem incluir: [PA167.IG101.SP103.SubP101.N101]

Planos de garantia da qualidade

Planos de gerenciamento de configurações

Estratégia de gerenciamento de riscos

Planos de documentação



2. Incorporar no plano do projeto as definições de medidas e de atividades de medições para o gerenciamento do projeto. [PA167.IG101.SP103.SubP102]

Exemplos de medidas que seriam incorporadas incluem: [PA167.IG101.SP103.SubP102.N101]

Conjunto comum de medidas da organização

Medidas adicionais específicas do projeto

3. Identificar e analisar os riscos de interface do produto e do projeto. [PA167.IG101.SP103.SubP103]

Exemplos de riscos de interface de produtos e projeto incluem: [PA167.IG101.SP103.SubP103.N101]

Descrições incompletas de interfaces

Indisponibilidade de ferramentas ou equipamentos de testes

Disponibilidade de produtos de prateleira

Interfaces de equipes inadequadas ou ineficientes

4. Criar o cronograma das tarefas em uma seqüência que leve em conta os fatores críticos do desenvolvimento e os riscos do projeto. [PA167.IG101.SP103.SubP104]

Exemplos de fatores considerados na criação do cronograma incluem: [PA167.IG101.SP103.SubP104.N101]

Tamanho e complexidade das tarefas

Questões de integração e testes

Necessidades do cliente e dos usuários finais

Disponibilidade de recursos críticos

Disponibilidade de pessoal chave

5. Incorporar os planos para execução de revisões por pares nos produtos de trabalho do processo definido do projeto. [PA167.IG101.SP103.SubP105]

Veja a área de processo de Verificação para obter maiores informações sobre revisões por pares. [PA167.IG101.SP103.SubP105.R101]

6. Incorporar o treinamento necessário para executar o processo definido do projeto nos planos de treinamento do projeto. [PA167.IG101.SP103.SubP106]

Esta tarefa normalmente envolve negociar com o grupo de treinamento organizacional o suporte que eles fornecerão. [PA167.IG101.SP103.SubP106.N101]



7. Estabelecer critérios objetivos de entrada e saída para autorizar o início e encerramento das tarefas descritas na estrutura de decomposição do trabalho (work breakdown structure - WBS). [PA167.IG101.SP103.SubP107]

Veja a área de processo de Planejamento do Projeto para obter maiores informações sobre a WBS. [PA167.IG101.SP103.SubP107.R101]

8. Assegurar que o plano do projeto está apropriadamente compatível com os planos dos stakeholders relevantes. [PA167.IG101.SP103.SubP108]

Normalmente o plano e as mudanças no plano serão revisados para verificar sua compatibilidade. [PA167.IG101.SP103.SubP108.N101]

9. Identificar como serão resolvidos os conflitos que surgirem entre os stakeholders relevantes. [PA167.IG101.SP103.SubP109]

SP 1.4 Gerenciar o Projeto Utilizando os Planos Integrados

Gerenciar o projeto utilizando o plano do projeto, outros planos que afetam o projeto e o processo definido do projeto. [PA167.IG101.SP104]

Veja a área de processo de Definição do Processo Organizacional para obter maiores informações sobre os ativos de processos organizacionais. [PA167.IG101.SP104.R101]

Veja a área de processo de Foco no Processo Organizacional para obter maiores informações sobre as necessidades e objetivos dos processos organizacionais e a coordenação de atividades de melhorias de processos com o restante da organização. [PA167.IG101.SP104.R102]

Veja a área de processo de Gerenciamento de Riscos para obter maiores informações sobre gerenciamento de riscos. [PA167.IG101.SP104.R103]

Veja a área de processo de Monitoramento e Controle do Projeto para obter maiores informações sobre o monitoramento e controle do projeto. [PA167.IG101.SP104.R104]


1. Produtos de trabalho criados pela execução do processo definido do projeto [PA167.IG101.SP104.W101]

2. Medidas coletadas (“reais”) e registros ou relatórios de progresso [PA167.IG101.SP104.W102]

3. Requisitos, planos e compromissos revisados [PA167.IG101.SP104.W103]

4. Planos integrados [PA167.IG101.SP104.W104]



Sub-práticas

1. Implementar o processo definido do projeto utilizando a biblioteca de ativos de processos da organização. [PA167.IG101.SP104.SubP101]

Esta tarefa normalmente inclui o seguinte: [PA167.IG101.SP104.SubP101.N101]

Incorporar artefatos da biblioteca de ativos de processos da organização no projeto, conforme apropriado

Utilizar as lições aprendidas da biblioteca de ativos de processos da organização para gerenciar o projeto

2. Monitorar e controlar as atividades e produtos de trabalho do projeto utilizando o processo definido do projeto, o plano do projeto e outros planos que afetam o projeto. [PA167.IG101.SP104.SubP102]

Esta tarefa normalmente inclui o seguinte: [PA167.IG101.SP104.SubP102.N101]

Utilizar os critérios definidos de entrada e saída para autorizar o início ou determinar o encerramento das tarefas

Monitorar as atividades que poderiam afetar significativamente os valores reais dos parâmetros de planejamento do projeto

Rastrear os parâmetros de planejamento do projeto utilizando limitações mensuráveis que irão disparar investigações e ações apropriadas

Monitorar os riscos de interfaces de produtos e projetos

Gerenciar compromissos internos e externos baseados nos planos das tarefas e produtos de trabalho da implementação do processo definido do projeto

Um entendimento dos relacionamentos entre as diversas tarefas e produtos de trabalho do processo definido do projeto e os papéis a serem desempenhados pelos stakeholders relevantes, juntamente com mecanismos de controle bem definidos (por exemplo, revisões por pares) obtém uma melhor visibilidade do desempenho do projeto e um melhor controle do projeto. [PA167.IG101.SP104.SubP102.N102]

3. Obter e analisar as medidas selecionadas para gerenciar o projeto e suportar as necessidades da organização. [PA167.IG101.SP104.SubP103]

Veja a área de processo de Medições e Análises para obter maiores informações sobre a definição de um processo para obter e analisar medidas. [PA167.IG101.SP104.SubP103.R101]

4. Periodicamente revisar a adequação do ambiente para atender as necessidades do projeto e para suportar a coordenação. [PA167.IG101.SP104.SubP104]

Exemplos de ações que podem ser tomadas incluem: [PA167.IG101.SP104.SubP104.N101]

Acrescentar novas ferramentas

Adquirir redes, equipamento, treinamento e suporte adicional



5. Periodicamente revisar e alinhar o desempenho do projeto com as necessidades atuais e previstas, objetivos e requisitos da organização, do cliente e dos usuários finais, conforme apropriado. [PA167.IG101.SP104.SubP105]

Esta revisão inclui o alinhamento com as necessidades e objetivos dos processos organizacionais. [PA167.IG101.SP104.SubP105.N101]

Exemplos de ações que obtêm alinhamento incluem: [PA167.IG101.SP104.SubP105.N102]

Acelerar o cronograma, com os ajustes apropriados nos outros parâmetros de planejamento e nos riscos do projeto

Modificar os requisitos em resposta a mudanças das oportunidades de mercado ou das necessidades do cliente ou usuário final

Encerrar o projeto

SP 1.5 Contribuir para os Ativos de Processos Organizacionais

Contribuir com produtos de trabalho, medidas e experiências documentadas para os ativos de processos organizacionais. [PA167.IG101.SP105]

Veja a área de processo de Foco no Processo Organizacional para obter maiores informações sobre propostas de melhoria de processos. [PA167.IG101.SP105.R101]

Veja a área de processo de Definição do Processo Organizacional para obter maiores informações sobre os ativos de processos organizacionais, o repositório de medições da organização e a biblioteca de ativos de processos da organização. [PA167.IG101.SP105.R102]

Esta prática específica trata da coleta de informações dos processos no processo definido do projeto. [PA167.IG101.SP105.N101]


1. Melhorias propostas aos ativos de processos organizacionais [PA167.IG101.SP105.W101]

2. Medidas reais do processo e do produto coletadas no projeto [PA167.IG101.SP105.W102]

3. Documentação (por exemplo, descrições de processos exemplares, planos, módulos de treinamento, checklists e lições aprendidas) [PA167.IG101.SP105.W103]

Sub-práticas

1. Propor melhorias nos ativos de processos organizacionais. [PA167.IG101.SP105.SubP101]



2. Armazenar medidas de processos e produtos no repositório de medições da organização. [PA167.IG101.SP105.SubP102]

Veja a área de processo de Planejamento do Projeto para obter maiores informações sobre o registro de dados de planejamento e replanejamento. [PA167.IG101.SP105.SubP102.R101]

Veja a área de processo de Monitoramento e Controle do Projeto para obter maiores informações sobre o registro de medidas. [PA167.IG101.SP105.SubP102.R102]

Isto normalmente inclui: [PA167.IG101.SP105.SubP102.N101]

Dados de planejamento

Dados de replanejamento

Medidas

Exemplos de dados registrados pelo projeto incluem: [PA167.IG101.SP105.SubP102.N102]

Descrições de tarefas

Premissas

Estimativas

Estimativas revisadas

Definições de dados e medidas registrados

Medidas

Informações contextuais que relacionam as medidas com as atividades executadas e produtos de trabalho produzidos

Informações associadas necessárias para reconstruir as estimativas, analisar sua motivação e derivar estimativas para novos trabalhos

3. Submeter a documentação para possível inclusão na biblioteca de ativos de processos da organização. [PA167.IG101.SP105.SubP103]

Exemplos de documentação incluem: [PA167.IG101.SP105.SubP103.N101]

Descrições de processos exemplares

Módulos de treinamento

Planos exemplares

Checklists

4. Documentar lições aprendidas no projeto para a inclusão na biblioteca de ativos de processos da organização. [PA167.IG101.SP105.SubP104]



SG 2 Coordenar e Colaborar com os Stakeholders Relevantes

A coordenação e colaboração do projeto com os stakeholders relevantes é conduzida. [PA167.IG102]

SP 2.1 Gerenciar o Envolvimento dos Stakeholders

Gerenciar o envolvimento dos stakeholders relevantes do projeto. [PA167.IG102.SP101]

Veja a área de processo de Planejamento do Projeto para obter maiores informações sobre a identificação de stakeholders e o seu envolvimento apropriado e sobre o estabelecimento e manutenção de compromissos. [PA167.IG102.SP101.R101]


1. Programas e cronogramas para atividades colaborativas [PA167.IG102.SP101.W101]

2. Questões documentadas (por exemplo, questões com os requisitos de clientes, requisitos de produtos e componentes de produtos, arquitetura de produto e design do produto) [PA167.IG102.SP101.W102]

3. Recomendações para resolver questões com os stakeholders relevantes [PA167.IG102.SP101.W103]

Sub-práticas

1. Coordenar com os stakeholders relevantes quem deverá participar nas atividades do projeto. [PA167.IG102.SP101.SubP101]

Os stakeholders relevantes já deverão estar identificados no plano do projeto. [PA167.IG102.SP101.SubP101.N101]

2. Assegurar que os produtos de trabalho, que são produzidos para satisfazer os compromissos, atendem os requisitos dos projetos que os recebem. [PA167.IG102.SP101.SubP103]

Veja a área de processo de Verificação para obter maiores informações sobre como determinar a aceitabilidade de produtos de trabalho. [PA167.IG102.SP101.SubP103.R101]

Esta tarefa normalmente inclui: [PA167.IG102.SP101.SubP103.N101]

Revisar, demonstrar ou testar, conforme apropriado, cada produto de trabalho produzido pelos stakeholders relevantes

Revisar, demonstrar ou testar, conforme apropriado, cada produto de trabalho produzido pelo projeto para outros projetos, com representantes dos projetos que receberão o produto de trabalho

Resolver questões relacionadas à aceitação dos produtos de trabalho



3. Desenvolver recomendações e coordenar as ações para resolver os mal entendidos e problemas com os requisitos de produtos e componentes de produtos, arquitetura de produtos e componentes de produtos e design de produto e componentes de produtos. [PA167.IG102.SP101.SubP104]

SP 2.2 Gerenciar Dependências

Participar com os stakeholders relevantes para identificar, negociar e rastrear as dependências críticas. [PA167.IG102.SP102]

Veja a área de processo de Planejamento do Projeto para obter maiores informações sobre a identificação de stakeholders e o seu envolvimento apropriado e sobre o estabelecimento e manutenção de compromissos. [PA167.IG102.SP102.R101]


1. Defeitos, questões e itens de ações resultantes das revisões com os stakeholders relevantes [PA167.IG102.SP102.W102]

2. Dependências críticas [PA167.IG102.SP102.W103]

3. Compromissos para tratar as dependências críticas [PA167.IG102.SP102.W104]

4. Status das dependências críticas [PA167.IG102.SP102.W105]

Sub-práticas

1. Conduzir revisões com os stakeholders relevantes. [PA167.IG102.SP102.SubP101]

2. Identificar todas as dependências críticas. [PA167.IG102.SP102.SubP102]

3. Estabelecer datas de necessidades e de planos para cada dependência crítica, com base no cronograma do projeto. [PA167.IG102.SP102.SubP103]

4. Revisar e obter acordos sobre os compromissos para tratar cada dependência crítica com as pessoas responsáveis por fornecer o produto de trabalho e com as pessoas que receberão o produto de trabalho. [PA167.IG102.SP102.SubP104]

5. Documentar as dependências críticas e os compromissos. [PA167.IG102.SP102.SubP105]

A documentação dos compromissos normalmente inclui: [PA167.IG102.SP102.SubP105.N101]

Descrever o compromisso

Identificar quem fez o compromisso

Identificar quem é o responsável por satisfazer o compromisso



Especificar quando o compromisso será satisfeito

Especificar os critérios para determinar se o compromisso foi satisfeito

6. Rastrear as dependências críticas e compromissos e tomar as ações corretivas, conforme apropriado. [PA167.IG102.SP102.SubP106]

Veja a área de processo de Monitoramento e Controle do Projeto para obter maiores informações sobre o rastreamento de compromissos. [PA167.IG102.SP102.SubP106.R101]

Rastrear as dependências críticas normalmente inclui: [PA167.IG102.SP102.SubP106.N101]

Avaliar os efeitos do término antecipado ou atrasado com relação ao impacto em atividades futuras e milestones

Resolver problemas reais e potenciais com as pessoas responsáveis, quando isso for possível

Levar para os gerentes apropriados os problemas reais e potenciais que não possam ser resolvidos com as pessoas responsáveis

SP 2.3 Resolver Questões de Coordenação

Resolver questões com os stakeholders relevantes. [PA167.IG102.SP103]

Exemplos de questões de coordenação incluem: [PA167.IG102.SP103.N101]

Dependências críticas e compromissos atrasados

Defeitos de requisitos e design de produtos e componentes de produtos

Problemas de produtos

Indisponibilidade de recursos ou pessoal críticos


1. Questões de coordenação com os stakeholders relevantes [PA167.IG102.SP103.W101]

2. Status das questões de coordenação com os stakeholders relevantes [PA167.IG102.SP103.W102]

Sub-práticas

1. Identificar e documentar as questões. [PA167.IG102.SP103.SubP101]

2. Comunicar questões aos stakeholders relevantes. [PA167.IG102.SP103.SubP102]

3. Resolver questões com os stakeholders relevantes. [PA167.IG102.SP103.SubP103]

4. Levar para os gerentes apropriados aquelas questões que não possam ser resolvidas com os stakeholders relevantes. [PA167.IG102.SP103.SubP104]



5. Rastrear as questões até o encerramento. [PA167.IG102.SP103.SubP105]

6. Comunicar aos stakeholders relevantes o status e a resolução das questões. [PA167.IG102.SP103.SubP106]



Compromissos


Estabelecer e manter uma política organizacional para planejar e executar o processo de gerenciamento integrado do projeto. [GP103]

Elaboração:

Esta política estabelece as expectativas organizacionais para utilizar o processo definido do projeto e coordenar e colaborar com os stakeholders relevantes. [PA167.EL101]

Habilitações


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

Elaboração:

Esta prática genérica é diferente da prática específica Estabelecer o Processo Definido do Projeto desta área de processo. Esta prática genérica estabelece e mantém um processo definido de gerenciamento integrado do projeto. A prática específica Estabelecer o Processo Definido do Projeto define o processo definido do projeto, que inclui todos os processos que afetam o projeto. [PA167.EL118]


Estabelecer e manter o plano para execução do processo de gerenciamento integrado do projeto. [GP104]



Elaboração:

Normalmente, este plano para execução do processo de gerenciamento integrado do projeto é uma parte do plano do projeto, conforme descrito na área de processo de Planejamento do Projeto. [PA167.EL107]


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

Elaboração:


Pacotes de rastreamento de problemas e de informações de ocorrências

Ferramentas de trabalho em grupo (groupware)

Video-conferências

Banco de dados integrado de decisões

Ambientes integrados de suporte ao produto


Atribuir responsabilidades e autoridade para executar o processo, desenvolver os produtos de trabalho e fornecer os serviços do processo de gerenciamento integrado do projeto. [GP106]


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



Elaboração:


Adaptar o conjunto de processos padrão da organização para atender as necessidades do projeto

Procedimentos para gerenciar o projeto baseados no processo definido do projeto

Utilizar o repositório de medições da organização

Utilizar os ativos de processos organizacionais

Gerenciamento integrado

Coordenação inter-grupos

Resolução de problemas em grupo

Implementações


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

Elaboração:


O processo definido do projeto

Planos do projeto

Outros planos que afetam o projeto

Planos integrados

Medidas reais de processos e produtos coletadas no projeto


Identificar e envolver os stakeholders relevantes do processo de gerenciamento integrado do projeto, conforme planejado. [GP124]



Elaboração:

Esta prática genérica é diferente do gerenciamento do envolvimento dos stakeholders do projeto, que é coberto pelas práticas específicas dentro desta área de processo. [PA167.EL108]


Resolver questões sobre a adaptação dos ativos de processos organizacionais

Resolver questões entre o plano do projeto e os outros planos que afetam o projeto

Revisar o desempenho do projeto para alinhar com as necessidades, objetivos e requisitos atuais e projetados


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

Elaboração:


Quantidade de mudanças no processo definido do projeto

Cronograma e esforço para adaptar o conjunto de processos padrão da organização

Tendências de questões de coordenação de interfaces (isto é, quantidade de ocorrências abertas e encerradas)


Coletar produtos de trabalho, medidas, resultados de medições e informações de melhorias derivados do planejamento e execução do processo de gerenciamento integrado do projeto para suportar o uso futuro e a melhoria dos processos e ativos de processos da organização. [GP117]

Elaboração:

Esta prática genérica é diferente da prática específica Contribuir para os Ativos de Processos Organizacionais desta área de processo. Esta prática genérica coleta informações de melhorias sobre os processos de gerenciamento integrado do projeto. A prática específica Contribuir para os Ativos de Processos Organizacionais coleta informações dos processos do processo definido do projeto. [PA167.EL119]



Verificações


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

Elaboração:


Estabelecer, manter e utilizar o processo definido do projeto

Coordenar e colaborar com os stakeholders relevantes


Processo definido do projeto

Planos do projeto

Outros planos que afetam o projeto


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



GERENCIAMENTO DE RISCOS


Objetivo

O objetivo do Gerenciamento de Riscos (Risk Management) é identificar problemas potenciais antes que eles ocorram, de forma que as atividades de tratamento de riscos possam ser planejadas e invocadas, conforme necessário, durante a vida do produto ou projeto para mitigar os impactos adversos no atendimento dos objetivos. [PA148]


O gerenciamento de riscos é um processo contínuo e de previsão, que é uma parte importante dos processos de gerenciamento técnico e de negócios. O gerenciamento de riscos deverá tratar as questões que poderiam colocar em perigo o atendimento dos objetivos críticos. Uma abordagem contínua de gerenciamento de riscos é aplicada para antecipar e mitigar, de forma efetiva, os riscos que têm um impacto crítico no projeto. [PA148.N101]

O gerenciamento efetivo de riscos inclui uma antecipada e agressiva identificação de riscos através da colaboração e envolvimento dos stakeholders relevantes, conforme descrito no plano para envolvimento dos stakeholders tratado na área de processo de Planejamento do Projeto. Uma forte liderança entre todos os stakeholders relevantes é necessária para estabelecer um ambiente para uma exposição e discussão livres e abertas sobre os riscos. [PA148.N102]

Embora as questões técnicas sejam uma preocupação importante tanto nas etapas iniciais quanto em todas as fases do projeto, o gerenciamento de riscos deve considerar as fontes internas e externas de riscos técnicos, de custos e de cronograma. Uma detecção de riscos antecipada e agressiva é importante porque, normalmente, é mais fácil, barato e causa menos interrupções fazer mudanças e corrigir esforços de trabalho durante as fases iniciais, que em fases posteriores do projeto. [PA148.N103]

O gerenciamento de riscos pode ser dividido em três partes: definir uma estratégia de gerenciamento de riscos, identificar e analisar os riscos e tratar os riscos identificados, incluindo a implementação de planos de mitigação de riscos, quando necessário. [PA148.N104]

Nível de Maturidade: 3, Gerenciamento de Riscos400


Conforme representado nas áreas de processos de Planejamento do Projeto e Monitoramento e Controle do Projeto, as organizações podem inicialmente se concentrar simplesmente na identificação de riscos para ter consciência deles e reagir conforme eles ocorrerem. A área de processo de Gerenciamento de Riscos descreve uma evolução destas práticas específicas para um planejamento, antecipação e mitigação sistemáticos dos riscos para minimizar, de forma pró-ativa, seus impactos no projeto. [PA148.N105]

Embora a ênfase principal da área de processo de Gerenciamento de Riscos seja o projeto, o conceito pode também ser aplicado ao gerenciamento dos riscos organizacionais. [PA148.N106]


Veja a área de processo de Planejamento do Projeto para obter maiores informações sobre a identificação de riscos do projeto e o planejamento do envolvimento dos stakeholders relevantes. [PA148.R101]

Veja a área de processo de Monitoramento e Controle do Projeto para obter maiores informações sobre monitoramento de riscos do projeto. [PA148.R102]

Veja a área de processo de Análises de Decisões e Resoluções para obter maiores informações sobre a utilização de um processo formal de avaliação de alternativas para seleção e mitigação de riscos identificados. [PA148.R103]


SG 1 Preparar para o Gerenciamento de Riscos [PA148.IG101]

A preparação para o gerenciamento de riscos é conduzida.

SG 2 Identificar e Analisar Riscos[PA148.IG102]

Os riscos são identificados e analisados para determinar sua importância relativa.

SG 3 Mitigar Riscos [PA148.IG103]

Os riscos são tratados e mitigados, quando apropriado, para reduzir os impactos adversos no atendimento dos objetivos.

Nível de Maturidade: 3, Gerenciamento de Riscos 401





SG 1 Preparar para o Gerenciamento de Riscos [PA148.IG101]

SP 1.1 Determinar Fontes e Categorias de RiscosSP 1.2 Definir Parâmetros de RiscosSP 1.3 Estabelecer uma Estratégia de Gerenciamento de Riscos

SG 2 Identificar e Analisar Riscos [PA148.IG102]

SP 2.1 Identificar RiscosSP 2.2 Avaliar, Categorizar e Priorizar Riscos

SG 3 Mitigar Riscos [PA148.IG103]

SP 3.1 Desenvolver Planos de Mitigação de RiscosSP 3.2 Implementar Planos de Mitigação de Riscos




SG 1 Preparar para o Gerenciamento de Riscos

A preparação para o gerenciamento de riscos é conduzida. [PA148.IG101]

A preparação é conduzida pelo estabelecimento e manutenção de uma estratégia para a identificação, análise e mitigação de riscos. Isto é normalmente documentado como um plano de gerenciamento de riscos. A estratégia de gerenciamento de riscos trata as ações específicas e a abordagem de gerenciamento utilizadas para aplicar e controlar o programa de gerenciamento de riscos. Isto inclui identificar as fontes de riscos, o esquema utilizado para categorizar os riscos e os parâmetros utilizados para avaliar, conectar e controlar riscos para um tratamento efetivo. [PA148.IG101.N101]



SP 1.1 Determinar Fontes e Categorias de Riscos

Determinar fontes e categorias de riscos. [PA148.IG101.SP101]

A identificação das fontes de riscos fornece uma base para o exame sistemático das mudanças de situações ao longo do tempo, de forma a descobrir circunstâncias que causam impacto na capacidade do projeto em atingir seus objetivos. Fontes de riscos podem ser internas ou externas ao projeto. Conforme o projeto progride, outras fontes de riscos podem ser identificadas. Estabelecer categorias para os riscos fornece um mecanismo para a coleta e organização dos riscos, bem como assegura um estudo cuidadoso apropriado e a atenção do gerenciamento para aqueles riscos que podem ter conseqüências mais sérias no atendimento dos objetivos do projeto. [PA148.IG101.SP101.N101]


1. Listas de fontes de riscos (externas e internas) [PA148.IG101.SP101.W101]

2. Listas de categorias de riscos [PA148.IG101.SP101.W102]

Sub-práticas

1. Determinar fontes de riscos. [PA148.IG101.SP101.SubP101]

Fontes de riscos são os direcionadores fundamentais que causam riscos dentro de um projeto ou organização. Existem muitas fontes de riscos, tanto internas quanto externas ao projeto. As fontes de riscos identificam áreas comuns onde os riscos podem se originar. As fontes, internas e externas, mais comuns de riscos incluem: [PA148.IG101.SP101.SubP101.N101]

Requisitos incertos

Esforços sem precedentes – não há estimativas disponíveis

Design impossível de ser implementado

Tecnologia não disponível

Estimativas ou alocações de cronograma irreais

Equipe e habilitações inadequadas

Questões de custos ou recursos financeiros

Capacitação incerta ou inadequada do subcontratado

Capacitação incerta ou inadequada do fornecedor

Muitas destas fontes de riscos são freqüentemente aceitas sem o planejamento adequado. A identificação antecipada de fontes de riscos internas e externas pode levar a uma identificação antecipada dos riscos. Planos de mitigação de riscos podem, então, ser implementados antecipadamente no projeto para impedir a ocorrência dos riscos ou reduzir as conseqüências de sua ocorrência. [PA148.IG101.SP101.SubP101.N102]

2. Determinar categorias de riscos. [PA148.IG101.SP101.SubP102]



As categorias de riscos refletem as “latas” para a coleta e organização de riscos. Um motivo para identificar as categorias de riscos é ajudar na futura consolidação das atividades nos planos de mitigação de riscos. [PA148.IG101.SP101.SubP102.N101]

Os seguintes fatores podem ser considerados quando se determina as categorias de riscos: [PA148.IG101.SP101.SubP102.N102]

As fases do modelo de ciclo de vida do projeto (por exemplo, requisitos, design, fabricação, teste e avaliação, entrega, descarte)

Os tipos de processos utilizados

Os tipos de produtos utilizados

Riscos de programas de gerenciamento (por exemplo, riscos do contrato, riscos de orçamento/custos, riscos de cronograma, riscos de recursos, riscos de desempenho, riscos de suporte)

Uma taxonomia de riscos pode ser utilizada para fornecer um framework para a determinação de fontes e categorias de riscos. [PA148.IG101.SP101.SubP102.N103]

SP 1.2 Definir Parâmetros de Riscos

Definir os parâmetros utilizados para analisar e categorizar os riscos e os parâmetros utilizados para controlar o esforço de gerenciamento de riscos. [PA148.IG101.SP102]

Os parâmetros para a avaliação, categorização e priorização de riscos incluem: [PA148.IG101.SP102.N101]

Probabilidade de riscos (isto é, probabilidade de ocorrência do risco)

Conseqüência dos riscos (isto é, impacto e gravidade da ocorrência do risco)

Limites para disparar as atividades de gerenciamento

Os parâmetros de riscos são utilizados para fornecer critérios comuns e consistentes para comparar os diversos riscos a serem gerenciados. Sem estes parâmetros, seria muito difícil medir a gravidade de mudanças não desejadas causadas pelo risco e priorizar as ações necessárias exigidas pelo planejamento de mitigação de riscos. [PA148.IG101.SP102.N102]


1. Critérios de avaliação, categorização e priorização de riscos [PA148.IG101.SP102.W101]

2. Requisitos de gerenciamento de riscos (níveis de controle e aprovação, intervalos para novas avaliações, etc.) [PA148.IG101.SP102.W102]



Sub-práticas

1. Definir critérios consistentes para a avaliação e quantificação da probabilidade e dos níveis de gravidade dos riscos. [PA148.IG101.SP102.SubP101]

Critérios utilizados de forma consistente (por exemplo, as ligações entre a probabilidade e os níveis de gravidade) permitem que os impactos de diferentes riscos possam ter um entendimento comum, receber o nível apropriado de estudo detalhado e obter a atenção garantida do gerenciamento. No gerenciamento de riscos diferentes (por exemplo, segurança do pessoal versus a poluição ambiental) é importante assegurar consistência no resultado final (por exemplo, um alto risco de poluição ambiental é tão importante quanto um alto risco para a segurança do pessoal). [PA148.IG101.SP102.SubP101.N101]

2. Definir limites para cada categoria de riscos. [PA148.IG101.SP102.SubP102]

Para cada categoria de riscos, podem ser estabelecidos limites para determinar a aceitabilidade ou não dos riscos, a priorização dos riscos ou gatilhos para disparar uma ação de gerenciamento. [PA148.IG101.SP102.SubP102.N101]

Exemplos de limites incluem: [PA148.IG101.SP102.SubP102.N102]

Limites no âmbito do projeto poderiam ser estabelecidos para envolver a gerência sênior quando os custos dos produtos excederem 10% do custo determinado ou quando os Índices de Desempenho de Custos (Cost Performance Indexes - CPIs) caírem abaixo de 0,95.

Limites de cronograma poderiam ser estabelecidos para envolver a gerência sênior quando os Índices de Desempenho do Cronograma (Schedule Performance Indexes - SPIs) caírem abaixo de 0,95.

Limites de desempenho poderiam ser configurados para envolver a gerência sênior quando itens chave de design especificados (por exemplo, utilização do processador) excederem 125% do design pretendido.

Isto pode ser refinado mais tarde, para cada risco identificado, para estabelecer pontos nos quais um monitoramento de riscos mais agressivo é empregado ou para sinalizar a implementação de planos de mitigação de riscos. [PA148.IG101.SP102.SubP102.N105]

3. Definir limitações para a aplicação dos limites contra ou dentro de uma categoria. [PA148.IG101.SP102.SubP103]

Existem poucos limites nos quais os riscos podem ser avaliados de uma forma quantitativa ou qualitativa. A definição de limitações (ou condições de fronteiras) pode ser utilizada para ajudar a definir o escopo do esforço de gerenciamento de riscos e evitar um gasto excessivo de recursos. As limitações podem incluir a exclusão de uma fonte de risco de uma categoria. Estas limitações podem também excluir uma condição que ocorre com uma freqüência menor que uma dada freqüência. [PA148.IG101.SP102.SubP103.N101]



SP 1.3 Estabelecer uma Estratégia de Gerenciamento de Riscos

Estabelecer e manter a estratégia a ser utilizada para o gerenciamento de riscos. [PA148.IG101.SP103]

Uma estratégia abrangente de gerenciamento de riscos trata de itens como: [PA148.IG101.SP103.N101]

O escopo do esforço de gerenciamento de riscos

Métodos e ferramentas a serem utilizados para a identificação, análise, mitigação, monitoramento e comunicação de riscos

Fontes de riscos específicas do projeto

Como estes riscos são organizados, categorizados, comparados e consolidados

Parâmetros, incluindo a probabilidade, conseqüências e limitações para a tomada de ações nos riscos identificados

Técnicas de mitigação de riscos a serem utilizadas, como prototipação, simulação, designs alternativos ou desenvolvimento evolutivo

Definição de medidas de riscos para monitorar o status dos riscos

Intervalos de tempo para monitoramento e reavaliação dos riscos

A estratégia de gerenciamento de riscos deverá ser guiada por uma visão comum do sucesso que descreve os resultados futuros desejados para o projeto, em termos do produto que será entregue, seu custo e sua adequação à tarefa. A estratégia de gerenciamento de riscos é, muitas vezes, documentada em um plano de gerenciamento de riscos do projeto ou organizacional. A estratégia de gerenciamento de riscos é revisada com os stakeholders relevantes para promover o compromisso e o entendimento. [PA148.IG101.SP103.N102]


1. Estratégia de gerenciamento de riscos do projeto [PA148.IG101.SP103.W101]

SG 2 Identificar e Analisar os Riscos

Os riscos são identificados e analisados para determinar sua importância relativa. [PA148.IG102]

O grau dos riscos impacta nos recursos atribuídos para tratar um risco identificado e a determinação de quando a atenção apropriada do gerenciamento é exigida. [PA148.IG102.N101]



A análise de riscos envolve identificar os riscos a partir de fontes internas e externas identificadas e, então, avaliar cada risco identificado para determinar sua probabilidade e conseqüências. A categorização dos riscos, baseada em uma avaliação contra as categorias de riscos estabelecidas e os critérios desenvolvidos para a estratégia de gerenciamento de riscos, fornece as informações necessárias para o tratamento dos riscos. Os riscos relacionados podem ser agrupados para um tratamento eficiente e uma utilização eficaz dos recursos de gerenciamento de riscos. [PA148.IG102.N102]

SP 2.1 Identificar Riscos

Identificar e documentar os riscos. [PA148.IG102.SP101]

A identificação de potenciais questões, perigos, ameaças e vulnerabilidades que poderiam afetar negativamente os esforços ou planos de trabalho é a base para um sonoro e bem sucedido gerenciamento de riscos. Os riscos devem ser identificados e descritos de uma forma fácil de entender, antes que possam ser analisados e gerenciados de forma apropriada. Os riscos são documentados em uma declaração concisa que inclui o contexto, as condições e as conseqüências da ocorrência do risco. [PA148.IG102.SP101.N101]

A identificação dos riscos deverá usar uma abordagem organizada e abrangente para pesquisar riscos prováveis ou reais ao atendimento dos objetivos. Para ser eficaz, a identificação dos riscos não deverá ser uma tentativa de tratar todos os eventos possíveis, não importando que sejam improváveis. O uso de categorias e parâmetros desenvolvidos na estratégia de gerenciamento de riscos, junto com as fontes identificadas de riscos, podem fornecer a disciplina e o fluxo de trabalho apropriados para a identificação dos riscos. Os riscos identificados formam uma baseline para iniciar as atividades de gerenciamento de riscos. A lista de riscos deverá ser revisada periodicamente para reexaminar possíveis fontes de riscos e condições que mudaram, para descobrir fontes e riscos não percebidos ou inexistentes na última atualização da estratégia de gerenciamento de riscos. [PA148.IG102.SP101.N102]

As atividades de identificação de riscos se concentram na identificação dos riscos, não em identificação de culpados. Os resultados das atividades de identificação de riscos não são utilizados pela gerência para avaliar o desempenho de indivíduos. [PA148.IG102.SP101.N104]

Existem diversos métodos para a identificação de riscos. Os métodos comuns de identificação incluem: [PA148.IG102.SP101.N103]

Examinar cada elemento da estrutura de decomposição do trabalho (WBS) do projeto para descobrir riscos.



Conduzir uma análise de riscos utilizando uma taxonomia de riscos.

Entrevistar especialistas no assunto.

Revisar os esforços de gerenciamento de riscos em produtos semelhantes.

Examinar documentos ou bancos de dados de lições aprendidas.

Examinar especificações de design e requisitos de acordos.


1. Lista de riscos identificados, incluindo o contexto, condições e conseqüências da ocorrência de riscos [PA148.IG102.SP101.W101]

Sub-práticas

1. Identificar os riscos associados com o custo, cronograma e desempenho em todas as fases apropriadas do ciclo de vida do produto. [PA148.IG102.SP101.SubP101]

Riscos de custo, cronograma e desempenho deverão ser examinados durante todas as fases do ciclo de vida do produto para verificar a extensão do seu impacto nos objetivos do projeto. Podem existir riscos potenciais descobertos que estejam fora do escopo dos objetivos do projeto, mas que sejam vitais para os interesses do cliente. Por exemplo, os riscos de custos de desenvolvimento, custos de aquisição de produtos, custos de produtos de reposição (ou substituição) e custos de disposição (ou descarte) de produtos têm implicações no design. O cliente pode não ter fornecido requisitos para o custo de suporte de campo do produto. O cliente deverá ser informado de tais riscos, mas o gerenciamento ativo destes riscos pode não ser necessário. Os mecanismos para tomar tais decisões deverão ser examinados para o projeto e para a organização e colocados em prática se considerados apropriados, especialmente para riscos que impactam na capacidade de verificar e validar o produto. [PA148.IG102.SP101.SubP101.N101]

Além dos riscos de custos identificados acima, outros riscos de custos podem incluir aqueles associados com níveis de finanças, estimativas de fundos e orçamentos distribuídos. [PA148.IG102.SP101.SubP101.N102]

Riscos de cronograma podem incluir riscos associados com as atividades planejadas, eventos chave e milestones. [PA148.IG102.SP101.SubP101.N103]

Riscos de desempenho podem incluir riscos associados com: [PA148.IG102.SP101.SubP101.N104]

Requisitos

Análise e design

Aplicação de nova tecnologia

Tamanho físico

Formato



Peso

Manufatura e fabricação

Desempenho funcional e operação

Verificação

Validação

Atributos de manutenção de desempenho

Os atributos de manutenção de desempenho são aquelas características que possibilitam que um produto em uso forneça o desempenho originalmente exigido, como a manutenção da segurança e o desempenho da proteção. [PA148.IG102.SP101.SubP101.N105]

Existem outros riscos que não se encaixam nas categorias de custo, cronograma ou desempenho. [PA148.IG102.SP101.SubP101.N106]

Exemplos destes outros riscos incluem: [PA148.IG102.SP101.SubP101.N107]

Riscos associados com greves

Diminuição de fontes de fornecimento

Tempo do ciclo de tecnologia

Competição

2. Revisar elementos ambientais que podem impactar o projeto. [PA148.IG102.SP101.SubP102]

Os riscos para um projeto que são freqüentemente esquecidos incluem aqueles que supostamente estão fora do escopo do projeto (isto é, o projeto não tem controle sobre se eles ocorrerão, mas pode mitigar seu impacto), como clima, desastres naturais, mudanças políticas e falhas de telecomunicação. [PA148.IG102.SP101.SubP102.N101]

3. Revisar todos os elementos da estrutura de decomposição do trabalho (WBS) como parte da identificação de riscos, para ajudar a assegurar que todos os aspectos do esforço de trabalho foram considerados. [PA148.IG102.SP101.SubP103]

4. Revisar todos os elementos do plano do projeto como parte da identificação de riscos, para ajudar a assegurar que todos os aspectos do projeto foram considerados. [PA148.IG102.SP101.SubP104]

Veja a área de processo de Planejamento do Projeto para obter maiores informações sobre a identificação de riscos do projeto. [PA148.IG102.SP101.SubP104.R101]

5. Documentar o contexto, condições e conseqüências potenciais do risco. [PA148.IG102.SP101.SubP105]



Declarações de riscos são normalmente documentadas em um formato padrão que contém o contexto, condições e conseqüências da ocorrência do risco. O contexto do risco fornece informações adicionais, de forma que o risco possa ser facilmente entendido. Na documentação do contexto do risco, considere o intervalo de tempo relativo do risco, as circunstâncias ou condições em torno do risco e quaisquer dúvidas ou incertezas. [PA148.IG102.SP101.SubP105.N101]

6. Identificar os stakeholders relevantes associados com cada risco. [PA148.IG102.SP101.SubP106]

SP 2.2 Avaliar, Categorizar e Priorizar Riscos

Avaliar e categorizar cada risco identificado utilizando categorias e parâmetros definidos de riscos e determinar sua prioridade relativa. [PA148.IG102.SP102]

A avaliação de riscos é necessária para atribuir a importância relativa para cada risco identificado e é utilizada para determinar quando a atenção apropriada do gerenciamento é exigida. Freqüentemente, é útil agregar riscos com base nos seus interrelacionamentos e desenvolver opções agregadas. Quando um risco agregado é formado por um conjunto de riscos de mais baixo nível, deve-se tomar cuidado para assegurar que riscos importantes de baixo nível não sejam ignorados. [PA148.IG102.SP102.N101]

Coletivamente, as atividades de avaliação, categorização e priorização de riscos são, algumas vezes, chamadas de “avaliação de riscos” ou “análise de riscos”. [PA148.IG102.SP102.N103]


1. Lista de riscos, com a prioridade atribuída a cada risco [PA148.IG102.SP102.W101]

Sub-práticas

1. Avaliar os riscos identificados utilizando os parâmetros definidos de riscos. [PA148.IG102.SP102.SubP101]

Cada risco é avaliado e são atribuídos valores de acordo com os parâmetros definidos de riscos, que podem incluir probabilidade, conseqüência (gravidade ou impacto) e limites. Os valores atribuídos para os parâmetros de riscos podem ser integrados para produzir medidas adicionais, tais como exposição a riscos, que podem ser utilizadas para priorizar os riscos a serem tratados. [PA148.IG102.SP102.SubP101.N101]

Freqüentemente, uma escala de três a cinco valores é utilizada para avaliar a probabilidade e conseqüência. A probabilidade, por exemplo, pode ser categorizada como remota, improvável, provável, altamente provável ou quase certa. [PA148.IG102.SP102.SubP101.N102]



Exemplos de conseqüências incluem: [PA148.IG102.SP102.SubP101.N104]

Baixa

Média

Alta

Negligenciável

Marginal

Significativo

Crítica

Catastrófica

Valores de probabilidade são normalmente utilizados para quantificar a possibilidade de ocorrência do risco. As conseqüências são geralmente relacionadas ao custo, cronograma, impacto ambiental ou medidas humanas (como horas de trabalho perdidas ou gravidade do ferimento). [PA148.IG102.SP102.SubP101.N105]

Esta avaliação é freqüentemente uma tarefa difícil e demorada. Especialização ou técnicas de grupo podem ser necessárias para avaliar os riscos e obter a confiança na priorização. Além disso, as prioridades podem exigir uma reavaliação, conforme o tempo passa. [PA148.IG102.SP102.SubP101.N103]

2. Categorizar e agrupar riscos de acordo com as categorias de riscos definidas. [PA148.IG102.SP102.SubP102]

Os riscos são categorizados em categorias de riscos definidas, fornecendo um meio de verificar riscos de acordo com sua fonte, taxonomia ou componente do projeto. Riscos relacionados ou equivalentes podem ser agrupados para um tratamento mais eficiente. Os relacionamentos de causa e efeito entre os riscos relacionados são documentados. [PA148.IG102.SP102.SubP102.N101]

3. Priorizar riscos para mitigação. [PA148.IG102.SP102.SubP103]

Uma prioridade relativa é determinada para cada risco, com base nos parâmetros de riscos atribuídos. Critérios claros deverão ser utilizados para determinar a prioridade dos riscos. A intenção da priorização é determinar as áreas mais efetivas nas quais os recursos de mitigação de riscos podem ser aplicados com um maior impacto positivo no projeto. [PA148.IG102.SP102.SubP103.N101]

SG 3 Mitigar Riscos

Os riscos são tratados e mitigados, quando apropriado, para reduzir os impactos adversos no atendimento dos objetivos. [PA148.IG103]



As etapas do tratamento de riscos incluem o desenvolvimento de opções de tratamento de riscos, monitoramento de riscos e execução de atividades de tratamento de riscos quando os limites definidos forem excedidos. Os planos de mitigação de riscos são desenvolvidos e implementados para os riscos selecionados para pró-ativamente reduzir o impacto potencial da ocorrência do risco. Isto pode também incluir planos de contingência para lidar com o impacto dos riscos selecionados, que podem ocorrer apesar das tentativas de mitigá-los. Os parâmetros de riscos utilizados para disparar as atividades de tratamento de riscos são definidos pela estratégia de gerenciamento de riscos. [PA148.IG103.N101]

SP 3.1 Desenvolver Planos de Mitigação de Riscos

Desenvolver um plano de mitigação de riscos para os riscos mais importantes para o projeto, conforme definido na estratégia de gerenciamento de riscos. [PA148.IG103.SP101]

Um componente crítico de um plano de mitigação de riscos é desenvolver cursos alternativos de ação, caminhos alternativos e posições de retomada, com um curso de ação recomendado para cada risco crítico. O plano de mitigação de riscos para um dado risco inclui técnicas e métodos utilizados para evitar, reduzir e controlar a probabilidade de ocorrência do risco, a extensão do dano gerado, caso o risco ocorra (algumas vezes chamado de “plano de contingência”) ou ambos. Os riscos são monitorados e quando excedem os limites estabelecidos, os planos de mitigação de riscos são implantados para fazer o esforço impactado retornar a um nível aceitável de risco. Se o risco não pode ser mitigado, um plano de contingência pode ser invocado. Os planos de mitigação de riscos e de contingência são freqüentemente gerados somente para riscos selecionados, onde as conseqüências dos riscos são definidas como altas ou inaceitáveis; outros riscos podem ser aceitos e simplesmente monitorados. [PA148.IG103.SP101.N102]

As opções para o tratamento de riscos normalmente incluem alternativas como: [PA148.IG103.SP101.N103]

Evitar o risco: Mudar ou diminuir requisitos, mantendo o atendimento às necessidades do usuário

Controle de riscos: Executar etapas ativas para minimizar os riscos

Transferência de riscos: Realocação de requisitos de design para baixar os riscos

Monitoramento de riscos: Observar e periodicamente reavaliar os riscos com relação a mudanças nos parâmetros de riscos atribuídos



Aceitação do risco: Reconhecer o risco mas não tomar nenhuma ação

Freqüentemente, especialmente para riscos altos, mais de uma abordagem para o tratamento do risco deverá ser gerada. [PA148.IG103.SP101.N104]

Em muitos casos, os riscos serão aceitos ou observados. A aceitação do risco é normalmente feita quando o risco é julgado de nível muito baixo para uma mitigação formal ou quando parece não haver uma maneira viável de reduzir o risco. Se um risco é aceito, a justificativa para esta decisão deverá ser documentada. Os riscos são observados quando há um limite objetivamente definido, verificável e documentado de desempenho, prazo ou exposição ao risco (a combinação de probabilidade e conseqüência) que irá disparar o plano de mitigação de riscos ou invocar um plano de contingência, se for necessário. [PA148.IG103.SP101.N105]

Uma consideração adequada deverá ser dada de forma antecipada a demonstrações de tecnologia, modelos, simulações e protótipos, como parte do plano de mitigação de riscos. [PA148.IG103.SP101.N106]


1. Opções de tratamento documentadas para cada risco identificado [PA148.IG103.SP101.W101]

2. Planos de mitigação de riscos [PA148.IG103.SP101.W102]

3. Planos de contingência [PA148.IG103.SP101.W104]

4. Lista dos responsável por rastrear e tratar cada risco [PA148.IG103.SP101.W103]

Sub-práticas

1. Determinar os níveis e limites que definem quando um risco se torna inaceitável e dispara a execução de um plano de mitigação de riscos ou um plano de contingência. [PA148.IG103.SP101.SubP101]

O nível de risco (derivado utilizando um modelo de risco) é uma medida que combina a incerteza de se atingir um objetivo com as conseqüências de se falhar em atingir o objetivo. [PA148.IG103.SP101.SubP101.N101]

Níveis de riscos e limites, que definem o desempenho planejado ou aceitável, devem ser claramente entendidos e definidos para fornecer meios com os quais os riscos possam ser entendidos. A classificação apropriada dos riscos é essencial para assegurar a prioridade do risco, baseada na gravidade, e a responsabilidade gerencial associada. Existem diversos limites empregados para iniciar diversos níveis de respostas gerenciais. Normalmente, limites para a execução dos planos de mitigação de riscos são definidos para serem acionados antes da execução dos planos de contingência. [PA148.IG103.SP101.SubP101.N102]



2. Identificar a pessoa ou grupo responsável pelo tratamento de cada risco. [PA148.IG103.SP101.SubP102]

3. Determinar a razão custo-benefício da implementação do plano de mitigação de riscos para cada risco. [PA148.IG103.SP101.SubP103]

As atividades de mitigação de riscos deverão ser examinadas com relação aos benefícios que elas oferecem versus os recursos que são gastos. Como em qualquer outra atividade de design, planos alternativos podem precisar ser desenvolvidos e os benefícios de cada alternativa serem avaliados. O plano mais apropriado é, então, selecionado para implementação. Às vezes, o risco pode ser significativo e os benefícios pequenos, mas o risco deve ser mitigado para reduzir a probabilidade de ocorrerem conseqüências inaceitáveis. [PA148.IG103.SP101.SubP103.N101]

4. Desenvolver um plano geral de mitigação de riscos para o projeto para orquestrar a implementação dos planos individuais de mitigação de riscos e de contingência. [PA148.IG103.SP101.SubP104]

O conjunto completo dos planos de mitigação de riscos pode não ser possível de ser implementado. Uma análise de custo-benefício deverá ser feita para priorizar os planos de mitigação de riscos a serem implementados. [PA148.IG103.SP101.SubP104.N101]

5. Desenvolver planos de contingência para os riscos críticos selecionados, na hipótese que seus impactos ocorram. [PA148.IG103.SP101.SubP105]

Os planos de mitigação de riscos são desenvolvidos e implementados, conforme necessário, para reduzir de forma pró-ativa os riscos antes que eles se tornem problemas. Apesar dos melhores esforços, alguns riscos podem ser inevitáveis e se tornar problemas que impactam o projeto. Os planos de contingência podem ser desenvolvidos para os riscos críticos, para descrever as ações que um projeto deve tomar para lidar com a ocorrência deste impacto. A intenção é definir um plano pró-ativo para tratar o risco, seja reduzindo o risco (mitigação) ou respondendo ao risco (contingência), mas de qualquer maneira, gerenciando o risco. [PA148.IG103.SP101.SubP105.N101]

Alguns artigos sobre gerenciamento de riscos podem considerar planos de contingência como um sinônimo ou sub-conjunto dos planos de mitigação de riscos. Estes planos também podem ser tratados juntos como planos de tratamento de riscos ou de ação de riscos. [PA148.IG103.SP101.SubP105.N102]

SP 3.2 Implementar Planos de Mitigação de Riscos

Monitorar o status de cada risco periodicamente e implementar o plano de mitigação de riscos, conforme apropriado. [PA148.IG103.SP102]



Para efetivamente controlar e gerenciar riscos durante o esforço de trabalho, siga um programa pró-ativo para regularmente monitorar os riscos e o status e resultados das ações de tratamento de riscos. A estratégia de gerenciamento de riscos define os intervalos nos quais os status dos riscos deverão ser revistos. Esta atividade pode resultar na descoberta de novos riscos ou de novas opções de tratamento de riscos, que podem exigir um replanejamento ou uma reavaliação. Em cada caso, os limites de aceitabilidade associados com o risco deverão ser comparados contra o status, para determinar a necessidade de implementar um plano de mitigação de riscos. [PA148.IG103.SP102.N101]


1. Listas atualizadas de status de riscos [PA148.IG103.SP102.W101]

2. Análises atualizadas de probabilidade de riscos, conseqüências e limites [PA148.IG103.SP102.W102]

3. Listas atualizadas de opções de tratamento de riscos [PA148.IG103.SP102.W103]

4. Listas atualizadas de ações tomadas para tratar riscos [PA148.IG103.SP102.W104]

5. Planos de mitigação de riscos [PA148.IG103.SP102.W105]

Sub-práticas

1. Monitorar status de riscos. [PA148.IG103.SP102.SubP101]

Após um plano de mitigação de riscos ser iniciado, o risco é ainda monitorado. Limites são analisados para verificar a execução potencial de um plano de contingência. [PA148.IG103.SP102.SubP101.N101]

Um mecanismo periódico para monitoramento deverá ser empregado. [PA148.IG103.SP102.SubP101.N102]

2. Fornecer um método para rastrear os itens de ação de tratamento de riscos abertos até o encerramento. [PA148.IG103.SP102.SubP102]

Veja a área de processo de Monitoramento e Controle do Projeto para obter maiores informações sobre o rastreamento de itens de ação. [PA148.IG103.SP102.SubP102.R101]

3. Invocar opções selecionadas de tratamento de riscos, quando os riscos monitorados excederem os limites definidos. [PA148.IG103.SP102.SubP103]



Muito freqüentemente, o tratamento de riscos é somente executado para aqueles riscos julgados “altos” ou “médios”. A estratégia de tratamento de riscos para um dado risco pode incluir técnicas e métodos para evitar, reduzir e controlar a probabilidade do risco ou a extensão do dano ocorrido, caso o risco (evento ou situação prevista) ocorra ou ambos. Neste contexto, o tratamento de riscos inclui os planos de mitigação e de contingência. [PA148.IG103.SP102.SubP103.N101]

Técnicas de tratamento de riscos são desenvolvidas para evitar, reduzir e controlar o impacto adverso aos objetivos do projeto e para causar resultados aceitáveis à luz dos impactos prováveis. Ações geradas para tratar um risco exigem a carga de recursos apropriados e uma programação dentro dos planos e cronogramas na baseline. Este esforço de replanejamento precisa considerar muito bem os efeitos sobre as iniciativas ou atividades de trabalho adjacentes ou dependentes. [PA148.IG103.SP102.SubP103.N102]

Veja a área de processo de Monitoramento e Controle do Projeto para obter maiores informações sobre como revisar o plano do projeto. [PA148.IG103.SP102.SubP103.N102.R101]

4. Estabelecer um cronograma ou um período de execução para cada atividade de tratamento de risco, que inclui a data inicial e a data prevista de encerramento. [PA148.IG103.SP102.SubP104]

5. Fornecer um compromisso contínuo de recursos para cada plano, para permitir a execução bem sucedida das atividades de tratamento de riscos. [PA148.IG103.SP102.SubP105]

6. Coletar medidas de desempenho nas atividades de tratamento de riscos. [PA148.IG103.SP102.SubP106]



Compromissos


Estabelecer e manter uma política organizacional para planejar e executar o processo de gerenciamento de riscos. [GP103]

Elaboração:

Esta política estabelece as expectativas organizacionais para definir uma estratégia de gerenciamento de riscos e identificar, analisar e mitigar os riscos. [PA148.EL101]



Habilitações


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


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

Elaboração:

Normalmente, este plano para execução do processo de gerenciamento de riscos está incluído no (ou é referenciado pelo) plano do projeto, que é descrito na área de processo de Planejamento do Projeto. O plano para a execução do processo de gerenciamento de riscos difere tanto da estratégia de gerenciamento de riscos como dos planos de mitigação de riscos, descritos nas práticas específicas desta área de processo. O plano que é tratado por esta prática genérica trata do planejamento geral para todas as práticas específicas desta área de processo, da determinação das fontes e categorias de riscos até a implementação dos planos de mitigação de riscos. Em contraste, a estratégia de gerenciamento de riscos, tratada em uma prática específica, trata da estratégia de risco específica do projeto para coisas como as fontes de riscos, limites, ferramentas e técnicas e monitora os intervalos de tempo. Os planos de mitigação de riscos, tratados por outra prática específica, tratam de itens mais específicos, como os níveis que disparam as atividades de tratamento de riscos. [PA148.EL103]


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

Elaboração:


Bancos de dados de gerenciamento de riscos

Ferramentas de mitigação de riscos


Modelagem e simulação




Atribuir responsabilidades e autoridade para executar o processo, desenvolver os produtos de trabalho e fornecer os serviços do processo de gerenciamento de riscos. [GP106]


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

Elaboração:


Conceitos e atividades de gerenciamento de riscos (por exemplo, identificação e análise de riscos, monitoramento, mitigação)

Seleção de medidas para a mitigação de riscos

Implementações


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

Elaboração:



Itens de riscos identificados

Planos de mitigação de riscos


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



Elaboração:


Estabelecer um ambiente colaborativo para uma discussão livre e aberta sobre os riscos

Revisar a estratégia de gerenciamento de riscos e os planos de mitigação de riscos

Participar das atividades de identificação, análise e mitigação de riscos

Comunicar e relatar status do gerenciamento de riscos


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

Elaboração:


Quantidade de riscos identificados, gerenciados, rastreados e controlados

Exposição ao risco e mudanças na exposição ao risco para cada risco avaliado e como um percentual de resumo da reserva de gerenciamento

Atividade de mudanças para os planos de mitigação de riscos (por exemplo, processos, cronograma, recursos)

Ocorrência de riscos não previstos

Volatilidade da classificação de riscos

Comparação de esforço e impacto de mitigação de riscos estimados versus reais


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 riscos para suportar o uso futuro e a melhoria dos processos e ativos de processos da organização. [GP117]



Verificações


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

Elaboração:


Estabelecer e manter uma estratégia de gerenciamento de riscos

Identificar e analisar riscos

Mitigar riscos



Planos de mitigação de riscos


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

Elaboração:

Revisões do status de risco do projeto são executadas periodicamente e na ocorrência de determinados eventos, com os níveis apropriados de gerenciamento, para fornecer a visibilidade do potencial de exposição de riscos do projeto e a ação corretiva apropriada. [PA148.EL118]

Normalmente, estas revisões incluirão um resumo dos riscos mais críticos, parâmetros chave de riscos (como a probabilidade e conseqüência destes riscos) e o status dos esforços de mitigação de riscos. [PA148.EL119]



ANÁLISES DE DECISÕES E RESOLUÇÕES


Objetivo

O objetivo das Análises de Decisões e Resoluções (Decision Analysis and Resolution) é analisar as decisões possíveis, utilizando um processo formal de avaliação que avalia as alternativas identificadas contra os critérios estabelecidos. [PA156]


A área de processo Análises de Decisões e Resoluções envolve o estabelecimento de instruções para determinar quais questões deverão ser submetidas a um processo formal de avaliação e, então, aplicar processos formais de avaliação a estas questões. [PA156.N101]

Um processo formal de avaliação é uma abordagem estruturada para avaliar soluções alternativas contra critérios estabelecidos, para determinar uma solução recomendada para tratar uma questão. Um processo de avaliação formal envolve as seguintes ações: [PA156.N112]

Estabelecer os critérios para avaliar alternativas

Identificar soluções alternativas

Selecionar métodos para avaliar alternativas

Avaliar as soluções alternativas utilizando os critérios e métodos estabelecidos

Selecionar soluções recomendadas a partir das alternativas, baseando-se nos critérios de avaliação

Em lugar de utilizar a frase “soluções alternativas para tratar questões” todas as vezes que esta for necessária, usaremos uma destas frases menores: “soluções alternativas” ou “alternativas”. [PA156.N113]

Um processo formal de avaliação reduz a natureza subjetiva da decisão e tem uma probabilidade maior de selecionar uma solução que atenda a diversas demandas dos stakeholders relevantes. [PA156.N102]

Embora a aplicação principal desta área de processo seja selecionar questões técnicas, os processos formais de avaliação também podem ser aplicados a muitas questões não-técnicas, especialmente quando um projeto está sendo planejado. Questões que têm diversas soluções alternativas e critérios de avaliação se adaptam a um processo formal de avaliação. [PA156.N103]

Nível de Maturidade: 3, Análises de Decisões e Resoluções 421


Estudos comerciais de equipamento ou software são exemplos típicos de processos formais de avaliação. [PA156.N111]

Durante o planejamento, questões específicas que exigem um processo formal de avaliação são identificadas. Questões típicas incluem a seleção entre as alternativas de arquitetura ou design, o uso de componentes reutilizáveis ou de prateleira, seleção de fornecedores, ambientes de suporte de engenharia ou ferramentas associadas, ambientes de testes e logística e produção. Um processo formal de avaliação também pode ser utilizado para tratar uma decisão do tipo comprar-ou-fazer, o desenvolvimento de processos de manufatura, a seleção de locais de distribuição e outras decisões. [PA156.N104]

Instruções são criadas para decidir quando utilizar processos formais de avaliação para tratar questões não planejadas. As instruções freqüentemente sugerem o uso de processos formais de avaliação quando as questões estão associadas com riscos de nível médio a alto, ou quando as questões afetam a capacidade do projeto atender seus objetivos. [PA156.N106]

Processos formais de avaliação podem variar em termos de formalidade, tipos de critérios e métodos empregados. Decisões menos formais podem ser analisadas em apenas algumas horas, utilizar somente poucos critérios (por exemplo, eficiência e custo para implementar) e resultar em relatórios de apenas uma ou duas páginas. Decisões mais formais podem exigir planos separados, meses de esforço, reuniões para desenvolver e aprovar critérios, simulações, protótipos, pilotos e uma extensa documentação. [PA156.N107]

Podem ser utilizados critérios numéricos e não-numéricos em um processo formal de avaliação. Critérios numéricos utilizam pesos para refletir a importância relativa dos critérios. Critérios não-numéricos utilizam uma escala de classificação mais subjetiva (por exemplo, alto, médio, baixo). Decisões mais formais podem exigir um completo estudo comercial. [PA156.N108]

Um processo formal de avaliação identifica e avalia as soluções alternativas. A seleção final de uma solução pode envolver atividades iterativas de identificação e avaliação. Partes de alternativas identificadas podem ser combinadas, tecnologias emergentes podem modificar alternativas e a situação de mercado para os fornecedores pode se modificar, durante o período de avaliação. [PA156.N109]

Nível de Maturidade: 3, Análises de Decisões e Resoluções422


Uma alternativa recomendada é acompanhada pela documentação dos métodos selecionados, critérios, alternativas e justificativas para a recomendação. A documentação é distribuída para os stakeholders relevantes; ela fornece um registro do processo formal de avaliação e a sua justificativa, que é útil para outros projetos que encontrem uma questão semelhante. [PA156.N110]


Veja a área de processo de Planejamento do Projeto para obter maiores informações sobre o planejamento geral para os projetos. [PA156.R101]

Veja a área de processo de Gerenciamento Integrado do Projeto para obter maiores informações sobre o estabelecimento do processo definido do projeto. O processo definido do projeto inclui um processo de avaliação formal para cada questão selecionada e incorpora o uso de instruções para a aplicação de um processo formal de avaliação para questões não previstas. [PA156.R102]

Veja a área de processo de Gerenciamento de Riscos para obter maiores informações sobre a identificação e mitigação de riscos. Um processo formal de avaliação é, muitas vezes, utilizado para tratar questões com níveis de riscos identificados de médio a alto. As soluções selecionadas normalmente afetam os planos de mitigação de riscos. [PA156.R103]


SG 1 Avaliar Alternativas [PA156.IG101]

Decisões são baseadas em uma avaliação de alternativas utilizando critérios estabelecidos.




SG 1 Avaliar Alternativas [PA156.IG101]

SP 1.1 Estabelecer Instruções para a Análise de DecisõesSP 1.2 Estabelecer Critérios de AvaliaçãoSP 1.3 Identificar Soluções AlternativasSP 1.4 Selecionar Métodos de AvaliaçãoSP 1.5 Avaliar AlternativasSP 1.6 Selecionar Soluções






SG 1 Avaliar Alternativas

Decisões são baseadas em uma avaliação de alternativas utilizando critérios estabelecidos. [PA156.IG101]

Questões que exigem um processo formal de avaliação podem ser identificadas durante qualquer fase do ciclo de vida de um produto ou projeto. O objetivo deverá ser identificar questões com a maior antecedência possível, para maximizar o tempo disponível para resolver a questão. [PA156.IG101.N101]

SP 1.1 Estabelecer Instruções para a Análise de Decisões

Estabelecer e manter instruções para determinar quais questões estão sujeitas a um processo formal de avaliação. [PA156.IG101.SP101]

Nem toda decisão é significativa o bastante para exigir um processo formal de avaliação. A escolha entre o trivial e o realmente importante pode não ficar clara sem instruções explícitas. Se uma decisão é significativa ou não depende do projeto e das circunstâncias e isso é determinado pelas instruções estabelecidas. [PA156.IG101.SP101.N101]

Instruções típicas para determinar quando exigir um processo formal de avaliação incluem: [PA156.IG101.SP101.N102]

Quando uma decisão está diretamente relacionada com tópicos avaliados como sendo de risco médio ou alto

Quando uma decisão está relacionada com a mudança de produtos de trabalho sob gerenciamento de configurações

Quando uma decisão causaria atrasos no cronograma acima de um certo percentual ou quantidade específica de tempo



Quando uma decisão afeta a capacidade do projeto atender seus objetivos

Quando os custos do processo formal de avaliação são justificáveis, quando comparados com o impacto da decisão

Veja a área de processo de Gerenciamento de Riscos para obter maiores informações sobre como determinar quais questões são de risco médio ou alto. [PA156.IG101.SP101.N102.R101]

Exemplos de quando utilizar um processo de avaliação formal incluem: [PA156.IG101.SP101.N103]

Sobre a compra de material quando 20% das partes de material constituem 80% dos custos totais de material

Sobre decisões de implementação de design quando a falha no desempenho técnico pode causar uma falha catastrófica (por exemplo, segurança em um item de vôo)

Sobre decisões com o potencial de reduzir significativamente riscos de design, mudanças de engenharia, tempo do ciclo e custos de produção (por exemplo, usar modelos litográficos para avaliar a capacitação de formato e encaixe, antes de liberar modelos de engenharia e itens produzidos)


1. Instruções sobre quando aplicar um processo formal de avaliação [PA156.IG101.SP101.W101]

Sub-práticas

1. Estabelecer instruções. [PA156.IG101.SP101.SubP101]

2. Incorporar a utilização das instruções nos processos definidos, quando apropriado. [PA156.IG101.SP101.SubP102]

Veja a área de processo de Gerenciamento Integrado do Projeto para obter maiores informações sobre o estabelecimento do processo definido do projeto. [PA156.IG101.SP101.SubP102.R101]

SP 1.2 Estabelecer Critérios de Avaliação

Estabelecer e manter os critérios para a avaliação de alternativas e a classificação relativa destes critérios. [PA156.IG101.SP103]

Os critérios de avaliação fornecem a base para a avaliação de soluções alternativas. Os critérios são classificados de forma que os critérios com a maior classificação exercem maior influência na avaliação. [PA156.IG101.SP103.N101]



Esta área de processo é referenciada por muitas outras áreas de processos do modelo e existem diversos contextos nos quais um processo formal de avaliação pode ser utilizado. Portanto, em algumas situações você pode descobrir que os critérios já foram definidos como parte de outro processo. Esta prática específica não sugere que seja feito um segundo desenvolvimento de critérios. [PA156.IG101.SP103.N103]

Documentar os critérios de avaliação para minimizar a possibilidade das decisões serem criticadas ou que o motivo para a tomada daquela decisão seja esquecido. Decisões baseadas em critérios explicitamente definidos e estabelecidos removem as barreiras para serem aceitas pelos stakeholders. [PA156.IG101.SP103.N102]


1. Critérios de avaliação documentados [PA156.IG101.SP103.W101]

2. Classificações de importância de critérios [PA156.IG101.SP103.W102]

Sub-práticas

1. Definir os critérios para a avaliação de soluções alternativas. [PA156.IG101.SP103.SubP101]

Os critérios deverão se rastreáveis com os requisitos, cenários, hipóteses de casos de negócios, objetivos de negócios ou outras fontes documentadas. [PA156.IG101.SP103.SubP101.N101]

Tipos de critérios a serem considerados incluem: [PA156.IG101.SP103.SubP101.N102]


Impacto ambiental

Riscos

Custos de propriedade total e do ciclo de vida

2. Definir o intervalo e a escala para a classificação de critérios de avaliação. [PA156.IG101.SP103.SubP102]

Escalas de importância relativa dos critérios de avaliação podem ser estabelecidas com valores não-numéricos ou com fórmulas que relacionem o parâmetro de avaliação a um peso numérico. [PA156.IG101.SP103.SubP102.N101]

3. Classificar os critérios. [PA156.IG101.SP103.SubP103]

Os critérios são classificados de acordo com o intervalo e a escala definidos para refletir as necessidades, objetivos e prioridades dos stakeholders relevantes. [PA156.IG101.SP103.SubP103.N101]

4. Avaliar os critérios e sua importância relativa. [PA156.IG101.SP103.SubP105]

5. Evoluir os critérios de avaliação para melhorar sua validade. [PA156.IG101.SP103.SubP106]



6. Documentar a justificativa para a seleção ou rejeição dos critérios de avaliação. [PA156.IG101.SP103.SubP104]

A documentação dos critérios de seleção e das justificativas pode ser necessária para justificar as soluções ou para futura referência e uso. [PA156.IG101.SP103.SubP104.N101]

SP 1.3 Identificar Soluções Alternativas

Identificar soluções alternativas para tratar questões. [PA156.IG101.SP104]

Um gama maior de alternativas pode surgir através da solicitação da participação de todos os stakeholders que for possível consultar. As entradas dos stakeholders com diferentes habilidades e históricos podem ajudar as equipes a identificar e tratar hipóteses, restrições e tendências. Sessões de brainstorming podem estimular alternativas inovadoras, através da rápida interação e feedback. Suficientes soluções candidatas podem não ser fornecidas para análise. Conforme a análise prossegue, outras alternativas deverão ser adicionadas à lista de potenciais soluções candidatas. A geração e consideração prévia de múltiplas alternativas em um processo de análise de decisões e resoluções aumenta a probabilidade de que uma decisão aceitável seja tomada e que as conseqüências da decisão sejam entendidas. [PA156.IG101.SP104.N101]


1. Alternativas identificadas [PA156.IG101.SP104.W101]

Sub-práticas

1. Executar uma pesquisa na literatura. [PA156.IG101.SP104.SubP101]

Uma pesquisa na literatura pode descobrir o que outros já fizeram dentro ou fora da organização. Ela pode fornecer um entendimento mais profundo do problema, alternativas a serem consideradas, barreiras à implementação, estudos comerciais existentes e lições aprendidas a partir de decisões semelhantes. [PA156.IG101.SP104.SubP101.N101]

2. Identificar alternativas para consideração, além daquelas que possam ter sido fornecidas com a questão. [PA156.IG101.SP104.SubP102]

Critérios de avaliação são um eficiente ponto de partida para a identificação de alternativas. Os critérios de avaliação identificam as prioridades dos stakeholders relevantes e a importância dos desafios técnicos. [PA156.IG101.SP104.SubP102.N101]

Combinar atributos chave das alternativas existentes pode gerar alternativas adicionais e, algumas vezes, melhores. [PA156.IG101.SP104.SubP102.N102]

Solicitar alternativas dos stakeholders relevantes. Sessões de brainstorming, entrevistas e grupos de trabalho podem ser utilizados de forma eficiente para descobrir alternativas. [PA156.IG101.SP104.SubP102.N103]



3. Documentar as alternativas propostas. [PA156.IG101.SP104.SubP103]

SP 1.4 Selecionar Métodos de Avaliação

Selecionar os métodos de avaliação. [PA156.IG101.SP102]

Métodos para a avaliação de soluções alternativas contra os critérios estabelecidos podem variar de simulações ao uso de modelos probabilísticos e teoria da decisão. Estes métodos precisam ser cuidadosamente selecionados. O nível de detalhamento de um método deverá ser medido em relação ao custo, cronograma, desempenho e impacto dos riscos. [PA156.IG101.SP102.N101]

Embora muitos problemas possam precisar de somente um método de avaliação, alguns problemas podem exigir diversos métodos. Por exemplo, simulações podem melhorar um estudo comercial para determinar qual alternativa de design melhor atende a um dado critério. [PA156.IG101.SP102.N102]


1. Métodos de avaliação selecionados [PA156.IG101.SP102.W101]

Sub-práticas

1. Selecionar os métodos com base no objetivo da análise da decisão e na disponibilidade de informações utilizadas para dar suporte ao método. [PA156.IG101.SP102.SubP101]

Por exemplo, os métodos utilizados para avaliar uma solução técnica, quando os requisitos foram mal definidos, podem ser diferentes dos métodos utilizados quando os requisitos forem bem definidos. [PA156.IG101.SP102.SubP101.N101]

Métodos típicos de avaliação incluem: [PA156.IG101.SP102.SubP101.N102]

Simulações

Estudos de engenharia

Estudos de manufatura

Estudos de custos

Estudos de oportunidades de negócios

Pesquisas

Extrapolações baseadas em experiências de campo e protótipos

Revisões e comentários do usuário

Testes

2. Selecionar métodos de avaliação baseando-se na sua capacidade de se concentrar nas questões em foco, sem serem influenciados por questões adjacentes. [PA156.IG101.SP102.SubP102]



Resultados de simulações podem ser distorcidos por atividades aleatórias da solução que não estão diretamente relacionadas às questões em foco. [PA156.IG101.SP102.SubP102.N101]

3. Determinar as medidas necessárias para suportar o método de avaliação. [PA156.IG101.SP102.SubP103]

Considerar o impacto no custo, cronograma, desempenho e riscos. [PA156.IG101.SP102.SubP103.N101]

SP 1.5 Avaliar Alternativas

Avaliar as soluções alternativas utilizando os critérios e métodos estabelecidos. [PA156.IG101.SP105]

Avaliar soluções alternativas envolve análise, discussão e revisão. Ciclos iterativos de análises são, algumas vezes, necessários. Análises de suporte, experimentos, prototipação ou simulações podem ser necessários para substanciar a classificação e as conclusões. [PA156.IG101.SP105.N101]

Freqüentemente, a importância relativa dos critérios é imprecisa e o efeito total em uma solução não é aparente até que a análise seja feita. Em casos onde os pontos resultantes diferem por quantidades relativamente pequenas, a melhor seleção entre as soluções alternativas pode não ficar clara. Questionamentos aos critérios e hipóteses deverão ser encorajados. [PA156.IG101.SP105.N102]


1. Resultados de avaliações [PA156.IG101.SP105.W101]

Sub-práticas

1. Avaliar as soluções alternativas propostas utilizando os critérios de avaliação estabelecidos e os métodos selecionados. [PA156.IG101.SP105.SubP101]

2. Avaliar as hipóteses relacionadas aos critérios de avaliação e a evidência que suporta estas hipóteses. [PA156.IG101.SP105.SubP102]

3. Avaliar se a incerteza dos valores das soluções alternativas afeta a avaliação e tratá-la, conforme apropriado. [PA156.IG101.SP105.SubP103]

Por exemplo, se a classificação pode variar entre dois valores, a diferença é significativa o bastante para fazer diferença no conjunto final da solução? A variação na classificação representa um alto risco? Para tratar estes problemas, podem ser feitas simulações e estudos mais aprofundados ou critérios de avaliação podem ser modificados, entre outras coisas. [PA156.IG101.SP105.SubP103.N101]



4. Executar simulações, modelagem, protótipos e pilotos, conforme necessário, para exercitar os critérios de avaliação, métodos e as soluções alternativas. [PA156.IG101.SP105.SubP104]

Critérios não testados, sua importância relativa e os dados ou funções de suporte fazem com que a validade das soluções seja questionada. Os critérios e suas prioridades e escalas relativas podem ser testados com rodadas de testes contra um conjunto de alternativas. Estas rodadas de testes de um conjunto selecionado de critérios permitem a avaliação do impacto acumulativo dos critérios sobre uma solução. Se os testes revelarem problemas, critérios ou alternativas diferentes podem ser considerados para evitar essas influências. [PA156.IG101.SP105.SubP104.N101]

5. Considerar novas soluções alternativas, critérios ou métodos se os propostos não se derem bem nos testes; repetir as avaliações até que as alternativas passem nos testes. [PA156.IG101.SP105.SubP105]

6. Documentar os resultados da avaliação. [PA156.IG101.SP105.SubP106]

Documentar a justificativa para a adição de novas alternativas ou métodos e mudanças nos critérios, bem como os resultados de avaliações intermediárias. [PA156.IG101.SP105.SubP106.N101]

SP 1.6 Selecionar Soluções

Selecionar soluções a partir de alternativas com base nos critérios de avaliação. [PA156.IG101.SP106]

Selecionar soluções envolve pesar os resultados a partir da avaliação de alternativas. Os riscos associados com a implementação das soluções devem ser avaliados. [PA156.IG101.SP106.N101]


1. Soluções recomendadas para tratar questões significativas [PA156.IG101.SP106.W101]

Sub-práticas

1. Analisar os riscos associados com a implementação da solução recomendada. [PA156.IG101.SP106.SubP101]

Veja a área de processo de Gerenciamento de Riscos para obter maiores informações sobre a identificação e gerenciamento de riscos. [PA156.IG101.SP106.SubP101.R101]

Freqüentemente, decisões devem ser tomadas com informações incompletas. Pode haver um risco substancial associado com a decisão, pelo fato de haver informações incompletas. [PA156.IG101.SP106.SubP101.N101]



Quando decisões devem ser tomadas de acordo com um cronograma específico, tempo e recursos podem não estar disponíveis para reunir informações completas. Conseqüentemente, decisões arriscadas feitas com informações incompletas podem exigir uma reanálise posterior. Os riscos identificados deverão ser monitorados. [PA156.IG101.SP106.SubP101.N102]

2. Documentar os resultados e a justificativa para a solução recomendada. [PA156.IG101.SP106.SubP102]

É importante registrar tanto porque uma solução foi selecionada como porque outra solução foi rejeitada. [PA156.IG101.SP106.SubP102.N101]



Compromissos


Estabelecer e manter uma política organizacional para planejar e executar o processo de análises de decisões e resoluções. [GP103]

Elaboração:

Esta política estabelece as expectativas organizacionais para analisar seletivamente possíveis decisões utilizando um processo formal de avaliação, que avalia as alternativas identificadas contra os critérios estabelecidos. A política deverá também fornecer instruções sobre quais decisões exigem um processo formal de avaliação. [PA156.EL101]

Habilitações


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


Estabelecer e manter o plano para execução do processo de análises de decisões e resoluções. [GP104]



Elaboração:

Normalmente, este plano para execução do processo de análise de decisões e resolução está incluído no (ou é referenciado pelo) plano do projeto, que é descrito na área de processo de Planejamento do Projeto. [PA156.EL110]


Fornecer os recursos adequados para executar o processo de análises de decisões e resoluções, desenvolver os produtos de trabalho e fornecer os serviços do processo. [GP105]

Elaboração:


Simuladores e ferramentas de modelagem


Ferramentas para conduzir pesquisas


Atribuir responsabilidades e autoridade para executar o processo, desenvolver os produtos de trabalho e fornecer os serviços do processo de análises de decisões e resoluções. [GP106]


Treinar as pessoas para executar e suportar o processo de análises de decisões e resoluções, conforme necessário. [GP107]

Elaboração:


Análises formais de decisão

Métodos para avaliar soluções alternativas contra critérios



Implementações


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

Elaboração:


Instruções sobre quando aplicar um processo formal de avaliação

Relatórios de avaliação contendo as soluções recomendadas


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

Elaboração:


Estabelecer instruções sobre quais questões estão sujeitas a um processo formal de avaliação

Estabelecer critérios de avaliação

Identificar e avaliar alternativas

Selecionar métodos de avaliação

Selecionar soluções


Monitorar e controlar o processo de análises de decisões e resoluções contra o plano para execução do processo e tomar as ações corretivas apropriadas. [GP110]

Elaboração:


Razão custo-benefício do uso de processos formais de avaliação




Coletar produtos de trabalho, medidas, resultados de medições e informações de melhorias derivados do planejamento e execução do processo de análises de decisões e resoluções para suportar o uso futuro e a melhoria dos processos e ativos de processos da organização. [GP117]

Verificações


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

Elaboração:


Avaliar alternativas utilizando critérios e métodos estabelecidos


Instruções sobre quando aplicar um processo formal de avaliação

Relatórios de avaliação contendo soluções recomendadas


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



A. Acrônimos

AB Habilitações (característica comum) (Ability)

ARC Requisitos de Avaliação para o CMMI (Appraisal Requirements for CMMI)

CAR Análise de Causas e Resoluções (Causal Analysis and Resolution) (área de processo)

CBA IPI Avaliação baseada no CMM para a Melhoria de Processos Internos (CMM-Based Appraisal for Internal Process Improvement)

CCB Comitê de controle de configurações (configuration control board)

CM Gerenciamento de Configurações (Gerenciamento de Configurações) (área de processo)

CMM Modelo de Maturidade de Capacitação (Capability Maturity Model)

CMMI Modelo Integrado de Maturidade de Capacitação (Capability Maturity Model Integration)

CMMI-SE/SW Modelo Integrado de Maturidade de Capacitação para Engenharia de Sistemas e Engenharia de Software (Capability Maturity Model Integration for Systems Engineering and Software Engineering)

CO Compromissos (commitments) (característica comum)

COTS Produto de prateleira (commercial off the shelf)

CPM Método do caminho crítico (critical path method)

DAR Análises de Decisões e Resoluções (Decision Analisys and Resolution) (área de processo)

DI Implementações (Direct Implementation) (característica comum)

Acrônimos 435


DoD Departamento de Defesa dos Estados Unidos (Department of Defense)

EIA/IS Electronic Industries Alliance Interim Standard

GG Meta genérica (generic goal)

GP Prática genérica (generic practice)

IDEAL Iniciar, Diagnosticar, Estabelecer, Agir, Aprender (Initiating, Diagnosing, Establishing, Acting, Learning)

IPD-CMM Desenvolvimento Integrado do Produto – Modelo de Maturidade de Capacitação (Integrated Product Development Capability Maturity Model)

IPM Gerenciamento Integrado do Projeto (Integrated Project Management) (área de processo)

IPPD Desenvolvimento Integrado do Produto e do Processo (Integrated Product and Process Development)

IPT Equipe Integrada do Produto (Integrated Product Team)

ISO Organização Internacional para Padronização (International Organization for Standardization)

ISO/IEC Organização Internacional para Padronização e Comissão Eletrotécnica Internacional (International Organization for Standardization and International Electrotechnical Commission)

IT Equipes Integradas (Integrated Teaming) (área de processo)

MA Medições e Análises (Medições e Análises) (área de processo)

MOA Memorando de Acordo (Memorandum of Agreement)

OEI Ambiente Organizacional para Integração (Organizational Environment for Integration) (área de processo)

OID Inovação Organizacional e Implantação (Organizational Innovation and Deployment) (área de processo)

OPD Definição do Processo Organizacional (process area)

OPF Foco no Processo Organizacional (Organizational Process Focus) (área de processo)

Acrônimos436


OPP Desempenho do Processo Organizacional (Organizational Process Performance) (área de processo)

OT Organizational Trainning (Treinamento Organizacional) (área de processo)

OUSD/AT&L Escritório da Sub-Secretaria de Defesa, Aquisição, Tecnologia e Logística (Office of the Under Secretary of Defense, Acquisition, Technology, and Logistics)

PA Área de processo (process area)

PAIS Sistema de Informações de Avaliações de Processos (Process Appraisal Information System)

PERT Técnica de Avaliação e Revisão de Programação (Program Evaluation and Review Technique)

PI Integração de Produtos (Integração de Produtos) (área de processo)

PMC Monitoramento e Controle do Projeto (Monitoramento e Controle do Projeto) (área de processo)

PP Planejamento do Projeto (Planejamento do Projeto) (área de processo)

PPQA Garantia da Qualidade do Processo e do Produto (Garantia da Qualidade do Processo e do Produto) (área de processo)

QFD Implantação da Função de Qualidade (Quality Function Deployment)

QPM Gerenciamento Quantitativo do Projeto (Quantitative Project Management) (área de processo)

RD Desenvolvimento de Requisitos (Desenvolvimento de Requisitos) (área de processo)

REQM Gerenciamento de Requisitos (Gerenciamento de Requisitos) (área de processo)

RSKM Risks Management (Gerenciamento de Riscos) (área de processo)

SA-CMM Modelo de Maturidade de Capacitação de Aquisição de Software (Software Acquisition Capability Maturity Model)

Acrônimos 437


SAM Gerenciamento de Acordos com Fornecedores (Gerenciamento de Acordos com Fornecedores) (área de processo)

SCAMPI Método Padrão de Avaliação CMMI para Melhoria de Processos (Standard CMMI Appraisal Method for Process Improvement)

SE-CMM Modelo de Maturidade de Capacitação para Engenharia de Sistemas (Systems Engineering Capability Maturity Model)

SECAM Modelo de Avaliação de Capacitação de Engenharia de Sistemas (Systems Engineering Capability Assessment Model)

SECM Modelo de Capacitação de Engenharia de Sistemas (Systems Engineering Capability Model)

SE/SW Engenharia de sistemas e engenharia de software (systems engineering and software engineering)

SG Meta específica (specific goal)

SP Prática específica (specific practice)

SW-CMM Modelo de Maturidade de Capacitação para Software (Capability Maturity Model for Software)

TS Soluções Técnicas (Soluções Técnicas) (área de processo)

VAL Validação (Validação) (área de processo)

VE Verificações (Verificação) (característica comum)

VER Verificação (Verificação) (área de processo)

WBS Estrutura de decomposição do trabalho (work breakdown structure)

Acrônimos438


Acrônimos 439


B. Glossário

O glossário do CMMI define muitos dos termos básicos utilizados nos modelos CMMI. As entradas do glossário são normalmente termos com várias palavras, consistindo de um nome e um ou mais modificadores restritivos (por exemplo, em lugar de definir “adaptação”, são definidos “adaptação do modelo CMMI”, “adaptação de avaliação CMMI” e “instruções de adaptação”). (Existem algumas exceções a esta regra que tratam de termos de palavra única no glossário). [FM113.T101]

O glossário foi desenvolvido utilizando critérios definidos para a seleção dos termos e definições. Alguns termos não foram incluídos no glossário porque foram utilizados somente em uma única área de processo ou porque o termo foi utilizado no seu sentido comum. Em qualquer caso, o uso do termo é explicado na área de processo. [FM113.T102]

Para serem considerados para inclusão no glossário dos modelos CMMI, os termos devem atender as seguintes condições: [FM113.T103]

Condição 1 – A entrada deve aparecer nos modelos CMMI. O glossário não inclui palavras que sejam auto-explicativas no contexto do produto CMMI ou que, através do uso popular, já são amplamente compreendidas pelos usuários do modelo. Os termos utilizados somente como exemplos e que não sejam conceitos críticos para o uso dos modelos CMMI, também foram excluídos. Entretanto, se havia alguma dúvida sobre o entendimento do termo, este foi incluído no glossário. [FM113.T104]

Condição 2 – A definição do termo não é satisfeita com uma definição comum do dicionário. A melhor fonte de referência para as definições do termo é um dicionário comum. Entretanto, uma vez que um termo foi identificado no CMMI Product Suite, ele (ou as palavras que o compõe) foram pesquisadas (em inglês) no Miriam-Webster’s Online Collegiate Dictionary (http://www.m-w.com). Se a definição encontrada caracterizava de forma suficientemente precisa a maneira como o termo foi utilizado nos produtos CMMI, o termo foi deixado de fora do glossário, porque não havia uma necessidade premente de replicar definições comuns encontradas no dicionário. [FM113.T105]

Glossário440


Condição 3 – Em alguns casos, os termos utilizados nos modelos CMMI são únicos no contexto do CMMI. Nestes casos, definições originais não encontradas em outros contextos foram criadas. Quando foram selecionadas ou criadas as definições do CMMI, foi tomado um grande cuidado para assegurar que as definições não tinham alguma das seguintes características: [FM113.T106]

Definições circulares

Definições auto-definidas, quando um termo é utilizado para definir a si próprio

Termos que estão diferenciados, quando na realidade são sinônimos, de acordo com um dicionário padrão

Definições altamente restritivas que obstruiriam o uso dos termos, normalmente entendidos pelo público em situações mais comuns

Definições que fornecer informações explicativas que pertenceriam melhor a outro lugar do modelo

Quando foram selecionadas as definições para os termos do glossário CMMI, foram utilizadas, quando possível, definições de fontes reconhecidas. As definições foram primeiro selecionadas a partir de fontes existentes que eram amplamente conhecidas nas disciplinas de desenvolvimento de software, desenvolvimento de sistemas e IPPD. Se uma definição foi selecionada a partir de uma destas fontes, uma anotação no final da definição entre colchetes (por exemplo, [ISO 9000]), foi incluída. A ordem de precedência utilizada na seleção de definições foi: [FM113.T109]

1. Dicionário Webster’s 2. ISO/IEC 90003. ISO/IEC 122074. ISO/IEC 155045. ISO/IEC 152886. Modelos fonte do CMMI [FM113.T115]

IPD-CMM v0.98

EIA/IS 731 (SECM)

SW-CMM v 2, draft C

7. CMMI A-Spec8. IEEE9. SW-CMM v1.110. EIA 63211. SA-CMM12. FAA-CMM13. P-CMM [FM113.T116]

Glossário 441


O Glossário foi desenvolvido reconhecendo a importância do uso de terminologia que todos os usuários do modelo possam entender. Ele também reconhece que palavras e termos podem ter diferentes significados em diferentes contextos e ambientes. O glossário dos modelos CMMI foi projetado para documentar os significados de palavras e termos que deverão ter o mais amplo uso e entendimento pelos usuários dos produtos CMMI. [FM113.T117]

Ação corretiva (corrective action)

Atos ou ações utilizados para remediar uma situação, remover um erro ou ajustar uma condição.

Adaptação de avaliação CMMI (CMMI appraisal tailoring)

Seleção de opções dentro do método de avaliação para uso em uma instância específica.

A intenção da adaptação da avaliação é ajudar uma organização a alinhar a aplicação do método com os seus objetivos de negócios.

Adaptação do modelo CMMI (CMMI model tailoring)

A utilização de um subconjunto de um modelo CMMI com o objetivo de torná-lo adequado para uma aplicação específica. A intenção da adaptação do modelo é ajudar uma organização a alinhar a aplicação de um modelo com seus objetivos de negócios.

Adaptação de processo (process tailoring)

Fazer, alterar ou adaptar uma descrição de processo para um fim específico. Por exemplo, um projeto adapta seu processo definido a partir do conjunto de processos padrão da organização para atender seus objetivos, restrições e ambiente do projeto. (Veja “descrição de processo”, “conjunto de processos padrão da organização” e “processo definido”).

Adequado (adequate)

Veja no Capítulo 3 uma explicação de como os termos “adequado”, “apropriado” e “conforme necessário” são utilizados no CMMI Product Suite.

Análise (assessment)

Veja no Capítulo 3 uma explicação de como a palavra “análise” é utilizada no CMMI Product Suite.

Análise de causas (causal analysis)

A análise de defeitos para determinar a causa.

Análise de requisitos (requirements analysis)

A determinação de desempenho de um produto específico e das características funcionais baseada em análises de necessidades de clientes, expectativas e restrições; conceito operacional; ambientes de utilização projetados para as pessoas, produtos e processos; e medidas de eficácia.

Glossário442


Análise de riscos (risk analysis)

A avaliação, classificação e priorização de riscos.

Análise funcional (functional analysis)

Exame de uma função definida para identificar todas as subfunções necessárias para o cumprimento daquela função; identificação de relacionamentos funcionais e interfaces (internas e externas) e captura destes em uma arquitetura funcional e o caminho todo dos requisitos de desempenho de alto nível e a atribuição destes requisitos a subfunções de mais baixo nível. (Veja “arquitetura funcional”).

Apropriado (appropriate)


Aquisição (acquisition)

O processo de obtenção, através de contrato, de qualquer ação distinta ou ação proposta que a entidade de aquisição se comprometeria a investir (fundos adequados) para obter produtos ou serviços.

Área de processo (process area)

Veja no Capítulo 2 uma explicação de como “área de processo” é utilizado no CMMI Product Suite.

Arquitetura funcional (functional architecture)

O arranjo hierárquico de funções, suas interfaces funcionais internas e externas (externas à própria agregação) e interfaces físicas externas, seus requisitos funcionais e de desempenho respectivos e suas restrições de design.

Arquiteturas de processos (process architectures)

Veja no Capítulo 3 uma explicação de como “arquiteturas de processos” é utilizado no CMMI Product Suite.

Ativo de processo (process asset)

Qualquer coisa que a organização considera útil para atender as metas de uma área de processo. (Veja “ativos de processos organizacionais”).

Ativos de processos organizacionais (organizational process assets)

Veja no Capítulo 3 uma explicação de como “ativos de processos organizacionais” é utilizado no CMMI Product Suite.

Atributo de processo (process attribute)

Uma característica mensurável da capacitação do processo aplicável a qualquer processo.

Glossário 443


Atributos de produtos de trabalho e tarefas (work product and task attributes)

Características de produtos, serviços e tarefas de projetos utilizadas para ajudar a estimar o trabalho do projeto. Estas características incluem itens como tamanho, complexidade, peso, formato, encaixe ou função. Estas são normalmente utilizadas como entrada para derivar outras estimativas de projeto e de recursos (por exemplo, esforço, custo, cronograma).

Auditoria (audit) No trabalho de melhoria de processos do CMMI, um exame independente de um produto de trabalho ou de um conjunto de produtos de trabalho para determinar se os requisitos estão sendo satisfeitos.

Auditoria de configurações (configuration audit)

Uma auditoria conduzida para verificar se um item de configuração atende a um padrão ou requisito específico. (Veja “auditoria” e “item de configuração”).

Avaliação (appraisal)

Veja o Capítulo 3 para uma explicação de como a palavra “avaliação” é utilizada no CMMI Product Suite.

Avaliação da capacitação (capability evaluation)

Uma avaliação feita por uma equipe de profissionais treinados utilizada como distinção para selecionar fornecedores, monitorar contratos e para incentivos. As avaliações são usadas para ajudar os tomadores de decisões a tomar melhores decisões de aquisição, melhorar o desempenho dos subcontratados e fornecer visibilidade para a organização que está fazendo a aquisição.

Avaliador líder (lead appraiser)

Conforme utilizado no CMMI Product Suite, uma pessoa que conseguiu o reconhecimento de um corpo de autorização para desempenhar o papel de líder de uma equipe de avaliação, para um método de avaliação específico.

Avaliar objetivamente (objectively evaluate)

Revisar atividades e produtos de trabalho contra critérios que minimizem a subjetividade e influências do revisor. Um exemplo de uma avaliação objetiva é uma auditoria contra os requisitos, padrões ou procedimentos para uma função de garantia da qualidade independente (Veja “auditoria”).

Baseline (Veja “baseline de configurações”, “baseline do desempenho do processo” e “baseline do produto”).

Glossário444


Baseline de configurações (configuration baseline)

As informações de configurações formalmente projetadas em um momento específico durante a vida de um produto ou componente de produto. Baselines de configurações, mais as mudanças aprovadas a estas baselines, constituem as informações atuais de configurações. (Veja “ciclo de vida do produto”).

Baseline de desempenho do processo (process performance baseline)

Uma caracterização documentada dos resultados reais atingidos seguindo-se um processo, que é utilizada como benchmark para comparação do desempenho real do processo contra o seu desempenho esperado. (Veja “desempenho do processo”).

Baseline do produto (product baseline)

No gerenciamento de configurações, o pacote de dados técnicos inicialmente aprovado (incluindo, para software, a listagem do código fonte) definindo um item de configuração durante a produção, operação, manutenção e suporte logístico do seu ciclo de vida. (Veja “gerenciamento de configurações” e “item de configuração”).

Biblioteca de ativos de processos (process asset library)

Uma coleção de ativos de processos mantidos que podem ser utilizados por uma organização ou projeto. (Veja “biblioteca de ativos de processos da organização”).

Biblioteca de ativos de processos da organização (organization’s process asset library)

Veja no Capítulo 3 uma explicação de como “biblioteca de ativos de processos da organização” é utilizado no CMMI Product Suite.

Capacitação do processo (process capability)

A faixa de resultados esperados que pode ser atingida seguindo um processo. [EIA/IS 731, V1.0]

Causa atribuída da variação do processo (assignable cause of process variation)

No CMMI, o termo “causa especial de variação do processo” é utilizado em lugar de “causa atribuída da variação do processo” para assegurar consistência. Ambos os termos são definidos de forma idêntica. (Veja “causa especial de variação do processo”).

Causa comum de variação de processos (common cause of process variation)

A variação de um processo que existe por causa de interações normais e esperadas entre os componentes de um processo. (Veja “causas especiais de variação de processos”).

Glossário 445


Causa especial de variação do processo (special cause of process variation)

Uma causa de um defeito que é específico de alguma circunstância passageira e não uma parte inerente do processo. (Veja “causa comum de variação de processo”).

Causa raiz (root cause)

Uma causa raiz é uma fonte de um defeito que, se for removida, o defeito será diminuído ou removido.

Cenário operacional (operational scenario)

Uma descrição de uma seqüência imaginária de eventos que incluem a interação do produto com seu ambiente e usuários, bem como a interação entre seus componentes do produto. Cenários operacionais são utilizados para avaliar os requisitos e o design do sistema e verificar e validar o sistema.

Ciclo de vida do produto (product life cycle)

Veja no Capítulo 3 uma explicação de como “ciclo de vida do produto” é utilizado no CMMI Product Suite.

Classificação (rating)

(Veja “classificação da avaliação”).

Classificação da avaliação (appraisal rating)

Conforme utilizado nos materiais de avaliação do CMMI, o valor atribuído por uma equipe de avaliação para (1) uma meta ou área de processo do CMMI, (2) o nível de capacitação de uma área de processo e (3) o nível de maturidade de uma unidade organizacional. A classificação é determinada pela atuação do processo de classificação definido para o método de avaliação que está sendo empregado.

Cliente (customer) Veja no Capítulo 3 uma explicação de como “cliente” é utilizado no CMMI Product Suite.

CMMI Framework Veja no Capítulo 3 uma explicação de como “CMMI Framework” é utilizado no CMMI Product Suite.

CMMI Product Suite Veja no Capítulo 3 uma explicação de como “CMMI Product Suite” é utilizado no CMMI Product Suite. (Veja “CMMI Framework”).

Comitê de controle de configurações (configuration control board)

Um grupo de pessoas responsáveis por avaliar e aprovar ou desaprovar mudanças propostas aos itens de configuração e por assegurar a implementação das mudanças aprovadas. (Veja “item de configuração”). Os comitês de controle de configurações são também conhecidos como “comitês de controle de mudanças”.

Componente de produto (product component)

Veja no Capítulo 3 uma explicação de como “componente de produto” é utilizado no CMMI Product Suite.

Glossário446


Componente do modelo CMMI (CMMI model component)

Qualquer um dos principais elementos de arquitetura que compõem o modelo CMMI. Alguns dos principais elementos do modelo CMMI incluem práticas específicas, práticas genéricas, metas específicas, metas genéricas, áreas de processos, níveis de capacitação e níveis de maturidade.

Componentes CMMI esperados (expected CMMI components)

Os componentes CMMi que explicam o que deve ser feito para satisfazer um componente CMMI exigido. Os usuários do modelo podem implementar os componentes esperados de forma explícita ou implementar práticas alternativas equivalentes a estes componentes. Práticas específicas e genéricas são componentes esperados do modelo.

Componentes exigidos do CMMI (required CMMI components)

Componentes do CMMI que são essenciais para atingir a melhoria de processos em uma dada área de processo. Estes componentes são utilizados em avaliações para determinar a capacitação do processo. Metas específicas e metas genéricas são componentes exigidos do modelo.

Componentes informativos do CMMI (informative CMMI components)

Componentes do CMMI que ajudam os usuários do modelo a entender os componentes exigidos e esperados de um modelo. Estes componentes podem conter exemplos, explicações detalhadas e outras informações de auxílio. Sub-práticas, notas, referências, títulos de metas, títulos de práticas, fontes, produtos de trabalho típicos, definições ampliadas de disciplinas e elaborações de práticas genéricas são componentes informativos de modelos.

Compromissos (commitment to perform)

Uma característica comum das áreas de processos do modelo CMMI com uma representação em estágios, que agrupa as práticas genéricas relacionadas com a criação de políticas e a garantia de patrocínio.

Comunicação do status de configurações (configuration status accounting)

Um elemento do gerenciamento de configurações que consiste do registro e relato de informações necessárias para gerenciar efetivamente uma configuração. Estas informações incluem uma lista das identificações de configurações aprovadas, o status das mudanças propostas às configurações e o status da implementação das mudanças aprovadas. (Veja “gerenciamento de configurações” e “identificação de configurações”).

Conceito de operações (concept of operations)

(Veja “conceito operacional”).

Conceito operacional (operational concept)

Uma descrição geral da maneira pela qual uma entidade é utilizada ou opera. (Também conhecido como “conceito de operações”).

Glossário 447


Conjunto de processos padrão da organização (organization's set of standard processes)

Veja no Capítulo 3 uma explicação de como “conjunto de processos padrão da organização” é utilizado no CMMI Product Suite. (Veja “processo definido” e “elemento de processo”).

Conjunto de produtos (product suite)

(Veja “CMMI Product Suite”).

Conforme necessário (as needed)


Contexto do processo (process context)

O conjunto de fatores, documentados nas entradas da avaliação, que influenciam o julgamento e comparação das classificações da avaliação.

Estes incluem, embora não estejam limitados a, o tamanho da unidade organizacional a ser avaliada; a demografia da unidade organizacional; a disciplina de aplicação dos produtos ou serviços; o tamanho, criticidade e complexidade dos produtos ou serviços e as características de qualidade dos produtos ou serviços.

Contratado (contractor)

(Veja “fornecedor”).

Controle da qualidade (quality control)

As técnicas e atividades operacionais que são utilizadas para atender os requisitos para a qualidade. [ISO 8402-1994] (Veja “garantia da qualidade”).

Controle de configurações (Configuration control)

Um elemento de gerenciamento de configurações consistindo da avaliação, coordenação, aprovação ou desaprovação e implementação das mudanças nos itens de configuração, após o estabelecimento formal de sua identificação de configuração. (Veja “gerenciamento de configurações”, “identificação de configurações” e “itens de configurações”).

Controle de interfaces (interface control)

No gerenciamento de configurações, o processo de (1) identificar todas as características funcionais e físicas relevantes para as interfaces entre dois ou mais itens de configuração fornecidos por uma ou mais organizações e (2) assegurar que as mudanças propostas a estas características são avaliadas e aprovadas antes de sua implementação. [IEEE 828-1983] (Veja “gerenciamento de configurações” e “item de configuração”).

Glossário448


Controle de versões (version control)

O estabelecimento e manutenção de baselines e a identificação de mudanças nas baselines, que tornam possível retornar à baseline anterior.

Controle estatístico do processo (statistical process control)

Análise baseada em estatísticas de um processo e medições do desempenho de um processo, que identificará causas comuns e especiais de variação do desempenho do processo e manterá o desempenho do processo dentro de limites. (Veja “causa comum de variação do processo”, “processo estatisticamente gerenciado” e “causa especial de variação do processo”).

Critérios de aceitação (acceptance criteria)

Os critérios que um produto ou componente de produto deve satisfazer para ser aceito por um usuário, cliente ou outra entidade autorizada.

Critérios de entrada (entry criteria)

Estados que devem estar presentes antes que um esforço possa começar com sucesso. Também chamados de pré-condições.

Critérios de saída (exit criteria)

Estados que devem estar presentes antes que um esforço possa ser encerrado com sucesso. Também chamados de pós-condições.

Declaração de trabalho (statement of work)

Uma descrição do trabalho contratado necessário para completar um projeto.

Definição do processo (process definition)

O ato de definir e descrever um processo. O resultado da definição do processo é uma descrição do processo. (Veja “descrição do processo”).

Definições ampliadas de disciplinas (discipline amplification)

Veja no Capítulo 2 uma explicação de como “definições ampliadas de disciplinas” são utilizadas no CMMI Product Suite.

Densidade de defeitos (defect density)

Quantidade de defeitos por unidade de tamanho do produto (por exemplo, problemas relatados por 1000 linhas de código).

Descobertas (finding)

(Veja “descobertas da avaliação”).

Glossário 449


Descobertas da avaliação (appraisal findings)

As conclusões de uma avaliação que identificam as questões mais importantes, problemas ou oportunidades dentro do escopo da avaliação. As descobertas incluem, no mínimo, os pontos fortes e fracos baseados em observações válidas.

Descrição do processo (process description)

Uma expressão documentada de um conjunto de atividades executadas para atingir um dado objetivo, que oferece uma definição dos principais componentes de um processo. A documentação especifica, de uma forma completa, precisa e verificável, os requisitos, design, comportamento e outras características de um processo. Ela também pode incluir procedimentos para determinar se estas provisões foram satisfeitas. Descrições de processos podem ser encontradas no nível de atividade, projeto ou organização.

Desempenho do processo (process performance)

Uma medida dos resultados reais a serem atingidos seguindo-se um processo. Ela é caracterizada por medidas de processos (por exemplo, esforços, tempo do ciclo e eficiência de remoção de defeitos) e medidas de produtos (por exemplo, confiabilidade, densidade de defeitos e tempo de resposta).

Desenvolvimento (development)

Veja no Capítulo 3 uma explicação de como “desenvolvimento” é utilizado no CMMI Product Suite.

Desenvolvimento Integrado do Produto e do Processo (Integrated Product and Process Development)

Uma abordagem sistemática para o desenvolvimento do produto que consegue uma colaboração pontual dos stakeholders relevantes, durante todo o ciclo de vida do produto, para melhor satisfazer as necessidades do cliente.

Elaboração da prática genérica (generic practice elaboration)

Veja no Capítulo 2 uma explicação de como “elaboração da prática genérica” é utilizada no CMMI Product Suite.

Glossário450


Elemento de processo (process element)

A unidade fundamental de um processo. Um processo pode ser definido em termos de subprocessos ou elementos de processo. Um subprocesso pode ser mais decomposto; um elemento de processo não pode.

Cada elemento de processo cobre um conjunto fortemente relacionado de atividades (por exemplo, elementos de estimativa, elementos de revisão por pares). Elementos de processos podem ser retratados utilizando templates a serem completados, abstrações a serem refinadas ou descrições a serem modificadas ou utilizadas. Um elemento de processo pode ser uma atividade ou tarefa.

Elicitação de requisitos (requirements elicitation)

Utilizar técnicas sistemáticas, como protótipos e pesquisas estruturadas, para identificar e documentar de forma pró-ativa as necessidades do cliente e do usuário final.

Empreendimento (enterprise)

Veja no Capítulo 3 uma explicação de como “empreendimento” é utilizado no CMMI Product Suite.

Engenharia de sistemas (systems engineering)

A abordagem interdisciplinar que governa o esforço total técnico e gerencial exigido para transformar um conjunto de necessidades do cliente, expectativas e restrições em uma solução de produto e suporte àquela solução durante toda a vida do produto.

Isto inclui a definição de medidas de desempenho técnico, a integração de especialidades da engenharia em direção ao estabelecimento de uma arquitetura de produto e a definição de processos de suporte do ciclo de vida que equilibram os objetivos de custo, desempenho e cronograma.

Engenharia de software (software engineering)

(1) A aplicação de uma abordagem sistemática, disciplinada e quantificável para o desenvolvimento, operação e manutenção de software. (2) O estudo de abordagens como as de (1).

Equipe de ação de processo (process action team)

Uma equipe que tem a responsabilidade de desenvolver e implementar atividades de melhoria de processos para uma organização, conforme documentado no plano de ação de melhoria de processos.

Glossário 451


Equipe integrada (integrated team)

Um grupo de pessoas com habilidades e conhecimentos complementares que estão comprometidas com a entrega de produtos de trabalho específicos em uma colaboração pontual. Membros da equipe integrada fornecem habilidades e o suporte apropriado a todas as fases da vida dos produtos de trabalho e são coletivamente responsáveis por entregar os produtos de trabalho conforme especificados. Uma equipe integrada deverá incluir representantes fortes das organizações, disciplinas e funções que têm influência no sucesso dos produtos de trabalho.

Escopo da avaliação (appraisal scope)

A definição das fronteiras da avaliação, levando em conta os limites organizacionais e os limites do modelo CMMI.

Estabelecer e manter (establish and maintain)

Veja no Capítulo 3 uma explicação sobre como “estabelecer e manter” são utilizadas no CMMI Product Suite.

Estágios alvo (target staging)

Na representação contínua, uma seqüência de perfis alvo que descrevem o caminho da melhoria do processo a ser seguido pela organização. (Veja “perfil de nível de capacitação”, “perfil de satisfação” e “perfil alvo”).

Estágios equivalentes (equivalent staging)

Estágios equivalentes são estágios alvo, criados utilizando a representação contínua, definidos de forma que os resultados da utilização do estágio equivalente possam ser comparados com os níveis de maturidade da representação em estágios. (Veja “estágios alvo”, “nível de maturidade”, “perfil de nível de capacitação” e “perfil alvo”).

Tais estágios permitem fazer um benchmark do progresso entre organizações, empreendimentos e projetos, independente da representação CMMI utilizada. A organização pode implementar componentes de modelos CMMI, além daqueles relatados como parte do estágio equivalente. Os estágios equivalentes são somente uma medida para relatar como a organização é comparada a outras organizações em termos de níveis de maturidade.

Estratégia de aquisição (acquisition strategy)

A abordagem específica para adquirir produtos e serviços que se baseia em considerações sobre as fontes de fornecimento, métodos de aquisição, tipos de especificação de requisitos, tipos de contratos ou acordos e os riscos relacionados à aquisição.

Glossário452


Estratégia de gerenciamento de riscos (gerenciamento de riscos strategy)

Uma abordagem técnica e organizada para identificar o que poderia causar perda ou dano (identificar riscos), avaliar e quantificar os riscos identificados e desenvolver e, se necessário, implementar uma abordagem apropriada para prevenir ou tratar causas de riscos que poderiam resultar em um dano ou perda significativos. Normalmente, o gerenciamento de riscos é desempenhado para o projeto, organização ou unidades organizacionais de desenvolvimento do produto.

Estrutura de decomposição do trabalho (work breakdown structure)

Um arranjo de elementos de trabalho e seus relacionamentos uns com os outros e com o produto final.

Estudo comercial (trade study)

Uma avaliação de alternativas baseada em critérios e análise sistemática, para selecionar a melhor alternativa para conseguir determinados objetivos.

Evidência (evidence)

(Veja “evidência objetiva”).

Evidência objetiva (objective evidence)

Conforme utilizado nos materiais de avaliação do CMMI, as informações qualitativas ou quantitativas, registros ou declarações de fatos pertinentes às características de um item ou serviço ou à existência e implementação de um elemento de processo, que são baseadas na observação, medição ou testes e que são verificáveis.

Executivo (executive)

(Veja “gerente sênior”).

Fornecedor (supplier)

(1) Uma entidade que entrega produtos ou executa serviços que estão sendo adquiridos. (2) Um indivíduo, parceiro, companhia, corporação, associação ou outro serviço sob um acordo (contrato) com o aquisidor do design, desenvolvimento, manufatura, manutenção, modificação ou fornecimento de itens sob os termos de um acordo (contrato).

Framework (Veja “CMMI Framework”).

Garantia da qualidade (quality assurance)

Meios planejados e sistemáticos para assegurar ao gerenciamento que os padrões definidos, práticas, procedimentos e métodos do processo estão sendo aplicados.

Glossário 453


Gerenciamento de configurações (configuration management)

Uma disciplina que aplica um direcionamento técnico e administrativo e vigilância a (1) identificar e documentar as características funcionais e físicas de um item de configuração, (2) controlar mudanças a estas características, (3) registrar e relatar o processamento de mudanças e o status da implementação e (4) verificar a conformidade com os requisitos especificados. [IEEE Std 610.1990] (Veja “identificação de configuração”, “controle de configurações”, “comunicação do status de configurações” e “auditoria de configurações”).

Gerenciamento de dados (data management)

Princípios, processos e sistemas para o compartilhamento e gerenciamento de dados.

Gerenciamento de mudanças (change management)

O uso cuidadoso de meios para efetivar uma mudança, ou uma proposta de mudança, em um produto ou serviço (Veja “gerenciamento de configurações”).

Gerenciamento de requisitos (requirements management)

O gerenciamento de todos os requisitos recebidos e gerados pelo projeto, incluindo os requisitos técnicos e não-técnicos, bem como aqueles requisitos impostos no projeto pela organização.

Gerenciamento de riscos (gerenciamento de riscos )

Um processo organizado e analítico para identificar o que poderia causar dano ou perda (identificar riscos), avaliar e quantificar os riscos identificados e desenvolver e, se necessário, implementar uma abordagem apropriada para prevenir ou tratar causas de riscos que poderiam resultar em um dano ou perda significativos.

Gerente (manager) Veja no Capítulo 3 uma explicação de como “gerente” é utilizado no CMMI Product Suite.

Gerente do projeto (project manager)

Veja no Capítulo 3 uma explicação de como “gerente do projeto” é utilizado no CMMI Product Suite.

Gerente sênior (senior manager)

Veja no Capítulo 3 uma explicação de como “gerente sênior” é utilizado no CMMI Product Suite.

Grupo de processo (process group)

Uma coleção de especialistas que facilita a definição, manutenção e melhoria dos processos utilizados na organização.

Grupo independente (independent group)

Na área de processo de Garantia da Qualidade do Processo e do Produto, veja a discussão sobre um “grupo que é independente” nas Notas Introdutórias.

Glossário454


Habilitação (ability to perform)

Uma característica comum das áreas de processos do modelo CMMI com representação em estágios, que agrupa as práticas genéricas relacionadas a assegurar que o projeto e/ou organização tem os recursos que necessita.

Identificação de configuração (configuration identification)

Um elemento de gerenciamento de configuração consistindo da seleção de itens de configuração para um produto, atribuição de identificadores únicos para eles e registro de suas características funcionais e físicas na documentação técnica. (Veja “gerenciamento de configurações”, “item de configuração” e “produto”).

Identificação de riscos (risk identification)

Uma abordagem organizada e abrangente para pesquisar riscos prováveis ou reais ao atendimento dos objetivos.

Implementação (directing implementation)

Uma característica comum de áreas de processos do modelo CMMI com uma representação em estágios, que agrupa 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.

Institucionalização (institutionalization)

A maneira enraizada de fazer negócios que uma organização segue rotineiramente, como parte de sua cultura corporativa.

Instruções de adaptação (tailoring guidelines)

Veja no Capítulo 3 uma explicação de como “instruções de adaptação” é utilizado no CMMI Product Suite.

Item de configuração (configuration item)

Uma agregação de produtos de trabalho que é atribuída para o gerenciamento de configurações e tratada como uma entidade única no processo de gerenciamento de configurações. (Veja “gerenciamento de configurações”).

Item não desenvolvido (non-developmental item)

Um item de fornecimento que foi desenvolvido previamente ao seu uso atual em um processo de aquisição ou desenvolvimento. Tal item pode exigir pequenas modificações para atender os requisitos do seu uso atual pretendido.

Líder da equipe de avaliação (appraisal team leader)

Uma pessoa que lidera as atividades de uma avaliação e que satisfaz os critérios de qualificação com relação à experiência, conhecimento e habilidades definidos pelo método de avaliação.

Glossário 455


Ligações naturais (natural bounds)

O processo inerente refletido por medidas de desempenho do processo, algumas vezes referenciado como “voz do processo”. Técnicas como gráficos de controle, intervalos de confiança e intervalos de previsão são utilizadas para determinar se a variação é devido a causas comuns (isto é, o processo é previsível ou “estável”) ou se é devido a alguma causa especial que pode e deverá ser identificada e removida.

Linha de produtos (product line)

Um grupo de produtos que compartilha um conjunto de características comuns e gerenciadas que satisfazem as necessidades específicas de um mercado ou missão selecionada.

Maturidade organizacional (organizational maturity)

A extensão na qual uma organização tem explícita e consistentemente implantados processos que são documentados, gerenciados, medidos, controlados e continuamente melhorados. A maturidade organizacional pode ser medida através de avaliações.

Medição de processos (process measurement)

O conjunto de definições, métodos e atividades utilizados para fazer medições de um processo e seus produtos resultantes, com o objetivo de caracterizar e entender o processo.

Medida básica (base measure)

Um propriedade ou característica específica de uma entidade e o método utilizado para quantificá-la. (Veja “medidas derivadas”).

Medidas derivadas (derived measures)

Dados resultantes da função matemática de duas ou mais medidas básicas. (Veja “medidas básicas”).

Melhoria de processo (process improvement)

Um programa de atividades projetado para melhorar o desempenho e maturidade dos processos da organização e os resultados de tal programa.

Melhorias de processo e de tecnologia (process and technology improvements)

Na área de processo de Inovação e Desenvolvimento Organizacional, veja a discussão de “melhorias de processo e de tecnologia” nas Notas Introdutórias.

Meta (goal) Veja no Capítulo 3 uma explicação de como “meta” é utilizada no CMMI Product Suite.

Glossário456


Meta específica (specific goal)

Veja no Capítulo 2 uma explicação de como “meta específica” é utilizada no CMMI Product Suite. (Veja “área de processo”, “nível de capacitação”, “meta genérica”, “objetivo quantitativo” e “objetivos de negócios da organização”).

Meta genérica (generic goal)

Veja no Capítulo 2 uma explicação de como “meta genérica” é utilizada no CMMI Product Suite.

Minuta de acordo (memorandum of agreement)

Documentos legais de entendimento ou acordo entre duas ou mais partes. (Também conhecido como “memorando de entendimento”).

Modelo CMMI (CMMI model)

Veja no Capítulo 3 uma explicação de como “modelo CMMI” é utilizado no CMMI Product Suite.

Modelo de ciclo de vida (life-cycle model)

O particionamento da vida de um produto em fases que guiam o projeto a partir da identificação das necessidades do cliente até o descarte do produto.

Modelo de desempenho do processo (process performance model)

Uma descrição dos relacionamentos entre os atributos de um processo e seus produtos de trabalho que é desenvolvida a partir de dados históricos de desempenho de processos e calibrada utilizando medidas de processo e de produto, coletadas no projeto e que são utilizadas para prever os resultados a ser atingidos seguindo-se um processo.

Modelo de maturidade da capacitação (capability maturity model)

Um modelo de maturidade da capacitação (CMM) contém os elementos essenciais dos processos efetivos para uma ou mais disciplinas. Ele também descreve um caminho de melhoria evolutiva, de processos imaturos e empíricos para processos disciplinados e maduros, com a qualidade e eficiência melhoradas.

Modelo de referência (reference model)

Um modelo que é utilizado como benchmark para medir algum atributo.

Modelo de referência da avaliação (appraisal reference model)

Conforme utilizado nos materiais de avaliação do CMMI, o modelo CMMI para o qual uma equipe de avaliação correlaciona as atividades de processos implementadas.

Nível de capacitação (capability level)

A satisfação da melhoria do processo dentro de uma área de processo específica. Um nível de capacitação é definido pelas práticas genéricas e específicas apropriadas para a área de processo. (Veja “nível de maturidade”, “área de processo”, “prática genérica” e “meta genérica”).

Glossário 457


Nível de maturidade (maturity level)

Grau de melhoria de processos em um conjunto pré-definido de áreas de processos, no qual todas as metas dentro do conjunto foram atendidas. (Veja “nível de capacitação” e “área de processo”).

Objetivo (objective) Veja no Capítulo 3 uma explicação de como “objetivo” é utilizado no CMMI Product Suite.

Objetivo quantitativo (quantitative objective)

Valor alvo desejado expressado em medidas quantitativas. (Veja “objetivos de qualidade e desempenho do processo” e “objetivos de melhoria de processos”).

Objetivos de melhoria de processos (process-improvement objectives)

Um conjunto de características alvo estabelecidas para direcionar o esforço para melhorar um processo existente de uma forma específica mensurável, seja em termos de características do produto resultante (por exemplo, qualidade, desempenho, conformidade a padrões, etc.) ou da maneira pela qual o processo é executado (por exemplo, eliminação de etapas redundantes do processo, combinação de etapas do processo, melhoria do tempo do ciclo, etc.). (Veja “objetivo quantitativo” e “objetivos de negócios da organização”).

Objetivos de negócios (business objectives)

(Veja “objetivos de negócios da organização”).

Objetivos de negócios da organização (organization’s business objectives)

Estratégias desenvolvidas pela gerência sênior para assegurar a existência contínua da organização e melhorar sua lucratividade, participação no mercado e outros fatores que influenciam o sucesso da organização. (Veja “objetivo quantitativo” e “objetivos de qualidade e desempenho do processo”).

Tais objetivos podem incluir reduzir o número de solicitações de mudanças durante a fase de integração de um sistema, reduzir o tempo do ciclo de desenvolvimento, aumentar o número de erros encontrados na primeira ou segunda fase de desenvolvimento de um produto, reduzir o número de defeitos relatados pelo cliente, etc., quando aplicados às atividades de engenharia de sistemas.

Glossário458


Objetivos de qualidade e desempenho do processo (quality and process-performance objectives)

Veja no Capítulo 3 uma explicação de como “objetivos de qualidade e desempenho do processo” é utilizado no CMMI Product Suite.

Observação (observation)

Conforme utilizado nos materiais de avaliação do CMMI, um registro escrito que representa o entendimento dos membros da equipe de avaliação das informações vistas ou ouvidas durante as atividades de coleta de dados da avaliação. O registro escrito pode tomar a forma de uma declaração ou formas alternativas, desde que o conteúdo da informação seja preservado.

Organização (organization)

Veja no Capítulo 3 uma explicação de como “organização” é utilizada no CMMI Product Suite.

Outsourcing (Veja “aquisição”).

Pacote de dados técnicos (technical data package)

Uma coleção de itens que podem incluir o seguinte, se tais informações forem apropriadas ao tipo de produto e componente de produto (por exemplo, requisitos de materiais e manufatura podem não ser úteis para componentes de produtos associados a serviços ou processos de software):

Descrição da arquitetura do produto

Requisitos alocados

Descrições de componentes de produtos

Descrições de processos relacionados ao ciclo de vida do produto, se não forem descritos como componentes de produtos separados

Características chave dos produtos

Características físicas exigidas e restrições


Requisitos de materiais (pedidos ou materiais e características de materiais)

Requisitos de fabricação e manufatura (para o fabricante do equipamento original e para o suporte de campo)

Os critérios de verificação utilizados para assegurar que os requisitos sejam atendidos

Condições de utilização (ambientes) e cenários

Glossário 459


operacionais/de utilização, modos e estados de operação, suporte, treinamento, manufatura, descarte e verificações em toda a vida do produto

Justificativa para decisões e características (requisitos, alocações de requisitos, decisões de design)

Pacote de solicitação (solicitation package)

Um documento formal que delineia requisitos técnicos e não-técnicos, que é utilizado para requisitar ofertas em convites para concorrências (concorrências) e requisições de propostas (propostas) ou para requisitar avaliações de capacitação e cotações de preços (cotações). Ele é também utilizado como base para selecionar uma fonte ou fontes de fornecimento para oferecer produtos e serviços.

Padrão (standard) Veja no Capítulo 3 uma explicação de como “padrão” é utilizado no CMMI Product Suite.

Parâmetros de desempenho (performance parameters)

As medidas de eficácia e outras medidas chave utilizadas para guiar e controlar o desenvolvimento progressivo.

Participantes da avaliação (appraisal participants)

Membros da unidade organizacional que participam fornecendo informações durante a avaliação.

Perfil (profile) (Veja “perfil de satisfação” e “perfil alvo”).

Perfil alvo (target profile)

Na representação contínua, uma lista de áreas de processos e seus níveis de capacitação correspondentes que representam um objetivo para a melhoria do processo. (Veja “perfil de nível de capacitação” e “perfil de satisfação”).

Perfil de nível de capacitação (capability level profile)

Na representação contínua, uma lista das áreas de processos e seus níveis de capacitação correspondentes. (Veja “estágios alvo”, “perfil de nível de capacitação”, “perfil de satisfação” e “perfil alvo”). O perfil pode ser um perfil de satisfação quando representar o progresso da organização em cada área de processo, a medida em que esta avança pelos níveis de capacitação. Ou o perfil pode ser um perfil alvo quando ele representa um objetivo de melhoria do processo.

Perfil de satisfação (achievement profile)

Na representação contínua, uma lista de áreas de processos e seus níveis correspondentes de capacitação, que representam o progresso da organização para cada área de processo, enquanto avança pelos níveis de capacitação. (Veja “estágios alvo”, “perfil de nível de capacitação” e “perfil alvo”).

Glossário460


Plano de ação de processos (process action plan)

Na área de processo de Foco no Processo Organizacional, veja a definição de “plano de ação de processo” nas Notas Introdutórias.

Plano de desenvolvimento (developmental plan)

Um plano para direcionamento, implementação e controle do design e desenvolvimento de um ou mais produtos. (Veja “plano do projeto” e “ciclo de vida do produto”).

Plano de melhoria de processos (process-improvement plan)

Na área de processo de Foco no Processo Organizacional, veja a definição de “plano de melhoria de processos” nas Notas Introdutórias.

Plano do projeto (project plan)

Na área de processo de Planejamento do Projeto, veja a definição de “plano do projeto” nas Notas Introdutórias.

Política (policy) (Veja “política organizacional”).

Política organizacional (organizational policy)

Um princípio de direcionamento normalmente estabelecido pela gerência sênior, que é adotado por uma organização para influenciar e determinar decisões.

Ponto forte (strength)

Conforme utilizado nos materiais de avaliação do CMMI, uma implementação exemplar ou digna de nota de uma prática de modelo CMMI.

Ponto fraco (weakness)

Conforme utilizado nos materiais de avaliação do CMMI, a implementação deficiente ou a falta de implementação de uma ou mais práticas do modelo CMMI.

Prática alternativa (alternative practice)

Uma prática que é substituta para uma ou mais práticas genéricas ou específicas contidas nos modelos CMMI, que geram um efeito equivalente em direção à satisfação da meta genérica ou específica associada com práticas do modelo. Práticas alternativas não são necessariamente substituições de um-para-um para as práticas genéricas ou específicas.

Prática específica (specific practice)

Veja no Capítulo 2 uma explicação de como “prática específica” é utilizada no CMMI Product Suite. (Veja “área de processo” e “meta específica”).

Prática genérica (generic practice)

Veja no Capítulo 2 uma explicação de como “prática genérica” é utilizada no CMMI Product Suite.

Práticas avançadas (advanced practices)

Na representação contínua, todas as práticas específicas com um nível de capacitação de dois ou superior.

Glossário 461


Práticas básicas (base practices)

Na representação contínua, todas as práticas específicas com o nível de capacitação 1.

Previsibilidade estatística (statistical predictability)

O desempenho de um processo quantitativo que é controlado utilizando estatísticas e outras técnicas quantitativas.

Procedimento de teste (test procedure)

Instruções detalhadas para a configuração, execução e avaliação de resultados para um dado teste.

Processo (process) Veja no Capítulo 3 uma explicação de como “processo” é utilizado no CMMI Product Suite.

Processo capaz (capable process)

Um processo que pode satisfazer seus objetivos especificados de qualidade do produto, qualidade do serviço e desempenho do processo. (Veja “processo estável”, “processo padrão”, “processo gerenciado estatisticamente”).

Processo definido (defined process)

Veja no Capítulo 3 uma explicação de como “processo definido” é utilizado no CMMI Product Suite.

Processo definido do projeto (project's defined process)

Na área de processo de Gerenciamento Integrado do Projeto, veja a definição de “processo definido do projeto” nas Notas Introdutórias e na prática específica Estabelecer o Processo Definido do Projeto.

Processo estatisticamente gerenciado (statistically managed process)

Um processo que é gerenciado por uma técnica baseada em estatísticas, na qual os processos são analisados, as causas especiais de variação do processo são identificadas e o desempenho é contido dentro de limites bem definidos. (Veja “processo estável”, “processo padrão”, “controle estatístico do processo”, “processo capacitado” e “causa especial de variação do processo”).

Processo estável (stable process)

O estado no qual todas as causas especiais de variação do processo foram removidas e impedidas de ocorrer novamente, de forma que somente as causas comuns de variação do processo se mantêm. (Veja “causa especial de variação do processo”, “causa comum de variação”, “processo padrão”, “processo estatisticamente gerenciado” e “processo capaz”).

Processo executado (performed process)

Um processo que satisfaz o trabalho necessário para produzir uma saída de produtos de trabalho identificados, utilizando produtos de trabalho de entrada identificados (também conhecido como capacitação nível 1). As metas específicas da área de processo são atendidas.

Glossário462


Processo formal de avaliação (formal evaluation process)

Na área de processo de Análises de Decisões e Resoluções, veja a definição de “processo formal de avaliação” nas Notas Introdutórias.

Processo gerenciado (managed process)

Veja no Capítulo 3 uma explicação de como “processo gerenciado” é utilizado no CMMI Product Suite.

Processo incompleto

Um processo que não é executado ou que somente é executado parcialmente (também conhecido como capacitação nível 0). Uma ou mais metas específicas da área de processo não estão sendo satisfeitas.

Processo otimizado (optimizing process)

Um processo quantitativamente gerenciado que foi melhorado com base em um entendimento das causas comuns de variação inerentes ao processo. Um processo que se concentra em uma melhoria continua da sua faixa de desempenho de processo, através de melhorias tanto incrementais quanto inovadoras. (Veja “processo quantitativamente gerenciado”, “processo definido” e “causa comum de variação de processos”).

Processo padrão (standard process)

Uma definição operacional do processo básico que guia o estabelecimento de um processo comum em uma organização. [ISO/IEC 15504-9]

Um processo padrão que descreve os elementos fundamentais do processo que se espera que sejam incorporados em qualquer processo definido. Ele também descreve os relacionamentos (por exemplo, ordem e interfaces) entre estes elementos de processos. (Veja no Capítulo 3 uma explicação de como “processo definido” é utilizado no CMMI Product Suite).

Processo planejado (planned process)

Um processo que é documentado tanto por uma descrição como por um plano. A descrição e o plano deverão ser coordenados e o plano deverá incluir padrões, requisitos, objetivos, recursos, atribuições, etc.

Processo quantitativamente gerenciado (quantitatively managed process)

Um processo definido que é controlado utilizando estatísticas e outras técnicas quantitativas. Os atributos de qualidade do produto, qualidade do serviço e desempenho do processo são mensuráveis e controlados em todo o projeto. (Veja “processo otimizado”, “processo definido” e “processo estatisticamente gerenciado”).

Glossário 463


Processos relacionados com o ciclo de vida do produto (product-related life-cycle processes)

Processos associados com um produto durante uma ou mais fases de sua vida (isto é, da concepção até o descarte), como os processos de manufatura e suporte.

Produto (product) Veja no Capítulo 3 uma explicação de como “produto” é utilizado no CMMI Product Suite.

Produtos de prateleira (COTS)

Itens que podem ser comprados de um fornecedor comercial. (COTS quer dizer “commercial off the shelf” ou produto de prateleira).

Produto de trabalho (work product)

Veja no Capítulo 3 uma explicação de como “produto de trabalho” é utilizado no CMMI Product Suite.

Produto de trabalho típico (typical work product)

Veja no Capítulo 2 uma explicação de como “produto de trabalho típico” é utilizado no CMMI Product Suite.

Programa (program) (1) Um projeto. (2) Uma coleção de projetos relacionados e a infra-estrutura que lhes dá suporte, incluindo objetivos, métodos, atividades, planos e medidas de sucesso. (Veja “projeto”).

Progresso e desempenho do projeto (project progress and performance)

O que um projeto satisfaz com relação a implementação de planos do projeto, incluindo esforço, custo, cronograma e desempenho técnico.

Projeto (project) Veja no Capítulo 3 uma explicação de como “projeto” é utilizado no CMMI Product Suite.

Proprietário do processo (process owner)

A pessoa (ou equipe) responsável por definir e manter um processo. No nível organizacional, o proprietário do processo é a pessoa (ou equipe) responsável pela descrição de um processo padrão; no nível do projeto, o proprietário do processo é a pessoa (ou equipe) responsável pela descrição do processo definido. Um processo pode, portanto, ter diversos proprietários em diferentes níveis de responsabilidade. (Veja “processo padrão” e “processo definido”).

Glossário464


Protótipo (prototype)

Um tipo, forma ou instância preliminar de um produto ou componente de produto que serve como modelo para as etapas posteriores ou para a versão final e completa do produto. Este modelo (físico, eletrônico, digital, analítico, etc.) pode ser utilizado para os seguintes (e outros) objetivos:

Avaliar a possibilidade de se construir o produto utilizando uma tecnologia nova ou desconhecida

Avaliar ou mitigar riscos técnicos

Validar requisitos

Demonstrar características críticas

Qualificar um produto

Qualificar um processo

Caracterizar o desempenho ou recursos do produto

Elucidar princípios físicos

Qualidade (quality) A capacidade de um conjunto de características inerentes de um produto, componente de produto ou processo em atender completamente os requisitos dos clientes.

Rastreabilidade (traceability)

(Veja “rastreabilidade de requisitos”).

Rastreabilidade de requisitos (requirements traceability)

A evidência de uma associação entre um requisito e seu requisito fonte, sua implementação e sua verificação.

Referência (reference)

Veja no Capítulo 2 uma explicação de como “referência” é utilizada no CMMI Product Suite.

Repositório de medições da organização (organization’s measurement repository)

Veja no Capítulo 3 uma explicação de como “repositório de medições da organização” é utilizado no CMMI Product Suite.

Representação (representation)

No Capítulo 1, veja as definições de “representação em estágios” e “representação contínua”.

Glossário 465


Representação contínua (continuous representation)

Uma estrutura de modelo de maturidade de capacitação onde os níveis de capacitação oferecem uma ordem recomendada para a abordagem da melhoria de processos, dentro de cada área de processo específica. (Veja “representação em estágios”, “nível de capacitação” e “área de processo”).

Representação em estágios (staged representation)

Uma estrutura de modelo onde o atendimento de metas de um conjunto de áreas de processos estabelece um nível de maturidade; cada nível constrói uma base para os níveis subseqüentes. (Veja “área de processo” e “nível de maturidade”).

Requisito (requirement)

(1) Uma condição ou capacitação exigida por um usuário para resolver um problema ou atingir um objetivo. (2) Uma condição ou capacitação que deve ser atingida ou possuída por um produto ou componente de produto para satisfazer um contrato, padrão, especificação ou outros documentos formalmente impostos. (3) Uma representação documentada de uma condição ou capacitação conforme em (1) e (2). [IEEE 610.12-1990]

Requisito alocado (allocated requirement)

Requisitos que empregam todo ou parte do desempenho e funcionalidade de um requisito de nível mais alto, em um elemento de arquitetura ou componente de design de nível mais baixo.

Requisitos de acordos/contratos (agreement/contract requirements)

Todos os requisitos técnicos e não-técnicos relacionados a uma aquisição.

Requisitos de componentes de produtos (product-component requirements)

Requisitos de componentes de produtos oferecem uma especificação completa de um componente de produto, incluindo o encaixe, formato, função, desempenho e qualquer outro requisito.

Requisitos derivados (derived requirements)

Requisitos que não estão explicitamente declarados nos requisitos do cliente, mas são inferidos (1) a partir dos requisitos do contexto (por exemplo, padrões aplicáveis, leis, políticas, práticas comuns e decisões de gerenciamento) ou (2) a partir de requisitos necessários para especificar um componente de produto. Requisitos derivados também podem surgir durante a análise e o design de componentes do produto ou sistema. (Veja “requisitos do produto”).

Glossário466


Requisitos do produto (product requirements)

Um refinamento dos requisitos do cliente na linguagem do desenvolvedor, tornando requisitos implícitos em requisitos derivados explícitos. (Veja “requisitos de componentes de produtos” e “requisitos derivados”). O desenvolvedor utiliza os requisitos do produto para guiar o design e construção do produto.

Requisitos não-técnicos (nontechnical requirements)

Provisões contratuais, compromissos, condições e termos que afetam como os produtos ou serviços estão sendo adquiridos. Exemplos incluem produtos a ser entregues, direitos de dados para produtos comerciais de prateleira entregues, item não desenvolvidos (Non-Developmental Item - NDIs), datas de entrega e milestones com critérios de saída. Outros requisitos não-técnicos incluem requisitos de treinamento, requisitos de localização e cronogramas de implantação.

Requisitos técnicos (technical requirements)

Propriedades (atributos) de produtos ou serviços a serem adquiridos ou desenvolvidos.

Retorno do investimento (return on investment)

A razão da receita da saída (produto) com os custos de produção, que determina se uma organização se beneficia da execução de uma ação para produzir algo.

Revisão de design (design review)

Um exame formal, documentado, abrangente e sistemático de um design para avaliar os requisitos de design e a capacidade do design atender estes requisitos e identificar problemas e propor soluções.

Revisão por pares (peer review)

Veja no Capítulo 3 uma explicação de como “revisão por pares” é utilizada no CMMI Product Suite.

Solicitação (solicitation)

O processo de preparar um pacote de solicitação e selecionar um fornecedor (contratado).

Stakeholder Veja no Capítulo 3 uma explicação de como “stakeholder” é utilizado no CMMI Product Suite.

Stakeholder relevante (relevant stakeholder)

Veja no Capítulo 3 uma explicação de como “stakeholder relevante” é utilizado no CMMI Product Suite.

Sub-prática (subpractice)

Veja no Capítulo 2 uma explicação de como “sub-prática”é utilizada no CMMI Product Suite.

Subprocesso (subprocess)

Um processo que é parte de um processo maior. (Veja “descrição do processo”).

Glossário 467


Sustentação (sustainment)

Os processos utilizados para assegurar que um produto pode ser utilizado de forma operacional por seus usuários finais ou clientes. A sustentação assegura que a manutenção é feita de tal forma que o produto está em condições de operação, se o produto estiver em uso ou não pelos clientes ou usuários finais.

Técnicas estatísticas (statistical techniques)

Uma técnica analítica que emprega métodos estatísticos (por exemplo, controle estatístico de processos, intervalos de confiança, intervalos de previsão).

Testes de aceitação (acceptance testing)

Testes formais executados para possibilitar que um usuário, cliente ou outra entidade autorizada determine se aceita um produto ou componente de produto. (Veja “testes de unidade”).

Teste de unidade (unit testing)

Teste de unidades individuais de hardware ou software ou grupos de unidades relacionadas. (Veja “teste de aceitação”).

Treinamento (training)

Na área de processo de Treinamento Organizacional, veja a definição de “treinamento” nas Notas Introdutórias.

Unidade organizacional (organizational unit)

A parte de uma organização que está sujeita a uma avaliação (também conhecida como o escopo organizacional de uma avaliação).

Uma unidade organizacional implanta um ou mais processos que têm um contexto de processo coerente e opera dentro de um conjunto coerente de objetivos de negócios. Uma unidade organizacional é normalmente parte de uma organização maior, embora em uma organização pequena, a unidade organizacional possa ser a organização como um todo.

Validação (validation)

Veja no Capítulo 3 uma explicação de como “validação” é utilizado no CMMI Product Suite.

Verificação (verification)

Veja no Capítulo 3 uma explicação de como “verificação” é utilizado no CMMI Product Suite.

Glossário468


Verificação (verifying implementation)

Uma característica comum das áreas de processos do modelo CMMI com uma representação em estágios, que agrupa as práticas genéricas relacionadas com a revisão pela gerência de mais alto nível e a avaliação objetiva da conformidade às descrições de processos, procedimentos e padrões.

Visão compartilhada (shared vision)

Veja no Capítulo 3 uma explicação de como “visão compartilhada” é utilizada no CMMI Product Suite.

Glossário 469


C. Elementos Exigidos e Esperados do Modelo

Elementos do Modelo Exigidos e Esperados470


NÍVEL DE MATURIDADE: 2



GERENCIAMENTO DE REQUISITOS


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]





O processo é institucionalizado como um processo gerenciado. [CL103.GL101]

Práticas por Meta:



SP 1.1 Obter um Entendimento dos Requisitos

Desenvolver um entendimento com os fornecedores de requisitos sobre o significado dos requisitos. [PA146.IG101.SP101]

SP 1.2 Obter Compromissos com os Requisitos

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

SP 1.3 Gerenciar Mudanças nos Requisitos

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



SP 1.4 Manter a Rastreabilidade Bidirecional dos Requisitos

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

SP 1.5 Identificar Inconsistências entre o Trabalho do Projeto e os Requisitos

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



Compromissos


Estabelecer e manter uma política organizacional para planejar e executar o processo de gerenciamento de requisitos. [GP103]

Habilitações


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


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


Atribuir responsabilidades e autoridade para executar o processo, desenvolver os produtos de trabalho e fornecer os serviços do processo de gerenciamento de requisitos. [GP106]




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

Implementações


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


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


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

Verificações


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]


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



PLANEJAMENTO DO PROJETO


O objetivo do Planejamento do Projeto é estabelecer e manter planos que definem as atividades do projeto. [PA163]



Estimativas de parâmetros de planejamento de projeto são estabelecidas e mantidas. [PA163.IG101]

SG 2 Desenvolver um Plano do Projeto

Um plano de projeto é estabelecido e mantido como a base para o gerenciamento do projeto. [PA163.IG102]





Práticas por Meta:


Estimativas de parâmetros de planejamento de projeto são estabelecidas e mantidas. [PA163.IG101]

SP 1.1 Estimar o Escopo do Projeto

Estabelecer uma estrutura de decomposição de trabalho (WBS) de alto nível para estimar o escopo do projeto. [PA163.IG101.SP101]



SP 1.2 Estabelecer Estimativas de Atributos de Produtos de Trabalho e Tarefas

Estabelecer e manter estimativas dos atributos de produtos de trabalho e tarefas. [PA163.IG101.SP102]

SP 1.3 Definir o Ciclo de Vida do Projeto

Definir as fases do ciclo de vida do projeto sobre as quais é definido o escopo do esforço de planejamento. [PA163.IG101.SP103]

SP 1.4 Determinar Estimativas de Esforço e Custo

Estimar o esforço e custo do projeto para os produtos de trabalho e tarefas baseadas nas justificativas de estimação. [PA163.IG101.SP104]

SG 2 Desenvolver um Plano do Projeto

Um plano de projeto é estabelecido e mantido como a base para o gerenciamento do projeto. [PA163.IG102]

SP 2.1 Estabelecer o Orçamento e o Cronograma

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

SP 2.2 Identificar os Riscos do Projeto

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

SP 2.3 Planejar o Gerenciamento de Dados

Planejar o gerenciamento dos dados do projeto. [PA163.IG102.SP102]

SP 2.4 Planejar os Recursos do Projeto

Planejar os recursos necessários para executar o projeto. [PA163.IG102.SP104]

SP 2.5 Planejar os Conhecimentos e Habilidades Necessários

Planejar os conhecimentos e habilidades necessários para executar o projeto. [PA163.IG102.SP105]



SP 2.6 Planejar o Envolvimento dos Stakeholders

Planejar o envolvimento dos stakeholders identificados. [PA163.IG102.SP106]

SP 2.7 Estabelecer o Plano do Projeto

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



SP 3.1 Revisar Planos que Afetam o Projeto

Revisar todos os planos que afetam o projeto para atender os compromissos do projeto. [PA163.IG103.SP103]

SP 3.2 Equilibrar Níveis de Trabalho e Recursos

Equilibrar o plano do projeto para refletir os recursos disponíveis e estimados. [PA163.IG103.SP101]

SP 3.3 Obter Compromissos com o Plano

Obter compromissos dos stakeholders relevantes responsáveis pela execução e suporte do plano de execução. [PA163.IG103.SP102]



Compromissos


Estabelecer e manter uma política organizacional para planejar e executar o processo de planejamento do projeto. [GP103]



Habilitações


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


Fornecer os recursos adequados para executar o processo de planejamento do projeto, desenvolver os produtos de trabalho e fornecer os serviços do processo. [GP105]


Atribuir responsabilidades e autoridade para executar o processo, desenvolver os produtos de trabalho e fornecer os serviços do processo de planejamento do projeto. [GP106]


Treinar as pessoas para executar ou suportar o processo de planejamento do projeto, conforme necessário. [GP107]

Implementações


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


Identificar e envolver os stakeholders relevantes do processo de planejamento do projeto, conforme planejado. [GP124]


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]



Verificações


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]


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]



MONITORAMENTO E CONTROLE DO PROJETO


O objetivo do Monitoramento e Controle do Projeto é fornecer um entendimento do progresso do projeto de forma que as ações corretivas apropriadas possam ser tomadas quando o desempenho do projeto se desviar significativamente do plano. [PA162]



O desempenho e o progresso reais do projeto são monitorados contra o plano do projeto. [PA162.IG101]


As ações corretivas são gerenciadas até o encerrado quando o desempenho ou os resultados do projeto se desviam significativamente do plano. [PA162.IG102]



Práticas por Meta:


O desempenho e o progresso reais 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]

SP 1.2 Monitorar os Compromissos

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



SP 1.3 Monitorar os Riscos do Projeto

Monitorar os riscos contra os que foram identificados no plano do projeto. [PA162.IG101.SP103]

SP 1.4 Monitorar os Gerenciamento de Dados

Monitorar o gerenciamento dos dados do projeto contra o plano do projeto. [PA162.IG101.SP106]

SP 1.5 Monitorar o Envolvimento dos Stakeholders

Monitorar o envolvimento dos stakeholders contra o plano do projeto. [PA162.IG101.SP107]

SP 1.6 Conduzir Revisões de Progresso

Periodicamente revisar o progresso, desempenho e questões do projeto. [PA162.IG101.SP104]

SP 1.7 Conduzir Revisões de Milestones

Revisar os cumprimentos e resultados do projeto em milestones selecionados do projeto. [PA162.IG101.SP105]


As ações corretivas são gerenciadas até o encerrado quando o desempenho ou os resultados do projeto se desviam significativamente do plano. [PA162.IG102]

SP 2.1 Analisar Questões

Coletar e analisar as questões e determinar as ações corretivas necessárias para tratar as questões. [PA162.IG102.SP101]

SP 2.2 Tomar Ações Corretivas

Tomar ações corretivas em questões identificadas. [PA162.IG102.SP102]

SP 2.3 Gerenciar Ações Corretivas

Gerenciar as ações corretivas até o encerramento. [PA162.IG102.SP103]





Compromissos


Estabelecer e manter uma política organizacional para planejar e executar o processo de monitoramento e controle do projeto. [GP103]

Habilitações


Estabelecer e manter o plano para execução do processo de monitoramento e controle do projeto. [GP104]


Fornecer os recursos adequados para executar o processo de monitoramento e controle do projeto, desenvolver os produtos de trabalho e fornecer os serviços do processo. [GP105]


Atribuir responsabilidades e autoridade para executar o processo, desenvolver os produtos de trabalho e fornecer os serviços do processo de monitoramento e controle do projeto. [GP106]


Treinar as pessoas para executar ou suportar o processo de monitoramento e controle do projeto, conforme necessário. [GP107]



Implementaçõ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]


Identificar e envolver os stakeholders relevantes do processo de monitoramento e controle do projeto, conforme planejado. [GP124]


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

Verificações


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


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]



GERENCIAMENTO DE ACORDOS COM FORNECEDORES


O objetivo do Gerenciamento de Acordos com Fornecedores é gerenciar a aquisição de produtos de fornecedores para os quais exista um acordo formal. [PA166]




SG 2 Satisfazer Acordos com Fornecedores

Acordos com fornecedores são satisfeitos pelo projeto e pelo fornecedor. [PA166.IG102]



Práticas por Meta:



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]

SP 1.2 Selecionar Fornecedores

Selecionar fornecedores com base em uma avaliação de sua capacidade em atender os requisitos especificados e os critérios estabelecidos. [PA166.IG101.SP102]

SP 1.3 Estabelecer Acordos com Fornecedores

Estabelecer e manter acordos formais com fornecedores. [PA166.IG101.SP103]



SG 2 Satisfazer Acordos com Fornecedores

Acordos com fornecedores são satisfeitos pelo projeto e pelo fornecedor. [PA166.IG102]

SP 2.1 Revisar Produtos de Prateleira

Revisar os produtos de prateleira candidatos para assegurar que eles satisfazem os requisitos especificados que são cobertos por um acordo com fornecedores. [PA166.IG102.SP101]

SP 2.2 Executar o Acordo com o Fornecedor

Executar atividades com o fornecedor conforme especificado no acordo com o fornecedor. [PA166.IG102.SP102]

SP 2.3 Aceitar o Produto Adquirido

Assegurar que o acordo com o fornecedor seja satisfeito antes de aceitar o produto adquirido. [PA166.IG102.SP103]

SP 2.4 Fazer a Transição de Produtos

Fazer a transição dos produtos adquiridos do fornecedor para o projeto. [PA166.IG102.SP104]



Compromissos


Estabelecer e manter uma política organizacional para planejar e executar o processo de gerenciamento de acordos com fornecedores. [GP103]



Habilitações


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


Fornecer os recursos adequados para executar o processo de gerenciamento de acordos com fornecedores, desenvolver os produtos de trabalho e fornecer os serviços do processo. [GP105]


Atribuir responsabilidades e autoridade para executar o processo, desenvolver os produtos de trabalho e fornecer os serviços do processo de gerenciamento de acordos com fornecedores. [GP106]


Treinar as pessoas para executar ou suportar o processo de gerenciamento de acordos com fornecedores, conforme necessário. [GP107]

Implementaçõ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]


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




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

Verificações


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]


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]



MEDIÇÕES E ANÁLISES


O objetivo das Medições e Análises é desenvolver e sustentar uma capacitação de medições que é utilizada para suportar as necessidades de informações do gerenciamento. [PA154]


SG 1 Alinhar as Atividades de Medições e Análises

Objetivos e atividades de medições são alinhados com as necessidades de informações e objetivos identificados. [PA154.IG101]


Resultados de medições que tratam as necessidades de informações e objetivos identificados são fornecidos. [PA154.IG102]



Práticas por Meta:

SG 1 Alinhar as Atividades de Medições e Análises

Objetivos e atividades de medições são alinhados com as necessidades de informações e objetivos identificados. [PA154.IG101]

SP 1.1 Estabelecer Objetivos de Medições

Estabelecer e manter objetivos de medições que são derivados das necessidades de informações e objetivos identificados. [PA154.IG101.SP101]

SP 1.2 Especificar Medidas

Especificar medidas para tratar os objetivos de medições. [PA154.IG101.SP102]



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]

SP 1.4 Especificar Procedimentos de Análises

Especificar como os dados de medições serão analisados e relatados. [PA154.IG101.SP104]


Resultados de medições que tratam as necessidades de informações e objetivos identificados são fornecidos. [PA154.IG102]

SP 2.1 Coletar Dados de Medições

Obter os dados de medições especificados. [PA154.IG102.SP101]

SP 2.2 Analisar Dados de Medições

Analisar e interpretar dados de medições. [PA154.IG102.SP102]

SP 2.3 Armazenar Dados e Resultados

Gerenciar e armazenar dados de medições, especificações de medições e resultados de análises. [PA154.IG102.SP103]

SP 2.4 Comunicar Resultados

Relatar resultados de atividades de medições e análises de todos os stakeholders relevantes. [PA154.IG102.SP104]



Compromissos


Estabelecer e manter uma política organizacional para planejar e executar o processo de medições e análises. [GP103]



Habilitações


Estabelecer e manter o plano para execução do processo de medições e análises. [GP104]


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


Atribuir responsabilidades e autoridade para executar o processo, desenvolver os produtos de trabalho e fornecer os serviços do processo de medições e análises. [GP106]


Treinar as pessoas para executar ou suportar o processo de medições e análises, conforme necessário. [GP107]

Implementaçõ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]


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


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



Verificações


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


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]



GARANTIA DA QUALIDADE DO PROCESSO E DO PRODUTO


O objetivo da Garantia da Qualidade do Processo e do Produto é fornecer à equipe e ao gerenciamento uma visão objetiva dos processos e produtos de trabalho associados. [PA145]


SG 1 Avaliar Objetivamente Processos e Produtos de Trabalho

A aderência do processo executado e dos produtos de trabalho e serviços associados às descrições, padrões e procedimentos dos processos aplicáveis é avaliada de forma objetiva. [PA145.IG101]

SG 2 Fornecer Visão Objetiva

As questões de não conformidades são rastreadas e comunicadas objetivamente e a resolução é assegurada. [PA145.IG102]



Práticas por Meta:

SG 1 Avaliar Objetivamente Processos e Produtos de Trabalho

A aderência do processo executado e dos produtos de trabalho e serviços associados às descrições, padrões e procedimentos dos processos aplicáveis é avaliada de forma objetiva. [PA145.IG101]

SP 1.1 Avaliar Objetivamente os Processos

Avaliar objetivamente os processos executados determinados contra as descrições, padrões e procedimentos de processos aplicáveis. [PA145.IG101.SP101]

SP 1.2 Avaliar Objetivamente os Produtos de Trabalho e Serviços

Avaliar objetivamente os produtos de trabalho e serviços determinados contra as descrições, padrões e procedimentos de processos aplicáveis. [PA145.IG101.SP102]



SG 2 Fornecer Visão Objetiva

As questões de não conformidades são rastreadas e comunicadas objetivamente e a resolução é assegurada. [PA145.IG102]

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 conformidade com a equipe e os gerentes. [PA145.IG102.SP101]


Estabelecer e manter registros das atividades de garantia da qualidade. [PA145.IG102.SP102]



Compromissos


Estabelecer e manter uma política organizacional para planejar e executar o processo de garantia da qualidade do processo e do produto. [GP103]

Habilitações


Estabelecer e manter o plano para execução do processo de garantia da qualidade do processo e do produto. [GP104]


Fornecer os recursos adequados para executar o processo de garantia da qualidade do processo e do produto, desenvolver os produtos de trabalho e fornecer os serviços do processo. [GP105]




Atribuir responsabilidades e autoridade para executar, desenvolver os produtos de trabalho e fornecer os serviços do processo de garantia da qualidade do processo e do produto. [GP106]


Treinar as pessoas para executar ou suportar o processo de garantia da qualidade do processo e do produto, conforme necessário. [GP107]

Implementaçõ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]


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


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]

Verificações


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




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]



GERENCIAMENTO DE CONFIGURAÇÕES


O objetivo do Gerenciamento de Configurações é estabelecer e manter a integridade dos produtos de trabalho utilizando identificação de configurações, controle de configurações, informações do status de configurações e auditorias de configurações. [PA159]



As baselines dos produtos de trabalho identificados são estabelecidas. [PA159.IG101]


Mudanças nos produtos de trabalho sob gerenciamento de configurações são rastreadas e controladas. [PA159.IG102]





Práticas por Meta:


As baselines dos produtos de trabalho identificados são estabelecidas. [PA159.IG101]

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 gerenciamento de configurações. [PA159.IG101.SP101]



SP 1.2 Estabelecer um Sistema de Gerenciamento de Configurações

Estabelecer e manter um sistema de gerenciamento de configurações e de gerenciamento de mudanças nos produtos de trabalho controlados. [PA159.IG101.SP102]

SP 1.3 Criar ou Liberar Baselines

Criar ou liberar baselines para uso interno ou para entrega para o cliente. [PA159.IG101.SP103]


Mudanças nos produtos de trabalho sob gerenciamento de configurações são rastreadas e controladas. [PA159.IG102]

SP 2.1 Rastrear Solicitações de Mudanças

Rastrear solicitações de mudanças para os itens de configurações. [PA159.IG102.SP101]

SP 2.2 Controlar Itens de Configurações

Controlar mudanças aos itens de configurações. [PA159.IG102.SP102]



SP 3.1 Estabelecer Registros de Gerenciamento de Configurações

Estabelecer e manter registros descrevendo os itens de configurações. [PA159.IG103.SP101]

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]





Compromissos


Estabelecer e manter uma política organizacional para planejar e executar o processo de gerenciamento de configurações. [GP103]

Habilitações


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


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


Atribuir responsabilidades e autoridade para executar o processo, desenvolver os produtos de trabalho e fornecer os serviços do processo de gerenciamento de configurações. [GP106]


Treinar as pessoas para executar ou suportar o processo de gerenciamento de configurações, conforme necessário. [GP107]

Implementaçõ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]




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


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

Verificações


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]


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]





NÍVEL DE MATURIDADE: 3

Nível de Maturidade: 3 501


DESENVOLVIMENTO DE REQUISITOS


O objetivo do Desenvolvimento de Requisitos é produzir e analisar requisitos de clientes, produtos e componentes de produtos. [PA157]





Requisitos de clientes são refinados e elaborados para desenvolver os requisitos de produtos e de componentes de produtos. [PA157.IG103]

SG 3 Analisar e Validar Requisitos

Os requisitos são analisados e validados e uma definição da funcionalidade exigida é desenvolvida. [PA157.IG102]


O processo é institucionalizado como um processo definido. [CL104.GL101]

Práticas por Meta:



SP 1.1 Elicitar Necessidades

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

Nível de Maturidade: 3, Desenvolvimento de Requisitos502


A seguinte prática específica aparece na representação contínua como SP 1.1-1, mas está incluída na Representação em Estágios como SP 1.1, Elicitar Necessidades. A prática específica é apresentada aqui em cinza apenas como material informativo.

SP 1.1-1 Coletar Necessidades dos Stakeholders

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

SP 1.2 Desenvolver os Requisitos do Cliente

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


Requisitos de clientes são refinados e elaborados para desenvolver os requisitos de produtos e de componentes de produtos. [PA157.IG103]

SP 2.1 Estabelecer os Requisitos do Produto e dos Componentes do Produto

Estabelecer e manter os requisitos do produto e do componentes do produto, que são baseados nos requisitos dos clientes. [PA157.IG103.SP101]

SP 2.2 Alocar Requisitos de Componentes do Produto

Alocar os requisitos para cada componente do produto. [PA157.IG103.SP102]

SP 2.3 Identificar Requisitos de Interfaces

Identificar requisitos de interfaces. [PA157.IG103.SP103]

SG 3 Analisar e Validar Requisitos

Os requisitos são analisados e validados e uma definição da funcionalidade exigida é desenvolvida. [PA157.IG102]



SP 3.1 Estabelecer Conceitos Operacionais e Cenários

Estabelecer e manter conceitos operacionais e cenários associados. [PA157.IG102.SP101]

SP 3.2 Estabelecer uma Definição da Funcionalidade Exigida

Estabelecer e manter uma definição da funcionalidade exigida. [PA157.IG102.SP102]

SP 3.3 Analisar os Requisitos

Analisar requisitos para assegurar que eles são necessários e suficientes. [PA157.IG102.SP103]

SP 3.4 Analisar Requisitos para Atingir o Equilíbrio

Analisar requisitos para equilibrar necessidades e restrições dos stakeholders. [PA157.IG102.SP104]

SP 3.5 Validar Requisitos com Métodos Abrangentes

Validar requisitos para assegurar que o produto resultante será executado conforme pretendido no ambiente do usuário utilizando diversas técnicas, conforme apropriado. [PA157.IG102.SP106]

A seguinte prática específica aparece na representação contínua como SP 3.5-1, mas está incluída na Representação em Estágios como SP 3.5, Validar Requisitos com Métodos Abrangentes. A prática específica é apresentada aqui em cinza somente como material informativo.

SP 3.5-1 Validar Requisitos

Validar requisitos para assegurar que o produto resultante será executado apropriadamente no seu ambiente de uso pretendido. [PA157.IG102.SP105]





Compromissos


Estabelecer e manter uma política organizacional para planejar e executar o processo de desenvolvimento de requisitos. [GP103]

Habilitações


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


Estabelecer e manter o plano para execução do processo de desenvolvimento de requisitos. [GP104]


Fornecer os recursos adequados para executar o processo de desenvolvimento de requisitos, desenvolver os produtos de trabalho e fornecer os serviços do processo. [GP105]


Atribuir responsabilidades e autoridade para executar o processo, desenvolver os produtos de trabalho e fornecer os serviços do processo de desenvolvimento de requisitos. [GP106]


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



Implementações


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


Identificar e envolver os stakeholders relevantes do processo de desenvolvimento de requisitos, conforme planejado. [GP124]


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


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 dar suporte à futura utilização e melhoria dos processos e ativos de processos da organização. [GP117]

Verificações


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


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



SOLUÇÕES TÉCNICAS


O objetivo das Soluções Técnicas é fazer o design, desenvolver e implementar soluções para os requisitos. Soluções, designs e implementações envolvem produtos, componentes de produtos e processos do ciclo de vida relacionado ao produto isoladamente ou em combinações, conforme apropriado. [PA160]


SG 1 Selecionar Soluções de Componentes de Produtos



Os designs de produtos ou componentes de produtos são desenvolvidos. [PA160.IG102]





Práticas por Meta:

SG 1 Selecionar Soluções de Componentes de Produtos


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]



A seguinte prática específica aparece na representação contínua como SP 1.1-1, mas está incluída na Representação em Estágios como SP 1.1, Desenvolver Soluções Alternativas e Critérios de Seleção. A prática específica é apresentada aqui em cinza somente como material informativo.

SP 1.1-1 Desenvolver Soluções Alternativas e Critérios de Seleção

Desenvolver soluções alternativas e critérios de seleção. [PA160.IG101.SP101]

SP 1.2 Evoluir os Conceitos Operacionais e Cenários

Evoluir o conceito operacional, cenários e ambientes para descrever as condições, modos de operação e estados operacionais específicos para cada componente de produto. [PA160.IG101.SP103]

SP 1.3 Selecionar Soluções de Componentes de Produtos

Selecionar as soluções de componentes de produtos que melhor satisfazem os critérios estabelecidos. [PA160.IG101.SP104]


Os designs de produtos ou componentes de produtos são desenvolvidos. [PA160.IG102]

SP 2.1 Criar o Design do Produto e dos Componentes do Produto

Desenvolver um design para o produto ou componente de produto. [PA160.IG102.SP101]

SP 2.2 Estabelecer um Pacote de Dados Técnicos

Estabelecer e manter um pacote de dados técnicos. [PA160.IG102.SP103]

SP 2.3 Criar Designs de Interfaces Utilizando Critérios

Criar designs abrangentes de interfaces de componentes de produtos em termos dos critérios estabelecidos e mantidos. [PA160.IG102.SP105]

Nível de Maturidade: 3, Soluções Técnicas508


A seguinte prática específica aparece na representação contínua como SP 2.3-1, mas está incluída na Representação em Estágios como SP 2.3, Criar o Design de Interfaces Utilizando Critérios. A prática específica é apresentada aqui em cinza somente como material informativo.

SP 2.3-1 Estabelecer Descrições de Interfaces

Estabelecer e manter a solução para interfaces de componentes de produtos. [PA160.IG102.SP104]

SP 2.4 Executar Análises de Fabricação, Compra ou Reutilização

Avaliar se os componentes do produto deverão ser desenvolvidos, comprados ou reutilizados com base nos critérios estabelecidos. [PA160.IG102.SP106]



SP 3.1 Implementar o Design

Implementar os designs dos componentes de produtos. [PA160.IG103.SP101]

SP 3.2 Desenvolver a Documentação de Suporte ao Produto

Desenvolver e manter a documentação do usuário final. [PA160.IG103.SP102]



Compromissos


Estabelecer e manter uma política organizacional para planejar e executar o processo de soluções técnicas. [GP103]



Habilitações


Estabelecer e manter a descrição de um processo definido de soluções técnicas. [GP114]


Estabelecer e manter o plano para execução do processo de soluções técnicas. [GP104]


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


Atribuir responsabilidades e autoridade para executar o processo, desenvolver os produtos de trabalho e fornecer os serviços do processo de soluções técnicas. [GP106]


Treinar as pessoas para executar ou suportar o processo de soluções técnicas, conforme necessário. [GP107]

Implementações


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


Identificar e envolver os stakeholders relevantes do processo de soluções técnicas, conforme planejado. [GP124]

Nível de Maturidade: 3, Soluções Técnicas510



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


Coletar produtos de trabalho, medidas, resultados de medições e informações de melhorias derivados do planejamento e execução do processo de soluções técnicas para dar suporte à futura utilização e melhoria dos processos e ativos de processos da organização. [GP117]

Verificações


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


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



INTEGRAÇÃO DE PRODUTOS


O objetivo da Integração de Produtos é montar o produto a partir dos componentes do produto, garantindo que o produto, quando integrado, funciona apropriadamente e entregar o produto. [PA147]


SG 1 Preparar para a Integração de Produtos

A preparação para a integração de produtos é conduzida. [PA147.IG101]

SG 2 Assegurar a Compatibilidade das Interfaces

As interfaces dos componentes do produto, tanto internas como externas, são compatíveis. [PA147.IG102]


Os componentes de produtos verificados são montados e o produto integrado, verificado e validado é entregue. [PA147.IG103]



Práticas por Meta:

SG 1 Preparar para a Integração de Produtos

A preparação para a integração de produtos é conduzida. [PA147.IG101]

SP 1.1 Determinar a Seqüência de Integração

Determinar a seqüência de integração dos componentes do produto. [PA147.IG101.SP101]

SP 1.2 Estabelecer o Ambiente da Integração de Produtos

Estabelecer e manter o ambiente necessário para suportar a integração dos componentes de produtos. [PA147.IG101.SP102]

Nível de Maturidade: 3, Integração do Produto512


SP 1.3 Estabelecer os Procedimentos e Critérios para a Integração de Produtos

Estabelecer e manter os procedimentos e critérios para a integração dos componentes de produtos. [PA147.IG101.SP103]

SG 2 Assegurar a Compatibilidade das Interfaces

As interfaces dos componentes do produto, tanto internas como externas, são compatíveis. [PA147.IG102]

SP 2.1 Revisar as Descrições de Interfaces com Relação à Completitude

Revisar as descrições de interfaces com relação à cobertura e completitude. [PA147.IG102.SP101]

SP 2.2 Gerenciar Interfaces

Gerenciar as descrições, designs e mudanças nas interfaces internas e externas para produtos e componentes de produtos. [PA147.IG102.SP102]


Os componentes de produtos verificados são montados e o produto integrado, verificado e validado é entregue. [PA147.IG103]

SP 3.1 Confirmar que os Componentes do Produto estão Prontos para a Integração

Confirmar, antes da montagem, que cada componente do produto exigido para a montagem do produto foi apropriadamente identificado, funciona de acordo com sua descrição e que as interfaces dos componentes do produto estão em conformidade com as descrições de interfaces. [PA147.IG103.SP101]

SP 3.2 Montar os Componentes de Produtos

Montar os componentes de produtos de acordo com a seqüência de integração de produtos e os procedimentos disponíveis. [PA147.IG103.SP102]

Nível de Maturidade: 3, Integração do Produto 513


SP 3.3 Avaliar os Componentes de Produtos Montados

Avaliar os componentes de produtos montados com relação à compatibilidade da interface. [PA147.IG103.SP103]

SP 3.4 Empacotar e Entregar o Produto ou o Componente do Produto

Empacotar o produto ou componente de produto montado e entregá-lo ao cliente apropriado. [PA147.IG103.SP104]



Compromissos


Estabelecer e manter uma política organizacional para planejar e executar o processo de integração de produtos. [GP103]

Habilitações


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


Estabelecer e manter o plano para execução do processo de integração de produtos. [GP104]


Fornecer os recursos adequados para executar o processo de integração de produtos, desenvolver os produtos de trabalho e fornecer os serviços do processo. [GP105]




Atribuir responsabilidades e autoridade para executar o processo, desenvolver os produtos de trabalho e fornecer os serviços do processo de integração de produtos. [GP106]


Treinar as pessoas para executar ou suportar o processo de integração de produtos, conforme necessário. [GP107]

Implementações


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


Identificar e envolver os stakeholders relevantes do processo de integração de produtos, conforme planejado. [GP124]


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


Coletar produtos de trabalho, medidas, resultados de medições e informações de melhorias derivados do planejamento e execução do processo de integração de produtos para dar suporte à futura utilização e melhoria dos processos e ativos de processos da organização. [GP117]

Nível de Maturidade: 3, Integração do Produto 515


Verificações


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


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



VERIFICAÇÃO


O objetivo da Verificação é assegurar que os produtos de trabalho selecionados atenderão seus requisitos. [PA150]





Revisões por pares são executadas nos produtos de trabalho selecionados. [PA150.IG102]


Produtos de trabalho selecionados são verificados contra seus requisitos especificados. [PA150.IG103]



Práticas por Meta:



SP 1.1 Selecionar Produtos de Trabalho para Verificação

Selecionar os produtos de trabalho a serem verificados e os métodos de verificação que serão utilizados para cada um deles. [PA150.IG101.SP101]

SP 1.2 Estabelecer o Ambiente de Verificação

Estabelecer e manter o ambiente necessário para suportar a verificação. [PA150.IG101.SP102]



SP 1.3 Estabelecer os Procedimentos e Critérios de Verificação

Estabelecer e manter procedimentos e critérios de verificação para os produtos de trabalho selecionados. [PA150.IG101.SP103]


Revisões por pares são executadas nos produtos de trabalho selecionados. [PA150.IG102]

SP 2.1 Preparar para as Revisões por Pares

Preparar para as revisões por pares dos produtos de trabalho selecionados. [PA150.IG102.SP101]

SP 2.2 Conduzir Revisões por Pares

Conduzir revisões por pares nos produtos de trabalho selecionados e identificar questões resultantes da revisão por pares. [PA150.IG102.SP102]

SP 2.3 Analisar os Dados de Revisões por Pares

Analisar dados sobre a preparação, condução e resultados das revisões por pares. [PA150.IG102.SP103]


Produtos de trabalho selecionados são verificados contra seus requisitos especificados. [PA150.IG103]

SP 3.1 Executar a Verificação

Executar a verificação nos produtos de trabalho selecionados. [PA150.IG103.SP101]

SP 3.2 Analisar os Resultados da Verificação e Identificar as Ações Corretivas

Analisar os resultados de todas as atividades de verificação e identificar as ações corretivas. [PA150.IG103.SP102]





Compromissos


Estabelecer e manter uma política organizacional para planejar e executar o processo de verificação. [GP103]

Habilitações


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


Estabelecer e manter o plano para execução do processo de verificação. [GP104]


Fornecer os recursos adequados para executar o processo de verificação, desenvolver os produtos de trabalho e fornecer os serviços do processo. [GP105]


Atribuir responsabilidades e autoridade para executar o processo, desenvolver os produtos de trabalho e fornecer os serviços do processo de verificação. [GP106]


Treinar as pessoas para executar ou suportar o processo de verificação, conforme necessário. [GP107]



Implementações


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


Identificar e envolver os stakeholders relevantes do processo de verificação, conforme planejado. [GP124]


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


Coletar produtos de trabalho, medidas, resultados de medições e informações de melhorias derivados do planejamento e execução do processo de verificação para dar suporte à futura utilização e melhoria dos processos e ativos de processos da organização. [GP117]

Verificações


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


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



VALIDAÇÃO


O objetivo da Validação é demonstrar que um produto ou componente de produto atende plenamente seu uso pretendido quando colocado no seu ambiente pretendido. [PA149]








Práticas por Meta:



SP 1.1 Selecionar Produtos para Validação

Selecionar produtos e componentes de produtos a serem validados e os métodos de validação que serão utilizados para cada um deles. [PA149.IG101.SP101]

SP 1.2 Estabelecer o Ambiente de Validação

Estabelecer e manter o ambiente necessário para suportar a validação. [PA149.IG101.SP102]

SP 1.3 Estabelecer Procedimentos e Critérios de Validação

Estabelecer e manter procedimentos e critérios para validação. [PA149.IG101.SP103]





SP 2.1 Executar a Validação

Executar a validação dos produtos e componentes de produtos selecionados. [PA149.IG102.SP101]

SP 2.2 Analisar os Resultados da Validação

Analisar os resultados das atividades de validação e identificar questões. [PA149.IG102.SP102]



Compromissos


Estabelecer e manter uma política organizacional para planejar e executar o processo de validação. [GP103]

Habilitações


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


Estabelecer e manter o plano para execução do processo de validação. [GP104]




Fornecer os recursos adequados para executar o processo de validação, desenvolver os produtos de trabalho e fornecer os serviços do processo. [GP105]


Atribuir responsabilidades e autoridade para executar o processo, desenvolver os produtos de trabalho e fornecer os serviços do processo de validação. [GP106]


Treinar as pessoas para executar ou suportar o processo de validação, conforme necessário. [GP107]

Implementações


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


Identificar e envolver os stakeholders relevantes do processo de validação, conforme planejado. [GP124]


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


Coletar produtos de trabalho, medidas, resultados de medições e informações de melhorias derivados do planejamento e execução do processo de validação para dar suporte à futura utilização e melhoria dos processos e ativos de processos da organização. [GP117]



Verificações


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


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



FOCO NO PROCESSO ORGANIZACIONAL


O objetivo do Foco no Processo Organizacional é planejar e implementar a melhoria do processo organizacional baseada em um entendimento abrangente dos pontos fracos e fortes atuais dos processos e ativos de processos da organização. [PA152]



Pontos fortes e fracos e oportunidades de melhorias para os processos da organização são identificados periodicamente e tratados conforme necessário. [PA152.IG101]





Práticas por Meta:


Pontos fortes e fracos e oportunidades de melhorias para os processos da organização são identificados periodicamente e tratados conforme necessário. [PA152.IG101]

SP 1.1 Estabelecer Necessidades de Processos Organizacionais

Estabelecer e manter a descrição das necessidades e objetivos do processo para a organização. [PA152.IG101.SP101]

SP 1.2 Avaliar os Processos Organizacionais

Avaliar os processos da organização periodicamente e conforme necessário para manter um conhecimento de seus pontos fortes e fracos. [PA152.IG101.SP102]



SP 1.3 Identificar as Melhorias de Processos da Organização

Identificar melhorias para os processos e ativos de processos da organização. [PA152.IG101.SP103]



SP 2.1 Estabelecer Planos de Ações de Processos

Estabelecer e manter planos de ações de processos para tratar melhorias aos processos e ativos de processos da organização. [PA152.IG102.SP101]

SP 2.2 Implementar Planos de Ações de Processos

Implementar planos de ações de processos em toda a organização. [PA152.IG102.SP102]

SP 2.3 Implantar Ativos de Processos Organizacionais

Implantar ativos de processos organizacionais em toda a organização. [PA152.IG102.SP103]

SP 2.4 Incorporar Experiências Relacionadas a Processos nos Ativos de Processos Organizacionais

Incorporar produtos de trabalho relacionados ao processo, medidas e informações de melhorias derivadas do planejamento e execução do processo nos ativos de processos organizacionais. [PA152.IG102.SP104]





Compromissos


Estabelecer e manter uma política organizacional para planejar e executar o processo de foco no processo organizacional. [GP103]

Habilitações


Estabelecer e manter a descrição de um processo definido de foco no processo organizacional. [GP114]


Estabelecer e manter o plano para execução do processo de foco no processo organizacional. [GP104]


Fornecer os recursos adequados para executar o processo de foco no processo organizacional, desenvolver os produtos de trabalho e fornecer os serviços do processo. [GP105]


Atribuir responsabilidades e autoridade para executar o processo, desenvolver os produtos de trabalho e fornecer os serviços do processo de foco no processo organizacional. [GP106]


Treinar as pessoas para executar ou suportar o processo de foco no processo organizacional, conforme necessário. [GP107]



Implementações


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


Identificar e envolver os stakeholders relevantes do processo de foco no processo organizacional, conforme planejado. [GP124]


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


Coletar produtos de trabalho, medidas, resultados de medições e informações de melhorias derivados do planejamento e execução do processo de foco no processo organizacional para dar suporte à futura utilização e melhoria dos processos e ativos de processos da organização. [GP117]

Verificações


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


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



DEFINIÇÃO DO PROCESSO ORGANIZACIONAL


O objetivo da Definição do Processo Organizacional é estabelecer e manter um conjunto utilizável de ativos de processos organizacionais. [PA153]






Práticas por Meta:



SP 1.1 Estabelecer Processos Padrão

Estabelecer e manter o conjunto de processos padrão da organização. [PA153.IG101.SP101]

SP 1.2 Estabelecer Descrições de Modelos de Ciclo de Vida

Estabelecer e manter descrições de modelos de ciclo de vida aprovadas para uso na organização. [PA153.IG101.SP102]

SP 1.3 Estabelecer Critérios e Instruções de Adaptação

Estabelecer e manter os critérios e instruções de adaptação para o conjunto de processos padrão da organização. [PA153.IG101.SP103]



SP 1.4 Estabelecer o Repositório de Medições da Organização

Estabelecer e manter o repositório de medições da organização. [PA153.IG101.SP104]

SP 1.5 Estabelecer a Biblioteca de Ativos de Processos da Organização

Estabelecer e manter a biblioteca de ativos de processos da organização. [PA153.IG101.SP105]



Compromissos


Estabelecer e manter uma política organizacional para planejar e executar o processo de definição do processo organizacional. [GP103]

Habilitações


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


Estabelecer e manter o plano para execução do processo de definição do processo organizacional. [GP104]


Fornecer os recursos adequados para executar o processo de definição do processo organizacional, desenvolver os produtos de trabalho e fornecer os serviços do processo. [GP105]




Atribuir responsabilidades e autoridade para executar o processo, desenvolver os produtos de trabalho e fornecer os serviços do processo de definição do processo organizacional. [GP106]


Treinar as pessoas para executar ou suportar o processo de definição do processo organizacional, conforme necessário. [GP107]

Implementações


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


Identificar e envolver os stakeholders relevantes do processo de definição do processo organizacional, conforme planejado. [GP124]


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


Coletar produtos de trabalho, medidas, resultados de medições e informações de melhorias derivados do planejamento e execução do processo de definição do processo organizacional para dar suporte à futura utilização e melhoria dos processos e ativos de processos da organização. [GP117]



Verificações


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


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



TREINAMENTO ORGANIZACIONAL


O objetivo do Treinamento Organizacional é desenvolver as habilidades e conhecimentos das pessoas de forma que elas possam desempenhar seus papéis de forma mais eficiente e eficaz. [PA158]



Uma capacidade de treinamento que suporta o gerenciamento e os papéis técnicos da organização é estabelecida e mantida. [PA158.IG101]





Práticas por Meta:


Uma capacidade de treinamento que suporta o gerenciamento e os papéis técnicos da organização é estabelecida e mantida. [PA158.IG101]

SP 1.1 Estabelecer as Necessidades Estratégicas de Treinamento

Estabelecer e manter as necessidades estratégicas de treinamento da organização. [PA158.IG101.SP101]

SP 1.2 Determinar quais as Necessidades de Treinamento são de Responsabilidade da Organização

Determinar quais necessidades de treinamento são de responsabilidade da organização e quais serão deixadas para o projeto individual ou grupo de suporte. [PA158.IG101.SP102]



SP 1.3 Estabelecer um Plano Tático de Treinamento Organizacional

Estabelecer e manter um plano tático de treinamento organizacional. [PA158.IG101.SP103]

SP 1.4 Estabelecer a Capacidade de Treinamento

Estabelecer e manter a capacidade de treinamento para atender às necessidades de treinamento organizacional. [PA158.IG101.SP104]



SP 2.1 Entregar o Treinamento

Entregar o treinamento seguindo o plano tático de treinamento organizacional. [PA158.IG102.SP101]

SP 2.2 Estabelecer Registros de Treinamento

Estabelecer e manter registros do treinamento organizacional. [PA158.IG102.SP102]

SP 2.3 Avaliar a Eficácia do Treinamento

Avaliar a eficiência do programa de treinamento da organização. [PA158.IG102.SP103]



Compromissos


Estabelecer e manter uma política organizacional para planejar e executar o processo de treinamento organizacional. [GP103]



Habilitações


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


Estabelecer e manter o plano para execução do processo de treinamento organizacional. [GP104]


Fornecer os recursos adequados para executar o processo de treinamento organizacional, desenvolver os produtos de trabalho e fornecer os serviços do processo. [GP105]


Atribuir responsabilidades e autoridade para executar o processo, desenvolver os produtos de trabalho e fornecer os serviços do processo de treinamento organizacional. [GP106]


Treinar as pessoas para executar ou suportar o processo de treinamento organizacional, conforme necessário. [GP107]

Implementações


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


Identificar e envolver os stakeholders relevantes do processo de treinamento organizacional, conforme planejado. [GP124]




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


Coletar produtos de trabalho, medidas, resultados de medições e informações de melhorias derivados do planejamento e execução do processo de treinamento organizacional para dar suporte à futura utilização e melhoria dos processos e ativos de processos da organização. [GP117]

Verificações


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


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



GERENCIAMENTO INTEGRADO DO PROJETO


O objetivo do Gerenciamento Integrado do Projeto é estabelecer e gerenciar o projeto e o envolvimento dos stakeholders relevantes de acordo com um processo definido e integrado que é adaptado a partir do conjunto de processos padrão da organização. [PA167]








Práticas por Meta:



SP 1.1 Estabelecer o Processo Definido do Projeto

Estabelecer e manter o processo definido do projeto. [PA167.IG101.SP101]

SP 1.2 Utilizar os Ativos de Processos Organizacional para o Planejamento das Atividades do Projeto

Utilizar os ativos de processos organizacionais e o repositório de medições para estimar e planejar as atividades do projeto. [PA167.IG101.SP102]



SP 1.3 Integrar os Planos

Integrar o plano do projeto e outros planos que afetam o projeto para descrever o processo definido do projeto. [PA167.IG101.SP103]

SP 1.4 Gerenciar o Projeto Utilizando os Planos Integrados

Gerenciar o projeto utilizando o plano do projeto, outros planos que afetam o projeto e o processo definido do projeto. [PA167.IG101.SP104]

SP 1.5 Contribuir para os Ativos de Processos Organizacionais

Contribuir com produtos de trabalho, medidas e experiências documentadas para os ativos de processos organizacionais. [PA167.IG101.SP105]



SP 2.1 Gerenciar o Envolvimento dos Stakeholders

Gerenciar o envolvimento dos stakeholders relevantes do projeto. [PA167.IG102.SP101]

SP 2.2 Gerenciar Dependências

Participar com os stakeholders relevantes para identificar, negociar e rastrear as dependências críticas. [PA167.IG102.SP102]

SP 2.3 Resolver Questões de Coordenação

Resolver questões com os stakeholders relevantes. [PA167.IG102.SP103]



Nível de Maturidade: 3, Gerenciamento Integrado do Projeto538


Compromissos


Estabelecer e manter uma política organizacional para planejar e executar o processo de gerenciamento integrado do projeto. [GP103]

Habilitações


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


Estabelecer e manter o plano para execução do processo de gerenciamento integrado do projeto. [GP104]


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


Atribuir responsabilidades e autoridade para executar o processo, desenvolver os produtos de trabalho e fornecer os serviços do processo de gerenciamento integrado do projeto. [GP106]


Treinar as pessoas para executar ou suportar o processo de gerenciamento integrado do projeto, conforme necessário. [GP107]



Implementações


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


Identificar e envolver os stakeholders relevantes do processo de gerenciamento integrado do projeto, conforme planejado. [GP124]


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


Coletar produtos de trabalho, medidas, resultados de medições e informações de melhorias derivados do planejamento e execução do processo de gerenciamento integrado do projeto para dar suporte à futura utilização e melhoria dos processos e ativos de processos da organização. [GP117]

Verificações


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


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

Nível de Maturidade: 3, Gerenciamento Integrado do Projeto540


GERENCIAMENTO DE RISCOS


O objetivo do Gerenciamento de Riscos é identificar os problemas potenciais antes que ocorram, de forma que as atividades de tratamento de riscos podem ser planejadas e invocadas conforme necessário em toda a vida do produto ou projeto para mitigar os impactos adversos na satisfação dos objetivos. [PA148]






SG 3 Mitigar Riscos




Práticas por Meta:



SP 1.1 Determinar Fontes e Categorias de Riscos

Determinar fontes e categorias de riscos. [PA148.IG101.SP101]



SP 1.2 Definir Parâmetros de Riscos

Definir os parâmetros utilizados para analisar e categorizar os riscos e os parâmetros utilizados para controlar o esforço de gerenciamento de riscos. [PA148.IG101.SP102]

SP 1.3 Estabelecer uma Estratégia de Gerenciamento de Riscos

Estabelecer e manter a estratégia a ser utilizada para o gerenciamento de riscos. [PA148.IG101.SP103]



SP 2.1 Identificar Riscos

Identificar e documentar os riscos. [PA148.IG102.SP101]

SP 2.2 Avaliar, Categorizar e Priorizar Riscos

Avaliar e categorizar cada risco identificado utilizando categorias e parâmetros definidos de riscos e determinar sua prioridade relativa. [PA148.IG102.SP102]

SG 3 Mitigar Riscos


SP 3.1 Desenvolver Planos de Mitigação de Riscos

Desenvolver um plano de mitigação de riscos para os riscos mais importantes para o projeto, conforme definido na estratégia de gerenciamento de riscos. [PA148.IG103.SP101]

SP 3.2 Implementar Planos de Mitigação de Riscos

Monitorar o status de cada risco periodicamente e implementar o plano de mitigação de riscos, conforme apropriado. [PA148.IG103.SP102]





Compromissos


Estabelecer e manter uma política organizacional para planejar e executar o processo de gerenciamento de riscos. [GP103]

Habilitações


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


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


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


Atribuir responsabilidades e autoridade para executar o processo, desenvolver os produtos de trabalho e fornecer os serviços do processo de gerenciamento de riscos. [GP106]


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



Implementações


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


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


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


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 riscos para dar suporte à futura utilização e melhoria dos processos e ativos de processos da organização. [GP117]

Verificações


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


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



ANÁLISES DE DCISÕES E RESOLUÇÕES


O objetivo das Análises de Decisões e Resoluções é analisar as decisões possíveis utilizando um processo formal de avaliação que avalia as alternativas identificadas contra os critérios estabelecidos. [PA156]






Práticas por Meta:



SP 1.1 Estabelecer Instruções para a Análise de Decisões

Estabelecer e manter instruções para determinar quais questões estão sujeitas a um processo formal de avaliação. [PA156.IG101.SP101]

SP 1.2 Estabelecer Critérios de Avaliação

Estabelecer e manter os critérios para a avaliação de alternativas e a classificação relativa destes critérios. [PA156.IG101.SP103]

SP 1.3 Identificar Soluções Alternativas

Identificar soluções alternativas para tratar questões. [PA156.IG101.SP104]

SP 1.4 Selecionar Métodos de Avaliação

Selecionar os métodos de avaliação. [PA156.IG101.SP102]



SP 1.5 Avaliar Alternativas

Avaliar as soluções alternativas utilizando os critérios e métodos estabelecidos. [PA156.IG101.SP105]

SP 1.6 Selecionar Soluções

Selecionar soluções a partir de alternativas baseadas em critérios de avaliação. [PA156.IG101.SP106]



Compromissos


Estabelecer e manter uma política organizacional para planejar e executar o processo de análises de decisões e resoluções. [GP103]

Habilitações


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


Estabelecer e manter o plano para execução do processo de análises de decisões e resoluções. [GP104]


Fornecer os recursos adequados para executar o processo de análises de decisões e resoluções, desenvolver os produtos de trabalho e fornecer os serviços do processo. [GP105]




Atribuir responsabilidades e autoridade para executar o processo, desenvolver os produtos de trabalho e fornecer os serviços do processo de análises de decisões e resoluções. [GP106]


Treinar as pessoas para executar ou suportar o processo de análises de decisões e resoluções, conforme necessário. [GP107]

Implementações


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


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


Monitorar e controlar o processo de análises de decisões e resoluções contra o plano para execução do processo e tomar as ações corretivas apropriadas. [GP110]


Coletar produtos de trabalho, medidas, resultados de medições e informações de melhorias derivados do planejamento e execução do processo de análises de decisões e resoluções para dar suporte à futura utilização e melhoria dos processos e ativos de processos da organização. [GP117]



Verificações


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


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


Documents

CMMI em Português