Mapeamento dos Resultados Esperados

Os Resultados Esperados do modelo MPS.BR possuem relacionamentos de dependência entre si, uma característica que, apesar de ser intrínseca ao modelo, não é explicitada em sua documentação. Há os relacionamentos intra-processo, isto é, entre Resultados Esperados do mesmo processo, os quais foram considerados implícitos e, também, relacionamentos inter-processo, ou seja, entre Resultados Esperados de processos distintos do modelo de qualidade, relacionamentos nos quais, baseados em análises e discussões, foram propostos pela equipe de integração do Projeto SPIDER.

O escopo das relações aqui descritas envolve os Resultados Esperados, oriundos dos processos do nível G do MPS.BR, os quais fornecem base para a implementação de Resultados Esperados dos níveis G e F do modelo. O objetivo é analisar como os processos definidos no Nível G do MPS.BR impacta sobre outros processos dos níveis G e F deste modelo. O impacto dos processos definidos no nível F do MPS.BR é avaliado em outro subprojeto do Projeto SPIDER, assunto do trabalho de conclusão de curso “Uma Proposta de Integração do Apoio Sistematizado aos Resultados Esperados do Nível F do MPS.BR” (MENDES & ÁVILA, 2009).

A estratégia adotada para formalizar os relacionamentos (dependências) entre os Resultados Esperados foi através da criação das seguintes definições: Resultado Esperado Base; Resultado Esperado Dependente; Descrição do Mapeamento e Implementação Conjunta. Um conjunto o qual contenha estes elementos caracteriza uma dependência entre Resultados Esperados.

Resultado Esperado Dependente foi definido como aquele o qual o seu atendimento depende de eventos ou informações oriundos do atendimento do Resultado Esperado Base correspondente. Por conseguinte, a Descrição do Mapeamento é necessária para justificar a associação, bem como fornecer um exemplo de implementação da relação entre Resultados Esperados por meio da Implementação Conjunta para explicitar e melhor esclarecer a dependência.

O título das subseções a seguir é denotado com a seguinte sintaxe: Resultado Esperado Base x Resultado Esperado Dependente. A Descrição do Mapeamento e a Implementação Conjunta constam no corpo da subseção. Na Descrição do Mapeamento, ao ser comentado o ponto relevante do Resultado Esperado para o mapeamento, um parêntese é observado contendo a sigla do Resultado Esperado ao qual o elemento citado pertence. Por exemplo, o elemento “Objetivos de Medição” presente na subseção 4.2.1 está contemplado pelo resultado esperado MED1 do processo de Medição.

4.2.1 GPR 1 x MED 1

Os Objetivos de Medição (MED1) precisam previamente que os objetivos do projeto estejam definidos no seu escopo de projeto (GPR1).

• Implementação Conjunta: Ao definir o escopo do projeto, os objetivos do mesmo são definidos. Estes Objetivos serão utilizados como base para a definição dos Objetivos de Medição.

4.2.2 GPR 5 x GCO 3

As baselines são geradas (GCO3) em marcos do projeto e/ou conforme definido no Cronograma (GPR5).

• Implementação Conjunta: Para cada marco e/ou ponto de controle do projeto, uma baseline deve estar atrelada, conforme definido na metodologia da empresa. Além disso, baselines periódicas podem ser criadas, conforme estabelecido no cronograma. 4.2.3 GPR 6 x GQA 4

Para efetivar as alterações definidas nas ações corretivas (GQA4) deve-se, previamente, analisar os riscos e seus impactos associados no projeto (GPR6).

• Implementação Conjunta: A tomada de decisão para correção de uma não- conformidade deve ser realizada, caso seja viável, após análise dos riscos dessa alteração e seus impactos no projeto, verificando suas dependências.

4.2.4 GPR 9 x GCO 2

A Gerência de Configuração necessita da identificação dos dados relevantes do projeto (GPR9) para a identificação dos itens de configuração (GCO2).

• Implementação Conjunta: A identificação dos dados relevantes do projeto (artefatos) fornece insumos para a identificação dos itens de configuração.

4.2.5 GPR 10 x GPP 2

Para cada um dos projetos que tenham sido selecionados e priorizados devem ser provisionados e disponibilizados os recursos e o orçamento necessários (GPP2), incluídos no Plano do Projeto (GPR10).

• Implementação Conjunta: Determinado recurso humano pode estar alocado a mais de um projeto. É importante analisar se a carga total alocada é compatível com a carga horária disponível do profissional.

4.2.6 GPR 11 x GPP 1

A transformação de um projeto em execução em um portfólio depende da análise de viabilidade de negócio (GPR11) para atender uma oportunidade de mercado (GPP1).

• Implementação Conjunta: Quando a Gerência de Portfólio pretende transformar um projeto em execução em um Portfólio, ela deve usar os dados da análise de viabilidade do projeto para a decisão de criação do portfólio.

4.2.7 GPR 11 x GPP 5

Projetos que atendem aos acordos e requisitos que levaram à sua aprovação (GPP5) dependem da análise da viabilidade de atingir as metas do projeto, considerando as restrições e os recursos disponíveis (GPR11).

• Implementação Conjunta: A análise de viabilidade é executada para que seja decidido quais projetos devem ser redirecionados ou cancelados.

4.2.8 GPR 17 x GQA 4

Ações para corrigir desvios em relação ao planejado e para prevenir a repetição dos problemas identificados (GPR17) devem estar em sintonia com as ações corretivas para não conformidades estabelecidas na Gerência de Qualidade (GQA4).

• Implementação Conjunta: As não conformidades devem possuir ações corretivas, que serão gerenciadas até serem concluídas.

4.2.9 GPR 17 x GPP 4

Uma vez identificado um conflito de recurso entre projetos (GPP4), a gerência de projeto se encarrega de identificar, propor solução e acompanhar a resolução do conflito até a sua conclusão (GPR17).

• Implementação Conjunta: Um conflito identificado pela Gerência de Portfólio, por exemplo, um programador alocado mais de 100% do seu tempo pra vários projetos, é encaminhado para a Gerência de Projeto para que o conflito seja solucionado.

4.2.10 GRE 1 x GPR 1

A definição dos requisitos entendidos, avaliados e aceitos (GRE1) impactam diretamente no escopo, caso a modificação não seja aderente aos objetivos e restrições originais do sistema (GPR1).

• Implementação Conjunta: Uma alteração em um requisito aprovado deve ter sua aderência em relação ao escopo anterior analisada. Caso haja conflito, ações estabelecidas no Plano de Projeto devem indicar o procedimento a ser adotado.

4.2.11 GRE 1 x GPR 2

O dimensionamento de tarefas e produtos de trabalho utilizando métricas adequadas (GPR2) pode ter como um dos parâmetros o número de requisitos avaliados e aceitos (GRE1). • Implementação Conjunta: Os requisitos de software servem como parâmetro para análise de um método apropriado para o dimensionamento das tarefas como pontos por função.

4.2.12 GRE 1 x GPR 3

O modelo e o ciclo de vida do projeto (GPR3) devem levar em consideração o escopo dos requisitos (GRE1).

• Implementação Conjunta: Com a análise das peculiaridades do projeto, tendo em vista o escopo dos requisitos, deve ser realizada para escolher um modelo e fases de ciclo de vida adequadas.

4.2.13 GRE 1 x GPR 5

As atividades definidas no escopo dependem diretamente dos requisitos avaliados e aceitos (GRE1), impactando definição das tarefas no cronograma (GPR5).

• Implementação Conjunta: A definição dos requisitos avaliados e aceitos deve ser seguida de uma tarefa constante no Plano do Projeto. Esta nova tarefa deve constar no escopo e deve, por conseguinte, impactar sobre o custo do projeto.

4.2.14 GRE 1 x GPR 11

Os requisitos entendidos, avaliados e aceitos (GRE1) são um parâmetro necessário para avaliar a viabilidade de atingir as metas do projeto (GPR11).

• Implementação Conjunta: Em um marco ou ponto de controle onde seja avaliada a viabilidade de se atingir as metas do projeto, os requisitos de software são requeridos para uma análise acurada.

4.2.15 GRE 1 x GCO 7

As auditorias da gerência de configuração (GCO7) utilizam, entre outros critérios, os requisitos aprovados (GRE1).

• Implementação Conjunta: Durante as auditorias de configuração, a análise dos requisitos aprovados pode ter impacto significativo.

4.2.16 GRE 2 x GPR 12

O comprometimento dos envolvidos com plano de projeto (GPR12) necessita do comprometimento da equipe técnica com os requisitos (GRE2).

• Implementação Conjunta: A partir do comprometimento da equipe técnica com os requisitos, o gerente do projeto pode marcar uma reunião para obter o comprometimento no plano de projeto.

4.2.17 GRE 3 x GPR 5

A rastreabilidade bidirecional (GRE3) permite que seja analisado o impacto de alterações proporcionadas pelos requisitos no cronograma (GPR5).

• Implementação Conjunta: O impacto no projeto de software de alterações nos requisitos é analisado tendo como base uma tabela de rastreabilidade.

4.2.18 GRE 3 x GPR 6

A identificação dos riscos (GPR6) é auxiliada pela análise das dependências identificadas na rastreabilidade bidirecional (GRE3).

• Implementação Conjunta: A análise dos riscos pode levar em conta as alterações em cadeia nos produtos de trabalho, vide a matriz de rastreabilidade, para um resultado mais preciso, pois nesta matriz consta as dependências entre requisitos e produtos de trabalho.

4.2.19 GRE 4 x GPR 10

Identificar e corrigir inconsistências nos planos e produtos de trabalho (GRE4) implica em alterações no Plano de Projeto (GPR10).

• Implementação Conjunta: A identificação e correção dos requisitos e produtos de trabalho, caso haja alguma inconsistência, implicará em alterações no plano de projeto como: mudanças de escopo, esforço, custo, cronograma e recursos.