(Parte 1 de 59)

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]

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]

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]

No Apêndice E estão listados os membros atuais e eméritos dos quatro grupos envolvidos no desenvolvimento dos produtos CMMI. [FM101.HDA102.T111]

Onde Procurar Informações Adicionais

Você pode encontrar informações adicionais, como o público alvo, cenários, históricos dos modelos CMMI e os benefícios de se utilizar os modelos CMMI em diversas fontes. Muitas destas fontes estão documentadas no site do CMMI, em http://www.sei.cmu.edu/cmmi/. [FM101.HDA103.T101]

Feedback

Sugestões para melhorar o CMMI Product Suite são bem-vindas. Veja o site do CMMI para obter informações sobre como fornecer feedback: http://www.sei.cmu.edu/cmmi/. [FM101.HDA104.T101]

Se tiver perguntas, envie um e-mail para cmmi-comments@sei.cmu.edu. [FM101.HDA104.T103]

Conteúdo

Prefácio i

Histórico do Desenvolvimento i

Agradecimentos iii

Onde Procurar Informações Adicionais iv

Feedback iv

1 Introdução 1

Sobre os Modelos CMMI 1

Selecionando um Modelo CMMI 2

Representações: Contínua ou em Estágios? 2

Representação Contínua 2

Representação em Estágios 3

Que Modelo Integrado Escolher? 3

Disciplinas: Qual é a Diferença? 3

Engenharia de Sistemas 4

Engenharia de Software 4

Desenvolvimento Integrado de Produtos e Processos 4

Uma Recomendação 5

O Conteúdo dos Modelos CMMI 5

Convenções Tipográficas 6

Metas Específicas e Genéricas 7

Práticas Específicas e Genéricas 7

Referências 7

Notas Introdutórias, Produtos de Trabalho Típicos e Sub-práticas 7

Exemplos 7

Elaborações das Práticas Genéricas 8

Definições Ampliadas de Disciplinas 8

Esquema de Numeração 8

Códigos de Identificação de Parágrafos 9

2 Componentes do Modelo 10

Visão Geral da Estrutura 10

Níveis de Maturidade 11

Detalhes dos Níveis de Maturidade 12

Nível de Maturidade 1: Inicial 12

Nível de Maturidade 2: Gerenciado 12

Nível de Maturidade 3: Definido 13

Nível de Maturidade 4: Gerenciado Quantitativamente 14

Nível de Maturidade 5: Otimizado 15

Avançando Através dos Níveis de Maturidade 16

Saltando Níveis de Maturidade 17

Componentes Exigidos, Esperados e Informativos 18

Componentes do Modelo 19

Áreas de Processos 19

Metas Específicas 19

Práticas Específicas 20

Características Comuns 20

Produtos de Trabalho Típicos 20

Sub-práticas 20

Definições Ampliadas de Disciplinas 21

Metas Genéricas 21

Práticas Genéricas 21

Elaborações de Práticas Genéricas 21

Referências 22

Comparação das Representações de Modelos 22

3 Terminologia do Modelo 24

Evolução da Terminologia 24

Terminologia Comum com Significados Especiais 25

Adequado, Apropriado, Conforme Necessário 25

Estabelecer e Manter 25

Cliente 25

Stakeholder 25

Stakeholders relevantes 26

Gerente 26

Gerente do Projeto 26

Gerente Sênior 26

Visão Compartilhada 27

Organização 27

Empreendimento 27

Desenvolvimento 27

Disciplina 27

Projeto 28

Produto 28

Produto de Trabalho 28

Componente do Produto 28

Avaliação (Appraisal) 29

Análise (Assessment) 29

Instruções para Adaptação 29

Verificação 30

Validação 30

Meta 30

Objetivo 30

Objetivos de Qualidade e Desempenho do Processo 31

Padrão 31

Terminologia Específica do CMMI 31

CMMI Product Suite 31

Framework CMMI 31

Modelo CMMI 32

Revisão por Pares 32

Conjunto de Processos Padrão da Organização 32

Processo 32

Processo Gerenciado 33

Processo Definido 33

Ativos de Processos Organizacionais 33

Arquitetura dos Processos 34

Ciclo de Vida do Produto 34

Repositório de Medições da Organização 34

Biblioteca de Ativos de Processos da Organização 35

Documento 35

4 Características Comuns, Metas Genéricas e Práticas Genéricas 37

Visão Geral 37

Características da Institucionalização 37

Metas Genéricas 39

Características Comuns 40

Práticas Genéricas Listadas por Características Comuns 40

5 Interações do Framework 53

Quatro Categorias de Áreas de Processos do CMMI 53

Gerenciamento de Processos 54

O Escopo do Gerenciamento de Processos 54

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

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

Gerenciamento de Projetos 59

O Escopo do Gerenciamento de Projetos 59

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

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

Engenharia 64

O Escopo da Engenharia 64

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

Áreas de Processos de Engenharia e Recursão 68

Suporte 69

O Escopo do Suporte 69

Áreas de Processos Básicas de Suporte 70

Áreas de Processos Avançadas de Suporte 72

6 Utilizando os Modelos CMMI 76

Interpretando os Modelos CMMI 76

Avaliações e Benchmarking 77

Requisitos de Avaliações para o CMMI 79

Compatibilidade e Conformidade com o ISO/IEC 15504 79

Fazendo a Transição para o CMMI 80

Organizações com Experiência no CMM para Software 80

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

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

Treinamento 83

Perspectivas de Adaptação 83

Adaptação do Modelo 83

Perspectivas de Adaptação do Modelo 83

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

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

Adaptação de Modelos para Pequenos Projetos 86

Adaptação de Avaliações 87

7 Áreas de Processos 89

Nível de Maturidade 2: Gerenciado 91

Gerenciamento de Requisitos 92

Planejamento do Projeto 105

Monitoramento e Controle do Projeto 134

Gerenciamento de Acordos com Fornecedores 150

Medições e Análises 167

Garantia da Qualidade do Processo e do Produto 189

Gerenciamento de Configurações 202

Nível de Maturidade 3: Definido 222

Desenvolvimento de Requisitos 223

Soluções Técnicas 246

Integração de Produtos 280

Verificação 302

Validação 321

Foco no Processo Organizacional 335

Definição do Processo Organizacional 354

Treinamento Organizacional 371

Gerenciamento Integrado do Projeto 389

Gerenciamento de Riscos 411

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

A. Acrônimos 447

B. Glossário 452

C. Elementos Exigidos e Esperados do Modelo 482

Nível de Maturidade: 2 483

Gerenciamento de Requisitos 484

Planejamento do Projeto 487

Monitoramento e Controle do Projeto 492

Gerenciamento de Acordos com Fornecedores 496

Medições e Análises 500

Garantia da Qualidade do Processo e do Produto 504

Gerenciamento de Configurações 508

Nível de Maturidade: 3 513

Desenvolvimento de Requisitos 514

Soluções Técnicas 519

Integração de Produtos 524

Verificação 529

Validação 534

Foco no Processo Organizacional 538

Definição do Processo Organizacional 542

Treinamento Organizacional 546

Gerenciamento Integrado do Projeto 550

Gerenciamento de Riscos 554

Análises de Dcisões e Resoluções 558

1Introduçã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]

Sua organização pode utilizar um modelo CMMI para ajudar a definir os objetivos e prioridades de melhoria de processos, melhorar processos e fornecer direcionamento para assegurar processos estáveis, capacitados e maduros. Um modelo CMMI selecionado pode servir como guia para a melhoria dos processos organizacionais. [FM108.HDA102.T102]

Utilize uma opinião profissional para interpretar as práticas específicas e genéricas do CMMI. Embora as áreas de processos ilustrem comportamentos que deveriam aparecer em qualquer organização, todas as práticas devem ser interpretadas utilizando um conhecimento profundo do modelo CMMI que está sendo utilizado, da organização, do ambiente de negócios e das circunstâncias envolvidas. [FM108.HDA102.T104]

Selecionando um Modelo CMMI

Existem diversos modelos CMMI disponíveis, gerados a partir do CMMI Framework. Em conseqüência disso, você precisa estar preparado para decidir qual modelo CMMI melhor atende às necessidades de melhoria de processos da sua organização. [FM108.HDA101.T101]

Você deve selecionar uma representação, contínua ou em estágios, e determinar as áreas de conhecimento que deseja incluir no modelo que sua organização irá utilizar. [FM108.HDA101.T102]

Representações: Contínua ou em Estágios?

Existem muitas razões válidas para selecionar uma representação ou outra. Pode ser que a sua organização escolha utilizar a representação que lhe seja mais familiar. As listas seguintes descrevem algumas das possíveis vantagens e desvantagens de selecionar cada uma das representações. [FM108.HDA101.HDB101.T101]

Representação Contínua

Se você escolher a representação contínua para sua organização, pode esperar que o modelo: [FM108.HDA101.HDB102.T101]

  • Permitirá que você selecione a seqüência de melhorias que melhor atende os objetivos de negócios e reduz as áreas de risco da sua organização

  • Possibilitará comparações dentro e entre organizações em uma área de processo em termos de área de processo ou pela comparação de resultados através do uso de estágios equivalentes

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

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

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]

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.

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

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]

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]

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]

2Componentes 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]

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]

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]

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]

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]

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]

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]

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]

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.

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]

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]

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]

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.

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]

3Terminologia 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]

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]

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

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]

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]

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]

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]

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]

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

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]

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]

4Caracterí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)

  • 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

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]

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]

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]

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]

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]

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]

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]

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]

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

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]

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.

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.

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]

5Interaçõ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

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

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

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]

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]

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]

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

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]

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]

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]

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)

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]

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]

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]

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]

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)

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

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]

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]

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]

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]

6Utilizando 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]

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

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

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]

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]

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]

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]

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

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

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

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]

7Áreas de Processos

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]

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]

Áreas de Processos Relacionadas

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

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

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

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

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

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

Metas Específicas e Genéricas

SG 1 Gerenciar Requisitos [PA146.IG101]

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

GG 2 Institucionalizar um Processo Gerenciado [CL103.GL101]

O processo é institucionalizado como um processo gerenciado.

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

GG 3 Institucionalizar um Processo Definido [CL104.GL101]

O processo é institucionalizado como um processo definido.

Tabela de Relacionamentos Práticas-Metas

SG 1 Gerenciar Requisitos [PA146.IG101]

SP 1.1 Obter um Entendimento dos Requisitos

SP 1.2 Obter Compromisso sobre os Requisitos

SP 1.3 Gerenciar Mudanças nos Requisitos

SP 1.4 Manter a Rastreabilidade Bidirecional dos Requisitos

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

GG 2 Institucionalizar um Processo Gerenciado [CL103.GL101]

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

GP 2.2 (AB 1) Planejar o Processo

GP 2.3 (AB 2) Fornecer Recursos

GP 2.4 (AB 3) Atribuir Responsabilidades

(Parte 1 de 59)

Comentários