Guia de Implementacao SV Parte 1 2013

MPS.
BR - Melhoria de Processo do Software Brasileiro
Guia de Implementao Parte 1: Fundamentao para

Implementao do Nvel G do MR-MPS-SV:2012
Este guia contm orientaes para a

implementao do nvel G do Modelo de
Referncia MR-MPS-SV: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)
Sumrio
1 Prefcio ............................................................................................................... 3
2 Introduo ........................................................................................................... 5
3 Objetivo ............................................................................................................... 6
4 Comeando a implementao do MR-MPS-SV pelo nvel G ............................... 7
5 Gerncia de Trabalhos (GTR) ............................................................................. 7
5.1 Propsito ......................................................................................................... 7
5.2 Fundamentao terica ................................................................................. 10
5.3 Resultados esperados ................................................................................... 11
6 Gerncia de Requisitos (GRE) .......................................................................... 26
6.1 Propsito ....................................................................................................... 26
7 Gerncia de Incidentes (GIN) ............................................................................ 32
7.1 Propsito ....................................................................................................... 32
8 Gerncia de Nvel de Servio (GNS) ................................................................. 38
8.1 Propsito ....................................................................................................... 38
9 Entrega de Servios (ETS)................................................................................ 43
9.1 Propsito ....................................................................................................... 43
10 Os atributos de processo no nvel G .............................................................. 45
10.1 AP 1.1 - O processo executado .................................................................. 45
10.2 AP 2.1 - O processo gerenciado ................................................................. 46
Referncias bibliogrficas ........................................................................................ 49
Lista de colaboradores do Guia de Implementao Parte 1:2013 ......................... 52
MR-MPS-SV Guia de Implementao Parte 1:2013 2/52

1 Prefcio
O MPS.BR1 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 MPS.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 do modelo 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 justo, 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 o modelo MPS; (iv) organizaes com avaliao MPS publicada
(prazo de validade de trs anos).
O programa MPS.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)
criao e aprimoramento contnuo do MR-MPS-SW, MR-MPS-SV, MA-MPS e seus
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.
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, 2012b];
Guia Geral MPS de Servios:2012 [SOFTEX, 2012a];
Guia de Avaliao:2013 [SOFTEX, 2013i][SOFTEX, 2013i];
Guia de Aquisio de Software:2013 [SOFTEX, 2013a] [SOFTEX, 2013a];
Guia de Implementao Parte 1: Fundamentao para Implementao do
Nvel G do MR-MPS-SW:2012 [SOFTEX, 2013b][SOFTEX, 2013b];
Nvel F do MR-MPS-SW:2012 [SOFTEX, 2013c][SOFTEX, 2013c];
Nvel E do MR-MPS-SW:2012 [SOFTEX, 2013d][SOFTEX, 2013d];
Nvel D do MR-MPS-SW:2012 [SOFTEX, 2013e][SOFTEX, 2013e];
Nvel C do MR-MPS-SW:2012 [SOFTEX, 2013f][SOFTEX, 2013f];
Nvel B do MR-MPS-SW:2012 [SOFTEX, 2013g][SOFTEX, 2013g];
Nvel A do MR-MPS-SW:2012 [SOFTEX, 2013h][SOFTEX, 2013h];
Guia de Implementao Parte 8: Implementao do MR-MPS:2011 (Nveis G a
A) em organizaes que adquirem software [SOFTEX, 2011a][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][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][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][SOFTEX, 2012c];
Parte 12 -MPS-SW:2012
em rel /IEC 29110-4-1:2012 - Engenharia de Software - Perfis de
ciclo de vida para micro- - -
[SOFTEX, 2012d][SOFTEX, 2012d];

Guia de Implementao Parte 13: Mapeamento e sistema de equivalncias
entre o MR-MPS-SW:2012 e o MoProSoft:2005 [SOFTEX, 2012e][SOFTEX,
2012e].
Nvel G do MR-MPS-SV:2013 [SOFTEX, 2013j];
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.
Nos ltimos anos vem crescendo a quantidade de novas tecnologias disponveis,
bem como a dependncia das organizaes em relao aos servios de suporte. Em
seu dia a dia, estas organizaes acabam trabalhando de forma reativa, tendo
pouco tempo para planejar, treinar pessoal, analisar criticamente e atuar mais
proximamente ao cliente. O resultado que estas organizaes acabam no
adotando prticas mais proativas e estruturadas de trabalho [ISO/IEC, 2012]. O
desenvolvimento e a melhoria das prticas de servios so chaves para um melhor
desempenho, aumento da satisfao do cliente e a lucratividade do setor [CMMI
Product Team, 2010].
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 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, os modelos MPS possuem quatro componentes:
Modelo de Referncia de Software (MR-MPS-SW), Modelo de Referncia de
Servios (MR-MSP-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 de Software: contm a descrio geral dos modelos MPS e
detalha o Modelo de Referncia de Software (MR-MPS-SW), seus
componentes e as definies comuns necessrias para seu entendimento e
aplicao [SOFTEX, 2012b].
Guia Geral de Servios: contm a descrio geral dos modelos MPS e
detalha o Modelo de Referncia de Servios (MR-MPS-SV), seus
componentes e as definies comuns necessrias para seu entendimento e
aplicao [SOFTEX, 2012a].
Guia de Aquisio: descreve um processo de aquisio de software.
descrito de forma a apoiar as instituies que queiram adquirir produtos de
software 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].
Guias de Implementao de Software: srie de treze documentos que
fornecem orientaes para implementar nas organizaes os nveis de
maturidade descritos no Modelo de Referncia MR-MPS-SW [SOFTEX,
2011a], [SOFTEX, 2011b], [SOFTEX, 2011c], [SOFTEX, 2012c], [SOFTEX,
2012d], [SOFTEX, 2012e], [SOFTEX, 2013b], [SOFTEX, 2013c], [SOFTEX,
2013d], [SOFTEX, 2013e], [SOFTEX, 2013f], [SOFTEX, 2013g], [SOFTEX,
2013h].
Guias de Implementao de Servios: srie de sete documentos que
fornecem orientaes para implementar nas organizaes os nveis de
maturidade descritos no Modelo de Referncia MR-MPS-SV.
3 Objetivo
O Guia de Implementao de Servios fornece orientaes para implementar nas

organizaes os nveis de maturidade descritos no Modelo de Referncia de
Servios (MR-MPS-SV), 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 de
Servios e aborda a implementao do nvel de maturidade G.
Este documento destinado, mas no est limitado, a organizaes interessadas
em utilizar o MR-MPS-SV para melhoria de seus processos de servios e a
Instituies Implementadoras (II). O contedo deste documento informativo, ou
seja, no se espera que uma organizao implementando o MR-MPS-SV 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
Servios, s requerido o atendimento aos resultados esperados definidos no Guia
Geral de Servios [SOFTEX, 2012a]. 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-SV pelo nvel G
O nvel G o primeiro nvel de maturidade do MR-MPS-SV. Sua implementao

deve ser executada com cautela por estabelecer o incio da implantao de melhoria
dos processos de gerenciamento de servios na organizao. Ao final da
implantao deste nvel, a organizao deve ser capaz de gerenciar parcialmente a
execuo dos seus servios.
Dois pontos so desafiadores na implantao do nvel G: (1) mudana de cultura
organizacional, orientando a definio e melhoria dos processos de gerenciamento
de servios; 2 q servio .
De acordo com [CATER-STEEL, TOLEMANN, TAN, 2006], os principais benefcios
alcanados pela melhoria no sistema de gerenciamento de servios so:
infraestrutura mais previsvel por meio de um maior rigor nos testes e nas mudanas
de sistema; melhoria da atuao dos grupos dentro da organizao; negociao
mais tranquila de Acordos de Nvel de Servio (ANS); servio gerenciado do comeo
ao fim; processos de gerenciamento de servios documentados e consistentes ao
longo de toda a organizao; e, registro consistente de incidentes.
No nvel G, o gerenciamento de servios pode usar os seus prprios padres e
procedimentos, no sendo necessrio que se tenha padres organizacionais
comuns a todos os servios. Se, porventura, a organizao possuir processos j
definidos e os servios necessitarem adaptar os processos existentes, deve-se
registrar essa adaptao durante o planejamento do servio. Adaptaes podem
incluir alteraes em processos, atividades, ferramentas, tcnicas, procedimentos,
padres, medidas, entre outras.
O nvel de maturidade G composto pelos processos Entrega de Servios (ETS),
Gerncia de Incidentes (GIN), Gerncia de Nvel de Servio (GNS), Gerncia de
Requisitos (GRE) e Gerncia de Trabalhos (GTR). Neste nvel a implementao dos
processos deve satisfazer os atributos de processo AP 1.1 e AP 2.1.
5 Gerncia de Trabalhos (GTR)
5.1 Propsito
O propsito do processo Gerncia de Trabalhos estabelecer e manter planos

que definem as atividades, recursos e responsabilidades do trabalho, bem
como prover informaes sobre o andamento do trabalho que permitam a
realizao de correes quando houver desvios significativos no desempenho
do trabalho. 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 trabalhos passe a ser
realizada com base no processo definido para o trabalho e nos planos
integrados. No nvel B, a gerncia de trabalhos passa a ter um enfoque
quantitativo, refletindo a alta maturidade que se espera da organizao.
Novamente, alguns resultados evoluem e outros so incorporados.
Um trabalho, no contexto do modelo MR-MPS-SV, compreendido de duas formas,
uma, relacionada ao conceito de projeto, e outra, relacionada ao conceito de
operao.
No primeiro caso, se uma organizao est iniciando a implantao de um novo
servio, o termo trabalho equivale ao projeto realizado para o desenvolvimento e
implantao e continuidade do servio. Entende-se por projeto o conceito clssico
proveniente do PMBOK (A Guide to The Project Management Body of Knowledge)
q projeto um esforo temporrio empreendido para criar um produto, servio
ou resultado exclusivo. A natureza temporria do projeto indica que ele possui um
comeo e um fim definidos. [PMI, 2012]. Este tambm o conceito empregado pelo
MR-MPS-SW: Projeto um empreendimento realizado para criar um produto. O
projeto se caracteriza por temporalidade e resultado, produto nico e elaborao
progressiva [SOFTEX, 2012b].
De acordo com o PMBOK [PMI, 2012], um projeto pode criar:
i) um produto que pode ser um componente de outro item, uma melhoria em
um item, ou um item final em si;
ii) um servio ou a capacidade para executar um servio (por exemplo, uma
funo de negcio que apoia a produo ou a distribuio);
iii) uma melhoria em um produto ou servio existente (por exemplo, um projeto
de six sigma para reduzir defeitos); e,
iv) um resultado, como uma sada ou um documento (por exemplo: um projeto
de pesquisa que desenvolve um conhecimento que pode ser usado para
determinar uma tendncia ou um novo processo que beneficiar a
sociedade).
Neste contexto, planejar um trabalho adquire o mesmo conceito de planejar um
projeto. O plano do trabalho deve conter todas as informaes necessrias acerca
do planejamento para a realizao e controle do trabalho, que, neste caso, adquire a
forma do item (ii) acima, ou seja, um projeto para implantar um servio ou
capacidade de executar um servio. Quando este trabalho se encerra, ou seja,
quando o servio implantado, ele passa a ser caracterizado como uma operao,
ou seja, passa a ser executado de forma contnua. A partir deste momento, o
trabalho adquire a segunda forma, descrita a seguir.
A segunda forma de compreender o conceito de trabalho quando uma organizao
j possui servios implantados e em funcionamento, ento o termo trabalho usado
com o conceito de controle da operao. Entende-se por operao uma atividade
repetitiva, que ocorre no dia a dia da organizao e, contrariamente ao conceito de
projeto, no possui natureza temporria. Neste contexto, o plano de trabalho se
refere ao plano de produo do servio ou da rea que atende ao servio e ser
denominado aqui de Plano de Trabalho Organizacional. Este plano de trabalho
poder ser instanciado para uma execuo especfica, se esta apresentar
caractersticas diferentes das demais execues ou necessitar de um planejamento
detalhado individual, denominando-se, neste contexto, Plano de Trabalho
Especfico.
Para facilitar a explicao dos resultados esperados do processo, visando
compreenso de sua abrangncia, sero utilizadas as seguintes expresses:
Plano de Trabalho Organizacional: refere-se ao plano de produo, ou seja,
ao plano para gerenciamento da rea que presta o servio e, portanto, trata
do conjunto de servios que est sendo prestado. Conceito tipicamente
relacionado ao planejamento da operao.
Plano de Trabalho Especfico: refere-se ao plano de um projeto de
implantao de um novo tipo de servio ou ao plano para a realizao de um
servio especfico, cujo porte ou natureza assim o exijam. Conceito
tipicamente relacionado ao planejamento clssico de projeto.
Independentemente da abordagem, o processo Gerncia de Trabalhos (GTR)
envolve vrias atividades, como: desenvolver um plano geral de controle do
trabalho; obter o comprometimento e mant-lo ao longo de toda a execuo do
trabalho; e conhecer o progresso do trabalho, de maneira que aes corretivas
possam ser tomadas quando a execuo do trabalho se desviar do planejado.
O desenvolvimento do plano do trabalho inclui: identificar e estimar o escopo, os
produtos intermedirios e as tarefas do trabalho; estabelecer recursos necessrios;
identificar e analisar riscos do trabalho; estabelecer compromissos; e definir
cronograma de execuo baseado no ciclo de vida definido para o trabalho. O plano
do trabalho estabelece a base de execuo e controle para as atividades do trabalho
junto aos seus interessados (especialmente o cliente). Todos os interessados devem
estar comprometidos com ele.
O progresso da execuo do trabalho determinado pela comparao dos atributos
reais de produtos intermedirios e tarefas, esforo, custo e cronograma com o que
foi planejado nos marcos ou em pontos de controle predefinidos no planejamento do
trabalho. Um marco um ponto de reviso, por exemplo, o incio ou o final de cada
fase do trabalho ou algumas atividades de fundamental importncia para o seu
sucesso. A reviso de incio de fase de trabalho, quando se aplicar, 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 trabalho 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 trabalho. 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 trabalho, porm, no esto no caminho
crtico do trabalho, ou seja, o trabalho 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 trabalho 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 Trabalhos (GTR) evoluem e outros so
adicionados ao processo nos nveis de maturidade E e B do MR-MPS-SV. Esta parte
do Guia de Implementao apresenta orientaes apenas para implementar os
resultados do processo Gerncia de Trabalhos (GTR) no nvel de maturidade G do
MR-MPS-SV. As orientaes de implementao dos demais resultados esperados
deste processo so apresentadas nas partes 3 e 6 do Guia de Implementao.
5.2 Fundamentao terica
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 (A Guide to The Project Management Body of Knowledge)
[PMI, 2012]. 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, 2012] 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.
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, 2012].
Gerenciar um projeto, de acordo com o PMBOK [PMI, 2012], significa balancear
aspectos como: escopo, qualidade, cronograma, oramento, recursos, riscos, entre
outros. A relao entre estes fatores tal que, se um for modificado, o outro tambm
ser. Se o escopo aumentar, o oramento ser aumentado e o cronograma ser
dilatado. Para manter o mesmo cronograma, provavelmente a qualidade ser
afetada. Cabe ao gerente de projeto identificar estes relacionamentos e selecionar a
melhor alternativa, quando estes so conflitantes.

No conceito do MR-MPS-SV, projetos so utilizados como sinnimo para trabalho,
quando este for utilizado para a implantao de um novo servio ou para o
gerenciamento de um servio cujas caractersticas sejam to especficas que
necessitem de procedimentos de gerenciamento de projetos.
Para o , empreendimentos contnuos que produzem sadas
repetitivas, com recursos atribudos para fazer basicamente o mesmo conjunto de
tarefas de acordo com padres institucionalizados em um ciclo de vida de produto.
[PMI, 2012]. Gerenciar uma operao significa garantir que as operaes de negcio
continuam, de forma contnua, utilizando recursos otimizados e atendendo s
demandas dos clientes. , os objetivos dos projetos e das operaes
so fundamentalmente diferentes. A finalidade de um projeto atingir seu objetivo e,
em seguida, terminar. Por outro lado, o objetivo de uma operao contnua manter
o negcio. Os projetos so diferentes porque o projeto termina quando seus
objetivos especficos forem atingidos, enquanto as operaes adotam um novo
j bj v b h . [PMI, 2012]. No contexto do MR-MPS-
SV, para os casos de gerenciamento de prestao de servios padro existentes,
operaes so usadas como sinnimo de trabalho.
5.3 Resultados esperados
5.3.1 GTR1 - O escopo do trabalho definido
O escopo do trabalho define todo o trabalho necessrio, e somente ele, para

entregar um servio que satisfaa as necessidades, caractersticas e funes
especificadas para o trabalho, de forma a conclu-lo com sucesso.
O escopo o ponto de partida para o planejamento do trabalho. A definio do
escopo deve estabelecer o que est e o que no est includo no trabalho. Para
isso, o escopo em geral contm a definio do objetivo e da motivao, os limites e
restries, todos os servios que sero entregues e os outros produtos gerados pelo
trabalho, entre outras informaes.
O escopo pode ser representado por meio de uma WBS (Work Breakdown
Structure), conhecida em portugus como EDT (Estrutura de Decomposio do
Trabalho) ou EAP (Estrutura Analtica de Projeto). A WBS fornece um esquema para
identificao e organizao das unidades lgicas de trabalho a serem gerenciadas,
q h b h work packages). Uma WBS uma
estrutura hierrquica que decompe o trabalho em partes menores, de modo que
possam ser mais facilmente visualizadas e gerenciadas.
Este resultado tambm pode ser implementado por meio de um Documento de
Viso ou outro documento que defina, claramente, o escopo do trabalho.
5.3.2 GTR2 - As tarefas e os produtos derivados de trabalho so
dimensionados utilizando mtodos apropriados
O escopo do trabalho, identificado na forma dos seus principais produtos e tarefas,

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 WBS ou estrutura equivalente. A estrutura de
decomposio fornece uma referncia para a atribuio de tamanho, esforo,
cronograma (ou equivalente) e responsabilidades e utilizada como uma estrutura
subjacente para planejar, organizar e controlar o trabalho. 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 GTR4 refere-se
estimativa de esforo e custo.
No nvel G, a estimativa de escopo, produtos e tarefas pode ser feita baseada na
complexidade, no nmero de requisitos ou no uso da WBS juntamente com dados
histricos e a experincia em trabalhos anteriores. Uma organizao pode tambm
aplicar tcnicas de estimativas prprias que se mostraram eficientes e adequadas s
necessidades e caractersticas da empresa.
5.3.3 GTR3 - O modelo e as fases do ciclo de vida do trabalho 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. Isto se aplica totalmente a um
trabalho que se assemelhe a um projeto, como o caso de desenvolvimento de novos
servios ou como o caso de um servio de maior porte, que demande um plano
similar a um projeto. No entanto, para o conceito de operao, o ciclo de vida pode
se resumir a poucas ou uma nica etapa.
O ciclo de vida de trabalho define um conjunto de fases, que por sua vez geram
produtos de trabalho (artefatos) necessrios para o desenvolvimento de fases
posteriores. Essa organizao em fases permite planejar o trabalho, incluindo
marcos importantes para o controle e as 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 trabalho. Assim, importante conhecer alguns modelos de ciclo
de vida e em que situaes so aplicveis. Quando se trata do desenvolvimento de
software, por exemplo, os principais modelos de ciclo de vida podem ser agrupados
em trs categorias: modelos sequenciais ou cascata, modelos incrementais e
modelos evolutivos. Para o desenvolvimento de servios, conceitos similares podem
ser adotados. Um ciclo cascata ser caracterizado pela realizao de fases
sequenciais, usando um desenvolvimento linear. Um ciclo incremental ser
caracterizado pelo desenvolvimento em iteraes, com incremento de
funcionalidades do servio a cada nova iterao.
O ciclo de vida dos trabalhos pode estar predefinido no mbito organizacional, ou
seja, a organizao pode preestabelecer que todos os trabalhos 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 trabalho, ser selecionado aquele que melhor
atender s suas caractersticas.

A determinao das fases do ciclo de vida 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.
Para o caso de desenvolvimento de novos servios, pode-se usar ciclos de vida
similares aos existentes para outros tipos de projetos conhecidos pela organizao.
Em projetos de software, por exemplo, so utilizados, tipicamente, os modelos de
ciclo de vida cascata, iterativo e incremental etc.
5.3.4 GTR4 - (At o nvel F) O esforo e o custo para a execuo das tarefas
do 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 servios 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, os produtos de
trabalho e as tarefas estimadas; os riscos; as mudanas j previstas; o ciclo de vida;
as viagens previstas; o nvel de competncia da equipe do trabalho, dentre outros.
Normalmente as estimativas das tarefas 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-SV geralmente no possuem bases
de dados histricas consistentes, que possam ser utilizadas como parmetro para
estimar. Entretanto, para alcanar nveis superiores de maturidade preciso que
essa base seja construda e os dados obtidos pelos trabalhos executados, mesmo
no nvel G, so fortes candidatos a aliment-la.
5.3.5 GTR5 - O oramento e o cronograma do trabalho, incluindo a definio
de marcos e pontos de controle, so estabelecidos e mantidos
Quando os servios so de fornecimento contnuo, o Plano de Trabalho

Organizacional prev um cronograma que representado pelo plano de operao
ou plano de produo, contendo as equipes alocadas, seus turnos (se aplicvel) e
os servios programados para execuo naquele perodo. Nestes casos, comum
que as mesmas atividades sejam realizadas periodicamente (Ex.: equipe que realiza
rotina diria de monitoramento de servidores). Tratamento similar pode ser dado
para o servio que realizado sob demanda, ou seja, o cliente envia uma solicitao
de servio, a partir da qual inicia a prestao do servio (Ex.: chamado para ligao
de um ponto de rede, chamado para esclarecimento sobre uma funcionalidade de
um software de gesto, chamado para reparao de um equipamento). O
cronograma nestes casos prev apenas a equipe que est alocada, por exemplo, ao
turno de trabalho, bem como os servios que esta equipe realiza.
O cronograma deve ainda prever dependncias entre atividades, se houver. 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 WBS e as
estimativas de esforo e custo (GTR4), considerando as dependncias entre as
tarefas e os marcos e pontos de controle eventos que so considerados
significativos no mbito do trabalho. importante ter-se o cuidado de manter a
coerncia entre ciclo de vida, WBS, estimativas e cronogramas.
O oramento do trabalho 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 trabalho. Desta forma,
sempre que necessrio, devem ser revistos e atualizados.
5.3.6 GTR6 - Os riscos do trabalho so identificados e o seu impacto,
probabilidade de ocorrncia e prioridade de tratamento so determinados e
documentados
Riscos so situaes de incerteza que podem adquirir conotao positiva

(oportunidade) ou negativa (ameaa). mais comum que as organizaes foquem o
gerenciamento dos riscos que representam uma ameaa ao sucesso. No entanto,
neste resultado esperado, ambas abordagens podem ser utilizadas.
A organizao pode optar por produzir uma lista de riscos mais comuns que ocorrem
em seus servios e, a partir destes, instanciar riscos especficos associados a um
servio, a um conjunto de servios, a um cliente ou a um conjunto de clientes.
A cada risco, uma probabilidade de ocorrncia e um impacto caso ele ocorra, esto
associados. Isto ajuda a priorizar os riscos e a direcionar os recursos para prevenir e
solucionar os que representem uma ameaa maior para a organizao (ou seja, com
maior severidade). comum que sejam atribudas categorias para a probabilidade
(como alta, mdia e baixa) e que estas estejam associadas maior ou menor
chance do risco ocorrer. De forma anloga, comum utilizar categorias para
dimensionar o impacto (alto, mdio, baixo). Com estas duas categorizaes,
bastante comum se estabelecer uma matriz relacionando as duas dimenses e
dando um sentido de severidade. Riscos do quadrante superior direito da matriz
(probabilidade alta x impacto alto) sero priorizados no tratamento, enquanto que
riscos no quadrante inferior esquerdo (probabilidade baixa e impacto baixo) podero
ser apenas documentados e acompanhados, no exigindo nenhuma ao
especfica.
No nvel G, ainda no necessrio definir aes de preveno (reduo da
probabilidade de ocorrncia) e aes de contingncia (reduo do impacto, ou seja,
dos efeitos do risco caso ele ocorra). Isto passa a ser exigido apenas a partir do
nvel C. No entanto, ao planejar os riscos, natural que se definam aes que sero
utilizadas em sua preveno, da mesma forma que comum definir aes que sero
adotadas no caso que o risco ocorra.
A monitorao dos riscos exigida pelo resultado esperado GTR15. Os problemas
advindos da ocorrncia do risco so tratados de acordo com as exigncias dos
resultados esperados GTR18 e GTR19.
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 medida que novos riscos forem sendo identificados.
importante demonstrar que esta planilha est sendo monitorada e atualizada.
Na implantao de um novo servio (Plano de Trabalho Especfico), os riscos mais
comuns so aqueles que ocorrem em projetos de qualquer natureza, como, por
exemplo: indisponibilidade de recursos (financeiros, instalaes, equipamentos,
pessoas), impreciso nas estimativas que geraram o plano (especialmente
cronograma e oramento), mudanas externas organizao (de ordem poltica,
econmica, de marco regulatrio ou legislao), mudanas internas (estrutura
organizacional, prioridades entre projetos), problemas tcnicos (falhas em
equipamentos, mudanas de tecnologia), e assim por diante.
Durante a prestao dos servios (Plano de Trabalho Organizacional) ameaas a
esta execuo podem estar relacionadas, mas no restritas a: falhas em itens de
configurao relacionados a hardware (servidores, cabeamento, arrays de disco,
impressoras, linhas telefnicas etc.); falhas em itens de configurao relacionados a
software (ferramentas de monitoramento de servidores, redes e banco de dados,
ferramentas de apoio ao registro e soluo de incidentes); indisponibilidade de
meios de locomoo de pessoal e equipamentos; indisponibilidade peridica ou
permanente de recursos humanos crticos especializados (doena, aposentadoria,
desligamento da empresa), entre outros.
Em nveis mais altos de maturidade, os riscos identificados no Plano de Trabalho
Organizacional esto tambm associados aos processos de Gerncia de
Capacidade e Gerncia de Continuidade e Disponibilidade de Servios.
Uma viso mais organizacional e abrangente do gerenciamento de riscos ser
necessria a partir do nvel C do MR-MPS-SV, quando o processo de Gerncia de
Riscos (GRI) for implantado.
5.3.7 GTR7 - Os recursos humanos para o trabalho so planejados
considerando o perfil e o conhecimento necessrios para execut-lo
O planejamento de recursos humanos determina funes, responsabilidades e

relaes hierrquicas. As funes 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, 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 possam ser executadas de
forma adequada e de acordo com a responsabilidade esperada; (ii) a alocao dos
recursos humanos s atividades de acordo com o planejamento realizado. Dessa
forma, este resultado implica que o planejamento da alocao de recursos humanos
seja realizado com base na anlise das competncias requeridas em relao s
competncias possudas.
Caso uma pessoa seja alocada 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 pode ser realizado na forma tradicional (estilo sala de aula) ou
alternativa (de outra maneira, como curso on-line ou mentoring) e inclui todas as
atividades realizadas para aprimorar as competncias dos membros da equipe..
Exemplos de mtodos para realizao de treinamentos incluem treinamento formais
em sala de aula (internos na prpria organizao ou externos); cursos on-line;
treinamento on the job, ou seja, no momento da realizao da tarefa; leituras
tcnicas; aconselhamento e orientaes.
Em reas de prestao de servios, comum que perfis diferenciados sejam
necessrios para os diversos nveis de atendimento de servios. Atendentes de 2
nvel so normalmente mais especializados que atendentes de 1 nvel e assim
sucessivamente. importante que todos os requisitos necessrios para cada um
destes nveis estejam claramente definidos e que sejam utilizados na seleo de
pessoal. Alm dos perfis, tambm importante prever a quantidade necessria, de
modo que os ANSs possam ser respeitados e cumpridos. Na medida em que novos
clientes de um servio so incorporados, uma reviso da quantidade de recursos
necessrios dever ser realizada, refletindo as novas necessidades da equipe de
operao.
Quando, por exemplo, uma equipe de tcnicos especializados no atendimento de
redes alocada, ela possui uma determinada capacidade de atendimento. Quando
aumentam as solicitaes de servio, ou a quantidade de clientes a serem
atendidos, a equipe possivelmente ter que ser aumentada, sob risco de que os
prazos definidos nos ANSs no possam mais ser cumpridos.
A partir do Nvel C do MR-MPS-SV, o processo de Gerncia de Capacidade (GCA)
utilizado como apoio para o planejamento e monitoramento da capacidade de
execuo dos servios.
5.3.8 GTR8 - (At o nvel F) Os recursos e o ambiente de trabalho necessrios
para executar o trabalho so planejados
Este resultado faz referncia obrigatoriedade de se planejar os recursos e o

ambiente necessrios para a realizao do trabalho. Isto inclui, mas no est
limitado a: equipamentos, ferramentas, outros servios, viagens e at mesmo
requisitos de processo (processos especiais para o trabalho). Os recursos humanos,
incluindo treinamentos, j so tratados pelo resultado anterior (GTR7).

bastante comum que as organizaes possuam um ambiente de trabalho padro,
cujos recursos j estejam adquiridos e disposio para uso. Este o caso,
normalmente de estaes de trabalho, incluindo computadores e softwares,
impressoras, linhas telefnicas etc. Na medida em que um novo trabalho inicia,
parte-se do princpio que todas as pessoas j possuem a infraestrutura necessria
para as suas atividades. No entanto, para este resultado do modelo MR-MPS-SV,
importante que os recursos fiquem explicitamente planejados, pois se esta questo
no for analisada, podem ocorrer riscos de indisponibilidade de recursos. Isto pode
ser feito por meio de um Plano Organizacional de Infraestrutura que referenciado
dentro do Plano de Trabalho. Mesmo nestes casos, importante explicitar que a
questo foi analisada e que nada complementar necessrio.
Caso recursos especiais sejam necessrios, importante lembrar que isto dever
ser previsto no oramento do trabalho (caso seja necessrio adquiri-los) e tambm
nas atividades do cronograma. importante que se analise, quando da elaborao
do cronograma, se existe dependncia de recursos para a realizao da atividade e
se este recurso estar disponvel no prazo necessrio.
No Plano de Trabalho Organizacional, todos os recursos envolvidos na prestao do
servio devero estar identificados, especificados e quantificados. O ideal que este
mapeamento seja realizado por tipo de servio ou at mesmo em alguns casos,
detalhado por cliente, caso o contrato com o cliente preveja recursos especficos.
Este planejamento dever ser revisado sempre que a assinatura de um novo
contrato para a prestao de servio implicar na ampliao dos recursos instalados,
visando sempre manuteno da capacidade de atendimento aos ANSs.
Quando a prestao de um servio para um cliente envolver a utilizao de um
servio de terceira parte, isto dever ser previsto no planejamento de recursos.
importante, neste caso, que esta necessidade se reflita em outros pontos do
planejamento como: oramento, cronograma e riscos. Nestes casos, no nvel de
maturidade F do MR-MPS-SV o processo de Aquisio (AQU) dever ser
implementado, permitindo um gerenciamento adequado da aquisio do servio
junto a um prestador de servios.
A partir do nvel de maturidade F do MR-MPS-SV muitos destes recursos sero
mapeados como itens de configurao no processo de Gerncia de Configurao
(GCO), especialmente aqueles relacionados ao hardware e ao software utilizado na
prestao do servio. No nvel de maturidade C, o planejamento dos recursos
necessrios refinado e detalhado no processo de Gerncia de Capacidade (GCA),
visando garantir que a capacidade instalada est apta a atender s solicitaes de
servios, respeitando os ANSs.
5.3.9 GTR9 - Os dados relevantes do trabalho 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 trabalho 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, 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.
bastante comum que as organizaes possuam um procedimento padronizado
para as questes relacionadas a dados. Por exemplo, comum que: nomes
padronizados sejam utilizados para servidores, equipamentos e arquivos; locais
padronizados sejam utilizados para o armazenamento de informaes; privilgios de
acesso sejam atribudos por perfis individuais, grupos ou cargos; informaes
sensveis sejam protegidas por criptografia, senhas etc. Se este for o caso, isto
poder ser documentado em um Plano Organizacional de Dados que ser apenas
referenciado no Plano de Trabalho (Organizacional ou Especfico). importante, no
entanto, que qualquer tratamento diferenciado do padro que seja necessrio, esteja
adequadamente documentado no Plano de Trabalho.
5.3.10 GTR10 - Um plano geral para a execuo do trabalho estabelecido com
a integrao de planos especficos
O objetivo deste resultado esperado garantir que todos os planos que afetam o
trabalho 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.
Muitas vezes o Plano de Trabalho no formalizado por meio de um nico
documento. O cronograma, por exemplo, pode ser definido em uma ferramenta
especfica para elaborao de cronograma. Os riscos podem ter sido documentados
em uma planilha. A infraestrutura padro da organizao pode estar em um Plano
Organizacional de Infraestrutura e assim por diante. O importante que o Plano de
Trabalho faa referncia a todas estas partes, que, juntas, constituem o
planejamento do trabalho.
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, 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 depender de uma organizao adequada destas
informaes de planejamento. Ao longo da execuo, elas devero ser comparadas

aos dados obtidos durante sua execuo, em busca de uma maior visibilidade do
andamento do trabalho. Quando necessrio, o planejamento dever ser revisto.
5.3.11 GTR11 - A viabilidade de atingir as metas do trabalho explicitamente
avaliada considerando restries e recursos disponveis. Se necessrio,
ajustes so realizados
A anlise da viabilidade no caso de servios compreendida de duas formas:

Se um novo tipo de servio esta sendo planejado (Plano de Trabalho Especfico),
ento se deve analisar a viabilidade de execuo do trabalho para a implantao do
novo servio, considerando os recursos necessrios e os recursos disponveis.
Neste caso, so analisados aspectos tcnicos (requisitos e recursos), financeiros
(capacidade da organizao) e humanos (disponibilidade de pessoas com a
capacitao necessria).
Se um conjunto de servios est sendo gerenciado por meio de um Plano de
Trabalho Organizacional, a viabilidade de aceitar um novo contrato ou uma nova
solicitao de um cliente deve ser examinada com base na capacidade da
organizao de atender ao novo ANS pretendido e de continuar podendo atender
aos ANSs j estabelecidos.
Em ambos os casos, deve-se considerar tambm os objetivos de negcio e a
composio do portflio de trabalhos da organizao. Muitas vezes prefervel no
aceitar um novo contrato de prestao de servio do que prosseguir com um nvel
de servio inadequado, ou que pode implicar em perdas maiores, tanto para o
provedor do servio como para o cliente.
No incio do trabalho, 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.
Posteriormente, medida que o projeto do novo servio (trabalho) 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 do novo servio (trabalho). De qualquer forma, a viabilidade 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 marcos do trabalho e mesmo durante as atividades de acompanhamento, pode
ser necessria a confirmao da viabilidade de continuidade do trabalho de
implantao do novo servio.
Para servios em andamento, quando o Plano de Trabalho Organizacional
definido, a viabilidade analisada em relao aos contratos de prestao de servio
existentes e capacidade para atend-los. Esta viabilidade deveria ser revisada
sempre que as condies de prestao do servio forem alteradas. Isto inclui:
entrada de um novo cliente; entrada de um novo tipo de servio; indisponibilidade
momentnea ou permanente de algum tipo de recurso; mudana nas exigncias do
ANS de algum cliente, entre outros. Estes so motivos pelos quais o servio pode
deixar de ser prestado com a qualidade requerida e estabelecida nos ANSs.

5.3.12 GTR12 - O Plano do Trabalho revisado com todos os interessados e o
compromisso com ele obtido e mantido
Para obter o compromisso 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 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 trabalho 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. 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 tempo, de acordo com a
dinmica do ambiente, 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.
No caso do Plano de Trabalho Especfico, algumas organizaes costumam realizar
uma reunio de incio de trabalho (kick off meeting) que pode ser utilizada para
resolver os conflitos e obter o comprometimento, tanto dos participantes internos,
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
trabalho por estarem ausentes ou terem sido alocadas a tarefas do trabalho
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 trabalhos. Nestes casos, uma alternativa seria condicionar o
comprometimento de parte da equipe do trabalho aceitao das tarefas alocadas.
De qualquer forma, importante, para minimizar os riscos, que o comprometimento
dos envolvidos seja obtido antes da participao na execuo de alguma tarefa.
Este resultado esperado est de certa forma associado ao GTR11, pois a realizao
da anlise de viabilidade pode resultar em aes para soluo de conflitos que
impactem no comprometimento dos envolvidos. 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 atividades 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 se possa efetivamente contar com os recursos planejados,
para atingir as metas definidas.
No caso do Plano de Trabalho Organizacional, a abordagem do comprometimento
um pouco diferente. Para prestadores de servio com vrias equipes e com grande

quantidade de pessoas alocadas impossvel obter o comprometimento de forma
individualizada de toda a equipe tcnica envolvida no trabalho. Suponha um Plano
de Trabalho Organizacional referente ao planejamento das atividades de uma
equipe de suporte tcnico de redes, cujos tcnicos atendem a chamados dos
clientes remotamente (1 nvel) e presencialmente (2 nvel). Neste caso, os
recursos esto alocados para a prestao do servio de suporte a redes, atendendo
s solicitaes de servios dos clientes. O comprometimento global da organizao
est documentado e assinado no ANS, que estabelece o servio contratado e seu
nvel de desempenho esperado. A equipe como um todo tem uma capacidade X de
atendimento e isto gerenciado por quem supervisiona a equipe. Neste caso, o
comprometimento individual se d quando um tcnico especfico recebe e aceita
uma solicitao de incidente ou uma solicitao de servio. Neste caso, este
comprometimento est regido pelo ANS assinado entre o provedor do servio e o
cliente, que determina que ele ter um tempo X para resolver o incidente ou a
solicitao de servio do cliente.
5.3.13 GTR13 - O escopo, as tarefas, as estimativas, o oramento e o
cronograma do trabalho so monitorados em relao ao planejado
A aderncia aos diversos planos deve ser avaliada continuamente durante todo o
ciclo de vida do trabalho. Se o trabalho referente a um novo servio, o
monitoramento ocorre at que o trabalho seja finalizado e o novo servio esteja
implantado. Nestes casos, 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 trabalho
em relao a aspectos relacionados s tarefas, estimativas, oramento e
cronograma (ver GTR2, GTR3, GTR4, GTR5). 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 trabalho; estimativas precisam ser
adequadas em decorrncia de alteraes no escopo do trabalho em termos de
tarefas e/ou trabalho previsto, adequaes de fatores de ajuste de produtividade
etc.; o oramento do trabalho pode sofrer alteraes em decorrncia dos valores
reais dos custos diretos e indiretos do trabalho; parte das atividades presentes no
cronograma do trabalho 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.
Quando o acompanhamento refere-se a uma rea que presta um servio, os itens
constantes do Plano de Trabalho Organizacional devem tambm ser monitorados.
Isto pode ser realizado na periodicidade que mais convier organizao. O
importante que esta periodicidade seja compatvel com a dinmica do ambiente e
com as necessidades de ajustes, permitindo a tomada de aes corretivas no tempo
adequado. Isto pode ocorrer de forma peridica (diria, semanal, mensal etc.) ou por
eventos (a cada entrada de um novo cliente ou servio).
Neste resultado esperado, monitora-se o escopo do servio, as tarefas, as
estimativas, o oramento e o cronograma. Uma das questes comuns quando se
implanta um novo servio no dispor de estimativas precisas sobre o tempo
necessrio para a realizao de um servio. Isto pode levar ao estabelecimento de
ANSs inviveis de serem cumpridos.
Questes que podem ser detectadas no monitoramento, no que se refere a
estimativas:
O tempo necessrio para o atendimento de uma solicitao de servios foi
subestimado, levando ao estabelecimento de um ANS incompatvel.
Por exemplo, inicialmente se previu uma solicitao de servio de
atendimento a uma dvida de banco de dados poderia ser resolvida em at
30 minutos e, com o monitoramento do servio se percebeu que a mdia
de 45 minutos.
O tamanho da equipe necessria para o atendimento da carteira de clientes
de um servio foi subestimado, levando ao gargalo no atendimento aos
clientes.
Por exemplo, inicialmente se previu que uma equipe de 5 pessoas seria
suficiente prestar atendimento a 10 clientes de suporte a redes.
Posteriormente se verificou que esta equipe conseguiria atender no mximo
7 clientes.
Em todo o caso, o planejamento 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. Desvios significativos podem levar necessidade de replanejamento,
implicando em alteraes no Plano de Trabalho ou em qualquer um dos planos
associados. Caso seja necessrio, planos de ao devem ser gerados (ver GTR18 e
GTR19) para corrigir desvios ou evitar que outros desvios aconteam
posteriormente.
5.3.14 GTR14 - Os recursos materiais e humanos bem como os dados
relevantes do trabalho so monitorados em relao ao planejado
O objetivo deste resultado esperado garantir que o trabalho seja monitorado em

relao aos itens planejados referentes a recursos materiais e recursos humanos
(ver GTR7 e GTR8). Em geral, durante um monitoramento, faz-se uma anlise do
que foi planejado anteriormente com os valores atuais das variveis consideradas.
Questes em relao aos recursos humanos podem estar relacionadas, mas no se
limitam a: sada de um membro da equipe; identificao de necessidade de um novo
perfil no previsto anteriormente; produtividade abaixo do esperado; entre outros.

Questes em relao aos recursos materiais podem estar relacionadas, mas no se
limitam a: necessidade de aquisio de novos equipamentos ou softwares;
necessidade de substituio de equipamentos ou softwares; novas necessidades de
viagens; indisponibilidade de recursos ou instalaes previamente planejados; entre
outros.
Questes em relao aos dados relevantes podem estar relacionadas, mas no se
limitam : identificao de novos documentos que devem ser includos no
repositrio; produtos de trabalho intermedirios que no foram produzidos ou
armazenados adequadamente; novas necessidades de liberao ou restrio de
acesso a dados; novas polticas de privacidade impostas pela organizao ou pelo
cliente; entre outros.
Em todo o caso, o planejamento do trabalho deve ser revisto para adequao dos
itens pertinentes. Caso seja necessrio, planos de ao devem ser gerados (ver
GTR18 e GTR19) para corrigir desvios ou evitar que outros desvios aconteam
posteriormente. Desvios significativos podem levar necessidade de
replanejamento, implicando em alteraes no Plano de Trabalho ou em qualquer um
dos planos associados.
5.3.15 GTR15 - Os riscos so monitorados em relao ao planejado
No decorrer da execuo, novos riscos podem ser identificados e os parmetros dos

riscos j identificados podem ser alterados (ver GTR6). Embora no exigido o seu
planejamento no nvel G, 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 GTR18 e GTR19)
para corrigir problemas ocasionados pela ocorrncia de um risco ou para evitar que
outros riscos aconteam posteriormente. Desvios significativos podem levar
necessidade de replanejamento, implicando em alteraes no Plano de Trabalho ou
em qualquer um dos planos associados.
5.3.16 GTR16 - O envolvimento das partes interessadas no trabalho
planejado, monitorado e mantido
Devem ser identificados os interessados relevantes, em que fases eles so

importantes e como eles sero envolvidos (comunicaes, revises peridicas,
revises em marcos, comprometimentos, entre outros). Uma vez identificado e
planejado o envolvimento, este dever ser seguido, monitorado e mantido ao longo
de toda a execuo do trabalho. Os interessados podem incluir, mas no esto
limitados a: clientes, usurios (ou seus representantes), direo da organizao,
membros da equipe, outras reas internas da organizao, entre outros. Quanto
menor o trabalho, ou o ambiente e a quantidade de clientes, mais simples poder
ser a comunicao, devido ao pequeno nmero de pessoas envolvidas.

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. O
distanciamento da gerncia do trabalho em relao aos interessados pode acarretar
desvios em relao s reais necessidades que o trabalho 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 Trabalhos 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 trabalho e o que se espera desta
participao. O mesmo deve ser aplicado aos membros da equipe.
Para o caso do Plano de Trabalho Organizacional, importante que todas as
comunicaes previstas com os clientes estejam identificadas e documentadas,
assim como as interfaces entre as diversas reas internas e externas envolvidas na
prestao do servio. Quando o gerenciamento dos servios apoiado por uma
ferramenta computacional, comum que um workflow garanta esta comunicao.
Este workflow geralmente est programado para prover feedbacks regulares aos
clientes com relao ao atendimento de suas solicitaes de servios e tambm em
relao ao atendimento de incidentes.
5.3.17 GTR17 - Revises so realizadas em marcos do trabalho e conforme
estabelecido no planejamento
Revises em marcos do trabalho no devem ser confundidas com o

acompanhamento descrito em GTR13, GTR14 e GTR15, que derivado do
acompanhamento do dia-a-dia do trabalho.
No caso do Plano de Trabalho Especfico, os marcos do trabalho precisam ser
previamente definidos ao se realizar o planejamento. Geralmente so estabelecidos
marcos ao final de cada fase. No caso do Plano de Trabalho Organizacional, esta
periodicidade no est relacionada a uma fase, mas sim a um ponto importante e
relevante de controle. Muitas vezes realizada uma reviso semestral ou anual,
dependendo das necessidades dos servios.
Este resultado importante porque as revises em marcos so oportunidades para
verificar, de forma ampla, o andamento de todo o trabalho, independentemente do
acompanhamento do dia-a-dia. Em trabalhos grandes essas revises so
fundamentais, questionando, inclusive, a viabilidade de continuidade do trabalho.
Alm das revises em marcos, outras revises podero ser estabelecidas no
planejamento do trabalho. Caso isto ocorra, estas revises devero ser executadas
conforme planejado.
Uma reviso, com periodicidade mais longa, de uma equipe de operao,
geralmente visa anlise do cumprimento geral dos ANSs, da rentabilidade
esperada dos servios, da capacidade para atendimento de novos clientes, da
capacidade para a introduo de novos servios etc.

5.3.18 GTR18 - 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 (GTR17) e de monitoramento (GTR13, GTR14

e GTR15) do trabalho possibilitam a identificao de desvios que estejam ocorrendo
nos trabalhos. natural que desvios em relao ao planejamento aconteam
durante a execuo dos trabalhos. Estes desvios devem ser analisados e
registrados, por exemplo, por meio de ferramentas especficas, planilhas ou outros
tipos de mecanismos de gerenciamento. A falha na execuo desta tarefa pode
afetar a habilidade de executar aes para correo dos desvios, afetando o bom
andamento dos trabalhos.
Para completar o trabalho de monitoramento, os desvios precisam ser corrigidos e
gerenciados at a sua resoluo, com base em planos de ao, estabelecidos
especificamente para resolver as questes levantadas e registradas (GTR19). Caso
no se consiga resolver as questes neste nvel, deve-se escalonar a resoluo das
aes a nveis superiores de gerncia.
5.3.19 GTR19 - 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 trabalho (GTR13, GTR14 e GTR15) e das

revises em marcos (GTR17), desvios so identificados, analisados e registrados
(GTR18). Aes corretivas devem ser estabelecidas para resolver desvios que
possam impedir o trabalho de atingir seus objetivos se no forem resolvidos de
forma adequada. No caso do Plano de Trabalho Especfico, pode ser que os
resultados esperados do trabalho sejam comprometidos. No caso do Plano de
Trabalho Organizacional, pode ser que o desempenho previsto nos ANSs possa no
ser atingido.
As aes corretivas definidas devem ser gerenciadas at sua concluso. O controle
das questes levantadas, as aes tomadas, os responsveis pelas aes e os
resultados devem ser registrados.
As questes identificadas, e devidamente registradas, provm uma 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
trabalho. 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 desvios inesperados e suas implicaes. Acompanhar o andamento de
uma ao corretiva at sua concluso inclui verificar, com 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 trabalho, como clientes e usurios.

6 Gerncia de Requisitos (GRE)
6.1 Propsito
O propsito do processo Gerncia de Requisitos gerenciar os requisitos do

trabalho e dos componentes do trabalho e identificar inconsistncias entre os
requisitos, os planos do trabalho e os produtos do trabalho.
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 trabalho, incluindo requisitos impostos ao servio pela prpria
organizao.
Para assegurar que o conjunto de requisitos acordados gerenciado e fornece
apoio s necessidades de planejamento e execuo do trabalho, a organizao
deve executar um conjunto de passos definidos e apropriados. Quando um trabalho
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 trabalho. 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 e os produtos de trabalho.
Na rea de gerenciamento de servios, a Gerncia de Requisitos (GRE) est
fortemente relacionada com a Gerncia de Nvel de Servio (GNS). A Gerncia de
Nvel de Servio responsvel por documentar e gerenciar os Acordos de Nvel de
Servio (ANS), que estabelecem as expectativas de desempenho do fornecedor ao
prover os servios. importante, no entanto, compreender, que nem todos os
requisitos do servio estaro documentados por meio de ANSs. Existem requisitos
que so internos da organizao que no faro parte dos ANSs, uma vez que estes
regem os relacionamentos do provedor do servio com os seus clientes. Quando
acordos semelhantes precisarem ser estabelecidos com reas internas do prprio
provedor, ento sero utilizados os Acordos de Nvel Operacional (ANOs).
Uma boa comunicao com os fornecedores de requisitos fundamental para

assegurar um bom entendimento das necessidades do cliente e dos requisitos do
servio e, consequentemente, aumentar as chances de sucesso. Compreender
quem so os fornecedores de requisitos e estabelecer mecanismos adequados de
comunicao fundamental para o sucesso na implantao e na operao de
servios.
Existem diversos aspectos ligados a requisitos que devem ser negociados com os
fornecedores de requisitos, como por exemplo: definio de requisitos, aprovao de
requisitos, solicitao de mudana nos requisitos, dentre outros.

Um requisito de servio pode ser entendido como o conjunto completo de requisitos
que afetam a entrega do servio e desenvolvimento do sistema de servios [CMMI
Product Team, 2010]. Os requisitos de servios incluem requisitos tcnicos
(propriedades do servio a serem entregues e o sistema de servio necessrio para
viabilizar a entrega) e no tcnicos (condies adicionais, provises,
comprometimentos e condies derivadas dos objetivos de negcio) [CMMI Product
Team, 2010].
A gerncia de requisitos envolve identificar os requisitos do servio e dos
componentes do servio, bem como estabelecer e manter um acordo entre o cliente
e a equipe sobre esses requisitos. Tambm objetivo da gerncia de requisitos
controlar e tratar as mudanas nos requisitos ao longo do desenvolvimento.
Nenhum servio existe isoladamente e a compreenso do relacionamento entre os
servios e seus componentes fundamental para a manuteno dos ANSs. Para
apoiar o processo de mudana de requisito, fundamental definir e manter a
rastreabilidade dos requisitos. Aqui se pode considerar o uso do mesmo conceito de
rastreabilidade utilizado no desenvolvimento de software. 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 servio
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. O CMMI-SVC define rastreabilidade bidirecional
uma associao entre duas ou mais entidades lgicas que
discernvel em qualquer direo (isto , de e para uma entidade) [CMMI Product
Team, 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 elementos 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 servio. Esse mecanismo deve permitir tambm
rastrear itens do nvel mais baixo de decomposio do servio at os seus requisitos
fonte. A rastreabilidade vertical auxilia a determinar se todos os requisitos fonte
foram completamente tratados e se todos os requisitos de mais baixo nvel podem
ser rastreados para um requisito fonte vlido. A rastreabilidade vertical bidirecional
possibilita, ento, rastrear requisitos e produtos de trabalho a itens de servio
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 trabalho
que contm as estimativas aprovadas de esforo e custo para os produtos de
trabalho e tarefas, bem como os itens do servio que necessitam ser modificados.
Por essas anlises, o responsvel pela gerncia do trabalho capaz de negociar
com o cliente alteraes nos planos do trabalho ou nos ANSs para atender s
solicitaes de mudanas de requisitos e, ao mesmo tempo, minimizar os riscos,
como por exemplo, desvios de cronograma e de custos.
Os requisitos de um servio deveriam permitir que sejam atendidos os requisitos em
todas as seguintes reas de negcio [TSO, 2011b]:
Escalabilidade do servio para atender aos requisitos futuros, como apoio aos
de objetivos de negcio de longo prazo;
Os processos e as unidades de negcio suportadas pelos servios;
Os servios e os requisitos de negcio acordados para a funcionalidade (por
exemplo, utilidade);
O servio em si e seus ANSs;
Os componentes de tecnologia utilizados para implantar e entregar o servio,
incluindo a infraestrutura, o ambiente, os dados e as aplicaes;
Os servios de suporte internos entregues e componentes e seus ANOs
associados;
Os servios de suporte externos entregues e componentes e seus contratos
associados, que normalmente tero seus prprios acordos e/ou cronogramas;
As medidas e as mtricas associadas exigidas;
Os nveis legais e requeridos de segurana;
Requisitos de sustentabilidade.
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 trabalho, 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.
Aps a identificao dos requisitos do servio e dos componentes do servio,
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

trabalho a partir do qual mudanas nos requisitos devem ser tratadas formalmente
para minimizar o impacto dessas mudanas no trabalho 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 trabalho, se possvel, a partir de critrios estabelecidos.
Na rea de gerenciamento de servios, por exemplo, comum que faam parte dos
requisitos, itens de infraestrutura, como: servidores, estaes de trabalho,
equipamentos de rede, sistemas gerenciadores de banco de dados, ferramentas
diversas de monitoramento de hardware e software, sistemas de proteo (firewall),
sistemas de backup, unidades de armazenamento (discos), entre outros. Podem
ainda ter que ser considerados itens relacionados ao prprio ambiente de operao
como espaos fsicos, climatizao, isolamento trmico e acstico, segurana fsica,
entre outros. Softwares e os dados por ele utilizados tambm podem ser
considerados requisitos na rea de servios [TSO, 2011b].
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 itens de
especificao para implementao do servio. 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 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. Isto se torna especialmente
importante antes da assinatura do ANS, pois a partir deste momento, requisitos de
desempenho passam a fazer parte da relao contratual com 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 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.
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
2
A equipe tcnica compreende todos os envolvidos diretamente no desenvolvimento do servio.
trabalho como um todo (incluindo seus requisitos). Esta reunio possibilita que as
diversas partes possam opinar, aprovar e se comprometer em relao aos
requisitos. 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.
Para prestadores de servio com vrias equipes e com grande quantidade de
pessoas alocadas, a tarefa de obter o comprometimento, de forma individualizada,
no trivial. Para esses casos os ANSs e procedimentos internos de atendimento
dos servios atendem a este resultado.
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 descritas no Plano de Trabalho.
Ao longo do desenvolvimento do servio, os requisitos assumem diferentes
abstraes e denominaes. Por exemplo, podem estar descritos na forma de
necessidades e restries do cliente, requisitos de cliente, requisitos do servio,
requisitos tcnicos etc. Os requisitos, dentro do ciclo de vida do desenvolvimento do
servio, so posteriormente derivados em elementos de especificao, projeto
(design) e, ento, transformados em itens implementados em produo.
Em geral, o detalhamento dos requisitos, a transformao em especificaes, o
desenvolvimento do servio, o planejamento e a execuo de testes so planejados
para garantir a correta execuo do servio. Geralmente isto est descrito por meio
de tarefas previstas no Plano de Trabalho, conforme previsto pelo processo
Gerncia de Trabalhos (GTR). Dessa forma, a existncia de rastreabilidade
horizontal e vertical, conforme prevista neste resultado esperado, pressupe que
diferentes abstraes dos requisitos, documentos relacionados (por exemplo,
cronogramas e casos de testes) e os itens implementados 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 e/ou servios.
6.3.4 GRE4 - Revises em planos e produtos derivados do trabalho so
realizadas visando a identificar e corrigir inconsistncias em relao aos
requisitos
A consistncia entre os requisitos e os produtos gerados pelo trabalho deve ser

avaliada e os problemas identificados devem ser corrigidos.

Este resultado sugere a realizao de revises ou de algum mecanismo equivalente
para identificar inconsistncias entre os requisitos e os demais elementos do
trabalho como, por exemplo, planos, atividades e produtos de trabalho resultantes.
As inconsistncias identificadas devem ser registradas e aes corretivas
executadas com o objetivo de resolv-las. Exemplos de revises com esse objetivo
so revises de monitorao e controle do trabalho 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; entre
outros.
As aes para correes das inconsistncias devem ser acompanhadas at que
sejam resolvidas.
6.3.5 GRE5 - Mudanas nos requisitos so gerenciadas ao longo do trabalho
Durante a execuo do trabalho, os requisitos podem mudar por uma srie de

motivos. Desta forma, requisitos adicionais podem ser incorporados, requisitos
podem ser retirados 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 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 acontecem em diferentes nveis de abstrao dos
requisitos, no apenas nos requisitos de cliente. A partir do nvel E de maturidade do
MR-MPS-SV, o processo de Gerncia de Mudana (GMU) se relaciona com este
processo, de modo que todas as mudanas so analisadas antes de serem
efetivamente implantadas.
importante ressaltar que em um trabalho no obrigatrio que sempre ocorram
mudanas nos requisitos estabelecidos. Porm, raro um trabalho 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, 2013i], evidncias da gerncia de mudanas de requisitos
devem ser fornecidas pelo menos para um dos trabalhos avaliados.

7 Gerncia de Incidentes (GIN)
7.1 Propsito
O propsito do processo Gerncia de Incidentes restaurar os servios

acordados e cumprir as solicitaes de servios dentro de um Acordo de Nvel
de Servio (ANS).
No mbito do modelo MR-MPS-SV optou-se pelo tratamento conjunto, ou seja, no

mesmo processo, de Incidentes e Solicitaes de Servios, conforme definido na
Norma Internacional ISO/IEC 20000-1 [ISO/IEC, 2011]. Outros modelos relacionados
a servios, como o ITIL [TSO, 2011a] e o CMMI-SVC [CMMI Product Team, 2010]
tratam os dois processos separadamente. Ainda no contexto do modelo MR-MPS-
SV optou-se pelo tratamento de Incidentes e Problemas em processos separados,
conforme previsto na ISO/IEC 20000-1 [ISO/IEC, 2011] e no modelo ITIL [TSO,
2011a], mas contrrio ao modelo CMMI-SVC [CMMI Product Team, 2010] que faz o
tratamento conjunto de Incidentes e Problemas na rea de processo Incident
Resolution and Prevention. Na Norma ISO/IEC 20000 [ISO/IEC, 2011] os processos
Gerncia de Incidentes e Gerncia de Problemas fazem parte do grupo de
processos denominado Processos de Resoluo.
Para a compreenso do processo de Gerncia de Incidentes alguns conceitos so
relevantes: incidentes, gerenciamento de incidentes, solicitao de servios e
gerenciamento de solicitaes de servios.
Um incidente pode ser compreendido como sendo uma interrupo no planejada
de um servio, uma reduo na qualidade de um servio ou um evento que ainda
no impactou o servio para o cliente [ISO/IEC, 2011].
Definio similar tambm utilizada no contexto do modelo ITIL [TSO, 2011a]: um
incidente uma interrupo no planejada em um servio de TI ou a reduo na
qualidade de um servio de TI. Falha em um item de configurao que pode ainda
no ter afetado o servio um incidente por exemplo, a falha de um disco em um
conjunto de espelhamento.
O modelo CMMI-SVC [CMMI Product Team, 2010] utiliza a expresso incidente de
servio, para distinguir o termo de seu uso corriqueiro em outros contextos. Define,
portanto, incidente de servio como sendo: uma indicao de uma interferncia real
ou potencial em um servio.
Conforme se pode observar a partir das definies, entende-se por incidente, algo
no planejado, que ocorre ao longo da prestao do servio e que pode afetar o
negcio do cliente. Por exemplo, durante a prestao de um servio de
monitoramento de servidores, a ferramenta de monitoramento trava e interrompe o
monitoramento (incidente), no permitindo que se acompanhe o status do servidor.
Neste instante, a execuo do servio de monitoramento interrompida. Gerenciar o
incidente significa colocar a ferramenta de monitoramento no ar o mais rpido
possvel, de modo que o tempo de interrupo do servio esteja de acordo com o

que estabelece o Acordo de Nvel de Servio assinado com o cliente para quem o
servio de monitoramento de servidores est sendo prestado. Gerenciar significa
ainda, registrar, acompanhar, escalonar, se necessrio, e encerrar o registro do
incidente.
Um dos objetivos do processo de Gerncia de Incidentes, como descrito em seu
propsito, restaurar a prestao do servio ao estado normal o mais rapidamente
possvel, sem se deter, inicialmente, em suas causas subjacentes. Consiste ainda
em implementar solues de contorno (workarounds), quando necessrio. No MR-
MPS-SV, as causas subjacentes sero tratadas em processo parte, denominado
Gerncia de Problemas (GPL). O gerenciamento de incidentes responsvel pela
coordenao de todos os esforos para o restabelecimento da normalidade do
servio dentro dos prazos acordados no Acordo de Nvel de Servio. O
gerenciamento de servios assegura, ainda, que nenhum incidente tenha sido
perdido, esquecido ou ignorado [ORAND, 2013].
Um incidente pode ser detectado de vrias formas: por chamados realizados para a
central de suporte, por meio de ferramentas de monitoramento de itens de
configurao automticas, por comunicaes realizadas por fornecedores etc.
O processo de Gerncia de Incidentes precisa estar alinhado aos processos de
negcio, de modo que a prioridade na resoluo dos incidentes seja aquela
determinada pelo negcio. Isto, geralmente, est descrito no Acordo de Nvel de
Servio. Quanto mais rapidamente um incidente tratado, maior a disponibilidade do
servio e, consequentemente, maior a satisfao do cliente e/ou usurio do servio.
A Norma ISO/IEC 20000-2 [ISO/IEC, 2012] sugere que seja definido um processo
especial para o tratamento de incidentes mais graves (major incidents). Isto inclui
definir: o que um incidente grave, quem tem a autoridade para declarar que um
incidente grave, quem deve coordenar a sua resoluo, como deve ser resolvido,
que comunicaes devem ser realizadas ao longo de sua resoluo e qual o
relacionamento com o processo de Gerncia de Continuidade e Disponibilidade dos
Servios (GCD) e quando sua invocao necessria.
Conforme citado anteriormente, optou-se, no MR-MPS-SV, por considerar que o
processo de Gerncia de Incidentes trata tanto dos incidentes, quanto das
solicitaes de servios. Portanto, o outro objetivo do processo de Gerncia de
Incidentes cumprir as solicitaes de servios de acordo com o previsto no Acordo
de Nvel de Servios.
Uma solicitao de servio refere-se a qualquer solicitao do cliente em relao
aos servios prestados. Pode ser, por exemplo, um telefonema para esclarecimento
de uma dvida, a solicitao para reativao de uma senha de acesso, a solicitao
de uma documentao, o esclarecimento de como acessar um servio, a execuo
de mudanas de baixo risco pr-aprovadas etc.
O processo de Gerncia de Incidentes se relaciona com o processo de Gerncia de
Problemas, uma vez que os incidentes so repassados do primeiro para o segundo,
com o objetivo de buscar a causa raiz. Este relacionamento e suas interfaces devem
ser documentados no processo de Gerncia de Incidentes.

O processo de Gerncia de Incidentes tambm se relaciona com o processo de
Gerncia de Mudanas, uma vez que uma solicitao de mudana pode estar sendo
realizada para resolver um incidente ou para cumprir uma solicitao de servio.
Este relacionamento e suas interfaces tambm devem estar documentados no
processo de Gerncia de Incidentes.
O processo de Gerncia de Incidentes tambm se relaciona com o processo de
Gerncia de Continuidade e Disponibilidade dos Servios (GCD) e com o processo
de Gerncia de Nvel de Servio (GNS).
7.3.1 GIN 1 - Uma abordagem para o gerenciamento de incidentes e

solicitao de servio estabelecida e mantida
A organizao deve estabelecer polticas, diretrizes e procedimentos para o

tratamento das solicitaes de servios e dos incidentes, ao longo de todo o seu
ciclo de vida. Isto inclui procedimentos para registro, priorizao, tratamento,
escalonamento, resoluo e comunicao para as partes interessadas.
Normalmente o gerenciamento de incidentes inicia com a comunicao do incidente
para um Service Desk. Isto pode ser compreendido, no senso tradicional de
servios, como uma Central de Atendimento, ou, em ambientes menores, como
sendo a pessoa de contato, que responsvel por receber a solicitao de servio
ou o incidente e dar continuidade no seu atendimento.
Como parte da abordagem, solues tpicas para incidentes comuns podem ser
disponibilizadas para a equipe que presta o atendimento aos incidentes, agilizando o
atendimento e padronizando respostas e solues. Normalmente, os procedimentos
incluem o passo a passo a ser utilizado na soluo, a definio das equipes ou
especialistas a serem envolvidos, tempo tpico de soluo, procedimentos para o
escalonamento, entre outros.
Incidentes mais graves, ou seja, que tenham prioridade mais elevada, em funo
dos nveis de servio acordados e da criticidade para os negcios, podem ter
procedimentos especiais e destacados, facilitando o acesso s informaes e,
consequentemente, agilizando a soluo.
Quando uma organizao trabalha em turnos, importante que os procedimentos
para o gerenciamento de incidentes preveja como ser a passagem de informaes
entre os turnos, especialmente com relao aos incidentes pendentes de resoluo.
7.3.2 GIN 2 - Um sistema de gerenciamento e controle de incidentes e
solicitao de servios estabelecido e mantido
Um sistema de gerenciamento e controle de incidentes e solicitao de servios

normalmente implementado por meio de uma ferramenta automatizada, ou seja,
um software. O mercado possui uma srie de ferramentas que permitem que as
solicitaes de servio e os incidentes sejam registrados e acompanhados.
comum que estas ferramentas permitam o registro de uma variedade de atributos
acerca das solicitaes de servios e dos incidentes, permitindo que seu progresso
seja monitorado e controlado, utilizando, inclusive, funcionalidades de workflow.
No entanto, isto no uma exigncia. Dependendo da complexidade dos servios
oferecidos, o sistema pode ser composto por um conjunto de procedimentos e
instrumentos de registro e acompanhamento que no seja uma ferramenta
especfica para esta finalidade. Nestes casos, e-mails e planilhas adequadamente
configurados podem ajudar.
Independentemente do meio escolhido, necessrio definir os estados
intermedirios do que se deseja acompanhar. Estes estados podem variar, de
acordo com as necessidades de acompanhamento da organizao, bem como de
acordo com as exigncias documentadas nos ANSs. normal que, no mnimo,
sejam planejados estados como: aberto (ou registrado), em progresso (ou em
execuo), solucionado (tica do prestador do servio) e encerrado (tica do
cliente). De acordo com as necessidades da organizao, mais nveis intermedirios
podem ser adicionados. importante lembrar que, estabelecer nveis intermedirios
significa controles adicionais, ou seja, s far sentido colocar um estado adicional se
este estado for efetivamente relevante para o acompanhamento da solicitao de
servio ou do incidente. Estados intermedirios podem incluir, mas no esto
limitados a: em anlise, escalonado para nvel X, e assim por diante.
7.3.3 GIN 3 - Incidentes e solicitaes de servios so registrados e
classificados
As solicitaes de servios e os incidentes devem ser registrados utilizando os

procedimentos definidos e o sistema de gerenciamento colocado em operao.
Preferencialmente, sempre que possvel, devem ser armazenadas informaes de
forma padronizada, facilitando o acesso informao, tanto no momento de
resoluo do incidente, quanto posteriormente na anlise para adoo de solues
definitivas (Gerncia de Problemas).
O registro deve incluir todos os atributos necessrios para o acompanhamento do
ciclo de vida completo da solicitao de servio ou do incidente. Isto pode incluir,
mas no est limitado a: data da solicitao, solicitante, descrio da
solicitao/incidente, nvel de acordo de servio associado, priorizao etc. Na
medida em que o incidente vai sendo tratado e progride de estado, novas
informaes passam a ser registradas como, por exemplo, os passos para a
resoluo do incidente, a pessoa responsvel pela soluo etc.
O correto registro dos incidentes, bem como o registro da sua posterior soluo,
contribui para a gesto do conhecimento acerca destes acontecimentos, permitindo
evoluir a qualidade da prestao do servio.
Um sistema de classificao, priorizao e escalonamento padronizado, e
preferencialmente automatizado, ajuda a agilizar o atendimento, alm de permitir
que sejam extradas informaes operacionais e gerenciais que contribuiro para a
melhoria do servio prestado ao longo do tempo.
Posteriormente no ciclo de vida do gerenciamento de servios, as informaes
registradas acerca dos incidentes e das solicitaes de servio iro prover um
valioso instrumento para auxiliar na anlise da viabilidade de se cumprir os ANSs
acordados. Servios cuja soluo de incidentes e solicitaes de servio

sistematicamente quebra os ANSs so candidatos reviso em termos de
capacidade e disponibilidade.
7.3.4 GIN 4 - Incidentes e solicitaes de servios so priorizados e
analisados
As solicitaes de servios e os incidentes devem ser priorizados levando-se em

considerao, principalmente, os ANSs estabelecidos.
Para a priorizao dos incidentes, de acordo com a Norma ISO/IEC 20000-2
[ISO/IEC, 2012], deveriam ser considerados, pelo menos:
Prioridade;
Perfis disponveis;
Requisitos competindo pelos recursos;
Esforo/custo para prover o mtodo de resoluo; e,
Tempo decorrido para prover o mtodo de resoluo.
Geralmente a organizao possui um sistema de priorizao de incidentes que se
baseia: na criticidade do sistema (riscos envolvendo a vida, prejuzos financeiros,
ANSs mais rigorosos etc.), na quantidade de usurios afetados pela parada, na
disponibilidade de recursos para a soluo do incidente etc.
comum determinar a prioridade, tanto dos incidentes, quanto das solicitaes de
servios, com base na urgncia da solicitao/incidente e no seu impacto. o
mesmo conceito utilizado na definio da severidade de riscos, por exemplo, quando
se analisa a probabilidade do risco ocorrer e o impacto caso ele ocorra. Uma matriz
com os tempos esperados de soluo dos incidentes e solicitao de servios, em
funo da urgncia e impacto pode ser estabelecida. Pode ser necessrio ter
matrizes separadas para incidentes e solicitaes de servios.
7.3.5 GIN 5 - Incidentes e solicitaes de servios so resolvidos e
encerrados
As solicitaes de servios devem ser atendidas dentro dos prazos estabelecidos

nos ANSs. Da mesma forma, os incidentes devem ser resolvidos obedecendo
prazos especficos estabelecidos nos ANSs. Em um ambiente dinmico de
atendimento a incidentes, um determinado incidente pode chegar com determinada
prioridade menor e, na medida em que o tempo vai passado, ao se aproximar do
tempo limite previsto pelo ANS, ele ganha nova prioridade mais alta, visando garantir
que o ANS seja cumprido.
Para a resoluo dos incidentes, a equipe de atendimento deve ter sua disposio
todas as informaes necessrias, incluindo a lista de erros conhecidos e
respectivos procedimentos de tratamento, alm de todas as ferramentas (hardware e
software) necessrias para a soluo.
comum que o encerramento do incidente ou da solicitao de servios seja
realizado em duas etapas: uma referente ao provedor de servios, que considera
que o incidente ou solicitao de servios est encerrado, outro do cliente, que

confirma seu encerramento. Um incidente ou uma solicitao de servio no poder
ser considerado encerrado at que o cliente tenha confirmado seu encerramento.
7.3.6 GIN 6 - Incidentes e solicitaes de servios que no progrediram
conforme os acordos de nvel de servio so escalonados
Quando uma solicitao de servio ou um incidente no progredirem de acordo com

os prazos estabelecidos nos ANSs, um procedimento de escalonamento deve ser
colocado em ao. Escalonar, neste contexto, significa comunicar a um nvel
superior que o ANS pode no ser atendido e adotar aes corretivas para reduzir os
impactos sobre o negcio.
Dependendo da criticidade do servio e da prioridade do ANS, pode ser necessrio
definir pontos intermedirios de controle, antes que o ANS seja quebrado. Neste
caso, procedimentos para preveno so disparados.
Se for utilizada ferramenta automatizada para o gerenciamento de incidentes e
solicitaes de servio, possvel que ela permita a configurao de parmetros
para escalonamento automtico, com base em tempos de execuo. Desta forma,
ao atingir determinados limites pr-estabelecidos, ser possvel que
automaticamente o incidente seja escalonado para o prximo nvel.
7.3.7 GIN 7 - Informaes a respeito da situao ou progresso de um incidente
relatado ou solicitao de servio so comunicadas s partes interessadas
importante que a organizao defina e coloque em execuo procedimentos para

que as partes envolvidas possam tomar conhecimento do andamento das
solicitaes de servio e do tratamento dos incidentes.
Quando uma ferramenta automatizada utilizada para o registro e
acompanhamento dos incidentes e das solicitaes de servios, normal que haja
formas de disponibilizar consultas s informaes de acompanhamento,
diferenciadas por perfil. Para clientes externos, comum que sejam disponibilizadas
informaes referentes ao andamento da solicitao/incidente, tais como: data e
hora do incio da soluo, ANS associado, situao, previso de atendimento, entre
outras. Para a equipe interna da organizao necessrio conhecer detalhes que
muitas vezes no so disponibilizados para os clientes externos, tais como tempos
internos de soluo, tentativas de soluo (bem ou mal sucedidas), escalonamentos
e comentrios detalhados sobre a soluo que est sendo adotada.
importante que o cliente/usurio seja informado quando um ANS acordado no
poder ser cumprido, de modo que se possa ativar possveis rotinas de
contingncia, evitando, ou minimizando impactos sobre o negcio.
Vises agregadas de informaes sobre o andamento de incidentes e solicitaes
de servio tambm devem ser geradas e comunicadas para as partes interessadas
dos diversos nveis de gesto da organizao como gerncia superior, gerncia local
e equipes envolvidas. Isto especialmente importante quando se trata do
relacionamento da Gerncia de Incidentes com outros processos do gerenciamento
de servios como: Gerncia de Problemas (GPL), Gerncia de Capacidade (GCA),
Gerncia de Continuidade e Disponibilidade de Servios (GCD), Gerncia de Nvel
de Servio (GNS) etc.
8 Gerncia de Nvel de Servio (GNS)
8.1 Propsito
O propsito do processo Gerncia de Nvel de Servio garantir que os

objetivos dos acordos de nvel de servio para cada cliente sejam atendidos.
Para o entendimento do processo de Gerncia de Nvel de Servio (GNS)

importante compreender o conceito de Acordo de Nvel de Servio (ANS) ou, como
tambm conhecido do ingls, SLA (Service Level Agreement).
O ANS v servios e o cliente que
v bj v v [ISO/IEC, 2011]. Ainda de acordo
com a Norma ISO/IEC 20000, um acordo de nvel de servio pode tambm ser
estabelecido entre o provedor e o fornecedor, um grupo interno ou um cliente
atuando como fornecedor. O acordo de nvel de servio pode tambm ser includo
em um contrato ou outro tipo de documento de acordo.
O CMMI-SVC [CMMI Product Team, 2010] distingue o termo acordo de servio do
termo acordo de nvel de servio. No primeiro caso, define um acordo de servio
como sendo uma ligao (acordo escrito) de uma troca prometida de valor entre o
fornecedor do servio e o cliente. Entende por troca prometida de valor o
reconhecimento mtuo do que cada parte deve fornecer. Geralmente o cliente
fornece um pagamento e o fornecedor, um servio. No segundo caso, define ANS
v q v ;
as medidas do servio; os nveis aceitveis e no aceitveis de servio; e, as
responsabilidades e aes, tanto do cliente quanto do fornecedor, em situaes
antecipadas.
Para o modelo ITIL [TSO, 2011a], um acordo entre um provedor de
servios e um cliente. Complementa ainda, afirmando que um ANS descreve o
servio de TI, documenta objetivos de nvel de servio e especifica as
responsabilidades do fornecedor de servios e do cliente.
Gerenciar o nvel de servio significa garantir que o que est estabelecido no ANS
seja cumprido. O processo de Gerncia de Nvel de Servio (GNS) , portanto, o
condutor entre o provedor do servio e o negcio, para representar as capacidades
operacionais para os negcios [ORAND, 2013].
De acordo com [ORAND, 2013], o ciclo de vida do gerenciamento do servio pode
ser compreendido conforme a Figura 8-1, a seguir.

Definir
Revisar Negociar
Relatar Acordar
Monitorar Entregar
Figura 8-1. Ciclo de vida do gerenciamento de nvel de servio, adaptado de

[ORAND, 2013].
Um novo servio, ou uma alterao em um servio existente, definido. Em

seguida, este servio negociado entre as partes e um acordo estabelecido.
medida que o servio prestado, ocorre o monitoramento e o relato de desempenho
do servio. Revises podem ser necessrias para ajuste no servio, no acordo ou
em ambos. Logo que um servio implantado no ambiente produtivo, as revises
so mais frequentes. Posteriormente, estas revises passam a ser menos
frequentes, pois o servio tende a se estabilizar. Um ANS tambm revisado
quando ocorre uma mudana nos requisitos do servio.
Em [ORAND, 2013] o autor sumariza o objetivo da Gerncia de Nvel de Servio
como sendo: definir, documentar, acordar, monitorar, medir, relatar e revisar o nvel
dos servios prestados com os representantes dos negcios.
No modelo ITIL, o processo Gerncia de Nvel de Servio faz parte do grupo de
processos de Projeto (design) do Servio [TSO, 2011b]. Na Norma ISO/IEC 20000-
1, o processo Gerncia de Nvel de Servio (GNS) faz parte do grupo de Processos
de Entrega de Servios [ISO/IEC, 2011]. O CMMI-SVC [CMMI Product Team, 2010]
trata o assunto de forma particionada nas reas de processo de Gerncia
Estratgica de Servio (Strategic Service Management - SSM) e Entrega de Servios
(Service Delivery - SD).
O processo de Gerncia de Nvel de Servio est diretamente relacionado com o
processo de Gerncia de Portflio de Trabalhos (GPT), no nvel F, no que diz
respeito ao alinhamento estratgico dos servios com os objetivos de negcio da
organizao, estabelecendo os itens gerais que nortearo os ANSs. Est ainda
diretamente relacionado com os processos de Gerncia de Incidentes (GIN),
Aquisio (AQU) e Medio (MED).

8.3.1 GNS1 - Servios e dependncias so identificados
O primeiro passo para o Gerenciamento do Nvel de Servio a identificao dos

servios oferecidos, que so geralmente documentados em forma de um catlogo
de servios. Quando a Gerncia de Portflio de Trabalhos (GPT) j est
implementada, no nvel F, este um produto resultante da anlise do portflio de
servios.
Para cada servio oferecido, as dependncias devem ser identificadas, de modo que
todo o ciclo de prestao do servio possa ser compreendido e gerenciado. Isto
inclui as reas internas envolvidas na prestao do servio e suas formas de
relacionamento. Nestes casos comum que sejam estabelecidos Acordos de Nvel
de Operao (ANO), conhecidos como OLA, do ingls Operational Level Agreement.
Trata-se de acordos entre as reas internas envolvidas na prestao do servio, de
modo que o ANS externo possa ser atendido.
Dependncias tambm incluem servios ou componentes de servios que so
adquiridos de terceira parte e que compem o servio entregue ao cliente. Quando
esta situao se configurar, o processo de Aquisio deve estar envolvido para
garantir a seleo, a contratao e o monitoramento da terceira parte, de modo que
os ANSs estabelecidos com o cliente possam ser cumpridos. ANSs entre o
fornecedor e o seu subcontratado tambm podem ser previstos.
8.3.2 GNS2 - Objetivos de nvel de servio e solues caractersticas para
servios so definidas em um Acordo de Nvel de Servio (ANS)
Conforme definido anteriormente, um ANS um entendimento entre o provedor do

servio e o cliente, sobre o que o cliente deve esperar que seja entregue pelo
provedor. O cliente aqui compreendido como aquele responsvel por aceitar o
servio e realizar o pagamento. Um cliente pode ser uma rea interna da
organizao. Um cliente no necessariamente o usurio do servio. Provedor
compreendido como o responsvel pelo fornecimento do servio.
Um ANS pode tomar diversas formas, dependendo do tipo de negcio. H casos em
que o ANS um contrato legal assinado entre as partes, contendo todos os detalhes
que regem a relao de prestao do servio, ou ainda, termos aditivos a contratos
pr-existentes. H outros casos em que o ANS pode ser um instrumento mais
simples, como um acordo, memorando ou at mesmo um e-mail. O importante que
o instrumento utilizado seja reconhecido, por ambas as partes, fornecedor e cliente,
como um compromisso que rege o relacionamento entre ambos no que se refere
prestao do servio.
Um ANS pode cobrir um ou mais servios e um ou mais clientes. Um ANS pode ser
nico para o servio (ANS baseado no servio), independentemente do cliente, ou
pode ter particularidades diferentes para cada cliente. Um ANS pode tambm ser
nico para um cliente, cobrindo todos os servios prestados para aquele cliente
(ANS baseado no cliente). Aspectos de ordem mais geral, que podem atingir todos
os clientes podem ser documentados em um ANS geral e aspectos mais especficos

do cliente podem ser documentados em ANSs especficos. Desta forma se deixa em
termos mais especficos os aspectos mais sujeitos volatilidade.
Podem fazer parte do ANS informaes como: descrio do servio, desempenho
esperado, valores mnimos aceitveis, sanes ou multas, condies de resciso do
contrato etc.
Como em qualquer tipo de contrato, o mais importante a preservao do esprito
ganha-ganha (win-win situation) na elaborao do ANS, ou seja, um bom acordo
aquele que bom para ambas as partes. Acordos que beneficiam apenas um dos
lados, seja o cliente ou o provedor do servio, inevitavelmente esto fadados ao
fracasso. Nveis de acordo de servio que o provedor no tem capacidade para
atender levaro, ao longo do tempo, ao desgaste da relao comercial e, em ltima
instncia, ao rompimento do contrato e at mesmo a disputas judiciais.
As medidas utilizadas para determinar o desempenho do servio podem variar de
acordo com o tipo de servio prestado:
No caso de prestao de servios, envolvendo hardware e software, por exemplo,
por um provedor de servios na nuvem (cloud computing), comum o uso de
medidas como: disponibilidade (ex.: 24h x 7), MTBF (mean time between failures
tempo mdio entre falhas) e MTTR (mean time to repair ou mean time to recovery
tempo mdio para conserto ou tempo mdio para recuperao).
Quando o servio prestado refere-se ao suporte tcnico para determinado assunto,
por exemplo, quando uma organizao vende um produto de software para o
mercado e oferece, como parte dos seus servios, uma central de suporte ao uso do
produto, as principais medidas de desempenho se referem agilidade e preciso do
atendimento. Por exemplo: quantidade de ligaes perdidas (porque o cliente
desistiu de esperar na fila); quantidade de casos resolvidos no primeiro nvel de
atendimento; quantidade de casos resolvidos em determinado tempo limite (80% dos
casos resolvidos em menos de 10 minutos); entre outros.
O importante quando se estabelecem objetivos de nvel de servio que os itens
que compem o acordo possam ser medidos e acompanhados. As medidas
definidas devem ser factveis de coleta, anlise e comunicao. Objetivos pouco
claros so fonte de discrdias entre fornecedores provedores e clientes.
Um mesmo servio pode ser comercializado para diferentes clientes com diferentes
acordos. Por exemplo, um cliente pode ter um ANS que prev ser atendido em at 2
horas, enquanto que outro, para o qual o servio no seja to crtico, pode ter um
tempo de atendimento previsto de at 24 horas. Estas diferenas podem gerar
condies e negociaes financeiras diferenciadas, inclusive.
De acordo com a convenincia da organizao, de modo a garantir o cumprimento
dos ANS estabelecidos com os clientes, podem ser tambm estabelecidos Acordos
de Nvel de Operao (ANOs) entre as reas internas da organizao. Esta uma
forma de garantir desempenhos internos intermedirios que, se no atendidos,
podem comprometer o atendimento do desempenho acordado com o cliente no
ANS. Por exemplo, o tempo previsto para resoluo de um incidente influenciado
pelas vrias etapas do processo, como recebimento da comunicao do incidente,
compreenso do incidente, escalonamento interno (se for o caso), registro da

soluo e encerramento. Todas estas etapas precisam ocorrer nos tempos previstos
ou o ANS no ser cumprido.
Todos os envolvidos na prestao do servio devem ser comunicados sobre o que
envolve o ANS de um determinado servio/cliente. Em nveis superiores de
mautirade do MR-MPS-SV a capacidade e a disponibilidade devem alimentar os
ANSs e os ANOs.
8.3.3 GNS3 - Os servios so monitorados e comparados com os Acordos de
Nvel de Servio (ANS)
Durante a execuo do servio, as medidas que fazem parte do ANS devem ser
monitoradas para que possa ser identificado quando o acordo est sendo cumprido
ou no.
O monitoramento acontece durante a execuo do servio e visa a fornecer
informaes que possam embasar o relacionamento contratual com o cliente. H
casos em que o no cumprimento de um ANS pode levar a sanes para o provedor
do servio.
8.3.4 GNS4 - O desempenho do nvel do servio em relao aos objetivos do
nvel do servio comunicado s partes interessadas
Assim que um servio entra em operao, o ANS comea a vigorar, respeitando os

prazos de carncia negociados, se for o caso. A partir da, periodicamente o
desempenho do nvel de servio, estabelecido pela comparao entre o
desempenho esperado e o desempenho efetivamente ocorrido, precisa ser
comunicado para as partes interessadas. Estas partes interessadas podem ser
externas (cliente) ou internas (reas da organizao envolvidas na prestao do
servio, nvel gerencial RH etc.). H casos, dependendo do tipo de servio prestado,
em que as medidas de desempenho, bem como suas anlises, precisam ser
disponibilizadas a rgos regulamentadores que assim o exigem legalmente.
A periodicidade desta comunicao definida de acordo com a necessidade do
negcio. O ideal que esta periodicidade j esteja estabelecida inclusive dentro do
prprio ANS. Comunicaes acerca do desempenho normal de um servio podem
ter periodicidade maior, como semanal. Comunicaes acerca dos ANSs que foram
quebrados podem ter periodicidade mais frequente (diria, por exemplo).
8.3.5 GNS5 - Alteraes nos requisitos do servio so refletidas no Acordo de
Nvel de Servio (ANS)
Sempre que houver algum tipo de alterao nos requisitos do servio, esta dever
ser refletida no Acordo de Nvel de Servio. Alteraes desta natureza so
negociadas antecipadamente entre as partes, passam por todo o ciclo de
gerenciamento de mudana, envolvendo, inclusive, a formalizao contratual que
refletida no ANS.
Uma alterao nos requisitos pode ser proveniente do prprio cliente, que passa a
demandar por um desempenho diferente, ou por parte do fornecedor. Por exemplo,
um cliente que utiliza os servios de monitoramento de servidores, pode requerer
uma disponibilidade diferente do inicialmente acordado. No primeiro momento a
demanda era, por exemplo, pelo monitoramento dos servidores em dias e horrios
comerciais (5 dias por semana, 10 horas por dia). Posteriormente, ele passa a
demandar o monitoramento em tempo integral (7 dias por semana, 24 horas por
dia). Esta alterao uma mudana de requisito do servio demandada pelo cliente,
que deve seguir todo o ciclo previsto para o gerenciamento da mudana, incluindo a
alterao no ANS.
Todas as alteraes ocorridas em um ANS devem ser imediatamente comunicadas
a todos os envolvidos. Novos ANOs podem ser necessrios.
importante compreender que este resultado est inserido em um contexto maior,
que envolve o processo de Gerncia de Requisitos, Gerncia de Mudanas (GMU),
Gerncia de Capacidade (GCA) e Gerncia de Continuidade e Disponibilidade dos
Servios (GCD). Por exemplo, no caso de um servio de monitoramento de
servidores, necessrio revisar se a capacidade atualmente instalada suficiente
para atender nova exigncia de monitoramento.
9 Entrega de Servios (ETS)
9.1 Propsito
O propsito do processo Entrega de Servios entregar os servios em

conformidade com os acordos de servios.
A Norma ISO/IEC 20000-1 [ISO/IEC, 2011] possui um grupo de processos

denominado Entrega de Servios, do qual fazem parte os diversos processos
envolvidos na entrega do servio, tais como: Gerncia de Capacidade, Gerncia de
Continuidade e Disponibilidade do Servio, Gerncia do Nvel de Servios, Relato de
Servios, Segurana da Informao, Oramento e Contabilizao de Servios. No
caso do modelo CMMI-SVC [CMMI Product Team, 2010], existe a rea de processo
especfica de Entrega de Servios (Service Delivery SD).
O processo de Entrega de Servios tem como foco:
Garantir que existe uma abordagem (polticas, diretrizes etc.) documentada
para a entrega e a operao dos servios;
Garantir que todos os elementos (infraestrutura, recursos etc.) necessrios
para o fornecimento dos servios estejam disponveis;
Garantir que o sistema de fornecimento de servios, automatizado ou no,
esteja em operao ou pronto para entrar em operao;
Garantir que o sistema de fornecimento dos servios sofre manutenes
peridicas para manter a continuidade das entregas dos servios acordados.
O processo de Entrega de Servios est diretamente relacionado com o processo de
Gerncia de Incidentes (GIN) e Gerncia de Nvel de Servio (GNS).

9.3.1 ETS 1 - Uma abordagem para entrega e operao de servios

estabelecida e mantida
O processo de Entrega dos Servios (ETS) comea com a definio de uma

abordagem para a entrega e operao dos servios, ou seja, a organizao deve
estabelecer polticas, diretrizes e procedimentos para receber e tratar as solicitaes
de servios ao longo de todo o seu ciclo de vida, at a sua concluso. Isto inclui
procedimentos para registro, priorizao, tratamento, escalonamento, resoluo e
comunicao para as partes interessadas.
Este resultado tem relacionamento direto com o resultado GIN 1 do processo de
Ger b
solicitao de servio e b .
9.3.2 ETS 2 - A disponibilidade dos elementos necessrios para a prestao
do servio confirmada
Antes que o servio comece a ser prestado, importante que todos os itens
necessrios para o fornecimento do servio estejam disponveis e em operao.
Entende-se por itens necessrios, todos aqueles identificados no trabalho do
servio, tais como: servidores, computadores, impressoras, unidades de disco, redes
de telecomunicaes, materiais de consumo, infraestrutura fsica, instalaes,
softwares, recursos humanos etc.
Dependendo do tipo do servio e do ambiente em que ele est sendo executado,
esta confirmao da prontido para entrega pode ser confirmada por meio de
ferramentas automticas de monitoramento. Isto inclui, por exemplo, ferramentas de
monitoramento de servidores, bancos de dados, backup, logs, antivrus, entre
outras.
9.3.3 ETS 3 - O sistema de servios colocado em operao para entregar os
servios acordados
Um sistema de servios pode ser compreendido como sendo um conjunto de tudo o

que necessrio para operar o servio.
Por exemplo, no caso de um servio de monitoramento de servidores, o sistema
pode incluir a ferramenta que realiza o monitoramento, as formas de
acompanhamento e emisso de alertas, a equipe que far o tratamento das
ocorrncias, os procedimentos de trabalho etc. No caso de um curso ou treinamento
distncia, podem ser as salas de aula virtuais disponibilizadas aos alunos.
Colocar o sistema de servios em operao significa realizar as atividades para que
a entrega do servio ocorra de acordo com o que est estabelecido nos ANSs.
9.3.4 ETS 4 - A manuteno do sistema de servios realizada para garantir a
continuidade da entrega dos servios
Quando se considera que os servios referem-se disponibilizao de infraestrutura

de TI, entende-se que o sistema de servios seja todo o conjunto necessrio para a

prestao do servio o que pode incluir: equipamentos, softwares,
telecomunicaes, pessoas etc. Manter o sistema de servios realizar alteraes
em qualquer um dos elementos, sempre que seja necessrio de modo que a
continuidade da entrega seja garantida. Esta manuteno pode ser preventiva,
corretiva, adaptativa ou perfectiva. Para essas manutenes, todo o procedimento
de parada, se necessrio, dever ser adequadamente planejado, monitorado,
controlado e comunicado aos envolvidos. Os ANSs devem ser analisados para
garantir que no sejam impactados por essas paradas. comum que estas paradas
j sejam previstas no prprio ANS.
Para alguns tipos de servios, as manutenes podem ser evidenciadas por meio de
reviso de procedimentos e manuais, treinamentos/qualificao de pessoal interno,
revises em processos de entrega dos servios etc.
Este resultado tem relacionamento direto com os processos de Gerncia de
Mudanas (GMU), Gerncia de Capacidade (GCA) e Gerncia de Continuidade e
Disponibilidade dos Servios (GCD).
10 Os atributos de processo no nvel G
De acordo com o Guia Geral de Servios (MR-MPS-SV), 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-SV, medida que a organizao/unidade
organizacional evolui nos nveis de maturidade, um maior nvel de capacidade para
desempenhar o processo deve ser atingido [SOFTEX, 2012a].
, , q v v , j ,
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
F q b v [SOFTEX, 2012a]. No
que se refere aos atributos de processo, para atingir o nvel G do MR-MPS, uma
organizao deve atender aos resultados esperados RAP1 a RAP10. Numa
avaliao, segundo o MA-MPS , exigido, para se considerar um processo
T F T v , q b . j
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, 2013i].
A seguir, os atributos de processo AP 1.1 e AP 2.1, conforme aplicveis no nvel G,
so descritos com detalhes.
10.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:
10.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.
10.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:
10.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-SV, 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
h v b x . U v
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.
10.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.

10.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 trabalho, quando aplicvel.
10.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 trabalho (servio).
10.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, atendentes etc.
10.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.
10.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.
10.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.
10.2.9 RAP10 - (Para o nvel G) O processo planejado para o trabalho
executado
O objetivo deste resultado garantir que o trabalho 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 trabalho.

Referncias bibliogrficas
[CATER-STEEL, TOLEMANN, TAN, 2006] CATER-STEEL A., TOLEMANN, M.,

TAN, W. Transforming IT service Management the ITIL Impact. IN: 17th
Australasian Conference on Information Systems 6-8 Dec, Adelaide, Australia, 2006.
[CMMI Product Team, 2010] CMMI PRODUCT TEAM, CMMI for Services - Version
1.3, Software Engineering Institute, Carnegie Mellon University, Pittsburgh,
Pennsylvania, Technical Report CMU/SEI-2010-TR-034, 2010. Disponvel em:
http://www.sei.cmu.edu/library/abstracts/reports/10tr034.cfm.
[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, 2008] INTERNATIONAL ORGANIZATION FOR STANDARDIZATION/
INTERNATIONAL ELECTROTECHNICAL COMISSION. ISO/IEC 12207:2008
Systems and software engineering Software life cycle processes, Geneve:
ISO, 2008.
INTERNATIONAL ELECTROTECHNICAL COMISSION. ISO/IEC 20000-2:2012
Information Technology Service Management. Part 2: Guidance on the
application of service management systems, Geneve: ISO, 2012.
INTERNATIONAL ELECTROTECHNICAL COMISSION. ISO/IEC TR 20000-4:2010
Information Technology Process Reference Model. Part 4: Service
Management Systems Requirements, Geneve: ISO, 2010.
INTERNATIONAL ELECTROTECHNICAL COMISSION. ISO/IEC 20000-1:2011
Information Technology Service Management. Part 1: Service Management
Systems Requirements, Geneve: ISO, 2011.
[KRUCHTEN, 2003] KRUCHTEN, P., The Rational Unified Process: An
Introduction, 3a Edio, Addison-Wesley Object Technology Series, 2003.
[ORAND, 2013] ORAND, B. Foundations of IT Service Management with ITIL 2011.
2nd Ed. San Bernardino, CA: ITILyaBrady, 2013.
[PMI, 2012] PROJECT MANAGEMENT INSTITUTE - PMI. A Guide to the Project
Management Body of Knowledge - PMBOK, Syba: PMI Publishing Division,
2012. Disponvel para associados do PMI em: <www.pmi.org>.
[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.
[SOFTEX, 2012a] - ASSOCIAO PARA PROMOO DA EXCELNCIA DO
SOFTWARE BRASILEIRO SOFTEX. MPS.BR Guia Geral MPS de
Servios:2012, agosto 2012. Disponvel em www.softex.br
[SOFTEX, 2012b] - ASSOCIAO PARA PROMOO DA EXCELNCIA DO
SOFTWARE BRASILEIRO SOFTEX. MPS.BR Guia Geral MPS de
Software: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
- -
- - - - -
- - : 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.
[SOFTEX, 2013a] ASSOCIAO PARA PROMOO DA EXCELNCIA DO
SOFTWARE BRASILEIRO SOFTEX. MPS.BR Guia de Aquisio:2013,
setembro 2013. Disponvel em: www.softex.br.
[SOFTEX, 2013b] ASSOCIAO PARA PROMOO DA EXCELNCIA DO
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,
setembro 2013. Disponvel em: www.softex.br. 3
[SOFTEX, 2013j] ASSOCIAO PARA PROMOO DA EXCELNCIA DO
1: Fundamentao para Implementao do Nvel G do MR-MPS-SV:2012,
[TSO, 2011a] THE STATIONARY OFFICE TSO. ITIL Service Operation, 2011.
Disponvel em www.best-management-practice.com.
[TSO, 2011b] THE STATIONARY OFFICE TSO. ITIL Service Design, 2011.
Disponvel em www.best-management-practice.com.
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:2013
Editores:
Ana Ceclia Zabeu ASR Consultoria
Renato Ferraz Machado QualityFocus
Sheila Reinehr PUCPR e QualityFocus
Revisores:
Ana Liddy Cenni de Castro Magalhes UFMG e QualityFocus

Ana Regina Rocha COPPE/UFRJ
Gleison Santos UNIRIO

Guia de Implementacao SV Parte 1 2013

Caricato da

Informazioni sul documento

Titolo originale

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

Guia de Implementacao SV Parte 1 2013

Caricato da

Copyright:

Formati disponibili

MPS.

BR - Melhoria de Processo do Software Brasileiro

Guia de Implementao Parte 1: Fundamentao para

Este guia contm orientaes para a

MR-MPS-SV Guia de Implementao Parte 1:2013 2/52

O MPS.BR1 um programa mobilizador, de longo prazo, criado em dezembro de

MR-MPS-SV Guia de Implementao Parte 1:2013 4/52

As mudanas que esto ocorrendo nos ambientes de negcios tm motivado as

MR-MPS-SV Guia de Implementao Parte 1:2013 5/52

O Guia de Implementao de Servios fornece orientaes para implementar nas

4 Comeando a implementao do MR-MPS-SV pelo nvel G

O nvel G o primeiro nvel de maturidade do MR-MPS-SV. Sua implementao

5 Gerncia de Trabalhos (GTR)

O propsito do processo Gerncia de Trabalhos estabelecer e manter planos

O PMI (Project Management Institute), um dos mais conceituados e reconhecidos

MR-MPS-SV Guia de Implementao Parte 1:2013 10/52

5.3.1 GTR1 - O escopo do trabalho definido

O escopo do trabalho define todo o trabalho necessrio, e somente ele, para

O escopo do trabalho, identificado na forma dos seus principais produtos e tarefas,

MR-MPS-SV Guia de Implementao Parte 1:2013 11/52

O ciclo de vida de um projeto consiste de fases e atividades que so definidas de

MR-MPS-SV Guia de Implementao Parte 1:2013 12/52

As estimativas de esforo e custo so, normalmente, baseadas nos resultados de

Quando os servios so de fornecimento contnuo, o Plano de Trabalho

Riscos so situaes de incerteza que podem adquirir conotao positiva

O planejamento de recursos humanos determina funes, responsabilidades e

Este resultado faz referncia obrigatoriedade de se planejar os recursos e o

MR-MPS-SV Guia de Implementao Parte 1:2013 16/52

Os dados do trabalho so as vrias formas de documentao exigidas para sua

MR-MPS-SV Guia de Implementao Parte 1:2013 17/52

MR-MPS-SV Guia de Implementao Parte 1:2013 18/52

A anlise da viabilidade no caso de servios compreendida de duas formas:

MR-MPS-SV Guia de Implementao Parte 1:2013 19/52

Para obter o compromisso dos interessados relevantes, importante revisar o

MR-MPS-SV Guia de Implementao Parte 1:2013 20/52

O objetivo deste resultado esperado garantir que o trabalho seja monitorado em

MR-MPS-SV Guia de Implementao Parte 1:2013 22/52

No decorrer da execuo, novos riscos podem ser identificados e os parmetros dos

Devem ser identificados os interessados relevantes, em que fases eles so

MR-MPS-SV Guia de Implementao Parte 1:2013 23/52

Revises em marcos do trabalho no devem ser confundidas com o

MR-MPS-SV Guia de Implementao Parte 1:2013 24/52

As atividades de reviso em marcos (GTR17) e de monitoramento (GTR13, GTR14

Como resultado do acompanhamento do trabalho (GTR13, GTR14 e GTR15) e das

MR-MPS-SV Guia de Implementao Parte 1:2013 25/52

O propsito do processo Gerncia de Requisitos gerenciar os requisitos do

Uma boa comunicao com os fornecedores de requisitos fundamental para

MR-MPS-SV Guia de Implementao Parte 1:2013 26/52

6.3.1 GRE1 - O entendimento dos requisitos obtido junto aos fornecedores

O objetivo deste resultado garantir que os requisitos estejam claramente definidos

MR-MPS-SV Guia de Implementao Parte 1:2013 28/52

Este resultado indica a necessidade de se estabelecer um mecanismo que permita

A consistncia entre os requisitos e os produtos gerados pelo trabalho deve ser

MR-MPS-SV Guia de Implementao Parte 1:2013 30/52

Durante a execuo do trabalho, os requisitos podem mudar por uma srie de

MR-MPS-SV Guia de Implementao Parte 1:2013 31/52

O propsito do processo Gerncia de Incidentes restaurar os servios

No mbito do modelo MR-MPS-SV optou-se pelo tratamento conjunto, ou seja, no

MR-MPS-SV Guia de Implementao Parte 1:2013 32/52

MR-MPS-SV Guia de Implementao Parte 1:2013 33/52

7.3.1 GIN 1 - Uma abordagem para o gerenciamento de incidentes e

A organizao deve estabelecer polticas, diretrizes e procedimentos para o

Um sistema de gerenciamento e controle de incidentes e solicitao de servios