CMMI - Guia Rápido
A melhoria do processo é a melhoria contínua. Nunca podemos alcançar a perfeição. Neste tutorial, aprenderemos o CMM que é um modelo em constante evolução e aprimoramento, onde o foco está sempre em fazer melhor. Nosso alcance deve sempre exceder nosso alcance.
O que é CMM?
CMM significa Capability Mmaturidade Model.
Concentra-se em elementos de práticas e processos essenciais de vários corpos de conhecimento.
Descreve maneiras comprovadas, eficientes e de bom senso de fazer negócios (o que você já deveria estar fazendo) - não uma abordagem nova e radical.
CMM é um método para avaliar e medir a maturidade do processo de desenvolvimento de software de uma organização.
O CMM mede a maturidade do processo de desenvolvimento de software em uma escala de 1 a 5.
O CMM v1.0 foi desenvolvido pelo Software Engineering Institute (SEI) da Carnegie Mellon University em Pittsburgh, EUA.
CMM foi originalmente desenvolvido para Desenvolvimento e Manutenção de Software, mas depois foi desenvolvido para -
Engenharia de sistemas
Fornecimento de fornecedores
Desenvolvimento Integrado de Produto e Processo
Pessoas CMM
Aquisição de software
Exemplos CMM
Pessoas CMM - Desenvolver, motivar e reter talentos em projetos.
Software CMM - aprimora a capacidade de desenvolvimento e manutenção focada em software.
O que é maturidade?
As definições variam, mas geralmente se pensa que os processos maduros são -
Well-defined,
Repeatable,
Measured,
Analyzed,
Melhorado, e
Effective.
Processos ruins, mas maduros, são tão ruins quanto nenhuma maturidade!
O CMM ajuda a resolver o problema de maturidade definindo um conjunto de práticas e fornecendo uma estrutura geral para melhorá-las. O foco do CMM está na identificação de áreas-chave de processo e nas práticas exemplares que podem compreender um processo de software disciplinado.
Organização imatura x organização madura
Uma organização imatura teria as seguintes características -
Processo improvisado durante o projeto
Processos aprovados sendo ignorados
Reativo, não proativo
Orçamento e cronograma irrealistas
Qualidade sacrificada pelo cronograma
Nenhuma medida objetiva de qualidade
Em contraste, as características de uma organização madura são as seguintes -
Comunicação e coordenação entre grupos
Trabalho realizado de acordo com o plano
Práticas consistentes com os processos
Processos atualizados conforme necessário
Funções / responsabilidades bem definidas
A administração se compromete formalmente
O que é CMMI?
O projeto de integração do CMM foi formado para resolver o problema de usar vários CMMs. A missão da equipe de produto CMMI era combinar trêsSource Modelsem uma única estrutura de melhoria para as organizações que buscam a melhoria de processos em toda a empresa. Esses três modelos de origem são -
Modelo de Maturidade de Capacidade para Software (SW-CMM) - v2.0 Rascunho C.
Padrão provisório da Electronic Industries Alliance (EIA / IS) - 731 Engenharia de Sistemas.
Modelo de maturidade da capacidade de desenvolvimento de produto integrado (IPD-CMM) v0.98.
CMM Integration
Constrói um conjunto inicial de modelos integrados.
Melhora as melhores práticas de modelos de origem com base nas lições aprendidas.
Estabelece uma estrutura para permitir a integração de modelos futuros.
Diferença entre CMM e CMMI
CMM é um modelo de referência de práticas amadurecidas em uma disciplina específica como Engenharia de Sistemas CMM, Software CMM, Pessoas CMM, Software Acquisition CMM etc., mas eram difíceis de integrar quando necessário.
O CMMI é o sucessor do CMM e evoluiu como um conjunto de diretrizes mais amadurecido e foi construído combinando os melhores componentes das disciplinas individuais do CMM (Software CMM, People CMM, etc.). Pode ser aplicado à fabricação de produtos, gestão de pessoas, desenvolvimento de software, etc.
CMM descreve sobre a engenharia de software sozinha, enquanto CMM Integrated descreve a engenharia de software e de sistema. O CMMI também incorpora o Processo Integrado e Desenvolvimento de Produto e o sourcing de fornecedores.
CMMI e objetivos de negócios
Os objetivos do CMMI são muito óbvios. Eles são os seguintes -
Produce quality products or services- O conceito de melhoria de processo nos modelos CMMI evoluiu do paradigma de qualidade Deming, Juran e Crosby: Produtos de qualidade são resultado de processos de qualidade. O CMMI tem um forte foco em atividades relacionadas à qualidade, incluindo gerenciamento de requisitos, garantia de qualidade, verificação e validação.
Create value for the stockholders- Organizações maduras são mais propensas a fazer melhores estimativas de custo e receita do que aquelas com menos maturidade e, então, ter um desempenho de acordo com essas estimativas. O CMMI oferece suporte a produtos de qualidade, cronogramas previsíveis e medição eficaz para apoiar o gerenciamento na realização de previsões precisas e defensáveis. Essa maturidade do processo pode proteger contra problemas de desempenho do projeto que podem enfraquecer o valor da organização aos olhos dos investidores.
Enhance customer satisfaction- Cumprir as metas de custo e cronograma com produtos de alta qualidade que são validados de acordo com as necessidades do cliente é uma boa fórmula para a satisfação do cliente. O CMMI aborda todos esses ingredientes por meio de sua ênfase no planejamento, monitoramento e medição, e a previsibilidade aprimorada que vem com processos mais capazes.
Increase market share- A participação no mercado é resultado de muitos fatores, incluindo produtos e serviços de qualidade, identificação do nome, preço e imagem. Os clientes gostam de lidar com fornecedores que têm reputação de cumprir seus compromissos.
Gain an industry-wide recognition for excellence- A melhor maneira de desenvolver uma reputação de excelência é consistentemente ter um bom desempenho nos projetos, entregando produtos e serviços de qualidade dentro dos parâmetros de custo e prazo. Ter processos em conformidade com os requisitos do CMMI pode melhorar essa reputação.
A Integração CMM é um modelo que integrou várias disciplinas / corpos de conhecimento. Atualmente, existem quatro corpos de conhecimento disponíveis para você ao selecionar um modelo CMMI.
Engenharia de sistemas
A engenharia de sistemas cobre o desenvolvimento de sistemas completos, que podem ou não incluir software. Os engenheiros de sistemas se concentram em transformar as necessidades, expectativas e restrições do cliente em soluções de produto e em apoiar essas soluções de produto durante todo o ciclo de vida do produto.
Engenharia de software
A engenharia de software cobre o desenvolvimento de sistemas de software. Os engenheiros de software se concentram na aplicação de abordagens sistemáticas, disciplinadas e quantificáveis para o desenvolvimento, operação e manutenção de software.
Desenvolvimento Integrado de Produto e Processo
O Desenvolvimento Integrado de Produto e Processo (IPPD) é uma abordagem sistemática que consegue uma colaboração oportuna das partes interessadas relevantes ao longo da vida do produto para melhor satisfazer as necessidades, expectativas e requisitos do cliente. Os processos de suporte a uma abordagem IPPD são integrados aos outros processos da organização.
Se um projeto ou organização escolher o IPPD, ele executa as melhores práticas do IPPD simultaneamente com outras melhores práticas usadas para produzir produtos (por exemplo, aquelas relacionadas à engenharia de sistemas). Ou seja, se uma organização ou projeto deseja usar o IPPD, deve selecionar uma ou mais disciplinas além do IPPD.
Fornecimento de fornecedores
Conforme os esforços de trabalho se tornam mais complexos, os gerentes de projeto podem usar fornecedores para executar funções ou adicionar modificações aos produtos que são especificamente necessários para o projeto. Quando essas atividades são críticas, o projeto se beneficia de uma análise aprimorada da fonte e do monitoramento das atividades do fornecedor antes da entrega do produto. Nessas circunstâncias, a disciplina de sourcing de fornecedores cobre a aquisição de produtos de fornecedores.
Semelhante às melhores práticas de IPPD, as melhores práticas de sourcing do fornecedor devem ser selecionadas em conjunto com as melhores práticas usadas para produzir produtos.
Seleção de Disciplina CMMI
Selecionar uma disciplina pode ser uma etapa difícil e depende do que a organização deseja melhorar.
Se você está melhorando seus processos de engenharia de sistemas, como Gerenciamento de Configuração, Medição e Análise, Foco no Processo Organizacional, Monitoramento e Controle de Projetos, Garantia de Qualidade de Processo e Produto, Gerenciamento de Risco, Gerenciamento de Contrato com Fornecedor, etc., então você deve selecionar Engenharia de Sistemas (SE) disciplina. As amplificações da disciplina para engenharia de sistemas recebem ênfase especial.
Se você estiver melhorando seus processos integrados de desenvolvimento de produtos e processos, como Equipes Integradas, Ambiente Organizacional para Integração, deverá selecionar IPPD. As ampliações disciplinares para IPPD recebem ênfase especial.
Se você estiver melhorando seus processos de seleção de fontes, como o Gerenciamento integrado de fornecedores, deverá selecionar Fornecimento de fornecedores (SS). As amplificações de disciplina para sourcing de fornecedores recebem ênfase especial.
Se você estiver aprimorando várias disciplinas, precisará trabalhar em todas as áreas relacionadas a essas disciplinas e prestar atenção a todas as amplificações de disciplina para essas disciplinas.
Discutiremos diferentes áreas relacionadas à implementação do CMMI nos capítulos subsequentes.
O CMMI está estruturado da seguinte forma -
- Níveis de maturidade (representação em estágios) ou níveis de capacidade (representação contínua)
- Áreas de Processo
- Objetivos: genéricos e específicos
- Características comuns
- Práticas: genéricas e específicas
Este capítulo irá discutir sobre duas representações CMMI e o resto dos assuntos serão cobertos em capítulos subsequentes.
Uma representação permite que uma organização busque objetivos de melhoria diferentes. Uma organização pode seguir um dos dois caminhos de melhoria a seguir.
Representação Encenada
A representação em estágios é a abordagem usada no Software CMM. É uma abordagem que usa conjuntos predefinidos de áreas de processo para definir um caminho de melhoria para uma organização. Este caminho de melhoria é descrito por um componente do modelo denominado Nível de Maturidade. Um nível de maturidade é um platô evolutivo bem definido para alcançar processos organizacionais aprimorados.
Representação encenada CMMI
Fornece uma sequência comprovada de melhorias, cada uma servindo como base para a próxima.
Permite comparações entre as organizações pelo uso de níveis de maturidade.
Fornece uma migração fácil de SW-CMM para CMMI.
Fornece uma única classificação que resume os resultados da avaliação e permite comparações entre as organizações.
Assim, a representação em estágios fornece um roteiro predefinido para a melhoria organizacional com base no agrupamento e ordenação comprovados de processos e relacionamentos organizacionais associados. Você não pode desviar da sequência de etapas.
Estrutura em estágio CMMI
A imagem a seguir ilustra a estrutura do modelo em estágio CMMI.
Representação Contínua
A representação contínua é a abordagem utilizada no SECM e no IPD-CMM. Essa abordagem permite que uma organização selecione uma área de processo específica e faça melhorias com base nela. A representação contínua usa níveis de capacidade para caracterizar a melhoria em relação a uma área de processo individual.
Representação Contínua CMMI
Permite que você selecione a ordem de melhoria que melhor atende aos objetivos de negócios de sua organização e reduz as áreas de risco de sua organização.
Permite comparações entre as organizações em uma base de área de processo por área de processo.
Fornece uma migração fácil do EIA 731 (e outros modelos com uma representação contínua) para o CMMI.
Assim, a Representação Contínua fornece flexibilidade para as organizações escolherem os processos de melhoria, bem como a quantidade de melhoria necessária.
Estrutura Contínua CMMI
A imagem a seguir ilustra a Estrutura do Modelo Contínuo CMMI.
Representações Contínuas vs Estagiadas
Representação Contínua | Representação Encenada |
---|---|
As áreas de processo são organizadas por categorias de área de processo. |
As áreas de processo são organizadas por níveis de maturidade. |
A melhoria é medida usando níveis de capacidade. Os níveis de capacidade medem a maturidade de um processo específico em uma organização; varia de 0 a 5. |
A melhoria é medida usando níveis de maturidade. Os níveis de maturidade medem a maturidade de um conjunto de processos em uma organização: varia de 1 a 5. |
Existem dois tipos de práticas específicas: básicas e avançadas. Todas as práticas específicas aparecem na representação contínua. |
Existe apenas um tipo de prática específica. Os conceitos de práticas básicas e avançadas não são usados. Todas as práticas específicas aparecem na representação encenada, exceto quando um par de práticas relacionadas base-avançada aparece na representação contínua, caso em que apenas a prática avançada aparece na representação encenada. |
Os níveis de capacidade são usados para organizar as práticas genéricas. |
Recursos comuns são usados para organizar práticas genéricas. |
Todas as práticas genéricas estão incluídas em cada área de processo. |
Apenas as práticas genéricas de nível 2 e nível 3 são incluídas. |
O teste equivalente permite a determinação de um nível de maturidade a partir do perfil de realização de uma organização. |
Não há necessidade de um mecanismo de equivalência para apoiar a representação contínua, porque cada organização pode escolher o que melhorar e quanto melhorar usando a representação em estágios. |
Qual representação é melhor?
Cada representação tem suas vantagens sobre a outra, algumas organizações usam ambas as representações para atender a requisitos específicos em vários momentos em seus programas de melhoria.
A maturidade organizacional é o foco da representação em estágios, enquanto a capacidade da área de processo é o foco da representação contínua.
Maturidade organizacional e capacidade da área de processo são conceitos semelhantes. A diferença entre eles é que a maturidade organizacional pertence a um conjunto de áreas de processo em uma organização, enquanto a capacidade da área de processo lida com um conjunto de processos relacionados a uma única área de processo ou prática específica.
O diagrama a seguir descreve ambas as apresentações. Neste diagrama,ML indica o nível de maturidade e PA Indica a área de processo.
Um nível de maturidade é um platô evolutivo bem definido para alcançar um processo de software maduro. Cada nível de maturidade fornece uma camada na base para a melhoria contínua do processo.
Os modelos CMMI com representação em estágios têm cinco níveis de maturidade designados pelos números de 1 a 5. Eles são -
- Initial
- Managed
- Defined
- Gerenciado Quantitativamente
- Optimizing
Níveis de maturidade de representação escalonada CMMI
A imagem a seguir mostra os níveis de maturidade em uma representação encenada CMMI.
Agora aprenderemos os detalhes de cada nível de maturidade. A próxima seção listará todas as áreas de processo relacionadas a esses níveis de maturidade.
Detalhes do nível de maturidade
Os níveis de maturidade consistem em um conjunto predefinido de áreas de processo. Os níveis de maturidade são medidos pelo alcance dospecific e generic goalsque se aplicam a cada conjunto predefinido de áreas de processo. As seções a seguir descrevem as características de cada nível de maturidade em detalhes.
Nível de maturidade 1 inicial
No nível de maturidade 1, os processos são geralmente ad hoc e caóticos. A organização geralmente não oferece um ambiente estável. O sucesso nessas organizações depende da competência e heroísmo das pessoas da organização e não do uso de processos comprovados.
As organizações de nível 1 de maturidade geralmente produzem produtos e serviços que funcionam; entretanto, freqüentemente excedem o orçamento e o cronograma de seus projetos.
As organizações de nível 1 de maturidade são caracterizadas por uma tendência de se comprometer demais, abandonar processos em tempos de crise e não ser capaz de repetir seus sucessos anteriores.
Nível de maturidade 2 gerenciado
No nível de maturidade 2, uma organização atingiu todos os specific e generic goalsdas áreas de processo do nível de maturidade 2. Em outras palavras, os projetos da organização garantem que os requisitos sejam gerenciados e que os processos sejam planejados, executados, medidos e controlados.
A disciplina de processo refletida pelo nível de maturidade 2 ajuda a garantir que as práticas existentes sejam mantidas em momentos de estresse. Quando essas práticas estão em vigor, os projetos são executados e gerenciados de acordo com seus planos documentados.
No nível de maturidade 2, requisitos, processos, produtos de trabalho e serviços são gerenciados. O status dos produtos de trabalho e a entrega dos serviços são visíveis para a gestão em pontos definidos.
Compromissos são estabelecidos entre as partes interessadas relevantes e são revisados conforme necessário. Os produtos de trabalho são revisados com as partes interessadas e são controlados.
Os produtos e serviços de trabalho satisfazem seus requisitos, padrões e objetivos especificados.
Nível de maturidade 3 definido
No nível de maturidade 3, uma organização atingiu todos os specific e generic goals das áreas de processo atribuídas aos níveis de maturidade 2 e 3.
No nível de maturidade 3, os processos são bem caracterizados e compreendidos e são descritos em padrões, procedimentos, ferramentas e métodos.
Uma distinção crítica entre o nível de maturidade 2 e o nível de maturidade 3 é o escopo dos 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 específica 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 ajustados a partir do conjunto de processos padrão da organização para se adequar a um determinado projeto ou unidade organizacional. O conjunto de processos padrão da organização inclui os processos tratados no nível de maturidade 2 e nível de maturidade 3. Como resultado, os processos executados em toda a organização são consistentes, exceto pelas diferenças permitidas pelas diretrizes de adaptação.
Outra distinção crítica é que no nível de maturidade 3, os processos são normalmente descritos com mais detalhes e mais rigor do que no nível de maturidade 2. No nível de maturidade 3, os processos são gerenciados de forma mais proativa usando um entendimento das inter-relações das atividades do processo e medidas detalhadas de o processo, seus produtos de trabalho e seus serviços.
Nível de maturidade 4 gerenciado quantitativamente
No nível de maturidade 4, uma organização atingiu todos os specific goals das áreas de processo atribuídas aos níveis de maturidade 2, 3 e 4 e o generic goals atribuído aos níveis de maturidade 2 e 3.
No nível de maturidade 4, são selecionados subprocessos que contribuem significativamente para o desempenho geral do processo. Esses subprocessos selecionados são controlados por meio de técnicas estatísticas e outras técnicas quantitativas.
Objetivos quantitativos de qualidade e desempenho do processo são estabelecidos e usados como critérios na gestão dos processos. Os objetivos quantitativos são baseados nas necessidades do cliente, usuários finais, organização e implementadores de processo. A qualidade e o desempenho do processo são entendidos em termos estatísticos e gerenciados ao longo da vida dos processos.
Para esses processos, medidas detalhadas de desempenho do processo são coletadas e analisadas estatisticamente. As causas especiais de variação do processo são identificadas e, quando apropriado, as fontes das causas especiais são corrigidas para evitar ocorrências futuras.
As medidas de desempenho de qualidade e processo são incorporadas ao repositório de medições da organização para apoiar a tomada de decisão baseada em fatos no futuro.
Uma distinção crítica entre o nível de maturidade 3 e o nível de maturidade 4 é a previsibilidade do desempenho do processo. No nível de maturidade 4, o desempenho dos processos é controlado por meio de técnicas estatísticas e outras técnicas quantitativas, e é previsível quantitativamente. No nível de maturidade 3, os processos são previsíveis apenas qualitativamente.
Otimização de nível de maturidade 5
No nível de maturidade 5, uma organização atingiu todos os specific goalsdas áreas de processo atribuídas aos níveis de maturidade 2, 3, 4 e 5 e o generic goals atribuído aos níveis de maturidade 2 e 3.
Os processos são continuamente aprimorados com base em uma compreensão quantitativa das causas comuns de variação inerentes aos processos.
Este nível se concentra na melhoria contínua do desempenho do processo por meio 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 os objetivos de negócios em mudança e usados como critérios no gerenciamento de melhoria de processos.
Os efeitos das melhorias de processo implantadas são medidos e avaliados em relação aos objetivos quantitativos de melhoria de processo. Tanto os processos definidos quanto o conjunto de processos padrão da organização são alvos de atividades de melhoria mensuráveis.
A otimização de processos ágeis e inovadores, depende da participação de uma força de trabalho capacitada e alinhada aos valores de negócio e objetivos da organização. A capacidade da organização de responder rapidamente a mudanças e oportunidades é aprimorada com a descoberta de maneiras de acelerar e compartilhar o aprendizado. A melhoria dos processos é inerentemente uma função que todos devem desempenhar, resultando em um ciclo de melhoria contínua.
Uma distinção crítica entre o nível de maturidade 4 e o nível de maturidade 5 é o tipo de variação de processo abordada. No nível de maturidade 4, os processos estão preocupados em abordar as causas especiais de variação do processo e fornecer previsibilidade estatística dos resultados. Embora os processos possam produzir resultados previsíveis, os resultados podem ser insuficientes para atingir os objetivos estabelecidos. No nível de maturidade 5, os processos estão preocupados em abordar as causas comuns de variação do processo e alterar o processo (ou seja, mudar os meios de desempenho do processo) para melhorar o desempenho do processo (mantendo a previsibilidade estatística) para atingir os objetivos quantitativos de melhoria de processo estabelecidos .
Os níveis de maturidade não devem ser ignorados
Cada nível de maturidade fornece uma base necessária para a implementação eficaz de processos no próximo nível.
Os processos de nível superior têm menos chance de sucesso sem a disciplina fornecida pelos níveis inferiores.
O efeito da inovação pode ser obscurecido em um processo ruidoso.
Processos com níveis de maturidade mais altos podem ser executados por organizações com níveis de maturidade mais baixos, com o risco de não serem aplicados de forma consistente em uma crise.
Níveis de maturidade e áreas de processo
Aqui está uma lista de todas as áreas de processo correspondentes definidas para uma organização de software. Essas áreas de processo podem ser diferentes para diferentes organizações.
Esta seção fornece os nomes das áreas de processo relacionadas. Para obter mais detalhes sobre essas áreas de processo, consulte o capítulo Áreas de processo do CMMI.
Nível | Foco | Área de Processo Chave | Resultado |
---|---|---|---|
5 Otimizando |
Melhoria Contínua de Processos | Inovação Organizacional e Implantação Análise e Resolução Causal |
Mais alta qualidade / menor risco |
4 Gerenciado Quantitativamente |
Gerenciado Quantitativamente | Desempenho de processos organizacionais Gestão Quantitativa de Projetos |
Maior qualidade / menor risco |
3 Definiram |
Padronização de processos | Desenvolvimento de Requisitos Solução técnica Integração de Produto Verificação Validação Foco no Processo Organizacional Definição de Processo Organizacional Treinamento Organizacional Gerenciamento de projeto integrado (com extras de IPPD) Gerenciamento de riscos Análise e Resolução de Decisão Equipe Integrada (apenas IPPD) Org. Ambiente para integração (apenas IPPD) Gestão Integrada de Fornecedores (somente SS) |
Qualidade média / risco médio |
2 Gerenciou |
Gestão Básica de Projetos | Gerenciamento de Requisitos Planejamento de Projeto Monitoramento e Controle do Projeto Gestão do Contrato do Fornecedor Medição e Análise Garantia de Qualidade de Processo e Produto Gerenciamento de configurações |
Baixa qualidade / alto risco |
1 Inicial |
O processo é informal e Adhoc | Menor qualidade / maior risco |
Um nível de capacidade é um platô evolutivo bem definido que descreve a capacidade da organização em relação a uma área de processo. Um nível de capacidade consiste em práticas específicas e genéricas relacionadas para uma área de processo que podem melhorar os processos da organização associados a essa área de processo. Cada nível é uma camada na base para a melhoria contínua do processo.
Assim, os níveis de capacidade são cumulativos, ou seja, um nível de capacidade superior inclui os atributos dos níveis inferiores.
Em modelos CMMI com uma representação contínua, existem seis níveis de capacidade designados pelos números de 0 a 5.
- 0 - Incompleto
- 1 - realizado
- 2 - Gerenciado
- 3 - Definido
- 4 - Gerenciado Quantitativamente
- 5 - Otimizando
Uma breve descrição de cada nível de capacidade é a seguinte -
Nível de capacidade 0: Incompleto
Um "processo incompleto" é um processo que não é executado ou parcialmente executado. Uma ou mais das metas específicas da área de processo não são satisfeitas e não existem metas genéricas para este nível, uma vez que não há razão para institucionalizar um processo parcialmente executado.
Isso equivale ao Nível de Maturidade 1 na representação encenada.
Nível de capacidade 1: realizado
Um processo de Nível 1 de Capacidade é um processo que deve realizar todas as práticas específicas e genéricas do Nível 1 de Capacidade. O desempenho pode não ser estável e pode não atender a objetivos específicos, como qualidade, custo e cronograma, mas um trabalho útil pode ser realizado. Este é apenas um começo, ou passo de bebê, na melhoria do processo. Significa que você está fazendo algo, mas não pode provar que realmente está funcionando para você.
Nível de capacidade 2: gerenciado
Um processo gerenciado é planejado, executado, monitorado e controlado para projetos individuais, grupos ou processos autônomos para atingir um determinado propósito. O gerenciamento do processo atinge os objetivos do modelo para o processo e também outros objetivos, como custo, cronograma e qualidade. Como o título deste nível indica, você está gerenciando ativamente a maneira como as coisas são feitas em sua organização. Você tem algumas métricas que são coletadas de forma consistente e aplicadas à sua abordagem de gerenciamento.
Note- as métricas são coletadas e usadas em todos os níveis do CMMI, tanto nas representações em estágios quanto nas contínuas. É uma falácia amarga pensar que uma organização pode esperar até o nível de capacidade 4 para usar as métricas.
Nível de capacidade 3: definido
Um processo de nível 3 de capacidade é caracterizado como um "processo definido". Um processo definido é um processo gerenciado (nível de capacidade 2) que é adaptado a partir do conjunto de processos padrão da organização de acordo com as diretrizes de adaptação da organização e contribui com produtos de trabalho, medidas e outras informações de melhoria de processo para os ativos de processos organizacionais.
Nível de Capacidade 4: Gerenciado Quantitativamente
Um processo de nível 4 de capacidade é caracterizado como um "processo gerenciado quantitativamente". Um processo gerenciado quantitativamente é um processo definido (nível de capacidade 3) que é controlado por meio de técnicas estatísticas e outras técnicas quantitativas. Os objetivos quantitativos de qualidade e desempenho do processo são estabelecidos e usados como critérios na gestão do processo. A qualidade e o desempenho do processo são entendidos em termos estatísticos e gerenciados ao longo da vida do processo.
Nível de capacidade 5: Otimizando
Um processo de otimização é um processo gerenciado quantitativamente que é aprimorado, com base no entendimento das causas comuns de variação do processo inerentes ao processo. Ele se concentra na melhoria contínua do desempenho do processo por meio de melhorias incrementais e inovadoras. Tanto os processos definidos quanto o conjunto de processos padrão da organização são os alvos das atividades de melhoria.
O Nível 4 de capacidade se concentra no estabelecimento de linhas de base, modelos e medidas para o desempenho do processo. O Nível de Capacidade 5 se concentra em estudar os resultados de desempenho em toda a organização ou em toda a empresa, encontrando causas comuns de problemas em como o trabalho é feito (o processo [s] usado) e corrigindo os problemas no processo. A correção incluiria a atualização da documentação do processo e o treinamento envolvido onde os erros foram injetados.
Organização de Áreas de Processo em Representação Contínua
Categoria | Área de Processo |
---|---|
Gerenciamento de Projetos |
|
Apoio, suporte |
|
Engenharia |
|
Gerenciamento de processos |
|
Uma Área de Processo é um agrupamento de práticas relacionadas em uma área que, quando implementadas coletivamente, atendem a um conjunto de objetivos considerados importantes para fazer melhorias significativas nessa área. Todas as áreas de processo CMMI são comuns às representações contínuas e em estágios.
A representação contínua permite que a organização escolha o foco de seus esforços de melhoria de processos, escolhendo aquelas áreas de processo, ou conjuntos de áreas de processo inter-relacionadas, que melhor beneficiam a organização e seus objetivos de negócios. Embora existam alguns limites sobre o que uma organização pode escolher devido às dependências entre as áreas de processo, a organização tem uma liberdade considerável em sua seleção.
Depois de selecionar as áreas de processo, você também deve selecionar o quanto gostaria de melhorar os processos associados a essas áreas de processo (ou seja, selecionar o nível de capacidade apropriado). Os níveis de capacidade e as metas e práticas genéricas apoiam a melhoria dos processos em áreas de processos individuais.
Por outro lado, você verá que a representação em estágios o incentiva a sempre olhar para as áreas de processo no contexto do nível de maturidade ao qual pertencem. As áreas de processo são organizadas por níveis de maturidade para reforçar esse conceito. Ao usar uma área de processo, você usa toda a área de processo, ou seja, todos os objetivos e todas as práticas.
As áreas de processo (PAs) CMMI podem ser agrupadas nas quatro categorias a seguir para entender suas interações e ligações entre si, independentemente de seus níveis definidos:
Gerenciamento de processos
Gerenciamento de Projetos
Engineering
Support
Cada área de processo é definida por um conjunto de objetivos e práticas. Existem duas categorias de objetivos e práticas -
Generic goals and practices - Eles fazem parte de todas as áreas de processo.
Specific goals and practices - São específicos para uma determinada área de processo.
Uma área de processo é satisfeita quando os processos de uma empresa cobrem todas as metas e práticas genéricas e específicas para aquela área de processo.
Metas e práticas genéricas
Metas e práticas genéricas fazem parte de todas as áreas de processo.
NOTATIONS - GG -> Metas Genéricas e GP -> Prática Genérica
GG 1 Atingir Metas Específicas
GP 1.1 Realizar 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 as partes interessadas relevantes
GP 2.8 Monitorar e controlar o processo
GP 2.9 Avaliar Objetivamente a Adesão
GP 2.10 Status de revisão com gerenciamento de nível superior
GG 3 Institucionalizar um Processo Definido
GP 3.1 Estabelecer um Processo Definido
GP 3.2 Colete Informações de Melhoria
GG 4 Institucionalizar um Processo Gerenciado Quantitativamente
GP 4.1 Estabelecer objetivos quantitativos para o processo
GP 4.2 Estabilizar o desempenho do subprocesso
GG 5 Institucionalizar um Processo de Otimização
GP 5.1 Garantir a melhoria contínua do processo
GP 5.2 Causas raízes corretas dos problemas
Características comuns
As características comuns são atributos que indicam se a implementação e institucionalização de uma área-chave de processo é eficaz, repetível e duradoura. Os cinco recursos comuns estão listados abaixo -
Commitment to Perform- O Compromisso de Executar descreve as ações que a organização deve realizar para garantir que o processo seja estabelecido e perdure. O compromisso com o desempenho normalmente envolve o estabelecimento de políticas organizacionais e o patrocínio da alta administração.
Ability to Perform- Capacidade de desempenho descreve as pré-condições que devem existir no projeto ou organização para implementar o processo de software com competência. Capacidade de desempenho normalmente envolve recursos, estruturas organizacionais e treinamento.
Activities Performed- Atividades realizadas descreve as funções e procedimentos necessários para implementar uma área-chave de processo. As atividades executadas geralmente envolvem o estabelecimento de planos e procedimentos, a execução do trabalho, o acompanhamento e a adoção de ações corretivas conforme necessário.
Measurement and Analysis- Medição e análise descreve a necessidade de medir o processo e analisar as medições. Medição e análise normalmente incluem exemplos das medidas que podem ser tomadas para determinar o status e a eficácia das atividades realizadas.
Verifying Implementation- Verificação da Implementação descreve as etapas para garantir que as atividades sejam realizadas em conformidade com o processo estabelecido. A verificação normalmente engloba revisões e auditorias por gerenciamento e garantia de qualidade de software.
As práticas na característica comum Atividades Executadas descrevem o que deve ser implementado para estabelecer uma capacidade de processo. As demais práticas, tomadas em conjunto, formam a base pela qual uma organização pode institucionalizar as práticas descritas na característica comum das Atividades Realizadas.
Áreas de Processo em Detalhe
O CMMI contém 22 áreas de processo que indicam os aspectos de desenvolvimento de produto que devem ser cobertos pelos processos da empresa.
Análise e Resolução Causal
É uma área de processo de suporte no nível de maturidade 5.
Objetivo
O propósito de Causal Analysis and Resolution (CAR) é identificar as causas dos defeitos e outros problemas e tomar medidas para evitar que ocorram no futuro.
Práticas Específicas por Meta
SG 1 Determinar as causas dos defeitos
SP 1.1 Selecione Dados de Defeito para Análise
SP 1.2 Analisar Causas
Endereço SG 2 Causas de Defeitos
SP 2.1 Implementar as propostas de ação
SP 2.2 Avalie o efeito das mudanças
SP 2.3 Dados de registro
Gerenciamento de configurações
É uma área de processo de suporte no Nível de Maturidade 2.
Objetivo
O propósito de Configuration Management (CM) é estabelecer e manter a integridade dos produtos de trabalho usando identificação de configuração, controle de configuração, contabilidade de status de configuração e auditorias de configuração.
Specific Practices by Goal
SG 1 Estabelecer Baselines
SP 1.1 Identificar itens de configuração
SP 1.2 Estabelecer um Sistema de Gerenciamento de Configuração
SP 1.3 Criar ou liberar linhas de base
SG 2 Track and Control Changes
SP 2.1 Rastrear Solicitações de Mudança
Itens de configuração de controle SP 2.2
SG 3 Estabelece Integridade
SP 3.1 Estabelecer Registros de Gerenciamento de Configuração
SP 3.2 Realizar auditorias de configuração
Análise e Resolução de Decisão
É uma área de processo de suporte no Nível de Maturidade 3.
Objetivo
O propósito de Decision Analysis and Resolution (DAR) é analisar possíveis decisões usando um processo de avaliação formal que avalia as alternativas identificadas em relação aos critérios estabelecidos.
Práticas Específicas por Meta
SG 1 Avaliar Alternativas
SP 1.1 Estabelecer Diretrizes para Análise de Decisão
SP 1.2 Estabelecer Critérios de Avaliação
SP 1.3 Identificar soluções alternativas
SP 1.4 Selecionar métodos de avaliação
SP 1.5 Avaliar Alternativas
SP 1.6 Selecione Soluções
Gestão Integrada de Projetos + IPPD
É uma área de processo de Gerenciamento de Projetos no Nível de Maturidade 3.
Objetivo
O propósito de Integrated Project Management + IPPD (IPM) é estabelecer e gerenciar o projeto e o envolvimento das partes interessadas relevantes de acordo com um processo integrado e definido que é adaptado a partir do conjunto de processos padrão da organização.
Práticas Específicas por Meta
SG 1 Use o processo definido do projeto
SP 1.1 Estabelecer o Processo Definido do Projeto
SP 1.2 Usar Ativos de Processos Organizacionais para Planejar Atividades de Projeto
SP 1.3 Estabelecer o Ambiente de Trabalho do Projeto
SP 1.4 Integrar Planos
SP 1.5 Gerenciar o projeto usando os planos integrados
SP 1.6 Contribuir para os Ativos de Processos Organizacionais
SG 2 Coordenar e colaborar com as partes interessadas relevantes
SP 2.1 Gerenciar o envolvimento das partes interessadas
SP 2.2 Gerenciar Dependências
SP 2.3 Resolver Problemas de Coordenação
Adição IPPD -
SG 3 Aplicar Princípios IPPD
SP 3.1 Estabelecer a Visão Compartilhada do Projeto
SP 3.2 Estabelecer a Estrutura de Equipe Integrada
SP 3.3 Alocar Requisitos para Equipes Integradas
SP 3.4 Estabelecer Equipes Integradas
SP 3.5 Garanta a colaboração entre as equipes de interface
Medição e Análise
É uma área de processo de suporte no Nível de Maturidade 2.
Objetivo
O propósito de Measurement and Analysis (MA) é desenvolver e sustentar uma capacidade de medição que é usada para apoiar as necessidades de informação de gestão.
Práticas Específicas por Meta
SG 1 Alinhar atividades de medição e análise
SP 1.1 Estabelecer Objetivos de Medição
SP 1.2 Especificar Medidas
SP 1.3 Especificar procedimentos de coleta e armazenamento de dados
SP 1.4 Especificar Procedimentos de Análise
SG 2 fornece resultados de medição
SP 2.1 Colete Dados de Medição
SP 2.2 Analisar dados de medição
SP 2.3 Armazenar dados e resultados
SP 2.4 Comunicar resultados
Inovação Organizacional e Implantação
É uma área de processo de Gestão de Processos no Nível de Maturidade 5.
Objetivo
O propósito de Organizational Innovation and Deployment(OID) é selecionar e implantar melhorias incrementais e inovadoras que melhoram de forma mensurável os processos e tecnologias da organização. As melhorias apóiam os objetivos de qualidade e desempenho de processos da organização, conforme derivados dos objetivos de negócios da organização.
Práticas Específicas por Meta
SG 1 Selecione Melhorias
SP 1.1 Colete e analise propostas de melhoria
SP 1.2 Identificar e analisar inovações
SP 1.3 Melhorias do Piloto
SP 1.4 Selecione Melhorias para Implementação
SG 2 Implementar Melhorias
SP 2.1 Planejar as áreas de implantação
SP 2.2 Gerenciar a implantação
SP 2.3 Medir efeitos de melhoria
Definição de Processo Organizacional + IPPD (OPD)
É uma área de processo de Gestão de Processos no Nível de Maturidade 3.
Objetivo
O propósito de Organizational Process Definition + IPPD (OPD) é estabelecer e manter um conjunto utilizável de ativos de processos organizacionais.
Práticas Específicas por Meta
SG 1 Estabelecer Ativos de Processos Organizacionais
SP 1.1 Estabelecer Processos Padrão
SP 1.2 Estabelecer Descrições do Modelo de Ciclo de Vida
SP 1.3 Estabelecer Critérios e Diretrizes de Adaptação
SP 1.4 Estabelecer o Repositório de Medidas da Organização
SP 1.5 Estabelecer a Biblioteca de Ativos de Processos da Organização
Adição IPPD -
SG 2 Habilitar gerenciamento IPPD
SP 2.1 Estabelecer Mecanismos de Empoderamento
SP 2.2 Estabelecer Regras e Diretrizes para Equipes Integradas
SP 2.3 Responsabilidades da equipe de equilíbrio e da organização doméstica
Foco no Processo Organizacional
É uma área de processo de Gestão de Processos no Nível de Maturidade 3.
Objetivo
O propósito de Organizational Process Focus (FPO) é planejar e implementar a melhoria dos processos organizacionais com base em uma compreensão completa dos pontos fortes e fracos atuais dos processos e ativos de processos da organização.
Práticas Específicas por Meta
SG 1 Determine oportunidades de melhoria de processo
SP 1.1 Estabelecer Necessidades de Processos Organizacionais
SP 1.2 Avaliar os Processos da Organização
SP 1.3 Identificar as melhorias de processo da organização
SG 2 Planejar e implementar atividades de melhoria de processos
SP 2.1 Estabelecer Planos de Ação de Processo
SP 2.2 Implementar Planos de Ação de Processo
SG 3 Implantar Ativos de Processos Organizacionais e Incorporar Lições Aprendidas
SP 3.1 Implantar Ativos de Processos Organizacionais
SP 3.2 Implementar Processos Padrão
Implementação do monitor SP 3.3
SP 3.4 Incorporar Experiências Relacionadas ao Processo aos Ativos de Processos Organizacionais
Desempenho de processos organizacionais
É uma área de processo de Gestão de Processos no Nível de Maturidade 4.
Objetivo
O propósito de Organizational Process Performance (OPP) é estabelecer e manter uma compreensão quantitativa do desempenho do conjunto de processos padrão da organização em apoio aos objetivos de desempenho de qualidade e processo e fornecer os dados de desempenho do processo, linhas de base e modelos para gerenciar quantitativamente os projetos da organização.
Práticas Específicas por Meta
SG 1 Estabelece modelos e linhas de base de desempenho
SP 1.1 Selecionar processos
SP 1.2 Estabelecer Medidas de Desempenho de Processo
SP 1.3 Estabelecer Objetivos de Desempenho de Qualidade e Processo
SP 1.4 Estabelecer Bases de Desempenho de Processo
SP 1.5 Estabelecer Modelos de Desempenho de Processo
Treinamento Organizacional
É uma área de processo de Gestão de Processos no Nível de Maturidade 3.
Objetivo
O propósito de Organizational Training (OT) é desenvolver as habilidades e o conhecimento das pessoas para que possam desempenhar suas funções de forma eficaz e eficiente.
Práticas Específicas por Meta
SG 1 Estabeleça uma Capacidade de Treinamento Organizacional
SP 1.1 Estabelecer as Necessidades de Treinamento Estratégico
SP 1.2 Determinar quais necessidades de treinamento são de responsabilidade da organização
SP 1.3 Estabelecer um Plano Tático de Treinamento Organizacional
SP 1.4 Estabelecer Capacidade de Treinamento
SG 2 fornece treinamento necessário
SP 2.1 Oferecer Treinamento
SP 2.2 Estabelecer Registros de Treinamento
SP 2.3 Avalie a eficácia do treinamento
Integração de Produto
É uma área de processo de Engenharia no Nível 3 de Maturidade.
Objetivo
O propósito de Product Integration (PI) é montar o produto a partir dos componentes do produto, garantir que o produto, conforme integrado, funcione corretamente e entregue o produto.
Práticas Específicas por Meta
SG 1 Prepare-se para a integração do produto
SP 1.1 Determine a sequência de integração
SP 1.2 Estabelecer o Ambiente de Integração do Produto
SP 1.3 Estabelecer Procedimentos e Critérios de Integração de Produto
SG 2 garantir compatibilidade de interface
SP 2.1 Revisar as descrições da interface quanto à integridade
SP 2.2 Gerenciar Interfaces
SG 3 Montar componentes do produto e entregar o produto
SP 3.1 Confirme a Prontidão dos Componentes do Produto para Integração
SP 3.2 Montar componentes do produto
SP 3.3 Avalie os componentes do produto montados
SP 3.4 Empacotar e entregar o produto ou componente do produto
Monitoramento e Controle do Projeto
É uma área de processo de Gerenciamento de Projetos no Nível de Maturidade 2.
Objetivo
O propósito de Project Monitoring and Control (PMC) é fornecer uma compreensão do progresso do projeto para que as ações corretivas apropriadas possam ser tomadas quando o desempenho do projeto se desviar significativamente do plano.
Práticas Específicas por Meta
SG 1 Monitorar Projeto Contra o Plano
SP 1.1 Monitorar Parâmetros de Planejamento de Projeto
SP 1.2 Monitorar Compromissos
SP 1.3 Monitorar riscos do projeto
SP 1.4 Monitorar Gerenciamento de Dados
SP 1.5 Monitorar o envolvimento das partes interessadas
SP 1.6 Conduzir análises de progresso
SP 1.7 Conduzir análises de marcos
SG 2 Gerenciar Ação Corretiva para Fechamento
SP 2.1 Analisar Problemas
SP 2.2 Tome uma ação corretiva
SP 2.3 Gerenciar Ação Corretiva
Planejamento de Projeto
É uma área de processo de Gerenciamento de Projetos no Nível de Maturidade 2.
Objetivo
O propósito de Project Planning (PP) é estabelecer e manter planos que definam as atividades do projeto.
Práticas Específicas por Meta
SG 1 Estabeleça Estimativas
SP 1.1 Estimativa do Escopo do Projeto
SP 1.2 Estabelecer Estimativas de Produto de Trabalho e Atributos de Tarefa
SP 1.3 Definir o Ciclo de Vida do Projeto
SP 1.4 Determinar estimativas de esforço e custo
SG 2 Desenvolva um Plano de Projeto
SP 2.1 Estabelecer o Orçamento e Cronograma
SP 2.2 Identificar os riscos do projeto
SP 2.3 Plano para gerenciamento de dados
SP 2.4 Plano de Recursos do Projeto
SP 2.5 Plano de Conhecimento e Habilidades Necessárias
SP 2.6 Plano de Envolvimento das Partes Interessadas
SP 2.7 Estabelecer o Plano do Projeto
SG 3 Obtenha Compromisso com o Plano
SP 3.1 Revisão dos Planos que Afetam o Projeto
SP 3.2 Reconciliar Trabalho e Níveis de Recursos
SP 3.3 Obtenha o Compromisso do Plano
Garantia de Qualidade de Processo e Produto
É uma área de processo de suporte no Nível de Maturidade 2.
Objetivo
O propósito de Process and Product Quality Assurance (PPQA) é fornecer à equipe e à gerência uma visão objetiva dos processos e produtos de trabalho associados.
Práticas Específicas por Meta
SG 1 Avaliar Objetivamente Processos e Produtos de Trabalho
SP 1.1 Avaliar Objetivamente os Processos
SP 1.2 Avaliar Objetivamente Produtos e Serviços de Trabalho
SG 2 fornecer uma visão objetiva
SP 2.1 Comunicar e garantir a resolução de problemas de não conformidade
SP 2.2 Estabelecer Registros
Gestão Quantitativa de Projetos
É uma área de processo de Gerenciamento de Projetos no Nível de Maturidade 4.
Objetivo
O propósito do Quantitative Project Management (QPM) área de processo é gerenciar quantitativamente o processo definido do projeto para atingir os objetivos de qualidade e desempenho de processo estabelecidos do projeto.
Práticas Específicas por Meta
SG 1 Gerenciar Quantitativamente o Projeto
SP 1.1 Estabelecer os Objetivos do Projeto
SP 1.2 Compor os processos definidos
SP 1.3 Selecione os subprocessos que serão gerenciados estatisticamente
SP 1.4 Gerenciar o desempenho do projeto
SG 2 Gerenciar estatisticamente o desempenho do subprocesso
SP 2.1 Selecionar medidas e técnicas analíticas
SP 2.2 Aplicar métodos estatísticos para compreender a variação
SP 2.3 Monitorar o desempenho dos subprocessos selecionados
SP 2.4 Registro de dados de gerenciamento estatístico
Desenvolvimento de Requisitos
É uma área de processo de Engenharia no Nível 3 de Maturidade.
Objetivo
O propósito de Requirements Development (RD) é produzir e analisar os requisitos do cliente, do produto e dos componentes do produto.
Práticas Específicas por Meta
SG 1 Desenvolver requisitos do cliente
SP 1.1 Elicitar Necessidades
SP 1.2 Desenvolver os requisitos do cliente
SG 2 Desenvolver requisitos de produto
SP 2.1 Estabelecer Requisitos de Produto e Componente de Produto
SP 2.2 Alocar requisitos de componentes do produto
SP 2.3 Identificar requisitos de interface
SG 3 Analisar e validar requisitos
SP 3.1 Estabelecer Conceitos Operacionais e Cenários
SP 3.2 Estabelecer uma Definição de Funcionalidade Requerida
SP 3.3 Analisar Requisitos
SP 3.4 Analise os requisitos para alcançar o equilíbrio
SP 3.5 Validar Requisitos
Gerenciamento de Requisitos
É uma área de processo de Engenharia no Nível 2 de Maturidade.
Objetivo
O propósito de Requirements Management (REQM) é gerenciar os requisitos dos produtos e componentes do produto do projeto e identificar inconsistências entre esses requisitos e os planos e produtos de trabalho do projeto.
Práticas Específicas por Meta
SG 1 Gerenciar Requisitos
SP 1.1 Obtenha uma compreensão dos requisitos
SP 1.2 Obter Compromisso com os Requisitos
SP 1.3 Gerenciar Mudanças de Requisitos
SP 1.4 Manter a rastreabilidade bidirecional dos requisitos
SP 1.5 Identificar inconsistências entre o trabalho do projeto e os requisitos
Gerenciamento de riscos
É uma área de processo de Gerenciamento de Projetos no Nível de Maturidade 3.
Objetivo
O propósito de Risk Management (RSKM) é identificar problemas potenciais antes que eles ocorram para que as atividades de tratamento de risco possam ser planejadas e acionadas conforme necessário ao longo da vida do produto ou projeto para mitigar os impactos adversos no cumprimento dos objetivos.
Práticas Específicas por Meta
SG 1 Prepare-se para a gestão de risco
SP 1.1 Determinar fontes e categorias de risco
SP 1.2 Definir parâmetros de risco
SP 1.3 Estabelecer uma Estratégia de Gestão de Risco
SG 2 Identificar e Analisar Riscos
SP 2.1 Identifique os riscos
SP 2.2 Avaliar, categorizar e priorizar os riscos
SG 3 Mitigar Riscos
SP 3.1 Desenvolver Planos de Mitigação de Risco
SP 3.2 Implementar Planos de Mitigação de Risco
Gestão do Contrato do Fornecedor
É uma área de processo de Gerenciamento de Projetos no Nível de Maturidade 2.
Objetivo
O propósito de Supplier Agreement Management (SAM) é gerenciar a aquisição de produtos de fornecedores para os quais existe um acordo formal.
Práticas Específicas por Meta
SG 1 Estabelecer Contratos de Fornecedor M
SP 1.1 Determine o tipo de aquisição
SP 1.2 Selecionar fornecedores
SP 1.3 Estabelecer Contratos de Fornecedor
SG 2 satisfaz os acordos do fornecedor
SP 2.1 Executar o Contrato do Fornecedor
SP 2.2 Monitorar processos de fornecedores selecionados
SP 2.3 Avaliar produtos de trabalho do fornecedor selecionado
SP 2.4 Aceite o Produto Adquirido
Produtos de transição SP 2.5
Solução técnica
É uma área de processo de Engenharia no Nível 3 de Maturidade.
Objetivo
O propósito de Technical Solution(TS) é projetar, desenvolver e implementar soluções para requisitos. Soluções, projetos e implementações abrangem produtos, componentes de produtos e processos de ciclo de vida relacionados a produtos individualmente ou em combinação, conforme apropriado.
Práticas Específicas por Meta
SG 1 Selecione Soluções de Componentes de Produto
SP 1.1 Desenvolver Soluções Alternativas e Critérios de Seleção
SP 1.2 Selecione Soluções de Componentes do Produto
SG 2 Desenvolva o Design
SP 2.1 Projetar o produto ou componente do produto
SP 2.2 Estabelecer um Pacote de Dados Técnicos
SP 2.3 Design de interfaces usando critérios
SP 2.4 Realizar análise de fabricação, compra ou reutilização
SG 3 Implementar o Design do Produto
SP 3.1 Implementar o Design
SP 3.2 Desenvolver documentação de suporte ao produto
Validação
É uma área de processo de Engenharia no Nível 3 de Maturidade.
Objetivo
O propósito de Validation (VAL) é para demonstrar que um produto ou componente de produto cumpre o uso pretendido quando colocado no ambiente pretendido.
Práticas Específicas por Meta
SG 1 Preparar para validação
SP 1.1 Selecionar produtos para validação
SP 1.2 Estabelecer o ambiente de validação
SP 1.3 Estabelecer Procedimentos e Critérios de Validação
SG 2 Validar Produto ou Componentes do Produto
SP 2.1 Executar validação
SP 2.2 Analisar os resultados da validação.
Verificação
É uma área de processo de Engenharia no Nível 3 de Maturidade.
Objetivo
O propósito de Verification (VER) é para garantir que os produtos de trabalho selecionados atendam aos requisitos especificados.
Práticas Específicas por Meta
SG 1 Prepare-se para a verificação
SP 1.1 Selecione Produtos de Trabalho para Verificação
SP 1.2 Estabelecer o ambiente de verificação
SP 1.3 Estabelecer Procedimentos e Critérios de Verificação
SG 2 realizar revisões de pares
SP 2.1 Prepare-se para revisões por pares
SP 2.2 Conduzir avaliações por pares
SP 2.3 Analisar Dados de Revisão por Pares
SG 3 Verificar Produtos de Trabalho Selecionados
SP 3.1 Realizar Verificação
SP 3.2 Analisar resultados de verificação
Alterações feitas na versão 1.2
Apenas as alterações feitas no conjunto de áreas de processo são consideradas aqui. Para obter mais detalhes, visite a página inicial do SEI .
As seguintes áreas de processo foram removidas (todas no nível de maturidade 3) -
Ambiente Organizacional para Integração (OEI)
Equipe Integrada (TI)
Gestão Integrada de Fornecedores (ISM)
As seguintes adições foram feitas nas Áreas de Processo existentes -
IPM. SG3 e SG4 foram eliminados, novo SG3 foi adicionado (todos IPPD PAs)
OPD. SG foi adicionado, transformando-o em um IPPD PA
OPF. dois SPs foram extraídos do SG e criaram o SG3 junto com dois novos SPs
REQD. SP3.5 foi renomeado para Validar Requisitos
SAM. SP2.1 foi eliminado, dois novos SPs adicionados no SG2
TS. SP1.2 foi eliminado
VER. SP3.2 foi renomeado como Analisar Resultados da Verificação
A Avaliação CMMI é um exame de um ou mais processos por uma equipe treinada de profissionais usando um modelo de referência de avaliação como base para determinar os pontos fortes e fracos de uma organização.
As avaliações requerem planejamento. Ao planejar uma avaliação de sua organização, determine o escopo da unidade organizacional, quais disciplinas incluir, se a equipe de avaliação será composta por membros internos ou externos à sua organização, projetos a serem incluídos, indivíduos a serem entrevistados e o tipo de classe de avaliação necessária.
As avaliações consideram três categorias de componentes do modelo, conforme definido no CMMI -
Required - objetivos específicos e genéricos apenas.
Expected - práticas específicas e genéricas apenas.
Informative - inclui subpráticas e produtos de trabalho típicos.
O SEI lançou dois documentos orientadores para as avaliações CMMI -
Appraisal Requirements for CMMI (ARC) - Ele contém os requisitos para três classes de métodos de avaliação Classe A, Classe B e Classe C. Esses requisitos são as regras para definir cada classe de método de avaliação.
Standard CMMI Appraisal Method for Process Improvement (SCAMPI) - O Documento de Descrição do Método (MDD) é atualmente o único método de avaliação Classe A aprovado.
SCAMPI é atualmente o único método de avaliação CMMI Classe A aprovado. Ou seja, o SCAMPI atende a todos os requisitos de um Método de Avaliação ARC Classe A e foi aprovado pelo SEI.
Existem três classes de Métodos de Avaliação CMMI: Classe A, Classe B e Classe C.
Avaliação SCAMPI Classe A
Uma avaliação SCAMPI Classe A é normalmente conduzida quando uma organização implementou uma série de melhorias de processo significativas e precisa fazer um benchmark formal de seu processo em relação ao CMMI. A SCAMPI A é o único método de avaliação que fornece classificações de Nível de Maturidade CMMI ou Nível de Capacidade.
Você pode esperar os seguintes resultados de um SCAMPI A -
Uma classificação de nível de maturidade ou classificações de nível de capacidade.
Resultados que descrevem os pontos fortes e fracos do processo da sua organização em relação ao CMMI.
Consenso em relação às questões-chave do processo da organização.
Um banco de dados de avaliação que a organização pode continuar a usar para monitorar o progresso da melhoria do processo e dar suporte a avaliações futuras.
Avaliação SCAMPI Classe B
Um SCAMPI B é necessário quando uma organização precisa avaliar seu progresso em direção a um nível de maturidade CMMI alvo, mas a um custo menor do que um SCAMPI A. As avaliações do SCAMPI B fornecem descobertas detalhadas e indicam a probabilidade de que as práticas avaliadas sejam classificadas como satisfatoriamente implementado em uma avaliação SCAMPI A.
Uma avaliação SCAMPI Classe B, um dos três métodos de avaliação SEI, ajuda uma organização a compreender, com um grau relativamente alto de confiança, o status de seu processo de engenharia de software e sistemas em relação ao CMMI. Um SCAMPI B é frequentemente realizado quando uma organização precisa avaliar com precisão seu progresso em direção a um nível de maturidade CMMI alvo.
Você pode esperar os seguintes resultados de um SCAMPI B -
Descobertas detalhadas que descrevem os pontos fortes e fracos do processo de sua organização em relação ao CMMI.
Caracterizações de prática que indicam a probabilidade de que as práticas examinadas satisfaçam os objetivos e atendam à intenção do CMMI.
Consenso em relação às questões-chave do processo da organização.
Um banco de dados FIDO que a organização pode continuar a usar, para monitorar o progresso da melhoria do processo e para apoiar avaliações futuras.
Avaliação SCAMPI Classe C
As avaliações SCAMPI C são mais curtas e flexíveis do que as avaliações SCAMPI A e B e são realizadas para atender a uma variedade de necessidades especiais, desde uma rápida análise de lacunas até determinar a prontidão de uma organização para um SCAMPI A.
As avaliações SCAMPI Classe C, as menos formais do conjunto de métodos de avaliação do SEI, são altamente flexíveis e podem ser conduzidas para atender a uma variedade de necessidades. Normalmente muito mais curta em duração do que as avaliações de Classe A e B, as avaliações SCAMPI C são frequentemente realizadas por razões como -
Fornece uma rápida análise de lacunas do processo de uma organização em relação ao CMMI.
Avalie a adequação de um novo processo antes de sua implementação.
Monitore a implementação de um processo.
Determine a prontidão de uma organização para um SCAMPI A.
Apoie a seleção de um fornecedor.
Você pode esperar os seguintes resultados de um SCAMPI C -
Resultados que descrevem os pontos fortes e fracos dos processos avaliados. Dependendo do escopo e da estratégia da avaliação, as descobertas podem ser mapeadas para os componentes CMMI relevantes.
Caracterizações que sintetizam a adequação dos processos avaliados vis-à-vis o CMMI.
Ações de melhoria de processo recomendadas.
Um banco de dados FIDO que a organização pode continuar a usar para monitorar o progresso da melhoria do processo e para apoiar avaliações futuras.
Características da classe de avaliação
Cada classe se distingue pelo grau de rigor associado à aplicação do método. A Classe A é a mais rigorosa, a Classe B é um pouco menos rigorosa e a Classe C é a menos rigorosa. A tabela a seguir dá uma ideia das diferenças esperadas entre os métodos em cada classe.
Características | Classe A | Classe B | Classe C |
---|---|---|---|
Quantidade de evidências objetivas coletadas | Alto | Médio | Baixo |
Avaliação gerada | sim | Não | Não |
Necessidades de recursos | Alto | Médio | Baixo |
Tamanho da equipe | ampla | Médio | Pequeno |
Fontes de dados (instrumentos, entrevistas e documentos) | Requer todas as três fontes de dados | Requer apenas duas fontes de dados (uma deve ser entrevistas) | Requer apenas uma fonte de dados |
Requisito do líder da equipe de avaliação | Avaliador Líder Autorizado | Avaliador Líder Autorizado ou pessoa treinada e experiente | Pessoa treinada e experiente |
Fundamentos SCAMPI
SCAMPI é um acrônimo que significa Método de Avaliação Padrão CMMI para Melhoria de Processos. Uma avaliação SCAMPI deve ser conduzida por um Avaliador Líder SCAMPI autorizado pela SEI. SCAMPI é suportado pelo SCAMPI Product Suite, que inclui a descrição do método SCAMPI, questionário de maturidade, ajudas de trabalho e modelos.
Atualmente, o SCAMPI é o único método que pode fornecer uma classificação, o único método reconhecido pelo SEI e o método de maior interesse para as organizações.
SCAMPI é baseado na experiência de métodos anteriores, incluindo -
CBA IPI - Avaliação baseada em CMM para melhoria de processos internos.
SCE - Avaliação da capacidade do software.
EIA/IS 732.2 - O padrão internacional provisório intitulado Método de Avaliação de Engenharia de Sistemas.
SDCE - Avaliação da capacidade de desenvolvimento de software.
Método de avaliação FAA.
Este capítulo discute os principais participantes envolvidos em um esforço de melhoria de processo. No entanto, sua organização pode exigir mais ou menos grupos.
Observe que uma pessoa pode cumprir muitas dessas funções simultaneamente ou em série, dependendo do tamanho da sua organização e da complexidade do seu esforço de melhoria de processos (PI).
Melhoria de processos
Os esforços de melhoria de processos geralmente requerem os seguintes indivíduos e grupos -
PI Sponsor- A pessoa da organização responsável por supervisionar todo o esforço de PI. Essa pessoa geralmente tem o poder de alocar fundos e pessoal. Essa pessoa geralmente está no nível de diretoria ou acima.
PI Champion- Este é o responsável pelas relações públicas do esforço de PI, que pode ou não servir como líder de EPG. Essa pessoa comercializa a ideia, a abordagem e os resultados do IP.
Engineering Process Group (EPG) Lead- Essa pessoa lidera o grupo que analisa os processos. Essa pessoa atribui tarefas aos membros do EPG, monitora seus esforços e planeja as tarefas diárias do EPG.
EPG Members- Esses indivíduos atuam no EPG como membros do comitê. Eles são responsáveis por garantir que a documentação de melhoria do processo seja escrita e seguida. Eles também são responsáveis por gerar métricas para rastrear o processo de melhoria do processo. Eles lideram os PATs.
Process Action Teams (PATs) − These teams generate the process improvement documentation, policies, processes, procedures, charters, and Action Plans.
Transition Partner − Usually one or two individuals who are outside consultants brought in to help set up, plan, lead, and monitor progress in organizational process improvement. These individuals bring experience doing process improvement from several other organizations and industries.
This tutorial covered the Structure of CMMI that consists of the following components −
- Maturity Levels (staged representation) or Capability Levels (continuous representation)
- Process Areas
- Goals: Generic and Specific
- Common Features
- Practices: Generic and Specific
We have covered all the maturity levels and capability levels. In addition, we discussed all the Key Process Areas and related Generic Goals, Specific Goals, Common Features and Practices.
Later, we have given you a brief introduction on CMMI Appraisals and showed you the different Appraisal Classes.
What is Next?
SEI CMMI is a big subject that cannot be explained in a small tutorial. So we strongly recommend you to go through other CMMI resources and collect more information on this subject. These resources are listed in the CMMI Resources chapter.
Please send me your feedback at [email protected]
A | B | C | D | E | F | G | H | I | J | K |
L | M | N | O | P | Q | R | S | T | U | V |
W | X | Y | Z |
Ability to perform − A common feature of CMMI model process areas with a staged representation that groups the generic practices related to ensuring that the project and/or organization has the resources it needs.
Acceptance criteria − The criteria that a product or product component must satisfy to be accepted by a user, customer, or other authorized entity.
Acceptance testing − Formal testing conducted to enable a user, customer, or other authorized entity to determine whether to accept a product or product component.
Achievement profile − In the continuous representation, a list of process areas and their corresponding capability levels that represent the organization's progress for each process area while advancing through the capability levels.
Acquisition − The process of obtaining, through contract, any discrete action or proposed action by the acquisition entity that would commit to invest for obtaining products and services.
Acquisition strategy − The specific approach to acquiring products and services that is based on considerations of supply sources, acquisition methods, requirements specification types, contract or agreement types, and the related acquisition risk.
Adequate − Adequate, appropriate, and as needed appear in CMMI to allow managers at all levels and practitioners to interpret the specific and generic goals and practices in light of the organization's business objectives. For example, a Generic Practice for the process area of Risk Management states− "Provide adequate resources for performing the risk management process, developing the work products, and providing the services of the process." Adequate could be satisfied by Numbers of people, People who must monitor the risks etc.
Advanced practices − In the continuous representation, all the specific practices with a capability level of two or higher.
Agreement/contract requirements − All technical and non-technical requirements related to an acquisition.
Allocated requirement − Requirement that levies all or part of the performance and functionality of a higher level requirement on a lower level architectural element or design component.
Alternative practice − A practice that is a substitute for one or more generic or specific practices contained in CMMI models that achieves an equivalent effect toward satisfying the generic or specific goal associated with model practices. Alternative practices are not necessarily one-for-one replacements for the generic or specific practices.
Appraisal − An appraisal is an examination of one or more processes by a trained team of professionals using an appraisal reference model as the basis for determining strengths and weaknesses.
Appraisal findings − The conclusions of an appraisal that identify the most important issues, problems, or opportunities within the appraisal scope. It includes, at a minimum, strengths and weaknesses based on valid observations.
Appraisal participants − Members of the organizational unit who participate in providing information during the appraisal.
Appraisal rating − As used in CMMI appraisal materials, the value assigned by an appraisal team to either (1) a CMMI goal or process area, (2) the capability level of a process area, or (3) the maturity level of an organizational unit. The rating is determined by enacting the defined rating process for the appraisal method being employed.
Appraisal reference model − As used in CMMI appraisal materials, the CMMI model to which an appraisal team correlates implemented process activities.
Appraisal scope − The definition of the boundaries of the appraisal encompassing the organizational limits and the CMMI model limits.
Appraisal team leader − A person who leads the activities of an appraisal and has satisfied the qualification criteria for experience, knowledge, and skills defined by the appraisal method.
Appropriate − See definition for Adequate.
As needed − See definition for Adequate.
Assessment − An assessment is an appraisal that an organization conducts for itself for the purposes of process improvement.
Assignable cause of process variation − In CMMI, the term "special cause of process variation" is used in place of "assignable cause of process variation" to ensure consistency. Both terms are defined identically.
Audit − An independent examination of a work product or set of work products to determine whether requirements are being met.
Base measure − A distinct property or characteristic of an entity and the method for quantifying it.
Base practices − In the continuous representation, all the specific practices with a capability level of 1.
Baseline − The term baseline is normally used to denote such a reference point. A baseline is an approved snapshot of the system at appropriate points in the development life cycle. A baseline establishes a formal base for defining subsequent change. Without this line or reference point, the notion of change is meaningless.
Business objectives − Senior-management-developed strategies designed to ensure an organization's continued existence and enhance its profitability, market share, and other factors influencing the organization's success.
Capability evaluation − An appraisal by a trained team of professionals used as a discriminator to select suppliers, for contract monitoring, or for incentives. Evaluations are used to help decision makers make better acquisition decisions, improve subcontractor performance, and provide insight to a purchasing organization.
Capability level − Achievement of process improvement within an individual process area. A capability level is defined by the appropriate specific and generic practices for a process area.
Capability level profile − In the continuous representation, a list of process areas and their corresponding capability levels. The profile may be an achievement profile when it represents the organization's progress for each process area while advancing through the capability levels. Or, the profile may be a target profile when it represents an objective for process improvement.
Capability maturity model − A capability maturity model (CMM) contains the essential elements of effective processes for one or more disciplines. It also describes an evolutionary improvement path from ad hoc, immature processes to disciplined, mature processes with improved quality and effectiveness.
Capable process − A process that can satisfy its specified product quality, service quality, and process performance objectives.
Causal analysis − The analysis of defects to determine their cause.
Change management − Judicious use of means to effect a change, or proposed change, on a product or service.
CMMI appraisal tailoring − Selection of options within the appraisal method for use in a specific instance. The intent of appraisal tailoring is to assist an organization in aligning application of the method with its business objectives.
CMMI model component − Any of the main architectural elements that compose a CMMI model. Some of the main elements of a CMMI model include specific practices, generic practices, specific goals, generic goals, process areas, capability levels, and maturity levels.
CMMI model tailoring − The use of a subset of a CMMI model for the purpose of making it suitable for a specific application. The intent of model tailoring is to assist an organization in aligning application of a model with its business objectives.
CMMI Product Suite − This term has been used for a complete CMMI Framework.
Commitment to perform − A common feature of CMMI model process areas with a staged representation that groups the generic practices related to creating policies and securing sponsorship.
Common cause of process variation − The variation of a process that exists because of normal and expected interactions among the components of a process.
Concept of operations − A general description of the way in which an entity is used or operates.
Configuration audit − An audit conducted to verify that a configuration item conforms to a specified standard or requirement.
Configuration baseline − The configuration information formally designated at a specific time during a product's or product component's life. Configuration baselines, plus approved changes from those baselines, constitute the current configuration information.
Configuration control − An element of configuration management consisting of the evaluation, coordination, approval or disapproval, and implementation of changes to configuration items after formal establishment of their configuration identification.
Configuration control board − A group of people responsible for evaluating and approving or disapproving proposed changes to configuration items, and for ensuring implementation of approved changes.
Configuration identification − An element of configuration management consisting of selecting the configuration items for a product, assigning unique identifiers to them, and recording their functional and physical characteristics in technical documentation.
Configuration item − An aggregation of work products that is designated for configuration management and treated as a single entity in the configuration management process.
Configuration management − A discipline applying technical and administrative direction and surveillance to (1) identify and document the functional and physical characteristics of a configuration item, (2) control changes to those characteristics, (3) record and report change processing and implementation status, and (4) verify compliance with specified requirements. [IEEE Std 610.1990]
CMMI Model − Since the CMMI Framework can generate different models based on the needs of the organization using it, there are multiple CMMI models. Consequently, the phrase "CMMI MODEL" could be any one of many collections of information. The phrase "CMMI models" refers to one, some, or the entire collection of possible models that can be generated from the CMMI Framework.
Configuration status accounting − An element of configuration management consisting of the recording and reporting of information needed to manage a configuration effectively. This information includes a listing of the approved configuration identification, the status of proposed changes to the configuration, and the implementation status of approved changes.
Continuous representation − A capability maturity model structure wherein capability levels provide a recommended order for approaching process improvement within each specified process area.
Corrective action − Acts or deeds used to remedy a situation, remove an error, or adjust a condition.
COTS − Items that can be purchased from a commercial vendor.
Customer − A customer is the individual, project, organization, group, and so forth that is responsible for accepting the product or for authorizing payment. The customer is external to the project but not necessarily external to the organization. The term customer also serves as a variable when we discuss requirements gathering or elicitation.
Data management − Principles, processes, and systems for the sharing and management of data.
Defect density − Number of defects per unit of product size (e.g., problem reports per 1000 lines of code).
Defined process − A defined set of steps to be followed as a part of the improvement.
Derived measures − Data resulting from the mathematical function of two or more base measures.
Derived requirements − Requirements that are not explicitly stated in the customer requirements, but are inferred (1) from contextual requirements (e.g., applicable standards, laws, policies, common practices, and management decisions), or (2) from requirements needed to specify a product component. Derived requirements can also arise during analysis and design of components of the product or system.
Design review − A formal, documented, comprehensive, and systematic examination of a design to evaluate the design requirements and the capability of the design to meet these requirements, and to identify problems and propose solutions.
Development − Development, as it is used throughout CMMI, implies maintenance activities as well as development activities. Experience has shown that best practices should be applied to both development and maintenance projects if an organization is in pursuit of engineering excellence.
Developmental plan − A plan for guiding, implementing, and controlling the design and development of one or more products.
Directing implementation − A common feature of CMMI model process areas with a staged representation that groups the generic practices related to managing the performance of the process, managing the integrity of its work products, and involving relevant stakeholders.
Discipline amplification − Model components that provide guidance for interpreting model information for specific disciplines (e.g., systems engineering, or software engineering) are called "DISCIPLINE AMPLIFICATIONS." Discipline amplifications are added to other model components where necessary. These are easy to locate because they appear on the right side of the page and have a title indicating the discipline that they address (for example, "For Software Engineering").
Document − A document is a collection of data, regardless of the medium on which it is recorded. It generally has permanence and can be read by humans or machines. Documents include both paper and electronic documents.
Enterprise − Enterprise is used to refer to very large companies that consist of many organizations in many different locations with different customers.
Entry criteria − States of being that must be present before an effort can begin successfully.
Equivalent staging − Equivalent staging is a target staging, created using the continuous representation that is defined so that the results of using the target staging can be compared to the maturity levels of the staged representation.
Exit criteria − States of being that must be present before an effort can end successfully.
Expected CMMI components − CMMI components that explain what may be done to satisfy a required CMMI component. Model users can implement the expected components explicitly or implement equivalent alternative practices to these components. Specific and generic practices are expected model components
Finding − See appraisal findings.
Formal evaluation process − In the Decision Analysis and Resolution process area, see the definition of a "formal evaluation process" in the introductory notes.
Functional analysis − Examination of a defined function to identify all the sub-functions necessary to the accomplishment of that function; identification of functional relationships and interfaces (internal and external) and capturing these in a functional architecture; and flow down of upper level performance requirements and assignment of these requirements to lower level sub-functions.
Functional architecture − The hierarchical arrangement of functions, their internal and external (external to the aggregation itself) functional interfaces and external physical interfaces, their respective functional and performance requirements, and their design constraints.
Generic goal − GENERIC GOALS are called "generic" because the same goal statement appears in multiple process areas. In the staged representation, each process area has only one generic goal. Achievement of a generic goal in a process area signifies improved control in planning and implementing the processes associated with that process area, thus indicating whether these processes are likely to be effective, repeatable, and lasting. Generic goals are required model components and are used in appraisals to determine whether a process area is satisfied.
Generic practice − GENERIC PRACTICES provide institutionalization to ensure that the processes associated with the process area will be effective, repeatable, and lasting. Generic practices are categorized by generic goals and common features and are expected components in CMMI models. (Only the generic practice title, statement, and elaborations appear in the process areas.)
Generic practice elaboration − After the specific practices, the generic practice titles and statements appear that apply to the process area. After each generic practice statement, an elaboration may appear in plain text with the heading "Elaboration". The GENERIC PRACTICE ELABORATION provides information about how the generic practice should be interpreted for the process area. If there is no elaboration present, the application of the generic practice is obvious without an elaboration.
Goal − A "GOAL" is a required CMMI component that can be either a generic goal or a specific goal. When you see the word "goal" in a CMMI model, it always refers to model components (for example, generic goal, specific goal).
Incomplete process − A process that is not performed or is only performed partially (also known as capability level 0). One or more of the specific goals of the process area are not satisfied.
Independent group − In the Process and Product Quality Assurance process area, see the discussion of a "group that is independent" in the introductory notes.
Informative CMMI components − CMMI components that help model users understand the required and expected components of a model. These components may contain examples, detailed explanations, or other helpful information. Sub-practices, notes, references, goal titles, practice titles, sources, typical work products, discipline amplifications, and generic practice elaborations are informative model components.
Institutionalization − The ingrained way of doing business that an organization follows routinely as part of its corporate culture.
Integrated Product and Process Development − A systematic approach to product development that achieves a timely collaboration of relevant stakeholders throughout the product life cycle to better satisfy customer needs.
Integrated team − A group of people with complementary skills and expertise who are committed to delivering specified work products in timely collaboration. Integrated team members provide skills and advocacy appropriate to all phases of the work products and are collectively responsible for delivering the work products as specified. An integrated team should include empowered representatives from organizations, disciplines, and functions that have a stake in the success of the work products.
Interface control − In configuration management, the process of (1) identifying all functional and physical characteristics relevant to the interfacing of two or more configuration items provided by one or more organizations, and (2) ensuring that the proposed changes to these characteristics are evaluated and approved prior to implementation. [IEEE 828-1983].
Lead appraiser − As used in the CMMI Product Suite, a person who has achieved recognition from an authorizing body to perform as an appraisal team leader for a particular appraisal method.
Life-cycle model − A partitioning of the life of a product into phases that guide the project from identifying customer needs through product retirement.
Manager − A project manager is the person responsible for planning, directing, controlling, structuring, and motivating the project. He or she may provide both technical and administrative direction and control to those performing project tasks or activities within his or her area of responsibility. The project manager is ultimately responsible to the customer.
Maturity level − Degree of process improvement across a predefined set of process areas in which all goals within the set are attained.
Memorandum of agreement − Binding documents of understanding or agreements between two or more parties.
Natural bounds − The inherent process reflected by measures of process performance, sometimes referred to as "voice of the process." Techniques such as control charts, confidence intervals, and prediction intervals are used to determine whether the variation is due to common causes (i.e., the process is predictable or "stable") or is due to some special cause that can and should be identified and removed.
Non-developmental item − An item of supply that was developed previous to its current use in an acquisition or development process. Such an item may require minor modifications to meet the requirements of its current intended use.
Nontechnical requirements- Disposições contratuais, compromissos, condições e termos que afetam como os produtos ou serviços devem ser adquiridos. Os exemplos incluem produtos a serem entregues, direitos de dados para itens comerciais não desenvolvidos (NDIs) entregues de prateleira (COTS), datas de entrega e marcos com critérios de saída. Outros requisitos não técnicos incluem requisitos de treinamento, requisitos de local e cronogramas de implantação.
Objective- O termo objetivo é usado no CMMI no sentido comum do dia a dia; este é o nosso objetivo ou meta a ser cumprido.
Objective evidence - Conforme usado em materiais de avaliação CMMI, informações qualitativas ou quantitativas, registros ou declarações de fatos relativos às características de um item ou serviço ou à existência e implementação de um elemento de processo, que são baseados em observação, medição ou teste e que são verificáveis.
Objectively evaluate- Revisar atividades e produtos de trabalho em relação a critérios que minimizem a subjetividade e o preconceito do revisor. Um exemplo de avaliação objetiva é uma auditoria em relação a requisitos, normas ou procedimentos por uma função de garantia de qualidade independente.
Observation- Conforme usado nos materiais de avaliação do CMMI, um registro escrito que representa a compreensão dos membros da equipe de avaliação das informações vistas ou ouvidas durante as atividades de coleta de dados da avaliação. O registro escrito pode assumir a forma de uma declaração ou pode assumir formas alternativas, desde que o conteúdo da informação seja preservado.
Operational concept - Uma descrição geral da forma como uma entidade é usada ou opera.
Operational scenario- Uma descrição de uma sequência imaginada de eventos que inclui a interação do produto com seu ambiente e usuários, bem como a interação entre seus componentes de produto. Os cenários operacionais são usados para avaliar os requisitos e o design do sistema e para verificar e validar o sistema.
Optimizing process- Um processo gerenciado quantitativamente que é aprimorado com base na compreensão das causas comuns de variação inerentes ao processo. Um processo que se concentra na melhoria contínua da faixa de desempenho do processo por meio de melhorias incrementais e inovadoras.
Organization - Uma organização é uma estrutura na qual as 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.
Organization's business objectives - Estratégias desenvolvidas pela Alta Administração para garantir a continuidade da existência de uma organização e aumentar sua lucratividade, participação no mercado e outros fatores que influenciam o sucesso da organização.
Organizational maturity- Até que ponto uma organização implementou de forma explícita e consistente os processos documentados, gerenciados, medidos, controlados e continuamente aprimorados. A maturidade organizacional pode ser medida por meio de avaliações.
Organizational policy - Um princípio orientador normalmente estabelecido pela alta administração que é adotado por uma organização para influenciar e determinar decisões.
Organizational unit- A parte de uma organização que é objeto de uma avaliação (também conhecida como o escopo organizacional da avaliação). Uma unidade organizacional implanta um ou mais processos que têm um contexto de processo coerente e opera dentro de um conjunto coerente de objetivos de negócios. Uma unidade organizacional normalmente faz parte de uma organização maior, embora em uma organização pequena, a unidade organizacional possa ser a organização inteira.
Outsourcing - O processo de obtenção, por meio de contrato, de qualquer ação discreta ou proposta de ação da entidade adquirente que se comprometa a investir para a obtenção de produtos e serviços.
Peer review - Uma revisão feita pelo par para descobrir defeitos em uma entrega.
Performance parameters - As medidas de eficácia e outras medidas-chave usadas para orientar e controlar o desenvolvimento progressivo.
Performed process- Um processo que realiza o trabalho necessário para produzir produtos de trabalho de saída identificados usando produtos de trabalho de entrada identificados (também conhecido como nível de capacidade 1). Os objetivos específicos da área de processo são atendidos.
Planned process- Um processo que é documentado por uma descrição e um plano. A descrição e o plano devem ser coordenados, e o plano deve incluir padrões, requisitos, objetivos, recursos, atribuições, etc.
Process - Um conjunto de atividades, métodos, práticas e transformações que as pessoas usam para desenvolver e manter sistemas e produtos associados.
Process action plan - Na área de processo Foco no Processo Organizacional, consulte a definição de "plano de ação do processo" nas notas introdutórias.
Process action team - Uma equipe que tem a responsabilidade de desenvolver e implementar atividades de melhoria de processo para uma organização, conforme documentado no plano de ação de melhoria de processo.
Process and technology improvements - Na área de processo de Inovação Organizacional e Implantação, consulte a discussão sobre "melhorias de processo e tecnologia" nas notas introdutórias.
Process area- Uma área de Processo é um conjunto de práticas relacionadas a uma área que, quando realizadas de forma coletiva, atendem a um conjunto de metas consideradas importantes para a realização de melhorias significativas nessa área. Todas as áreas de processo CMMI são comuns às representações contínuas e em estágios. Na representação em estágios, as áreas de processo são organizadas por níveis de maturidade.
Process asset - Qualquer coisa que a organização considere útil para atingir os objetivos de uma área de processo.
Process asset library - Uma coleção de acervos de ativos de processo que podem ser usados por uma organização ou projeto.
Process attribute - Uma característica mensurável da capacidade do processo aplicável a qualquer processo.
Process capability - A gama de resultados esperados que podem ser alcançados seguindo um processo.
Process context- O conjunto de fatores, documentado na entrada da avaliação, que influencia o julgamento e a comparabilidade das classificações da avaliação. Isso inclui, mas não está limitado ao tamanho da unidade organizacional a ser avaliada; a demografia da unidade organizacional; a disciplina de aplicação dos produtos ou serviços; o tamanho, criticidade e complexidade dos produtos ou serviços; e as características de qualidade dos produtos ou serviços.
Process definition- O ato de definir e descrever um processo. O resultado da definição do processo é uma descrição do processo.
Process description- Uma expressão documentada de um conjunto de atividades realizadas para atingir um determinado propósito que fornece uma definição operacional dos principais componentes de um processo. A documentação especifica, de maneira completa, precisa e verificável, os requisitos, design, comportamento ou outras características de um processo. Também pode incluir procedimentos para determinar se essas disposições foram satisfeitas. As descrições dos processos podem ser encontradas no nível de atividade, projeto ou organizacional.
Process element- A unidade fundamental de um processo. Um processo pode ser definido em termos de subprocessos ou elementos de processo. Um subprocesso pode ser decomposto posteriormente; um elemento do processo não pode. Cada elemento do processo cobre um conjunto estreitamente relacionado de atividades (por exemplo, elemento de estimativa, elemento de revisão por pares). Os elementos do processo podem ser retratados usando modelos a serem concluídos, abstrações a serem refinadas ou descrições a serem modificadas ou usadas. Um elemento de processo pode ser uma atividade ou tarefa.
Process group - Um conjunto de especialistas que facilitam a definição, manutenção e melhoria do (s) processo (s) utilizado (s) pela organização.
Process improvement - Um programa de atividades destinado a melhorar o desempenho e a maturidade dos processos da organização e os resultados de tal programa.
Process-improvement objectives - Um conjunto de características-alvo estabelecidas para orientar o esforço para melhorar um processo existente de uma forma mensurável específica, seja em termos de características resultantes do produto (por exemplo, qualidade, desempenho, conformidade com padrões, etc.) ou na forma como o processo é executado (por exemplo, eliminação de etapas de processo redundantes, combinação de etapas de processo, melhoria do tempo de ciclo, etc.)
Process-improvement plan - Na área de processo Foco no Processo Organizacional, consulte a definição de "plano de melhoria de processo" nas notas introdutórias.
Process measurement - O conjunto de definições, métodos e atividades usados para fazer medições de um processo e seus produtos resultantes com o propósito de caracterizar e compreender o processo.
Process owner- A pessoa (ou equipe) responsável por definir e manter um processo. No nível organizacional, o proprietário do processo é a pessoa (ou equipe) responsável pela descrição de um processo padrão; no nível do projeto, o proprietário do processo é a pessoa (ou equipe) responsável pela descrição do processo definido. Um processo pode, portanto, ter vários proprietários em diferentes níveis de responsabilidade.
Process performance- Uma medida dos resultados reais alcançados ao seguir um processo. É caracterizado por medidas de processo (por exemplo, esforço, tempo de ciclo e eficiência de remoção de defeitos) e medidas de produto (por exemplo, confiabilidade, densidade de defeitos e tempo de resposta).
Process performance baseline - Uma caracterização documentada dos resultados reais alcançados seguindo um processo, que é usada como uma referência para comparar o desempenho real do processo com o desempenho esperado do processo.
Process performance model - Uma descrição das relações entre os atributos de um processo e seus produtos de trabalho que são desenvolvidos a partir de dados históricos de desempenho do processo e calibrados usando medidas coletadas de processo e produto do projeto e que são usadas para prever resultados a serem alcançados seguindo um processo.
Process tailoring- Para fazer, alterar ou adaptar uma descrição de processo para um fim específico. Por exemplo, um projeto adapta seu processo definido a partir do conjunto de processos padrão da organização para atender aos objetivos, restrições e ambiente do projeto.
Product- Um produto pode ser considerado qualquer saída ou serviço tangível resultante da sequência de um processo e destinado a ser entregue a um cliente ou usuário final. Um produto também pode ser qualquer produto de trabalho entregue ao cliente de acordo com o contrato.
Product component- Os componentes do produto são geralmente componentes de nível inferior do produto e são integrados para "construir" o produto. Os componentes do produto podem ser parte do produto entregue ao cliente ou servir na fabricação ou uso do produto. Por exemplo, para as empresas que fabricam baterias para celulares, a bateria para celulares é um produto. Para as empresas que desenvolvem e entregam telefones celulares, a bateria é um componente do produto.
Product baseline - No gerenciamento de configuração, o pacote de dados técnicos inicial aprovado (incluindo, para software, a listagem do código-fonte) definindo um item de configuração durante a produção, operação, manutenção e suporte logístico de seu ciclo de vida.
Product-component requirements - Os requisitos dos componentes do produto fornecem uma especificação completa de um componente do produto, incluindo ajuste, forma, função, desempenho e qualquer outro requisito.
Product life cycle- Um produto de trabalho é qualquer artefato produzido por um processo de ciclo de vida e também pode ser referido como um produto de trabalho de ciclo de vida. Os produtos de trabalho do ciclo de vida podem incluir especificações de requisitos, especificações de interface, especificações de arquitetura, planos de projeto, documentos de design, planos de teste de unidade, planos de teste de integração e sistema, um processo como um processo de montagem de produto de manufatura.
Project- Um projeto é um conjunto gerenciado de recursos inter-relacionados que entrega um ou mais produtos a um cliente ou usuário final. O conjunto de recursos tem início e fim definidos e opera de acordo com um plano.
Product line - Um grupo de produtos que compartilha um conjunto comum e gerenciado de recursos que satisfazem as necessidades específicas de um mercado ou missão selecionados.
Product-related life-cycle processes - Processos associados a um produto ao longo de uma ou mais fases de sua vida (ou seja, desde a concepção até o descarte), como os processos de fabricação e suporte.
Product requirements - Um refinamento dos requisitos do cliente na linguagem dos desenvolvedores, transformando os requisitos implícitos em requisitos derivados explícitos.
Program- (1) Um projeto. (2) Uma coleção de projetos relacionados e a infraestrutura que os apóia, incluindo objetivos, métodos, atividades, planos e medidas de sucesso.
Project manager- Um gerente de projeto é a pessoa responsável por planejar, dirigir, controlar, estruturar e motivar o projeto. Ele ou ela pode fornecer direção técnica e administrativa e controle para aqueles que executam tarefas ou atividades do projeto dentro de sua área de responsabilidade. O gerente de projeto é o responsável final perante o cliente. O gerente de projeto assume diferentes funções e responsabilidades conforme o tamanho, diversidade e complexidade do projeto mudam.
Project progress and performance - O que um projeto alcança com relação à implementação de planos de projeto, incluindo esforço, custo, cronograma e desempenho técnico.
Project's defined process - Na área de processo Gestão Integrada de Projetos, consulte a definição de "processo definido do projeto" nas notas introdutórias e na prática específica Estabelecer o processo definido de projetos.
Prototype - Um tipo, formulário ou instância preliminar de um produto ou componente de produto que serve como modelo para estágios posteriores ou para a versão final completa do produto.
Quality - A capacidade de um conjunto de características inerentes a um produto, componente de produto ou processo atender aos requisitos dos clientes.
Quality assurance - Um meio planejado e sistemático para garantir à gestão que os padrões, práticas, procedimentos e métodos definidos para o processo sejam aplicados.
Quality control - As técnicas operacionais e atividades que são utilizadas para cumprir os requisitos de qualidade.
Quantitative objective - Valor alvo desejado expresso em medidas quantitativas.
Quantitatively managed process- Um processo definido que é controlado por meio de técnicas estatísticas e outras técnicas quantitativas. Os atributos de qualidade do produto, qualidade do serviço e desempenho do processo são mensuráveis e controlados ao longo do projeto.
Reference mode - Um modelo que é usado como referência para medir algum atributo.
Relevant stakeholder - Uma parte interessada relevante é usada para designar uma parte interessada que é identificada para envolvimento em atividades especificadas e é incluída em um plano apropriado, como o plano do projeto.
Required CMMI components- Componentes do CMMI que são essenciais para alcançar a melhoria do processo em uma determinada área de processo. Esses componentes são usados em avaliações para determinar a capacidade do processo. Metas específicas e metas genéricas são componentes obrigatórios do modelo.
Requirement- (1) Uma condição ou capacidade necessária a um usuário para resolver um problema ou atingir um objetivo. (2) Uma condição ou capacidade que deve ser satisfeita ou possuída por um produto ou componente do produto para satisfazer um contrato, padrão, especificação ou outros documentos formalmente impostos. (3) Uma representação documentada de uma condição ou capacidade como em (1) ou (2).
Requirements analysis- A determinação do desempenho específico do produto e características funcionais com base em análises das necessidades, expectativas e restrições do cliente; conceito operacional; ambientes de utilização projetados para pessoas, produtos e processos; e medidas de eficácia.
Requirements elicitation - Usar técnicas sistemáticas, como protótipos e pesquisas estruturadas, para identificar e documentar de forma proativa as necessidades do cliente e do usuário final.
Requirements management - A gestão de todos os requisitos recebidos ou gerados pelo projeto, incluindo os requisitos técnicos e não técnicos, bem como os requisitos impostos ao projeto pela organização.
Requirements traceability - A evidência de uma associação entre um requisito e seu requisito de origem, sua implementação e sua verificação.
Return on investment - A relação entre a receita da saída (produto) e os custos de produção, que determina se uma organização se beneficia ao realizar uma ação para produzir algo.
Risk analysis - A avaliação, classificação e priorização de riscos.
Risk identification - Uma abordagem organizada e completa para buscar riscos prováveis ou realistas na realização de objetivos.
Risk management - Um processo analítico organizado para identificar o que pode causar dano ou perda (identificar riscos), avaliar e quantificar os riscos identificados e desenvolver e, se necessário, implementar uma abordagem adequada para prevenir ou lidar com as causas de risco que podem resultar em danos significativos ou perda.
Risk management strategy- Uma abordagem técnica e organizada para identificar o que pode causar dano ou perda (identificar riscos), avaliar e quantificar os riscos identificados e desenvolver e, se necessário, implementar uma abordagem adequada para prevenir ou lidar com as causas de risco que podem resultar em dano ou perda significativa . Normalmente, o gerenciamento de riscos é executado para unidades organizacionais de desenvolvimento de projetos, organizações ou produtos.
Root cause - A causa raiz é a origem de um defeito, que se removido, o defeito é diminuído ou removido.
Senior manager- O termo gerente sênior, conforme usado no CMMI, refere-se a uma função de gerenciamento em um nível alto o suficiente em uma organização que o foco principal da pessoa é a saúde a longo prazo e o sucesso da organização, em vez do projeto de curto prazo e preocupações e pressões contratuais. Um gerente sênior pode ser responsável pela supervisão de um programa que pode conter muitos projetos que são gerenciados por gerentes de projeto.
Software engineering- (1) A aplicação de uma abordagem sistemática, disciplinada e quantificável para o desenvolvimento, operação e manutenção de software. (2) O estudo de abordagens como em (1).
Solicitation - O processo de preparação de um pacote de solicitação e seleção de um fornecedor (empreiteiro).
Solicitation package- Um documento formal delineando os requisitos técnicos e não técnicos que é usado para solicitar ofertas em convites para licitações (licitações) e solicitações de propostas (propostas), ou para solicitar declarações de capacidades e cotações de preços (cotações). Caso contrário, é usado como base para selecionar uma fonte ou fontes de fornecimento de produtos ou serviços.
Special cause of process variation - A causa de um defeito que é específico de alguma circunstância transitória e não uma parte inerente de um processo.
Specific goal- OBJETIVOS ESPECÍFICOS se aplicam a uma área de processo e abordam as características exclusivas que descrevem o que deve ser implementado para satisfazer a área de processo. Metas específicas são componentes obrigatórios do modelo e são usadas em avaliações para ajudar a determinar se uma área de processo está satisfeita.
Specific practice- UMA PRÁTICA ESPECÍFICA é uma atividade considerada importante para atingir o objetivo específico associado. As práticas específicas descrevem as atividades que se espera que resultem no cumprimento das metas específicas de uma área de processo. Práticas específicas são componentes esperados do modelo.
Stable process - O estado em que todas as causas especiais de variação do processo foram removidas e impedidas de se repetir, de modo que apenas as causas comuns de variação do processo permanecem.
Staged representation- Uma estrutura modelo em que o cumprimento dos objetivos de um conjunto de áreas de processo estabelece um nível de maturidade; cada nível constrói uma base para os níveis subsequentes.
Stakeholder - Uma parte interessada é um grupo ou indivíduo que é afetado pelo resultado de um projeto ou pode afetar as atividades ou a produção do projeto.
Standard process- Uma definição operacional do processo básico que orienta o estabelecimento de um processo comum em uma organização. Um processo padrão descreve os elementos fundamentais do processo que devem ser incorporados em qualquer processo definido. Ele também descreve os relacionamentos (por exemplo, pedidos e interfaces) entre esses elementos do processo.
Statement of work - Uma descrição do trabalho contratado necessário para concluir um projeto.
Statistical predictability - O desempenho de um processo quantitativo que é controlado por meio de técnicas estatísticas e outras técnicas quantitativas.
Statistical process control - Análise com base estatística de um processo e medições de desempenho do processo, que identificará as causas comuns e especiais de variação no desempenho do processo e manterá o desempenho do processo dentro dos limites.
Statistical techniques - Uma técnica analítica que emprega métodos estatísticos (por exemplo, controle estatístico do processo, intervalos de confiança, intervalos de previsão).
Statistically managed process - Um processo gerenciado por uma técnica baseada em estatísticas em que os processos são analisados, as causas especiais de variação do processo são identificadas e o desempenho é contido dentro de limites bem definidos.
Strength - Como usado em materiais de avaliação CMMI, uma implementação exemplar ou digna de nota de uma prática modelo CMMI.
Sub-process - Um processo que faz parte de um processo maior.
Supplier- (1) Uma entidade que entrega produtos ou realiza serviços sendo adquiridos. (2) Um indivíduo, parceria, empresa, corporação, associação ou outro serviço tendo um acordo (contrato) com uma aquisição para o design, desenvolvimento, fabricação, manutenção, modificação ou fornecimento de itens sob os termos de um acordo (contrato )
Sustainment- Os processos usados para garantir que um produto possa ser utilizado operacionalmente por seus usuários finais ou clientes. A sustentação garante que a manutenção seja feita de forma que o produto esteja em condições operacionais, esteja ele em uso ou não pelos clientes ou usuários finais.
Systems engineering- A abordagem interdisciplinar que rege o esforço técnico e gerencial total necessário para transformar um conjunto de necessidades, expectativas e restrições do cliente em uma solução de produto e dar suporte a essa solução ao longo da vida do produto. Isso inclui a definição de medidas de desempenho técnico, a integração de especialidades de engenharia para o estabelecimento de uma arquitetura de produto e a definição de processos de ciclo de vida de suporte que equilibrem custo, desempenho e objetivos de cronograma.
Tailoring guidelines- A adaptação de um processo cria, altera ou adapta as descrições do processo, normalmente descritas no nível organizacional, para uso em um projeto específico. Para a maioria das organizações, uma definição de processo organizacional não pode ou não será seguida 100% para todos os projetos. Normalmente, é necessária alguma adaptação. As diretrizes de adaptação descrevem o que pode e o que não pode ser modificado e identificam os componentes do processo que são candidatos permitidos para modificação.
Target profile - Na representação contínua, uma lista de áreas de processo e seus níveis de capacidade correspondentes que representam um objetivo de melhoria de processo.
Target staging - Na representação contínua, uma sequência de perfis-alvo que descreve o caminho de melhoria de processos a ser seguido pela organização.
Technical data package - Uma coleção de itens que podem incluir o seguinte, se tais informações forem apropriadas ao tipo de produto e componente do produto.
Technical requirements - Propriedades (atributos) de produtos ou serviços a serem adquiridos ou desenvolvidos.
Test procedure - Instruções detalhadas para configuração, execução e avaliação dos resultados de um determinado teste.
Trade study - Uma avaliação de alternativas com base em critérios e análise sistemática, para selecionar a melhor alternativa para atingir determinados objetivos.
Training- Na área de processo Treinamento Organizacional, veja a definição de .training. nas notas introdutórias.
Unit testing - Teste de unidades individuais de hardware ou software ou grupos de unidades relacionadas.
Validation- A validação demonstra que o produto, conforme fornecido, (ou como será fornecido) atenderá ao uso pretendido no ambiente operacional. A validação garante que "Você construiu a coisa certa."
Verification- A verificação inclui a verificação do produto e produtos de trabalho intermediários em relação a todos os requisitos selecionados, incluindo cliente, produto e requisitos de componentes de produto. A verificação é inerentemente um processo incremental. Ele começa com a verificação dos requisitos, avança através da verificação dos produtos de trabalho em evolução e culmina na verificação do produto concluído. A verificação trata se o produto de trabalho reflete adequadamente os requisitos especificados. A verificação garante "Você construiu da maneira certa".
Verifying implementation - Uma característica comum das áreas de processo do modelo CMMI com uma representação em estágios que agrupa as práticas genéricas relacionadas à revisão pela gerência de nível superior e avaliação objetiva de conformidade com as descrições, procedimentos e padrões do processo.
Version control - O estabelecimento e manutenção de linhas de base e a identificação de alterações nas linhas de base que possibilitem o retorno à linha de base anterior.
Weakness - Conforme usado em materiais de avaliação CMMI, a implementação ineficaz ou inexistente de uma ou mais práticas do modelo CMMI.
Work breakdown structure - Um arranjo de elementos de trabalho e sua relação entre si e com o produto final.
Work product- O termo PRODUTO DE TRABALHO é usado em todo o CMMI Product Suite para significar qualquer artefato produzido por um processo. Esses 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 fabricação, um processo de treinamento e um processo de descarte do produto. Uma distinção fundamental entre um PRODUTO DE TRABALHO e um componente de produto é que um produto de trabalho não precisa ser projetado ou parte do produto final.
Work product and task attributes- Características de produtos, serviços e tarefas do projeto usadas para ajudar na estimativa do trabalho do projeto. Essas características incluem itens como tamanho, complexidade, peso, forma, ajuste ou função. Eles são normalmente usados como uma entrada para derivar outras estimativas de projeto e recursos (por exemplo, esforço, custo, cronograma)
Aqui está a lista de todos os acrônimos CMMI organizados em ordem alfabética.
Acrônimo | Forma expandida |
---|---|
ARCO | Requisitos de avaliação para CMMI |
CAF | Estrutura de avaliação CMM |
CARRO | Análise e Resolução Causal (área de processo) |
CAU | Atualização da aviônica da cabine |
CBA IPI | Avaliação baseada em CMM para melhoria de processos internos |
CBT | Treinamento baseado em computador |
CCB | Placa de controle de configuração |
CM | Gestão da Configuração (área de processo) |
CMM | modelo de maturidade capacitiva |
CMMI | Integração do modelo de maturidade de capacidade |
CMMI-SE / SW | Capacidade de integração do modelo de maturidade para engenharia de sistemas e engenharia de software |
CMMI-SE / SW / IPPD | Capacidade de integração do modelo de maturidade para engenharia de sistemas, engenharia de software e desenvolvimento integrado de produto e processo |
CMMI-SE / SW / IPPD / SS | Capacidade de integração do modelo de maturidade para engenharia de sistemas, engenharia de software, desenvolvimento integrado de produtos e processos e terceirização de fornecedores |
COTS | Comercial de prateleira |
CPM | Método do Caminho Crítico |
DAR | Análise e Resolução de Decisões (área de processo) |
EIA | Electronic Industries Alliance |
EIA / IS | Padrão provisório da Electronic Industries Alliance |
FAA | Administração da Aviação Federal |
FAA-iCMM | Modelo de maturidade de capacidade integrada da Administração Federal de Aviação |
GG | Objetivo Genérico |
GP | Prática Genérica |
IDEAL | Iniciando, Diagnosticando, Estabelecendo, Agindo, Aprendendo |
IEEE | Instituto de Engenheiros Elétricos e Eletrônicos |
INCOSE | Conselho Internacional de Engenharia de Sistemas |
IPD-CMM | Modelo de maturidade de capacidade de desenvolvimento de produto integrado |
IPM | Gestão Integrada de Projetos (área de processo) |
IPPD | Desenvolvimento Integrado de Produto e Processo |
IPT | Equipe de Produto Integrado |
ISM | Gestão Integrada de Fornecedores (área de processo) |
ISO | Organização Internacional para Padronização |
ISO / IEC | Organização Internacional de Normalização e Comissão Eletrotécnica Internacional |
ISTO | Equipe Integrada (área de processo) |
KSLOC | Milhares de linhas de código de origem |
MA | Medição e Análise (área de processo) |
MOA | Memorando de entendimento |
NDI | Item de não desenvolvimento |
NDIA | Associação Industrial de Defesa Nacional |
OEI | Ambiente Organizacional para Integração (área de processo) |
OID | Inovação Organizacional e Implantação (área de processo) |
OPD | Definição de Processo Organizacional (área de processo) |
OPF | Foco no processo organizacional (área de processo) |
OPP | Desempenho de processos organizacionais (área de processo) |
OT | Treinamento Organizacional (área de processo) |
OUSD / AT & L | Escritório do Subsecretário de Defesa, Aquisição, Tecnologia e Logística |
P-CMM | Modelo de Maturidade de Capacidade de Pessoas |
PA | Área de Processo |
PAIS | Sistema de informação de avaliação de processos |
PASSAR | Sistema de software de aviônica primária |
PERT | Avaliação e técnica de revisão do programa |
PI | Integração de produto (área de processo) |
PMC | Monitoramento e Controle do Projeto (área de processo) |
PP | Planejamento de Projeto (área de processo) |
PPQA | Processo e Garantia da Qualidade do Produto (área de processo) |
QFD | Implementação da função de qualidade |
QPM | Gestão Quantitativa de Projetos (área de processo) |
RD | Desenvolvimento de Requisitos (área de processo) |
REQM | Gerenciamento de Requisitos (área de processo) |
RSKM | Gestão de Risco (área de processo) |
SA-CMM | Modelo de maturidade da capacidade de aquisição de software |
SAM | Gestão do Contrato do Fornecedor (área de processo) |
SCAMPI | Método de avaliação CMMI padrão para melhoria de processos |
SDMP | Plano de gerenciamento de desenvolvimento de software |
SE | Engenharia de sistemas |
SE-CMM | Modelo de maturidade da capacidade de engenharia de sistemas |
SEC | Conselho Executivo de Software |
SECAM | Modelo de avaliação de capacidade de engenharia de sistemas |
SECM | Modelo de capacidade de engenharia de sistemas |
SEI | Instituto de Engenharia de Software |
SE / SW | Engenharia de Sistemas e Engenharia de Software |
SEPG | Grupo de Processo de Engenharia de Software |
SG | Objetivo Específico |
SP | Prática Específica |
SPMN | Rede de gerentes de programa de software |
SS | Fornecimento de fornecedores |
STSC | Centro de Suporte de Tecnologia de Software |
SW | Engenharia de software |
SW-CMM | Modelo de maturidade de capacidade para software |
TS | Solução Técnica (área de processo) |
VAL | Validação (área de processo) |
VER | Verificação (área de processo) |
WBS | TrabalhoDemolirEstrutura |