Norma ANSI PMBOK Guide PDF

**2 Normalização da Gestão de Projetos** **2.1 Standards para os Projetos de Software** Os processos e procedimentos de muitas organizações de serviços e de desenvolvimento de software são baseados nos standards produzidos pelos comités conjuntos da International Standards Organization (ISO), da I...

**2 Normalização da Gestão de Projetos** **2.1 Standards para os Projetos de Software** Os processos e procedimentos de muitas organizações de serviços e de desenvolvimento de software são baseados nos standards produzidos pelos comités conjuntos da International Standards Organization (ISO), da International Electrotechnical Commission (IEC) e do Institute for Electrical and Electronic Engineers (IEEE) para a engenharia de software, no PMBOK® Guide do Project Management Institute (PMI) e nos Capability Maturity Models Integrated (CMMI) do Software Engineering Institute (SED). Alguns standards ISO/IEC e IEEE que foram harmonizados e emitidos como standards conjuntos (ISO/IEC/IEEE) incluem: - - Os CMMI, desenvolvidos e mantidos pelo SEI incluem: - - - Estes modelos serão explicados ao longo do capítulo. Em 2013, o PMI e a IEEE Computer Society lançaram em conjunto um novo standard dedicado aos projetos de desenvolvimento de software - o Software Extension to the PMBOK Guide Fifth Edition. O principal contributo desta extensão ao PMBOK Guide é a descrição de processos que são aplicáveis à gestão de projetos de software com ciclos de vida adaptativos. Os métodos de desenvolvimento adaptativos e os ciclos de vida ajustam-se bem ao desenvolvimento de software e à gestão de projetos de software, porque tiram partido da natureza intangível do software. Usados em conjunto, o PMBOK Guide e essa extensão fornecem uma visão equilibrada de métodos, ferramentas e técnicas para a gestão de projetos de software, adaptáveis aos diversos ciclos de vida desde os altamente previsíveis (modelos em cascata) até aos altamente adaptativos (modelos ágeis). **2.2 Norma ANSI PMBOK Guide** O PMBOK Guide do PMI é um repositório de conhecimento acerca da gestão de projetos, que inclui práticas tradicionais provadas que são amplamente aplicadas, bem como práticas inovadoras que estão a emergir na profissão. É atualmente um standard ANSI (American National Standards Institute). A publicação do PMI tem como objetivo identificar os principais elementos do corpo de conhecimento, geralmente reconhecidos como boas práticas, bem como fornecer e promover um léxico comum para a conversação, a escrita e a aplicação da gestão de projetos. O PMI usa este documento como uma referência básica para os seus programas de desenvolvimento profissional, nomeadamente para as seguintes certificações: - - - - - O PMBOK Guide a Software Extension to the PMBOK Guide descrevem o conhecimento que é exclusivo do domínio da gestão de projetos e que se interliga com outras disciplinas da gestão (Figura 2.1). Figura 2.1-Relação entre as áreas de conhecimento e outras disciplinas da gesthe O conhecimento da gestão de projetos descrito no PMBOK Guide e na Sa Extension to the PMBOK Guide compreende - - - **2.2.1 Ciclo de Vida dos Projetos de Software** Os gestores de projeto, ou a organização, podem dividir os projetos em fases, com o objetivo de proporcionar um melhor controlo de gestão com as ligações adequadas às operações rotineiras. Estas fases são conhecidas, no seu conjunto, como o ciclo de vida do projeto. O ciclo de vida de um projeto define as fases que ligam o início do projeto com o seu término. Por exemplo, quando uma organização identifica uma oportunidade à qual gostaria de responder, autoriza, normalmente, a realização de um estudo de viabilidade para decidir se deve, ou não, realizar o projeto. A definição de ciclo de vida do projeto pode ajudar o gestor de projeto a clarificar se deve tratar o estudo de viabilidade como a primeira fase do projeto ou como um projeto separado. Quando a conclusão deste esforço preliminar não é claramente identificável, é preferível tratá-lo como um projeto separado (PMBOK Guide, 2012\]. Não existe uma maneira única e melhor de definir um ciclo de vida ideal para um projeto. O conceito abarca um espetro contínuo que vai desde o ciclo de vida predefinido (modelos em cascata, SDLC e em V) até ao ciclo de vida adaptativo (modelos incrementais e modelos ágeis). A Figura 2.2 ilustra o espetro de ciclos de vida para projetos de software. Figura **2.2** - Espetro de ciclos de vida de projetos de software Os ciclos de vida altamente predefinidos são caracterizados pela ênfase na especificação de requisitos e no planeamento detalhado durante as fases de iniciação e planeamento do projeto. Planos detalhados baseados em requisitos e restrições conhecidos reduzem risco e o casto. São igualmente planeados os momentos no projeto em que as partes interessadas-chave são envolvidas. Os ciclos de vida altamente adaptativos são caracterizados pela progressiva especificação dos requisitos, tendo como base ciclos curtos de desenvolvimento iterativo. O risco e o custo são reduzidos através da evolução progressiva de planos iniciais. As partes interessadas-chave são envolvidas de forma contínua. Para os ciclos de vida intermédios do espetro aplicam-se as seguintes considerações: - - É importante frisar que os ciclos de vida dos projetos de software são complexos e multidimensionais. Incluem atividades como gestão da configuração, garantia da qualidade de processos e produtos, testes independentes e outras atividades conforme considerado necessário e adequado. Além disso, os projetos de software podem ser elementos de programas, e podem incluir interfaces com outras unidades funcionais da organização que desenvolve ou patrocina o desenvolvimento do software, com outros projetos e/ou com grupos ou subprojetos subcontratados. Existe uma diferença entre planear e executar um projeto de software e preparar e entregar o produto resultante. O cliente e outras partes interessadas-chave de um projeto com ciclo de vida predeterminado poderão escolher entre: - - - - De modo similar, um cliente e outras partes interessadas-chave de um projeto de software com ciclo de vida adaptativo poderão decidir observar demonstrações de funcionalidades evolutivas no final de ciclos de iteração, e terem uma entrega única no final do projeto, ou aceitar a entrega de incrementos do produto em intervalos planeados. São igualmente possíveis outras variações: - - - - A execução do projeto e a entrega do produto são atividades distintas. O modelo do ciclo de vida para a execução do projeto e a entrega do produto deve ser desenhado tão cuidadosamente como o produto de software, tendo como base fatores como os listados na Figura 2.2. Algumas organizações estabelecem políticas que padronizam todos os projetos com um ciclo de vida único, ao passo que outras permitem à equipa de gestão do projeto escolher o ciclo de vida mais adequado ao seu contexto. Os ciclos de vida dos projetos definem normalmente: - - - - As descrições dos ciclos de vida podem ser muito genéricas ou muito detalhadas. Neste último caso, podem incluir formulários, gráficos ou checklists, para assegurar estrutura e controlo. **2.2.1.1** Características do Ciclo de Vida dos Projetos de Software O desenvolvimento de produtos de software requer tipicamente um conjunto de processos que se desenrolam ao longo de diversas fases. De acordo com o standard IEC/IEEE 12207 \[ISO/IEEE, 2008\], o desenvolvimento de software inclui as seguintes fases: - - - - - - Os ciclos de vida predefinidos partilham um certo número de características comuns: - - - **Figura 2.3 - Níveis típicos de custos e de esforço ao longo do ciclo de vida dos projetos** Há poucos ciclos de vida que sejam idênticos; alguns podem ter quatro ou cinco fases, ao passo que outros podem possuir nove ou mais. **Exemplo:** O ciclo de desenvolvimento de software de uma organização pode possuir uma fase de desenho única, ao passo que outro pode ter fases separadas para o desenho da arquitetura e o desenho detalhado. Os ciclos de vida adaptativos tendem a reduzir o pico do nível do custos e de pessoal durante a fase de execução e monitorização e controlo, deslocando o perfil inteiro para os estágios iniciais. Isto é possível porque os ciclos de vida adaptativos **validam incrementos de software funcional numa base permanente** para minimizar o impacto e o custo de alterações subsequentes. Além disso, os ciclos de vida adaptativos que mantêm um nível constante de pessoal durante a execução e monitorização e controlo tendem a nivelar o perfil durante essas etapas do ciclo de vida. **2.2.1.2 Ciclos de Vida Predefinidos** Ciclos de vida previsíveis são aqueles para os quais o âmbito do projeto, bem como o tempo e o custo requeridos para desenvolver e entregar esse âmbito, são determinados tão cedo quanto possível no ciclo de vida do projeto \[PMBOK® Guide, 2012\]. Um ciclo de vida predefinido para projetos de software é caracterizado por uma sequência de fases de desenvolvimento sobreponíveis com feedback para as fases anteriores (e repetição destas) conforme necessário. Exemplos deste tipo de modelo são: - - No Capitulo 22 serão detalhados os dois modelos. **2.2.1.3 Ciclos de Vida Iterativos e Incrementais** Ciclos de vida iterativos e incrementais são aqueles em que o âmbito do projeto é geralmente determinado no início do ciclo de vida do projeto, mas as estimativas do tempo e do custo são modificadas de forma regular à medida que aumenta a compreensão do produto por parte da equipa de projeto. Para os produtos de software, os requisitos são frequentemente alterados juntamente com as estimativas de tempo e custo, o que resulta na necessidade de efetuar constantes compromissos entre esses três fatores. Um, ou mais desses fatores, poderá ser restringido, limitando assim as opções de compromisso. Se forem restringidos os três fatores, isso resulta geralmente na falha do projeto e do produto. São exemplos de modelos deste tipo de ciclo de vida: - - - O modelo de prototipagem será desenvolvido no Capítulo 22. **2.2.1.4 Ciclos de Vida Adaptativos** Os ciclos de vida adaptativos - também conhecidos como métodos ágeis - têm como objetivo facilitar a mudança e requerem um elevado grau de permanente envolvimento das partes interessadas. \"Ágil\" não é um ciclo de vida, mas antes um termo utilizado para caracterizar certos atributos que os ciclos de vida adaptativos partilham em diferentes graus. As principais características dos ciclos de vida adaptativos são as seguintes: - - - - - - - - A curta duração das iterações (2 a 4 semanas) permite que o trabalho que tenha de ser refeito devido a alterações ou erros seja integrado com as iterações, ao invés de ser acumulado como uma larga porção de trabalho a ser realizado no final do desenvolvimento do software (situação tipica nos ciclos de vida predeterminados). Refazer trabalho em pequenos incrementos é mais eficaz e económico do que em grandes porções durante as fases de testes e integração típicas dos ciclos de vida predeterminados em virtude de os especialistas de software estarem na posse de todos os detalhes e o volume de trabalho refeito ser reduzido. Os ciclos de vida adaptativos são particularmente adequados quando é dificil ter uma definição das necessidades do cliente no início do projeto, ou quando a tecnologia é usada de uma forma diferente da que a equipa está habituada. Embora as práticas adaptativas tendam a melhorar a qualidade global e reduzir o Total Cost of Ownership (TCO) do software ao longo do ciclo de vida do produto, a curva do respetivo custo da qualidade é diferente da curva dos ciclos de vida predeterminados. São exemplos de modelos de cico de vida adaptativo: - - - Os dois primeiros modelos serão desenvolvidos no Capítulo 22. **2.2.2 Características das Fases dos Projetos** Uma fase de um projeto é caracterizada pela conclusão e aprovação de um ou mais entregáveis. Estes e, por conseguinte, as fases são parte de um processo geralmente sequencial, desenhado de modo a assegurar o controlo adequado do projeto e a garantir a obtenção do produto ou serviço desejado, que constitui o objetivo do projeto. Por motivos de dimensão, complexidade, nível de risco e restrições de cash flow, num projeto específico as fases podem ser decompostas em subfases, em que cada uma está alinhada com um, ou mais, entregáveis específicos, por motivos de monitorização e controlo. O final de uma fase do projeto é marcado, regra geral, por uma revisão técnica ou do desenho do trabalho concluído e dos entregáveis, para decidir a respetiva aceitação, a eventual necessidade de trabalho extra, ou o encerramento da fase. A conclusão formal de uma fase não inclui a autorização da fase subsequente. De modo a garantir um controlo eficaz, cada fase é formalmente iniciada para produzir um resultado (output) específico, detalhando o que é permitido e esperado para essa fase, conforme evidenciado na Figura 2.4. Pode realizar-se uma revisão de fim de fase\", com o objetivo explícito de obter autorização para encerrar a fase corrente e iniciar a subsequente. **Figura 2.4** - **Sequência típica de fases no ciclo de vida de um projeto** **2.2.3 Ciclo de Vida do Produto** O ciclo de vida de um produto de software inclui um ciclo de vida do projeto inicial, mas inclui igualmente os processos de deployment, suporte, manutenção corretiva, manutenção evolutiva, substituição e abandono do produto de software. A melhoria e a adaptação do software inicialmente entregue pode envolver vários ciclos de vida de projetos para além do inicial. A Figura 2.5 ilustra esta ideia. **Figura 2.5** - **Relação entre os ciclos de vida do projeto e do produto do projeto** **2.2.4 Processos da Gestão de Projetos** Ao longo de um projeto há que realizar dois tipos fundamentais de processos: - - O objetivo deste livro é o tratamento detalhado dos processos da gestão de projetos. Os outros processos pertencem à engenharia de software e a sua descrição detalhada está fora do âmbito deste livro. No entanto, no Capítulo 22 far-se-á uma breve descrição dos modelos de engenharia de software mais usados. **2.2.5 Grupos de Processos da Gestão de Projetos** De acordo com o modelo do PMBOK® Guide e da ISO 21500, os processos da gestão de projetos agregam-se em cinco grupos de processos: - - - - - A forma como estes cinco grupos de processos são aplicados aos projetos de software pode variar de projeto para projeto, dependendo dos ciclos de vida utilizados. Projetos de desenvolvimento de software baseados em ciclos de vida adaptativos envolvem interações frequentes e estreitamente coordenadas entre o cliente e o projeto, em particular na tradução de requisitos em planeamento, a qual é comunicada até à execução. É de particular importância notar que o fluxo dos processos não é estritamente unidirecional, em que a informação é alimentada sequencialmente de um processo para o seguinte. Em projetos de software é necessário um feedback frequente entre os cinco grupos de processos, de modo a assegurar que o produto de software em construção **é** consistente com os (possivelmente em constante mutação) requisitos, funcionalidades e expectativas. A documentação das decisões é necessária; no entanto, a documentação, só por si, não é suficiente para fornecer a compreensão necessária para implementar um produto de software que satisfaz as necessidades de um cliente ou uma empresa. Além da documentação, são necessárias frequentes interações interpessoais para proporcionar clareza para todas as partes interessadas; por isso, nestes projetos a ênfase é colocada no desenvolvimento de software utilizável e evolutivo em cada ciclo de desenvolvimento do ciclo de vida do projeto. É necessário gerir o projeto e o âmbito do produto, de forma a manter o equilíbrio entre eles. É igualmente importante reconhecer que o contínuo do ciclo de vida para os projetos de software não é linear- é multidimensional. Todos os processos e funções de suporte do desenvolvimento de software gestão da configuração, garantia da qualidade, documentação, testes independentes, etc. - devem ser adaptados para satisfazer as necessidades de cada tipo de ciclo de vida e de cada projeto de software. **2.2.6 Áreas de Conhecimento da Gestão de Projetos** O PMBOK® Guide organiza os 47 processos que integram os cinco grupos de processos da gestão de projetos em dez **áreas de conhecimento,** que se descrevem de seguida: - - - - - - - - - - A Figura 2.6 indica os processos elementares de cada uma das áreas de conhecimento. Os aspetos anteriormente descritos - fases do ciclo de vida do desenvolvimento de software, áreas de conhecimento da gestão de projetos e grupos de processos (estágios) da gestão de projetos constituem as três dimensões da gestão dos projetos de desenvolvimento de software que o gestor de projeto e a sua equipa têm de integrar e consolidar para que os projetos sejam bem-sucedidos. A Figura 2.7 mostra esquematicamente estas três dimensões. **Gestão do âmbito** - - - - - - **Gestão das comunicações** - - - **Gestão da integração** - - - - - - **Gestão do tempo** - - - - - - - **Gestão dos recursos humanos** - - - - **Gestão do custo** - - - - **Gestão da qualidade** - - - **Gestão do risco** - - - - - - **Gestão das aquisições** - - - - **Gestão das partes interessadas** - - - - Figura 2.6 - Áreas de conhecimento da gestão de projetos e respetivos processos **Figura 2.7 - Dimensões da gestão e desenvolvimento de projetos de software** **2.3 Norma ISO 21500** A norma ISO 21500 - Guidance on Project Management foi oficialmente lançada em agosto de 2012. Pouco tempo depois foi lançada a versão Portuguesa da norma, a NP ISO 21500 - Guia para a Gestão de Projetos. As duas normas - ANSI e ISO - são muito semelhantes. Ambas apresentam um conjunto de processos organizados de modo idêntico, por fase da gestão do projeto e tópico da gestão e projetos. Os **processos da** ISO são mais orientados para uma abordagem em cascata da definição do âmbito, **ao** invés de uma abordagem iterativa. Deste modo, a norma ISO será eventual- mente menos **atrativa** para as organizações orientadas para as metodologias Agile (ágeis). Ambos os standards - ANSI e ISO - estão estruturados em **estágios da gestão de projetos** (não em fases do projeto) e tópicos da gestão de projetos (áreas de conhecimento no PMBOK® Guide e grupos temáticos na ISO 21500). A Tabela 2.1 mostra os **39** processos da ISO 21500 e o respetivo agrupamento por grupos temáticos e **grupos** de processos. **Tabela 2.1 - Mapeamento dos grupos temáticos e dos grupos de processos na ISO 21500** **Tabela 22-Compass estratturas da 150 21500 de PMBOK Guille** A ISO 2500 inclui também a gestão do conhecimento, sem no entanto a tomar um grupo temático propriamente dito. O mais importante contributo da ISO foi a adição de grupo temático formal para lidar com as partes interessadas do projeto. No PMBOK Guide Fourth Edition (edição em vigor aquando do lançamento da ISO 21501, em agosto de 2012) este tema estava incluído na área de conhecimento de gestão das comunicações. Na 5.° edição do PMBOK Guide, lançada em dezembro de 2012, foi acrescentada igualmente uma área de conhecimento sobre este importantíssimo tema. **2.4 Capability Maturity Model Integration** **2.4.1 Enquadramento** Mais do que nunca as organizações procuram fornecer produtos melhores e de forma mais rápida e mais económicas. Em simultâneo, dada a crescente complexidade tecnológica dos produtos, é rara a empresa que desenvolve todas as componentes que integram os seus produtos. E muito frequente alguns componentes serem construidos internamente e outros serem adquiridos, sendo depois todos eles integrados num produto final. As organizações têm de ser capazes de gerir e controlar a complexidade, deste, desenvolvimento e manutenção dos produtos. Por outro lado, muitas organizações que não eram tipicamente empresas de software como, por exemplo, instituições financeiras e fabricantes de automóveis e de aviões descobriram que em grande parte do seu negócio dependem de software e que este último constitui muitas vezes o seu diferenciador face à concorrência. Os problemas que estas organizações tratam atualmente envolvem software e engenharia de sistemas, tomando-se estas disciplinas uma parte cada vez mais crítica dos seus negócios. Na essência, essas organizações são fabricantes de produtos que necessitam de possuir uma abordagem integrada à sua engenharia de sistemas e ao seu software, como forma de alcançar os seus objetivos de negócio. No mercado atual existem modelos de maturidade, standards, metodologias e linhas de orientação que podem ajudar uma organização a melhorar a sua forma de fazer negócio. No entanto, a maioria das metodologias de melhoramento disponíveis centra-se numa parte específica do negócio e não faz uma abordagem sistémica aos problemas que a maioria das organizações enfrenta. O CMMI proporciona uma oportunidade para evitar, ou mesmo eliminar, esses estrangulamentos e barreiras, através de modelos integrados que transcendem disciplinas. O CMMI engloba as melhores práticas que tratam do desenvolvimento e manutenção de produtos e que cobrem o ciclo de vida do produto desde a conceção até à entrega e manutenção. É colocada uma ênfase na engenharia de sistemas e na engenharia de software, em simultâneo, bem como na integração necessária para construir e manter o produto total. O projeto CMMI foi lançado com o objetivo de resolver o problema da utilização de múltiplos modelos de maturidade, através da combinação de três modelos-base: - - - A seleção destes três modelos específicos deveu-se à sua adoção por muitas organizações das comunidades de software e engenharia de sistemas e às diferentes abordagens de melhoria de processos que lhes estão subjacentes. Desenvolver um conjunto de modelos integrados envolveu mais do que a simples combinação de materiais dos modelos. Usando processos que promovem consensos, a equipa do CMMI construiu um modelo que acomoda múltiplas disciplinas e é suficientemente flexível para suportar as diferentes abordagens dos modelos que lhe serviram de fonte. A estrutura do CMMI foi desenhada igualmente com o propósito de suportar a futura integração de outras disciplinas. Além disso, é consistente e compatível com o ISO/IEC 15504 Technical Report for Software Process Assessment \[International Standards Organization, 1998\]. Diversas versões do CMMI foram efetuadas desde 2001 para incorporarem milhares de pedidos de alteração e melhorias sucessivas. A versão atualmente disponível é a 1.3 - CMMITM for Systems Engineering, Software Engineering, Integrated Product and Process Development, and Supplier Sourcing (CMMI-SE/SW/IPPD/SS, V1.3). **2.4.2 Cobertura dos Corpos de Conhecimento** O objetivo do CMMI é proporcionar um modelo de maturidade que não só cubra o desenvolvimento e manutenção de produtos e serviços, mas que possibilite também uma estrutura extensível que permita a incorporação de novos corpos de conhecimento. Atualmente, estão disponíveis quatro **corpos de conhecimento**, ou disciplinas, para o planeamento de processos usando o CMMI: - - - - Uma área de processo, na terminologia do CMMI, corresponde a um grupo de melhores práticas numa área que, quando implementadas coletivamente, satisfazem um conjunto de objetivos considerados importantes para a obtenção de melhorias significativas nessa área. Todos os CMM possuem áreas de processo definidas por níveis (Tabela 2.3). Um outro conceito importante refere-se às \"amplificações da disciplina\", que si componentes do modelo que contêm informação relevante para uma disciplina particular. Por exemplo, quando se refere que uma área é \"para engenharia de software\", iss significa uma amplificação da disciplina para engenheiros de software. Essa informaç aplica-se apenas à melhoria dos processos de software. Para atingir os seus objetivos, uma organização tem de aplicar seletivamente as áreas processo adequadas A Tabela 2.3 mostra as áreas de processo do CMMI **Tabela 2.3 - Áreas de processo do CMMI** **2.4.3 Compatibilização de Diferentes Abordagens** A definição de um Capability Maturity Model (CMM) permite à comunidade desenvolver modelos que possuem diferentes abordagens. Para ser considerado um CMM, qualquer modelo tem de: - - Todos os modelos-fome do CMMI são considerados CMM, embora cada um contemple uma abordagem diferente. A revisão e o exame de cada modelo-fonte conduziram à descoberta de dois tipos de metodologias de apresentação dos CMM, que foram designados por \"representações. Uma representação reflete a organização, uso e apresentação das componentes de um modelo Existem dois tipos de representações do modelo do CMMI faseada (staged) e continua: - - O CMMI suporta ambas as representações em virtude da familiaridade que as pessoas tinham com os modelos de origem e a preocupação com o facto de que, se fosse escolhida uma representação em detrimento de outra, parte da comunidade não adotaria o CMMI Embora isto acrescente complexidade ao CMMI, proporciona igualmente uma transição mais fácil para o CMMI para as pessoas familiarizadas com uma das representações. **2.4.3.1 Representação Continua** Esta representação proporciona uma abordagem flexível da melhoria dos processos. Uma organização poderá optar por melhorar o desempenho de uma parte problemática de um dos seus processos ou trabalhar em diversas áreas que estão estreitamente alinhadas com os objetivos de negócio da organização. A representação continua permite igualmente a uma organização melhorar diferentes processos com taxas de desempenho diferentes. Existem, no entanto, algumas limitações as escolhas de uma organização, devido às dependências entre algumas áreas de processe Para medir o caminho de melhoria ao longo de cada área de processo, desde um processo com mau desempenho até um processo otimizado, usam-se níveis de aptidão (capability levels) Exemplo: Uma organização pode desejar atingir um nível de aptidão 2 numa área de processo e um nível de aptidão 4 noutra área. Quando o processo atingir um determinado nível de aptidão, a organização pode estabelecer como **objetivo** o nível de aptidão seguinte para a mesma área de processo, ou pode decidir alargar o seu âmbito e criar o mesmo nível de aptidão para um número maior de áreas de processo. Quando se conhecem os processos que necessitam de melhoria na organização e se compreendem as dependências entre as áreas de processo descritas no CMMI, a representação contínua constituirá uma boa escolha. **2.4.3.2 Representação Faseada** A representação faseada proporciona uma forma estruturada de abordar a melhoria dos processos passo a passo. A consecução de cada fase ou patamar dá a garantia de que foi obtida uma melhoria adequada como alicerce para a fase seguinte. As áreas de processo são organizadas por níveis de maturidade, que retiram ao processo de melhoria muito trabalho de improvisação. Esta forma de representação prescreve a ordem de implementação para cada área de processo, de acordo com níveis de maturidade, os quais definem o caminho de melhoria para uma organização, desde o nível primário inicial (ad hoc) até ao nível otimizado. Quando não se sabe por onde começar, nem que processos se devem escolher para melhoria, a representação faseada constitui uma boa escolha, pois prescreve um conjunto específico de processos para melhoria, os quais foram determinados ao longo de mais de uma década de pesquisa e experiência na comunidade de software. O Quadro 2.1 compara as vantagens de cada uma destas representações. **Representação continua** - - - - - - - **Representação faseada** - - - - - - - **Quadro 2.1 - Comparação entre a abordagem contínua e a abordagem faseada** **2.4.4 Componentes das Áreas de Processo** As componentes do modelo que descrevem as áreas de processo, no documento CMMI, encontram-se resumidas na Figura 2.8. **Figura 2.8 - Componentes do modelo CMMI** **2.4.4.1 Descrição do Objetivo** Este ponto é uma componente informativa e descreve o objetivo da área de processo. **Exemplo:** O objetivo do desenvolvimento de requisitos é produzir e analisar requisitos do cliente, do produto e de componentes do produto. **2.4.4.2 Notas Introdutórias** Este ponto é uma componente informativa e descreve os principais conceitos cobertos na área de processo. **Exemplo**: O planeamento inicia-se com os requisitos que definem o produto e o projeto. **2.4.4.3 Objetivos Genéricos** Este ponto aparece perto do final da área de processo. O termo \"genéricos\" refere-se ao facto de a mesma descrição do objetivo aparecer em múltiplas áreas de processo. Um objetivo genérico descreve as características que devem estar presentes para institucionalizar **os** processos que implementam a área de processo. É uma componente obrigatória do modelo e é usada nas avaliações, para determinar se é cumprida uma área de processo. **Exemplo:** O processo é institucionalizado como um processo definido. Apenas a descrição do objetivo genérico é considerada uma componente obrigatória. O título de um objetivo genérico (precedido pelo número do objetivo) e quaisquer notas associadas com o objetivo são consideradas componentes informativas do modelo. **2.4.4.4 Objetivos Específicos** Um objetivo específico descreve as características únicas, específicas, que devem estar presentes para satisfazer a área de processo. É uma componente obrigatória que é usada nas avaliações para determinar se é cumprida uma determinada área de processo. **Exemplo:** Um objetivo específico da área de processo Gestão da Configuração é: Estabelecer e manter a integridade das baselines. Apenas a descrição do objetivo específico é considerada uma componente obrigatória. O título de um objetivo específico (precedido pelo número do objetivo) e quaisquer notas associadas com esse objetivo são consideradas componentes informativas do modelo. **2.4.4.5 Tabelas de Relacionamento Prática e Objetivo** Tratam-se de tabelas que ilustram as relações entre as práticas que são componentes esperadas e os objetivos que são componentes obrigatórias. Estas relações são críticas durante uma avaliação para ajudar a determinar quando o objetivo está alcançado. Essas tabelas contêm um resumo de todos os objetivos e práticas e constituem uma componente informativa. **2.4.4.6 Práticas Genéricas** As práticas genéricas aparecem perto do final de uma área de processo. O termo \"genéricas\" refere-se ao facto de a mesma prática aparecer em múltiplas áreas de processo. Trata-se de uma descrição de uma atividade que é considerada importante para a consecução do objetivo genérico associado. É uma componente esperada do modelo. **Exemplo:** Uma prática genérica para o objetivo genérico O processo é institucionalizado como um processo gerido é: Fornecer recursos adequados para a realização do processo, o desenvolvimento dos produtos do trabalho e o fornecimento de serviços do processo. **2.4.4.7 Práticas Especificas** Uma prática específica é a descrição de uma atividade considerada importante para a consecução do objetivo específico associado. É uma componente esperada do modelo. **Exemplo:** Uma prática específica para a área de processo Gestão Integrada de Fornecedores é: Identificar e analisar as potenciais fontes de produtos que podem ser usadas para satisfazer os requisitos projeto **2.4.4.8 Produtos Típicos do Trabalho** Esta secção lista exemplos de outputs de uma prática específica. O nome \"produtos típicos do trabalho\" ilustra o facto de existirem frequentemente outros produtos do trabalho que são igualmente eficazes, mas que não estão listados. E uma componente informativa do modelo. **Exemplo:** Um produto típico do trabalho para a prática específica Estabelecer e manter procedimentos e critérios de verificação para os produtos do trabalho selecionados, na área de processo Verificação será: Critérios de verificação. **2.4.4.9 Subpráticas** Uma subprática é uma descrição detalhada que fornece orientação para a interpretação e implementação de uma prática específica. As subpráticas podem ser trabalhadas como se fossem prescritivas, embora sejam, na realidade, uma componente informativa cujo objetivo é proporcionar ideais que podem ser úteis para a melhoria do processo. **Exemplo:** Uma subprática para a prática específica Executar ações corretivas sobre problemas identificados, na área de processo Monitorização e Controlo do Projeto é: Determinar e documentar as ações adequadas necessárias para tratar dos problemas identificados. **2.4.4.10 Elaborações das Práticas Genéricas** Este item aparece após uma prática genérica numa área de processo, com o objetivo de dar orientação sobre o modo como a prática genérica deve ser aplicada, de forma única, à área de processo. É uma componente informativa do modelo. **Exemplo:** Uma elaboração de prática genérica na sequência da prática genérica Estabelecer e manter uma política organizacional para o planeamento e execução do processo de verificação, na área de processo Verificação é: Esta política estabelece expectativas organizacionais para o estabelecimento e manutenção de métodos, procedimentos e critérios de verificação, para o ambiente de verificação, para a realização de revisões e para a verificação dos produtos do trabalho selecionados. **2.4.5 Relações entre Áreas de Processo** A descrição das interações entre áreas de processo permite observar a melhoria de processos do ponto de vista organizacional, bem como quais as áreas de processo que contribuem para a implementação de outras. As relações entre áreas de processo apresentam duas dimensões: - - As iniciativas de melhoria de processos devem ser guiadas pelos objetivos de negócio da organização. **Exemplo**: Um objetivo de negócio vulgar é reduzir o tempo que demora a introduzir um produto no mercado. O objetivo de melhoria de processo derivado deste objetivo de negócio poderá ser a melhoria dos processos de gestão de projetos de modo a assegurar a entrega no momento necessário; estas melhorias assentam em melhores práticas nas áreas de processo de Planeamento de Projetos e Monitorização e Controlo de Projetos. As áreas de processo do CMMI agrupam-se em quatro categorias: - - - - Estar consciente das interações que existem entre as áreas de processo do CMMI e de quais são as áreas de processo fundamentais e progressivas ajuda a aplicar o CMMI de uma forma útil e produtiva. **2.4.5.1 Gestão de Processos** As áreas de processo de gestão de processos do CMMI contêm as atividades interprojeto relacionadas com a definição, planeamento, disseminação, monitorização, controlo, avaliação, medição e melhoria de processos, e dividem-se em: - - - - - A Figura 2.9 evidencia as áreas de processo fundamentais na gestão de projetos e a sua inter-relação. **Figura 2.9 - Áreas de processo fundamentais da gestão de projetos** **2.4.5.2 Gestão de Projetos** As áreas de processo da gestão de projetos cobrem as atividades relacionadas como planeamento, monitorização e controlo de projetos, e dividem-se em: - - - - - - - - No CMMI, o IPM tem dois objetivos, que se aplicam apenas quando se usa o CMMI disciplina IPPD. **2.4.5.3 Engenharia** As áreas de processo de engenharia cobrem as atividades de desenvolvimento e manutenção que são partilhadas pelas diversas disciplinas de engenharia, e estão escritas usando uma terminologia genérica de engenharia com o objetivo de qualquer disciplina envolvida no processo de desenvolvimento de produtos (por exemplo, engenharia de software, engenharia mecânica, etc.) poder usá-las para a melhoria de processos. As áreas de processo de engenharia integram igualmente os processos de engenharia de software e de engenharia de sistemas num processo de desenvolvimento único, que suporta uma estratégia de melhoria de processos orientada para o produto. Uma tal estratégia visa objetivos de negócio essenciais, não disciplinas técnicas específicas. Esta abordagem do processo evita efetivamente a tendência para uma mentalidade organizacional limitada e restritiva. As áreas de processo de engenharia aplicam-se ao desenvolvimento de qualquer produto ou serviço no domínio de desenvolvimento da engenharia - produtos de software, produtos de hardware, serviços ou processos. O fundamento técnico para o IPPD assenta numa sólida metodologia de engenharia de sistemas que abrange o desenvolvimento no contexto das fases da vida do produto. As áreas de processo de engenharia do CMMI são as seguintes: - - - - - - A Figura 2.10 ilustra uma visão global das interações entre essas seis áreas de processo. **Figura 2.10 - Áreas de processo da engenharia** **2.4.5.4 Suporte** As áreas de processo de Suporte cobrem as atividades que suportam o desenvolvimento e manutenção de produtos. Estas áreas tratam de processos que são usados no contexto d Regra geral, as áreas de processo de suporte tratam processos que são visados pelo projeto e podem tratar processos que se aplicam à organização de um modo mais g execução de outros processos. **Exemplo:** O processo de Garantia da Qualidade de Processo e Produto pode ser usado com todas as áreas de processo para proporcionar uma avaliação objetiva dos processos e produtos de trabalho descritos em todas as áreas de processo. As áreas de processo de suporte do CMMI são as seguintes: - - - - - -