Guia de Implementação Nível G

MPS.
BR - Melhoria de Processo do Software Brasileiro

Guia de Implementao Parte 1: Fundamentao para
Implementao do Nvel G do MR-MPS-SW:2012

Este guia contm orientaes para a
implementao do nvel G do
Modelo de Referncia MR-MPS-
SW:2012.

Setembro de 2013

Copyright 2013 - SOFTEX
Direitos desta edio reservados pela Sociedade SOFTEX
A distribuio ilimitada desse documento est sujeita a copyright
ISBN (Solicitado Biblioteca Nacional)

MPS.BR Guia de Implementao Parte 1:2013 2/49

Sumrio
1 Prefcio ............................................................................................................... 3
2 Introduo ........................................................................................................... 5
3 Objetivo ............................................................................................................... 6
4 Comeando a implementao do MR-MPS-SW pelo nvel G .............................. 7
5 Gerncia de Projetos (GPR)................................................................................ 7
5.1 Propsito ......................................................................................................... 7
5.2 Fundamentao terica ................................................................................... 9
5.3 Resultados esperados ................................................................................... 11
6 Gerncia de Requisitos (GRE) .......................................................................... 30
6.1 Propsito ....................................................................................................... 30
6.2 Fundamentao terica ................................................................................. 31
6.3 Resultados esperados ................................................................................... 32
7 Os atributos de processo no nvel G ................................................................. 38
7.1 AP 1.1 - O processo executado .................................................................. 39
7.2 AP 2.1 - O processo gerenciado ................................................................. 39
Referncias bibliogrficas ........................................................................................ 43
Lista de colaboradores do Guia de Implementao Parte 1:2011 ......................... 46
Lista de colaboradores do Guia de Implementao Parte 1:2009 ......................... 47
Lista de colaboradores do Guia de Implementao Parte 1 verso 1.1 Julho/2007
................................................................................................................................. 48
Lista de colaboradores do Guia de Implementao Parte 1 verso 1.0
Dezembro/2006 ........................................................................................................ 49


1 Prefcio
O MPS.BR
1
um programa mobilizador, de longo prazo, criado em dezembro de
2003, coordenado pela Associao para Promoo da Excelncia do Software
Brasileiro (SOFTEX), que conta com apoio do Ministrio da Cincia e Tecnologia
(MCT), Financiadora de Estudos e Projetos (FINEP), Servio Brasileiro de Apoio s
Micro e Pequenas Empresas (SEBRAE) e Banco Interamericano de
Desenvolvimento (BID).
O objetivo do Programa MPR.BR (acrnimo) a Melhoria de Processo de Software
e de Servios no Brasil, com duas metas a alcanar a mdio e longo prazos:
a) meta tcnica, visando criao e aprimoramento dos modelos MPS, com
resultados esperados tais como: (i) guias dos modelos MPS; (ii) Instituies
Implementadoras (II) credenciadas para prestar servios de consultoria de
implementao dos modelos de referncia MR-MPS-SW e MR-MPS-SV; (iii)
Instituies Avaliadoras (IA) credenciadas para prestar servios de avaliao
seguindo o Mtodo de Avaliao MA-MPS; (iv) Consultores de Aquisio (CA)
certificados para prestar servios de consultoria de aquisio de software e servios
relacionados;
b) meta de mercado, visando disseminao e adoo dos modelos MPS-SW e
MPS-SV, em todas as regies do pas, em um intervalo de tempo adequado, a um
custo razovel, tanto em PME (foco principal) quanto em grandes organizaes
pblicas e privadas, com resultados esperados tais como: (i) criao e
aprimoramento do modelo de negcio MN-MPS; (ii) cursos, provas e workshops; (iii)
organizaes que implementaram os modelos MPS; (iv) organizaes com avaliao
MPS publicada (prazo de validade de trs anos).
O Programa MPR.BR conta com duas estruturas de apoio para o desenvolvimento
de suas atividades, o Frum de Credenciamento e Controle (FCC) e a Equipe
Tcnica do Modelo (ETM). Por meio destas estruturas, o MPS.BR obtm a
participao de representantes de universidades, instituies governamentais,
centros de pesquisa e de organizaes privadas, os quais contribuem com suas
vises complementares que agregam qualidade ao empreendimento.

Cabe ao FCC: (i) emitir parecer que subsidie deciso da SOFTEX sobre o
credenciamento de Instituies Implementadoras (II) e Instituies Avaliadoras (IA);
(ii) monitorar os resultados das Instituies Implementadoras (II) e Instituies
Avaliadoras (IA), emitindo parecer propondo SOFTEX o seu descredenciamento
no caso de comprometimento da credibilidade do modelo MPS.
Cabe ETM apoiar a SOFTEX sobre os aspectos tcnicos relacionados aos
Modelos de Referncia (MR-MPS) e Mtodo de Avaliao (MA-MPS), para: (i)

1
MPS.BR, MR-MPS-SW, MR-MPS-SV, MA-MPS e MN-MPS so marcas da SOFTEX. A sigla
MPS.BR est associada ao Programa MPR.BR Melhoria do Processo de Software Brasileiro, a sigla
MPS-SW est associada ao modelo MPS para software Melhoria do Processo de Software e a sigla
MPS-SV est associada o modelo MPS para Servios Melhoria do Processo de Servios.


criao e aprimoramento contnuo do MR-MPS-SW, MR-MPS-SV, MA-MPS e seus
guias especficos; (ii) capacitao de pessoas por meio de cursos, provas e
workshops.
A criao e o aprimoramento do Guia Geral de Software e do Guia Geral de
Servios so tambm atribuies da ETM, sendo que este guia faz parte do seguinte
conjunto de documentos do modelo MPS:
Guia Geral MPS de Software:2012 [SOFTEX, 2012a];
Guia Geral MPS de Servios:2012 [SOFTEX, 2012b];
Guia de Avaliao:2013 [SOFTEX, 2013i];
Guia de Aquisio de Software:2013 [SOFTEX, 2013a];
Guia de Implementao Parte 1: Fundamentao para Implementao do
Nvel G do MR-MPS-SW:2012 [SOFTEX, 2013b];
Nvel F do MR-MPS-SW:2012 [SOFTEX, 2013c];
Nvel E do MR-MPS-SW:2012 [SOFTEX, 2013d];
Nvel D do MR-MPS-SW:2012 [SOFTEX, 2013e];
Nvel C do MR-MPS-SW:2012 [SOFTEX, 2013f];
Nvel B do MR-MPS-SW:2012 [SOFTEX, 2013g];
Nvel A do MR-MPS-SW:2012 [SOFTEX, 2013h];
Guia de Implementao Parte 8: Implementao do MR-MPS:2011 (Nveis G a
A) em organizaes que adquirem software [SOFTEX, 2011a];
Guia de Implementao Parte 9: Implementao do MR-MPS:2011 (Nveis G a
A) em organizaes do tipo Fbrica de Software [SOFTEX, 2011b];
Guia de Implementao Parte 10: Implementao do MR-MPS:2011 (Nveis G
a A) em organizaes do tipo Fbrica de Teste [SOFTEX, 2011c];
Guia de Implementao Parte 11: Implementao e Avaliao do MR-MPS-
SW:2012 (Nveis G a A) em conjunto com o CMMI-DEV v1.3 [SOFTEX, 2012c];
Guia de Implementao Parte 12: Anlise da Aderncia do MR-MPS-SW:2012
em relao NBR SO/IEC 29110-4-1:2012 - Engenharia de Software - Perfis de
ciclo de vida para micro-organizaes (VSEs) - Parte 4-1: Especificaes de
perfil: Grupo Perfil Genrico [SOFTEX, 2012d];
Guia de Implementao Parte 13: Mapeamento e sistema de equivalncias
entre o MR-MPS-SW:2012 e o MoProSoft:2005 [SOFTEX, 2012e].


As alteraes deste Guia de Implementao em relao verso 2012 so
decorrentes de:
incluso do Modelo de Referncia para Servios (MR-MPS-SV); e
alterao do logo da SOFTEX.
As alteraes deste Guia de Implementao em relao verso 2009 so
decorrentes de:
mudanas realizadas na verso 2009 do Guia Geral;
correo ortogrfica e gramatical;
adequao das referncias bibliogrficas;
incluso de notas explicativas contidas nas partes 8, 9 e 10 do Guia de
Implementao;
clarificao sobre o foco do resultado esperado GPR7.
incluso de explicao sobre a no necessidade de os requisitos serem
avaliados utilizando critrios objetivos por todos os membros da equipe tcnica
durante a reorganizao dos resultados esperados GRE1 e GRE2.
incluso de pargrafo sobre itens rastreveis em um projeto na explicao sobre
o resultado esperado GRE3.
2 Introduo
As mudanas que esto ocorrendo nos ambientes de negcios tm motivado as
empresas a modificar estruturas organizacionais e processos produtivos, saindo da
viso tradicional baseada em reas funcionais em direo a redes de processos
centrados no cliente. A competitividade depende, cada vez mais, do estabelecimento
de conexes nestas redes, criando elos essenciais nas cadeias produtivas. Alcanar
competitividade pela qualidade, para as empresas de software e servios, implica
tanto na melhoria da qualidade dos produtos de software e servios correlatos, como
dos processos de produo e distribuio.
Desta forma, assim como para outros setores, qualidade fator crtico de sucesso
para a indstria de software e servios. Para que se tenha um setor de software e
servios competitivo, nacional e internacionalmente, essencial que os
empreendedores do setor coloquem a eficincia e a eficcia dos seus processos em
foco nas empresas, visando oferta de produtos de software e servios correlatos
conforme padres internacionais de qualidade.
Busca-se que os modelos MPS-SW e MPS-SV sejam adequados ao perfil de
empresas com diferentes tamanhos e caractersticas, pblicas e privadas, embora
com especial ateno s micro, pequenas e mdias empresas. Tambm se espera
que os modelos MPS sejam compatveis com os padres de qualidade aceitos
internacionalmente e que tenham como pressuposto o aproveitamento de toda a
competncia existente nos padres e modelos de melhoria de processo j
disponveis. Dessa forma, o MR-MPS-SW tem como base os requisitos de
processos definidos nos modelos de melhoria de processo e atende a necessidade


de implantar os princpios de engenharia de software de forma adequada ao
contexto das empresas, estando em consonncia com as principais abordagens
internacionais para definio, avaliao e melhoria de processos de software. Da
mesma forma, o modelo MR-MPS-SV est em consonncia com as principais
abordagens internacionais para servios.
Os modelos MPS baseiam-se nos conceitos de maturidade e capacidade de
processo. Dentro desse contexto, o modelo MPS possui quatro componentes:
Modelo de Referncia para Software (MR-MPS-SW), Modelo de Referncia para
Servios (MR-MPS-SV), Mtodo de Avaliao (MA-MPS) e Modelo de Negcio (MN-
MPS).
Os modelos MPS esto descritos por meio de documentos em formato de guias:
Guia Geral para Software: contm a descrio geral dos modelos MPS e detalha
o Modelo de Referncia para Software (MR-MPS-SW), seus componentes e as
definies comuns necessrias para seu entendimento e aplicao [SOFTEX,
2012a];
Guia Geral para Servios: contm a descrio geral dos modelos MPS e detalha
o Modelo de Referncia para Servios (MR-MPS-SV), seus componentes e as
definies comuns necessrias para seu entendimento e aplicao [SOFTEX,
2012b];
Guia de Aquisio: descreve um processo de aquisio de software e servios
correlatos. descrito como forma de apoiar as instituies que queiram adquirir
produtos de software e servios correlatos apoiando-se no MR-MPS-SW
[SOFTEX, 2013a];
Guia de Avaliao: descreve o processo e o Mtodo de Avaliao MA-MPS, os
requisitos para avaliadores lderes, avaliadores adjuntos e Instituies
Avaliadoras (IA) [SOFTEX, 2013i];
Guia de Implementao: srie de treze documentos que fornecem orientaes
para implementar nas organizaes os nveis de maturidade descritos no Modelo
de Referncia MR-MPS-SW [SOFTEX, 2013b], [SOFTEX, 2013c], [SOFTEX,
2013d], [SOFTEX, 2013e], [SOFTEX, 2013f], [SOFTEX, 2013g], [SOFTEX,
2013h], [SOFTEX, 2011a], [SOFTEX, 2011b], [SOFTEX, 2011c], [SOFTEX,
2012c], [SOFTEX, 2012d], [SOFTEX, 2012e].
3 Objetivo
O Guia de Implementao fornece orientaes para implementar nas organizaes
os nveis de maturidade descritos no Modelo de Referncia MR-MPS-SW,
detalhando os processos contemplados nos respectivos nveis de maturidade e os
resultados esperados com a implementao dos processos. Este documento
corresponde parte 1 do Guia de Implementao e aborda a implementao do
nvel de maturidade G.
Este documento destinado, mas no est limitado, a organizaes interessadas
em utilizar o MR-MPS-SW para melhoria de seus processos de software e a
Instituies Implementadoras (II). O contedo deste documento informativo, ou


seja, no se espera que uma organizao implementando o MR-MPS-SW atenda a
todos os itens citados na explicao referente aos resultados esperados. As
observaes presentes neste documento procuram apenas explicitar elementos
importantes na interpretao dos resultados esperados. Durante uma avaliao
MPS, s requerido o atendimento aos resultados esperados definidos no Guia
Geral. Os avaliadores MPS devem analisar se a implementao dos processos na
organizao atende a cada resultado, com abertura a mltiplas formas vlidas de
implementao.
4 Comeando a implementao do MR-MPS-SW pelo nvel G
O nvel G o primeiro nvel de maturidade do MR-MPS-SW. Sua implementao
deve ser executada com cautela por estabelecer o incio dos trabalhos em
implantao de melhoria dos processos de software na organizao. Ao final da
implantao deste nvel a organizao deve ser capaz de gerenciar parcialmente
seus projetos de desenvolvimento de software.
Dois pontos so desafiadores na implantao do nvel G: (1) mudana de cultura
organizacional, orientando a definio e melhoria dos processos de desenvolvimento
de software; (2) definio do conceito acerca do que projeto para a organizao.
No nvel G, o projeto pode usar os seus prprios padres e procedimentos, no
sendo necessrio que se tenha padres organizacionais. Se, porventura, a
organizao possuir processos j definidos e os projetos necessitarem adaptar os
processos existentes, deve-se registrar essa adaptao durante o planejamento do
projeto. Adaptaes podem incluir alterao em processos, atividades, ferramentas,
tcnicas, procedimentos, padres, medidas, dentre outras.
Diversas organizaes de software trabalham com evoluo de produtos e precisam
adequar as suas formas de trabalhar para se tornarem organizaes orientadas a
projetos. Ser orientada a projetos significa redefinir algumas operaes (atividades
de rotina) j em andamento, como projeto, estabelecendo objetivos, prazos e escopo
para sua execuo. A prxima seo descreve em mais detalhes o que deve ser
considerado para uma organizao estar orientada a projetos.
5 Gerncia de Projetos (GPR)
5.1 Propsito
O propsito do processo Gerncia de Projetos estabelecer e manter planos
que definem as atividades, recursos e responsabilidades do projeto, bem
como prover informaes sobre o andamento do projeto que permitam a
realizao de correes quando houver desvios significativos no desempenho
do projeto. O propsito deste processo evolui medida que a organizao
cresce em maturidade. Assim, a partir do nvel E, alguns resultados evoluem e
outros so incorporados, de forma que a gerncia de projetos passe a ser
realizada com base no processo definido para o projeto e nos planos
integrados. No nvel B, a gerncia de projetos passa a ter um enfoque


quantitativo, refletindo a alta maturidade que se espera da organizao.
Novamente, alguns resultados evoluem e outros so incorporados.
O processo Gerncia de Projetos (GPR) envolve vrias atividades, como:
desenvolver um plano geral de controle do projeto; obter o comprometimento e
mant-lo ao longo de toda a execuo do projeto; e conhecer o progresso do
projeto, de maneira que aes corretivas possam ser tomadas quando a execuo
do projeto desviar do planejado.
O desenvolvimento do plano do projeto inclui: identificar e estimar o escopo, os
produtos de trabalho e as tarefas do projeto; estabelecer recursos necessrios;
identificar e analisar riscos do projeto; estabelecer compromissos; e definir
cronograma de execuo baseado no ciclo de vida definido para o projeto. O plano
do projeto estabelece a base de execuo e controle para as atividades do projeto
junto aos seus interessados (especialmente o cliente). Todos os interessados devem
estar comprometidos com ele.
O progresso da execuo do projeto determinado pela comparao dos atributos
reais de produtos de trabalho e tarefas, esforo, custo e cronograma com o que foi
planejado nos marcos ou em pontos de controle predefinidos no planejamento do
projeto. Um marco um ponto de reviso, por exemplo, o incio ou o final de cada
fase do projeto ou algumas atividades de fundamental importncia para o seu
sucesso. A reviso de incio de fase de projeto tem por objetivo verificar se as
condies para que uma fase seja iniciada esto atendidas. Pode ser que, mesmo
que a fase anterior no esteja encerrada, seja possvel iniciar a nova fase, nas
condies atendidas e com prazos para o cumprimento de algumas outras
condies. A reviso de fim de fase de projeto tem por objetivo verificar se todos os
critrios de encerramento de fase foram cumpridos. As revises em marcos podem
ter um carter formal, com participao de gerncias superiores, representantes do
cliente e outras partes interessadas no projeto. Sempre que necessrio, deve-se
realizar um replanejamento e uma nova anlise de sua viabilidade. Pontos de
controle representam pontos entre um marco e outro nos quais revises so
realizadas para avaliar o andamento do projeto, porm, no esto no caminho crtico
do projeto, ou seja, o projeto pode prosseguir mesmo que a reviso de um ponto de
controle no tenha sido concluda. A visibilidade apropriada possibilita a tomada de
aes corretivas quando o status do projeto se desvia significativamente do
esperado. Tais aes podem exigir o replanejamento, para incluir a reviso do plano
original, o estabelecimento de novos acordos ou atividades adicionais de mitigao
de riscos no plano.
Alguns resultados do processo Gerncia de Projetos (GPR) evoluem e outros so
adicionados ao processo nos nveis de maturidade E e B do MR-MPS-SW. Esta
parte do Guia de Implementao apresenta orientaes apenas para implementar
nas organizaes os resultados do processo Gerncia de Projetos (GPR) a partir do
nvel de maturidade G do MR-MPS-SW. As orientaes de implementao dos
demais resultados esperados deste processo so apresentadas nas partes 3 e 6 do
Guia de Implementao.


Comentrios adicionais para implementao em diferentes tipos de organizao
Adquirentes
de Software
(Parte 8)
No so permitidas excluses de resultados deste processo.

Fbrica de
Software
(Parte 9)

Fbrica de
Teste
(Parte 10)

5.2 Fundamentao terica
Antes de discorrer sobre gerenciamento de projetos, conveniente definir o que
um projeto. No MPS.BR, a definio de projeto Um empreendimento realizado
para criar um produto. O projeto se caracteriza por temporalidade e resultado,
produto nico e elaborao progressiva [SOFTEX, 2011a]. A temporalidade na
definio de projeto significa que todos os projetos possuem um incio e um fim bem
definidos e estabelecidos. O fim do projeto atingido quando os objetivos do projeto
tiverem sido alcanados, quando se tornar claro que os objetivos no sero ou no
podero ser alcanados ou ainda quando o projeto for cancelado.
O termo produto ou resultado exclusivo so as entregas exclusivas de um projeto.
A exclusividade uma caracterstica importante a ser observada nas entregas do
projeto. Outra caracterstica importante de projeto a elaborao progressiva que
integra os conceitos de temporalidade e exclusividade. Elaborao progressiva
significa desenvolver em etapas e por incrementos. Por exemplo, o escopo do
projeto ser identificado de maneira geral no incio do projeto e se tornar mais claro
e refinado medida que a equipe do projeto desenvolve um entendimento mais
completo dos objetivos e das entregas.
Outro conceito importante a ser destacado so as operaes. Assim como os
projetos, as operaes constituem a execuo de um trabalho para atingir um
conjunto de objetivos, compartilhando algumas caractersticas, por exemplo, so
planejadas, executadas e controladas por pessoas e tm restries de recursos. As
operaes e os projetos diferem principalmente no que diz respeito temporalidade,
pois as operaes so contnuas e repetitivas, enquanto os projetos so temporrios
e exclusivos.
Embora exista essa pequena diferena conceitual entre projeto e operao, muitas
operaes so redefinidas e gerenciadas como projeto, prtica comumente
chamada de Gerenciamento por Projetos. Uma organizao que adota essa
abordagem estabelece atividades de acordo com a definio de projeto apresentada
anteriormente. Contudo, isso no significa que todas as operaes podem ou devem
ser tratadas como projeto. A adoo da abordagem de Gerenciamento por Projeto


envolve tambm a adoo de uma cultura organizacional semelhante cultura de
gerenciamento de projeto.
O PMI (Project Management Institute), um dos mais conceituados e reconhecidos
institutos na rea de gerenciamento de projetos, responsvel pela publicao e
atualizao do PMBOK (Project Management Body of Knowledge) [PMI, 2008]. O
PMBOK um guia em gerncia de projetos. Ele agrupa o conhecimento em
gerncia de projetos que amplamente reconhecido como as boas prticas deste
tipo de gerenciamento.
O gerenciamento de projeto na viso do PMBOK [PMI, 2008] a aplicao de
conhecimento, habilidades, ferramentas e tcnicas s atividades do projeto, a fim de
atender aos seus requisitos. Gerenciar projeto envolve identificar as necessidades,
estabelecer objetivos claros e viveis e balancear as demandas conflitantes em
termos de qualidade, escopo, tempo e custo. Um processo de gerenciamento de
projeto identifica, estabelece, coordena e produz um produto, de acordo com seus
requisitos.
O IEEE (Institute of Electrical and Electronics Engineers), em seu Glossrio Padro
de Terminologias da Engenharia de Software [IEEE, 1990], diz que a gerncia de
projetos de software pode ser definida como a aplicao de planejamento,
coordenao, medio, monitoramento, controle e divulgao de relatrios, com o
intuito de garantir que o desenvolvimento e a manuteno de software sejam
sistemticos, disciplinados e qualificados. E, segundo a norma internacional ISO/IEC
12207, o propsito da gerncia de projetos identificar, estabelecer, coordenar e
monitorar as atividades, tarefas e recursos que um projeto necessita para produzir
um produto, no contexto dos requisitos e restries do projeto [ISO/IEC, 2008].
Vale ressaltar que a gerncia de esforo, custos, cronograma, equipe, riscos e de
outros fatores est intimamente relacionada a tarefas do processo definido do
projeto, o qual pode, tambm, fazer parte do plano do projeto. Certas atividades
sero, em nveis mais altos de maturidade, cobertas em outros planos que afetam o
projeto, como plano de garantia da qualidade, plano de gerncia de riscos, plano de
gerncia de configurao, plano de verificao e plano de validao. No contexto da
gerncia do projeto, integrao inclui caractersticas como unificao, consolidao,
articulao e aes de integrao que so cruciais para concluir o projeto, atender
satisfatoriamente os requisitos dos interessados e clientes e gerenciar as
expectativas [PMI, 2008].

Adquirentes
de Software
(Parte 8)
As organizaes que adquirem software devem planejar as tarefas do
fornecedor de forma macroscpica e as suas prprias tarefas de forma
detalhada. Aps a contratao, dados do planejamento do projeto no
fornecedor podem ser incorporados ao planejamento do projeto na
organizao adquirente. As atividades relacionadas monitorao do
projeto so de grande importncia para as organizaes adquirentes
para assegurar, por um lado, que suas tarefas esto sendo executadas
conforme o planejado e, por outro, para monitorar a execuo do
contrato pelo fornecedor [HOFMANN et al., 2007].


Fbrica de
Software
(Parte 9)
Em organizaes do tipo Fbrica de Software, o gerenciamento do
projeto pode ser realizado da mesma forma que para outros tipos de
organizao. A diferena normalmente reside no escopo do trabalho
que foca a etapa de construo (implementao) de cdigo.

Fbrica de
Teste
(Parte 10)
As organizaes do tipo Fbrica de Teste devem definir o seu projeto
de acordo com as atividades para as quais foi contratada, ou seja, o
teste do produto de software.
A Fbrica de Teste pode ser responsvel pelo desenvolvimento dos
casos de testes e estes podem ser desenvolvidos paralelamente ao
desenvolvimento e/ou manuteno do produto de software. Neste caso,
o planejamento do projeto da Fbrica de Teste deve ser negociado de
forma integrada ao desenvolvimento/manuteno do produto de
software e quaisquer desvios podem levar a um replanejamento.

5.3 Resultados esperados
5.3.1 GPR1 - O escopo do trabalho para o projeto definido
O escopo do projeto define todo o trabalho necessrio, e somente ele, para entregar
um produto que satisfaa as necessidades, caractersticas e funes especificadas
para o projeto, de forma a conclu-lo com sucesso.
O escopo o ponto de partida para o planejamento do projeto. A definio do
escopo deve estabelecer o que est e o que no est includo no projeto. Para isso,
o escopo em geral contm a definio do objetivo e da motivao, os limites e
restries, todos os produtos que sero entregues e os outros produtos gerados pelo
projeto, entre outras informaes.
O escopo pode ser representado por meio de uma Estrutura Analtica do Projeto
(EAP) tambm conhecida como WBS (Work Breakdown Structure). A EAP fornece
um esquema para identificao e organizao das unidades lgicas de trabalho a
serem gerenciadas, que so chamadas de pacotes de trabalho (work packages).
Este resultado tambm pode ser implementado por meio de um Documento de
Viso ou outro documento que defina, claramente, o escopo do trabalho.

Adquirentes
de Software
(Parte 8)
A definio do escopo do trabalho quando h aquisio deve deixar
claro o que responsabilidade do adquirente e o que
responsabilidade do fornecedor.

Fbrica de
Software
Em organizaes do tipo Fbrica de Software importante deixar claro
o que responsabilidade do contratante do servio, uma vez que
normalmente apenas uma parte do ciclo de vida (codificao) compe


(Parte 9)
o escopo do projeto que ser desenvolvido pela Fbrica de Software.
importante inserir na documentao do escopo, a etapa referente
recepo/compreenso das especificaes que, neste caso,
constituem uma parte relevante das atividades iniciais de uma Fbrica
de Software.
igualmente importante inserir na documentao do escopo quais so
as etapas de teste que sero desempenhadas pela Fbrica de
Software.

Fbrica de
Teste
(Parte 10)
A definio do escopo de trabalho deve deixar claro o que
responsabilidade do desenvolvedor do produto e da Fbrica de Teste
em relao aos testes.
Variaes no escopo de trabalho podem incluir, por exemplo:
O desenvolvimento dos casos de testes pela organizao
desenvolvedora ou pela Fbrica de Teste;
A necessidade de serem executados pela organizao
desenvolvedora testes unitrios nos componentes do produto,
antes destes serem enviados para a Fbrica de Teste;
Os tipos de teste que devem ser executados pela Fbrica de
Teste;
A contratao especfica de tipos de teste para cada
componente do software.

5.3.2 GPR2 - As tarefas e os produtos de trabalho do projeto so
dimensionados utilizando mtodos apropriados
O escopo do projeto, identificado na forma dos seus principais produtos de trabalho
e das tarefas do projeto, deve agora ser decomposto em componentes menores,
mais facilmente gerenciveis e possveis de serem dimensionados.
Uma estrutura de decomposio do trabalho apropriada deve ser estabelecida. Esta
estrutura de decomposio pode ser a EAP do projeto ou estrutura equivalente. A
estrutura de decomposio fornece uma referncia para a atribuio de tamanho,
esforo, cronograma e responsabilidades e utilizada como uma estrutura
subjacente para planejar, organizar e controlar o trabalho executado no projeto. O
tamanho a principal entrada de muitos modelos utilizados para estimar o esforo,
custo e cronograma. Este resultado diz respeito estimativa de tamanho, enquanto
o GPR4 refere-se estimativa de esforo e custo.
O tamanho a dimenso das funcionalidades sob o ponto de vista do usurio. So
contadas tabelas internas e externas ao sistema, classes, objetos, relatrios, telas,
consultas a banco de dados, clculos, transaes e atores dos casos de uso, linhas
de cdigo etc. Uma tcnica bastante utilizada para medir o tamanho do software a
tcnica de Anlise de Pontos por Funo (APF) [VAZQUEZ et al., 2005], que visa
estabelecer uma medida de tamanho do software em Pontos por Funo. No


entanto, importante enfatizar que o uso de uma tcnica deste tipo no exigido no
nvel G do MPS.BR, porm ser obrigatria a partir do nvel E. No nvel G, a
estimativa de escopo, produtos e tarefas pode ser feita baseada na complexidade,
no nmero de requisitos ou no uso da EAP juntamente com dados histricos e a
experincia em projetos anteriores. Uma organizao pode tambm aplicar tcnicas
de estimativas prprias que se mostraram eficientes e adequadas s necessidades e
caractersticas da empresa.

Adquirentes
de Software
(Parte 8)
Para organizaes adquirentes, a estimativa precisa de tamanho
essencial para se poder estabelecer, com segurana, o acordo com o
fornecedor. Desta forma, embora no Nvel G do MPS no seja exigido
o uso de tcnicas de estimativa, muito conveniente que estas sejam
utilizadas.

Fbrica de
Software
(Parte 9)
Em organizaes do tipo Fbrica de Software, a estimativa precisa de
tamanho essencial para estabelecer, com segurana, os parmetros
do contrato. Neste caso, esta estimativa tambm mais factvel de ser
obtida, uma vez que o produto j est especificado em nvel mais
detalhado, o que tende a garantir maior preciso na estimativa. Embora
tcnicas de estimativa mais elaboradas no sejam exigidas no Nvel G
do MPS, muito comum que sejam parte da negociao de contratos
em organizaes do tipo Fbrica de Software.

Fbrica de
Teste
(Parte 10)
Para a Fbrica de Teste o estabelecimento de estimativas poder
considerar o nmero de vezes em que os testes devero ser
executados, visto que, a depender da qualidade do produto entregue,
pode ser necessrio que os testes sejam repetidos e um esforo maior
seja acrescentado. Como consequncia, as estimativas de trabalho
podem estipular uma quantidade de testes a serem aplicados e isto
estar definido em contrato.

5.3.3 GPR3 - O modelo e as fases do ciclo de vida do projeto so definidos
O ciclo de vida de um projeto consiste de fases e atividades que so definidas de
acordo com o escopo dos requisitos, as estimativas para os recursos e a natureza
do projeto, visando oferecer maior controle gerencial.
O ciclo de vida de projeto define um conjunto de fases, que por sua vez geram
produtos de trabalho necessrios para o desenvolvimento de fases posteriores. Essa
organizao em fases permite planejar o projeto, incluindo marcos importantes para
o controle e revises.
As fases do ciclo de vida representam, de forma abstrata, o esqueleto do processo,
que pode ser chamado de modelo de ciclo de vida. De maneira geral, este modelo
descreve a estrutura de organizao de atividades do processo em fases e define


como essas fases esto relacionadas. Entretanto, ele no descreve um curso de
aes precisas, recursos, procedimentos e restries. A escolha de um modelo
fortemente dependente das caractersticas do projeto. Assim, importante conhecer
alguns modelos de ciclo de vida e em que situaes so aplicveis. Os principais
modelos de ciclo de vida podem ser agrupados em trs categorias principais:
modelos sequenciais ou cascata, modelos incrementais e modelos evolutivos
[ISO/IEC, 1998]. Cada um destes modelos pode ser utilizado na sua forma original
ou eles podem ser combinados para criar outro modelo de ciclo de vida hbrido. Na
norma ISO/IEC 15271 [ISO/IEC, 1998] a aplicao de cada modelo de ciclo de vida
detalhada. No entanto, outros tipos de modelos de ciclo de vida tm sido cada vez
mais adotados pelas organizaes, como o RUP (Rational Unified Process)
[KRUCHTEN, 2003] e suas variaes.
O ciclo de vida dos projetos pode estar predefinido no mbito organizacional, ou
seja, a organizao pode preestabelecer que todos os projetos tenham o mesmo
ciclo de vida. Pode-se, ainda, predefinir mais de um modelo de ciclo de vida para a
organizao. Neste caso, para cada projeto, ser selecionado aquele que melhor
atender s suas caractersticas.
A determinao das fases do ciclo de vida do projeto possibilita perodos planejados
de avaliao e de tomada de decises, nos quais compromissos significativos so
realizados com relao aos recursos, abordagem tcnica, reavaliao de escopo e
custo do projeto.

Adquirentes
de Software
(Parte 8)
O adquirente e o fornecedor no necessariamente utilizam o mesmo
modelo de ciclo de vida. A definio do modelo de ciclo de vida a ser
utilizado pelo fornecedor pode, ou no, fazer parte do acordo
estabelecido entre o adquirente e o fornecedor. Em qualquer caso,
entretanto, o adquirente deve conhecer e aprovar o modelo de ciclo de
vida utilizado pelo fornecedor. Alm disso, a interao entre o modelo
de ciclo de vida utilizado pelo adquirente e o utilizado pelo fornecedor
devem estar bem definidas.
Em algumas situaes onde o fornecedor no possuir um processo de
desenvolvimento e, como consequncia, tambm no utilizar um
modelo de ciclo de vida adequado e explicitamente definido, a
organizao adquirente pode estabelecer um ciclo de vida a ser
utilizado no projeto, com atividades e verificaes que garantam se
atingir os objetivos do projeto.

Fbrica de
Software
(Parte 9)
As organizaes do tipo Fbrica de Software geralmente executam
apenas uma parte do ciclo de vida, que corresponde s atividades de
implementao (codificao) e testes unitrios ou em nvel de mdulos.
importante detalhar como o ciclo de vida ser organizado e como as
entregas parciais ocorrero, se for o caso. Entregas parciais devem ser
planejadas junto organizao contratante, de modo a sincroniz-las
com o projeto de desenvolvimento como um todo.


Uma etapa essencial neste tipo de organizao a de recepo,
compreenso e aceitao das especificaes recebidas, que deve
preceder o incio da codificao. Refira-se a GRE1 para maiores
detalhes desta etapa.

Fbrica de
Teste
(Parte 10)
O modelo de ciclo de vida definido para ser implementado no projeto
da Fbrica de Teste tende a ser o mesmo utilizado para o
desenvolvimento e/ou manuteno do produto de software. Por
exemplo, se utilizado um modelo de ciclo de vida incremental, os
testes tambm podem ser definidos com este ciclo de vida.
A Fbrica de Teste pode optar, em comum acordo com a contratante,
em realizar um ciclo de vida em que as fases dos testes sejam
executadas em paralelo ao desenvolvimento do produto. Neste caso,
durante a especificao do produto, os casos de testes tambm so
especificados e to logo os componentes do produto estejam prontos,
os testes so realizados. Esta abordagem tende a agilizar o processo
de teste e faz com que o produto seja testado antecipadamente,
permitindo uma viso prvia da sua qualidade.

5.3.4 GPR4 - (At o nvel F) O esforo e o custo para a execuo das tarefas e
dos produtos de trabalho so estimados com base em dados histricos
ou referncias tcnicas
As estimativas de esforo e custo so, normalmente, baseadas nos resultados de
anlises utilizando modelos e/ou dados histricos aplicados ao tamanho, atividades
e outros parmetros de planejamento.
importante destacar que dados histricos incluem os dados de custo, esforo e
tempo de projetos executados anteriormente, alm de dados apropriados de escala
para equilibrar as diferenas de tamanho e complexidade.
As estimativas de esforo e custo tipicamente consideram: o escopo, produtos de
trabalho e as tarefas estimadas para o projeto; os riscos; as mudanas j previstas;
o ciclo de vida escolhido para o projeto; viagens previstas; nvel de competncia da
equipe do projeto, dentre outros.
Normalmente as estimativas do escopo, produtos de trabalho e as tarefas estimadas
para o projeto so afetadas pelos parmetros de produtividade, resultando nas
estimativas de esforo e custo. Os parmetros de produtividade so baseados em
dados histricos e devem ser periodicamente calibrados. Os parmetros de
produtividade podem ter valores diversos, conforme fatores como tecnologia
adotada, experincia do profissional, grau de ineditismo do servio para a
organizao ou para os profissionais alocados.
Empresas implementando o nvel G do MR-MPS-SW geralmente no possuem
bases de dados histricas. Entretanto, para alcanar nveis superiores de
maturidade preciso que essa base seja construda e os dados obtidos pelos
projetos executados, mesmo no nvel G, so fortes candidatos a aliment-la.


Adquirentes
de Software
(Parte 8)
As estimativas de esforo e custo devem ser feitas pelo adquirente de
forma detalhada para as tarefas que executar e de forma
macroscpica para as tarefas a serem executadas pelo fornecedor.

Fbrica de
Software
(Parte 9)
Para as organizaes do tipo Fbrica de Software mais vivel obter
estimativas de maior preciso, uma vez que estas se baseiam em
especificaes mais detalhadas. Devido ao seu escopo reduzido de
atuao (etapa de codificao), as bases histricas tendem a refletir
mais precisamente o relacionamento entre tamanho e esforo.

Fbrica de
Teste
(Parte 10)
Sem comentrio adicional para este resultado.

5.3.5 GPR5 - O oramento e o cronograma do projeto, incluindo a definio de
marcos e pontos de controle, so estabelecidos e mantidos
As dependncias entre tarefas so estabelecidas e potenciais gargalos so
identificados utilizando mtodos apropriados (por exemplo, anlise de caminho
crtico). Os gargalos so resolvidos quando possvel e o cronograma das atividades
com incio, durao e trmino estabelecido. Recursos requeridos so refletidos nos
custos estimados. Uma forma de se definir o cronograma utilizando a EAP e as
estimativas de esforo e custo (GPR4), considerando as dependncias entre as
tarefas e os marcos e pontos de controle eventos que so considerados
significativos no mbito do projeto. importante ter-se o cuidado de manter a
coerncia entre ciclo de vida, EAP, estimativas e cronogramas.
O oramento do projeto estabelecido com base no cronograma e na estimativa de
custos.
Este resultado importante porque o cronograma e o oramento so instrumentos
fundamentais para o acompanhamento do dia-a-dia do projeto. Desta forma, sempre
que necessrio, devem ser revistos e atualizados.

Adquirentes
de Software
(Parte 8)
Aps a contratao do fornecedor, o adquirente deve incorporar no seu
cronograma, marcos e pontos de controle onde far a monitorao do
projeto e do fornecedor. Deve, tambm, incorporar no oramento do
projeto o momento e o valor de cada desembolso para o fornecedor.

Fbrica de
Software
Para as organizaes do tipo Fbrica de Software importante definir
certas pr-condies para o incio de algumas de suas atividades,
como, por exemplo, o recebimento das especificaes vindas da


(Parte 9)
contratante. Em uma organizao do tipo Fbrica de Software, muitas
das dependncias que podem gerar gargalos sero provenientes de
atividades da contratante.

Fbrica de
Teste
(Parte 10)
Para organizaes do tipo Fbrica de Teste importante definir certas
pr-condies para incio de algumas de suas atividades como, por
exemplo, o recebimento do cdigo vindo da contratante.

5.3.6 GPR6 - Os riscos do projeto so identificados e o seu impacto,
probabilidade de ocorrncia e prioridade de tratamento so
determinados e documentados
Projetos tm riscos e estes precisam ser identificados, analisados e priorizados.
Para facilitar a identificao dos riscos, interessante elaborar uma lista de riscos
mais comuns a ser examinada pelo gerente do projeto e/ou equipe do projeto para
identificar quais destes so potenciais riscos para o projeto em questo. A anlise da
probabilidade de ocorrncia e da gravidade dos problemas decorrentes de sua
ocorrncia ajuda a definir a prioridade dos riscos. A monitorao dos riscos
garantida pelo resultado esperado GPR15. Os problemas gerados devido
materializao de riscos podem ser registrados de acordo com os requisitos do
resultado GPR18 e acompanhados de acordo com os requisitos do resultado
GPR19.
Os riscos identificados devem ser registrados, bem como o acompanhamento dos
seus estados e aes tomadas. Uma planilha de riscos, contendo dados como
identificador, descrio, probabilidade, impacto e prioridades no seu tratamento,
pode ser utilizada para identificao dos riscos, monitorao dos riscos identificados
e atualizao da lista de riscos do projeto medida que novos riscos forem sendo
identificados. importante demonstrar que esta planilha est sendo monitorada e
atualizada.
Este resultado no significa o Gerenciamento de Riscos, ou seja, a identificao, o
gerenciamento e a reduo contnua dos riscos nos nveis organizacionais e de
projeto, que so tratados pelo processo Gerncia de Riscos (GRI). No nvel G, os
riscos so acompanhados para verificar como afetam o projeto e para se tomar
aes, mesmo que ainda sem um gerenciamento completo (previsto a partir do nvel
C do MPS pela incorporao do processo Gerncia de Riscos).

Adquirentes
de Software
(Parte 8)
Alm dos riscos para o projeto que podem ter origem no ambiente do
adquirente, projetos que envolvem fornecedores esto sujeitos a riscos
vindos do acordo estabelecido entre o adquirente e o fornecedor e/ou
de caractersticas do fornecedor. Estes riscos precisam ser
identificados para poderem ser monitorados.


Fbrica de
Software
(Parte 9)
Para as organizaes do tipo Fbrica de Software, alm dos riscos
oriundos do prprio projeto, devem ser levados em considerao os
riscos advindos da contratante, como, por exemplo, a no entrega das
especificaes na data planejada ou at mesmo a entrega de
especificaes em qualidade inferior ao necessrio para o incio da
codificao.

Fbrica de
Teste
(Parte 10)
Alm dos riscos oriundos do prprio projeto da Fbrica de Teste,
devem ser levados em considerao os riscos advindos da contratante
como, por exemplo, a no entrega dos cdigos na data planejada ou
uma quantidade e severidade de problemas que impeam a realizao
dos testes planejados.

5.3.7 GPR7 - Os recursos humanos para o projeto so planejados
considerando o perfil e o conhecimento necessrios para execut-lo
O planejamento de recursos humanos determina funes, responsabilidades e
relaes hierrquicas do projeto. As funes do projeto podem ser designadas para
pessoas ou grupos, os quais podem ser internos ou externos organizao. O
planejamento de recursos humanos inclui informaes de como e quando o recurso
ser envolvido no projeto, critrios para sua liberao, competncia necessria para
a execuo das atividades, mapa de competncias da equipe e identificao de
necessidades de treinamento. A existncia de registros das necessidades e
disponibilidade evita a alocao com base em critrios subjetivos.
Este resultado esperado possui dois pontos principais: (i) planejamento prvio das
necessidades de pessoal em relao a competncias (conhecimento, habilidades,
atitudes e experincias) para que as tarefas previstas no decorrer do projeto possam
ser executadas de forma adequada e de acordo com a responsabilidade esperada;
(ii) a alocao dos recursos humanos ao projeto de acordo com o planejamento
realizado. Dessa forma, este resultado implica que o planejamento da alocao de
recursos humanos com base na anlise de suas competncias possudas e
requeridas para desempenhar as tarefas no projeto.
Caso uma pessoa seja alocada ao projeto sem ter as competncias necessrias, o
risco pode ser minimizado, por exemplo, com aes de treinamento e mentoring ou
supervisionando-se o trabalho da pessoa por um membro melhor capacitado. O
treinamento inclui todas as atividades realizadas para aprimorar as competncias
dos membros da equipe do projeto, podendo ser formal ou informal. Exemplos de
mtodos para realizao de treinamentos incluem treinamento em sala de aula, on-
line, baseado em computador, no trabalho, leituras, aconselhamento e orientaes.

Adquirentes
de Software
O adquirente responsvel por identificar os perfis e conhecimento
necessrios para executar o projeto, tanto de seu prprio pessoal,


(Parte 8)
quanto dos recursos humanos a serem providos pelo fornecedor, de
forma a garantir uma alocao adequada de pessoal ao projeto. Aps
a alocao da equipe pelo fornecedor, pode verificar a adequao do
pessoal alocado por meio de anlise das comprovaes pertinentes.
O adquirente pode ser responsvel por treinamentos para o fornecedor
(por exemplo: treinamento no domnio do problema), caso isto faa
parte do acordo estabelecido.

Fbrica de
Software
(Parte 9)

Fbrica de
Teste
(Parte 10)

5.3.8 GPR8 - (At o nvel F) Os recursos e o ambiente de trabalho necessrios
para executar o projeto so planejados
Este resultado faz referncia necessidade de se planejar, com base na EAP (ou
estrutura equivalente), as tarefas e previstos os recursos e o ambiente necessrios,
incluindo, por exemplo, equipamentos, ferramentas, servios, componentes, viagens
e requisitos de processo (processos especiais para o projeto).
Os recursos humanos, incluindo treinamentos, so tratados pelo GPR7.
Todos os recursos precisam ser explicitamente planejados, mesmo os j
considerados como existentes e disponveis ou que sero compartilhados com
outros projetos, uma vez que se trata da sua alocao para uso. Estes itens podem,
por exemplo, estar registrados no plano do projeto. Caso no haja necessidade de
nenhum recurso a ser adquirido para o projeto deve-se registrar o fato de que a
questo foi examinada.
Este resultado importante porque recursos especiais precisam de oramento e
planejamento de sua aquisio, o que pode se tornar crtico em alguns projetos.

Adquirentes
de Software
(Parte 8)
O adquirente deve planejar os recursos e o ambiente de trabalho
necessrios para executar o projeto, identificando o que ele mesmo
deve prover e o que responsabilidade do fornecedor.

Fbrica de
Software
(Parte 9)
Em organizaes do tipo Fbrica de Software tambm pode ser
necessrio planejar os recursos especficos relacionados
compatibilidade com o ambiente da contratante, o que inclui: recursos
para os testes unitrios ou de mdulos, disponibilizao de infra-
estrutura para acesso remoto a repositrios da contratante, treinamento
em ferramentas de uso da contratante etc.


Fbrica de
Teste
(Parte 10)

5.3.9 GPR9 - Os dados relevantes do projeto so identificados e planejados
quanto forma de coleta, armazenamento e distribuio. Um mecanismo
estabelecido para acess-los, incluindo, se pertinente, questes de
privacidade e segurana
Os dados do projeto so as vrias formas de documentao exigidas para sua
execuo, por exemplo: relatrios; dados informais; estudos e anlises; atas de
reunies; documentao; lies aprendidas; artefatos gerados; itens de ao; e
indicadores. Os dados podem estar em qualquer formato e existir em qualquer meio,
como: impressos ou desenhados em diversos materiais; fotografias; meio eletrnico;
e multimdia. Alguns dados podem ser disponibilizados aos clientes, enquanto outros
no necessariamente o sero. A distribuio pode ocorrer de vrias formas,
incluindo a transmisso eletrnica.
A identificao, coleta, armazenamento, distribuio (incluindo regras de segurana
e confidencialidade) para garantir a integridade, acesso e segurana aos dados
devem ser planejados. importante identificar os dados relevantes do projeto, para
depois colet-los, armazen-los e distribu-los de forma controlada, lembrando que
isso implica em custo. Desta forma, os dados devem ser coletados somente quando
forem necessrios. A confidencialidade das informaes, mesmo quando no
declarada pelo cliente, pode ter que ser tratada com cuidado. recomendvel,
portanto, explicitar a existncia ou no de dados confidenciais.
Se a organizao tem um critrio padro para execuo dessas atividades, isto deve
ser registrado no plano do projeto ou em outro documento.

Adquirentes
de Software
(Parte 8)
Este um aspecto crtico e que precisa estar explcito no acordo com o
fornecedor.
O Plano do Projeto deve conter a definio: (i) de como ser o fluxo de
dados entre o adquirente, o fornecedor e demais envolvidos no projeto;
(ii) de como ser o acesso aos dados, reproduo, manipulao,
alterao e transferncia de posse; (iii) de como os dados devero
estar formatados [HOFMANN et al., 2007].

Fbrica de
Software
(Parte 9)


Fbrica de
Teste
(Parte 10)

5.3.10 GPR10 - Um plano geral para a execuo do projeto estabelecido com
a integrao de planos especficos
O objetivo deste resultado esperado garantir que todos os planos que afetam o
projeto estejam integrados e que a dependncia entre estes planos tenha sido
identificada e levada em considerao durante o planejamento, conciliando o
trabalho a ser realizado aos recursos e condies existentes.
A realizao do planejamento do projeto garantida pelos resultados esperados no
escopo do nvel G do MR-MPS-SW do processo Gerncia de Projetos (GPR), que
prev, dentre outros, a criao do cronograma de atividades, o planejamento de
recursos humanos, custos, riscos, dados etc. A reunio destes documentos
entendida como sendo o Plano de Projeto. As tarefas do processo definido para o
projeto podem, tambm, fazer parte deste Plano do Projeto. Esta integrao entre os
planos pode acontecer de vrias formas, entre elas: cronograma gerado com base
nas atividades previstas para o projeto; plano de custos derivado do custo de cada
profissional contemplado no plano de recursos humanos; plano de treinamentos
derivado das tarefas a serem realizadas no projeto e das habilidades e
competncias dos colaboradores, conforme o plano de recursos humanos.
importante existir um alinhamento entre o que foi estimado, o que est sendo
planejado e o que ser acompanhado. A utilizao de uma mesma referncia
propicia maior visibilidade ao projeto, facilitando em muito no s o seu
gerenciamento, mas tambm a formao de uma base histrica. Esta base histrica
poder beneficiar a organizao em etapas posteriores de melhoria.
O monitoramento efetivo do projeto depender de uma organizao adequada
destas informaes de planejamento. Ao longo do projeto, elas devero ser
comparadas aos dados obtidos durante sua execuo, em busca de uma maior
visibilidade do andamento do projeto. Quando necessrio, o planejamento dever
ser revisto.
5.3.11 GPR11 - A viabilidade de atingir as metas do projeto explicitamente
avaliada considerando restries e recursos disponveis. Se necessrio,
ajustes so realizados
O estudo de viabilidade considera o escopo do projeto e examina aspectos tcnicos
(requisitos e recursos), financeiros (capacidade da organizao) e humanos
(disponibilidade de pessoas com a capacitao necessria). Pode-se considerar
tambm os objetivos de negcio e a composio do portflio de projetos da
organizao. Muitas vezes prefervel no iniciar ou parar um projeto j iniciado do
que prosseguir com um projeto invivel, que pode implicar perdas maiores, tanto
para o fornecedor como para o cliente.


No incio do projeto, uma avaliao preliminar pode ser conduzida, a partir da viso
geral dos objetivos e caractersticas dos resultados pretendidos, dos recursos
financeiros, tcnicos e humanos, bem como de restries impostas pelo cliente,
ambiente externo e interno, alm de condies para o desenvolvimento. medida
que o projeto evolui, a viabilidade de sucesso pode ser reavaliada com mais
preciso. As mudanas de requisitos so eventos que podem levar necessidade
de reavaliar a viabilidade do projeto. De qualquer forma, a viabilidade do projeto
deve ser avaliada de forma explcita. Muitas vezes esta avaliao feita de forma
subjetiva ou automtica, o que pode aumentar os riscos da organizao em relao
ao projeto sendo executado.
Em marcos do projeto e mesmo durante as atividades de acompanhamento, pode
ser necessria a confirmao da viabilidade de continuidade do projeto.

Adquirentes
de Software
(Parte 8)
Atividades relacionadas monitorao do fornecedor pelo adquirente
podem indicar no ser vivel a continuidade do projeto ou ser
necessria a sua reviso. O acordo deve estabelecer mecanismos que
possibilitem o seu cancelamento ou sua reviso conforme necessrio.

Fbrica de
Software
(Parte 9)
Um aspecto importante a ser considerado na anlise da viabilidade no
caso de uma organizao do tipo Fbrica de Software, a qualidade
das especificaes recebidas da contratante e a disponibilidade desta
para esclarecimento de dvidas. Este aspecto pode levar
inviabilidade do projeto.

Fbrica de
Teste
(Parte 10)
Um aspecto importante a ser considerado na anlise da viabilidade no
caso de uma organizao do tipo Fbrica de Teste, a qualidade das
especificaes recebidas da contratante para definir os casos de teste.
Este aspecto pode levar inviabilidade do projeto.

5.3.12 GPR12 - O Plano do Projeto revisado com todos os interessados e o
compromisso com ele obtido e mantido
Para obter compromissos dos interessados relevantes, importante revisar o
planejamento com eles e conciliar as diferenas existentes entre os recursos
estimados e disponveis. Negociaes devem ser realizadas quando existirem
conflitos entre as diversas variveis do projeto, como requisitos, custos e prazos. Por
exemplo: o escopo pode sofrer reduo para que as metas de prazos e custos
sejam cumpridas ou, ao contrrio, aumenta-se o oramento do projeto para que os
requisitos sejam atendidos na ntegra, dentro da meta de prazo.
Obter o compromisso pode envolver a interao entre todos os interessados
relevantes internos e externos ao projeto. Os indivduos ou grupos que se
comprometem devero ter a confiana de que o trabalho pode ser executado dentro
das restries de custo, cronograma e desempenho. Ao longo do projeto, de acordo


com a dinmica de sua execuo, novos interessados podem ser identificados e
compromissos anteriormente obtidos podem precisar ser modificados ou revistos.
Dessa forma, necessrio verificar se os compromissos assumidos pelas partes
interessadas esto sendo cumpridos ou negociados, sejam eles internos ou
externos, visando identificar aqueles que no foram satisfeitos ou que possuem um
grande risco de no serem satisfeitos.
Algumas organizaes costumam realizar uma reunio de incio de projeto (kick off)
que pode ser utilizada para resolver os conflitos e obter o comprometimento tanto
dos participantes internos do projeto quanto externos. Deve-se tomar cuidado, no
entanto, para que seja obtido o comprometimento das pessoas que no tenham
participado da reunio de incio de projeto por estarem ausentes ou terem sido
alocadas a tarefas do projeto posteriormente. Outras organizaes utilizam
ferramentas de alocao de tarefas ou gerenciamento de requisies (issue tracking
systems) para a gerncia das tarefas a serem desempenhadas nos projetos. Nestes
casos, uma alternativa seria condicionar o comprometimento de parte da equipe do
projeto aceitao das tarefas alocadas. De qualquer forma, importante, para
minimizar os riscos dos projetos, que o comprometimento dos envolvidos seja obtido
antes da participao na execuo de alguma tarefa.Este resultado esperado est
de certa forma associado ao GPR11, pois a realizao da anlise de viabilidade
pode resultar em aes para soluo de conflitos que impactem no
comprometimento dos envolvidos com o projeto. A integrao dos planos e o
planejamento global dos recursos da organizao tambm contribuem para a
resoluo prvia de conflitos envolvendo, por exemplo, a alocao de profissionais
compartilhados em diferentes projetos ou a conciliao de datas de profissionais das
reas de apoio (por exemplo, Garantia da Qualidade e Gerncia de Configurao). A
soluo dos conflitos e estabelecimento de compromissos fundamental para que o
projeto possa efetivamente contar com os recursos planejados, para atingir as metas
definidas.

Adquirentes
de Software
(Parte 8)
Deve-se ter o compromisso dos participantes do projeto na
organizao adquirente e o compromisso do fornecedor com as partes
do plano, relacionadas s tarefas que executar. O compromisso do
fornecedor pode ser realizado por meio de um representante definido
no acordo estabelecido.

Fbrica de
Software
(Parte 9)
Para as organizaes do tipo Fbrica de Software uma ateno
especial na obteno do compromisso com os participantes externos
ao projeto importante pelo alto grau de integrao e dependncia
entre as atividades de codificao e especificao.

Fbrica de
Teste
(Parte 10)
Uma ateno especial na obteno dos compromissos com os
participantes externos ao projeto importante pelo alto grau de
integrao e dependncia entre as atividades de testes e os resultados
do processo de desenvolvimento de software.


5.3.13 GPR13 - O escopo, as tarefas, as estimativas, o oramento e o
cronograma do projeto so monitorados em relao ao planejado
A aderncia aos diversos planos deve ser avaliada continuamente durante todo o
ciclo de vida do projeto. Os resultados e os critrios de concluso de cada tarefa so
analisados, as entregas so avaliadas em relao s suas caractersticas (por meio
de revises e auditorias, por exemplo), a aderncia ao cronograma e o dispndio de
esforos so examinados, bem como o uso dos recursos. Esta uma atividade
essencial de gerenciamento: acompanhar o que foi planejado, detectar problemas e
corrigi-los.
O objetivo deste resultado esperado assegurar que haja monitorao do projeto
em relao a aspectos relacionados s tarefas, estimativas, oramento e
cronograma (ver GPR2, GPR3, GPR4, GPR5). Em geral, durante um
monitoramento, faz-se uma anlise do que foi planejado anteriormente com os
valores atuais das variveis consideradas. Por exemplo, o conjunto de tarefas
planejadas inicialmente pode sofrer alteraes ao longo da execuo do projeto;
estimativas precisam ser adequadas em decorrncia de alteraes no escopo do
projeto em termos de tarefas e/ou trabalho previsto, adequaes de fatores de ajuste
de produtividade etc.; o oramento do projeto pode sofrer alteraes em decorrncia
dos valores reais dos custos diretos e indiretos do projeto; parte das atividades
presentes no cronograma do projeto pode estar atrasada ou adiantada.
O acompanhamento pode ser realizado utilizando-se ferramentas de planejamento,
em que se pode examinar o previsto contra o realizado, usando-se indicadores de
progresso e cumprimento de marcos, entre outros. O acompanhamento tambm
pode ser feito por meio de reunies e comunicao pessoal. Contudo, importante
ressaltar que devem existir registros desses acompanhamentos.
Em todo o caso, o planejamento do projeto deve ser revisto para adequao dos
itens pertinentes. Anlises devem ser realizadas e decises serem tomadas
considerando-se as variaes dos dados e desvios entre resultados e valores atuais
e esperados. Caso seja necessrio, planos de ao devem ser gerados (ver GPR18
e GPR19) para corrigir problemas ou evitar que outros problemas aconteam
posteriormente.

Adquirentes
de Software
(Parte 8)
O adquirente deve gerenciar sua parte no projeto e, tambm, como o
fornecedor est executando a sua parte de acordo com o acordo e com
os planos estabelecidos e aprovados por ambos.
A gerncia do projeto na organizao adquirente deve garantir a
monitorao do projeto levando em considerao tambm a
dependncia em relao s atividades executadas pelas empresas
contratadas no projeto em questo.


Fbrica de
Software
(Parte 9)

Fbrica de
Teste
(Parte 10)

5.3.14 GPR14 - Os recursos materiais e humanos bem como os dados
relevantes do projeto so monitorados em relao ao planejado
O objetivo deste resultado esperado garantir que o projeto seja monitorado em
relao aos itens planejados referentes a recursos materiais e recursos humanos
(ver GPR7 e GPR8). Em geral, durante um monitoramento, faz-se uma anlise do
que foi planejado anteriormente com os valores atuais das variveis consideradas.
Por exemplo, a sada de um membro da equipe pode disparar a alocao de uma
nova pessoa ou, at mesmo, a contratao de um novo funcionrio na organizao.
Da mesma forma, pode ser necessrio alocar um novo membro da equipe devido
identificao de um novo perfil ou competncia para concluso de uma tarefa. Da
mesma forma, pode ser necessria a compra de novos equipamentos ou softwares
ao longo da execuo do projeto. Outro ponto a ser considerado identificar se
novos documentos devem ser includos no repositrio do projeto ou se os produtos
de trabalho intermedirios do projeto esto de fato sendo produzidos e armazenados
adequadamente.
Em todo o caso, o planejamento do projeto deve ser revisto para adequao dos
itens pertinentes. Caso seja necessrio, planos de ao devem ser gerados (ver
GPR18 e GPR19) para corrigir problemas ou evitar que outros problemas
aconteam posteriormente.

Adquirentes
de Software
(Parte 8)
O adquirente deve gerenciar sua parte no projeto e, tambm, como o
fornecedor est executando a sua parte de acordo com o acordo e com
os planos estabelecidos e aprovados por ambos.

Fbrica de
Software
(Parte 9)

Fbrica de
Teste
(Parte 10)


5.3.15 GPR15 - Os riscos so monitorados em relao ao planejado
No decorrer do projeto novos riscos podem ser identificados para o projeto e os
parmetros dos riscos j identificados podem ser alterados (ver GPR6). Alm disso,
pode ser necessrio executar aes de mitigao para evitar que os riscos
aconteam ou, no caso de riscos terem se concretizado, pode ser preciso executar
aes de contingncia para minimizar seus efeitos. Tambm importante que a lista
de riscos seja reavaliada periodicamente em conjunto com uma avaliao dos seus
parmetros de anlise (probabilidade e impacto) e prioridade. Alteraes realizadas
no planejamento de riscos devem ser comunicadas aos interessados conforme
pertinente.
Caso seja necessrio, planos de ao devem ser gerados (ver GPR18 e GPR19)
para corrigir problemas ou evitar que outros problemas aconteam posteriormente.
Tambm pode ser necessrio rever o planejamento do projeto para adequao dos
itens pertinentes.

Adquirentes
de Software
(Parte 8)
A gerncia do projeto na organizao adquirente deve garantir a
monitorao dos riscos do projeto, que podem estar relacionados a
aspectos que envolvam as empresas contratadas.

Fbrica de
Software
(Parte 9)

Fbrica de
Teste
(Parte 10)

5.3.16 GPR16 - O envolvimento das partes interessadas no projeto planejado,
monitorado e mantido
Devem ser identificados os interessados relevantes no projeto, em que fases eles
so importantes e como eles sero envolvidos (comunicaes, revises em marcos
de projeto, comprometimentos, entre outros). Uma vez identificado e planejado o
envolvimento, este dever ser seguido, monitorado e mantido ao longo de todo o
projeto. Os interessados no projeto podem incluir os clientes e os usurios (ou seus
representantes), a direo da organizao e os membros da equipe do projeto. Em
projetos pequenos, estas atividades podem ser simplificadas devido ao pequeno
nmero de interessados e a pouca comunicao necessria em funo do curto
prazo.
A comunicao envolve, por exemplo, questes relativas a prazos, custos, recursos,
comprometimentos e tambm requisitos, pois estes afetam as outras variveis. Um
plano de gerenciamento das comunicaes pode cobrir este resultado esperado


[PMI, 2008]. O distanciamento da gerncia do projeto em relao aos interessados
pode acarretar desvios em relao s reais necessidades que o projeto dever
atender.
Este resultado tem relao com GRE1, em funo da comunicao necessria para
o entendimento dos requisitos junto aos seus fornecedores. No processo Gerncia
de Projetos, o foco mais amplo e envolve outros aspectos. indicado que os
fornecedores de requisitos e representantes do cliente saibam antecipadamente o
momento em que devero se envolver no projeto e o que se espera desta
participao. O mesmo deve ser aplicado aos membros da equipe do projeto.

Adquirentes
de Software
(Parte 8)
A gerncia do projeto na organizao adquirente deve garantir o
envolvimento das partes interessadas internas organizao e o
envolvimento do fornecedor.

Fbrica de
Software
(Parte 9)
Para as organizaes do tipo Fbrica de Software importante o
monitoramento das atividades externas, que dependem da contratante
como, por exemplo, a entrega das especificaes na data acordada.

Fbrica de
Teste
(Parte 10)
O envolvimento dos interessados essencial para analisar se o projeto
continua com os objetivos iniciais ou se estes foram alterados. Manter
o envolvimento dos interessados e do contratante nos resultados dos
testes pode subsidiar o contratante com informaes que o ajudaro a
tomar decises importantes em relao manuteno da qualidade do
produto de software.

5.3.17 GPR17 - Revises so realizadas em marcos do projeto e conforme
estabelecido no planejamento
Revises em marcos do projeto no devem ser confundidas com o
acompanhamento descrito em GPR13, GPR14 e GPR15, que derivado do
acompanhamento do dia-a-dia do projeto. Os marcos do projeto precisam, portanto,
ser previamente definidos ao se realizar o planejamento do projeto.
Este resultado importante porque as revises em marcos so oportunidades para
verificar, de forma ampla, o andamento de todo o projeto, independente do
acompanhamento do dia-a-dia. Em projetos grandes essas revises so
fundamentais, questionando, inclusive, a viabilidade de continuidade do projeto.
Alm das revises em marcos, outras revises podero ser estabelecidas no
planejamento do projeto. Caso isto ocorra, estas revises devero ser executadas
conforme planejado.


Adquirentes
de Software
(Parte 8)
O Plano do Projeto deve estabelecer os marcos e pontos de controle
do projeto e que produtos devem ser revistos em cada um. A
organizao adquirente responsvel pela reviso, nestes pontos, dos
produtos cujo desenvolvimento est sob sua responsabilidade e dos
produtos sob a responsabilidade do fornecedor.

Fbrica de
Software
(Parte 9)

Fbrica de
Teste
(Parte 10)

5.3.18 GPR18 - Registros de problemas identificados e o resultado da anlise
de questes pertinentes, incluindo dependncias crticas, so
estabelecidos e tratados com as partes interessadas
As atividades de reviso em marcos (GPR17) e de monitoramento (GPR13, GPR14
e GPR15) do projeto possibilitam a identificao de problemas que estejam
ocorrendo nos projetos. natural que problemas e desvios em relao ao
planejamento aconteam durante a execuo dos projetos. Estes problemas e
desvios devem ser analisados e registrados, por exemplo, por meio de ferramentas
especficas, planilhas ou outros tipos de mecanismos de gerenciamento de
problemas. A falha na execuo desta tarefa pode afetar a habilidade de executar
aes para correo dos desvios, afetando o bom andamento do projeto.
Para completar o trabalho de monitoramento do projeto, os problemas precisam ser
corrigidos e gerenciados at a sua resoluo, com base em planos de aes,
estabelecidos especificamente para resolver os problemas levantados e registrados
(GPR19). Caso no se consiga resolver os problemas neste nvel, deve-se
escalonar a resoluo das aes a nveis superiores de gerncia.

Adquirentes
de Software
(Parte 8)
Deve ser registrado tanto o que teve origem na organizao adquirente
quanto o que teve origem no fornecedor e foi identificado nas revises
feitas pelo adquirente.

Fbrica de
Software
(Parte 9)
Para as organizaes do tipo Fbrica de Software as dependncias
crticas, em geral, tambm esto associadas ao relacionamento com a
contratante, que a organizao responsvel por prover as
especificaes.


Fbrica de
Teste
(Parte 10)

5.3.19 GPR19 - Aes para corrigir desvios em relao ao planejado e para
prevenir a repetio dos problemas identificados so estabelecidas,
implementadas e acompanhadas at a sua concluso
Como resultado do acompanhamento do projeto (GPR13, GPR14 e GPR15) e das
revises em marcos (GPR17), problemas so identificados, analisados e registrados
(GPR18). Aes corretivas devem ser estabelecidas para resolver problemas que
possam impedir o projeto de atingir seus objetivos se no forem resolvidos de forma
adequada. As aes corretivas definidas devem ser gerenciadas at serem
concludas. O controle dos problemas levantados, as aes tomadas, os
responsveis pelas aes e os resultados devem ser registrados.
Os problemas identificados, e devidamente registrados, provem a base para a
tomada de aes corretivas. Quando apropriado, e quando o impacto e os riscos
associados so identificados e gerenciados, as mudanas podem ser realizadas no
projeto. Estas mudanas podem tomar a forma de aes corretivas, podem envolver
a incorporao de contingncias para que ocorrncias similares sejam evitadas e/ou
encadear a reviso de vrios planos e documentos relacionados para acomodar os
problemas inesperados e suas implicaes. Acompanhar o andamento de uma ao
corretiva at sua concluso inclui verificar, com uma certa frequncia, se ela j foi
resolvida e atuar em possveis pendncias. Caso no se consiga resolver neste
nvel, deve-se escalonar a resoluo das aes a nveis superiores de gerncia.
As aes corretivas estabelecidas podem ser reportadas para a gerncia de alto
nvel da organizao e para os interessados no projeto, como clientes e usurios.

Adquirentes
de Software
(Parte 8)
Devem ficar, claramente, definidas as responsabilidades da
organizao adquirente e do fornecedor na resoluo das aes
corretivas.

Fbrica de
Software
(Parte 9)
Para as organizaes do tipo Fbrica de Software os problemas
identificados podem envolver as especificaes provenientes da
contratante, o que pode implicar em replanejamento e at mesmo
renegociao de contrato. Nestes casos, importante identificar quem
ser o responsvel pela ao corretiva: a Fbrica de Software ou a
contratante.
Esta identificao pode variar conforme as caractersticas do projeto ou
devido a condies contratuais de atuao junto contratante. Nestes
casos, a definio da responsabilidade pela ao corretiva pode estar
definida e registrada, por exemplo, no contrato ou no plano de projeto.


Fbrica de
Teste
(Parte 10)
Em organizaes do tipo Fbrica de Teste, a responsabilidade pela
ao corretiva pode variar. recomendado que isto j esteja definido
no plano de projeto ou no contrato. De qualquer forma, dever ser
registrado na resoluo de problemas, quem o responsvel pelas
aes corretivas, se os membros do projeto ou a contratante.

6 Gerncia de Requisitos (GRE)
6.1 Propsito
O propsito do processo Gerncia de Requisitos gerenciar os requisitos do
produto e dos componentes do produto do projeto e identificar
inconsistncias entre os requisitos, os planos do projeto e os produtos de
trabalho do projeto.
O principal objetivo da Gerncia de Requisitos controlar a evoluo dos requisitos.
O processo Gerncia de Requisitos (GRE) gerencia todos os requisitos recebidos ou
gerados pelo projeto, incluindo requisitos funcionais e no-funcionais, bem como os
requisitos impostos ao projeto pela organizao.
Para assegurar que o conjunto de requisitos acordados gerenciado e fornece
apoio s necessidades de planejamento e execuo do projeto, a organizao deve
executar um conjunto de passos definidos e apropriados. Quando um projeto recebe
requisitos de um fornecedor de requisitos pessoa autorizada a participar de sua
definio e a solicitar modificao , estes devem ser revisados para resolver
questes e prevenir o mau entendimento, antes que os requisitos sejam
incorporados ao escopo do projeto. Quando o fornecedor de requisitos e a
organizao chegam a um acordo, obtido um compromisso das demais partes
interessadas sobre os requisitos.
Outras atribuies do processo Gerncia de Requisitos so documentar as
mudanas nos requisitos e suas justificativas, bem como manter a rastreabilidade
bidirecional entre os requisitos e produtos de trabalho em geral e identificar
inconsistncias entre os requisitos, os planos do projeto e os produtos de trabalho
do projeto.

Adquirentes
de Software
(Parte 8)

Fbrica de
Software
(Parte 9)


Fbrica de
Teste
(Parte 10)

6.2 Fundamentao terica
Uma boa comunicao com os fornecedores de requisitos fundamental para
assegurar um bom entendimento das necessidades do cliente e dos requisitos do
projeto e, consequentemente, aumentar as chances de sucesso do projeto.
Existem diversos assuntos ligados a requisitos que devem ser tratados com os
fornecedores de requisitos, como por exemplo: definio de requisitos, aprovao de
requisitos, solicitao de mudana nos requisitos, dentre outros.
Segundo Dorfmann e Thayer [1990], requisito de software representa a capacidade
requerida pelo usurio que deve ser encontrada ou possuda por um determinado
produto ou componente de produto para resolver um problema ou alcanar um
objetivo ou para satisfazer a um contrato, a um padro, a uma especificao ou a
outros documentos formalmente impostos.
A gerncia de requisitos envolve identificar os requisitos do produto e dos
componentes do produto do projeto, bem como estabelecer e manter um acordo
entre o cliente e a equipe de projeto sobre esses requisitos. Tambm objetivo da
gerncia de requisitos controlar e tratar as mudanas nos requisitos ao longo do
desenvolvimento.
Para apoiar o processo de mudana de requisito, fundamental definir e manter a
rastreabilidade dos requisitos. Rastreabilidade o grau em que o relacionamento
pode ser estabelecido entre dois ou mais produtos de desenvolvimento de software,
especialmente produtos que tenham uma relao de predecessor sucessor ou de
mestre subordinado com outro; por exemplo, o grau em que requisitos e projeto
(design) de um determinado componente de software combinam [IEEE, 1990].
Quando os requisitos so bem gerenciados, a rastreabilidade pode ser estabelecida,
desde um requisito fonte, passando por todos os nveis de decomposio do produto
at seus requisitos de mais baixo nvel e destes at 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 nvel podem ser
rastreados para uma fonte vlida [SEI, 2010].
A rastreabilidade bidirecional deve acontecer tanto de forma horizontal quanto
vertical. A rastreabilidade horizontal estabelece a dependncia entre os requisitos ou
produtos de trabalho em um mesmo nvel, por exemplo, rastreabilidade dos
requisitos entre si ou rastreabilidade entre cdigos de unidades dependentes. A
rastreabilidade vertical estabelece uma rastreabilidade bidirecional desde um
requisito fonte, passando pelos seus requisitos de mais baixo nvel, at o nvel de
decomposio mais baixo do produto, por exemplo, cdigos de unidade ou mdulos
do software. Esse mecanismo deve permitir tambm rastrear itens do nvel mais
baixo de decomposio do produto at o(s) seu(s) requisito(s) fonte. A
rastreabilidade vertical auxilia a determinar se todos os requisitos fonte foram


completamente tratados e se todos os requisitos de mais baixo nvel ou cdigos de
unidade podem ser rastreados para um requisito fonte vlido. A rastreabilidade
vertical bidirecional possibilita, ento, rastrear requisitos e produtos de trabalho a
cdigos de unidade ou mdulos do software implementados. Esse mecanismo de
rastreabilidade vertical essencial para a realizao da anlise de impacto de
mudanas de requisitos, por exemplo, para identificar de que forma uma mudana
de requisito impacta nos planos do projeto que contm as estimativas aprovadas de
esforo e custo para os produtos de trabalho e tarefas, bem como os cdigos de
unidade ou mdulos do software que necessitam ser modificados. Por essas
anlises, o responsvel pela gerncia do projeto capaz de negociar com o cliente
alteraes nos planos do projeto para atender s solicitaes de mudanas de
requisitos e, ao mesmo tempo, minimizar os riscos do projeto, como por exemplo,
desvios de cronograma e de custos.

Adquirentes
de Software
(Parte 8)
Gerenciar requisitos em organizaes que adquirem software envolve a
gerncia de requisitos resultante de atividades que executa e monitorar
o processo de gerncia de requisitos do fornecedor.

Fbrica de
Software
(Parte 9)
Para as organizaes do tipo Fbrica de Software a gerncia de
requisitos envolve gerenciar as modificaes nas especificaes
provenientes da organizao contratante.

Fbrica de
Teste
(Parte 10)
A gerncia de requisitos para a Fbrica de Teste deve ser entendida
como a gerncia de requisitos de teste.
As mudanas de requisitos no produto de software e que est sendo
gerenciada por uma outra parte devem ser monitoradas para que os
requisitos de teste estejam aderentes aos requisitos do produto.

6.3 Resultados esperados
6.3.1 GRE1 - O entendimento dos requisitos obtido junto aos fornecedores
de requisitos
O objetivo deste resultado garantir que os requisitos estejam claramente definidos
a partir do entendimento dos requisitos realizado junto aos fornecedores de
requisitos. Informaes sobre esses fornecedores podem ser identificadas no plano
do projeto, bem como informaes sobre como ser a comunicao com eles. Essas
comunicaes devem ser registradas formalmente em atas, e-mails, ferramentas de
comunicao ou outros meios.
Como comprovao do entendimento, os requisitos devem ser documentados. Esta
documentao pode assumir diferentes formas de acordo com as necessidades da
organizao, por exemplo, uma lista de requisitos, especificaes de casos de uso,


especificaes de estrias, ou ainda detalhados conforme uma metodologia prpria
da organizao.
Aps a identificao dos requisitos do produto e dos componentes do produto do
projeto, importante garantir que os requisitos propostos atendam s necessidades
e expectativas do cliente e dos usurios.
Aps a avaliao dos requisitos, um registro de aceite dos requisitos deve ser obtido
pelos fornecedores de requisitos. Esse registro pode ser tratado como um marco do
projeto a partir do qual mudanas nos requisitos devem ser tratadas formalmente
para minimizar o impacto dessas mudanas no projeto em termos de escopo,
estimativas e cronograma, bem como compromissos j estabelecidos. Sempre que
forem aprovadas mudanas nos requisitos, deve-se obter novas aprovaes dos
requisitos do projeto, se possvel, a partir de critrios estabelecidos.

Adquirentes
de Software
(Parte 8)
Dependendo das caractersticas da aquisio, as atividades
relacionadas a este resultado podem, no incio do projeto, ser
realizadas pela organizao adquirente ou pelo fornecedor. De
qualquer forma, ao se iniciar sua participao no projeto, importante
que a organizao fornecedora realize atividades direcionadas a
entender, avaliar e aceitar os requisitos.

Fbrica de
Software
(Parte 9)
Para as organizaes do tipo Fbrica de Software as atividades
relacionadas a este resultado envolvem o entendimento e a aceitao
das especificaes enviadas pela organizao contratante. As
especificaes recebidas constituem, neste caso, os requisitos do
projeto.

Fbrica de
Teste
(Parte 10)
Dependendo das caractersticas do projeto de teste, as atividades
relacionadas a este resultado podem ter sido especificadas pelo
adquirente quando da contratao da fbrica de teste. No entanto, a
fbrica de teste responsvel por entender, avaliar e aceitar os
requisitos, incluindo os requisitos especficos para teste.

6.3.2 GRE2 - Os requisitos so avaliados com base em critrios objetivos e
um comprometimento da equipe tcnica com estes requisitos obtido
A avaliao e aprovao por parte do cliente aps o entendimento dos requisitos por
si s no suficiente para que os requisitos sejam refinados e refletidos em modelos
de anlise e projeto para a codificao. A avaliao dos requisitos deve envolver,
alm do cliente, tambm, a equipe tcnica
2
da organizao, podendo ser realizada
de diversas formas. Alm disso, um comprometimento formal da equipe tcnica com

2
A equipe tcnica compreende todos os envolvidos diretamente no desenvolvimento do produto, por
exemplo, analistas de sistemas, desenvolvedores, projetistas, entre outros.


os requisitos deve ser obtido e registrado, por exemplo, na forma de ata de reunio,
e-mail ou algum outro mecanismo. Em geral, aconselhvel que os requisitos sejam
avaliados pela equipe tcnica antes de serem submetidos para aprovao pelo
cliente para evitar retrabalho ou a apresentao de um documento sem qualidade
tcnica adequada para o cliente.
Os requisitos identificados podem ser avaliados com base em um conjunto de
critrios objetivos, previamente estabelecidos. Alguns exemplos de critrios so:
possuir identificao nica; estar claro e apropriadamente declarado; no ser
ambguo; ser relevante; ser completo; estar consistente com os demais requisitos;
ser implementvel, testvel e rastrevel [IEEE, 1998]. O uso de um checklist para
apoiar esta atividade pode ser til, pois favorece a identificao dos problemas mais
frequentes em relao especificao de requisitos. Nem todos os membros da
equipe tcnica do projeto precisam efetivamente participar da avaliao dos
requisitos com base em critrios estabelecidos. No entanto, importante que haja o
comprometimento de todos para que diminua o risco de os requisitos no serem
entendidos perfeitamente por todos ou no poderem ser tratados adequadamente
durante as atividades subsequentes do projeto.
Uma prtica que algumas organizaes tm realizado com o intuito de satisfazer
este resultado a realizao de uma reunio de kick off na qual se apresenta o
projeto como um todo (incluindo seus requisitos). Esta reunio possibilita que as
diversas partes possam opinar, aprovar e se comprometer em relao aos requisitos
do projeto. Em alguns casos, essa reunio feita posteriormente. importante
observar que mudanas de requisitos aprovados pelos fornecedores de requisitos
podem afetar compromissos j estabelecidos pela equipe tcnica. Nestes casos, um
novo comprometimento da equipe tcnica com os requisitos modificados deve ser
obtido e registrado aps os requisitos modificados terem sido novamente aprovados
junto aos fornecedores de requisitos.

Adquirentes
de Software
(Parte 8)
Independentemente de quem foi responsvel pela identificao de
requisitos (organizao adquirente ou fornecedor), toda a equipe
tcnica envolvida no desenvolvimento do produto deve se comprometer
com os requisitos. O comprometimento do representante do fornecedor
suficiente para evidenciar o comprometimento de toda a sua equipe
tcnica em uma avaliao MPS da organizao adquirente.
Em qualquer circunstncia responsabilidade do adquirente definir os
critrios objetivos para avaliao dos requisitos.

Fbrica de
Software
(Parte 9)

Fbrica de
Teste
(Parte 10)


6.3.3 GRE3 - A rastreabilidade bidirecional entre os requisitos e os produtos
de trabalho estabelecida e mantida
Este resultado indica a necessidade de se estabelecer um mecanismo que permita
rastrear a dependncia entre os requisitos e os produtos de trabalho. Ter definida a
rastreabilidade facilita a avaliao do impacto das mudanas de requisitos que
possam ocorrer, por exemplo, nas estimativas do escopo, nos produtos de trabalho
ou nas tarefas do projeto descritas no cronograma.
Ao longo do projeto, os requisitos assumem diferentes abstraes e denominaes.
Por exemplo, podem estar descritos na forma de necessidades e restries do
cliente, requisitos de cliente, requisitos funcionais e no funcionais, casos de uso,
requisitos tcnicos, requisitos de produto, estrias etc. Os requisitos, dentro do ciclo
de vida do projeto, so posteriormente derivados em elementos de anlise e projeto
(design) e, ento, transformados em cdigo fonte para, ento, serem testados
(preferencialmente com base em casos de testes especficos).
Em geral, o detalhamento dos requisitos, a transformao em modelos, a
codificao e o planejamento e a execuo de testes so planejados para garantir a
correta execuo do projeto, possivelmente, tendo tarefas previstas para as aes
citadas anteriormente em um Plano do Processo para o Projeto ou em um
cronograma, conforme previsto pelo processo Gerncia de Projetos (GPR). Dessa
forma, a existncia de rastreabilidade horizontal e vertical, conforme prevista neste
resultado esperado, pressupe que diferentes abstraes dos requisitos (por
exemplo, requisitos de cliente ou casos de uso), documentos relacionados (por
exemplo, cronogramas e casos de testes) e o cdigo fonte sejam rastreveis entre
si. importante ressaltar que este resultado estabelece a criao de um sistema de
rastreamento e que no necessariamente envolve a criao de uma matriz de
rastreabilidade especfica para atendimento ao resultado esperado. Contudo, deve
existir um mecanismo que possibilite a realizao da rastreabilidade bidirecional
entre os requisitos e os demais produtos de trabalho.

Adquirentes
de Software
(Parte 8)
Em algumas situaes, dependendo do acordo estabelecido com o
fornecedor, responsabilidade da organizao fornecedora
estabelecer e manter a rastreabilidade bidirecional dos requisitos
definidos e responsabilidade da organizao adquirente verificar a
sua adequao. Em outras situaes, tambm dependendo do acordo,
parte da responsabilidade de elaborao e manuteno da
rastreabilidade da organizao adquirente e parte da organizao
fornecedora.
Em uma avaliao MPS, a organizao adquirente deve evidenciar que
possui o documento de rastreabilidade para os projetos concludos e
que realizou a sua avaliao para os projetos concludos e em
andamento.


Fbrica de
Software
(Parte 9)
Para as organizaes do tipo Fbrica de Software a rastreabilidade
bidirecional dos requisitos envolve a rastreabilidade das especificaes
recebidas em relao aos produtos produzidos pela prpria Fbrica de
Software (ex.: cdigo, planos de teste unitrio etc.). Neste caso, como
a Fbrica de Software no tem acesso aos requisitos originais do
cliente ou suas necessidades de negcio, no ter como manter a
rastreabilidade destes itens com os demais produtos por ela
produzidos. H casos em que a contratante impem Fbrica de
Software o seu padro de gerenciamento da rastreabilidade e, nestes
casos, este fato poder estar registrado no contrato ou no plano de
projeto.

Fbrica de
Teste
(Parte 10)
A rastreabilidade bidirecional, neste caso, feita em relao aos
produtos de trabalho que sero gerados pela fbrica de teste (por
exemplo: requisitos de teste, casos de teste, plano de teste e
componentes automatizados) e aos requisitos. O objetivo especificar
um mecanismo para analisar o impacto nos testes, quando uma
mudana nos requisitos ocorrer.
H casos em que a contratante impem Fbrica de Teste o seu
padro de gerenciamento da rastreabilidade e, nestes casos, este fato
poder estar registrado no contrato ou no plano de projeto.
Em uma avaliao MA-MPS os documentos produzidos pelo processo
de desenvolvimento (por exemplo: classe ou especificaes) no faro
parte do escopo da Fbrica de Teste.

6.3.4 GRE4 - Revises em planos e produtos de trabalho do projeto so
realizadas visando a identificar e corrigir inconsistncias em relao aos
requisitos
A consistncia entre os requisitos e os produtos de trabalho do projeto deve ser
avaliada e os problemas identificados devem ser corrigidos.
Este resultado sugere, portanto, a realizao de revises ou de algum mecanismo
equivalente para identificar inconsistncias entre os requisitos e os demais
elementos do projeto como, por exemplo, planos, atividades e produtos de trabalho.
As inconsistncias identificadas devem ser registradas e aes corretivas
executadas a fim de resolv-las. Exemplos de revises com esse objetivo so
revises de monitorao e controle do projeto e inspees baseadas em critrios
explcitos para identificar inconsistncias entre os planos, atividades e produtos de
trabalho com os requisitos e com mudanas nesses requisitos.
Quando h mudanas nos requisitos, importante examinar se os demais artefatos
esto consistentes com as alteraes realizadas como, por exemplo: verificar se a
planilha de estimativas est contemplando todos os requisitos e mudanas; verificar
se as mudanas dos requisitos foram incorporadas ao escopo ou cronograma do
projeto; e outros.


As aes para correes das inconsistncias devem ser acompanhadas at que
sejam resolvidas.

Adquirentes
de Software
(Parte 8)
Ao longo do projeto responsabilidade da organizao adquirente e da
organizao fornecedora realizarem revises visando garantir a
consistncia entre os requisitos e os produtos de trabalho do projeto. A
organizao adquirente pode delegar esta responsabilidade para o
fornecedor mas, neste caso, deve verificar se a reviso foi realizada de
forma adequada e as inconsistncias corrigidas.

Fbrica de
Software
(Parte 9)

Fbrica de
Teste
(Parte 10)

6.3.5 GRE5 - Mudanas nos requisitos so gerenciadas ao longo do projeto
Durante o projeto, os requisitos podem mudar por uma srie de motivos. Desta
forma, requisitos adicionais podem ser incorporados no projeto, requisitos podem ser
retirados do projeto e/ou mudanas podem ser feitas nos requisitos j existentes.
Ressalta-se que, devido s mudanas, os requisitos podem ter que ser revistos,
conforme definido no GRE4.
As necessidades de mudanas devem ser registradas e um histrico das decises
acerca dos requisitos deve estar disponvel. Estas decises so tomadas por meio
da realizao de anlises de impacto da mudana no projeto e podem incluir
aspectos como: influncia em outros requisitos, expectativa dos interessados,
esforo, cronograma, riscos e custo. importante destacar que o mecanismo de
rastreabilidade bidirecional institudo um importante mecanismo para facilitar a
anlise de impacto.
Muitas vezes mudanas nos projetos acontecem em diferentes nveis de abstrao
dos requisitos, no apenas nos requisitos de cliente. Por exemplo, mudanas em
casos de uso ou que afetem prottipos de telas podem precisar ser gerenciadas
utilizando um mecanismo mais formal de controle de mudana. Dessa forma,
indicado que a organizao determine a aplicabilidade da gerncia de mudana,
conforme descrito neste resultado esperado.
importante ressaltar que em um projeto no obrigatrio que sempre ocorram
mudanas nos requisitos estabelecidos. Porm, raro um projeto no ter mudanas.
Tambm vale ressaltar que, em uma avaliao da implementao deste resultado
esperado segundo o mtodo MA-MPS definido no Guia de Avaliao [SOFTEX,


2011b], evidncias da gerncia de mudanas de requisitos devem ser fornecidas
pelo menos para um dos projetos avaliados.

Adquirentes
de Software
(Parte 8)
Mudanas nos requisitos de um projeto, muitas vezes, tm como
consequncia a necessidade de alteraes no acordo estabelecido
entre adquirente e fornecedor. Esta reviso do acordo deve ser
realizada, quando pertinente, tendo em conta a anlise de impacto
realizada.

Fbrica de
Software
(Parte 9)

Fbrica de
Teste
(Parte 10)
As mudanas nos requisitos de um projeto podem surgir de diversas
fontes, principalmente quando se est desenvolvendo os testes
paralelamente ao desenvolvimento do produto. Portanto, mecanismos
para definir como as mudanas de requisitos sero gerenciadas e/ou
repassadas para a Fbrica de Teste pelo adquirente devem ser
estabelecidos e declarados. Em alguns casos, estas definies devem
estar explicitadas em contrato.

7 Os atributos de processo no nvel G
De acordo com o Guia Geral do MR-MPS-SW, a capacidade do processo
representada por um conjunto de atributos de processo descrito em termos de
resultados esperados. A capacidade do processo expressa o grau de refinamento e
institucionalizao com que o processo executado na organizao/unidade
organizacional. No MR-MPS-SW, medida que a organizao/unidade
organizacional evolui nos nveis de maturidade, um maior nvel de capacidade para
desempenhar o processo deve ser atingido [SOFTEX, 2011a].
Vale, ainda, ressaltar que Os nveis so acumulativos, ou seja, se a organizao
est no nvel F, esta possui o nvel de capacidade do nvel F que inclui os atributos
de processo dos nveis G e F para todos os processos relacionados no nvel de
maturidade F (que tambm inclui os processos do nvel G) [SOFTEX, 2011a]. No
que se refere aos atributos de processo, para atingir o nvel G do MR-MPS-SW, uma
organizao deve atender aos resultados esperados RAP1 a RAP10. Numa
avaliao, segundo o MA-MPS [SOFTEX, 2011b], exigido, para se considerar um
processo SATSFETO no nvel G, que o atributo de processo AP 1.1 seja
caracterizado como T (Totalmente implementado) e que o atributo de processo AP
2.1 seja caracterizado como T (Totalmente implementado) ou L (Largamente
implementado). importante destacar que, a partir do nvel E, as exigncias so
diferentes, conforme descrito no Guia de Avaliao [SOFTEX, 2011b].
A seguir, os atributos de processo AP 1.1 e AP 2.1, conforme aplicveis no nvel G,
so descritos com detalhes.


Adquirentes
de Software
(Parte 8)
No h nenhuma alterao nos resultados esperados para os atributos
de processo pelo fato de tratar-se de uma organizao que adquire
software. Todavia, estes resultados devero ser interpretados no
contexto dos processos definidos para esta situao.
No so permitidas excluses de resultados de atributos de processo.

Fbrica de
Software
(Parte 9)
de processo pelo fato de tratar-se de uma organizao do tipo Fbrica
de Software. Todavia, estes resultados devero ser interpretados no
contexto dos processos definidos para a Fbrica de Software.

Fbrica de
Teste
(Parte 10)
de processo pelo fato de tratar-se de uma organizao do tipo Fbrica
de Teste. Todavia, estes resultados devero ser interpretados no
contexto dos processos definidos para a Fbrica de Teste.

7.1 AP 1.1 - O processo executado
Este atributo evidencia o quanto o processo atinge o seu propsito.
Este atributo de processo est diretamente relacionado ao atendimento do propsito
do processo. Relacionado a este atributo de processo est definido o seguinte
resultado esperado:
7.1.1 RAP1 - O processo atinge seus resultados definidos
Este resultado esperado busca garantir que o processo transforma produtos de
trabalho de entrada identificveis em produtos de trabalho de sada, tambm
identificveis, permitindo, assim, atingir o propsito do processo. Ou seja, este
resultado implica diretamente na gerao dos principais produtos requeridos pelos
resultados dos processos.
7.2 AP 2.1 - O processo gerenciado
Este atributo evidencia o quanto a execuo do processo gerenciada.
Este atributo de processo est relacionado gerncia dos processos. A
implementao deste atributo de processo implica no planejamento da execuo do
processo, atribuindo responsabilidade e autoridade para sua execuo, bem como
fornecendo recursos adequados. Envolve tambm o monitoramento e controle da
execuo dos processos, tomando aes corretivas, quando necessrias.


Relacionados a este atributo de processo esto definidos os seguintes resultados
esperados:
7.2.1 RAP2 - Existe uma poltica organizacional estabelecida e mantida para o
processo
Este resultado visa definio de uma poltica contendo as diretrizes de como a
organizao planeja e implementa os seus processos, bem como informaes sobre
as expectativas organizacionais para a execuo dos processos e a indicao de
como devem ser atendidos os aspectos mais importantes de cada processo. Isso
pode incluir princpios bsicos e definies gerais de como executar os processos,
incluindo aspectos de responsabilidades, tempos e instrumentos. A poltica no deve
ser uma reproduo de textos do MR-MPS-SW, mas sim, como a organizao
enxerga seus processos. Um documento genrico pode existir definindo quem tem
autoridade, delegada pela gerncia de alto nvel, para aprovar cada tipo de
documento.
Normalmente, as polticas so definidas e aprovadas pela gerncia de alto nvel, no
havendo a obrigatoriedade de serem rotuladas exatamente de polticas. Uma vez
definidas, as polticas devem ser publicadas e divulgadas aos interessados em sua
execuo. Tal publicao pode ser realizada, por exemplo, na Intranet da
organizao. Em geral, a divulgao da poltica pela alta gerncia ajuda a enfatizar a
importncia dos processos, facilitando sua institucionalizao.
7.2.2 RAP3 - A execuo do processo planejada
Este resultado visa realizao de um plano para a execuo do processo. Este
planejamento deve incluir recursos, responsabilidades e tempo, bem como as
atividades de controle e monitoramento da execuo do processo. Deve ser
estabelecido e documentado um plano para a execuo do processo, o que inclui
sua prpria descrio, porm no se restringindo a ela.. importante que o
planejamento seja revisto, sempre que necessrio, especialmente quando forem
aprovadas mudanas significativas.
7.2.3 RAP4 - (Para o nvel G) A execuo do processo monitorada e ajustes
so realizados
Este resultado s se aplica ao nvel G e visa monitorar a execuo dos processos
conforme o que foi planejado e assegurar que aes corretivas sejam tomadas
sempre que houver desvios significativos em relao ao planejado.
Desta forma, revises das atividades, estado e resultados dos processos devem ser
realizadas e podem ocorrer tanto periodicamente ou motivadas por algum evento.
Durante o monitoramento dos processos, questes podero ser identificadas, para
as quais aes corretivas devero ser tomadas e acompanhadas at o seu
encerramento.
O monitoramento do processo pode ser includo nas prprias atividades de
monitoramento do projeto, quando aplicvel.


7.2.4 RAP5 - As informaes e os recursos necessrios para a execuo do
processo so identificados e disponibilizados
Um aspecto crtico da implementao de um processo garantir que as condies
necessrias para ter sucesso na implementao do processo definido esto
presentes. Este resultado visa assegurar que as informaes e os recursos
necessrios para executar o processo sero identificados previamente e que estaro
disponveis quando forem necessrios. Incluem recursos financeiros, condies
fsicas adequadas, pessoal e ferramentas apropriadas (incluindo processos e
modelos de documentos predefinidos).
Estas informaes e recursos podem estar estabelecidos na prpria descrio do
processo ou podem, tambm, estar presentes em planos especficos para os
processos nos nveis da organizao e/ou projeto.
7.2.5 RAP6 - (At o nvel F) As responsabilidades e a autoridade para executar
o processo so definidas, atribudas e comunicadas
Este resultado visa assegurar que as responsabilidades e a autoridade para
executar o processo esto claramente definidas e bem compreendidas.
Deve-se assegurar, tambm, que as responsabilidades e a autoridade para executar
o processo foram atribudas explicitamente e comunicadas a todas as partes
interessadas, por exemplo, patrocinador, implementadores etc.
7.2.6 RAP7 - As pessoas que executam o processo so competentes em
termos de formao, treinamento e experincia
Este resultado visa assegurar que as pessoas alocadas tenham as habilidades,
conhecimentos e experincias necessrios para executar ou apoiar o processo.
Deve-se assegurar que as pessoas tenham o conhecimento em relao ao seu
papel no processo: conhecimento completo para aqueles que vo realizar as
atividades do processo e conhecimento genrico para os que vo interagir com o
processo. Conhecimento e habilidades no se restringem aos documentos de
processo, mas podem incluir trabalho em grupo, liderana, anlise e soluo de
problemas.
Quando se julgar necessrio, um treinamento apropriado deve ser fornecido para as
pessoas que executaro os processos. Os treinamentos podem ser de diferentes
tipos, por exemplo: treinamento autodirecionado; instruo programada autodefinida;
treinamento formal dentro do trabalho; mentoring; treinamento formal em salas de
aula. Mantendo-se o registro das competncias atuais e necessrias das pessoas
para a realizao dos diversos papis na execuo dos processos, pode-se planejar
os treinamentos necessrios.
7.2.7 RAP8 - A comunicao entre as partes interessadas no processo
planejada e executada de forma a garantir o seu envolvimento
O objetivo deste resultado identificar as partes interessadas no processo, planejar,
executar e manter o seu envolvimento. Os interessados podem ser envolvidos


tipicamente em atividades tais como: planejamento; coordenao; reviso; e
definio dos requisitos para a execuo do processo.
importante gerenciar a interface entre as partes interessadas de forma a assegurar
a comunicao.
7.2.8 RAP9 - (At o nvel F) Os resultados do processo so revistos com a
gerncia de alto nvel para fornecer visibilidade sobre a sua situao na
organizao
O objetivo deste resultado fornecer visibilidade alta gerencia com relao ao
estado da execuo dos processos, considerando sua adequao, operao com
recursos apropriados e alcance dos resultados esperados. Um dos mtodos de
monitorao de processo a reviso, junto gerncia de alto nvel, de seu estado,
atividades realizadas e resultados alcanados. As revises devem ocorrer
periodicamente ou, ento, motivadas por algum evento e no necessitam ser
presenciais. Desta forma, o andamento da implantao dos processos, tendncias e
problemas so relatados e tratados em nveis apropriados. Caso pertinente, aes
corretivas so estabelecidas e gerenciadas at a sua concluso, com
escalonamento aos nveis adequados de gerncia, sempre que necessrio.
Este resultado no deve ser confundido com a monitorao do processo conforme
definida no RAP4, mas pode utilizar tambm os dados obtidos a partir de sua
execuo.
7.2.9 RAP10 - (Para o nvel G) O processo planejado para o projeto
executado
O objetivo deste resultado garantir que o projeto conduzido a partir da execuo
do seu processo planejado. Deve-se garantir que existem registros de execuo das
atividades do processo com base no seu planejamento. Esses registros devem ser
mantidos e revistos periodicamente para garantir que o processo planejado est
sendo seguido para atingir os objetivos do projeto.


Referncias bibliogrficas
[DORFMANN e THAYER, 1990] DORFMANN, M. e THAYER, R. Standards,
Guidelines, and Examples of System and Software Requirements Engineering.
Los Alamitos, CA: IEEE Computer Society Press, 1990.
[HOFMANN et al., 2007] HOFMANN, H. F., YEDLIN, D. K., MISHLER, J. W.,
KUSHNER, S., 2007, CMMI for Outsourcing, Addison Wesley, 2007.
[IEEE, 1990] Std 610.12 - IEEE Standard Glossary of Software Engineering
Terminology, Institute of Electrical and Electronics Engineers, 1990.
[IEEE, 1998] Std 830-1998 - IEEE recommended practice for software
requirements specifications, Institute of Electrical and Electronics Engineers, 1998.
[ISO/IEC, 1998] the International Organization for Standardization and the
International Electrotechnical Comission. ISO/IEC TR 15271: Information
Technology Guide for ISO/IEC 12207 (Software life cycle processes), Geneve:
ISO, 1998.
[ISO/IEC, 2003] INTERNATIONAL ORGANIZATION FOR STANDARDIZATION/
INTERNATIONAL ELECTROTECHNICAL COMISSION. ISO/IEC 15504-2:
Information Technology - Process Assessment Part 2 - Performing an
Assessment, Genebra: ISO, 2003.
[ISO/IEC, 2008] INTERNATIONAL ORGANIZATION FOR STANDARDIZATION/
INTERNATIONAL ELECTROTECHNICAL COMISSION. ISO/IEC 12207:2008
Systems and software engineering Software life cycle processes, Geneve:
ISO, 2008.
[KRUCHTEN, 2003] KRUCHTEN, P., The Rational Unified Process: An
Introduction, 3a Edio, Addison-Wesley Object Technology Series, 2003.
[PMI, 2008] PROJECT MANAGEMENT INSTITUTE. A Guide To The Project
Management Body of Knowledge. 4. ed. Newton Square: PMI Publications, 2008-
PROJECT MANAGEMENT INSTITUTE PMI. A Guide to the Project
Management Body of Knowledge - PMBOK, Syba: PMI Publishing Division,
2004. Disponvel em: <www.pmi.org>.
[SEI, 20102010] SOFTWARE ENGINEERING INSTITUTE. CMMI for Development
(CMMI-DEV), Version 1.3, Technical Report CMU/SEI-2010-TR-033. Pittsburgh, PA:
Software Engineering Institute, Carnegie Mellon University, 2010.
[SOFTEX, 2011a]. ASSOCIAO PARA PROMOO DA EXCELNCIA DO
SOFTWARE BRASILEIRO SOFTEX. MPS.BR Guia de Implementao Parte
8: Implementao do MR-MPS:2011 em organizaes que adquirem software,
julho 2011. Disponvel em: www.softex.br.
[SOFTEX, 2011b]. ASSOCIAO PARA PROMOO DA EXCELNCIA DO
9: Implementao do MR-MPS:2011 em organizaes do tipo Fbrica de
Software, julho 2011. Disponvel em: www.softex.br.


[SOFTEX, 2011c]. ASSOCIAO PARA PROMOO DA EXCELNCIA DO
10: Implementao do MR-MPS:2011 em organizaes do tipo Fbrica de
Teste, julho 2011. Disponvel em: www.softex.br.
SOFTWARE BRASILEIRO SOFTEX. MPS.BR Guia Geral MPS de
Software:2012, agosto 2012. Disponvel em: www.softex.br.
SOFTWARE BRASILEIRO SOFTEX. MPS.BR Guia Geral MPS de
Servios:2012, agosto 2012. Disponvel em: www.softex.br.
11: Implementao e Avaliao do MR-MPS-SW:2012 em Conjunto com o
CMMI-DEV v1.3, agosto 2012. Disponvel em: www.softex.br.
[SOFTEX, 2012d]. ASSOCIAO PARA PROMOO DA EXCELNCIA DO
SOFTWARE BRASILEIRO SOFTEX. MPS.BR Guia de ImpIementao Parte
12: AnIise da Aderncia do MR-MPS-SW:2012 em reIao NBR ISO/IEC
29110-4-1:2012 - Engenharia de Software - Perfis de cicIo de vida para micro-
organizaes (VSEs) - Parte 4-1: Especificaes de perfiI: Grupo Perfil
Genrico, setembro 2013. Disponvel em: www.softex.br.
[SOFTEX, 2012e]. ASSOCIAO PARA PROMOO DA EXCELNCIA DO
13: Mapeamento e sistema de equivalncias entre o MR-MPS-SW:2012 e o
MoProSoft:2005, outubro 2012. Disponvel em: www.softex.br.
SOFTWARE BRASILEIRO SOFTEX. MPS.BR Guia de Aquisio:2013,
setembro 2013. Disponvel em: www.softex.br.
1: Fundamentao para Implementao do Nvel G do MR-MPS-SW:2012,
2: Fundamentao para Implementao do Nvel F do MR-MPS-SW:2012,
[SOFTEX, 2013d]. ASSOCIAO PARA PROMOO DA EXCELNCIA DO
3: Fundamentao para Implementao do Nvel E do MR-MPS-SW:2012,
[SOFTEX, 2013e]. ASSOCIAO PARA PROMOO DA EXCELNCIA DO
4: Fundamentao para Implementao do Nvel D do MR-MPS-SW:2012,


[SOFTEX, 2013f]. ASSOCIAO PARA PROMOO DA EXCELNCIA DO
5: Fundamentao para Implementao do Nvel C do MR-MPS-SW:2012,
[SOFTEX, 2013g]. ASSOCIAO PARA PROMOO DA EXCELNCIA DO
6: Fundamentao para Implementao do Nvel B do MR-MPS-SW:2012,
[SOFTEX, 2013h]. ASSOCIAO PARA PROMOO DA EXCELNCIA DO
7: Fundamentao para Implementao do Nvel A do MR-MPS-SW:2012,
[SOFTEX, 2013i]. ASSOCIAO PARA PROMOO DA EXCELNCIA DO
SOFTWARE BRASILEIRO SOFTEX. MPS.BR Guia de Avaliao:2013, agosto
2013. Disponvel em: www.softex.br.
3

[VAZQUEZ et al., 2005] VAZQUEZ, C. E.; SIMES, G. S; ALBERT, R. M. Anlise
de Pontos de Funo Medio, Estimativas e Gerenciamento de Projetos de
Software. Editora rica, So Paulo, 3.ed. 2005.

3
Para referncias dos Guias MPS.BR no datadas, deve ser utilizada a sua verso mais recente
disponvel em www.softex.br


Lista de colaboradores do Guia de Implementao Parte 1:2011

Editores:
Gleison dos Santos Souza COPPE/UFRJ
Ana Regina C. Rocha COPPE/UFRJ (Coordenadora da ETM)

Revisores:
Ana Liddy Cenni C. Magalhes QualityFocus e UFMG
Danilo Scalet CELEPAR
Reinaldo Cabral Silva Filho COPPE/UFRJ e UFAL


Lista de colaboradores do Guia de Implementao Parte 1:2009

Editores:
Gleison dos Santos Souza COPPE/UFRJ
Mariano Angel Montoni COPPE/UFRJ

Revisores:
Ana Ceclia Peixoto Zabeu ASR
Ana Liddy C. C. Magalhes QualityFocus e Universidade FUMEC
Carla Alessandra Lima Reis QR e UFPA
Edmeia Leonor Pereira de Andrade EMBRAPA e UCB


Julho/2007

Editoras:
Ana Liddy C. C. Magalhes SwQuality

Colaboradores

Revisores:
Edmeia Leonor Pereira de Andrade MAPA


Dezembro/2006

Editoras:
Ana Cristina Rouiller UFRPE / SWQuality
Kthia Maral de Oliveira Universidade Catlica de Braslia

Colaboradores:
Alfredo Nozomu Tsukumo CenPRA
Clnio Figueiredo Salviano CenPRA
Geovane Nogueira Lima SWQuality
Heron Vieira Aguiar SWQuality
Marblia Passagnolo Srgio CenPRA
Renata Telles Moreira SWQuality
Sandro Ronaldo Bezerra Oliveira SWQuality
Wagner Roberto De Martino CenPRA

Revisores:
Kthia Maral de Oliveira Universidade Catlica de Braslia

Guia de Implementação Nível G

Hochgeladen von

Dokumentinformationen

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Guia de Implementação Nível G

Hochgeladen von

Copyright:

Verfügbare Formate

MPS.

BR - Melhoria de Processo do Software Brasileiro

Das könnte Ihnen auch gefallen