c

A ABC Consulting, TechnologiesandInformation é uma empresa de Tecnologia

da Informação que atua no mercado nacional a mais de 10 anos.

Atenta às mudanças do mercado, a ABC prepara -se para um grande salto

estratégico e mercadológico. A ABC esta iniciando as ações para atuar
também no mercado de offshore americano.

Com filias em todas as regiões do Brasil e um escritório em Miami, a empresa

inicia suas ações para a implantação do modelo CMMI.

Além de mercadologicamente necessário a ABC busca a implantação de um

programa de melhoria contínua de seus processos de desenvolvimento e
manutenção de software.

Para que uma empresa seja avaliada no Nível 2 do CMMI as seguintes áreas
de processos devem estar implantadas:

G Gerenciamento de Requisitos (Requirements Management)

G Planejamento do Projeto (Project Planning)
G Monitoramento e Controle do Projeto (Project MonitoringandControl)
G Gerenciamento de Acordos com Fornecedores (SupplierAgreement
Management)
G Medições e Análises (Measurement and Ana lysis)
G Garantia da Qualidade do Processo e do Produto
(ProcessandProductQualityAssurance)
G Gerenciamento de Configurações (Configuration Management)

Após algumas reuniões um auditor externo realizou várias entrevistas e as

compilou em um documento de 48 itens, relacionados às práticas do nível 2 do
modelo CMMI.

A ABC contratou sua consultoria de qualidade para com posse do documento

inicial, realizar a primeira avaliaçãode aderência entre seus processos e as
melhores práticas especificadas no modelo CMMI.

Cabe a você analisar o documento e preencher a planilha de avaliação de

aderência fornecida àvocê.

A planilha possui listadas as práticas de cada área de processo do nível 2 do

CMMI.
A seguir resumo das evidências levantadas nas reuniões:

‰

  

 Bem senhores, com relação ao 

 
    um projeto executa os passos apropriados
para assegurar que o conjunto de requisitos acordados é gerenciado para
suportar as necessidades de planejamento e execução do projeto. Qu ando um
projeto recebe requisitos de um gerador aprovado de requisitos, estes são
revisados com o fornecedor de requisitos para resolver questões e prevenir o
mau entendimento, antes que os requisitos sejam incorporados aos planos do
projeto. Uma vez que o fornecedor e o receptor dos requisitos cheguem a um
acordo, é obtido um compromisso dos participantes do projeto sobre os
requisitos. O projeto gerencia as mudanças feitas nos requisitos conforme eles
evoluem e identifica quaisquer inconsistências que oco rram entre planos,
produtos de trabalho e requisitos .

Com relação às Práticas Especificasdevemos observar:

 

  

ü
    
 
   
  
 
  



  

 
 


 

Conforme o projeto amadurece e requisitos são derivados, todas as atividades ou

disciplinas receberão requisitos. Para evitar que os requisitos cresçam indistintamente, são
estabelecidos critérios para determinar os canais apropriados ou fontes oficiais, a partir
dos quais deve-se receber os requisitos. As atividades de recebimento executam análises
dos requisitos junto ao fornecedor dos requisitos para assegurar que um entendimento
compartilhado e compatível do significado dos requisitos foi conseguido. O resultado desta
análise e diálogo é um conjunto de requisitos acordados.


 
1. Listas de critérios para distinguir os fornecedores apropriados de requisitos;
2. Critérios para a avaliação e aceitação dos requisitos ;
3. Resultados de análises contra os critérios;
4. Um conjunto de requisitos acordados;

! "    

·


 


   


  
 


 c

Enquanto a prática específica anterior trata de se chegar a um entendimento com os

fornecedores de requisitos, esta prática específica trata de acordos e compromissos entre
aqueles que terão que executar as atividades necessárias para implementar os requisitos.
Os requisitos evoluem ao longo do projeto, especialmente conforme descrito pelas práticas
específicas das áreas de processos de Desenvolvimento de Requisitos e de Soluções
Técnicas. Conforme os requisitos evoluem, esta prática específica assegura que os
participantes do projeto se comprometem com os requisitos atuais aprovados e com as
mudanças resultantes nos planos de projeto, atividades e produtos de trabalho.


 
1. Análises de impacto de requisitos;
2. Compromissos documentados com os requisitos e com as mudanças de requisitos;

#  $



  
^   
 

 


  


  

 c


Durante o projeto, os requisitos mudam por uma série de motivos. Conforme as

necessidades mudam e o trabalho prossegue, requisitos adicionais são derivados e
mudanças podem ter que ser feitas nos requisitos já existentes. É essencial gerenciar
esses acréscimos e mudanças de forma eficiente e eficaz. Para analisar de forma eficaz o
impacto das mudanças, é necessário que a fonte de cada requisito seja conhecida e que a
justificativa para qualquer mudança seja documentada. O gerente do projeto pode,
entretanto, desejar rastrear as medidas adequadas de volatilidade de requisitos para julgar
se são necessários novos controles ou a revisão dos já existentes.
% & 
1. Capturar todos os requisitos e mudanças de requisitos que foram recebidas ou
geradas pelo projeto.
2. Manter o histórico das mudanças nos requisitos juntamente com a justificativa para as
mudanças.
=
 
 
            
3. Avaliar o impacto das mudanças nos requisitos a partir do ponto de vista dos
stakeholders relevantes.
4. Tornar disponíveis para o projeto os dados de requisitos e de mudanças.

'$ 

(
 
  

=
  

     
  
  


  
 
  
 


 
 

A intenção desta prática específica é manter a rastreabilidade bidirecional dos requisitos

para cada nível de decomposição do produto. Quando os requisitos são bem gerenciados,
a rastreabilidade pode ser estabelecida, desde um requisito fonte até seus requisitos de
mais baixo nível e destes de volta para o seu requisito fonte. Tal rastreabilidade
bidirecional auxilia a determinar se todos os requisitos fonte foram completamente tratados
e se todos os requisitos de mais baixo nível podem ser rastreados para uma fonte válida. A
rastreabilidade de requisitos pode também cobrir os relacionamentos com outras
entidades, como produtos de trabalho intermediários e finais, mudanças na documentação
de design, planos de testes e tarefas de trabalho. A rastreabilidade deverá cobrir os
relacionamentos horizontais e verticais, como as interfaces. A rastreabilidade é
particularmente necessária na condução da análise do impacto de mudanças de requisitos
nos planos do projeto, atividades e produtos de trabalho.


 
1. Matriz de rastreabilidade de requisitos ;
2. Sistema de rastreamento de requisitos;
) *
 + * , 
-   
O 
   


 
 
  
 
   
  

  
 

 
 


 

Esta prática específica descobre as inconsistências entre os requisitos e os planos do

projeto e produtos de trabalho e inicia a ação corretiva para corrigi-las.


 
1. Documentação de inconsistências incluindo fontes, condições
e justificativas ;
2. Ações corretivas;

‰

  

 Bem senhores, com relação ao 

-
 - , este possui o objetivo de estabelecer e manter
planos que definem as atividades do projeto. A área de processo de
Planejamento do Projeto (Project Planning) envolve :c

G Desenvolver o plano do projeto

G Interagir com os stakeholders de forma apropriada
G Obter compromissos com o plano
G Manter o plano
O planejamento começa com os requisitos que definem o produto e o projeto.
O planejamento inclui estimar os atributos dos produtos de trabalho e tarefas,
determinar os recursos necessários, negociar compromissos, produzir um
cronograma e identificar e analisar os riscos do projeto. Iterações destas
atividades podem ser necessárias para estabelecer o plano do projeto. O plano
do projeto fornece a ba se para a execução e controle das atividades de projeto
que tratam dos compromissos com o cliente do projeto.
O plano do projeto normalmente precisará ser revisado, conforme o projeto
evolui, para tratar mudanças nos requisitos e compromissos, estimativas
imprecisas, ações corretivas e mudanças no processo. As práticas específicas
que descrevem o planejamento e o replanejamento estão contidas nesta área
de processo.
O termo ³plano do projeto´ é utilizado em todas as práticas genéricas e
específicas desta área de processo para se referir ao plano geral de controle
do projeto.
Com relação às Metas e Práticas Especificasdevemos observar:
$   
SP 1.1 Estimar o Escopo do Projeto
SP 1.2Estabelecer Estimativas de Atributos de Produtos de Trabalho e Tarefas
SP 1.3 Definir o Ciclo de Vida do Projeto
SP 1.4Determinar Estimativas de Esforço e Custo
$!.
- 
SP 2.1Estabelecer o Orçamento e o Cronograma
SP 2.2Identificar os Riscos do Projeto
SP 2.3Planejar o Gerenciamento de Dados
SP 2.4Planejar os Recursos do Projeto
SP 2.5Planejar as Habilidades e Conhecimentos Necessários
SP 2.6Planejar o Envolvimento dos Stakeholders
SP 2.7Estabelecer o Plano de Projeto
$#"   
SP 3.1 Revisar os Planos que Afetam o Projeto
SP 3.2Conciliar os Níveis de Trabalho e de Recursos
SP 3.3Obter Compromissos com o Plano
‰

  
 Bem senhores, com relação ao 

$ "
- , este possui o objetivo de estabelecer
e manter planos que definem as atividades do projeto. Quando o status real se
desvia significativamente dos valores esperados, as ações corretivas são
tomadas conforme apropriado. Estas ações podem exigir o replanejamento,
que pode incluir a revisão do plano original, estabelecimento de novos acordos
ou inclusão de atividades de mitigação de riscos adicionais dentro do plano
atual.

$$ -" 

SP 1.1Monitorar os Parâmetros de Planejamento do Projeto
SP 1.2Monitorar os Compromissos
SP 1.3Monitorar os Riscos do Projeto
SP 1.4Monitorar o Gerenciamento de Dados
SP 1.5Monitorar o Envolvimento dos Stakeholders
SP 1.6Conduzir Revisões de Progresso
SP 1.7Conduzir Revisões nos Milestones
$! 
" /01!*2!3 
SP 2.1Analisar Questões
SP 2.2Tomar Ações Corretivas
SP 2.3Gerenciar as Ações Corretivas

Ao verificarmos os projetos percebemos que:

GR ± META 1 ± SP01 - Os requisitos estão vindos de várias fontes diferentes,

não está definido um responsável para centralizar o envio de novos requisi tos.
Existem funcionalidades que não possuem requisitos associados. Não foi
apresentada uma lista de critérios para aceitação dos requisitos, tãopouco um
conjunto de requisitos formalmente acordados.

GR ± META 1 ± SP02 - Não foram identificados quaisquer tipos de análises de

impacto dos requisitos, assim como, não se verificou a presença de um
documento assinado pelo cliente que pudesse firmar algum tipo de
compromisso formal entre o cliente e a equipe de projeto.

GR ± META 1 ± SP03 - Várias mudanças solicitadas nos requisitos não foram

capturadas. Alguns requisitos foramCapturados, desses existe um pobre
histórico das mudanças nos requisitos juntamentecom suas justificativ as para
as mudanças. Porém não foram apresentadas qualquer tipo de avaliação de
impacto dessas mudanças nos requisitos.

GR ± META 1 ± SP04 - Não foram identificados quaisquer tipos de matriz de

rastreabilidade dos requisitos. Assim não foi possível identificar a
rastreabilidade bidirecional dos requisitos para cada nível de decomposição do
produto

GR ± META 1 ± SP05 - Com relação as inconsistências entre os requisitos e os

planos do projeto e produtos de trabalho, não identificamos qualquer
documentação de inconsistências incluindo fontes, condições e justificativas ou
ações corretivas;

PP ± META 1 ± SP01 - Não foi desenvolvida uma WBS que pudesse definir o
escopo do projeto. A WBS é, geralmente, uma estrutura orientada para o
produto que garante um esquema para identificação e organização das
unidades lógicas de trabalho a serem gerenciadas, que são chamadas de
³pacotes de trabalho´ (³workpackages´). A WBS fornece uma referência e um
mecanismo organizacional para a atribuição de esforços, cronograma e
responsabilidades e é utilizada como uma estrutura subjacente para planejar,
organizar e controlar o trabalho executado no projeto , definido, estimando seu
escopo.

PP ± META 1 ± SP02 - Foi apresentado um processo em estágio inicial no qual

se realizam estimativas para Produtos de Trabalho e Tarefas do projeto.

PP ± META 1 ± SP03± Em seu planejamento, foi definido um ciclo de vida para

o projeto.

PP ± META 1 ± SP04± Foram apresentadas evidências de que foram

Coletados dados históricos que foram utilizados para transformar os atributos
dos produtos de trabalho e tarefas em estimativas de horas de trabalho e custo
das atividades do projeto;

PP ± META2 ± SP01 ± Com base nas estimativas de horas de trabalho e custo

das atividades do projeto foram elaborados o Orçamento e o Cronograma do
Projeto;

PP ± META 2 ± SP02 ± Não foi apresentado para o líder da avaliação qualquer

evidência para identificação e gerenciamento de ri scos

PP ± META 2 ± SP03 ± Os dados são as várias formas de documentação

exigidas para suportar um programa em todas as suas áreas (por exemplo,
administração, engenharia, gerenciamento de configurações, finanças,
logística, qualidade, segurança, fabricação e compras). Os dados podem estar
em qualquer formato (por exemplo, relatórios, manuais, anotações, gráficos,
diagramas, especificações, arquivos ou correspondências). Os dados podem
existir em qualquer meio (por exemplo, impressos ou desenhados em diverso s
materiais, fotografias, meio eletrônico e multimídia). Os dados podem ser
produtos a serem entregues (por exemplo, itens identificados por requisitos de
dados contratuais de um programa) ou os dados podem não ser entregues (por
exemplo, dados informais, troca de estudos e análises, minutas de reuniões
internas, documentação interna de revisão de design, lições aprendidas e itens
de ação). A distribuição pode ocorrer de várias formas, inc luindo a transmissão
eletrônica. Não foi observada qualquer atividade para gestão dos dados do
projeto.

PP ± META 2 ± SP04 ± Foram apresentados cronogramas nos quais os

recursos foram estimados e alocados aos projetos;
PP ± META 2 ± SP05 ± Foi apresentado processo no qual o gerente do
projetoIdentifica os conhecimentos e habilidades dos recursos da empresa
necessários pra executar o projeto.

PP ± META 2 ± SP06 ± Não foram identificados Stakeholders, tão pouco seu

planejamento no projeto.

PP ± META 2 ± SP07 ± Foi apresentado um Plano de Proje to o qual ainda é

muito incipiente. Assim, esse líder não aceitou essa evidência.

PP ± META 3 ± SP01 ± Vários planos deveriam ser desenvolvidos dentro de

outras áreas de processos, os quais deveriam conter, normalmente,
informações semelhantes àquelas do plano geral do projeto. Estes planos
deveriam fornecer um direcionamento adicional detalhado e dever iam ser
compatíveis e suportar o plano geral do projeto para indicar quem tem a
autoridade, responsabilidade, comunicação e controle. Todos os planos que
afetam o projeto deveriam ser revisados para assegurar um entendimento
comum do escopo, objetivos, papéis e relacionamentos que são exigidos para
o projeto ser bem sucedido. Não forma identificados registros das revisões
desses planos que afetam o projeto .

PP ± META 3 ± SP02 ± Para obter compromissos dos stakeholders relevantes,

é importante conciliar as diferenças existentes entre os recursos estimados e
disponíveis. Essa conciliação é normalmente conseguida diminuindo os
requisitos de desempenho técnico, negociando mais recursos, encontrando
maneiras de aumentar a produtividade, alocando recursos externos
(outsourcing), ajustando a composição de habilidades da equipe ou revisando
todos os planos que afetam o projeto ou os cronogramas. Nenhuma
Conciliação entre os Níveis de Trabalho e de Recursos foi realizada no
planejamento dos projetos.
PP ± META 3 ± SP03 ± Obter compromissos com o plano envolve a interação
entre todos os stakeholders relevantes internos e externos ao projeto. Nada
disso foi realizado.

MC ± META 1 ± SP01 ± O Monitoramento dos Parâmetros de Planejamento do

Projeto é realizado de maneira primaria, de forma parcial bem inicial, ´e o que
podemos definir;

MC ± META 1 ± SP02 ± Os compromissos são monitorados de forma parcial;

MC ± META 1 ± SP03 ±Não foram apresentadas evidência de que exista
alguma tipo de monitoramento dos riscos. Os riscos dos projetosnão são
monitorados;

MC ± META 1 ± SP04 ±Não existe monitoramento do Gerenciamento dos

Dados do Projeto;
MC ± META 1 ± SP05 ± Não existe monitoramento do envolvimento dos
Stakeholders;
MC ± META 1 ± SP06 ±Algumas reuniões para revisão de Progresso do
Projeto foram realizadas. Trata-se de um processo executado de forma bem
parcial;
MC ± META 1 ± SP07 ± Algumas reuniões para revisão de Milestones foram
realizadas de forma bem preliminar;
MC ± META 2 ± SP01 ±Analisar questões trata de Coletar e analisar questões e
determinar as ações corretivas necessárias para tratar estas questões. Isso não é
realizado no projeto;

MC ± META 2 ± SP02 ±Não são tomadas ações corretivas na empresa e em

seus projetos;
MC ± META 2 ± SP03 ± Não existe gerenciamento de ações corretivas na
empresa e em seus projetos;

c
c