O documento apresenta o modelo CMMI (Capability Maturity Model Integration), descrevendo suas principais características como a estrutura em áreas de processo distribuídas por categorias e níveis de maturidade, e abordando conceitos como representações contínua e por estágio. O objetivo é introduzir o modelo de forma prática, questionar mitos e compartilhar axiomas sobre o mesmo.

1. Conhecendo o CMMI (2º Edição) Alessandro Almeida

2. Agenda Objetivos Por que pensar nestas coisas? Conhecendo o CMMI Uma empresa que poderia ser a sua

3. Objetivos Apresentar de uma forma prática e divertida o modelo CMMI, seus benefícios e alguns cases; Questionar alguns “mitos”; Compartilhar alguns “axiomas”. Axioma - “premissa considerada necessariamente evidente e verdadeira(...)” Mito - “afirmação fantasiosa, inverídica, que é disseminada com fins de dominação, difamatórios, propagandísticos, como guerra psicológica ou ideológica” Fonte: Houaiss

4. Por que pensar nestas coisas * ? (a.k.a. * Motivação) * coisas: Termo a ser definido em um slide futuro. * a.k.a.: “Also known as” ou “Também conhecido como”

5. Por que pensar nestas coisas? Sucesso em projetos Somente 29% dos projetos verificados foram bem sucedidos, ou seja, saíram conforme o planejado.

6. Por que pensar nestas coisas? Sucesso em projetos (a evolução) Evolução de 13% em 10 anos!?!

7. Por que pensar nestas coisas? Considerando as informações anteriores, podemos pensar: Ahhhh... Mas estes dados são antigos (2004). Além disso, tratam de projetos do mundo inteiro. Com certeza os projetos brasileiros são melhores! Somente nós temos o “jeitinho brasileiro”. Somente nós somos penta!

8. Por que pensar nestas coisas? A fonte dos slides a seguir é o Estudo de Benchmarking em Gerenciamento de Projetos Brasil 2007 (Anexo 1 – Perspectiva por Setor) Disponível para download no endereço www.pmi.org.br Realizado pelos capítulos brasileiros do PMI (Project Management Institute) 184 empresas participaram (~60 da área de TI) “ É importante ressaltar que as informações apresentadas são resultado da compilação e análise de dados fornecidos pelas Organizações participantes, não tendo sido realizada, portanto, nenhum tipo de auditoria em relação à veracidade ou adequação dos dados.”

9. Por que pensar nestas coisas?

10. Por que pensar nestas coisas?

11. Por que pensar nestas coisas?

12. Por que pensar nestas coisas?

13. Por que pensar nestas coisas? Somente 30% das organizações da área de TI dizem não apresentar desvio relevante no orçamento.

14. Por que pensar nestas coisas? Problemas que ocorrem com mais frequência nos projetos da organização (1/2): Não cumprimento dos prazos Problemas de comunicação Mudanças constantes no escopo Escopo não definido adequadamente Recursos humanos insuficientes Riscos não avaliados corretamente Não cumprimento do orçamento

15. Por que pensar nestas coisas? Problemas que ocorrem com mais frequência nos projetos da organização (2/2): Mudanças de prioridade constantes Estimativas incorretas ou sem fundamento Falta de definição de responsabilidades Problemas com fornecedores Retrabalho em função da falta de qualidade do produto Falta de competência para gerenciar projetos Falta de uma ferramenta de apoio Falta de uma metodologia de apoio Falta de apoio da alta administração Falta de conhecimento técnico

16. Por que pensar nestas coisas? Agora, o que deve ser a principal motivação: E na minha empresa, como é? Enfrentamos problemas com prazo, custo, qualidade, satisfação do cliente, etc.?

17. Quais são as “coisas” que devem nos preocupar? Gerenciamento de projetos; Riscos; Comunicação; Custos; Etc... Gerenciamento de requisitos; Gerenciamento de configuração; Qualidade; Processos. Etc...

18. 1º Mito a ser “quebrado” “CMMI é a solução!” O CMMI não é (e nunca será) a solução dos seus problemas!

19. 1º Axioma a ser compartilhado O CMMI sozinho nunca será a solução, mas, sozinho, ele pode representar todo o problema Por favor, não vão embora! Entenderemos esta afirmação antes do final do evento.

20. Então, onde o CMMI entra?

21. O que é o CMMI ® ? Capability Maturity Model Integration ® Fontes : Houaiss e Merriam-Webster 1 : the quality or state of being capable 2 : a feature or faculty capable of development : POTENTIALITY 3 : the facility or potential for an indicated use or deployment 4 : a usually miniature representation of something 1 : the quality or state of being mature 2 : estado, condição (de estrutura, forma, função ou organismo) num estágio adulto; condição de plenitude em arte, saber ou habilidade adquirida 3 : estado ou condição de pleno desenvolvimento

22. O que é o CMMI? Compilação de boas práticas no processo de diversas empresas de software Mostra “O QUÊ” fazer, e não “COMO” fazer Práticas distribuídas em 22 “áreas de processo” Área de Processo = PA (Process Area)

23. O que é o CMMI? Mantido pelo SEI (Software Engineering Institute) Universidade Carnegie Mellon http://www.sei.cmu.edu/cmmi Sponsors: DoD (U.S. Department of Defense) NDIA (National Defense Industrial Association) Foco da apresentação: CMMI for Development (CMMI-DEV)

24. O que é o CMMI? Um pouco de história... 1987 1991 1995 1997 2000 2002 First CMM Published Model Refined and Published as SW-CMM v1.0 SW-CMM v1.1 Published 1993 Software Acquisition (SA-CMM), Systems Engineering (SE-CMM), Integrated Product Development (IPD-CMM), Organizational Workforce Capability Development (People CMM) Developed CMMI Initiative Launched CMMI-SE/SW Version 1.02 Published CMMI-SE/SW/IPPD Version 1.1 Published 2006 2007 CMMI for Development v1.2 CMMI for Acquisition v1.2 Fontes: -CMMI Second Edition -http://www.rtpspin.org/Information/IntroCMMIv5.ppt 2008 CMMI for Services v1.2

25. O que é o CMMI? CMMI Model Foundation CMMI-DEV CMMI-ACQ CMMI-SVC Fonte: -http://www.sei.cmu.edu/cmmi/models/CMMI-Services-status.html

26. Estrutura do modelo

27. Estrutura do modelo 22 áreas de processo distribuídas em: 4 categorias 5 níveis de maturidade Mas o que é “área de processo”?

28. Estrutura do modelo Área de processo (Process Area) É o agrupamento de práticas comuns de uma determinada “disciplina”. É onde fica o “O que fazer”.

29. Estrutura do modelo

30. Demonstração 01 Detalhando uma área de processo

31. Detalhando uma área de processo Nome da PA Categoria Nível de Maturidade Propósito da PA Notas Introdutórias

32. Detalhando uma área de processo Áreas de Processo Relacionadas

33. Detalhando uma área de processo Sumário dos objetivos e práticas específicas

34. Detalhando uma área de processo Prática específica Produtos de trabalho típicos Subpráticas

35. Detalhando uma área de processo Prática genérica

36. Detalhando uma área de processo

37. Os “Objetivos Específicos” ( Specific Goals) Apresenta características únicas que devem ser seguidas para satisfazer a área de processo; É utilizada nas avaliações para verificar se a área de processo está sendo seguida.

38. Os “Objetivos Genéricos” ( Generic Goals) Todas as PAs devem seguir os objetivos genéricos correspondentes ao “capability ou maturity level” que se almeja; Apóiam a institucionalização do processo.

39. Áreas de processo distribuídas por categorias

40. Áreas de processo distribuídas por níveis de maturidade Processos ad hoc Œ Initial Configuration Management (CM) Measurement and Analysis (MA) Project Monitoring and Control (PMC) Project Planning (PP) Process and Product Quality Assurance (PPQA) Requirements Management (REQM) Supplier Agreement Management (SAM)  Managed Decision Analysis and Resolution (DAR) Integrated Project Management +IPPD (IPM) Organizational Process Definition +IPPD (OPD) Organizational Process Focus (OPF) Organizational Training (OT) Product Integration (PI) Requirements Development (RD) Risk Management (RSKM) Technical Solution (TS) Validation (VAL) Verification (VER) Ž Defined  Organizational Process Performance (OPP) Quantitative Project Management (QPM) Quantitatively Managed  Causal Analysis and Resolution (CAR) Organizational Innovation and Deployment (OID) Optimizing

41. Mas... Pra que tudo isto?

42. Representações (a.k.a. “formas de implementação do modelo”)

43. Representações Contínua

44. Representações Contínua Especialização em áreas de processos específicas Permite o foco em determinada(s) necessidade(s) Capability levels. Grande vantagem! Fornece flexibilidade Custo de implementação menor (considerando a representação por estágio) Permite atuação em categorias: Engineering; Process Management; Project Management; Support.

45. Áreas de processo distribuídas por categorias

46. Capability Levels 1 2 3 4 5 Objetivos específicos da área de processo são atendidos Processo gerenciado (monitorado, controlado, etc.) Processo definido para toda a organização Processo controlado utilizando estatística e técnicas quantitativas Melhoria contínua do processo... Optimizing Quantitatively Managed Performed Managed Defined Incomplete 0 Onde as coisas simplesmente acontecem

47. Capability Levels Exemplo:

48. Representações Por estágio

49. Representações Por estágio Foco em um conjunto de áreas de processo Demonstra a “experiência” da organização de uma forma simples: Nível de Maturidade É mais fácil de “vender” Mais “simples” Mais utilizada Pode ser um caminho interessante para organizações que estão iniciando o plano de melhoria do processo de software (SPI Plan)

50. Áreas de processo distribuídas por níveis de maturidade Processos ad hoc Œ Initial Configuration Management (CM) Measurement and Analysis (MA) Project Monitoring and Control (PMC) Project Planning (PP) Process and Product Quality Assurance (PPQA) Requirements Management (REQM) Supplier Agreement Management (SAM)  Managed Decision Analysis and Resolution (DAR) Integrated Project Management +IPPD (IPM) Organizational Process Definition +IPPD (OPD) Organizational Process Focus (OPF) Organizational Training (OT) Product Integration (PI) Requirements Development (RD) Risk Management (RSKM) Technical Solution (TS) Validation (VAL) Verification (VER) Ž Defined  Organizational Process Performance (OPP) Quantitative Project Management (QPM) Quantitatively Managed  Causal Analysis and Resolution (CAR) Organizational Innovation and Deployment (OID) Optimizing

51. Representações Por estágio Níveis de Maturidade: 1 [Initial] Semelhante ao “capability level 0”; Onde as coisas simplesmente acontecem; O “sucesso” nos projetos acontece “por acaso”; “ Por acaso, temos alguns heróis...” “ Por acaso, o cliente era mais desorganizado...” É normal estouro de prazo e custos (entre outros problemas); Ambiente sem controle (caos); Grande dependência dos heróis (mas não é qualquer herói...)

52. Jack Bauer – O herói das empresas nível 1

53. Jack Bauer – O herói das empresas nível 1 Está sempre sob pressão; Nunca tira férias; Anda sempre estressado; Nunca tem tempo para os amigos; Nunca se diverte; Sempre tem que trabalhar 24 horas direto; Até consegue terminar o projeto, mas...

54. Representações Por estágio Níveis de Maturidade: 2 [Managed] Recursos são definidos; Projetos são planejados e monitorados; Medições são coletadas; Requisitos são gerenciados; As coisas deixam de “simplesmente acontecer”...

55. Representações Por estágio Níveis de Maturidade: 3 [Defined] Processo definido para a organização; “ Portal de Processos”, “Processo de Desenvolvimento de Software”, etc. Customização do processo para projetos (a partir do processo padrão); Evolução do nível 2.

56. Representações Por estágio Níveis de Maturidade: 4 [Quantitatively Managed] Controle estatístico; Previsibilidade; Base de medições utilizada para tomada de decisão; É fundamental que os níveis 2 e 3 estejam “rodando perfeitamente”; High Level Maturity.

57. Representações Por estágio Níveis de Maturidade: 5 [Optimizing] Inovação; Revisões buscando refletir alterações nos objetivos de negócio; Melhoria contínua utilizando dados estatísticos; Estado da arte; High Level Maturity;

58. 2º Mito a ser “quebrado” “ CMMI acaba com os heróis.” A partir do nível 2 temos um novo herói...

59. James Bond – O herói das empresas nível 2 a 5

60. James Bond – O herói das empresas nível 2 a 5 Herói potencializado; Consegue planejar seus projetos; Tem os recursos definidos, de acordo com o projeto; Tem tempo para estudar e utilizar novas tecnologias; Tem tempo para os amigos; Consegue se divertir e até namorar...

61. Conhecendo as PAs

62. PAs do Nível 2 Configuration Management (CM) Measurement and Analysis (MA) Project Monitoring and Control (PMC) Project Planning (PP) Process and Product Quality Assurance (PPQA) Requirements Management (REQM) Supplier Agreement Management (SAM)  Managed Processos ad hoc Œ Initial

63. Requirements Management (REQM) ML 2 Categoria: Engineering Sugere práticas para: Gestão dos requisitos; Identificação de inconsistências entre requisitos e produtos do projeto.

64. Project Monitoring and Control (PMC) ML 2 Categoria: Project Management Sugere práticas para: Acompanhamento do projeto; Ações corretivas a serem tomadas em desvios significativos do plano .

65. Project Planning (PP) ML 2 Categoria: Project Management Sugere práticas para: Criação do plano de projeto; Revisão e aprovação do plano.

66. Supplier Agreement Management (SAM) ML 2 Categoria: Project Management Sugere práticas para: Estabelecer acordos com os fornecedores; Gerenciar os acordos com os fornecedores.

67. Configuration Management (CM) ML 2 Categoria: Support Process Sugere práticas para: Estabelecer e manter a integridade dos produtos de trabalho do projeto; Gerenciar mudanças.

68. Measurement and Analysis (MA) ML 2 Categoria: Support Process Sugere práticas para: Criação de medições ( úteis ); Coleta, análise, divulgação e armazenagem das medições coletadas.

69. Process and Product Quality Assurance (PPQA) ML 2 Categoria: Support Process Sugere práticas para: Verificar aderência dos projetos aos processos; Acompanhar inconsistências e “garantir” que serão resolvidas. Fiscal? Depende…

70. PAs do Nível 3 Processos ad hoc Œ Initial Configuration Management (CM) Measurement and Analysis (MA) Project Monitoring and Control (PMC) Project Planning (PP) Process and Product Quality Assurance (PPQA) Requirements Management (REQM) Supplier Agreement Management (SAM)  Managed Decision Analysis and Resolution (DAR) Integrated Project Management +IPPD (IPM) Organizational Process Definition +IPPD (OPD) Organizational Process Focus (OPF) Organizational Training (OT) Product Integration (PI) Requirements Development (RD) Risk Management (RSKM) Technical Solution (TS) Validation (VAL) Verification (VER) Ž Defined

71. Product Integration (PI) ML 3 Categoria: Engineering Sugere práticas para: Planejar a integração do produto; Garantir a compatibilidade; Realizar a “montagem”.

72. Requirements Development (RD) ML 3 Categoria: Engineering Sugere práticas para: Levantar requisitos do cliente; Levantar requisitos do produto; Analisar e validar requisitos.

73. Technical Solution (TS) ML 3 Categoria: Engineering Sugere práticas para: Projetar, desenvolver e implementar soluções para os requisitos levantados.

74. Validation (VAL) ML 3 Categoria: Engineering Sugere práticas para: Validar se você fez a coisa certa.

75. Verification (VER) ML 3 Categoria: Engineering Sugere práticas para: Validar se você fez a coisa da forma correta.

76. Organizational Process Definition +IPPD (OPD) ML 3 Categoria: Process Management Sugere práticas para: Estabelecer e manter ativos do processo organizacional. Processo Padrão; Ciclo de Vida; Critérios de customização; Repositório de medições; Ambiente de trabalho; Biblioteca de ativos do processo.

77. Organizational Process Focus (OPF) ML 3 Categoria: Process Management Sugere práticas para: Identificar oportunidades de melhoria do processo; Planejar, implementar e disponibilizar melhorias no processo; Avaliação do processo; Comitê responsável pelo processo: EPG (Engineering Process Group).

78. Organizational Training (OT) ML 3 Categoria: Process Management Sugere práticas para: Levantar necessidades de treinamento; Planejar e realizar treinamentos necessários.

79. Integrated Project Management +IPPD (IPM) ML 3 Categoria: Project Management Sugere práticas para: Customizar o processo para o projeto; Garantir o envolvimento dos stakeholders.

80. Risk Management (RSKM) ML 3 Categoria: Project Management Sugere práticas para: Identificar, analisar e mitigar riscos.

81. Decision Analysis and Resolution (DAR) ML 3 Categoria: Support Sugere práticas para: Analisar as possíveis decisões utilizando um processo de avaliação formal; Avaliar as alternativas e selecionar a solução.

82. PAs do Nível 4 Processos ad hoc Œ Initial Configuration Management (CM) Measurement and Analysis (MA) Project Monitoring and Control (PMC) Project Planning (PP) Process and Product Quality Assurance (PPQA) Requirements Management (REQM) Supplier Agreement Management (SAM)  Managed Decision Analysis and Resolution (DAR) Integrated Project Management +IPPD (IPM) Organizational Process Definition +IPPD (OPD) Organizational Process Focus (OPF) Organizational Training (OT) Product Integration (PI) Requirements Development (RD) Risk Management (RSKM) Technical Solution (TS) Validation (VAL) Verification (VER) Ž Defined  Organizational Process Performance (OPP) Quantitative Project Management (QPM) Quantitatively Managed

83. Organizational Process Performance (OPP) ML 4 Categoria: Process Management Sugere práticas para: Verificar performance dos processos no atendimento dos objetivos.

84. Quantitative Project Management (QPM) ML 4 Categoria: Project Management Sugere práticas para: Verificar quantitativamente o desempenho do projeto.

85. PAs do Nível 5 Processos ad hoc Œ Initial Configuration Management (CM) Measurement and Analysis (MA) Project Monitoring and Control (PMC) Project Planning (PP) Process and Product Quality Assurance (PPQA) Requirements Management (REQM) Supplier Agreement Management (SAM)  Managed Decision Analysis and Resolution (DAR) Integrated Project Management +IPPD (IPM) Organizational Process Definition +IPPD (OPD) Organizational Process Focus (OPF) Organizational Training (OT) Product Integration (PI) Requirements Development (RD) Risk Management (RSKM) Technical Solution (TS) Validation (VAL) Verification (VER) Ž Defined  Organizational Process Performance (OPP) Quantitative Project Management (QPM) Quantitatively Managed  Causal Analysis and Resolution (CAR) Organizational Innovation and Deployment (OID) Optimizing

86. Organizational Innovation and Deployment (OID) ML 5 Categoria: Process Management Sugere práticas para: A partir dos objetivos de negócio, selecionar e implementar melhorias no processo.

87. Causal Analysis and Resolution (CAR) ML 5 Categoria: Support Sugere práticas para: Identificar e analisar causas de defeitos; Tomar ações de prevenção.

88. Avaliando o trabalho (a.k.a. “buscando o ‘certificado’”)

89. SCAMPI Standard CMMI® Appraisal Method for Process Improvement Método utilizado para avaliar aderência do processo da empresa ao CMMI Deve ser realizado por um lead appraiser Deve ser realizado a cada 3 anos (SCAMPI 1.2) Classes A, B ou C

90. Complicado? Depende do ângulo...

91. Demonstração 02 Uma empresa que poderia ser a sua...

92. Cenário Nome da empresa: UCT Nº de funcionários: ~120 Tipo: Fábrica de software e projetos Situação: Jack Bauer é gerente de projetos na UCT, ele anda um pouco estressado, pois nenhum dos projetos possui um cronograma confiável. Além disso, o cliente muda de idéia toda hora, solicitando alterações direto para os desenvolvedores. Sem contar outros problemas que não cabem aqui...

93. Nosso objetivo

94. O diagnóstico Alô... Bill? Tem um minuto? Prossiga, Jack. Fiz um levantamento em nossos projetos e percebi que 95% são concluídos fora do prazo e custo... Além disso, 80% dos projetos teve desvio de pelo menos 70% do prazo e 55% do custo. Por isso, acredito que devemos fazer algo. Posso coordenar este trabalho? Vá em frente, Jack.

95. O diagnóstico Não temos uma forma de estimar o tamanho, esforço e nem o custo dos projetos; O cliente não se compromete com o planejado, pois nada é planejado, simplesmente realizamos uma reunião entre desenvolvedor e cliente e “saímos fazendo”; Os riscos não são levantados, consequentemente não temos gestão de riscos;

96. O diagnóstico O monitoramento é feito em conversas de corredor, o humor do cliente conta muito nas ações que serão tomadas; Os desenvolvedores trocam muitas idéias entre si, mas as lições aprendidas não são registradas.

97. Vamos ajudar o Jack?

98. O que fazer? Alô... Chefe? Tem um minuto? Fala, aspirante! Precisamos da sua ajuda... Diagnosticamos sérios problemas na gestão dos projetos, mas não sabemos “O QUE” fazer... Então, aspira, por que vocês não dão uma olhada no CMMI-DEV? Lá vocês podem verificar pelo menos as práticas das PAs “PP” e “PMC”, que focam o planejamento e o monitoramento dos projetos. É mesmo... Valeu! E não me chama de aspira! Ok! Boa sorte, aspira!

99. Como fazer?

100. Como fazer?

101. Como fazer?

102. O resultado Jack, parabéns! Pode ir em frente com a sua idéia. Bill, nossa iniciativa foi um sucesso! O processo que definimos já está em uso e ajudando na redução dos desvios de custo e prazo. Inclusive percebi que nosso processo está aderente a algumas práticas do modelo CMMI. Com o CMMI nível 2 ou 3 poderíamos atender novos clientes. O que acha de realizarmos um diagnóstico de aderência e aproveitarmos a oportunidade de negócio?

103. Compartilhando experiências (a.k.a. “alguns axiomas”)

104. Compartilhando experiências O diagnóstico deve ser muito bem feito Foto da situação atual Saiba onde você deseja chegar Quais são as metas? “ Por que estamos iniciando esta empreitada?” A iniciativa deve estar alinhada com a estratégia da empresa Alguém “forte” na organização deve ser o padrinho do projeto Normalmente envolve mudança cultural Traga o pessoal de RH para o projeto

105. Compartilhando experiências Conte com os “integradores” TODOS devem participar (desde analistas até diretores) Alguém deve gerenciar a iniciativa Seja “subversivo” Sempre questionem! “ Por que fazer assim se podemos fazer diferente?” Seja um “herege” Cuidado com os “religiosos”! “ Misture” práticas, metodologias, ferramentas e etc. Comunique!

106. Compartilhando experiências O CMMI deve ser um dos resultados da mudança Cuidado com àqueles que só estão preocupados com o “diploma” na parede Aproveite a oportunidade Mude de “Meu cliente exige que eu tenha CMMI.” para “O que posso oferecer de diferente utilizando o processo que criamos?”

107. Os últimos mitos a serem quebrados “CMMI é coisa de ‘indiano’.” “CMMI é sinônimo de burocracia.” “CMMI bloqueia a criatividade.” “CMMI só funciona em empresas grandes.”

108. Case

109. Empresa “S” Resultados em 24 meses (CMMI 3) Produtividade: aumento de 67% Todos os projetos entregues no prazo; Previsibilidade: Custo - 83% Esforço - 87% Tamanho - 82% Satisfação: Interna – 150 melhores empresas para se trabalhar (2005 e 2006)

110. Adoção Process Maturity Profile – Setembro de 2007 www.sei.cmu.edu/appraisal-program/profile/profile.html

111. Adoção

112. mps.Br

113. mps.Br Melhoria de processo do software brasileiro www.softex.br/mpsbr Foco em micro, pequenas e médias empresas Custo de implementação e avaliação menor Foi definido em conformidade ao CMMI for Development Níveis: G (Parcialmente Gerenciado) até A (Em otimização)

114. Vamos fazer uma revisão?

115. O que é o CMMI? Compilação de boas práticas no processo de diversas empresas de software Mostra “O QUÊ” fazer, e não “COMO” fazer Práticas distribuídas em 22 “áreas de processo” Área de Processo = PA (Process Area)

116. Representações Forma de implementar o modelo Maturity Levels 2 a 5 = Capability Levels 2 a 5 Diferença... Maturity Levels: Refere-se a um conjunto de áreas de processo Capability Levels: Refere-se a uma área de processo

117. Aguardo sua visita! www.AlessandroAlmeida.com Bate-Papo de Buteco Blog do Alessandro Células de Estudo Quality|Process

118. Muito obrigado! [email_address]

119. APÊNDICE

120. Como tudo se integra?

121. Process Management Basic Process Management Process Areas

122. Process Management Advanced Process Management Process Areas

123. Project Management Basic Project Management Process Areas

124. Project Management Advanced Project Management Process Areas

125. Engineering Engineering Process Areas

126. Support Basic Support Process Areas

127. Support Advanced Support Process Areas