Capability Maturity Model Integration - CMMI

Transcrição

1 Capability Maturity Model Integration - CMMI Para Desenvolvimento Versão 1.2 M.Sc. Roberto Couto Lima

2 ÍNDICE 1. Definição Evolução Modelos Integrados e Disciplinas Disciplinas Modelos Áreas de Conhecimento Categorias Representações Níveis de Capacidade Capability Levels Níveis de Maturidade Maturity Levels Níveis de Capacidade Capability Levels x Níveis de Maturidade Maturity Levels Modelo de Componentes Área de Processo Process Area Propósito Purpose Statement Nota introdutória Introductory Notes Áreas de Processos Relacionados Related Process Area Objetivos Específicos Specific Goals Objetivos Genéricos Generic Goals Práticas Específicas Specific Practices Práticas Genéricas Generic Practices Produtos de Trabalho Típicos Typical Work Products Sub-Práticas Subpractices Componentes Informativos de Suporte Supporting Informative Components Exemplo Real da Estrutura de uma Área de Processo e seus Componentes Análise de Causas e Resoluções Verificação Gerenciamento Integrado de Projeto + IPPD Objetivos Genéricos GG e Práticas Genéricas GP Objetivos Genéricos e a Representação por Estágios Áreas de Processo, Objetivos Específicos SG, Práticas Específicas SP e Área de Processo Gestão de Requisitos Área de Processo Planejamento de Projeto Área de Processo Garantia da Qualidade de Processo e Produto Área de Processo Gestão de Configuração Página 2 de 31

3 9.5. Área de Processo Gestão de Risco Página 3 de 31

4 1. Definiçã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. 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. 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. Portanto CMMI é um modelo de referência que contém práticas (Genéricas ou Específicas) necessárias à maturidade em disciplinas específicas como Engenhaira de Sistemas, Engenharia de Software, Engenharia de Hardware, Desenvolvimento Integrado de Produtos e Processos, Aquisição e Suporte, dando uma visão estruturada da melhoria (aprimoramento) da visão de processos de uma organização. 2. Evolução Página 4 de 31

5 3. Modelos Integrados e Disciplinas 3.1. Disciplinas 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. 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. 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. Na ultima versão do CMMI 1.2 o IPPD é opcional, ou seja, é considerado como additions Modelos Desenvolvimento sem IPPD CMMI para desenvolvimento é um modelo de referência que cobre as atividades de desenvolvimento e de manutenção aplicadas tanto para produto como serviço. Este modelo contém práticas que cobrem gerenciamento de projeto, gerenciamento de processo, engenharia de sistemas, engenharia de hardware e os processos de suporte usados no desenvolvimento e manutenção. Desenvolvimento com IPPD CMMI para desenvolvimento + IPPD também cobre o uso de times integrados para as atividades de desenvolvimento e manutenção. 4. Áreas de Conhecimento Categorias As áreas de processos podem ser agrupadas em quatro categorias: Gerenciamento de Processos Gerenciamento de Projetos Engenharia Suporte 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. 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: Página 5 de 31

6 Áreas de processos básicas 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: Foco no Processo Organizacional Definição do Processo Organizacional + IPPD Treinamento Organizacional Áreas de processos avançadas dão à organização uma avançada capacidade para atingir seus objetivos quantitativos de qualidade e desempenho do processo: Desempenho do Processo Organizacional Inovação e Desenvolvimento Organizacional As áreas de processos de Gerenciamento de Projetos cobrem as atividades de gerenciamento de projetos relacionadas ao planejamento, monitoramento e controle do projeto. 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: Áreas de processos básicas 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: Planejamento do Projeto Monitoramento e Controle do Projeto Gerenciamento de Acordos com Fornecedores Áreas de processos avançadas 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: Gerenciamento Integrado de Projetos + IPPD Gerenciamento de Riscos Gerenciamento Quantitativo de Projetos 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. São eles: Desenvolvimento de Requisitos Gerenciamento de Requisitos Soluções Técnicas Integração de Produtos Verificação Validação Página 6 de 31

7 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. 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: Áreas de processos básicas 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: Medições e Análises Garantia da Qualidade do Processo e do Produto Gerenciamento de Configurações Áreas de processos avançadas 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: Análise de Causas e Resoluções Análise de Decisões e Resoluções Uma área de processo com +IPPD após seu nome, contem um objetivo e uma pratica que são especificas ao IPPD. O material especifico sobre IPPD é chamado de IPPD adicional. 5. Representações 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. Representação Contínua 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 Página 7 de 31

8 Representação em Estágios 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 Níveis de Capacidade Capability Levels Níveis de capacidade, que pertencem a representação contínua, são aplicados para alcançar o melhoramento em uma única área de processo. Estes níveis representam um melhoramento gradativo de uma área de processo, existem seis níveis de capacidade, numerados de 0 a 5. Uma visão profile dos níveis de capacidade é uma lista de áreas de processos e suas correspondentes capacidades alcançadas, que pode ser visualizado pela figura a seguir: Página 8 de 31

9 Detalhes dos Níveis de Capacidade O fato dos níveis de capacidade de 2 a 5 usarem o mesmo termo como objetivo genérico é intencional, porque cada um desses objetivos e praticas genéricas refletem o nível de capacidade em termos de objetivos e praticas que você pode implementar. As seções seguintes descrevem as características de cada nível de capacidade em detalhes. Nível de Capacidade 0: Incompleto U m processo incompleto é um processo que não é realizado ou é realizado parcialmente, ou seja, pelo menos um de seus objetivos específicos da área de processo não é satisfeito e nenhum objetivo genérico existe para este nível, pois não há razão para institucionalizar um processo parcialmente. Nível de Capacidade 1: Executado Um processo com nível de capacidade 1 é caracterizado como um processo executado, ou seja, satisfaz os objetivos específicos da área de processo. Ele suporta e possibilita o trabalho necessário para produzir os produtos do trabalho. Nível de Capacidade 2: Gerenciado Um processo com nível de capacidade 2 é caracterizado como um processo gerenciado, ou seja é executado com a infraestrutura básica para suportar o processo. Ele é planejado e executado de acordo com as políticas, aplica pessoas habilitadas que possuem recursos adequados para produzir resultados controlados; envolve os stakeholders importantes; é monitorado, controlado e revisado; e é avaliado com base na sua própria descrição. A disciplina do processo com nível de capacidade 2 ajuda a confirmar que as práticas existentes são mantidas durante períodos de stress. Nível de Capacidade 3: Definido Um processo com nível de capacidade 3 é caracterizado como um processo definido, ou seja, é gerenciado e personalizado de acordo com um conjunto de processos padrões da organização. Uma Página 9 de 31

10 diferença entre o nível de capacidade 2 e 3 é o escopo dos padrões, descrições dos processos e procedimentos. No nível de capacidade 2, os padrões, descrições de processo e procedimentos variam em cada instância do processo, no nível de capacidade 3, os padrões, as descrições de processo e procedimentos são personalizados, com base em um conjunto padrão de processos da organização, para atender um projeto particular. Outra diferença é que no nível de capacidade 3, processos são descritos com mais rigor que no nível de capacidade 2. No nível de capacidade 3 os processos são gerenciados com mais proatividade, pois um processo definido claramente define seu propósito, entradas e seus critérios, atividades, regras, medidas, etapas de verificação, saídas e seus critérios. Nível de Capacidade 4: Gerenciado Quantitativamente Um processo com nível de capacidade 4 é caracterizado como um processo gerenciado quantitativamente, ou seja é definido e controlado usando estatística e outros métodos quantitativos. Objetivos quantitativos para a qualidade e performance são estabelecidos e usados como critério no gerenciamento do processo. Qualidade e performance do processo é entendido estatisticamente e é gerenciado durante toda a vida do processo. Nível de Capacidade 5: Em Otimização Um processo com nível de capacidade 5 é caracterizado como um processo em otimização, ou seja é gerenciado quantitativamente constantemente melhorado baseado no entendimento das causas comuns de variações que acontecem no processo. O foco de um processo em otimização é a constante evolução na performance do processo através de melhorias e inovações Níveis de Maturidade Maturity Levels Níveis de Maturidade, que pertencem a representação por estágios, são aplicados ao melhoramento da organização por meio do melhoramento de múltiplas áreas de processo. Estes níveis representam um caminho predefinido para um próximo estágio, existem cinco níveis de maturidade, numerados de 1 a 5. A figura a seguir mostra o relacionamento entre as áreas de processo e os níveis de maturidade. 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. Página 10 de 31

11 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. 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. 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. 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. 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). 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. A seguir as áreas de processos necessárias para o nível 2 Gerenciado : Gestão de Requisitos Planejamento de Projeto Monitoramento e Controle de Projeto Gestão de Contrato com Fornecedor Medição e Análise Garantia da Qualidade de processo e Produto Gestão de Configuração 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. 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. 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. 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 Página 11 de 31

12 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. 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 interrelacionamentos das atividades de processos e medidas detalhadas do processo, seus produtos de trabalho e seus serviços. A seguir as áreas de processos necessárias para o nível 3 Definido : Desenvolvimento de Requisitos Solução Técnica Integração de Produto Verificação Validação Foco no Processo Organizacional Definição do Processo Organizacional Treinamento Organizacional Gestão Integrada de Projeto Gestão de Risco Análise de Decisão 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 sub-processos que contribuem significativamente para o desempenho geral do processo. Estes sub-processos selecionados são controlados utilizando estatísticas e outras técnicas quantitativas. 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. Para estes processos, são coletadas e analisadas de forma estatística, medidas detalhadas de desempenho de processos. Causas especiais de variações de processos são identificadas e, quando apropriado, as fontes das causas especiais são corrigidas para evitar ocorrências futuras. 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. 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. A seguir as áreas de processos necessárias para o nível 4 Gerenciado Quantitativamente : Desempenho do Processo Organizacional Gestão Quantitativa de Projeto Página 12 de 31

13 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ções inerentes aos processos. 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. 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. 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. 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. A seguir as áreas de processos necessárias para o nível 5 Em Otimização : Inovação Organizacional Análise de Causa e Solução de Problemas 5.3. Níveis de Capacidade Capability Levels x Níveis de Maturidade Maturity Levels Na Tabela a seguir tem-se a disposição dos níveis de capacidade e maturidade: Nível Nível 0 Representação Contínua Incompleto Níveis de Capacidade Nível 1 Executado Inicial Nível 2 Gerenciado Gerenciado Nível 3 Definido Definido Representação por Estágios Níveis de Maturidade Nível 4 Gerenciado Quantitativamente Gerenciado Quantitativamente Nível 5 Em Otimização Em Otimização Página 13 de 31

14 A Tabela a seguir mostra o resumo das visões que devem ser alcançados quando utilizados a representação continua para ser equivalente com os níveis de maturidade de 2 a 5. Cada área marcada na coluna do nível de capacidade representa uma visão profile que é equivalente a um nível de maturidade. 6. Modelo de Componentes Os componentes das representações em estágios e contínua são áreas de processos, objetivos específicos, práticas específicas, objetivos genéricos, práticas genéricas, produtos de trabalho típicos, sub-práticas, elaborações de práticas genéricas, propósito, notas introdutórias, áreas de processos relacionados e componentes informativos de suporte (notas, exemplos, amplificações, referência). Estes componentes estão organizados em 3 categorias: Componentes Requeridos são componentes que descrevem o que uma organização deve realizar para satisfazer uma área de processo. Página 14 de 31

15 Componentes Esperados são componentes que descrevem o que é importante que uma organização implemente para alcançar um componente requerido. Componentes informativos são componentes que oferecem uma orientação que ajudam as organizações no entendimento sobre como alcançar um componente requerido e esperado Área de Processo Process Area Uma área de processo é um cluster de praticas relacionadas em uma área que, quando implementadas coletivamente, satisfazem um conjunto de objetivos considerados importantes para fazer uma melhoria na respectiva área. Existem 22 áreas de processos, listadas e divididas entre as quatro categorias descritas no item 4 anteriormente Propósito Purpose Statement Descreve o propósito de uma área de processo, é um componente informativo. Por exemplo, o propósito da área de processo Planejamento de Projeto: Estabelecer e manter planos que definam as atividades de projeto Nota introdutória Introductory Notes A seção de nota introdutória de uma área de processo descreve de uma forma mais abrangente a área de processo, é um componente informativo. Um exemplo, para o processo Planejamento de Projeto: A área de processo Planejamento de Projeto envolve o seguinte: Elaboração do plano de projeto Interação apropriada com os stackeholders Obtenção do comprometimento com o plano Manutenção do plano O planejamento inicia com os requisitos que definem o produto e o projeto. Página 15 de 31

16 O planejamento inclui a estimativa de atributos dos produtos de trabalho e tarefas, determinando os recursos necessários, negociando comprometimentos, produzindo um cronograma, identificando e analisando os riscos do projeto. A repetição dessas atividades pode ser necessária para se estabelecer um plano de projeto. O plano de projeto fornece a base para a execução e o controle das atividades do projeto que tratam dos comprometimentos com os clientes do projeto. O plano de projeto normalmente precisará ser revisado de acordo com o progresso do projeto para tratar das mudanças nos requisitos e comprometimentos, estimativas incorretas, ações corretivas e processo de mudanças. As práticas específicas que descrevem o planejamento e o replanejamento estão contidas nessa área de processo. A expressão plano de projeto é utilizada nas práticas genéricas e específicas nesta área de processo para referenciar todos os planos para o controle do projeto Áreas de Processos Relacionados Related Process Area A seção de áreas de processos relacionados refere-se aos relacionamentos de alto nível entre as áreas de processo, também é um componente informativo. Um exemplo do processo Planejamento de Projeto: Veja a área de processo Desenvolvimento de Requisitos para mais informações sobre desenvolvimento de requisitos que define o produto e os componentes de produto. Os requisitos de produto e componentes de produto servem como base para o planejamento e o replanejamento. Veja a área de processo Gestão de Requisitos para mais informações sobre gestão de requisitos necessários para planejamento e replanejamento. Veja a área de processo Gestão de Riscos para mais informações sobre identificação e gestão de requisitos. Veja a área de processo Solução Técnica para mais informações sobre transformação de requisitos em soluções de produto e componentes de produto Objetivos Específicos Specific Goals As metas ou objetivos específicos 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. Um exemplo de objetivo específico para a área de processo Planejamento de Projeto: Estabelecer estimativas Objetivos Genéricos Generic Goals As metas ou objetivos genéricos 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. Os objetivos genéricos são chamadas genéricos porque um mesmo objetivo genérico é aplicada em várias áreas de processo. Um exemplo de objetivo genérico: O processo é institucionalizado como um processo definido. Página 16 de 31

17 6.7. Práticas Específicas Specific Practices Uma prática específica é uma atividade que é considerada importante na satisfação de um objetivo específico associado. 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. Por exemplo, uma prática específica, relacionada ao objetivo especifico estabelecer estimativas da área de processo planejamento do projeto: Estimar o escopo do projeto Práticas Genéricas Generic Practices 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 pelos objetivos genéricos e são componentes esperados em modelos CMMI. As práticas genéricas são chamadas genéricas porque uma mesma prática genérica é aplicada em várias áreas de processo. Por exemplo, uma prática genérica, relacionada ao objetivo genérico institucionalizar um processo gerenciado : Designar responsabilidades Produtos de Trabalho Típicos Typical Work Products 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. Por exemplo, um produto típico de trabalho, relacionado à prática específica estimar o escopo do projeto do objetivo específico estabelecer estimativas da área de processo planejamento do projeto: Descrição das tarefas Sub-Práticas Subpractices 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. Como exemplo de uma sub-prática para a prática específica estimar o escopo do projeto que está relacionado ao objetivo específico estabelecer estimativas da área de processo planejamento do projeto temos: Desenvolver o Work Breakdown Structure WBS, baseado na arquitetura do produto Componentes Informativos de Suporte Supporting Informative Components Em vários casos, mais informação é necessário para descrever um conceito. Este material informativo é oferecido por meio de um dos componentes a seguir: Notas Exemplos Amplificadores uma nota ou exemplo que é relevante para uma disciplina particular Referências ligação para mais informações detalhadas em outras áreas de processos Página 17 de 31

18 7. Exemplo Real da Estrutura de uma Área de Processo e seus Componentes 7.1. Análise de Causas e Resoluções Página 18 de 31

19 7.2. Verificação Página 19 de 31

20 7.3. Gerenciamento Integrado de Projeto + IPPD Página 20 de 31

21 8. Objetivos Genéricos GG e Práticas Genéricas GP GG 1 Alcançar Metas Específicas Apenas para a Representação Contínua GP 1.1 Executar Práticas Específicas GG 2 Institucionalizar um Processo Gerenciado GP 2.1 Estabelecer uma Política Organizacional GP 2.2 Planejar o Processo GP 2.3 Fornecer Recursos GP 2.4 Atribuir Responsabilidades GP 2.5 Treinar Pessoas GP 2.6 Gerenciar Configurações GP 2.7 Identificar e Envolver os Stackeholders Relevantes GP 2.8 Monitorar e Controlar o processo GP 2.9 Avaliar Objetivamente a Aderência GP 2.10 Revisar a Situação com a Gerência Superior GG 3 Institucionalizar um Processo Definido GP 3.1 Estabelecer um Processo Definido GP 3.2 Coletar Informações de Melhoria GG 4 Institucionalizar um Processo Gerenciado Quantitativamente Apenas para a Representação Contínua GP 4.1 Estabelecer Objetivos Quantitativos para o Processo GP 4.2 Estabilizar o Desempenho do Subprocesso GG 5 Institucionalizar um Processo em Otimização Apenas para a Representação Contínua GP 5.1 Melhoria Contínua de Processo GP 5.2 Corrigir as Causas Raízes dos Problemas 8.1. Objetivos Genéricos e a Representação por Estágios Na representação por estágio, somente os objetivos genéricos 2 e 3 são usados, como pode ser visualizado pela figura a seguir. Quando você tenta alcançar o nível de maturidade 2, você usa as áreas de processos do nível de maturidade 2 assim como o objetivo genérico 2 e suas praticas genéricas. Verifique que os objetivos genéricos 4 e 5 e suas práticas genéricas não são usadas, porque nem todos processos serão elevados acima do nível de processo definido. Somente processos selecionados e subprocessos serão quantitativamente gerenciados e melhorados, como os processos indicados nos níveis de maturidade 4 e 5. Página 21 de 31

22 9. Áreas de Processo, Objetivos Específicos SG, Práticas Específicas SP e Todas as 22 áreas de processos, independente da forma de representação, possui seus objetivos específicos, sendo cada objetivo específico(componente requerido) subdividido em práticas específicas(componente esperado), que por sua vez podem ser detalhadas em subpráticas(componente informativo). Para exemplificar os seus relacionamentos serão utilizadas algumas áreas de processo como: Gestão de Requisitos, Planejamento de Projeto, Garantia da Qualidade de Processo e Produto, Gestão de Configuração e Gestão de Risco. Para o detalhamento de todas as áreas de processo, verificar documentação oficial Área de Processo Gestão de Requisitos SG 1 Gerenciar Requisitos SP 1.1 Obter um Entendimento dos Requisitos 1. Estabelecer critérios para a apropriada distinção dos fornecedores dos requisitos. 2. Estabelecer critérios objetivos para a avaliação e aceitação de requisitos. 3. Analisar os requisitos para assegurar o atendimento aos critérios definidos. 4. Alcançar um entendimento dos requisitos com os fornecedores de requisitos de forma a haver um comprometimento com os participantes do projeto. SP 1.2 Obter Comprometimento com os Requisitos Página 22 de 31

23 1. Avaliar o impacto dos requisitos nos acordos existentes. 2. Negociar e registrar acordos. SP 1.3 Gerenciar Mudanças de Requisitos 1. Documentar todos os requisitos e mudanças de requisitos do projeto. 2. Manter um histórico de mudanças de requisitos com os fundamentos lógicos das mudanças. 3. Manter o histórico de mudanças ajuda a rastrear a volatilidade dos requisitos. 4. Avaliar o impacto das mudanças de requisitos do ponto de vista dos stackeholders relevantes. 5. Tornar disponíveis ao projeto os dados de requisitos e de mudanças. SP 1.4 Manter Rastreabilidade Bidirecional dos Requisitos 1. Manter a rastreabilidade dos requisitos para assegurar que a origem do menor nível de requisito (derivado) esteja documentada. 2. Manter a rastreabilidade de um requisito com seus requisitos derivados e com sua alocação a funções, interfaces, pessoas, processos e produtos de trabalho. 3. Gerar a matriz de rastreabilidade de requisitos. SP 1.5 Identificar Inconsistências entre Trabalho de Projeto e Requisitos 1. Revisar os planos de projeto, atividades e produtos de trabalho visando a consistência com os requisitos e com as mudanças neles realizadas. 2. Identificar a origem das inconsistências e fundamento lógico. 3. Identificar mudanças que necessitam ser feitas nos planos e produtos de trabalho resultantes das mudanças na baseline de requisitos. 4. Iniciar as ações corretivas Área de Processo Planejamento de Projeto SG 1 Estabelecer Estimativas SP 1.1 Estimar o Escopo do Projeto 1. Desenvolver uma WBS com base na arquitetura do produto. 2. Identificação de pacotes de trabalho em nível de detalhe suficiente para estimar o projeto, tarefas, responsabilidades e o cronograma. 3. Identificar produtos ou componentes de produto que serão adquiridos externamente. 4. Identificar produtos de trabalho que serão reutilizados. Página 23 de 31

24 SP 1.2 Estabelecer Estimativas de Atributos de Produtos de Trabalho e Tarefas 1. Determinar a abordagem técnica para o projeto. 2. Utilizar métodos apropriados para determinar os atributos dos produtos de trabalho e tarefas que serão usados para estimar os requisitos de recurso. 3. Estimar os atributos de produtos de trabalho e tarefas. SP 1.3 Definir o Ciclo de Vida do Projeto SP 1.4 Determinar Estimativas de Esforço e Custo 1. Coletar os modelos ou dados históricos que serão utilizados para transformar os atributos dos produtos de trabalho e tarefas em estimativas de horas de mão-de-obra e custo. 2. Incluir infra-estrutura de suporte necessária na estimativa de esforço e custo. 3. Estimar custo e esforço utilizando modelos e dados históricos. SG 2 Elaborar um Plano de Projeto SP 2.1 Estabelecer o Orçamento e Cronograma 1. Identificar os principais marcos. 2. Identificar hipóteses de cronograma. 3. Identificar restrições. 4. Identificar dependências de tarefas. 5. Estabelecer e manter o orçamento e cronograma do projeto, 6. Estabelecer critérios de ação corretiva. SP 2.2 Identificar Riscos do Projeto 1. Identificar os riscos 2. Documentar os riscos. 3. Examinar e obter autorização com dos stackeholders relevantes sobre a integralidade e correção dos riscos documentados. 4. Revisar os riscos quando apropriado. SP 2.3 Plano para Gerenciamento de Dados 1. Estabelecer requisitos e procedimentos para assegurar a privacidade e segurança dos dados. 2. Estabelecer um mecanismo para arquivamento e acesso aos dados. 3. Determinar os dados do projeto a serem identificados, coletados e distribuídos. SP 2.4 Plano para Recursos do Projeto 1. Determinar requisitos do processo. Página 24 de 31

25 2. Determinar os requisitos de preenchimento de vagas. 3. Determinar facilidades, equipamento e requisitos de componentes. SP 2.5 Plano para Conhecimentos e Perfis Necessários 1. Identificar o conhecimento e perfil necessários para a execução do projeto. 2. Avaliar os conhecimentos e perfis disponíveis. 3. Selecionar mecanismos para providenciar os necessários conhecimentos e perfis. 4. Incorporar os mecanismos selecionados ao plano de projeto. SP 2.6 Plano de Envolvimento de Stackeholders SP 2.7 Estabelecer o Plano do Projeto SG 3 Obter Comprometimento com o Plano SP 3.1 Revisar Planos que Afetam o Projeto SP 3.2 Conciliar Níveis de Trabalho e Recursos SP 3.3 Obter Comprometimento com o Plano 1. Identificar o suporte necessário e negociar os comprometimentos com os stackeholders relevantes. 2. Documentar todos os comprometimentos organizacionais, assegurando o apropriado nível de signatários. 3. Revisar os comprometimentos internos com a gerência sênior. 4. Revisar os comprometimentos externos com a gerência sênior, quando apropriado. 5. Identificar os comprometimentos nas interfaces entre os elementos do projeto, com outros projetos e com unidades organizacionais de forma que possam ser monitorados Área de Processo Garantia da Qualidade de Processo e Produto SG 1 Avaliar Objetivamente Processos e Produtos de Trabalho SP 1.1 Avaliar Objetivamente os Processos 1. Promover um ambiente (criado como parte da gestão do projeto) que encoraje os empregados a participarem na identificação e relato de problemas relacionados à qualidade. 2. Criar e manter critérios claramente estabelecidos para as avaliações. A intenção desta subprática é fornecer critérios, baseados nas necessidades do negócio, tais como: O que será avaliado Quando ou com que freqüência um processo será avaliado Como a avaliação será conduzida Página 25 de 31

26 Quem precisa ser envolvido na avaliação 3. Utilizar os critérios estabelecidos para avaliar a aderência dos processos executados em relação à descrição dos processos, padrões e procedimentos. 4. Identificar cada não-conformidade encontrada durante a avaliação. 5. Identificar lições aprendidas que poderiam melhorar os processos para produtos e serviços futuros. SP 1.2 Avaliar Objetivamente Produtos de Trabalho e Serviços 1. Selecionar os produtos de trabalho a serem avaliados de acordo com o critério de amostragem, caso a amostragem seja utilizada. 2. Criar e manter critérios claramente estabelecidos para as avaliações de produtos de trabalho. A intenção desta subprática é fornecer critérios, com base nas necessidades de negócios, tais como: O que será avaliado durante a avaliação de um produto de trabalho Quando ou com que freqüência um produto de trabalho será avaliado Como a avaliação será conduzida Quem precisa ser envolvido na avaliação 3. Utilizar os critérios estabelecidos durante avaliações de produtos de trabalho. 4. Avaliar produtos de trabalho antes que sejam entregues ao cliente. 5. Avaliar produtos de trabalho em marcos definidos ao longo de seus desenvolvimentos. 6. Executar avaliações, in-progress3 ou incrementais, de produtos de trabalho e serviços em relação às descrições de processo, padrões e procedimentos. 7. Identificar cada não-conformidade encontrada durante as avaliações. 8. Identificar lições aprendidas que poderiam melhorar os processos para produtos e serviços futuros. SG 2 Fornecer uma Visão Objetiva SP 2.1 Comunicar e Garantir a Solução de Não-conformidades 1. Resolver cada não-conformidade com os membros apropriados da equipe, sempre que possível. 2. Documentar as não-conformidades que não puderem ser resolvidas no âmbito do projeto. 3. Escalar as não-conformidades que não podem ser resolvidas no âmbito do projeto para o nível de gerenciamento apropriado e definido para agir na solução de nãoconformidades. 4. Analisar as não-conformidades para ver se existe alguma tendência em relação à qualidade que pode ser identificada e tratada. 5. Garantir que os stackeholders relevantes estejam cientes dos resultados das avaliações e das tendência em relação à qualidade, em tempo hábil. Página 26 de 31

27 6. Revisar periodicamente as não-conformidades abertas e as tendências relativas a elas com o gerente definido para agir na solução de não-conformidades. 7. Rastrear as não-conformidades até sua resolução. SP 2.2 Estabelecer Registros 1. Registrar as atividades de garantia da qualidade do processo e do produto com detalhes suficientes para que tanto seus estados quanto seus resultados sejam conhecidos. 2. Revisar o status e o histórico das atividades de garantia da qualidade, sempre que necessário Área de Processo Gestão de Configuração SG 1 Estabelecer Baselines SP 1.1 Identificar itens de Configuração 1. Selecionar os itens de configuração e os produtos de trabalho que os compõem baseado em critérios documentados. 2. Atribuir identificadores únicos para os itens de configuração. 3. Especificar as características importantes de cada item de configuração. Exemplos de características de itens de configuração incluem o autor, o tipo de arquivo ou documento e a linguagem de programação para os arquivos de código de software. 4. Especificar quando cada item de configuração será colocado sob gestão de configuração. 5. Identificar o responsável para cada item de configuração. SP 1.2 Estabelecer um Sistema de Gestão de Configurações 1. Estabelecer um mecanismo para gerenciar diversos níveis de controle de gestão de configuração. 2. Armazenar e recuperar itens de configuração em um sistema de gestão de configuração. 3. Compartilhar e transferir itens de configuração entre níveis de controle dentro do sistema de gestão de configuração. 4. Armazenar e recuperar versões arquivadas de itens de configuração. 5. Armazenar, atualizar e recuperar registros de gestão de configuração. 6. Criar relatórios de gestão de configuração a partir do sistema de gestão de configuração. 7. Proteger o conteúdo do sistema de gestão de configuração. 8. Revisar a estrutura de gestão de configuração, quando necessário. SP 1.3 Criar ou Liberar Baselines Página 27 de 31

28 1. Obter autorização do Conselho de Configuração - CoC antes de criar ou liberar baselines de itens de configuração. 2. Criar ou liberar baselines somente a partir de itens de configuração armazenados no sistema de gestão de configuração. 3. Documentar o conjunto de itens de configuração que estão contidos em uma baseline. 4. Tornar o conjunto atual de baselines prontamente disponível. SG 2 Rastrear e Controlar Alterações SP 2.1 Rastrear Solicitações de Alteração 1. Iniciar e registrar as solicitações de alteração na base de dados de solicitações de alteração. 2. Analisar o impacto das alterações e das correções propostas nas solicitações de alteração. 3. Revisar as solicitações de alteração que serão tratadas na próxima baseline com os stakeholders relevantes e obter os seus acordos. 4. Rastrear os estado das solicitações de alteração até sua conclusão. SP 2.2 Controlar Itens de Configuração 1. Controlar alterações nos itens de configuração durante toda a vida do produto. 2. Obter a autorização apropriada antes que itens de configuração alterados entrem no sistema de gestão de configuração. 3. Retirar (check out) e colocar (check in) itens de configuração no sistema de gestão de configuração, para incorporar as alterações, de uma maneira que mantenha a correção e a integridade dos itens de configuração. 4. Executar revisões para assegurar que as alterações não causaram efeitos indesejáveis nas baselines (por exemplo, assegurar que as alterações não comprometeram a segurança ou segurança de acesso do sistema). 5. Registrar as alterações nos itens SG 3 Estabelecer Integridade SP 3.1 Estabelecer Registros de Gestão de Configuração 1. Registrar ações de gestão de configuração com detalhes suficientes, de forma que o conteúdo e estado de cada item de configuração seja conhecido e que versões anteriores possam ser recuperadas. 2. Assegurar que os stackeholders relevantes tenham acesso e conhecimento do estado dos itens de configuração. Página 28 de 31

29 4. Identificar a versão dos itens de configuração que constituem uma baseline específica. 5. Descrever as diferenças entre baselines sucessivas. 6. Revisar o estado e o histórico (isto é, alterações e outras ações) de cada item de configuração, quando necessário. SP 3.2 Executar Auditorias de Configuração 1. Avaliar a integridade de baselines. 2. Confirmar se os registros de gestão de configuração identificam corretamente a configuração dos itens de configuração. 3. Revisar a estrutura e a integridade dos itens no sistema de gestão de configuração. 4. Confirmar a completitude e correção dos itens no sistema de gestão de configuração. A completitude e correção do conteúdo são baseadas nos requisitos conforme declarados no plano e nas decisões de solicitações de alteração aprovadas. 5. Confirmar a conformidade com padrões e procedimentos de gestão de configuração aplicáveis. 6. Rastrear os itens de ação da auditoria até sua conclusão Área de Processo Gestão de Risco SG 1 Preparar para a Gestão de Risco SP 1.1 Determinar Fontes e Categorias de Risco 1. Determinar fontes de riscos. 2. Determinar categorias de riscos. SP 1.2 Definir Parâmetros de Riscos 1. Definir critérios consistentes para avaliar e quantificar probabilidade de riscos e níveis de severidade. 2. Definir limiares para cada categoria de risco. 3. Definir limites na extensão para os quais os limiares são aplicados em relação a uma categoria ou dentro dela. SP 1.3 Estabelecer uma Estratégia para a Gestão de Risco 1. Definir critérios consistentes para avaliar e quantificar probabilidade de riscos e níveis de severidade. SG 2 Identificar e Analisar Riscos SP 2.1 Identificar Riscos Página 29 de 31

30 1. Identificar os riscos associados a custo, cronograma e desempenho em todas as fases cabíveis do ciclo de vida do produto. 2. Revisar os elementos ambientais que podem impactar o projeto. 3. Revisar todos os elementos da estrutura de decomposição de trabalho (WBS) como parte da identificação de riscos para ajudar a garantir que todos os aspectos do esforço de trabalho foram considerados. 4. Revisar todos os elementos do plano de projeto como parte da identificação de riscos para ajudar a garantir que todos os aspectos do projeto foram considerados. 5. Documentar o contexto, as condições e as potenciais conseqüências dos riscos. 6. Identificar os stackeholders relevantes associadas a cada risco. SP 2.2 Avaliar, Categorizar e Priorizar Riscos SG 3 Mitigar Riscos 1. Avaliar os riscos identificados a partir dos parâmetros de risco definidos. 2. Categorizar e agrupar os riscos de acordo com as categorias de riscos definidas. 3. Priorizar os riscos para mitigação. SP 3.1 Elaborar Planos de Mitigação de Riscos 1. Determinar os níveis e limiares que definem quando um risco se torna inaceitável e dispara a execução de um plano de mitigação de riscos ou um plano de contingência. O nível de risco (derivado a partir de um modelo de risco) é uma medida que combina a incerteza de alcançar um objetivo com as conseqüências de se falhar na satisfação de um objetivo. 2. Identificar a pessoa ou equipe responsável pelo tratamento dos riscos. 3. Determinar a razão custo-benefício de se implementar o plano de mitigação de riscos para cada risco. 4. Elaborar um plano geral de mitigação de riscos para que o projeto coordene a implementação de planos individuais de mitigação e de contingência. 5. Elaborar um plano de contingência para os riscos críticos selecionados no caso em que seus impactos são conhecidos. SP 3.2 Implementar planos de mitigação de riscos 1. Monitorar a situação dos riscos. 2. Fornecer um método para acompanhamento de itens de ação de tratamento de risco abertos até a conclusão. 3. Lançar mão das opções de tratamento de riscos selecionadas quando os riscos monitorados ultrapassarem os limiares definidos. 4. Estabelecer um cronograma ou período de desempenho para cada atividade de Página 30 de 31

31 tratamento de risco que inclua a data de início e a data antecipada de conclusão. 5. fornecer compromisso continuado de recursos para cada plano, possibilitando a execução bem sucedida das atividades de tratamento de riscos. 6. Coletar medidas de desempenho das atividades de tratamento de riscos. Página 31 de 31