Guia de Implantao da Gerncia de Riscos em

Micro e Pequenas Empresas alinhado ao CMMISE/SW

Elton Sanders
Christiane Gresse von Wangenheim

Relatrio Tcnico LQPS001.06P

Copyright 2006 LQPS - Laboratrio de Qualidade e Produtividade de Software

Universidade do Vale do Itaja - UNIVALI Centro de Educao So Jos

Todos os direitos reservados. Nenhuma parte deste documento pode ser

reproduzida, distribuda ou utilizada com fins comerciais sem a prvia autorizao
dos autores.
Ttulo Guia de Implantao da Gerncia de Riscos em Micros e
Pequenas Empresas alinhado ao CMMI-SE/SW
No. LQPS001.06P
Data 02.05.2006
Verso Final
Distribuio Pblica

LQPS - Laboratrio de Qualidade e Produtividade de Software

Universidade do Vale do Itaja - UNIVALI - Centro de Educao So Jos
So Jos/SC, Brasil

Lista de Acrnimos
GP Prtica Genrica do CMMI-SE/SW (Generic Practice)
GG Objetivo Genrico do CMMI-SE/SW (Generic Goal)
SP Prtica Especfica do CMMI-SE/SW (Specific Practice)
GP Objetivo Especfico do CMMI-SE/SW (Specific Goal)
PA rea de Processo do CMMI-SE/SW (Process Area)
RCO Repositrio de Conhecimento da Organizao

Sumrio
1 Introduo ........................................................................................................................... 5
1.1 estrutura do documento ................................................................................................ 5
2 Viso Geral sobre o Modelo CMMI-SE/SW ......................................................................... 6
2.1 Gerncia de Riscos no CMMI-SE/SW ........................................................................... 9
3 Contexto: Micro e Pequenas Empresas............................................................................. 13
3 Contexto: Micro e Pequenas Empresas............................................................................. 13
4 Guia de Implantao da Gerncia de Riscos em MPEs..................................................... 20
4 Guia de Implantao da Gerncia de Riscos em MPEs..................................................... 20
4.1 Conceitos fundamentais ............................................................................................. 20
SG 1 Preparar para a gerncia de risco......................................................................... 21
SP 1.1 Determinar as fontes de riscos e categorias ................................................... 21
SP 1.2 Definir parmetros de riscos........................................................................... 26
SP 1.3 Estabelecer uma Estratgia de Gerncia de Riscos ....................................... 29
SG 2 Preparar para a gerncia de risco......................................................................... 31
SP 2.1 Identificar Riscos ............................................................................................ 31
SP 2.2 Avaliar, Categorizar e Priorizar Riscos ........................................................... 35
SG 3 Mitigar Riscos ....................................................................................................... 37
SP 3.1 Desenvolver planos de mitigao de riscos .................................................... 37
SP 3.2 Implementar planos de Mitigao de Riscos .................................................. 40
5 Anlise de Ferramentas..................................................................................................... 48
5.1 Critrios para a anlise de ferramentas ...................................................................... 48
5.1 TRIMS ............................................................................................................................ 49
5.2 RISK RADAR ................................................................................................................. 51
5.3 MS Project 2003 ............................................................................................................. 53
5.4 RiskFree ......................................................................................................................... 54
5.5 RISK+ ............................................................................................................................. 55
5.6 Comparao entre as ferramentas ................................................................................. 56
6 Exemplo ............................................................................................................................ 58
7 Concluso ......................................................................................................................... 76
Referncias Bibliogrficas .................................................................................................... 77
Anexo A Taxonomia de Riscos genrica para projetos de Software [DIR06] ..................... 82
Anexo B Taxonomia de riscos baseada em questionrio [CARR93] .................................. 93
Anexo C Os 10 principais riscos em projetos de software [BOEHM91] ............................ 107
Anexo D Taxonomia de Riscos [JONES94] ..................................................................... 108
Anexo E Taxonomia de Riscos [LEOPOLDINO04] .......................................................... 113
Anexo F Questionrio de de Riscos [THOMSETT02] ...................................................... 115
Anexo G Taxonomia de Riscos para projetos de manuteno [OLIVEIRA06] ................. 117
Anexo H Riscos identificados na modernizao de sistemas legados [SANTOS04] ........ 119
Anexo I Taxonomia de Riscos [MACHADO02] ................................................................ 120
Anexo J Templates usados na gerncia de riscos do Guia .............................................. 122

1 Introduo
Muitas empresas de desenvolvimento de software no esto preparadas para lidar com as
incertezas que podem acontecer durante um projeto de software, e caso as empresas no
lidem de forma apropriada, estas incertezas podem virar certezas. Segundo [HIGUEIRA96],
todas as reas englobadas por desenvolvimento de software so fontes de incerteza, por
exemplo, incerteza quanto tecnologia escolhida, incerteza quanto ao desempenho de
hardware, incerteza sobre a funcionalidade do software, incerteza quanto capacidade e
disponibilidade das pessoas ou incerteza quanto ao custo e o cronograma definido do
projeto. Estas incertezas so conhecidas como riscos, e caso estes riscos aconteam,
podem influenciar nos objetivos. A gerncia de riscos em projetos de software pode auxiliar
a empresa a identificar e controlar estes riscos, minimizando o impacto do risco sobre o
projeto, ou eliminando a incerteza do projeto.
Em micro e pequenas empresas de software (MPE) brasileiras, pouca ateno dada
gerncia de riscos [MCT05]: apenas 1,4% de micro empresas e 2,2% de pequenas
empresas possuem atividades de gerncia de risco. Segundo Boehm [BOEHM91], a falta de
gerncia de risco aumenta a chance de riscos realmente acontecerem, impactando
negativamente nos objetivos do projeto e no desempenho da MPE. Muitos destes problemas
poderiam ser evitados ou fortemente reduzidos se existisse um comprometimento em
identificar e resolver os elementos de alto risco destes projetos, pois frequentemente estes
projetos so levados por uma onda de otimismo, deixando passar sinais de riscos que
podem levar ao trmino prematuro do projeto.
A gerncia de risco abordada em modelos de referncia de software como o PMBOK
[PMI04] e o CMMI-SE/SW [SEI01]. No contexto do CMMI-SE/SW em estgios a rea de
processo de gerncia de riscos faz parte do nvel de maturidade 3. No modelo continuo esta
rea de processo includa no grupo de processos da gerncia de projetos. As duas
representaes do CMMI-SE/SW apresentam um conjunto de prticas especificas da
gerncia de riscos, que abordam cada uma das etapas do processo de gerncia de riscos.
Neste contexto, o presente projeto visa o desenvolvimento de um guia de implantao da
rea gerncia de riscos alinhado ao CMMI-SE/SW voltado especificamente a MPEs que
permita que estas gerenciem de forma ordenada os seus riscos e criem uma base para
planejar, monitorar e controlar os projetos de software. E desta forma oferecendo um
suporte para o sucesso e a competitividade destas empresas no mercado.
Este guia apresenta tcnicas e ferramentas para ajudar o responsvel pela gerncia de
riscos no projeto de software a tratar os riscos, organizadas por prtica especfica da
gerncia de risco segundo o CMMI-SE/SW.

1.1 Estrutura do documento

O captulo 2 apresenta uma viso geral do CMMI-SE/SW, e as reas de processo onde o
CMMI-SE/SW faz referncia a atividades de gerncia de riscos.
O captulo 3 apresenta uma viso geral das micro e pequenas empresas de software no
Brasil em relao a gerncia de riscos.
O captulo 4 apresenta as tcnicas e mtodos da gerncia de risco, organizadas por prtica
especifica do CMMI-SE/SW.
O captulo 5 apresenta ferramentas que podem auxiliar nas atividades de gerncia de risco.
O captulo 6 apresenta um exemplo de execuo da gerncia de risco utilizando este guia.

2 Viso Geral sobre o Modelo CMMI-SE/SW

O modelo Capability Maturity Model Integration - CMMI foi desenvolvido pelo SEI (Software
Engineering Institute) [SEI01] sendo uma evoluo do modelo CMM. O propsito do CMMI
fornecer um guia para melhorar os processos de uma organizao e a sua habilidade de
gerenciar o desenvolvimento, a aquisio e a manuteno de produtos ou servios.
O modelo CMMI-SE/SW apresenta duas representaes: a representao em estgios e a
representao contnua. Na representao contnua, o modelo CMMI-SE/SW apresenta 22
reas de processos (Proces Area - PA) organizadas em quatro categorias (vide Figura 1).
PAs de Gerncia de Processo:
OPF: Foco no Processo Organizacional
OPD: Definio do Processo
Organizacional
OT: Treinamento Organizacional
OPP: Desempenho do Processo
Organizacional
OID: Inovao e Melhoria Organizacional
PAs de Gerncia de Projeto:
PP: Planejamento de Projeto
PMC: Monitorao e Controle de Projeto
SAM: Gerncia de Acordos com
Fornecedores
IPM: Gerncia Integrada de Projeto
RSKM: Gerncia de Risco
QPM: Gerncia Quantitativa de Projeto

PAs de Engenharia:
REQM: Gerncia de Requisitos
RD: Desenvolvimento de Requisitos
TS: Soluo Tcnica
PI: Integrao de Produto
VER: Verificao
VAL: Validao
PAs de Apoio:
CM: Gerncia de Configurao
PPQA: Garantia da Qualidade de Processo e Produto
MA: Medio e Anlise
DAR: Anlise de Deciso e Resoluo
CAR: Anlise de Causa e Resoluo

Figura 1 - reas de Processo do CMMI-SE/SW [SEI01]

Na representao em estgios, as reas de processo so organizadas em cinco nveis de

maturidade, indicando quais reas de processo devem ser implementadas para atingir cada
nvel de maturidade (Figura 2).
Nvel 5:
Otimizando
OID, CAR
Nvel 4: Gerenciado
Quantitativamente
OPP, QPM
Nvel 3: Definido
RD, TS, PI, VER, VAL, OT, OPF,
OPD, IPM, RSKM, DAR
Nvel 2: Gerenciado
REQM, PP, PMC, SAM, MA, PPQA,CM
Nvel 1: Inicial

Figura 2 - Nveis de Maturidade da representao em estgios [SEI01]

Os nveis de maturidade representam um caminho de melhoria de processo ilustrando a

evoluo de melhoria para a unidade de organizao visando a melhoria de processo. Nesta
representao o resultado de uma avaliao do processo de software apresenta o nvel de
maturidade de uma unidade de organizao como um todo. Quanto maior o nvel de uma
organizao mais madura ela considerada.
Cada rea de processo do CMMI-SE/SW possui objetivos especficos (Specific goals SG)
e prticas especficas (Specific Practices - SP). Por meio das prticas especficas que so
alcanados os objetivos especficos de cada rea de processo, capacitando a organizao
na rea de processo. Um objetivo especfico (SG) descreve as caractersticas que devem
estar presentes para satisfazer uma rea de processo. Uma prtica especfica (SP) a
descrio de uma atividade que considerada importante para se alcanar o objetivo
especfico a ela associado.
Alm dos objetivos e prticas especficas, as reas de processo possuem objetivos
genricos (GG) e prticas genricas (SG). So chamadas de genricas porque possuem
caractersticas comuns por todas as reas de processo de um nvel de maturidade. Por
exemplo, as reas de processo do nvel 2 apresentam o mesmo objetivo genrico GG2
Institucionalizar um processo gerenciado, e as reas de processo do nvel 3 apresentam o
mesmo objetivo genrico GG3 Institucionalizar um processo definido. A Figura 3 mostra a
relao entre as reas de processo e as SG, SP, GG e SP na representao por estgios.

Nveis
de Levels
Maturidade
Maturity

Process
rea
de Processo
Area 1
1

Process
rea
de Processo
Area 2
2

Objetivos
Specific
Especficos
Goals

Process
rea
de Processo
Area n n

Generic Goals
ObjetivosGenricos

Caractersticas Comuns
Commitment
Compromisso
to Perform

Ability
Habilitao
to Perform

Directing
Implementao
Implementation
Implementation

Verifying da
Verificao
Implementation
Implementao

Specific
Prticas Practices
Especficas

Generic Practices
Prticas
Genricas

Figura 3 - Componentes da representao por estgios do modelo CMMI-SE/SW [SEI01]

A representao contnua do modelo CMMI-SE/SW utiliza os mesmos elementos da

representao por estgios (Figura 4), porm apresenta uma estrutura bidimensional,
separando a dimenso do processo (reas de processo) da dimenso da capacidade (nveis
de capacidade).

Nveis
deLevels
Maturidade
Maturity

Process
rea
de Processo
Area 1
1

Process
rea
de Processo
Area 2
2

Objetivos
Specific
Especficos
Goals

Specific
Prticas Practices
Especficas

Process
rea
de Processo
Area n n

Generic Goals
ObjetivosGenricos

Nveis de
Capacidade

Prticas Genricas

Figura 4 Componentes da representao contnua do modelo CMMI-SE/SW [SEI01]

Para indicar o nvel de capacidade, que cada rea de processo se encontra, so utilizados
os objetivos genricos (GG). Para cada nvel de capacidade, existe apenas um objetivo
genrico.
Assim, o modelo permite selecionar, de forma mais flexvel, um subconjunto de reas de
processo e respectivos nveis de capacidade para cada uma.

Nvel de Capacidade

A dimenso de capacidade organizada em seis nveis de capacidade (0 5), que indicam

a habilidade de uma organizao executar, controlar e melhorar uma determinada rea de
processo. Na representao contnua so gerados perfis de processos (Figura 5), contendo
as reas de processo mais relevantes da organizao e indicado o nvel de capacidade de
cada rea de processo especfica. Dessa forma possvel direcionar a melhoria apenas
para as reas de processo consideradas mais relevantes no contexto organizacional.

5 Otimizao
4 Gerenciado Quantitativamente
3 Definido
2 Gerenciado
1 Executado
0 Incompleto
OPF OPD
Processos avaliados

...

PP

...

Figura 5 - Perfis de Processo

Alm dos GG, GP, SG e SP, as duas representaes do modelo CMMI-SE/SW utilizam os
seguintes componentes informativos para direcionamento da implementao:

Sub-prticas (Subpractices) so descries detalhadas que provm mais informaes

sobre as prticas. Por exemplo, a prtica pode ser escrever um plano de projeto. E as
sub-prticas podem informar o que deve constar dentro do plano.

Produtos tpicos de trabalho (Typical Work Products) cada rea de processo prov
exemplos de documentos, templates e outras sadas que so tpicas na rea de
processo;

Diretrizes de adaptao so utilizadas para possibilitar que as organizaes

implementem processos padro de maneira adequada a seus projetos. O conjunto de
processos padro da organizao descrito em um nvel geral que no pode ser
diretamente til para executar o processo.

Exemplos so apresentados em todas as reas de processo para auxiliar o

entendimento;

Elaboraes das prticas genricas oferece informaes sobre como a prtica

genrica dever ser interpretada para a rea de processo. Se no existir uma
elaborao, a aplicao da prtica genrica considerada bvia.

2.1 Gerncia de Riscos no CMMI-SE/SW

O CMMI-SE/SW aborda a gerncia de riscos principalmente por meio da rea de processo
de Gerencia de Riscos. No contexto do CMMI-SE/SW em estgios a rea de processo de
gerncia de riscos faz parte do nvel de maturidade 3. No modelo continuo esta rea de
processo includa no grupo de processos da gerncia de projetos.
Porm, a gerncia de riscos est tambm sendo considerada por meio de uma prtica
especfica na rea de processo de Planejamento de Projeto, e na rea de processo de
Monitorao e Controle, ambas associadas ao nvel 2 de maturidade na representao em
estgios. A rea de processo Planejamento do Projeto, inclui o SG3 Desenvolvimento do
Plano do Projeto com a SP2.2 Identificar os Riscos do Projeto, que consiste na identificao
e na anlise dos riscos para se determinar o impacto, a probabilidade de ocorrncia e o
perodo em que podem ocorrer, para que os riscos possam ser priorizados. Na Monitorao
e Controle do Projeto, tem-se o SG1 Monitorar o Projeto de Acordo com o Plano, onde est
inserida a SP1.3 Monitorar os Riscos do Projeto, que consiste na monitorao de riscos que
foram identificados no projeto.
Assim, o modelo CMMI-SE/SW j no nvel 2 de maturidade, na gerncia de projetos,
comea a se preocupar com a gerncia de riscos, entretanto numa forma mais simples do
que no nvel 3 de maturidade, onde o modelo tem um foco bastante mais sistemtico nesta
rea por meio de uma rea de processo especfica voltado para a gerncia de riscos.
2.1.1 rea de processo de Gerncia de Risco
A gerncia de risco um processo contnuo e de previso, que uma parte importante dos
processos de gerenciamento tcnico e de negcios. A gerncia de riscos dever tratar as
questes que poderiam colocar em perigo o atendimento dos objetivos crticos. Uma
abordagem contnua da gerncia de risco aplicada para antecipar e mitigar, de forma
efetiva, os riscos que tm um impacto crtico no projeto [SEI01].
A gerncia de riscos de riscos inclui uma antecipada e agressiva identificao de riscos
atravs da colaborao e envolvimento dos stakeholders relevantes. Uma forte liderana
entre todos os stakeholders relevantes necessria para estabelecer um ambiente para
uma exposio e discusso livres e abertas sobre os riscos [SEI01].

Embora as questes tcnicas sejam preocupaes importantes tanto nas etapas iniciais
quanto em todas as fases do projeto, a gerncia de riscos deve considerar as fontes internas
e externas de riscos tcnicos, de custos e de cronograma. Uma deteco de riscos
antecipada e agressiva importante porque, normalmente, mais fcil, barato e causa
menos interrupes fazer mudanas e corrigir esforos de trabalho durante as fases iniciais,
que em fases posteriores do projeto [SEI01].
Conforme descrito no modelo CMMI-SE/SW, a gerncia de riscos pode ser dividida em trs
partes: definir uma estratgia de gerncia de riscos, identificar e analisar os riscos e tratar os
riscos identificados, incluindo a implementao de planos de mitigao de riscos, quando
necessrio.
A Figura 6 mostra o relacionamento entre as reas de processo do CMMI-SE/SW com
atividades de gerncia de risco.
Preparar para a Gerncia de Riscos
PP

Determinar
Fontes de
Riscos e
Categorias

Definir
parmetros
de riscos

Estabelecer
uma
estratgia
de gerncia
de riscos

Identificar e
analisar riscos

Identificar
Riscos

RISCOS

PMC
Implementa
r Planos de
Mitigao
de Riscos

Implementa
r Planos de
Mitigao
de Riscos

Avaliar,
Categorizar
e Priorizar
Riscos

Mitigar Riscos

Figura 6 Relacionamento entre as reas de processo PP e PMC com RSKM (Adaptado de

[AHERN03])

As reas de processo Planejamento do Projeto, e Monitorao e Controle do Projeto, nvel

2, tratam o gerenciamento de riscos de uma forma reativa, focando simplesmente na
identificao dos riscos para a conscientizao, e reao medida que ocorram. J o foco
da rea de processo Gerncia de Risco, nvel 3, voltado ao tratamento o gerncia de
riscos de uma forma pro-ativa, descrevendo a evoluo das prticas especficas para
sistematicamente planejar, antecipar, e mitigar riscos com o objetivo de minimizar seu
impacto no projeto.
Alm das reas de planejamento de projeto e monitorao e controle de projeto, a rea de
Anlise e Resoluo de Decises (associado ao nvel 3 de maturidade) prov um processo
formal de avaliao para todas as reas de processo, que garante que todas as alternativas
foram avaliadas e a melhor foi usada. Este processo de escolha usado na mitigao de

riscos. E a rea de processo de Soluo Tcnica prov solues tcnicas alternativas com a
finalidade tambm de mitigar riscos.
A Figura 7 mostra as atividades de gerncia de riscos nas reas de processo relacionadas.
Atividades
Identificar riscos
Analisar riscos

Controle e
Monitoramento
de Projeto

Monitorar riscos

Gerncia de
Riscos

Soluo Tcnica

Resoluo e
Anlise de
Deciso

Identificar parmetros de riscos

Estratgias formais para lidar c/ riscos
Planos de mitigao de riscos
Estruturao das avaliaes de riscos
Identificar, categorizar e analisar riscos
Solues Tcnicas para Riscos

Avalia decises e alternativas de soluo

GERNCIA DE RISCOS

Planejamento
do Projeto

Figura 7 - Atividades de gerncia de riscos nas reas de processo do CMMI-SE/SW [SEI01]

A rea de processo de Gerncia de Risco tem por finalidade identificar potenciais problemas
antes que ocorram. Desta forma, as atividades de tratamento destes riscos podem ser
planejadas e realizadas, de acordo com suas necessidades, ao longo do ciclo de vida do
produto ou projeto, para mitigar possveis impactos adversos.
A

Tabela 1 mostra os objetivos especficos e as prticas especficas e genricas da rea de

processo de gerncia de risco.

Tabela 1 Objetivos e prticas especficas e genricas da rea de processo da Gerncia de Risco

SG1

SG2

SG3

GG3

Preparao para a gerncia de riscos

SP1.1
Determinar fontes de riscos e categorias
SP1.2
Definir parmetros
SP1.3
Estabelecer uma estratgia de gerncia de riscos
Identificar e analisar riscos
SP2.1
Identificar riscos
SP2.2
Avaliar, categorizar e priorizar riscos
Mitigar riscos
SP3.1
Desenvolver planos de mitigao de riscos
SP3.2
Implementar planos de mitigao de riscos
Institucionalizar um processo definido
GP2.1
Estabelecer uma poltica organizacional
GP3.1
Estabelecer um processo definido
GP2.2
Planejar o processo
GP2.3
Fornecer recursos
GP2.4
Atribuir responsabilidades
GP2.5
Treinar as pessoas
GP2.6
Gerenciar configuraes
GP2.7
Identificar e envolver os stakeholders relevantes
GP2.8
Monitorar e controlar o processo
GP3.2
Coletar informaes e melhorias
GP2.9
Avaliar objetivamente a aderncia
GP2.10 Revisar o status com o nvel mais alto de gerncia

3 Contexto: Micro e Pequenas Empresas

As MPEs so, hoje, em todo o mundo e destacadamente no Brasil, um segmento dos mais
importantes, visto serem agentes de incluso econmica e social pelo acesso s
oportunidades ocupacionais e econmicas, tornando-se sustentculo da livre iniciativa e da
democracia, sendo responsvel pela esmagadora maioria dos postos de trabalho gerados
no Pas [SEBRAE05]. A Legislao Bsica da Micro e Pequena Empresa [SEBRAE06]
define uma MPE em relao receita bruta atual. Tambm existe a classificao do
SEBRAE [SEBRAE05] relativa a empresas de servios, que associa MPEs ao nmero de
empregados da empresa (Tabela 2). Este ser o critrio adotado por este trabalho para
definir uma MPE devido facilidade de se obter essa informao.
Tabela 2 - Classificao das empresas por porte [SEBRAE05]
Porte
Micro
Pequena
Mdia
Grande

Nmero de Empregados
At 9 pessoas
At 49 pessoas
At 99 pessoas
Acima de 99 pessoas

MPEs na economia brasileira representam 99% das empresas formalmente estabelecidas,

gerando 60% dos empregos formais e cerca de 20% do PIB [SEBRAE05]. No perodo de
1995 a 2000, foram criadas mais de 400 mil novas microempresas e que em relao a
novos postos de trabalho nos pequenos negcios o crescimento, no mesmo perodo, foi de
25,9%, correspondendo a 1,4 milhes de novos empregos, enquanto nas grandes empresas
o incremento foi de apenas 0,3%, no atingindo 30 mil novas contrataes [SEBRAE05].
De acordo com pesquisa realizada pelo [MCT05] com as empresas associadas ao SOFTEX,
cerca de 77% da fora efetiva das empresas de software no Brasil so micro e pequenas
empresas (Figura 8), demonstrando a importncia das MPEs no mercado nacional.
Grande
12.9%

Mdia
9.7%

Micro
35.7%

Pequena
41.7%

Figura 8 - Porte de empresas de software no Brasil [MCT05]

Quanto a idade, MPEs de Software so geralmente empresas muito novas, a maior parte
com menos de 15 anos de vida [MCT05], desta forma com pouca experincia acumulada.
Quanto ao tipo de produto, cerca de 98,6% de micro empresas e 99,4% das pequenas
empresas de software brasileiras desenvolvem software [MCT05], que podem chegar ao
mercado em pacote, servio ou embarcado [FREIRE02]:

Software pacote: geralmente padronizado e se caracteriza por no haver interao

direta entre o usurio e aqueles que desenvolvem o software durante a confeco do
produto. Desse modo, no existe um cliente exclusivo, o que significa que o software
deve estar apto a atender uma demanda bastante genrica, fazendo com que o produto
seja capaz de viver por si s, de forma independente. A comercializao usualmente
feita como produto de prateleira, sendo que as estratgias de marketing e vendas podem
ser similares s utilizadas pelos equipamentos de hardware. A competitividade dada
pela capacidade de desenvolvimento tcnico e de distribuio em massa, sendo que os
dispndios para a criao e o lanamento so altos, tendo realmente um carter mais
industrial. Assim, as empresas lderes
investem pesadamente em estratgias
agressivas de marketing, aproveitando as vantagens de economias de escala, rede de
vendas, suporte abrangente e marca reconhecida.

Software servio (ou por encomenda): aqueles programas desenvolvidos sob

encomenda, fruto normalmente de projetos solicitados por usurios, os quais
antecipadamente definem os traos gerais e especficos do desenvolvimento, desse
modo, possuindo um carter mais de servio do que de produto. Assim, a interatividade
entre usurio e os que o desenvolvem intrnseca ao processo de produo,
diferentemente do que acontece no software pacote. Como fator competitivo
preponderante esto no s o conhecimento das atividades como tambm das
necessidades dos clientes. Os riscos de mercado so menores, pois as vendas so
efetuadas antes, porm os custos de desenvolvimento so mais significativos.

Software embarcado: chegar ao mercado embutido em um equipamento. Atualmente,

todo equipamento automatizado traz consigo um software mesmo que simplificado
para operacionaliz-lo, o que torna a atividade de desenvolvimento desse tipo de
software uma das mais importantes e dinmicas.

Na Figura 9 e na Figura 10 apresentado um breve panorama do tipo de software produzido

por MPEs. So desenvolvidos diversos tipos de software, tanto em pacote, sob encomenda
e os embarcados.

Principais Tipos de Software Desenvolvidos por Micro Empresas

40.50%

Automao comercial

36.80%

Administrao de servios
30.00%

Gesto integrada - ERP

27.70%

Administrao - outros
22.30%

Automao industrial

21.40%

Automao de escritrios
Contabilidade
Ges to do relacionamento c/ cliente
Administrao de recursos humanos

19.50%
18.60%
16.80%
16.80%

Automao - outros
Comrcio eletrnico

15.50%

Figura 9 - Principais Tipos de Software Desenvolvidos por Micro Empresas [MCT05]

Principais Tipos de Software Desenvolvidos por Pequenas Empresas

28.70%

Gesto integrada - ERP

27.40%

Contabilidade

25.50%

Automao comercial

22.90%

Administrao - outros

22.30%

Administrao de recursos humanos

Administrao de servios
Gesto de processos organizacionais
Outros tipos de aplicao
Comrcio eletrnico
Ges to do relacionamento c/ cliente - CR
Automao industrial

21.00%
21.00%
20.40%
19.70%
19.70%
18.50%

Figura 10 - Principais Tipos de Softwares Desenvolvidos em Pequenas Empresas [MCT05]

Ainda segundo FREIRE [FREIRE02] os softwares podem ser agrupados conforme o tipo de
mercado em que se insere, dividindo-se em duas grandes categorias horizontal e vertical:

Segmento horizontal: produtos com contudo geralmente proviniente da rea de

informtica, com pouco contedo especfico de outra rea de conhecimento. Vendido em
forma de pacotes, precisa ser flexvel, pois tem como objetivo resolver problemas
informacionais bsicos comuns s mais diversas reas. So exemplos de produtos do

segmento horizontal os sistemas operacionais, as planilhas, os bancos de dados,

processadores de texto, entre outros.

Segmento vertical: produtos de uso restrito, abrangendo conhecimentos especficos de

outras reas alm da informtica, como sade, transportes, pesquisa, educao,
logstica, compras, estoques, entre outras, podendo ser vendido em forma de pacotes
ou, e principalmente, sob encomenda.

Considerando o conceito de segmento horizontal/vertical no mercado de softwares e o os

tipos de software desenvolvidos por MPEs possvel observar que h um concentrao no
mercado vertical, uma vez que as principais reas de atuao das MPEs so automao,
ERP e administrao, onde necessria embutir o conhecimento das empresas nos
softwares. Para Freire [FREIRE02] o baixo custo de desenvolvimento de programas para
estas reas e a menor complexidade relativa exigida para estes produtos, somados
fragmentao e crescimento constantes nessas reas, podem dar uma idia do por qu
dessa concentrao. Essas reas proporcionam o aparecimento de segmentos de mercado
especficos (automao de consultrios mdicos, livrarias, farmcias, videolocadoras),
abrindo oportunidades de atuao para as MPEs. Alm disso, a prpria estrutura que as
MPEs possuem, faz com que estas desenvolvam produtos de baixa complexidade que
necessitam de pouca mo de obra e tempo curto de projeto.
Nestes segmentos de mercado, os projetos se iniciam de maneira tmida, atendendo a
algumas funcionalidades iniciais requisitadas pelo cliente, facilitando a entrada da MPE no
mercado com pequenas equipes, baixo custo e um curto tempo de entrega da 1 verso do
produto. Depois so feitas constantes atualizaes incrementais no produto de forma a
atender a novas necessidades do cliente, e possibilitando amadurecer o produto e fornec-lo
a outras empresas do mesmo segmento [FREIRE02]

1. Cria produto
personalizado para o
cliente poucas
funcionalidades
atendidase estes

2. Atualizaes
constantes do produto
atendendo
necessidades do
cliente

3. Amadurecimento do
produto visando
atender outras
empresas

Figura 11 - Atuao de MPEs no mercado de Desenvolvimento de Software para empresas de

pequeno porte

Em consulta aos profissionais do Laboratrio de Qualidade e Pesquisa [LQPS06], algumas

MPEs fazem projetos de desenvolvimento de software sob encomenda, algumas fazem
pacotes, outras tem um produto padro customizvel, que adaptado para um cliente
especfico em pequenos projetos. Outras MPEs possuem projetos de manuteno contnua
ou desenvolvem software, porm vendem apenas o servio de manuteno.
Tipicamente, MPEs por terem um nmero reduzido de funcionrios, possuem equipes
pequenas, onde cada integrante da equipe assume diversos papis dentro do processo de
desenvolvimento e administrao da empresa, dividindo ora seu tempo em atividades
tcnicas, ora em atividades de administrao ou atividades organizacionais.
MPEs tambm apresentam uma srie de problemas de organizao interna causado por
excesso de informalidades de estrutura de organizao e do fluxo de informaes. Devido
falta de recursos, a empresa tem um enfoque em atividades externas, tais como terminar o
produto o quanto antes, promover o produto em atividades de marketing e vendas, criar
alianas estratgicas etc., no se dedicando com a ateno devida ao aperfeioamento do

processo de desenvolvimento, gerncia e qualidade. So ainda muito susceptveis a

influncias, sejam elas de investidores, clientes ou do prprio mercado. Desta forma, a
empresa se mantm em constante processo de ajuste daquilo que ela faz e de como faz.
Em relao gerncia de riscos, foco deste trabalho, pouca ateno dedicada a este tipo
de atividade em MPEs [MCT05]: apenas 1,4% de micro empresas e 2,2% de pequenas
empresas possuem atividades de gerncia de risco. Esta falta de gerncia de risco aumenta
a chance de riscos realmente acontecerem, impactando negativamente nos objetivos do
projeto e no desempenho da MPE. Muitos destes problemas poderiam ser evitados ou
fortemente reduzidos se existisse um comprometimento em identificar e resolver os
elementos de alto risco destes projetos, pois freqentemente estes projetos so levados por
uma onda de otimismo, deixando passar sinais de riscos que podem levar ao trmino
prematuro do projeto [BOEHM91]. Alm disto, as seguintes caractersticas das MPEs podem
lev-las a no executarem a gerncia de riscos [MARTENS01], [SEBRAE05], [ROVERE01]
[ROUILLER01], [KASSE04], [COLEMAN98]:

Dificuldade em insero no mercado As MPEs enfrentam dificuldades de insero

nos mercados que disputam, ambientes extremamente competitivos e globalizados; e
para conquist-los, precisam atender, simultaneamente, exigncia de preos, prazos,
qualidade e confiabilidade [MARTENS01]. Assim, as MPEs podem deixar de lado a
gerncia de riscos e demais processos, com o objetivo de gastar menos tempo e ter um
custo menor, correndo o risco de o produto no ter qualidade e confiabilidade.

A falta de recursos financeiros das MPEs - O uso de mquinas obsoletas

generalizado entre as MPEs devido s dificuldades que estas empresas encontram em
obter crdito, ficando mais sensveis aos ciclos econmicos, inibindo os esforos de
atualizao tecnolgica [SEBRAE05]. Assim, as MPEs podem no conseguir simular os
ambientes onde seus produtos esto instalados, com a finalidade de realizar testes de
benchmarketing para mitigar riscos, ou mesmo alocar recursos para gerenciar riscos.

Ambiente familiar - a baixa capacitao gerencial, que decorre do fato de que estas
empresas so em sua maioria familiares [ROVERE01]. Assim, as MPEs podem se
arriscar a no ter uma gerncia capacitada em resolver riscos, ou at mesmo que
encubra riscos em potenciais, por estarem relacionados a recursos de mo de obra da
prpria famlia.

Falta de capacitao gerencial - Alm disso, o tamanho reduzido das empresas faz
com que seus proprietrios/administradores tenham um horizonte de planejamento de
curto prazo, ficando presos num crculo vicioso onde a resoluo de problemas dirios
impede a definio de estratgias de longo prazo e de inovao [ROVERE01]. Assim, as
MPEs no enxergam oportunidades longo prazo, focando em aes de curto prazo,
por exemplo, demisso de mo de obra ou compra de equipamentos de menor custo,
porm com menor desempenho. Alm disso, esta caracterstica faz com que as MPEs
no possuam capacidade de avaliao de riscos de forma pr-ativa.

Falta de maturidade para atuar com novas tecnologias - A adoo de novas

tecnologias da informao pode provocar mudanas no comportamento e na estrutura
da MPE, no sistemas gerenciais, nas tcnicas e no domnio de processos adotados pela
empresa, causando grande impacto nas organizaes, devido a situaes novas
situaes a serem enfrentadas, que, muitas vezes, deixam os gerentes sem saber como
lidar com elas [MARTENS01]. Assim como novas tecnologias, novos processos de
gerncia de projetos tambm no so bem vistos em MPEs, tal como a prpria gerncia
de riscos, justamente por no estar no domnio dos gerentes, que normalmente se
limitam a ser o dono do negcio, realizando tarefas de alocao de recursos ou
relacionadas a pagamentos.

Multi-funcionalidade da mo de obra em MPEs A empresa no conta com pessoal

habilitado com conhecimentos tcnicos especficos na rea de TI, o que dificulta ainda
mais um melhor aproveitamento da tecnologia. Desta forma, o prprio empresrio tornase polivalente, passando a atender problemas de produo, de compras, de marketing
de vendas e de recursos humanos [MARTENS01]. Essa caracterstica faz com que o
gerente de projetos (que pode ser o prprio empresrio) possa no dispor de tempo
suficiente para aplicar a gerncia de riscos.

Precariedade na gerncia de projetos - os seguintes fatores agravam os problemas da

gerncia de projetos de software em MPEs [ROULLER01]: (1) Falta de formalizao de
procedimentos para gerncia e controle de projetos; (2) Inexistncia de um processo
definido; (3) Recursos pessoais e financeiros limitados; (4) Falta e/ou pouca cultura em
processos; (5) Pouco treinamento em engenharia de software; (6) Imaturidade
metodolgica; (7) Crescimento ocorrido por demanda; (8) Falta de experincia
administrativa por parte dos gerentes e diretores; (9) Falta de definio das metas
organizacionais. Todos estes fatores fazem com a execuo da gerncia de riscos seja
mais complicada pela falta da cultura organizacional em procedimentos definidos, e a
falta de planejamento pr-ativo, essencial para a gerncia de riscos.

Precariedade na gerncia de riscos - A falta de preparo para os momentos de impasse

demonstra que os gerentes das MPEs possuem dificuldades em gerenciar riscos, e
possivelmente enxergar novas oportunidades. Kasse [KASSE04] lista os seguintes
problemas na gerncia de riscos por parte dos gerentes: (1) Tendncia a gerenciar os
riscos que eles vem, e no todos os riscos ou os riscos crticos; (2) Tendncia a
gerenciar os riscos onde eles tm experincia; (3) Tendncia a realmente gerenciar para
custo e prazo os sintomas; (4) So normalmente recompensados por suas habilidades
em gerncia em situao de crise.

Tempo de entrega ao mercado - Segundo Kulpa & Johnson [KULPA03] o primeiro

dirigenciador do negcio para MPEs tempo de resposta ao mercado. Decises
precisam ser tomadas de forma rpida e dentro do prazo. Enquanto que o CMMI-SE/SW
promove a qualidade com o alongamento do processo usado para desenvolver e
entregar sistemas, as MPEs precisam entregar seus sistemas no tempo estimado do
mercado, preferindo a velocidade de entrega de qualidade ou funcionalidades do
sistema, deixando de lado a gerncia de riscos.

Ausncia de padro no ciclo de vida dos projetos - Segundo Coleman & Verbruggen
[COLEMAN98] as pequenas empresas possuem os seguintes problemas quanto a
ausncia de padres durante o ciclo de vida dos projetos: (1) Ausncia de um
documento padro de requisitos; (2) Ausncia de um documento padro para o projeto;
(3) Ausncia de padres para programao; (4) Ausncia de planos de programadores
para testes de unidade; (5) Ausncia de testes independente dos mdulos; (6) Ausncia
de documentao formal de erros; (7) Ausncia de documentao de solicitaes de
correes de erro e alteraes. Estes fatores dificultam a gerncia de riscos em MPEs,
uma vez que encontrar riscos na documentao gerada, conforme as melhores prticas
relatadas no CMMI-SE/SW, se torna um trabalho no repetitivo ao longo da vida da
empresa j que os projetos no possuem padro.

Estimativas irreais - Os gerentes de projetos em MPEs ao estimar, costumam basearse em estimativas passadas, mesmo sabendo que elas podem estar incorretas, e
tambm h gerentes que se recusam a estimar somente por julgarem perda de tempo,
uma vez que correm o risco de obterem resultados incorretos e, portanto, acharem que
esto desperdiando tempo [ROULLIER01]. Prazos irreais fazem com que processos
como a gerncia de risco, sejam descartados em funo da obteno do produto no

prazo estipulado (ou com pouco atraso), independente dos riscos volta do projeto,
resultando em uma baixa qualidade do produto final.
No prximo captulo apresentado o guia de implantao da gerncia de riscos em MPEs.
Este guia contextualizado com base nas caractersticas apresentadas das MPEs, de forma
a facilitar a implantao da gerncia de riscos em MPEs.

4 Guia de Implantao da Gerncia de Riscos em MPEs

Alinhado aos objetivos especficos e prticas especficas da rea de processo de gerncia
de riscos, este guia descreve a implantao da rea de processo de gerncia de riscos
especificamente voltado ao contexto de em Micro e Pequenas Empresas (MPEs).
Desta forma o presente guia fornece tcnicas, diretrizes, exemplos e templates de produtos
de trabalhos para a implementao de um processo de gerncia de riscos em conformidade
com as prticas especficas da reas de processo (PA) de Gerncia de Riscos do modelo
CMMI-SE/SW de forma adaptada para MPEs.

4.1 Conceitos fundamentais

A gerncia de riscos do projeto inclui os processos que tratam da realizao de
identificao, anlise, respostas, monitoramento e controle e planejamento da gerncia de
riscos em um projeto; a maioria desses processos atualizada durante todo o projeto
[PMI04].
O objetivo da gerncia de risco identificar os problemas em potencial antes que eles
ocorram, de forma que as atividades de tratamento de riscos possam ser planejadas e
invocadas, conforme necessrio, durante o ciclo de vida do projeto, para mitigar os impactos
adversos no atendimento dos objetivos do projeto [SEI01].
Risco a possibilidade de perigo, incerto, mas previsvel, que ameaa de dano pessoa ou
a coisa [MICHAELIS02]. No contexto de projetos de softwares, riscos so eventos ou
ocorrncias que impedem um projeto de alcanar seus objetivos de custo, cronograma e
desempenho [ENGERT99].
A gerncia de risco no contexto do CMMI-SE/SW considerada uma atividade contnua,
que deve ser executada durante todo o ciclo de vida de um projeto. Tipicamente a gerncia
de riscos composta das seguintes atividades [PMI04]:

Planejamento da gerncia de riscos

Identificao dos riscos

Anlise de riscos

Anlise qualitativa e quantitativa de riscos

Planejamento de resposta a riscos

Monitoramento e controle de riscos.

Desta forma, todas as atividades apresentadas neste guia formam uma nica iterao, mas
que devem ser repetidas durante todo o ciclo de vida do projeto, e seus resultados devem
ser armazenados em um Repositrio de Conhecimento da Organizao (RCO) para
consulta nas iteraes seguintes ou mesmo para consulta por outros projetos (vide Figura
12). O RCO pode ser elaborado, por exemplo, a partir de registros e documentos de
projetos, todas as informaes e a documentao relativas ao encerramento do projeto,
informaes sobre os resultados de decises a respeito da seleo de projetos anteriores e
informaes sobre o desempenho de projetos anteriores e informaes de esforo aplicado
para a gerncia de riscos.

Implementar Planos de
mitigao de riscos

Desenvolver planos de
mitigao de riscos

Aprender

Incio da 1
iterao

Determinar Fonte de Riscos e

categorias e definir parmetros

Repositrio
RCO

Identificar e analisar riscos

Estabelecer uma estratgia

de gerncia de riscos

Figura 12 Ciclo de atividades (iterao) do processo de gerncia de riscos

A seguir, so apresentados todos os objetivos especficos e prticas especficas do CMMISE/SW da rea de gerncia de riscos. Para cada uma das prticas, o guia descreve alm de
tcnicas e ferramentas alternativas que podem ser utilizadas para implementar estas
prticas de forma adaptada ao contexto de uma MPE.

SG 1 Preparar para a gerncia de risco

A preparao para a gerncia de risco conduzida.

SP 1.1 Determinar as fontes de riscos e categorias

Objetivo
O objetivo desta SP gerar um repositrio de fontes e categorias de risco [SEI01]:

Fontes de riscos so itens ou atividades com potencial para um impacto nos objetivos
do projeto. Fontes de riscos podem ser internas ou externas ao projeto. Exemplos so:
Requisitos incertos, esforos sem precedentes, design impossvel de ser implementado,
equipe com no capacitada etc.

Categorias de riscos fornecem um mecanismo para a coleta e organizao dos

riscos. Categorias podem ser baseadas nas fases do modelo de ciclo de vida do projeto
(por exemplo, riscos de requisitos, de design, de produo, de teste ou entrega), nos
tipos de processo (processo de desenvolvimento ou processo e mtodos de gerncia),
produtos utilizados (ferramentas de desenvolvimento), ou riscos do prprio projeto
(riscos de contrato, oramento, cronograma, desempenho).

A Figura 13 mostra o relacionamento entre as fontes e as categorias de riscos. As fontes

esto dentro das categorias de riscos, e dentro de uma mesma categoria podem ter fontes
internas e externas de riscos, e a Tabela 3 apresenta exemplos de categorias e fontes de
riscos.

Categoria de
Risco

Categoria de
Risco

Fontes Externas
Riscos de Oramento

Riscos de Recursos

Recursos financeiros

Fornecedores

Custos

Mo de Obra

Fontes Internas

Figura 13 - Relao entre fontes e categorias de riscos. Adaptado de [IRM02]

Tabela 3 - Categorias de Riscos de Software [CARR93]
A. Engenharia de Produto
1. Requisitos
a) Estabilidade
b) Completos
c) Clareza
d) Validade
e) Implementvel
f)
Histrico
g) Grau de Dificuldade
2. Design
a) Funcionalidade
b) Dificuldade
c) Interfaces
d) Desempenho
e) Testvel
f)
Restries de Hardware
g) Non-Developmental
1
Software
3. Codificao e Teste de Unidade
a) Implementvel
b) Testes
c) Codificao /
Implementao
4. Integrao e Teste
a) Ambiente
b) Produto
c) Sistema
5. Especialidades da Engenharia
a) Manutenibilidade
b) Disponibilidade
c) Proteo contra falhas
d) Segurana de Acesso
e) Fatores humanos
f)
Especificaes

B. Ambiente de Desenvolvimento
1. Processo de Desenvolvimento
a) Formalidade
b) Adequabilidade
c) Controle de Processo
d) Experincia
e) Controle de Produto
2. Ferramenta de Desenvolvimento
a) Capacidade
b) Adequabilidade
c) Usabilidade
d) Experincia
e) Disponibilidade
f)
Suporte Ferramenta
g) Entrega
3. Processo de Gerenciamento
a) Planejamento
b) Organizao do Projeto
c) Experincia em Gerncia
d) Interfaces do Projeto

C. Definies do Programa
1. Recursos
a) Programao
b) Equipe
c) Oramento
d) Facilidades
2. Contratos
e) Tipo de Contrato
f)
Restries
g) Dependncias
3. Interfaces de Programas
h) Cliente
i)
Parceiros
j)
Fornecedores
k) Contratos Principais
l)
Gerncia da Organizao
m) Fornecedores
n) Poltica

4. Mtodos de Gerenciamento
a) Monitorao
b) Gerenciamento de Pessoal
c) Garantia de Qualidade
d) Gerncia de Configurao
5. Ambiente de Trabalho
a) Atitude de Qualidade
b) Cooperao
c) Comunicao
d) Estado de Esprito

Non-Developmental Software tambm conhecido como softwares Drill-and-Practice, que um termo que
advm de uma teoria de aprendizado conhecida como comportamental. O foco desta teoria est na repetio
de novas habilidades at que essa habilidade seja incorporada ao indivduo. Feedback essencial, mas
oferecido de forma bem simples. Se o usurio que est aprendendo responder corretamente, e o feedback ser
ok ou uma luz verde, caso o usurio responder errado, no ser dado nenhum feedback, o usurio
simplesmente tem que tentar outra alternativa at o acerto.

A organizao poder determinar as fontes e categorias de risco durante a etapa de

planejamento do projeto. O planejamento do projeto visa definir e refinar os objetivos do
projeto, e planeja a ao necessria para alcanar os objetivos e o escopo para os quais o
projeto foi realizado. Mais informaes sobre o planejamento de projetos de software em
micro e pequenas empresas alinhado ao CMMI-SE/SW podem ser encontrado, por exemplo,
em [KUNTZE06].
As informaes do plano do projeto sero fundamentais para a identificao de fontes e
categorias de riscos que envolvem o projeto. Alm da consulta ao plano de projeto, a
organizao dever se basear nas prprias experincias anteriores, que podem ser
consultadas no Repositrio de Conhecimentos da Organizao (RCO), para obter mais
informaes sobre fontes e categorias de riscos utilizadas previamente por outros projetos
na organizao.
Este repositrio o local onde a organizao armazena as taxonomias de riscos, planos de
riscos (SP1.3), registro de riscos (SP2.1) e outros artefatos produzidos pela atividade de
gerncia de riscos dos projetos j executados ou em execuo.
Como ponto de partida para identificao de fontes e categorias de riscos de um projeto, a
organizao pode usar uma taxonomia de riscos. Taxonomias de riscos sintetizam
experincias passadas na execuo do processo de gerncia de riscos, com fontes e
categorias de riscos j caracterizadas. Estas taxonomias categorizam riscos ou em forma de
questionrios, com perguntas sobre o projeto (recursos humanos e materiais, fornecedores,
caractersticas da organizao, financeiros etc) ou em forma de checklist de riscos. Vrias
taxonomias genricas esto disponveis para consulta pblica. Algumas destas taxonomias
so apresentadas em anexo incluindo [DIR06], [CARR93], [JONES04], [BOEHM91],
[THOMSETT02], [LEOPOLDINO04] e [MACHADO02]. Estas taxonomias so genricas para
qualquer contexto, e podem ser usadas por qualquer projeto de software. Alm destas
taxonomias genricas, existem taxonomias voltadas para tipos especficos de projeto, como,
por exemplo, a taxonomia definida por [OLIVEIRA03], apresentada no anexo G, que
classifica reas de risco comuns em projetos de manuteno de software, e o anexo H, com
uma taxonomia que identifica riscos na modernizao de sistemas legados [SANTOS04].
importante ressaltar que estes taxonomias genricas foram desenvolvidas com base nas
experincias de vrias organizaes na prtica, mas que, mesmo assim, precisam ser
adaptadas ao contexto de uma organizao especfica para representar uma boa base para
a identificao de riscos, de forma totalmente adaptada ao contexto e as caractersticas
especificas de uma organizao, seus produtos, modelo de negcio e processos. Desta
forma, estas taxonomias podem ser utilizadas como ponto de partida, sendo revisadas
cuidadosamente e, com o passar do tempo, baseadas em dados objetivos coletados na
prpria organizao, acrescentando novas fontes de riscos ou eliminando fontes no
aplicveis.
Entretanto, importante que a organizao continuamente customize as prprias
taxonomias considerando suas caractersticas especificas, com base em dados histricos
sobre riscos observados em projetos passados na prpria organizao. Revisar a taxonomia
tem o objetivo de selecionar os riscos que so relevantes ao projeto especifico. Desta forma,
pode ser desenvolvido pela organizao, uma taxonomia de riscos para cada tipo de projeto,
visando facilitar a identificao de riscos especficos de um projeto, ou uma taxonomia
genrica da organizao, aplicvel a todos os projetos.
Atividades
Por meio das taxonomias de riscos possvel identificar quais fontes e categorias de riscos
pertencem. O primeiro passo da organizao selecionar todos os stakeholders que iro

participar das atividades de identificao de riscos (SP2.1), que pode incluir o gerente de
projetos, membros da equipe do projeto, equipe de gerenciamento de riscos (se designada),
especialistas no assunto de fora da equipe do projeto, clientes, usurios finais, outros
gerentes de projetos, partes interessadas e especialistas em gerenciamento de riscos
[PMI04].
Com os stakeholders selecionados, realizada uma reunio [PMI04] com o objetivo de
identificar as fontes e categorias de riscos pertinentes ao projeto e organizao. Nesta
reunio pode ser realizada uma reviso na taxonomia da organizao ou em taxonomias
disponveis para consulta pblica, de forma a obter mais informaes sobre novas
categorias e fontes de riscos aplicveis ao projeto ou organizao. Alm de tambm
descobrir categorias e fontes de riscos que deixaram de ser aplicveis ao projeto ou
organizao. A Figura 14 mostra um exemplo de apresentao da taxonomia de riscos para
o projeto.

Figura 14 - Exemplo de apresentao da taxonomia de riscos para o projeto [PMI04]

Algumas taxonomias (por exemplo, [THOMSETT02], [DIR06]), alm de categorias e fontes

de riscos, apresentam indicadores ou indcios de riscos que ajudam a identificar se a fonte
de risco ou a categoria ou no pertinente ao projeto, alm de tambm indicar o status
geral do risco no contexto do projeto (ver SP2.2). A Figura 15 mostra um exemplo de uma
taxonomia de riscos onde so apresentados indcios das fontes de risco. As fontes de riscos
encontradas so consolidadas em categorias existentes, ou novas categorias.

A definio das fontes e categorias de riscos a serem

usadas na taxonomia de riscos deve ser feita na 1 iterao.
Porm, a reviso e atualizao da taxonomia deve ser feita
em todas as iteraes, com o objetivo de adequar melhor a
taxonomia ao contexto da organizao.

Figura 15 - Taxonomia de Riscos [THOMSETT02]

Para manter a taxonomia de riscos atualizada, a organizao deve atualizar a taxonomia de

riscos sempre que:

Novas fontes de riscos, que no forem especficas do projeto, forem descobertas;

Fontes de riscos deixam de serem aplicveis a organizao;

Fontes de riscos mudam suas caractersticas.

A Figura 16 mostra um exemplo de template de taxonomia de risco que pode ser usado pela
organizao.
Taxonomia de riscos da organizao

Categoria
<< categoria
do risco>>

Fonte de
Risco
<< fonte de
risco dentro
da
categoria>>

Justificativa
<< justificativa
para ter includo
o risco dentro
desta categoria
>>

Tcnicas de
tratamento de
riscos
<< tcnicas que
podem ser
aplicadas para
tratar riscos
desta fonte de
riscos >>

Limites para monitorao

<< limites que podem ser
monitorados para verificar se
o risco est prximo, ou
aconteceu >>

Figura 16 Exemplo de Template de taxonomia de riscos

Procedimento de
medio
<< procedimentos de
coletar dados para
as mtricas que
podem ser usadas
para verificar se os
limites foram
atingidos >>

SP 1.2 Definir parmetros de riscos

Objetivo
O objetivo desta SP definir os parmetros utilizados para analisar e categorizar os riscos
(vide SP 2.2), e os parmetros utilizados para controlar o esforo da gerncia de riscos (vide
SP 3.1) [SEI01]. Estes parmetros so usados para comparar os riscos. Os parmetros para
a avaliao, categorizao e priorizao de riscos incluem:

Probabilidade de Riscos: Chance de um evento de risco acontecer [COOPER04]. Por

exemplo, a probabilidade pode ser medida em uma escala numrica de 0 a 1, ou em
percentuais (0%, 10%, 70% etc.), ou por meio de um escala ordinal, por exemplo:
remota, improvvel, provvel, altamente provvel, quase certa.

Impacto dos Riscos: Conseqncia de um evento de risco ao influenciar nos objetivos

do projeto [COOPER04]. O impacto pode ser medido da mesma forma que a
probabilidade, em uma escala numrica de 0 a 1, em percentuais (0%, 10%, 70% etc),
ou por meio de uma escala ordinal, por exemplo: Baixo, Mdio e Alto ou Crtico, Srio,
Menor, Desprezvel.

Limites para disparar atividades de gerncia de riscos: Indicao de eventos que,

quando aconteam, indiquem o momento de iniciar uma atividade de gerncia de riscos
[SEI01]. Por exemplo, quando o custo de um projeto exceder 10% do custo determinado
no oramento, disparar uma ao de conteno de despesas menos significativas para o
projeto, como por exemplo, material de escritrio.

Geralmente, a organizao deve revisar com cuidado a escala de impacto e probabilidade

que deseja utilizar para cada projeto, para garantir que a escala reflita os objetivos da
organizao [COOPER04].
Atividades
A organizao responsvel por definir critrios para a avaliao e quantificao da
probabilidade e dos impactos dos riscos. Desta forma, deve ser selecionado uma forma de
representar os parmetros de probabilidade e impacto. Pode ser muito difcil para as
empresas definirem matematicamente esses parmetros, pois no possuem experincia
suficiente e registro numrico do histrico destas informaes, alem de criar a impresso
que sabem estimar estes fatores com um maior grau de preciso do que realmente podem
[KASSE04]. Desta forma, pode ser mais adequado usar uma escala ordinal. Isto tambm
vale tipicamente para MPEs que em geral se caracterizam por falta de dados histricos
sistematicamente coletados e disponveis para uma classificao mais precisa. As
categorias usadas dependem de cada contexto. A Tabela 4 e a Tabela 5 apresentam
exemplos de escala ordinais relativa para indicar os riscos.
Alm do impacto e da probabilidade, necessrio identificar a forma de priorizao dos
riscos, que tem como objetivo identificar a importncia de cada um dos riscos levantados no
projeto, identificando assim aqueles que necessitam de mais ateno da organizao,
produzindo uma lista ordenada dos riscos identificados [BOEHM91]. A priorizao dos riscos
pode ser feita atravs da composio entre a probabilidade e o impacto (Fator de
Exposio), por meio de uma matriz de relacionamento entre probabilidade e impacto
(Figura 17). Com o resultado desta relao, obtm o fator de exposio, que define o nvel

de exposio do projeto ao risco, possibilitando a organizao de priorizar os riscos com

base no fator de exposio encontrado.
Tabela 4 Exemplo de Critrios de probabilidade de riscos baseada em uma escala ordinal

Nvel
Quase Certo

Alto

C
D

Possvel
Baixo

Raro

Descrio
Um evento simular aconteceu na organizao vrias vezes durante
o ano na mesma atividade, locao ou operao
Um evento similar aconteceu na organizao vrias vezes durante
o ano na organizao
Um evento similar aconteceu alguma vez na organizao
Um evento similar aconteceu alguma vez antes em uma
organizao simular
Um evento similar aconteceu alguma vez em outras empresas,
porm nunca nesta organizao

Tabela 5 Exemplo de critrios de impacto de riscos baseados em uma escala ordinal

Nvel
Catastrfico

Maior

Moderado

D
E

Menor
Insignificante

Descrio
Evento extremo, podendo gerar grandes custos ou atrasos, ou
prejudicar a reputao da organizao
Evento crtico, podendo gerar custos maiores custos ou atrasos, ou
produtos no apropriados
Grande impacto, mas pode ser gerenciado com algum esforo
usando procedimentos padres
Impacto minimizvel com procedimentos de gerncia padro
Impacto pode ser simplesmente ignorado

O fator de exposio pode ser representando por uma escala ordinal de termos relativos, tal
como a probabilidade e impacto. Com a definio do grau de exposio, os riscos, com
maior grau de exposio tero prioridade de ateno sobre os demais riscos.

Fator de
Exposio

Impacto

Alto

Mdio

Baixo
Probabilidade
Figura 17 Matriz de Probabilidade x Impacto: Clculo do Fator de Exposio

importante, caso for possvel, que a organizao use uma mesma escala ordinal de
termos relativos em todos os projetos executados pela organizao, de forma a facilitar a
consulta ao RCO por outros projetos.

A definio de parmetros de probabilidade

e impacto deve ser realizada na 1 iterao
da gerncia de projeto, e revisada nas
demais iteraes do ciclo do projeto.
Alm dos parmetros de probabilidade e impacto, a organizao, para cada fonte de risco
aplicvel ao projeto deve estabelecer limites para determinar a aceitabilidade do risco, a
priorizao, e gatilhos para disparar uma ao de gerncia [SEI01]. Limites so indicadores
de que o risco est prximo ou que aconteceu (caso os limites sejam ultrapassados). As
aes podem ser elaboradas com base na experincia da organizao, por meio da consulta
ao RCO ou reunies de brainstorming, ou consultando taxonomias que apresentem esta
informao. Exemplos de limites so: desempenho abaixo de 0.80, processamento superior
a 120%, indicador de faltas de funcionrios de 15%. A Tabela 6 mostra outros indicadores
de risco que podem ser usados na definio de limites.
Para mais informaes sobre a definio e uso de medidas como base para acompanhar os
limites, deve ser feito um programa de medio, usando, por exemplo, o mtodo GQM
(Goal-Question-Metric) [BASILI94] ou PSM (Practical Software and System Software
Measurement) [PSM06]. Estes mtodos so descritos no contexto de MPEs no Guia para
Medio e Anlise de Projetos de Software em Micro e Pequenas Empresas Alinhado ao
CMMI-SE/SW [RUBIK06].
Tabela 6 - Indicadores de risco (Adaptado de [SOMMERVILLE03])
Tipo do Risco
Tecnologia
Pessoas

Organizacional
Ferramentas

Requisitos
Estimativas

Indicadores possveis
Dias de atraso na entrega de hardware ou software de suporte
Problemas de tecnologia reportados
Moral baixa da equipe
Baixo relacionamento entre os integrantes da equipe
Disponibilidade de trabalho
Problemas organizacionais
Falta de ao da gerncia snior
A equipe no quer usar as ferramentas
Reclamaes sobre as ferramentas
Pedidos de computadores melhores
Reclamaes do cliente
Muitos pedidos de mudana de requisitos
No conseguir cumprir o prazo estabelecido
No conseguir eliminar os defeitos encontrados

Segundo [SEI01], a definio de limites pode ser refinada mais tarde, para cada risco
identificado, para estabelecer pontos em que o monitoramento de riscos mais agressivo
empregado ou para sinalizar a implementao de planos de mitigao de riscos. Este
procedimento pode ser realizado pela organizao durante a identificao de riscos, na
SP2.1. Faz parte da definio de limites identificar as fontes de riscos pertinentes ao projeto,
para evitar que sejam monitoradas fontes de riscos muito improvveis, e assim sejam
realizadas atividades de gerncia de riscos para categorias que no esto presentes no
projeto. Esta anlise pode ser suportada pelo uso de um template, como, por exemplo, o
apresentado no Anexo A, que mostra uma taxonomia de riscos, em forma de lista de fontes
de riscos, com a opo de identificar quais riscos so aplicveis ou no ao projeto. E para
documentao dos limites, podem ser usados os prprios formulrios de registro de risco,
que sero abordados na SP2.1.

SP 1.3 Estabelecer uma Estratgia de Gerncia de Riscos

Objetivo
O objetivo desta SP estabelecer e manter a estratgia a ser utilizada para a gerncia de
riscos. A estratgia de gerncia de risco deve incluir os seguintes itens [SEI01] [PMI04]:

Escopo do esforo da gerncia de riscos: Determinar o escopo da gerncia de risco que

ser utilizado pelo projeto, de acordo com as polticas de gerncia de risco
organizacional. Neste escopo esto includos recursos de hardware, software e pessoal
necessrio realizao da gerncia de risco, baseando no escopo do projeto.

Mtodos e ferramentas a serem utilizadas para a identificao, anlise, mitigao,

monitoramento e comunicao de riscos. Estes mtodos so apresentados ao longo
deste guia, tais como taxonomia de riscos, clculo do fator de exposio, entrevistas,
brainstorming, delphi, estratgias de tratamento de riscos, emisso de relatrios de risco
etc.

Fontes de riscos e categorias especficas do projeto, como mostrado na SP1.1

Como estes riscos so organizados (por exemplo, por meio de uma taxonomia),
categorizados, comparados e consolidados (por exemplo, riscos menores que fazem
parte de outros riscos podem ser includos nos riscos maiores);

Parmetros, incluindo a probabilidade, impacto, fator de exposio e limites;

Tcnicas de mitigao de riscos a serem utilizadas. Estas tcnicas so formas de evitar

ou resolver a fonte do risco [BOEHM91]. So exemplo destas tcnicas: prototipao,
simulao, designs alternativos ou desenvolvimento incremental. O Anexo C apresenta a
lista dos 10 maiores riscos elaborada por [BOHEM91], e com as respectivas tcnicas de
mitigao, usadas por diversos projetos, para cada um dos 10 riscos. A Figura 18 mostra
parte desta lista de riscos;

Definio de procedimentos de medio de riscos para monitorar o status dos riscos.

Estas medidas so formas de verificar a evoluo do risco (como mostrado na
identificao de limites na SP1.2);

Intervalos de tempo para monitoramento e reavaliao dos riscos.

Figura 18 - Riscos e tcnicas de gerncia de riscos [BOEHM91] (parcial)

Atividades
O primeiro passo para estabelecer uma estratgia de gerncia de riscos a organizao
determinar o escopo da gerncia de risco, identificando quais so os recursos de hardware,
software e pessoas para o projeto. Este passo busca evitar que sejam gastos recursos
excessivos com a gerncia de riscos, com base no escopo do projeto e na poltica da
organizao. Para cada uma das atividades da gerncia de riscos deve ser identificado um
grupo de pessoas responsveis por cada etapa das atividades da gerncia de risco,
recursos de hardware de softwares necessrios.
Com base nos recursos definidos no escopo da gerncia de risco, a organizao deve
identificar:

Mtodos e ferramentas a serem utilizadas para a identificao, anlise, mitigao,

monitorao e comunicao;

Fontes de riscos, que podem ser informados no registro de riscos (SP2.1);

Organizao dos Riscos;

Parmetros utilizados para utilizados para definir o nvel de probabilidade, impacto e

limite para os riscos (apresentados na SP1.2);

Tcnicas que sero utilizadas para mitigao de riscos;

Procedimentos de medio que sero analisadas para monitorao de riscos. Estes

procedimento podem ser atualizados na prpria taxonomia de riscos da organizao,
para facilitar a consulta por outros projetos;

Intervalo de tempo para a monitorao e reavaliao de riscos.

Desta forma, a organizao que deseja identificar poucos recursos de software, hardware e
pessoas, poder adequar as atividades de risco com base nestes recursos, escolhendo:

Mtodos e ferramentas que demandem menor esforo;

Parmetros de probabilidade, impacto e limites mais simples;

Tcnicas de mitigao de riscos que no exigem um alto custo de hardware, software ou

pessoal;

Medidas para monitorao de riscos menos precisas, porm funcionais;

Intervalo de tempo maior para a monitorao e reavaliao de riscos.

Com isto, a organizao vai ter uma gerncia de riscos menos precisa, porm adequada
poltica da organizao e ao projeto.
Para manter a estratgia de gerncia de risco acessvel para consulta, a organizao deve
ter um documento que consolide todas as informaes pertinentes a estratgia de gerncia
de riscos adotada. O Anexo J apresenta o template Estratgia de Gerncia de Riscos para
a documentao da estratgia de gerncia de riscos do projeto.
A organizao pode utilizar template apresentado na Figura 19 para gerar a Estratgia de
Gerncia de Riscos, baseando-se nas informaes do RCO e do plano do projeto. Este
documento pode ser armazenado no RCO, para consulta por outros projetos.
As fontes de riscos pertinentes ao projeto podem ser documentadas na prpria taxonomia
usada pelo projeto, e as medidas podem documentadas no prprio registro de riscos (como

mostrado na SP2.1). Porm, importante indicar qual a taxonomia e o documento de

registro de riscos que ser usado pelo projeto na estratgia de gerncia de riscos.
ESTRATGIA DA GERNCIA DE RISCOS
1 Escopo da Gerncia da Risco
<<Determinar o escopo da gerncia de risco que ser utilizado pelo projeto, de acordo com as polticas de gerncia de risco
organizacional. Nesta atividade sero definidos recursos de hardware, software e pessoal necessrio realizao da gerncia
de risco, baseando no escopo do projeto.>>
2 Tempo de reavaliao e monitorao de riscos
<<Intervalo de tempo para monitoramento e reavaliao dos riscos>>
3 Mtodos e ferramentas

<<Mtodos e ferramentas a serem utilizadas para a identificao, anlise, mitigao, monitoramento e comunicao de riscos.
Estes mtodos so apresentados ao longo deste guia, tais como taxonomia de riscos, clculo do fator de exposio,
entrevistas, brainstorming, delphi, estratgias de tratamento de riscos, emisso de relatrios de risco etc.>>
4 Organizao dos riscos
<<Como estes riscos so organizados (por exemplo, por meio de uma taxonomia), categorizados, comparados e consolidados
(por exemplo, riscos menores que fazem parte de outros riscos podem ser includos nos riscos maiores) >>
5 Parmetros
<<Parmetros, incluindo a probabilidade, impacto e limites>>

Figura 19 Exemplo de template para a estratgia de gerncia de riscos

SG 2 Preparar para a gerncia de risco

Os riscos so identificados e analisados para determinar sua
importncia relativa

SP 2.1 Identificar Riscos

Objetivo
O objetivo desta SP identificar e documentar os riscos [SEI01]. A identificao de
potenciais questes, perigos, ameaas e vulnerabilidades, com base na taxonomia que a
organizao definiu na estratgia de gerncia de risco, que poderiam afetar negativamente
os esforos ou plano de trabalho a base para a gerncia de risco.
Os riscos devem ser identificados e descritos de uma forma fcil de entender, antes que
possam ser analisados e gerenciados de forma apropriada. Os riscos so documentados em
uma declarao concisa que inclui o contexto, as condies e as conseqncias da
ocorrncia do risco.

Atividades
O primeiro passo, segundo o CMMI-SE/SW [SEI01], identificar os riscos associados a
custo, cronograma e desempenho em todas as fases apropriadas do ciclo de vida do projeto
para verificar a extenso do seu impacto nos objetivos do projeto. Porm a organizao
pode ter outras categorias de riscos identificadas na taxonomia que sejam prioritrios. Com
base nestas categorias, a organizao deve buscar informaes que podem ser usadas
para identificar riscos. So exemplos de fontes de informao [PMI04] [SEI01]:

Fatores ambientes da organizao - As informaes publicadas, inclusive bancos de

dados comerciais, estudos acadmicos, benchmarking ou outros estudos do setor
podem tambm ser teis para a identificao de riscos;

Histrico de riscos em outros projetos - As informaes sobre projetos anteriores

podem estar disponveis em arquivos de projetos anteriores, inclusive dados reais e
lies aprendidas. Este histrico pode ser disponibilizado no RCO da organizao;

Declaraes do escopo do projeto - A incerteza nas premissas do projeto deve ser

avaliada como causa potencial de riscos do projeto;

Plano de Gerncia de Riscos - as atribuies de funes e responsabilidades, proviso

para atividades de gerncia de riscos no oramento e no cronograma e categorias de
risco podem ser fontes de riscos;

Plano de Gerncia do Projeto - As sadas dos processos de outras reas de

conhecimento devem ser revisadas para identificar possveis riscos em todo o projeto;

WBS Work Breakdown Structure do projeto Cada elemento da estrutura de

decomposio do trabalho (WBS) deve ser revisado para descobrir riscos;

Especialistas no assunto Especialistas nos assuntos relacionados ao projeto;

Especificaes de design e requisitos de acordos - Examinar especificaes de

design e requisitos

Para coletar informaes nestas fontes, podem ser usadas as seguintes tcnicas [PMI04]
[MACHADO02]:

Reviso da documentao - Pode ser realizada uma reviso estruturada da

documentao do projeto, incluindo planos, premissas, arquivos de projetos anteriores,
taxonomias e outras informaes. A qualidade dos planos e tambm a consistncia entre
esses planos e com as premissas e requisitos do projeto podem ser indicadores de risco
do projeto;

Brainstorming - A meta do brainstorming obter uma lista abrangente de riscos do

projeto. A equipe do projeto normalmente realiza o brainstorming, freqentemente com
um conjunto multidisciplinar de especialistas que no fazem parte da equipe. Idias
sobre o risco do projeto so geradas sob a liderana de um facilitador, que pode ser o
gerente do projeto ou o gerente de riscos, ao depender do porte. A taxonomia de riscos,
definida pela organizao, pode ser usada como uma referncia. Em seguida, os riscos
so identificados e categorizados por tipo de risco e suas definies so refinadas;

Tcnica Delphi - A tcnica Delphi um meio de alcanar um consenso entre

especialistas. Nesta tcnica, os especialistas em riscos de projetos participam
anonimamente. Um facilitador usa um questionrio para solicitar idias sobre os riscos
importantes do projeto. As respostas so resumidas e ento redistribudas para os
especialistas para comentrios adicionais. O consenso pode ser alcanado aps

algumas rodadas desse processo. A tcnica Delphi ajuda a reduzir a parcialidade nos
dados e evita que algum possa indevidamente influenciar o resultado;

Entrevistas - As entrevistas com participantes experientes do projeto, partes

interessadas no projeto e especialistas no assunto podem identificar os riscos. As
entrevistas so uma das principais fontes de coleta de dados sobre identificao de
riscos;

Taxonomias de risco A organizao pode se basear na taxonomia de riscos para

coletar informaes necessrias para a identificao de riscos;

Anlise das premissas (cenrios) - Todos os projetos so concebidos e desenvolvidos

com base em um conjunto de hipteses, cenrios ou premissas. A anlise das premissas
uma ferramenta que explora a validade das premissas conforme elas se aplicam ao
projeto. Ela identifica os riscos do projeto causados pelo carter inexato, inconsistente ou
incompleto das premissas;

Comparao Anloga Esse mtodo identifica riscos com base na idia que nenhum
projeto representa um sistema totalmente novo, independente do quo avanado ou
nico ele seja. Para tanto, o mtodo prev a identificao de projetos similares, de modo
que os dados destes projetos possam ser utilizados pelo projeto atual para a sua reviso
ou para a sua prpria elaborao.

Anlise causal Estes mtodo mostra a relao entre um efeito e sua possvel causa
para que seja, verificada a origem e o risco. Entre os mtodos empregados na anlise
causal esto: o diagrama de causa e efeito e os 6 W.
o

Diagrama de causa e efeito - tambm conhecido como Espinha de peixe ou

Diagrama de Ishiwaka (Figura 20). A filosofia da anlise causal que se um erro
ocorrer, ele ir acontecer novamente, ao menos que se faa alguma coisa para
evit-lo.

6 Ws - baseada tambm em encontrar a origem das incertezas do projeto, e

enderea-las por meio de 6 questes bsicas: Who (Quem so os
stakeholders?), Why (O que os stakeholders querem alcanar?), What (No que
os stakeholders esto interessados?), Which way (De que maneira ser feito?),
Where whital (Quais recursos sero necessrios?) e When (Quando ter que ser
feito?).

Figura 20 - Diagrama de Causa e Efeito [MACHADO02].

Com base nestas tcnicas, os stakeholders selecionados para a identificao de riscos na

SP1.1, devem coletar informaes sobre riscos e ento identificar os riscos pertinentes ao

projeto. Para evitar que seja realizada uma outra reunio, esta SP pode ser executada
durante a reunio de reviso das fontes de riscos e categorias.
Os riscos so incertezas relacionadas s fontes de risco. Por exemplo, uma incerteza sobre
o perfil da mo de obra, ou sobre a data de entrega firmada com o cliente. Os riscos no
necessariamente so iguais s fontes de riscos encontradas. As fontes de riscos e
categorias servem como base para identificar os riscos. necessrio detalhar os riscos
conforme as situaes especficas encontradas pelos stakeholders durante a reunio. A
Tabela 7mostra exemplos de riscos em projetos de software.
Tabela 7 - Exemplo de fontes de riscos, categorias e riscos
Categoria
Equipe

Fontes de Risco
Novas tecnologias

Prazo
Tcnico

Falta ou insuficincia de tempo para assegurar a

implementao das mudanas
Dependncia do sistema

Projeto

Tamanho do projeto

Risco
A equipe do projeto pode no se
adaptar a tempo a tecnologia Java Web
No h tempo suficiente para entregar o
mdulo 5
No pode dar suporte a ferramenta
MobileCom, pois no apresenta rodar
em sistemas operacionais UNIX
Projeto grande (maior que 1 ano), com
atividades complexas (Mais de 20
pessoas)

A identificao de riscos deve ser feita em

todas as iteraes. Novos riscos podem
surgir ao longo do ciclo de vida do projeto.

Uma forma de descrever riscos atravs de frases SE-ENTO (if-then) [ENGERT99]. Ao

invs de apenar citar o problema ou causa, criada uma descrio onde apresentado o
problema que pode ocorrer, e a consequncia do problema caso ocorra. Como por exemplo:

SE o contrato no for fechado antes do dia 30 de setembro, ENTO o programa perde

$8 milhes em investimentos;

SE notebooks comerciais sem customizaes forem utilizados, ENTO a disponibilidade

operacional no ser adequada ao ambiente;

SE a verso 1.1 do programa X no for entregue com 1 ms de atraso, ENTO o projeto

sofrer um atraso significativo.

Aps a identificao dos riscos, deve-se documentar o contexto, condies e impactos

potenciais dos riscos identificados, de forma que os riscos possam ser facilmente
entendidos. Nesta documentao do contexto do risco, deve ser considerado o intervalo de
tempo relativo do risco, as circunstncias ou condies em torno do risco e quaisquer
dvidas ou incertezas [SEI01]. Alm disso, os stakeholders devem ser identificados e
associados a cada risco. Com base nas informaes coletadas at o momento da
identificao de riscos, a
Tabela 8 mostra um exemplo de risco identificado. Os riscos podem ser documentados no
registro de riscos.

Tabela 8 - Exemplo de Risco (SP 2.1)

Id
Risco
Descrio do Risco
Categoria
Fonte de Risco

1
Falta de Envolvimento do usurio
Se o usurio no se envolver no projeto, ento os requisitos podem
no atender ao prprio usurio
Cliente/Usurio
Envolvimento do usurio

A Figura 21 apresenta um exemplo de registro de riscos usado pela organizao para

documentao dos riscos em uma lista.
Riscos identificados
Categoria
Id
<<
<< categoria
identificador
do risco
nico do
encontrado
risco >>
>>

Fonte de
Risco
<< fonte de
risco >>

Se...
<< se
determinada
condio
acontecer >>

Ento...
<< ento
determinado
impacto
acontecer
>>

Probabilidade
<<
probabilidade
do risco
acontecer com
base na
escala
definida >>

Impacto
<<
impacto
caso o
risco
acontea
com base
na escala
definida
>>

Fator de
Exposio
<< clculo
baseado na
probabilidade
e no impacto
definido >>

Figura 21 - Exemplo de template para o registro dos riscos

SP 2.2 Avaliar, Categorizar e Priorizar Riscos

Objetivo
A avaliao de riscos necessria para atribuir a importncia relativa para cada risco
identificado. utilizada para determinar quando a ateno apropriada da gerncia de risco
exigida [SEI01].
Atividade
Inicialmente, cada risco avaliado e so atribudos valores de acordo com os parmetros de
riscos definidos, que incluem probabilidade, impacto, fator de exposio e limites, conforme
foram definidos na SP1.2.
A probabilidade e o impacto so avaliados para cada risco identificado. Os riscos podem ser
avaliados em entrevistas ou reunies com stakeholders selecionados por sua familiaridade
com as categorias de risco da pauta, usando tcnicas de brainstorming, Delphi ou reviso
documentao, tal como na identificao de riscos. So includos os membros da equipe do
projeto e, talvez, especialistas de fora do projeto. A opinio especializada necessria, pois
podem existir poucas informaes sobre riscos no RCO da organizao. Um facilitador
experiente pode liderar a discusso, pois os participantes podem ter pouca experincia em
avaliao de riscos. Esta etapa pode ser realizada na mesma reunio em que os riscos so
identificados na SP2.1, pelos stakeholders identificados pela organizao na SP1.1 [PMI04].

Outra opo de avaliar a probabilidade e impacto dos riscos usar tcnicas de estimativas
de trs pontos e simulao de Monte Carlos [PMI04]. Nas estimativas de trs pontos so
coletadas trs estimativas de custo ou durao para representar os cenrios otimista, mais
provvel e pessimista. A partir da mdia destes trs valores ser fornecido uma estimativa
de durao ou custo da atividade mais exato do que a estimativa mais provvel, de apenas
um dado coletado. A Tabela 9 mostra um exemplo da aplicao da tcnica de estimativas de
trs pontos. Com base na distribuio de valores encontrada, aplicada a tcnica de Monte
Carlo para realizar uma simulao de um cenrio futuro, e assim calcular a probabilidade de
um determinado custo ou prazo para o projeto. A Figura 22 apresenta a aplicao da anlise
de Monte Carlo, com base nos dados obtidos na Tabela 9, onde o projeto tem 12% de
chance de ter um custo de $41. Desta forma, o projeto tem um risco de 88% do oramento
de $41 no ser suficiente. Caso o projeto deseje diminuir este risco, dever trabalhar com
um oramento maior.
Tabela 9 - Faixas de estimativas de custo do projeto [PMI04]

Elemento do WBS Baixo Mais provvel Alta

Projeto

10

Construo

16

20

35

Teste

11

15

23

Projeto Total

41

Figura 22 - Aplicao da anlise de Monte Carlo [PMI04]

A partir da avaliao de probabilidade e impacto, o prximo passo o clculo do fator de

exposio de cada um dos riscos, como foi estabelecido na SP1.2 pela organizao, desta
forma possvel priorizar os riscos baseado no fator de exposio encontrado: quanto maior
o fator de exposio, maior a prioridade. Desta forma, ser produzida uma lista de riscos
ordenada do maior fator de exposio, ao menor fator de exposio.

A avaliao de riscos deve ser feita em

todas as iteraes da gerncia de risco,
pois os riscos podem diminuir ou aumentar
sua probabilidade e impacto ao longo do
ciclo de vida do projeto.

Depois de realizada a avaliao do risco, os riscos podem ser categorizados para um

tratamento mais eficiente. Esta categorizao pode ser realizada durante a identificao e
avaliao dos riscos, com base na taxonomia definida pela organizao.
A probabilidade, impacto, fator de exposio e a categoria devem ser informados no registro
de riscos, complementando as informaes sobre o risco, registradas na SP 2.1. A Tabela
10 mostra um exemplo de risco, com o impacto, probabilidade e fator de exposio
atualizado.
Tabela 10 - Exemplo de Risco (SP 2.2)
Id
Risco
Descrio do Risco
Categoria
Fonte de Risco
Probabilidade
Impacto
Fator de exposio

1
Falta de Envolvimento do usurio
Se o usurio no se envolver no projeto, ento os requisitos podem
no atender ao prprio usurio
Cliente/Usurio
Envolvimento do usurio
Baixa
Alto
Mdio

SG 3 Mitigar Riscos
Os riscos so tratados e mitigados, quando apropriado, para reduzir os
impactos adversos no atendimento dos objetivos.

SP 3.1 Desenvolver planos de mitigao de riscos

Objetivo
Um componente crtico de um plano de mitigao de riscos desenvolver cursos
alternativos de ao, caminhos alternativos e posies de retomada, com um curso de ao
recomendado para cada risco crtico [SEI01].
O plano de mitigao de riscos para um dado risco inclui tcnicas e mtodos utilizados para
evitar, reduzir e controlar a probabilidade de ocorrncia do risco, a extenso do dano
gerado, caso o risco ocorra (plano de contingncia) ou ambos, garantindo respostas em
temo hbil [SEI01] [RAMP03] [PMI04].
Os riscos so monitorados com base nos limites estabelecidos, e os planos de mitigao de
riscos so implantados para fazer com que o risco fique em um nvel aceitvel (abaixo do
limite). Caso o risco no possa ser mitigado, um plano de contingncia pode ser invocado.

Os planos de mitigao de riscos e de contingncia so freqentemente gerados somente

para riscos selecionados, onde as conseqncias dos riscos so definidas como altas ou
inaceitveis; outros riscos podem ser aceitos e simplesmente monitorados [SEI01].
As opes de tratamento de risco normalmente incluem alternativas como [SEI01] [PMI04]:

Evitar o risco Evitar o risco implica em mudar ou diminuir requisitos, mantendo o

atendimento s necessidades do usurio. Por exemplo, o esclarecimento dos requisitos,
obteno de informaes, melhoria da comunicao ou aquisio de especializao
podem prevenir alguns riscos que surgem no incio do projeto;

Controlar ou mitigar o risco - A mitigao de riscos exige a reduo da probabilidade

e/ou impacto de um evento de risco adverso at um limite aceitvel. Por exemplo, a
realizao de aes no incio para reduzir a probabilidade e/ou o impacto de um risco
que est ocorrendo no projeto freqentemente mais eficaz do que a tentativa de
reparar os danos aps a ocorrncia do risco; A adoo de processos menos complexos,
realizando mais testes, ou a escolha de um fornecedor mais estvel. A mitigao pode
exigir a elaborao de prottipos para reduzir o risco decorrente do incremento de escala
a partir de um modelo de bancada, para um dado processo ou produto. Quando no for
possvel reduzir a probabilidade, uma resposta de mitigao poder abordar o impacto
do risco se concentrando nas ligaes que determinam a gravidade. Por exemplo, o
projeto de redundncia em um subsistema pode reduzir o impacto de uma falha do
componente original;

Transferir o risco Exige a passagem do impacto negativo de uma ameaa para

terceiros, juntamente com a propriedade da resposta. Por exemplo, a contratao de um
fornecedor para desenvolvimento de um componente pode transferir o risco envolvido na
construo do componente para um fornecedor externo. Essa transferncia de riscos
simplesmente confere a uma outra parte a responsabilidade por seu gerenciamento; ela
no elimina os riscos.

Monitorar o risco - Observar e periodicamente reavaliar os riscos com relao a

mudanas nos parmetros de riscos atribudos. Por exemplo, observar se a quantidade
de requisitos novos por semana superior a 1 ou se um risco mudou sua probabilidade
de baixa para mdia;

Aceitar o risco - Reconhecer o risco, mas no tomar nenhuma ao. Uma estratgia
adotada porque raramente possvel eliminar todos os riscos do projeto. Esta estratgia
indica que a equipe do projeto decidiu no mudar o plano de gerenciamento do projeto
para tratar um risco ou que no consegue identificar qualquer outra estratgia de
resposta adequada. Por exemplo, um requisito adicional ao sistema devido a mudana
na lei que pode acontecer antes do projeto concluir.

Atividades
Uma vez determinado os principais riscos do projeto, a organizao deve desenvolver um
conjunto de funes para manter os riscos sobre controle.
O primeiro passo a ser realizado, determinar os nveis e limites que definem quando um
risco se torna inaceitvel e dispara a execuo de um plano de mitigao de riscos ou um
plano de contingncia. Com base nos limites e alternativas definidos na estratgia de
gerncia de risco, cabe a organizao selecionar qual limite e opo de tratamento de riscos
deve ser associado aos riscos, com base na prioridade do risco e categoria. Quando a
situao atingir o ponto identificado pelo limite, uma das opes de tratamento de risco ou
plano de contingncia, associados ao risco, deve ser executado.

A partir da reviso dos riscos, uma lista de possveis opes de tratamento e limites
gerada. So possveis escolhas de tratamento de riscos: evitar, mitigar, transferir, monitorar
ou aceitar o risco. O mtodo para gerar esta lista semelhante identificao e avaliao
de riscos. Por meio de brainstorming com os stakeholders selecionados pela organizao
sero geradas idias, o histrico de atividades de mitigao de riscos da organizao ser
analisado, sero usadas idias que j foram usadas anteriormente, ou sero usadas
taxonomias de riscos com opes de tratamento de riscos [COOPER04]. Com as novas
opes de tratamento de riscos definidas, a organizao pode atualizar a taxonomia de
riscos da organizao.
As atividades de mitigao de riscos devero ser examinadas com relao s vantagens e
desvantagens que elas oferecem versus os recursos que so gastos. Como em qualquer
outra atividade do projeto, pode ser necessrio desenvolver planos alternativos e avaliar os
benefcios de cada alternativa. O plano mais apropriado , ento, selecionado para
execuo. s vezes, o risco pode ser significativo e os benefcios pequenos, mas o risco
deve ser mitigado para reduzir a probabilidade de ocorrer um impacto [SEI01][COOPER04].

Os planos de mitigao de riscos devem

ser revistos a cada iterao da gerncia de
risco, uma vez que os status dos riscos
podem ter se alterado, e os planos
definidos anteriormente no terem um
custo-benefcio apropriado.
O plano de mitigao de riscos pode ser definido durante as atividades de identificao e
avaliao de riscos. Com isto, a organizao pode estabelecer uma reunio de riscos, de
acordo com o prazo pr-definido na estratgia de gerncia de riscos, para a execuo de
todas estas atividades. O registro de riscos pode ser atualizado com o plano de mitigao,
ou pode ser desenvolvido um plano de mitigao mais detalhado para cada risco. Estas
atividades extras podero ser incorporadas ao WBS do projeto.
Para cada atividade de tratamento de risco, deve ser definido uma data inicial, uma data
final, os recursos necessrios para a execuo da atividade e o responsvel por executar as
aes de tratamento de risco [SEI01]. Estas atividades de mitigao de riscos, ao serem
includas no projeto podem impactar o plano inicial do projeto, com um aumento de recursos
e tempo necessrio [RAMP03], por isto a gerncia de risco deve ser integrada s atividades
de monitorao e controle de projeto.
A Tabela 11 mostra um exemplo de risco atualizado com o plano de mitigao, limite e plano
de contingncia.
Tabela 11 - Exemplo de Risco (SP 3.1)
Id
Risco
Descrio do Risco
Categoria
Fonte de Risco
Probabilidade
Impacto
Fator de exposio
Responsvel
Estratgia

1
Falta de Envolvimento do usurio
Se o usurio no se envolver no projeto, ento os requisitos podem
no atender ao prprio usurio
Cliente/Usurio
Envolvimento do usurio
Baixa
Alto
Mdio
Gerente do Projeto
Mitigar

Plano de mitigao
Limite
Plano de
contingncia

Aumentar o nmero de reunies formais entre o usurio e a equipe de

desenvolvimento
Apenas 1 encontro entre o usurio e a equipe de desenvolvimento por
semana
Contratao de consultor/especialista na rea de domnio do sistema

A Figura 23 mostra um exemplo de template que pode ser usado para registrar os planos de
mitigao de riscos.
Plano de Mitigao de Riscos
Responsvel
Id
<<
<<
identificador
responsvel
nico do
pela
risco >>
preveno dos
riscos >>

Estratgia
<< mitigar,
transferir,
aceitar, etc.
>>

Preveno
<< tcnica de prevena escolhida para
tentar mitigar o risco >>

Limite
<< limite a
ser
monitorado
para verificar
se o risco
aconteceu ou
est prximo
de acontecer
>>

Plano de
Contingncia
<< ao a ser
executada
caso o risco
acontea >>

Figura 23 - Exemplo de template de Planos de mitigao de risocs

SP 3.2 Implementar planos de Mitigao de Riscos

Objetivo
Com base no perodo definido na estratgia de gerncia de riscos, a organizao deve
regularmente monitorar os limites definidos para os riscos. Esta atividade pode resultar na
descoberta de novos riscos ou de novas opes de tratamento de riscos, que podem exigir
um replanejamento ou uma reavaliao. Em cada caso, os limites associados com o risco
devero ser comparados contra o status, para determinar a necessidade de implementar um
plano de mitigao de riscos [SEI01].
Alm disso, o monitoramento e controle de riscos determina se [PMI04]:

As premissas do projeto continuam vlidas;

O risco, conforme avaliado, mudou seu estado anterior, usando anlise das tendncias;

Os procedimentos e polticas de gerncia de riscos adequados esto sendo seguidos;

As reservas para contingncias dos custos ou do cronograma devem ser modificadas de

acordo com os riscos do projeto.

Neste momento tambm garantido que todos aqueles que precisam estar envolvidos na
gerncia de riscos recebam as informaes necessrias sobre o desenvolvimento dos
riscos, e as medidas tomadas para lidar com eles [KASSE04].
Atividades
A organizao deve acompanhar o progresso dos riscos acompanhando probabilidade,
impacto, fator de exposio etc. para verificar a prioridade de tratamento dos riscos ou se
novos riscos, que estavam sendo apenas monitorados, aparecem. A organizao tambm

deve coletar medidas de desempenho do sucesso da execuo da atividade de tratamento

de risco, que podem ser baseadas em limites. Medidas baseadas em limites so usadas
quando valores planejados ou esperados se mantm relativamente constantes com o tempo
[NATWICK03]. A anlise de uma medida baseada em limites requer determinar quando o
desempenho ultrapassa os limites estabelecidos. Estes limites estabelecidos podem ser
normas, valores esperados ou restries, e podem ser acompanhados por meio de um
grfico de controle.
Para criar um grfico de controle [DORNER97] podem ser usadas ferramentas de planilha
eletrnica, onde dever ser informado os dados coletados, o limite superior e o limite inferior.
Por exemplo, a organizao deseja acompanhar o risco No disponibilidade das equipes,
por meio do indicador mdia de atraso semana (em horas). Para esta situao hipottica,
foi identificado que o limite para acusar a ocorrncia do risco seria de um atraso mdio de 2
horas dos colaboradores do time, com um erro de 15% para baixo ou para cima. A Tabela
12 mostra uma tabela onde foi apontada a mdia semana de atraso, em horas, de 3 times
(A, B e C). Nesta tabela tambm foi informado qual o limite superior e o limite inferior,
neste caso o limite estabelecido foi de 2 horas de atraso semanais, podendo variar 15%
(Limite superior = 1.7 e Limite inferior = 2.3).
Tabela 12 - Dados coletados em relao a mdia de atraso semanal de 3 times
A
0
0
0.5
0.75
0.7
0.8
0.6
0.9

B
1
1.5
1.3
1.4
1.8
1.9
1.2
1.4

C
1
1.3
1.4
1.9
2.2
2.5
2.7
2.6

Limite
2
2
2
2
2
2
2
2

LS
1.7
1.7
1.7
1.7
1.7
1.7
1.7
1.7

LI
2.3
2.3
2.3
2.3
2.3
2.3
2.3
2.3

Com a tabela criada, foi possvel elaborar o grfico de controle para acompanhamento do
progresso do risco. (Figura 24). O risco para a equipe B conseguiu ser controlado aps a 6
semana, porm o atraso mdio da equipe C, na mesma 6 semana, ultrapassou o limite
superior, indicando que as atividades de mitigao de risco no tiveram sucesso, e um plano
de contingncia teve que ser executado.

Mdia de atraso (Em horas)

3
2.5
A
2

B
C

1.5

Limite
LS

LI
0.5
0
1

Semanas

Figura 24 - Monitoramento do risco "No disponibilidade da mo de obra" por meio da varivel

"Mdia de Atraso (Em horas)"

Aps executar um plano de mitigao de riscos deve-se continuar monitorando o status do

risco, analisando os limites associados ao risco para verificar a necessidade de execuo de
um plano de contingncia. Enquanto um plano de mitigao de riscos est sendo executado,
o status do risco pode ser alterado, diminuindo o risco, ou agravando o risco, podendo gerar
a necessidade de invocar outras opes de tratamento de riscos para lidar com o novo
status.
O responsvel pela gerncia de risco pode realizar reunies com os stakeholders para
avaliar o progresso dos principais riscos do projeto. Nesta reunio, pode ser informado o
tempo em que o risco est na lista dos principais riscos, o ranking do risco em relao aos
principais riscos na reunio anterior, e uma sntese do progresso do risco. A Tabela 13
mostra como esta lista dos principais riscos pode ser elaborada.
Tabela 13 - Lista dos principais riscos do projeto (Adaptado de [BOEHM91])

Risco
Estagirios esto com muitas
responsabilidades no projeto
Documentao pobre do
sistema
Desempenho de hardware
abaixo do estimado no projeto

Ranking
ltima
Reunio

Nmero de
Reunies

Atual

Progresso
Est sendo avaliada a possibilidade
de contratao de um dos estagirios
A documentao est sendo
elaborada com a ajuda de um dos
desenvolvedores do sistema
Ser adquirido um hardware para
avaliao de desempenho

Alm disso, pode ser indicado no registro de riscos se o plano de mitigao de riscos no
est funcionando e aes so requeridas. Esta indicao pode ser feita por meio de um
alerta, que poderia ser um semforo, onde: verde representa sucesso nas atividades de
mitigao de risco, e vermelho indica falha nas atividades de mitigao de risco
[MACHADO02], e os riscos que forem sendo eliminados, podem ter o seu status alterado
para eliminado, e os riscos que acontecerem podem passar a ter um status de aconteceu.
Riscos sem avaliao de progresso podem ficar sem status. A Tabela 14 mostra o status
possveis para o risco.

Tabela 14 - Status do progresso da ao de tratamento dos riscos

Status do
Progresso
Vazio
Verde

Descrio
Ainda no foi avaliado o progresso
Ao de tratamento do risco est tendo
progresso
Ao de tratamento do risco no est tendo
progresso
Risco aconteceu
Risco foi eliminado

Vermelho
Aconteceu
Eliminado

A Figura 25 mostra um exemplo de template que pode ser usado pela organizao para
acompanhar o progresso dos riscos.
Progresso dos Riscos
Prob.
Id
Inicial
<< identificador
<< pronico do risco
babi>>
lidade
inicial >>

Imp.
Inicial
<< impacto
inicial >>

F.E.
Inicial
<< fa-tor
de exposio
inicial >>

Prob.
Atual
<< probabilidade
atual >>

Imp.
Atual
<< impacto
atual
>>

F.E.
Atual
<< fator de
exposio
atual
>>

Progresso

Observaes

<<verde,
vermelho,
eliminado ou
aconteceu >>

<< observaes
sobre o prorgresso
ou sobre o motivo
dos riscos terem
acontecido >>

Figura 25 - Exemplo de template de relatrio de progresso dos riscos

A organizao pode tambm criar um relatrio de status do risco como uma parte do
relatrio padro de gerncia do projeto, ou um relatrio separado, incluindo [KASSE04]
[GOLDPRACTICES06]:

Os 10 riscos principais;

Novos riscos desde o ltimo relatrio;

Nmero de itens que foram mitigados, evitados ou tiveram seu impacto reduzido para
uma prioridade menor com sucesso;

Nmero de planos de contingncia que tiveram que ser usados;

Riscos que aconteceram e quando aconteceram;

Status dos riscos existentes:

o

Descrio do risco;

Antiga e nova prioridade;

Antiga e nova probabilidade e impacto;

Antiga e nova responsabilidade;

Razo da mudana de status.

O relatrio de status dos riscos pode ser apresentado por etapa do processo de
desenvolvimento (Figura 26), com base no valor de exposio dos riscos que compe cada
fase, onde verde significa baixo nvel de risco, amarelo significa mdio, vermelho significa
alto e em branco quando os riscos ainda no foram avaliados.

Projeto

Requisitos

Implement
ao

Design

Testes

Implanta
o

Figura 26 - Status dos riscos por fase do projeto (Adaptado de [GOLDPRACTICES06])

A Figura 27 apresenta a quantidade de riscos agrupados por fator de exposio. Onde 4

riscos apresentam probabilidade e impacto baixos, 2 riscos apresentam probabilidade mdia
e impacto baixo, e apenas 1 risco apresenta probabilidade alta e impacto mdio. A Figura 28
apresenta os riscos graficamente na matriz de probabilidade versus impacto.
A Figura 29 mostra um painel de controle (Dashboard) com informaes sobre a quantidade
de riscos encontradas ao longos das semanas do projeto, os 5 principais riscos, a status do
tratamento de todos os riscos do projeto, a situao inicial dos riscos no projeto, e a situao
atual (com base no fator de exposio).
Fator de
Exposio

Impacto

Alto

1
4

Mdio

Baixo

Probabilidade
Figura 27 - Status geral do projeto em relao aos riscos (Adaptado de RADAR06])

Impacto

Pouca
experincia em
Java

Curto perodo de
tempo
Estagirios
podem sair a
qualquer
momento

Processo de
desenv. recm
implantado

Integrao com
o sistema
existente

Componente
pode no
atender as
expectativas

Probabilidade
Figura 28 - Apresentao dos riscos por fator de exposio (Adaptado de [COOPER04])

Figura 29 - Painel de Controle de Riscos (Adaptado de [CSO06])

O sucesso representado por meio do afastamento dos limites estabelecidos para cada um
dos riscos ou eliminando o risco. Este afastamento pode ser constatado por meio da
monitorao do risco, aplicando um procedimento de medio do risco. A Tabela 15 mostra
um exemplo de risco, com o progresso atualizado.
Tabela 15 - Exemplo de Risco (SP3.2)
Id
Risco
Descrio do Risco
Categoria
Fonte de Risco
Probabilidade
Impacto
Fator de exposio
Responsvel
Estratgia
Plano de mitigao
Limite
Plano de
contingncia
Progresso
Status

1
Falta de Envolvimento do usurio
Se o usurio no se envolver no projeto, ento os requisitos podem
no atender ao prprio usurio
Cliente/Usurio
Envolvimento do usurio
Baixa
Alto
Mdio
Gerente do Projeto
Mitigar
Aumentar o nmero de reunies formais entre o usurio e a equipe de
desenvolvimento;
Apenas 1 encontro entre o usurio e a equipe de desenvolvimento por
semana
Contratao de consultor/especialista na rea de domnio do sistema;
Levar o problema gerncia snior.
O usurio tem respeitado o horrio e datas marcadas para as reunies
formais
Verde

Porm nem sempre o tratamento de riscos realizado com sucesso, nestes casos novas
opes de ao de mitigao de riscos, ou o plano de contingncia (caso o risco tenha
acontecido) deve ser executado. A nova ao deve ser acompanhada at ser completada, e
o status do risco alterado. Os riscos que aconteceram deixam de ser risco, pois j
aconteceram. A Tabela 16 apresenta um risco onde foi necessrio executar o plano de
contingncia.
Tabela 16 - Risco onde houve a necessidade de executar o plano de contingncia.
Id
Risco
Plano de
contingncia

Responsvel
Data Incio
Data Final
Impacto no Projeto
Lies aprendidas

1
Falta de Envolvimento do usurio
O problema foi levado a gerncia snior, que procurou o
representante da organizao cliente, e foi acertado o envolvimento
de outro usurio com o sistema, com reunies semanais com horrio
pr-definido.
Jos / Gerente do Projeto
10/10/2006
12/10/2006
Houve um atraso estimado de duas semanas no projeto por conta da
falta de envolvimento com o usurio
Necessidade de acertar formalmente reunies semanais antes do
inicio da execuo do projeto, com data e horrios pr-estabelecidos.
Levar o problema a gerncia snior logo no incio (plano de
mitigao).

A Figura 30 mostra um exemplo de template onde pode ser registrado as aes corretivas,
tanto para planos de contingncia, como para planos de mitigao de riscos.

Aes Corretivas
Id
Risco
<< identificador nico
do risco >>

Data Final
Responsvel
<< responsvel pela
ao corretiva >>

Data Inicial
<< data da
ao
corretiva >>

<< data
final da
ao
corretiva
>>

Ao corretiva
<< pro-babi-lidade atual
>>

Impacto
<< impacto do
risco >>

Figura 30 - Exemplo de template para registrar aes corretivas

No final fechamento do projeto, importante reunir todos os riscos encontrados, e identificar

as lies aprendidas com cada um dos riscos encontrados ao longo do projeto, enumerando
os motivos pelos quais foi escolhida uma tcnica de mitigao ou um plano de contingncia,
se as opes selecionadas surtiram o efeito desejado ou no, e os motivos pelo qual o risco
aconteceu. Todas estas informaes devem ser armazenadas no RCO para serem
consultadas e revisadas por todos os stakeholders e outros projetos da organizao. A
apresenta um risco com as lies aprendidas cadastradas.
Tabela 17 Risco com lies aprendidas cadastradas
Id
Risco
Descrio do Risco
Categoria
Fonte de Risco
Probabilidade
Impacto
Fator de exposio
Responsvel
Estratgia
Plano de mitigao
Limite
Plano de
contingncia
Progresso
Status
Lies aprendidas

1
Falta de Envolvimento do usurio
Se o usurio no se envolver no projeto, ento os requisitos podem
no atender ao prprio usurio
Cliente/Usurio
Envolvimento do usurio
Baixa
Alto
Mdio
Gerente do Projeto
Mitigar
Aumentar o nmero de reunies formais entre o usurio e a equipe de
desenvolvimento;
Apenas 1 encontro entre o usurio e a equipe de desenvolvimento por
semana
Contratao de consultor/especialista na rea de domnio do sistema;
Levar o problema gerncia snior.
O usurio tem respeitado o horrio e datas marcadas para as reunies
formais
Verde
Necessidade de acertar reunies semanais antes do inicio da
execuo do projeto, com data e horrios pr-estabelecidos.

A Figura 31mostra um exemplo de template onde pode ser registrada as lies aprendidas.
Lies Aprendidas
Id
Risco
Risco
(Se.. Ento...)
<< identificador
<< se determinada
nico do risco >>
condio acontecer,
ento determinado
impacto acontecer
>> >>

Aconteceu?
<< indica se o risco
aconteceu ou no
>>

Lio Aprendida
<< lies aprendidas com o risco >>

Figura 31 - Exemplo de template onde pode ser registrado as lies aprendidas

5 Anlise de Ferramentas
O uso de ferramentas para a gerncia de riscos proporciona diversos benefcios s
atividades de identificao, anlise, monitorao e comunicao de riscos, tais como, a
organizao das informaes de forma mais eficiente e acessvel, o auxilio ao
monitoramento dos riscos e acompanhamento do histrico, a oportunidade de anlises
automatizadas de riscos, a integrao com outras ferramentas de gerncia de projeto, a
comunicao dos riscos e o desenvolvimento de relatrios.
Para auxiliar a gerncia de riscos, vrias ferramentas esto disponveis no mercado. Esses
programas so aplicveis no auxilio identificao de riscos, clculo de probabilidades e
impactos com base em dados histricos, registro de riscos, comunicao do progresso dos
riscos, armazenamento de informaes e comunicao entre os stakeholders do projeto.
Dentre as opes de software disponveis, importante escolher aquelas que atendem
melhor todo o processo de gerncia de riscos.
Existem hoje no mercado, tanto ferramentas comerciais quanto ferramentas gratuitas (free),
integradas a outras ferramentas, que funcionem em ambiente web ou em formato
standalone. Dentre as ferramentas disponveis para a gerncia de riscos e que sero
analisadas neste trabalho esto:

MS Project;

TRIMS;

RISK RADAR;

RiskFree;

RISK+;

5.1 Critrios para a anlise de ferramentas

Considerando as prticas especificas para a gerncia de riscos alinhada ao CMMI-SE/SW,
os templates propostos pelo guia, a necessidade de comunicao entre os stakeholders do
projeto, as restries apresentadas em uma MPE e os benefcios do uso de ferramentas de
apoio a gerncia de riscos, foram definidos critrios para que uma ferramenta possa
suportar as atividades requisitadas pelo guia. So estes:

R01. Permitir o registro de taxonomia de riscos (fontes de riscos e categorias);

R02. Permitir definir os parmetros de riscos (probabilidade, impacto, fator de exposio

e limites);

R03. Permitir registrar a estratgia de gerncia de riscos;

R04. Permitir registrar riscos (Descrio, Categoria, Fonte de Risco, Responsvel)

R05. Permitir avaliar, categorizar e priorizar riscos (Probabilidade, Impacto e Fator de

exposio);

R06. Permitir registrar planos de mitigao de riscos (Estratgia adotada, plano de

mitigao, limites a ser monitorado, plano de contingncia);

R07. Permitir acompanhar a execuo dos planos de mitigao de riscos (Definio do

progresso, emisso de relatrios de acompanhamento de mitigao e de planos de
contingncia);

R08. Documentao das lies aprendidas para os riscos;

R09. Ser em portugus;

R10. Baixo custo;

R11. Ser de fcil uso;

R12. Integrao com outras ferramentas de gerncia de projetos;

R13. Interface acessvel por mltiplos stakeholders;

R14. Possuir documentao

R15. Fcil instalao

5.1 TRIMS
A ferramenta TRIMS [TRIMS06] (Technical Risk Identification and Mitigation System)
[TRIMS06] faz parte do PMWS (Program Managers WorkStation), que grupo de
ferramentas gratuito, disponvel no idioma ingls, standalone, que prov informaes de
desenvolvimento e aquisio de sistemas, desenvolvido pelo programa BMP (Best
Manufacturing Practices) .
TRIMS baseada em conhecimento, e mede a gerncia de risco tecnicamente, ao invs de
medir custo ou prazo. Estouro no custo e prazo so indicadores de problemas tcnicos.
Segundo o site da ferramenta, projetos normalmente tem problemas no processo antes dos
problemas tcnicos serem identificados. Para impedir este progresso, TRIMS funciona como
uma ferramenta orientada a processo baseada em uma abordagem de engenharia de
sistema. A anlise e o monitoramento do processo permitem identificar estes problemas o
mais cedo possvel, e assim ter mais tempo para realizar aes corretivas, mitigar os riscos
e evitar problemas. TRIMS identifica reas de risco, monitora os objetivos e
responsabilidades do projeto, e pode gerar uma srie de relatrios.
A tela principal de TRIMS indica o risco de cada elemento, que podem ser mdulos, fases
ou projetos (Figura 32. Para cada um destes elementos, so apresentados questionrios
agrupados por categorias e subcategorias. Para cada categoria e subcategoria tambm
indicado o risco. Por exemplo, para a categoria 1.0 Requisitos, so apresentadas as
subcategorias estveis, completos, claros, vlidos, implementveis, precedentes e
escalveis.

Figura 32 - Tela principal do TRIMS

Para cada categoria (Requisitos, Design, Testes etc.) so feitas diversas perguntas, tais
como Os requisitos so estveis?, As interfaces externas sero finalizadas? (Figura 33).
Estas categorias e perguntas foram desenvolvidas com base no questionrio da SEI
[CARR93]. E ento o usurio responde o grau de confiana que tem nessa afirmao, que
pode ser: Sim, No, Parcialmente, No sabe ou No aplicvel. Cada uma das perguntas
possui um peso na categoria, que pode ser customizvel, e ento com base nas respostas
do usurio, calculado se o risco alto, mdio, baixo, desconhecido ou no aplicvel.

Figura 33 - Formulrio do TRIMS

Caso o usurio responda sim, no ou parcial, o TRIM vai pedir que o usurio indique os
documentos que serviram como base para responder as questes, planejar aes de
mitigao e prazos para execuo e resultados destas aes, associarem pessoas
responsveis aos risos e incluir observaes. Tambm possvel customizar as perguntas,
categorias e subcategorias, e informar o grau de impacto no custo, desempenho, segurana
e prazo para cada subcategoria.
Em relao aos requisitos relacionados SG1 - Preparar a gerncia de riscos -, o TRIMS
permite o cadastro de uma taxonomia ou a utilizao da taxonomia previamente cadastrada
(R01), porm no permite configurar os parmetros de probabilidade, impacto ou fator de
exposio (R02). O usurio apenas indica o grau de confiana que tem em relao a
pergunta feita, e com base no peso de cada pergunta calculado o grau do risco. A
estratgia de gerncia de risco no pode ser cadastrada no TRIMS (R03), e teria que ser
informada em outro documento.
Em relao aos requisitos relacionados SG2 Preparar para a gerncia de riscos - no
possvel registrar riscos especficos (R04), pois as atividades de tratamento de riscos so
associadas a cada uma das perguntas respondidas. Com base nas respostas, aes so
pedidas e responsveis so definidos. No so associados impactos e probabilidades aos
riscos, no permitindo a priorizao (R05).
Em relao aos requisitos relacionados SG3 - Nas aes informadas possvel informar
os planos de mitigao de riscos e limites a serem monitorados (R06). O status do grau de
riscos de cada uma das categorias acompanhada pela tela principal ou de uma forma mais
detalhada por meio de relatrios (R07). As lies aprendidas podem ser documentadas no
prprio campo de observaes (R08).
Em relao aos demais requisitos, o programa no apresenta verso em portugus (R09),
no possui custo de aquisio (R10), de fcil uso (R11), no integrvel a outras
ferramentas de gerncia de projetos (R12), sua interface standalone no permite um acesso
por mltiplos stakeholders (R13), possui documentao e apresentao de como usar (R14)
e possui fcil instalao (R15).

5.2 RISK RADAR

A ferramenta RISK RADAR [RADAR06] possui arquitetura Web, disponvel no idioma ingls,
e no gratuita (Ver preos na Tabela 18). Foi desenvolvida pela empresa ICE (Integrated
Computer Engineering). Por meio da ferramenta RISK RADAR possvel identificar,
analisar, acompanhar, mitigar, controlar e reportar os riscos.
Tabela 18 - Preo em Dlares Americanos da ferramenta RISK RADAR [RADAR06]
Quantidade de usurios
1
5
10
25

Custo Unitrio
$795,00
$2100,00
$3200,00
$5300,00

A ferramenta RISK RADAR permite gerenciar mltiplos projetos, gerenciar riscos em

diversos nveis (categorias, subcategorias etc.), criar novos riscos, atributos para cada
projeto e gatilhos que enviam e-mail de notificao quando o risco aconteceu ou est se
aproximando de acontecer baseados em datas, valores ou nmeros.
Outras caractersticas do RISK RADAR so:

Customizar o cubo do fator de exposio, por exemplo, escolhendo matrizes 3 x 3, 4 x 4

ou 5 x 5, e identificar qual as faixas de fator de exposio para riscos baixos, mdios ou
alto (0.1 at 0.2 baixo, 0.80 mdio, etc.).

Customizar os tipos de risco, status, fases afetadas, fontes de risco, tipo de controle
(interno, externo organizao etc.) e classificao da segurana da informao
(confidencial, pblico, etc.).

A Figura 34 apresenta a tela de entrada de dados para o detalhamento do risco.

Figura 34 - Tela de detalhe do risco da ferramenta RISK RADAR

Em relao aos requisitos relacionados SG1 - Preparar a gerncia de riscos -, a RISK

RADAR permite o cadastro de uma taxonomia categorias e fontes de riscos (R01), permite
configurar os parmetros de probabilidade, impacto ou fator de exposio (R02). A
estratgia de gerncia de risco no pode ser cadastrada no RISK RADAR (R03), e teria que
ser informada em outro documento.
Em relao aos requisitos relacionados SG2 Preparar para a gerncia de riscos -
possvel registrar riscos especficos (R04), com probabilidade, impacto e clculo do fato de
exposio, e ento priorizao de riscos (R05).
Em relao aos requisitos relacionados SG3 possvel registrar planos de mitigao, e
planos de contingncia (R06). Cada alterao feita no risco registrada no histrico,
permitindo o acompanhamento progressivo, alm de relatrios do prprio sistema (R07).
No h um espao para lies aprendidas ou um campo de observaes onde pudessem
ser documentadas lies aprendidas (R08).
Em relao aos demais requisitos, o programa no apresenta verso em portugus (R09),
possui custo de aquisio (R10), de fcil uso (R11), parcialmente integrvel a outras
ferramentas de gerncia de projetos (Por exemplo, MS Project) por meio da exportao de
dados (R12), sua interface WEB permite acesso por mltiplos stakeholders (R13), apresenta
documentao de como usar (R14) e possui fcil instalao.

5.3 MS Project 2003

A ferramenta MS Project 2003 [MICROSOFT06] um software comercial que permite
gerenciar projetos (atividades, duraes, recursos, calendrio, prazos, custos, marcos etc.).
Com o MS Project 2003 possvel trabalhar com a verso Standard ou com a verso
Professional. A Standard a verso para desktop, que funciona de forma independente, e
no possvel conexo com a verso Server. Esta verso inclui todas as funes bsicas
para gerncia de projetos. A verso Professional tem tudo que a verso Standard tm, e
tambm um ambiente colaborativo com interface Web, onde a equipe pode se comunicar e
atualizar as informaes do projeto em uma base nica, alm de permitir a gerncia de
diversos projetos dentro da uma mesma organizao. A verso standard no permite
gerenciar riscos, desta forma a verso avaliada por este trabalho a verso Server. O custo
de aquisio do MS Project Server 2003 com 5 clientes de R$3105,77 [DELL06]. Outras
diferenas da verso Professional incluem:

A colaborao entre times usando os mdulos Project Server 2003 e Web Access 2003.
Com o Project Server 2003 o gerente pode enviar alocar pessoas s tarefas, e por meio
do Web Access 2003, que possui uma interface Web, estas pessoas podem atualizar as
informaes das tarefas.

Permite personalizar os projetos de forma independente;

Permite alocar recursos de uma base de recursos de um grupo ou de toda a

organizao;

Vises gerais de todos os projetos da organizao.

Com os mdulos Project Server 2003 e Web Access 2003 instalados possvel gerenciar
riscos do projeto com o Project Professional 2003. Por meio do mdulo de gerncia de
riscos, os usurios podem registrar informaes sobre riscos e monitorar riscos. Riscos
podem ser associados a atividades, recursos, documentos ou a outros riscos. Alertas podem
ser enviados por e-mail aos responsveis pelo risco. O WBS do projeto totalmente
integrado a gerncia de riscos, de forma que as atividades relacionadas a mitigao de
riscos podem ficar no histrico do projeto para consultas futuras. A Figura 35 mostra a tela
de incluso de novos riscos.

Figura 35 - Tela de cadastro de um novo risco no MS Project.

Em relao aos requisitos relacionados SG1 - Preparar a gerncia de riscos -, o MS

PROJECT 2003 permite o cadastro de uma taxonomia apenas categorias de riscos (R01),
porm no permite configurar os parmetros de probabilidade, impacto ou fator de
exposio (R02). A estratgia de gerncia de risco no pode ser cadastrada no MS PROJCT
2003 (R03), e teria que ser informada em outro documento.
Em relao aos requisitos relacionados SG2 Preparar para a gerncia de riscos -
possvel registrar riscos especficos (R04), com probabilidade, impacto e clculo do fato de
exposio, e ento priorizao de riscos (R05).
Em relao aos requisitos relacionados SG3 possvel registrar planos de mitigao, e
planos de contingncia (R06). Tambm possvel emitir diversos relatrios do prprio
sistema (R07). No h um espao para lies aprendidas ou um campo de observaes
onde pudessem ser documentadas lies aprendidas diretamente associadas ao risco
(R08).
Em relao aos demais requisitos, o programa apresenta verso em portugus (R09),
possui um alto custo de aquisio para MPEs (R10), de fcil uso (R11), j faz parte de
uma ferramenta de gerncia de projetos (R12), sua interface WEB permite acesso por
mltiplos stakeholders (R13) e, por ser uma ferramenta muito usada no mercado, possui
muita documentao do prprio fabricante, alm de livros escritos por outros autores (R14),
e possui fcil instalao, caracterstica dos produtos da Microsoft (R15).

5.4 RiskFree
A ferramenta RiskFree [SILVEIRA06], desenvolvida por alunos da PUCRS, possui
arquitetura Web, disponvel no idioma portugus, e gratuita. Por meio da ferramenta
RiskFree possvel auxiliar as equipes de projetos nas atividades de gerncia de riscos. A
ferramenta tem como base as prticas descritas no PMBOK [PMI04]. A ferramenta RiskFree
tambm contempla as prticas de gerncia de riscos do CMMI-SE/SW [SILVEIRA06]. A
Figura 36 apresenta a tela de registro de riscos da ferramenta RiskFree.

Figura 36 - Tela de registro de riscos da ferramenta RiskFree

Em relao aos requisitos relacionados SG1 - Preparar a gerncia de riscos -, a RiskFree

permite o cadastro de uma taxonomia categorias e fontes (R01), porm no permite
configurar os parmetros de probabilidade, impacto ou fator de exposio (R02). A
estratgia de gerncia de risco pode ser cadastrada na prpria ferramenta (R03).
Em relao aos requisitos relacionados SG2 Preparar para a gerncia de riscos -
possvel registrar riscos especficos (R04), e so associados impactos e probabilidades aos
riscos, permitindo a priorizao (R05).
Em relao aos requisitos relacionados SG3 - possvel informar os planos de mitigao
de riscos e limites a serem monitorados (R06). possvel emitir diversos relatrios (R07). As
lies aprendidas podem ser documentadas durante a etapa de monitoramento e controle
(R08).
Em relao aos demais requisitos, o programa apresenta verso em portugus (R09), no
possui custo de aquisio (R10), de fcil uso (R11), no integrvel a outras ferramentas
de gerncia de projetos (R12), sua interface WEB permite um acesso por mltiplos
stakeholders (R13), apresenta pouca documentao sobre a ferramenta (R14) e apresenta
dificuldades na instalao (R15) devido aos softwares externos necessrios.

5.5 RISK+
A ferramenta RISK+ [CS06] um plug-in do MS Project de anlise de riscos que tem como
funo quantificar incertezas de custo e prazo associadas aos planos de projeto. A
ferramenta RISK+ busca responder questes como Quais so as chances de o projeto
completa antes de 2 de fevereiro? ou qual o grau de certeza que o custo ser abaixo de $9
milhes?. A ferramenta baseada nas tcnicas de estimativa de trs pontos e de Monte
Carlo (Ver SP2.2 Avaliar, categorizar e priorizar riscos - neste guia), e por meio destas

tcnicas consegue calcular a probabilidade de custo ou prazo acontecer. Para cada

atividade informado o custo mais provvel, o custo para um caso otimista, e um custo para
um caso pessimista (a mesma coisa para prazo), e com base nessa distribuio aplicada a
tcnica de Monte Carlo para encontrar as probabilidades do projeto atingirem o custo para
cada atividade, para um conjunto de atividades, ou para o projeto inteiro. Desta forma, para
ser usada, necessria a consulta especialistas ou ao histrico da organizao para saber
estimar os valores e prazos para os casos mais pessimistas, e para os casos mais otimistas.

Figura 37 - Tela do MS Project com o plug-in Risk+ instalado

A ferramenta RISK+ diferente das demais atualizadas, pois para funcionar depende de
outra ferramenta, o MS Project. Desta forma, um complemento para as demais
ferramentas, no atendendo aos requisitos relacionados aos SG1, SG2 e SG3.
Em relao aos demais requisitos, o programa no apresenta verso em portugus (R09),
possui custo de aquisio (R10) (Cerca de $695 dlares norte americanos) [CS06], de fcil
uso (R11), integrvel ao MS Project (R12), aplicvel somente verso standalone (R13),
apresenta documentao sobre a ferramenta (R14) e possui fcil instalao.

5.6 Comparao entre as ferramentas

Com o objetivo de avaliar ferramentas de apoio gerncia de risco, foram definidos
requisitos apropriados considerando as atividades de gerncia de risco propostas por este
guia, e o contexto de MPEs. A Tabela 19 mostra a comparao entre as 5 ferramentas
avaliadas.

Tabela 19 - Comparao entre as ferramentas de apoio gerncia de risco

Requisito

TRIMS

R01. Permitir o registro de taxonomia de riscos (fontes de

+
riscos e categorias)
R02. Permitir definir os parmetros de riscos
(probabilidade, impacto, fator de exposio e limites)
R03. Permitir registrar a estratgia de gerncia de riscos
R04. Permitir registrar riscos (Descrio, Categoria, Fonte
O
de Risco, Responsvel)
R05. Permitir avaliar, categorizar e priorizar riscos
(Probabilidade, Impacto e Fator de exposio)
R06. Permitir registrar planos de mitigao de riscos
+
(Estratgia adotada, plano de mitigao, limites a ser
monitorado, plano de contingncia)
R07. Permitir acompanhar a execuo dos planos de
+
mitigao de riscos (Definio do progresso, emisso de
relatrios de acompanhamento de mitigao e de planos
de contingncia)
R08. Documentao das lies aprendidas para os riscos
O
R09. Ser em portugus
R10. Baixo custo
+
R11. Ser de fcil uso
+
R12. Integrao com outras ferramentas de gerncia de
projetos
R13. Interface acessvel por mltiplos stakeholders
R14. Possuir documentao
+
R15. Fcil instalao
+
Legenda: (+)atende requisito (o) atende parcialmente (-)no atende

RADAR

RiskFree

RISK+

MS
PROJECT
2003
O

+
+

+
O

+
+
+

+
+
+
+
-

+
+

+
+
+

+
+
+

+
O
-

+
+

Entre as ferramentas analisadas, nenhuma delas apresentou suporte a todos os objetivos

especficos do CMMI (SG1, SG2 e SG3) R01 ao R08. Porm, a que melhor se adequou
aos requisitos apresentados, apesar do alto custo, foi o mdulo de riscos do MS Project,
principalmente pela simplicidade, arquitetura Web, por ser integrado ao MS Project, j
amplamente usado pelo mercado, e por ser em portugus.
As ferramentas TRIMS e o RISK+ so ferramentas de apoio gerncia de riscos e possuem
funcionalidades que as demais ferramentas no tm: questionrio eletrnico para
identificao de riscos e clculo da probabilidade de riscos de custo e prazo
respectivamente.
A ferramenta RISK RADAR, tal como o MS Project, paga e tambm permite o apoio
gerncia de riscos, arquitetura Web, porm no to integrada quanto ao MS Project, e
no tem verso em portugus. Apesar disso, a nica em que possvel definir a escala de
probabilidade, impacto e fator de exposio a ser utilizada pela gerncia de risco.
A ferramenta RiskFree foi desenvolvida com base nas prticas do PMBOK, desta forma ela
consegue apoiar a gerncia de riscos, alm de ser gratuita e em portugus. Porm, a
ferramenta ainda esta em fase inicial de desenvolvimento, possui complexidade de
instalao devido aos diversos componentes externos necessrios para a sua utilizao.
Vale ressaltar que a nica ferramenta que permite registrar a estratgia da gerncia de
riscos, entre as analisadas.

6 Exemplo
Este captulo apresenta um exemplo da aplicao do guia de gerncia de risco. O exemplo
mostra a aplicao da gerncia de riscos em uma empresa fictcia, com caractersticas
tpicas de uma MPE usando as tcnicas apresentadas neste guia, adequando-as realidade
de uma MPE.
A EMPRESA
A empresa a VENDESOFT, uma pequena empresa de Software criada h 5 anos na
grande Florianpolis, estado de Santa Catarina.
A empresa conta com 2 scios (Jane e Jones), 6 funcionrios (Barney, Fred, Vilma, Betty,
Pedrita, Bambam, Dino) e 4 estagirios (Tom e Tim, Tina e Tas). O horrio de
funcionamento o comercial (das 8 horas at 18 horas), com jornada de 5 dias por semana.
A disponibilidade e competncias dos funcionrios so detalhadas na Tabela 20.
Tabela 20 - Quadro de funcionrios da VENDESOFT
Pessoa
Jane
Jonas
Barney
Fred
Vilma
Betty
Pedrita
Dino
Bambam
Tom
Tim
Tina
Tas

Papis
Diretor comercial
Diretor tcnico/Gerente de Projeto
Analista/projetista
Programador snior
Analista/projetista
Testadora
DBA/projetista
Programador snior
Secretrio/assistente
Programador junior
Programador junior
Testadora
Documentadora

Salrio liquido
(R$ por hora)
75,00
75,00
45,00
30,00
45,00
30,00
45,00
30,00
20,00
20,00
20,00
20,00
20,00

S
8
8
8
8
8
8
8
8
8
4
4
4
4

T
8
8
8
8
8
8
8
8
8
4
4
4
4

Disponibilidade
Q
Q
S
8
8
8
8
8
8
8
8
8
8
8
8
8
8
8
8
8
8
8
8
8
8
8
8
8
8
8
4
4
4
4
4
4
4
4
4
4
4
4

S
-

D
-

Atualmente a empresa est prestando suporte e fazendo manuteno dos sistemas em

operao nos clientes. Para isto os funcionrios dedicam o esforo apresentado na Tabela
21 da disponibilidade total (incluindo tambm outras atividades internas).
Tabela 21 - Esforo dedicado pelos funcionrios da VENDESOFT ao projeto
Pessoa
Jane
Jonas
Barney
Fred
Vilma
Betty
Pedrita
Dino
Bambam
Tom
Tim
Tina
Tas

Papis
Diretor comercial
Diretor tcnico
Analista/projetista
Programador senior
Analista/projetista
Testadora
DBA/projetista
Programador senior
Secretrio/assistente
Programador junior
Programador junior
Testadora
Documentadora

S
2
2
2
2
2
2
2
2
2
1
1
1
1

T
2
2
2
2
2
2
2
2
2
1
1
1
1

Disponibilidade
Q
Q
S
2
2
2
2
2
2
2
2
2
2
2
2
2
2
2
2
2
2
2
2
2
2
2
2
2
2
2
1
1
1
1
1
1
1
1
1
1
1
1

S
-

D
-

A VENDESOFT apresenta a seguinte infra-estrutura:

10 computadores pessoais, onde 2 so notebooks Pentium-M 512mb, 4 so desktops

Pentium IV 3.2Ghz, 512mb Ram, em perfeitas condies, e 4 so desktops Pentium IV
256Mb Ram 1.8Ghz, precisando de atualizao de processador e memria;

2 servidores Pentium IV 3.2Ghz 2Gb Ram.

O PRODUTO
O produto produzido pela VENDESOFT o VideoABC, que surgiu partir da anlise
necessidade que os donos de vdeolocadoras tem para conseguir um bom sistema, que
pudesse lhes ajudar nas tarefas dirias da locadora, gerenciando as locaes, devolues,
promoes, clientes, etc. de uma maneira fcil e confivel. Desta forma, a VENDESOFT
decidiu desenvolver um sistema para atender locadoras de todos os estilos ou tamanhos,
que seja de simples utilizao e que permita o total controle do estabelecimento, eliminado
qualquer possibilidade de erro ou perda de informao.
A empresa vende um sistema de software customizvel para controle de emprstimos em
videolocadoras. A verso atual do sistema uma verso Cliente/ Servidor, desenvolvida na
linguagem Object-Pascal (ambiente DELPHI), com banco de dados PostgreSQL. As
principais funcionalidades da verso atual so:

Cadastro de clientes

Cadastro de acervo de filmes em diferentes mdias (Fitas, CDs, DVDs, etc)

Controle de emprstimo e devoluo

Tipicamente, a empresa customiza o sistema padro para um cliente especfico, instala o

sistema e oferece treinamento. A empresa tambm presta manuteno/suporte para os
sistemas em operao. Em alguns casos, novas funcionalidades so desenvolvidas em
novos projetos a pedido de clientes.
A equipe tem experincia com DELPHI. Atualmente, um dos funcionrios (Barney) tem boa
experincia em JAVA, sendo que os demais tiveram contato com JAVA apenas em suas
universidades.
Para o desenvolvimento de sistemas, a empresa adota, h 6 meses, um modelo de ciclo de
vida cascata, composto pelas seguintes fases:
1.

No incio do projeto a empresa realiza a anlise de requisitos, comeando com uma

ou mais reunies com o cliente para o levantamento de requisitos. Os requisitos
funcionais e no funcionais so documentados.

2.

Com base nisto, casos de uso so identificados e documentados, incluindo tambm

prottipos das telas do sistema a ser desenvolvido. No final, os requisitos so
revisados em conjunto com o cliente e aprovados pelo gerente e pelo cliente.

3.

Com base na anlise de requisitos, feito um projeto informal do sistema, incluindo

basicamente a arquitetura do sistema, diagrama(s) de classe e o modelo EntidadeRelacionamento do banco de dados.

4.

Depois o sistema codificado, incluindo a codificao das interfaces, parte da

aplicao e o banco de dados. So realizados testes de unidades de forma ad hoc.

5.

O sistema integrado e gerado um sistema executvel.

6.

Com base nos casos de uso documentados na anlise de requisitos, so

desenvolvidos casos de teste. Seguindo os casos de teste, o sistema executvel
testado.

7.

Assim que os testes do sistema sejam considerados satisfatrios, o sistema

instalado e liberado para o cliente. So realizados testes de aceitao de forma
informal pelo cliente e o cliente confirma que o sistema est pronto para ser utilizado.

Apesar do processo estar definido, ele ainda no totalmente seguido pelos funcionrios
menos experientes (Tom, Tim, Tina e Tas).
Aps a confirmao e aceitao dos clientes, o sistema considerado finalizado. Quaisquer
alteraes futuras, sejam motivadas por erros ou por novas necessidades dos clientes
devem ser tratadas pela gerncia de mudanas.
A VENDESOFT conta com os seguintes processos de apoio:

Controle de configurao/verses do sistema utilizando o CVS e adota uma estratgia de

acesso/segurana. O CVS usado para artefatos e para o cdigo fonte do sistema. A
empresa tambm formaliza a deteco e correo de defeitos detectados durante o
processo de desenvolvimento utilizando Bug Reports;

adotada a ferramenta CASE Enterprise Architect (EA) para a modelagem dos

sistemas, Microsoft WORD como editor de texto, e CVS para gerncia de configurao e
Microsoft Project para gerncia de projetos, OTRS para gerencia de mudanas e relatar
defeitos;

adotada a seguinte poltica de backup: realizar uma cpia diria do servidor em outra
mquina e, uma vez por semana, baixar em alguma mdia externa, com as cpias sendo
armazenadas na residncia dos diretores da empresa;

adotada a seguinte poltica de treinamento: Sempre que so adotadas novas

tecnologias ou procedimentos, feito um treinamento in-house para os funcionrios
sem experincia, com a contratao de profissionais especializados ou com a
participao de funcionrios experientes e capacitados a transmitir a tecnologia aos
demais.

O PROJETO
A VENDESOFT fechou um novo contrato com Bart Simpson, dono da vdeo-locadora
BestFilmes. Neste projeto, o cliente quer alm do sistema videoABC (e as funcionalidades j
includas), mais algumas funcionalidades:

Consulta de filmes por ttulo e/ou categoria (ao, infantil, etc.) via web para qualquer
interessado;

Reserva de filmes via web para os clientes j cadastrados na vdeo-locadora. O cliente j

cadastrado (o cadastro continua somente possvel pelo modulo cliente/servidor instalado
na vdeo-locadora) pode reservar filmes via web. A reserva mantida por 24 horas;

De acordo com estas funcionalidades, a empresa criou um novo projeto de desenvolvimento

de um mdulo a ser integrado ao sistema videoABC que tem estas funcionalidades. A
empresa pretende desenvolver o novo mdulo Web em JAVA.

A deciso pelo JAVA foi tomada devido a VENDESOFT ter planos futuros de migrao de
todo a sua aplicao (incluindo o cliente/servidor). Desta forma, a curva de aprendizado
futura seria reduzida. Como o escopo pequeno, seria uma oportunidade para minimizar o
impacto em relao ao atendimento das funcionalidades/prazo de entrega.
Alm disso, conforme acordado com o cliente, as novas funcionalidades tm que estar
disponveis para o cliente 1 ms aps o fechamento do contrato, data de aniversrio da
vdeo-locadora BestFilms.
EXECUO DA GERNCIA DE RISCO
1 Reunio de Riscos
Durante o planejamento inicial do projeto aps o contrato assinado, foi tambm realizada a
gerncia de riscos. Neste momento, deu-se incio a 1 reunio de riscos. Em uma reunio
entre os dois diretores da empresa (Jane e Jones), o analista/projetista (Barney) e o
programador snior (Fred), foi elaborada a taxonomia de riscos adequada organizao.
Esta taxonomia foi elaborada por meio da reviso de outras taxonomias apresentadas na
literatura, e ento, usando a tcnica Delphi, foram identificadas algumas fontes de riscos
apropriadas organizao de consenso de todos os participantes. Para este projeto, no
ser criada uma taxonomia de riscos prpria do projeto.
Tabela 22 - Taxonomia de Riscos da VendeSoft
Taxonomia de riscos da organizao
Categ
oria
Equipe

Fonte de Risco
Problemas em
utilizar novas
tecnologias em
projetos
[OLIVEIRA06]

Justificativa
Falta de
profissionais na
equipe
treinados com
habilidades
para utilizao
de novas
tecnologias

Crono
grama

Falta ou
insuficincia de
tempo para
assegurar a
implementao das
mudanas
[OLIVEIRA06]

Integra
o
entre
Sistem
as

Necessidade de
integrao com
outros sistemas
pode afetar
desempenho do
sistema original
[THOMSETT03]

Os projetos
podem possuir
um curto prazo
para entrega; a
equipe pode
no se sentir
confiante em
atingir a meta
de prazo.
Os produtos
desenvolvidos
podem
necessitar de
integrao com
outros
sistemas.

Equipe

Falta de
Disponibilidade dos
membros da equipe
[THOMSETT03]
[JONES94]

Possibilidade
de sada dos
estagirios e
funcionrios no
meio dos

Tcnicas de
tratamento de
riscos
Transferncia
de
conhecimento;
treinam ento;
consultoria;
contratao de
profissionais
com
experincia.

Estimativa de
cronograma
detallhada,
desenvolvim ent
o incremental,
re-utilizao de
software e
limpeza dos
requisitos
Reviso da
documentao
do sistema
atual;
Contratao de
especialista;
Benchmark do
sistema atual
aps
integrao.
Horas extras;
contratao de
trabalhadores
temporrios;
contratao de

Limites para monitorao

Caso aps a 1 semana, a
habilidade de 50% dos
membros da equipe so
avaliadas insuficientes.

Caso o cronogram a geral

esteja atrasado em 2 dias;

Procedimento de
medio
Avaliao subjetiva
da habilidade dos
funcionrios
baseado no
acompanhamento
feito por outro
trabalhador com
experincia por 2
horas/dia
[suficiente,
insuficiente].
Resultado da
diferena de dias
entre o cronograma
planejado em
relao ao
cronogram a
realizado para o dia
da avaliao.

Caso o Benchmark do sistema

atual mostra principais queries
com perda de 15% de
desempenho.

Resultados dos
testes de
benchmark com as
principais queries
do sistema
definidas pelo
analista snior
[Passou, no
passou].

Mais de um funcionrio de um
projeto em frias; Mdia de
ausncia dos funcionrios
superior a 2 horas por sem ana;

Quantidade de
horas de atraso
(sem justificativa)
do funcionrio.

Taxonomia de riscos da organizao

Categ
oria

Fonte de Risco

Justificativa
projetos.
Dispensas por
frias ou
atrasos.

Componentes
externos adquiridos
podem estar abaixo
da expectativa
[BOEHM91]
[JONES94]

Possibilidade
de aquisio de
componentes
de terceiros

Equipe

Falta de Experincia
com o modelo de
processo da
organizao [DIR06]

Possibilidade
dos
funcionrios
no estarem
preparado para
o modelo de
processo da
empresa

Integra
o
entre
Sistem
as

Documentao
inexistente
[OLIVEIRA06]

Equipe

Ambiente Fsico / de
Suporte para o time
[THOMSETT04]

Possibilidade
de integrao
com outros
sistemas que
no possuem
documentao
Computadores
ou ambiente
podem no ser
adequados
para as
atividades do
time

Fornec
edores

Tcnicas de
tratamento de
riscos
estagirios;
aumento
salarial;
oferecer
incentivos
extras; reunies
para obteno
de feedback.
Desenvolviment
o de um
contrato por um
advogado;
Anlise de
desempenho;
Checar as
referncias do
fornecedor.
Acompanhame
nto das
atividades;
Exigncia dos
produtos de
sada;
Treinamento;
Reunies
dirias de
status;
Contratao de
consultoria dos
desenvolvedore
s originais;

Investimento
em
computadores,
cadeiras,
mesas, luz etc.

Limites para monitorao

Componente entregue no
atender ao requisito com base
em testes de desempenho
abaixo de 10% do desejado
(requisito) e menos de 100%
dos testes de funcionalidade
no atendidos aps 10 testes
realizados ao integrar o
componente ao sistema;
Caso a quantidade diria de
artefatos produzidos fora dos
padres do processo seja
superior a 10;

Caso no existir documentao

para menos de 70% das
funes

Reclamao de mais de 50%

da equipe sobre os aspectos
fsicos da organizao

Procedimento de
medio

Resultado dos
testes de
benchmark [passou,
no passou];
Resultado dos
testes de integrao
realizado pelo
testador [Passou,
no passou].
Quantidade de
artefatos
produzidos fora do
padro (defeito).

Avaliao da
documentao por
funo do sistema
[Tem = 100%,
parcial = 50%, no
tem = 0%]
Avaliao realizada
por cada um dos
membros da equipe
[Ruim 0%, bom =
50%, timo = 100%]

Inicialmente nem todas as fontes de riscos da organizao foram identificadas no projeto,

porm so vlidas dentro do contexto da organizao, e podem acontecer em outros
projetos. Componentes externos adquiridos abaixo da expectativa, documentao
inexistente, e ambiente fsico / de suporte para o time no adequado so trs exemplos de
fontes no identificadas para o projeto.
Ainda na 1 reunio foi realizada a identificao de parmetros de riscos como parte da
definio da estratgia da gerncia de riscos. Todos os participantes da reunio optaram por
utilizar uma escala ordinal de valores bastante simples, com apenas trs valores possveis
(baixo, mdio e alto) facilitando a identificao do nvel de probabilidade, impacto e grau de
exposio de riscos. Foi decidido tambm que a identificao de limites seria realizada junto
com a identificao de riscos.
Para a elaborao da estratgia de riscos, foram feitas as seguintes definies:

A Erro! Fonte de referncia no encontrada. mostra a alocao de recursos de

pessoal para a gerncia de riscos;
A

Tabela 23 mostra os mtodos e ferramentas que sero utilizados para a gerncia de

risco;

As fontes de riscos e categorias do projeto sero apresentadas no prprio registro de

riscos do projeto;

A organizao dos riscos feita por meio de categorias e fontes, so comparados a

partir do clculo de fator de exposio (probabilidade x impacto), usando a escala ordinal
de valores definida (baixo, mdio e alto). E os limites so identificados para cada um dos
riscos pertinentes ao projeto;

Possveis tcnicas de preveno de riscos e limites de monitoramento esto informadas

na prpria taxonomia de riscos da organizao;

Por ser um projeto com um prazo muito curto, de forma a garantir o prazo estabelecido,
os riscos devero monitorados diariamente pelos responsveis, e as reunies de risco
devero ser realizadas uma vez por semana.

Tabela 23 Mtodos e Ferramentas que sero utilizados para a gerncia de risco

Atividade
SP1.1 Determinar fontes de riscos e categorias

SP1.2 Definir parmetros

SP1.3 Estabelecer uma estratgia de gerncia de riscos

SP2.1 Identificar Riscos

SP2.2 Avaliar, categorizar e priorizar riscos

SP3.1 Desenvolver planos de mitigao de riscos

SP3.2 Implementar plano de mitigao de riscos

Mtodos e Ferram entas

Guia de Implantao da
Gerncia de Riscos em Micro e Pequenas Empresas
alinhado ao CMMI-SE/SW
Template da taxonomia de riscos
Taxonomia da organizaco
Consulta ao plano de projeto e ao RCO da empresa
Escala ordinal de valores simples, com apenas 3 valores:
Baixo, Mdio e Alto
Priorizao de riscos a partir do clculo do fator de exposio
com base nos nveis de impacto e probabilidade
Consulta ao RCO da empresa
Template da estratgia de gerncia de riscosI.
Consulta ao RCO da empresa
Reviso da docum entao
Estratgia da gerncia de risco
Consulta ao RCO da empresa
Brainstorming
Taxonomia de riscos da organizao
Template de Registro de Riscos
Brainstorming
Estratgia da gerncia de risco
Avaliao de probabilidade e impacto
Clculo do fator de exposio
Taxonomia de riscos da organizao
Consulta ao RCO da empresa
Registro de Riscos
Registro de Riscos
Estratgia da gerncia de risco
Evitar, mitigar, aceitar ou transferir
Taxonomia da organizao
Consulta ao RCO da empresa
Template de planos de mitigao de riscos
Registro de riscos
Estratgia da gerncia de risco
Coleta de dados
Grficos de monitoram ento de riscos
Template de relatrio de progresso de riscos
Template de relatrio de acompanhamento de aes
corretivas
Template de relatrio de lies aprendidas

Tabela 24 Alocao de recursos de pessoal da VENDESOFT para a gerncia de riscos

Recursos
Jane/Diretora, Jonas/Gerente do
Projeto, Barney/Analista e
Fred/Programador
Jonas/Gerente do Projeto,
Barney/Programador

Atividade
SG1 - Preparao para a gerncia de riscos
SG2 Identificar e Analisar Riscos
SG3 Mitigar Riscos

Tabela 25 - Estratgia da Gerncia de Riscos do projeto VdeoABC

ESTRATGIA DA GERNCIA DE RISCOS
1 Escopo da Gerncia da Risco
SG1 - Preparao para a gerncia de riscos: Jane, Jonas, Barney e Fred
SG2 Identificar e Analisar Riscos: Jonas, Barney e Fred
SG3 Mitigar Riscos: Jonas / Softwares: Microsoft Word e Excel / Hardware: Laptop Jonas
2 Tempo de reavaliao e monitorao de riscos
Os riscos devero monitorados e reavaliados semanalmente
3 Mtodos e ferramentas

A VendeSoft segue o seguinte processo de gerncia de risco:

Determinar as fontes de riscos e categorias Nesta etapa, elaborada e/ou revisada a taxonomia de riscos da
organizao com base em outras taxonomias disponveis para consulta, e na consulta ao RCO da prpria organizao.

Definir parmetros Nesta etapa definido os parmetros a serem usados para classificar probabilidade, impacto e fator
de exposio. Com base no fator de exposio ser definida a priorizao dos riscos da empresa. Para esta definio
realizada uma consulta ao RCO da prpria organizao.

Estabelecer uma estratgia Com base no template apresentado no anexo I identificada todas as informaes que
compe a estratgia de gerncia de risco a ser usada na organizao.

Identificar os riscos Toda a documentao do projeto revisada pela equipe identificada para a gerncia de riscos, em
busca de novos riscos ou riscos que no so mais aplicveis ao projeto, especialmente os documentos que foram
atualizados desde a ltima reunio de gerncia de riscos. Esta reviso realizada por meio da tcnica de brainstorming
entre os integrantes da equipe. Alm da documentao, usada a taxonomia de riscos da organizao e a consulta ao
RCO da organizao, para a identificao de riscos.

Avaliar, categorizar e priorizar riscos Com o registro de riscos em mos, a equipe responsvel pela avaliao de
riscos, ir identificar por meio de brainstorming e delphi, a probabiliade e o impacto provveis para os riscos identificados.
Com base nestas duas informaes, ser identificado o fator de exposio, e ento priorizados. Neste momento o registro
de risco atualizado.

Desenvolver planos de mitigao de riscos Com os riscos priorizados, definida a estratgia de tratamento do risco,
entre as opes de evitar, mitigar, aceitar ou transferir o risco. Com base na opo escolhida, so selecionadas tcnicas
de mitigao do risco, um plano de contingncia, limites para monitoram ento e definio de procedimentos de medio
para identificar se os limites do risco foram ultrapassados. Neste mom ento a equipe de riscos deve atualizar a taxonomia
de riscos com estas opes, para que estas informaes estejam disponveis para outros projetos da organizao, e
tambm atualizar o registro de riscos com estas informaes.

Implementar planos de mitigao de riscos Nesta etapa feito o monitoramento e acompanhamento dos riscos
identificados. avaliado o progresso nas aes de mitigao dos riscos. Caso houver progresso, e os riscos estejam
afastados do limite, indicado um alerta verde para o risco, caso no houver progresso nas aes de mitigao de risco,
ligado o alerta vermelho. Caso os limites sejam ultrapassados, o plano de contingncia deve ser executado. Nesta etapa
so avaliadas se os planos de mitigao de riscos ou de contingncia ainda continuam vlidos. O registro de riscos deve
ser atualizado, e a taxonomia tambm deve ser atualizada com as novas opes. Grficos de monitoramento devem ser
produzidos para cada risco, com base nos limites e procedim entos de medio.

4 Organizao dos riscos

A organizao dos riscos feita por meio de categorias e fontes, so comparados a partir do clculo de fator de exposio
(probabilidade x impacto), usando a escala ordinal de valores definida (baixo, mdio e alto). E os limites so identificados para
cada um dos riscos pertinentes ao projeto;
5 Parmetros
Probabilidade: Baixo, Mdio e Alto
Impacto: Baixo, Mdio e Alto
Limites: Identificados no documento Taxonomia de Riscos do Projeto
Fator de exposio: Baixo, Mdio e Alto

Com a estratgia de gerncia de risco elaborada (

Tabela 25), iniciou-se a identificao de riscos. Foram reunidos os seguintes documentos

para reviso e anlise, como fontes de informao para identificao de riscos: Taxonomia
de riscos da organizao, Plano do projeto, WBS e estratgia da gerncia de risco. O plano
do projeto para este exemplo pode ser visto no guia de planejamento de projeto de software
[KUNTZE06].
Como a elaborao da taxonomia foi realizada pela prpria equipe, j foi possvel identificar,
avaliar e categorizar os riscos pertinentes ao projeto. Com a reviso da documentao e
posterior brainstorming entre os participantes, vrias sugestes foram dadas e ento foi
possvel, por meio de consenso usando a tcnica Delphi, agrupar os riscos semelhantes, e
descrever melhor os riscos e identificar responsveis pela mitigao.
Alm disso, durante a identificao dos riscos, foi realizada tambm a avaliao e
categorizao dos riscos, identificando probabilidade, impacto e fator de exposio com
base na escala ordinal definida na estratgia de gerncia de riscos (baixo, mdio e alto)
usando a tcnica Delphi entre os participantes. Com base nos riscos identificados, foi
elaborado o registro de riscos (Tabela 26), documentando as seguintes informaes:

Id Cdigo do risco;

Risco Descrio sucinta do risco;

Categoria e Fonte do Risco com base na taxonomia;

Descrio Descrio do risco no formato Se-Ento;

Probabilidade, impacto e fator de exposio.

Tabela 26 - Registro de Riscos (1 Reunio)
Riscos identificados
Categoria

Id
1

Equipe

Equipe

Cronograma

Integrao
entre sistemas

Fonte de Risco
Problemas em
utilizar novas
tecnologias em
projetos
Falta de
Experincia
com o modelo
de processo da
organizao

Falta ou
insuficincia de
tempo para
assegurar a
implementao
das mudanas
Necessidade de
integrao com
outros sistemas
pode afetar
desempenho do
sistema original

Probabilidade
Mdio

Impacto
Alto

Fator de
Exposio
Alto

Mdio

Mdio

Mdio

Ento o cliente no poder

inaugurar o sistema na data
de aniversrio, e a
VidieoABC

Alto

Alto

Alto

Ento o sistema poder

baixar o desempenho com a
integrao

Baixo

Mdio

Baixo

Se...
Se o time
no tiver
habilidade
com Java
Se o
processo de
software no
for usado por
todos os
integrantes
da equipe
Se no for
entregue o
produto em 1
ms

Ento...
Ento possvel que o prazo
estimado no seja cumprido,
e que o sistema no seja
elaborado com qualidade
Ento defeitos podem ser
encontrados aps a
implantao do produto no
cliente

Se houver
problemas
de
integrao
com o
sistema atual

Riscos identificados
Categoria
Id
5

Equipe

Fonte de Risco
Falta de
Disponibilidade
dos membros
da equipe

Se...
Se os
estagirios
sarem da
organizao
no meio do
projeto,

Ento...
Ento o projeto poder sofrer
atrasos, uma vez que os
estagirios esto assumindo
responsabilidades no projeto

Probabilidade
Alto

Impacto
Alto

Fator de
Exposio
Alto

Com os riscos identificados, e priorizados com base no fator de exposio, foi definido um
plano de tratamento para os riscos. Foi identificado que mitigar o risco ser a estratgia para
todos os riscos identificados. As opes de transferir ou aceitar foram descartadas.
Revisando a taxonomia foram selecionadas, para cada risco, aes de preveno e limites
para identificar quando o risco aconteceu, procedimentos de medio do progresso do risco,
e uma ao a ser executada caso o risco acontea (plano de contingncia). O plano de
mitigao de riscos pode ser visto na Tabela 27.
Tabela 27 - Plano de mitigao de riscos - 1a Reunio
Id
1

Responsvel
Barney

Estratgia
Mitigar

Jonas

Mitigar

Plano de mitigao de riscos

Preveno
Limite
Treinamento da Equipe por Barney;
Caso aps 1
Compra de Livros Java para
semana, a
Consulta
habilidade de 50%
dos membros da
equipe so
avaliadas
insuficientes.
Treinamento da equipe no modelo
Caso a quantidade
de processo / Acompanham ento do
diria de artefatos
processo de desenvolvimento
produzidos fora
dos padres do
processo seja
superior a 10;
Pedir que os funcionrios e
Caso o
estagirios faam horas extras para
cronograma geral
cobrir o atraso inferior a 4 dias
esteja atrasado em
2 dias;

Jonas

Mitigar

Barney

Mitigar

Testes de Benchmark de sistema

para avaliar o desempenho.

Jonas

Mitigar

Obter feedback dos estagirios

Caso o Benchmark
do sistema atual
mostra principais
queries com perda
de 15% de
desempenho.
Mdia de ausncia
dos estagirios
superior a 2 horas
por semana;

Plano de Contingncia
Contratao de
profissionais com
experincia em Java.

Contrao de consultoria
especializada em melhoria
de processos de software.

Contratao de
profissionais com
experincia em Java por
perodo limitado
Contratao de mo de
obra temporria para
resolver problema

Contratao do estagirio
ao depender do
desempenho; Contratao
de trabalhadores
temporrios com
experincia em Java

At o momento desta 1 reunio, nenhuma ao de tratamento de risco foi disparada. O

projeto ainda est no incio, e ainda no foram coletas as medidas necessrias para
identificar se o limite foi ou no atingido. Desta forma, todos os riscos esto com o alerta
verde. Este alerta pode passar para vermelho caso as aes de tratamento dos riscos no
estejam surtindo efeito.

2 Reunio da gerncia de riscos

Aps 1 semana de incio do projeto, a 2 reunio da gerncia de risco foi iniciada. Foram
reunidos novamente os recursos alocados para a gerncia de riscos, conforme estratgia da
gerncia de risco definida na 1 reunio. Foi feita uma reviso da taxonomia de riscos
adotada pela organizao, e de algumas outras taxonomias, e no foram encontradas
nenhuma categoria ou fonte de risco nova, ou nenhuma que devesse ser retirada.
Tambm foi acordado que nenhuma mudana nos parmetros ou na estratgia da gerncia
de risco deveria ser feita. A empresa ainda dispe dos mesmos recursos para a gerncia de
risco, tal como planejado na 1 reunio.
Para a identificao de riscos, foi revisada a taxonomia de riscos da organizao, e os
documentos do projeto (ex. requisitos, WBS, plano de projeto etc) que sofreram alterao
desde a ltima reunio de riscos, e assim foi realizado um brainstorming entre os membros
da reunio. Foi levantado que existe um novo requisito do cliente, e ser necessrio utilizar
um componente pronto para visualizao dos trailers dos filmes. Desta forma, um novo risco
foi detectado para a fonte de risco dependncia de um fornecedor externo para atingir um
cumprimento de um requisito. Este risco foi enquadrado na categoria Fornecedores, e foi
includo no registro de riscos conforme a seguir. Se o componente adquirido junto ao
fornecedor no atender aos requisitos de desempenho e funcionalidade, ento os requisitos
do cliente no sero atendidos.
Tabela 28 - Registro de riscos (Novo risco identificado) (2a Reunio)
Riscos identificados
Categoria
Id
6

Fornecedores

Fonte de Risco
Dependncia
de um
fornecedor
externo para
atingir um
cumprimento de
um requisito

Se...
Se o
componente
adquirido
junto ao
fornecedor
no atender
aos
requisitos de
desempenho
e
funcionalidad
e,

Ento...
Ento os requisitos do
cliente no sero
atendidos

Probabilidade
Baixo

Impacto
Alto

Fator de
Exposio
Mdio

A segunda etapa da atividade de gerncia de riscos a avaliao de todos os riscos

levantados. Para realizar esta avaliao, foi feito uma avaliao do progresso dos riscos,
com base nos limites identificados, dados coletados por Jonas, e opes de tratamento para
cada um dos riscos.
Foi identificado que o alerta vermelho deveria ser ligado para o risco 5, uma vez que as
aes de mitigao do risco no esto surtindo o efeito desejado. Os demais riscos
apresentam progresso com as aes de mitigao definidas. Para o risco 5, uma nova
opo de mitigao de risco deve ser executada, e esta ao foi documentada no
documento de aes corretivas (Tabela 29).

Tabela 29 - Aes corretivas

Aes Corretivas
Id
Risco
Responsvel
1
Jonas

Data Final
Data Inicial
10/Jan

Ao corretiva
Oferecer incentivos extras

Impacto
Aumentar o
estimulo dos
estagirios,
especialm ente
Tim

Continuando a reunio de riscos, foi decidido que alguns riscos deveriam manter os mesmos
nveis de probabilidade e impacto no projeto, e os riscos a seguir deveriam ter sua
probabilidade alterados: Estagirios podem sair a qualquer momento, Pouca Experincia
em Java Web e Perodo de Desenvolvimento de apenas 1 ms.
Tim, programador estagirio, est atrasando mais de 1 hr por semana e aparenta estar com
um grau de satisfao ruim em relao ao projeto, apesar do bom desempenho do mesmo
em cumprir as tarefas designadas a ele. Com isto, foi consenso de todos elevarem a
probabilidade do risco de o estagirio sair para alta.
A equipe est tendo um bom desempenho no aprendizado de Java, apesar de continuar a
necessidade de Barney acompanhar o trabalho dos outros membros da equipe. Com isto, foi
consenso que a probabilidade do risco 1 deveria ser reduzida para baixa. Como
conseqncia desta evoluo tcnica da equipe, o prazo de apenas 1 ms para concluso
do projeto deve ser cumprido (mas deve continuar sendo acompanhado), e este risco teve
sua probabilidade baixa para mdio.
Foi tambm avaliado o novo risco relacionado ao fornecimento de um componente para
exibio de trailers. Devido ao grau de confiana no fornecedor, segundo Jonas, a
probabilidade foi identificada como baixa, porm o impacto, caso o risco acontea, seja alto
no projeto, podendo impactar no prazo previsto. O responsvel pelo novo risco ser o
prprio Jonas.
Com estas alteraes, o principal risco passa a ser o risco de um estagirio sair do projeto.
Jonas vai continuar avaliando este grau de insatisfao dos estagirios. Este risco est com
o alerta vermelho. A Erro! Fonte de referncia no encontrada. mostra o relatrio de
progresso dos riscos.
Tabela 30 - Progresso dos Riscos

Id
1

Prob.
Inicial
Mdio

Imp.
Inicial
Alto

F.E.
Inicial
Alto

Prob.
Atual
Baixo

Mdio

Mdio

Mdio

Mdio

Progresso dos Riscos

Imp.
F.E.
Atual
Atual
Alto
Mdio

Mdio

Mdio

Progresso

Observaes

Verde

Barney realizou procedimento de

medio previsto, e analisou de
forma subjetiva a habilidade da
equipe em satisfatrio e no
satisfatrio, e mais de 50% da
equipe apresentou rendimento
satisfatrio nesta 1 semana,
porm o risco conitnua, e este
acompanhamento deve continuar
sendo feito (A Figura 41 mostra o
monitoram ento do risco ao longo
de todas as semanas).
Jonas coletou a quantidade de
artefatos produzidos fora do
padro do processo, e menos de 5
artefatos por dia foram produzidos
com defeitos. As atividades
continuam sendo acompanhadas.

Verde

Progresso dos Riscos

Imp.
F.E.
Atual
Atual
Alto
Alto

Id
3

Prob.
Inicial
Alto

Imp.
Inicial
Alto

F.E.
Inicial
Alto

Prob.
Atual
Alto

Progresso

Observaes

Verde

Jonas mostrou que o cronograma

do projeto est dentro do prazo
estabelecido, sem atrasos, quando
comparado ao j realizado. Os
requisitos esto claros e o WBS
est bem detalhado.
Ainda no foi possvel realizar
testes de desempenho no sistem a,
visto que o mdulo no tem
nenhuma parte pronta ainda. Estes
testes devero ser realizados
apenas a partir da 3 semana.
Tim (estagirio) possui uma mdia
de atraso de 1 hr por semana,
alm de aparente insatisfao em
relao a empresa. Jonas reuniu
os estagirios ter um feedback de
todos em relao ao projeto e a
organizao, porm no houve
efeito positivo em relao a Tim (A
Figura 42 mostra o monitoramento
do risco ao longo das 4 semanas).
<< Risco Novo >>

Baixo

Mdio

Baixo

Baixo

Mdio

Baixo

Verde

Mdio

Alto

Alto

Alto

Alto

Alto

Vermelho

Baixo

Alto

Mdio

Na terceira parte da reunio de riscos, no foram identificadas novas opes de tratamento

para os riscos j existentes. Para o novo risco identificado, relacionado ao fornecedor, foi
registrado o limite de 10% acima no desempenho de testes de benchmarking em relao a
condio atual do sistema, e menos de 100% dos testes de funcionalidade no atendidos.
Este risco dever ser mitigado, desenvolvendo um contrato legal firmando os requisitos de
funcionalidades necessrios, e buscar outros fornecedores capazes de entregar um
componente similar caso o escolhido no atenda. Caso o risco se torne realidade, dever
ser fechado um acordo com um novo fornecedor (Tabela 31). A taxonomia de riscos da
organizao tambm foi atualizada com estas opes de tratamento de risco, limites e
planos de contingncia.
Tabela 31 - Plano de mitigao de riscos parcial (2 Reunio)
Id
6

Responsvel
Jonas

Estratgia
Mitigar

Preveno
Desenvolver um contrato legal com
a empresa; buscar referncias da
empresa; buscar novas opes de
fornecedores;

Limite
Componente
entregue no
atender ao
requisito com base
em testes de
desempenho
abaixo de 10% do
desejado
(requisito) e
menos de 100%
dos testes de
funcionalidade no
atendidos aps 10
testes, no mnimo,
realizados ao
integrar o
componentes ao
sistema;

Plano de Contingncia
Contratao de outro
fornecedor com
componentes de pronta
entrega.

3 Reunio de Riscos
Na semana seguinte, a 3 reunio de riscos foi iniciada. Foi reunida novamente a equipe
designada para a gerncia de riscos. Foram reunidos novamente os recursos alocados para
a gerncia de riscos, conforme estratgia da gerncia de risco definida. Antes de iniciar a
reunio foi divulgado um quadro com a viso geral dos riscos com base no fator de
exposio das duas ltimas reunies (38). Por meio desta figura possvel que o nmero de
riscos aumentou, e que aumentou o fator de exposio de mais um risco.

1a Reunio

1
Impacto

Impacto

2
1

Fator de
Exposio

2a Reunio

Alto

Mdio

Baixo
Probabilidade

Probabilidade

Total de Riscos - 6

Total de Riscos - 5

Figura 38 - Viso geral da gerncia de riscos

Foi feita uma reviso da taxonomia de riscos adotada pela organizao, e de algumas outras
taxonomias, e no foram encontradas nenhuma categoria ou fonte de risco nova, ou
nenhuma que devesse ser retirada.
Tambm foi acordado que nenhuma mudana nos parmetros ou na estratgia da gerncia
de risco deveria ser feita. A empresa ainda dispe dos mesmos recursos para a gerncia de
risco, tal como planejado na 1 iterao.
Para a identificao de riscos, foi revisada a taxonomia de riscos da organizao, e os
documentos do projeto (ex. requisitos, WBS, plano de projeto etc.) que sofreram alterao
desde a ltima reunio de riscos, e assim foi realizado um brainstorming entre os membros
da reunio. No foram levantados novos riscos.
A segunda etapa da atividade de gerncia de riscos a avaliao de todos os riscos
levantados. Para realizar esta avaliao, foi feito uma avaliao do progresso dos riscos,
com base nos limites identificados, dados coletados por Jonas, e opes de tratamento para
cada um dos riscos.
Tabela 32 - Progresso dos Riscos (3 Reunio)

Id
1

Prob.
Inicial
Mdio

Imp.
Inicial
Alto

F.E.
Inicial
Alto

Prob.
Atual
-

Progresso dos Riscos

Imp.
F.E.
Atual
Atual
-

Progresso

Observaes

Eliminado

O risco foi eliminado, pois depois

de uma semana mais de 50% da
equipe apresentou capacidade em
aprender Java.

Progresso dos Riscos

Imp.
F.E.
Atual
Atual
-

Id
2

Prob.
Inicial
Mdio

Imp.
Inicial
Mdio

F.E.
Inicial
Mdio

Prob.
Atual
-

Progresso

Observaes

Eliminado

Jonas coletou a quantidade de

artefatos produzidos fora do
padro do processo, e no houve
erros de artefatos essa semana.

Alto

Alto

Alto

Mdio

Alto

Alto

Verde

Mdio

Baixo

Verde

Aconteceu

Eliminado

Jonas mostrou que o cronograma

do projeto est dentro do prazo
estabelecido, sem atrasos, quando
comparado ao j realizado. Os
requisitos esto claros e o WBS
est bem detalhado.
Ainda no foi possvel realizar
testes de desempenho no sistem a,
visto que o mdulo no tem
nenhuma parte pronta ainda. Estes
testes devero ser realizados
apenas a partir da 3 semana.
Tim, o estagirio, pediu demisso,
e se desligou do projeto.
O fornecedor entregou o
componente conform e previsto,
foram realizado os testes previstos
com o componente, e atende aos
requisitos.

Baixo

Mdio

Baixo

Baixo

Mdio

Alto

Alto

Baixo

Alto

Mdio

Um dos riscos se manifestou: Tim, o estagirio pediu para ir embora da empresa. Com isto,
houve a necessidade de executar o plano de contingncia. Tim no aceitou a proposta de
permanecer na equipe, foi ento contratado um profissional Java, que j havia atuando na
empresa em outros projetos, para esta ltima semana. O custo com a equipe aumentou em
10% com esta contrao. O risco 1, 2 e 6 foram eliminados. A equipe apresentou habilidade
suficiente para trabalhar com Java e com o modelo de processo, e o fornecedor entregou o
componente conforme previsto. Os outros dois riscos riscos apresentaram progresso nas
atividades de mitigao, mas mesmo assim foi consenso que deveriam manter os mesmos
status da semana anterior.
Tabela 33 - Aes Corretivas (3a Reunio)
Aes Corretivas
Id
Risco
Responsvel
1
Jonas

Data Final
Data Inicial
17/Jan

18/Jan

Ao corretiva
Contratao de um
profissional com
conhecimento em Java.

Impacto
Aumento do custo
da equipe em
10%

Na terceira parte da reunio de riscos, no foram identificadas novas opes de tratamento

para os riscos j existentes.
4 Reunio de Riscos
Na semana seguinte, a 4 e ltima iterao de gerncia de risco foi iniciada. O projeto est
concludo com sucesso. Foi reunida novamente a equipe designada para a gerncia de
riscos. Foram reunidos novamente os recursos alocados para a gerncia de riscos,
conforme estratgia da gerncia de risco definida.

Todos os riscos foram mapeados, planos de mitigao de riscos foram realizados, apenas
um plano de contingncia foi executado, trs riscos foram eliminado e os demais no se
manifestaram. A Figura 39 apresenta a quantidade de riscos ao longo do projeto.

Quantidade de Riscos

6
5
4
Riscos
3
2
1
0
1

Sem anas

Figura 39 - Quantidade de riscos ao longo do projeto

A Figura 40 mostra a viso geral do resultado das aes de gerncia de risco. Na 2 reunio
haviam 6 riscos, onde 4 apresentaram progresso com as aes de mitigao, 1 ainda estava
em fase de avaliao, e 1 no apresentava progresso com as aes de mitigao. Na quarta
e ltima reunio de riscos, 1 risco aconteceu, 3 riscos foram eliminados, e 2 riscos
continuaram existindo at o fim do projeto, porm no se manifestaram.

Figura 40 - Resultado das aes da gerncia de riscos

Foi feita uma reviso da taxonomia de riscos adotada pela organizao, e foi consenso que
todas as categorias e fontes de riscos deveriam ser mantidas na taxonomia da organizao.
A Tabela 34 apresenta a taxonomia atualizada.
Tabela 34 - Taxonomia de Riscos da VendeSoft
Taxonomia de riscos da organizao
Categ
oria
Equipe

Fonte de Risco
Problemas em
utilizar novas
tecnologias em
projetos
[OLIVEIRA06]

Justificativa
Falta de
profissionais na
equipe
treinados com
habilidades
para utilizao
de novas
tecnologias

Crono
grama

Falta ou
insuficincia de
tempo para
assegurar a
implementao das
mudanas
[OLIVEIRA06]

Integra
o
entre
Sistem
as

Necessidade de
integrao com
outros sistemas
pode afetar
desempenho do
sistema original
[THOMSETT03]

Os projetos
podem possuir
um curto prazo
para entrega; a
equipe pode
no se sentir
confiante em
atingir a meta
de prazo.
Os produtos
desenvolvidos
podem
necessitar de
integrao com
outros
sistemas.

Equipe

Falta de
Disponibilidade dos
membros da equipe
[THOMSETT03]
[JONES94]

Possibilidade
de sada dos
estagirios e
funcionrios no
meio dos
projetos.
Dispensas por
frias ou
atrasos.

Fornec
edores

Componentes
externos adquiridos
podem estar abaixo
da expectativa
[BOEHM91]
[JONES94]

Possibilidade
de aquisio de
componentes
de terceiros

Falta de Experincia
com o modelo de
processo da
organizao [DIR06]

Possibilidade
dos
funcionrios
no estarem
preparado para
o modelo de

Equipe

Tcnicas de
tratamento de
riscos
Transferncia
de
conhecimento;
treinam ento;
consultoria;
contratao de
profissionais
com
experincia.

Estimativa de
cronograma
detallhada,
desenvolvim ent
o incremental,
re-utilizao de
software e
limpeza dos
requisitos
Reviso da
documentao
do sistema
atual;
Contratao de
especialista;
Benchmark do
sistema atual
aps
integrao.
Horas extras;
contratao de
trabalhadores
temporrios;
contratao de
estagirios;
aumento
salarial;
oferecer
incentivos
extras; reunies
para obteno
de feedback.
Desenvolviment
o de um
contrato por um
advogado;
Anlise de
desempenho;
Checar as
referncias do
fornecedor.
Acompanhame
nto das
atividades;
Exigncia dos
produtos de
sada;

Limites para monitorao

Caso aps a 1 semana, a
habilidade de 50% dos
membros da equipe so
avaliadas insuficientes.

Caso o cronogram a geral

esteja atrasado em 2 dias;

Procedimento de
medio
Avaliao subjetiva
da habilidade dos
funcionrios
baseado no
acompanhamento
feito por outro
trabalhador com
experincia por 2
horas/dia
[suficiente,
insuficiente].
Resultado da
diferena de dias
entre o cronograma
planejado em
relao ao
cronogram a
realizado para o dia
da avaliao.

Caso o Benchmark do sistema

atual mostra principais queries
com perda de 15% de
desempenho.

Resultados dos
testes de
benchmark com as
principais queries
do sistema
definidas pelo
analista snior
[Passou, no
passou].

Mais de um funcionrio de um
projeto em frias; Mdia de
ausncia dos funcionrios
superior a 2 horas por sem ana;

Quantidade de
horas de atraso
(sem justificativa)
do funcionrio.

Componente entregue no
atender ao requisito com base
em testes de desempenho
abaixo de 10% do desejado
(requisito) e menos de 100%
dos testes de funcionalidade
no atendidos aps 10 testes
realizados ao integrar o
componente ao sistema;

Resultado dos
testes de
benchmark [passou,
no passou];

Caso a quantidade diria de

artefatos produzidos fora dos
padres do processo seja
superior a 10;

Resultado dos
testes de integrao
realizado pelo
testador [Passou,
no passou].
Quantidade de
artefatos
produzidos fora do
padro (defeito).

Taxonomia de riscos da organizao

Categ
oria

Fonte de Risco

Justificativa
processo da
empresa

Integra
o
entre
Sistem
as

Documentao
inexistente
[OLIVEIRA06]

Equipe

Ambiente Fsico / de
Suporte para o time
[THOMSETT04]

Possibilidade
de integrao
com outros
sistemas que
no possuem
documentao
Computadores
ou ambiente
podem no ser
adequados
para as
atividades do
time

Tcnicas de
tratamento de
riscos
Treinamento;
Reunies
dirias de
status;
Contratao de
consultoria dos
desenvolvedore
s originais;

Investimento
em
computadores,
cadeiras,
mesas, luz etc.

Limites para monitorao

Caso no existir documentao

para menos de 70% das
funes

Reclamao de mais de 50%

da equipe sobre os aspectos
fsicos da organizao

Procedimento de
medio

Avaliao da
documentao por
funo do sistema
[Tem = 100%,
parcial = 50%, no
tem = 0%]
Avaliao realizada
por cada um dos
membros da equipe
[Ruim 0%, bom =
50%, timo = 100%]

Tambm foi acordado que nenhuma mudana nos parmetros ou na estratgia da gerncia
de risco deveria ser feita. A empresa ainda dispe dos mesmos recursos para a gerncia de
risco, tal como planejado na 1 iterao.
A segunda etapa da atividade de gerncia de riscos a avaliao de todos os riscos
levantados. Como o projeto foi concludo, o registro de riscos foi armazenado no RCO da
organizao. As lies aprendidas deste projeto sero bastante teis para outros projetos
da organizao.
Tabela 35 - Lies aprendidas no projeto
Lies Aprendidas
Id
Risco
5

Risco
(Se.. Ento...)
Se os estagirios
sarem da
organizao no meio
do projeto, Ento o
projeto poder sofrer
atrasos, uma vez que
os estagirios esto
assumindo
responsabilidades no
projeto
Se o time no tiver
habilidade com Java,
Ento possvel que
o prazo estimado no
seja cumprido, e que
o sistema no seja
elaborado com
qualidade

Aconteceu?
Sim

Lio Aprendida
Apenas obter o feedback no eficiente. necessrio que
os estagirios assumam menos responsabilidades no
projeto.
Ter contatos com profissionais com experincia, antes do
incio do projeto, foi fundamental para resolver o problema,
apesar do custo ter crescido.

No

Barney se mostrou um excelente instrutor, e esta

caracterstica poder ser usada quando for necessrio
trabalhar com outros projetos novamente.

Na terceira etapa da atividade de gerncia de riscos, foi avaliado o progresso das atividades
de tratamento de riscos. Apesar de no ter conseguido evitar o risco de o estagirio Tim sair
do projeto, foi possvel executar o plano de contingncia conforme definido no plano de
tratamento do risco. Foi consenso da equipe de riscos manter o tratamento de risco na
taxonomia de riscos.
A Figura 41 e a Figura 42 apresentam o monitoramento de dois riscos apresentados neste
exemplo, ao longo das 4 semanas de projeto.

90%

% da equipe com
habilidade em Java

80%
70%
60%

Equipe

50%

Limite

40%

LS

30%

LI

20%
10%
0%
1

Tempo (Semanas)

Figura 41 - Monitoramento do risco da equipe no ter habilidade com Java

Atraso Mdio
Semanal (em horas)

2.5

Tom
Tom as

Tas
1.5

Tim
Limite

LS
Limite

0.5
0
2

Tempo (em semanas)

Figura 42 - Atraso mdio (em horas) por semana dos estagirios

7 Concluso
Com a implantao da gerncia de riscos, a organizao pode se capacitar a lidar com as
incertezas que rondam o projeto, atuando de forma pr-ativa. Desta forma, evitando que os
riscos se tornem realidade, e aes com um custo maior do que as aes de gerncia de
riscos tenham que ser disparadas.
Como foi visto no exemplo do captulo 6, ao monitorar os limites, foram identificadas aes
que poderiam ser disparadas para tratar os riscos: Treinamentos foram realizados pela
prpria organizao, horas extras foram autorizadas para corrigir o atraso, testes de
benchmark foram realizados identificando problemas previamente. Todas estas aes
impediram que os riscos se tornassem realidade. Porm, mesmo com a gerncia de risco,
riscos podem se tornar realidade, tal como aconteceu na sada do estagirio. Neste caso, a
gerncia do projeto estava preparada, e uma soluo alternativa foi encontrada, mesmo que
tenha tido um custo maior do que o previsto no incio do projeto. O importante que o
projeto foi entregue dentro do prazo estabelecido.
Tambm foi identificado que, apesar do CMMI-SE/SW identificar as boas prticas da
gerncia de riscos em seqncia, medida que a gerncia de riscos realizada, no h
necessidade de seguir a ordem exata destas atividades. Pode-se, por exemplo, fazer uma
avaliao do progresso dos riscos, antes de decidir pela mudana de status da
probabilidade e do impacto dos riscos.
As tcnicas e mtodos apresentados por este guia foram selecionados com base na
simplicidade de execuo destes mtodos. Tcnicas de brainstorming, delphi e taxonomias
se mostraram mais adequadas realidade das MPEs, por usarem um conhecimento j
validado pelo mercado, e a medida que a gerncia de riscos realizada em diversos
projetos, uma base de conhecimento da prpria organizao gerada (taxonomias de risco,
opes de tratamento de riscos etc.) e a experincia dos integrantes da equipe do projeto
aumenta a cada projeto realizado, facilitando o consenso de opinies em reunies e a
identificao e anlise de novos riscos,.
Para avaliar a aplicabilidade deste guia na pratica esto previstos estudos de casos
aplicando o guia na pratica e com base nisto o guia ser continuamente melhorado.
Alm disto, espera-se que este guia possa servir tambm como uma guia para
desenvolvimento de uma ferramenta de gerncia de riscos, que atenda a todos os requisitos
levantados na anlise de ferramentas (Captulo 5).

Referncias Bibliogrficas
[AHERN03] AHERN, Dennis M.; CLOUSE, Aaron; TURNER, Richard. CMMI Distilled: A practical
Introduction to Integrated Process Improvement. Second Edition. Person, 2003.

[BASILI94] BASILI, Victor R. CALDIERA, Gianluigi. ROMBACH, H. Dieter. The Goal Question Metric
Approach. Encyclopedia of Software Engineering, Two Volume Set, New York City: John Wiley &
Sons, 1994. Disponvel em: <http://wwwagse.informatik.unikl.de/pubs/repository/basili94b/encyclo.gqm.pdf>. Acesso em: 19 Julho 2006.
[BOEHM91] BOEHM, Barry W. Software Risk Management: Principles and Practices. IEEE
Software 8 (1):32-41, 1991.
[CARR93] CARR, Marvin. KONDA, Suresh; MONARCH, Ira. Taxonomy-Based Risk Identification.
Technical Report CMU/SEI-93-TR-6 ESC-TR-93-183, SEI Software Engineering Institute, Carnegie
Mellon University, 1993.
[CS06] CS Solutions, Inc. Risk+. Disponvel em: <http://www.cssolutions.com/products/?Product=Risk%20Plus>. Acesso em: 25 Julho 2006.
[CSO06] Chief Security Officers. Enterprise Risk Assessment. Disponvel em:
<http://www.chiefsecurityofficers.com/era.htm>. Acesso em: 25 julho 2006.
[COLEMAN98] COLEMAN, Gerry; VERBRUGGEN, Renaat. A quality software process for rapid
application development. Software Quality Journal 7: 107-122, 1998.
[COOPER04] COOPER, Dale; GREY, Stephen; RAYMOND, Geoffrey; WALKER, Phil. Project Risk
Management Guidelines: Managing Risk in Large Projects and Complex Procurements. John
Willey & Sons, 2004.
[DELL06] DELL Small Business. Office Project 2003 Server CD w/ 5 CALs. Disponvel em:
<http://accessories.us.dell.com/sna/productdetail.aspx?sku=A0157392&cs=04&c=us&l=en>. Acesso
em: 24 Julho 2006.

[DIR06] DIR Departament of Information Resources. Generic Software Project Risk Factors.
Disponvel em: <http://www.dir.state.tx.us/eod/qa/risk/swrisk.htm>. Acesso em: 21 Abril 2006.

[DORNER97]. DORNER, William W. Using Excel for Data Analysis. Quality Digest Outubro 1997.
Disponvel em: <http://www.qualitydigest.com/oct97/html/excel.html>. Acesso em: 19 Julho 2006.

[ENGERT99] ENGERT, Pamela A.; LANSDOWNE, Zachary F.; Risk Matrix Userss Guide Version
2.2. Bedford, Massachusetts, 1999.

[FREIRE02] FREIRE, Emerson. Inovao e competitividade: O desafio a ser enfrentado pela

indstria de software. Campinas, 2002. Disponvel em:
<http://libdigi.unicamp.br/document/?code=vtls000242713>. Acesso em: 20 Julho 2006.
[GOLDPRACTICES06] DACS Gold Practices Website. Software Acquisition Gold Practice Formal
Risk Management. Disponvel em: <http://www.goldpractices.com/practices/frm/index.php>. Acesso
em: 25 Julho 2006.
[HIGUEIRA96] HIGUERA, Ronald P.;HAIMES, Yacov Y. Software Risk Management (CMU/SEI-96TR-012). Pittsburgh, PA.: Software Engineering Institute, Carnegie Mellon University, 1996
[IRM02] IRM UK Institute of Risk Management; AIRMIC Association of Insurance and Risk
Managers; ALARM Association of Local Authority Risk Managers. A Risk Management Standard.
2002. Disponvel em: <http://airmic.com/stats/track.asp?r=../Downloads/Pubs/AIRMIC_RiskManagement-Standard.pdf>. Acesso em: 25 Julho 2006.

[JONES04] JONES, Capers. Assesment & Control of Software Risks. Englewood Cliffs: PrenticeHall, 1994.

[KASSE04] KASSE, T. Practical Insight into the CMMI. Ed. Artech House. Massachussets, 2004.
[KULPA03] KULPA, Margaret K.; JOHNSON, Kent A. Interpreting the CMMI: A process
Improvement Approach. Auerbach Publications, 2003.
[KUNTZE06] KUNTZE, Guiton Csar. Guia de Planejamento de Projeto de Software. Trabalho de
Concluso de Graduao, So Jos, 2006.
[LEOPOLDINO04] LEOPOLDINO, Cludio Bezerra. Avaliao de Riscos em Desenvolvimento de
Software. Dissertao de Mestrado, Porto Alegre, 2004. Disponvel em:
<http://volpi.ea.ufrgs.br/teses_e_dissertacoes/td/002941.pdf>. Acesso em: 25 Julho 2006.
[LQPS06] LQPS. Laboratrio de Qualidade e Produtividade de Software. 2006. Disponvel em:
<http://ssooweb04.univali.br>. Acesso em: 13/05/2006.

[MACHADO02] MACHADO, Cristina. A-RISK: Um mtodo para identificar e quantificar risco de prazo
em projetos de desenvolvimento de software. Dissertao de Mestrado, Curitiba, 2002.
[MARTENS01] MARTENS, Cristina. A Tecnologia da Informao (TI) em Pequenas Empresas
Industriais do Vale do Taquari/RS. Porto Alegre, 2001. Disponvel em:
<http://professores.ea.ufrgs.br/hfreitas/projetos/gianti/arquivos/pequenas_empresas.pdf>. Acesso em:
21 Novembro 2005.

[MCT05] MCT. Ministrio da Cincia e Tecnologia. Qualidade e Produtividade no Setor de

Software Brasileiro: Resultados da pesquisa 2005. Disponvel em:
<http://www.mct.gov.br/sepin/Dsi/Quali2005/Public2005.htm>. Acesso em 26/08/2005.
[MICHAELIS02] MICHAELIS. Moderno Dicionrio da Lngua Portuguesa. So Paulo,
Melhoramento, 1998.

[NATWICK03] NATWICK, Gary. Integrated Metrics for CMMI and SW-CMM. CrossTalk The
Journal of Defense Software Engineering, Maio 2003. Disponvel em:
<http://www.stsc.hill.af.mil/crosstalk/2003/05/natwick.html>. Acesso em: 04 Julho 2006.
[OLIVEIRA06] OLIVEIRA, Kathia M.; WEBSTER, Knia P. B.; ANQUETIL, Nicolas. Riscos para
Manuteno de Software. Artigo 2.22. Disponvel em:
<http://www.mct.gov.br/index.php/content/view/14515.html>. Acesso em: 25 Julho 2006.
[PMI04] PMI. Project Management Institute. Guia PMBOK: Um guia do conjunto de
conhecimentos em gerenciamento de projetos. 2004. Disponvel em:
<http://www.pmi.org/info/default.asp>. Acesso em: 15/08/2005.
[MICROSOFT06] Microsoft Office Online. MS Project 2003. Disponvel em:
<http://office.microsoft.com/pt-br/FX010857951046.aspx>. Acesso em: 10 Julho 2006.
[PSM06] Practical Software and System Meaurement. Practical Software Measurement: A
foundation objective project management, v. 4.0b1. Disponvel em:
<http://www.psmsc.com/PSMGuide.asp>. Acesso em: 19 Julho 2006.
[RADAR06] ICE - Integrated Computer Engineering. Risk Radar. Disponvel em:
<http://www.ascriskradar.com/Products.aspx?p=Products_RiskRadar>. Acesso em: 25 Julho 2006.

[RAMP03] Office of Information Technology Services. RAMP Risk Assessment Management

Process. North Carolina, USA, 2003.

[ROVERE01] ROVERE, R. L. Perspectivas das micro, pequenas e mdias empresas no Brasil.

Revista Econmica Contempornea. UFRJ, 2001. Disponvel em:
<http://www.ie.ufrj.br/revista/pdfs/perspectivas_das_micro_pequenas_e_medias_empresas_no_brasil.
pdf>. Acesso em: 21 Novembro 2005.
[ROUILLER01] ROUILLER, A. C. Gerenciamento de Projetos de Software para Empresas de
Pequeno Porte. Tese de Doutorado, UFPE. 2001. Disponvel em:
<http://www.qualidadesoftware.org.br>. Acesso em: 11 Novembro 2005.
[RUBIK06] RUBIK, Rafael. Guia para Medio e Anlise de Projetos de Software em Micro e
Pequenas Empresas Alinhado ao CMMI-SE/SW. Trabalho de Concluso de Graduao, So Jos,
2006.

[SILVEIRA06] SILVEIRA, Filipe P.; KNOB, Flvio F. RiskFree Uma ferramenta de apoio
gerncia de riscos em projetos de software. Trabalho de Concluso de Graduao, Porto Alegre,
2005.
[SANTOS04] SANTOS, Cssio. Gerncia de Risco na Modernizao de Sistemas Legados.
Dissertao de Mestrado, So Paulo, 2004. Disponvel em:
<http://www.pcs.usp.br/~lucia/teses/CassioSantos.pdf>. Acesso em: 25 julho 2006.
[SEI01] SEI. Software Engineering Institute. CMMI for Systems Engineering/Software Engineering,
Version 1.1 (CMMI-SE/SW, V1.1). Continuous Representation. Dezembro, 2001.Disponvel em:
<http://www.sei.cmu.edu/cmmi>. Acesso em: 15 Agosto 2006.
[SEBRAE05] SEBRAE. Servio Brasileiro de Apoio s Micro e Pequenas Empresas. Boletim
Estatstico de Micro e Pequenas Empresas, 2005. Disponvel em:
<http://www.sebrae.com.br/br/mpe_numeros/empresas.asp>. Acesso em: 25 Julho 2006.

[SEBRAE06] SEBRAE. Servio Brasileiro de Apoio s Micro e Pequenas Empresas. Legislao

Bsica da Micro e Pequena Empresa. Disponvel em:
<http://www.sebrae.com.br/br/aprendasebrae/estudosepesquisas_legislacao.asp>. Acesso em: 25
Julho 2006.
[SOMMERVILLE03] SOMMERVILLE, I. Engenharia de Sotware. So Paulo: Addison-Wesley, 2003.

[THOMSETT02] THOMSETT, Rob. Radical Project Management. Prentice Hall PTR, 2002.
[TRIMS06] BMP Best Manufactoring Practices. TRIMS - Technical Risk Identification and
Mitigation System. Disponvel em: <http://www.bmpcoe.org/pmws/download/trims.html>. Acesso em:
09 Julho 2006.

Anexo A Taxonomia de Riscos genrica para projetos de Software [DIR06]

Este taxonomia de riscos est disponvel on-line no site do DIR Departament of
Information Resources [DIR06], e foi traduzida livremente pelo autor. Alm desta taxonomia,
o DIR disponibiliza outras taxonomias para projetos genricos (inclusive no relacionados a
software), projetos de aquisio de software e projetos de software desenvolvidos por
terceiros.
O time do projeto deve usar essa tabela para facilitar pensar em riscos do projeto. O time
pode decidir que fontes de riscos so relevantes ao projeto. E ento identifica qual o nvel do
risco baseado nos indcios do risco.
Quando o projeto terminar, a organizao deve revisar se h novas fontes de riscos a serem
adicionadas, ou se h novos indcios que poderiam ser modificados para ajudar a outros
projetos a identificar riscos.

Fontes de Risco

Baixo

Mdio

Alto

Misso e Objetivo
1

Projeto
adequado a
organizao
cliente

Diretamente
suporta as
misses e
objetivos da
organizao
cliente
Diretamente
suporta misses e
objetivos da
organizao
patrocinadora

Indiretamente
impacta nos
objetivos ou
misso da
organizao
cliente
Indiretamente
impacta nos
objetivos ou
misso da
organizao
patrocinadora

No suporta ou
no est
relacionado a
organizao
cliente

Projeto
adequado a
organizao
patrocinadora

Percepo do
cliente

Cliente espera que

esta organizao
prove este

Organizao que
est trabalhando
no projeto em uma
area no esperada
pelo

Projeto no est
relacionado
produtos ou
servios
prioritrios desta
organizao

Fluxo de Trabalho

Pequena ou
nenhuma
mudana no fluxo
de trabalho

Ser mudado
algum aspecto ou
existir um
impacto pequeno
no fluxo de
trabalho

Significativamente
muda o fluxo de
trabalho ou os
mtodos da
organizao

Objetivos dos
projetos no so
conflitantes,
porm oferecem
pouco suporte ao
programa

Objetivo dos
projetos esto em
conflito, direta ou
indiretamente

No suporta ou
no est
relacionado a
organizao
patrocinadora

Gerenciamento do Programa
5

Conflito de
Objetivos

Objetivos dos
projetos do
programa so
complementares e
suportados pelo
program a

Alto

No Aplicvel

Mdio

Classificao
Baixo

Indcios

Notas

Fontes de Risco

Baixo

Mdio

Alto

Conflito de
recursos

Projetos do
program a
compartilham
recursos sem
problem a

Projetos do
programa
compartilham
recursos com
cuidados para
evitar problemas

Projetos do
programa
frequentemente
precisam dos
mesmos recursos
ao mesmo tempo,
ou competem por
estes recursos no
mesmo oramento

Conflito com
clients

Mltimos clients
do program a
possuem os
mesmos
interesses

Mltiplos clientes
do programa tem
necessidades
diferentes, porm
no h conflito

Mltiplos clientes
do programa
tentam direcionar
o programa para
direes distintas

Liderana

Programa possui
um gerente de
programa ativo
que coordenada o
program a

Programa temuma
pessoa ou um
time responsvel
pelo program a,
mas incapaz de
gastar tempo
suficiente para
liderar
efetivamente

Programa no tem
lder, ou conceito
de gerente de
program a em uso

Experincia do
gerente do
programa

Gerente do
programa tem
forte experincia
no domnio

Gerente do
programa tem
experincia no
domnio, e
capaz de
conseguir
respostas com
especialistas

Gerente do
programa novo
no domnio

1
0

Definio do
programa

Programa bem
definido, com um
escopo
gerencivel por
esta organizao

Programa bem
definido, porm
incapaz de ser
gerencivel por
esta organizao

Programa no
bem definido ou
carrega objetivos
conflitantes no
prprio escopo

Nenhuma deciso
com influncia
poltica da
organizao foi
tomada

Projeto tem muitas

decises motivas
por influncias
polticas, tais
como usar um
fornecedor
selecionado por
razes policas, ao
invs de
qualificaes

Projeto tem uma

variedade de
influncias
polticas ou a
maior parte das
decises so
feitas em salas
fechadas

Direo das decises

1
1

Influncias
polticas

Alto

No Aplicvel

Mdio

Classificao
Baixo

Indcios

Notas

Fontes de Risco

Baixo

Mdio

Alto

1
2

Data conveniente

Data para entrega

foi acertada por
um processo
razovel de
comprometimento

Data est baseada

na necessidade de
estar alinhada a
uma
demonstrao ao
mercado, evento
ou no est
relacionado a uma
estimativa tcnica

Data est
totalmente
associada a uma
demonstrao ao
mercado, evento
ou outro marco
deste tipo; pouca
considerao
estimativa do time
do projeto.

1
3

Tecnologia
atrativa

Tecnologia
selecionada
usada por algum
tempo

Projeto est sendo

feito levando em
considerao o
aprendizado de
uma nova
tecnologia

Projeto est sendo

feito para mostrar
uma nova
tecnologia ou
como uma
desculpa para
trazer a tecnologia
para dentro da
organizao

1
4

Soluo de curto
prazo

Projeto tem
necessidades de
curto prazo, sem
comprometer
perspectivas de
longo prazo

Projeto focado
em solues de
curto prazo para
um problema, com
pouco
entendim ento do
que necessrio
a longo prazo

Time do projeto
explicitamente foi
direcionado a
ignorer
perspectivas a
longo prazo e
focar em
completar a
entrega a curto
prazo

1
5

Estabilidade da
organizao

Pouca ou
nenhuma
mudana na
gernia ou
estrutura
esperada

Alguma mudana
de gerncia ou
reorganizao
esperada

Gerncia ou
estrutura da
organizao est
continuamente ou
rapidamente
mudando

1
6

Papis e
responsabilidades
da organizao

Indivduos da
organizao
entendem seus
papis e
responsabilidades
e dos outros
tambm

1
7

Polticas e
padres

Padres e
polticas de
desenvolvimento
so definidos e
cuidadosamente
seguidos

Indivduos
entendem seus
papis e
responsabilidades,
mas no possuem
certeza de quem
responsvel pelo
trabalho de outros
grupos
Padres e
polticas de
desenvolvimento
existem, mas so
fracos, ou no so
seguidos

Muitos na
organizao no
esto certos ou
no tem
conhecimento de
quem
responsvel pelas
atividades na
organizao
Padres e
polticas no
existem, ou so
definidos de forma
fraca, e no so
usados

Alto

No Aplicvel

Mdio

Classificao
Baixo

Indcios

Notas

Gerncia da Organizao

Fontes de Risco

Baixo

Mdio

Alto

1
8

Suporte da
gerncia

Fortemente
comprometida
com o sucesso do
projeto

Algum
comprometimento,
no total

Pouco ou nenhum
suporte

1
9

Envolvim ento da
direo

Visvel e forte
suporte

Suporte
occasional, prove
ajuda em
questes quando
perguntadas

No h suporte
visvel, no h
ajuda em
questes no
resolvidas

2
0

Objetivos do
projeto

Objetivos de
projeto verificados,
requisitos
razoveis

Alguns objetivos
do projeto,
medidas podem
ser questionadas

Objetivos do
projeto no esto
estabelecidos ou
objetivos no
esto medidos

Usurios esto
altamente
envolvidos com o
time do projeto,
fornecendo
valiosas
informaes
Usurios com
grande
experincia em
projetos imilares;
possuem idias
especificas de
como as
necessidades
podem ser
atendidas
Usurios aceitam
conceitos e
detalhes do
sistema; processo
est para ser
aprovado pelos
usurios

Usurios
participam de
forma modesta,
impacto moderado
no sistema

Envolvimento do
usurio mnimo ou
nenhum
envolvimento do
usurio; pouca
informao do
usurio
Usurios no tem
experincia em
projetos imilares;
no esto certos
de como as
necessidades
podem ser
atendidas

Usurios aceitam
a maior parte dos
conceitos e
detalhes do
sistema; processo
est para ser
aprovado pelos
usurios

Usurios no
aceitam nenhu
conceito ou
detalhes de design
do sistema

Necessidade de
treinamento do
usurio
considerada;
trienam ento em
progresso ou
plano existe
user training

Necessidade de
treinamento do
usurio
considerada;
nenhum
treinamento est
sendo
considerado ou
nenhum plano foi
desenvolvimento

Requisitos no
identificados ou
no endereados

Cliente/Usurio
2
1

Envolvim ento do
usurio

2
2

Experincia do
usurio

2
3

Aceitao do
usurio

2
4

Necessidade de
treinam ento do
usurio

Usurios tem
experincia em
projetos similares
e tem as
necessidades em
mente

Alto

No Aplicvel

Mdio

Classificao
Baixo

Indcios

Notas

Fontes de Risco

2
5

Justificativa do
usurio

Baixo

Mdio

Alto

Justificativa do
usurio
completa,
acurada, clara

Justificativa do
usurio foi dada,
completa com
algumas questes
sobre
aplicabilidade

Nenhuma
justificativa
satisfatria para o
sistema

Parmetros do projeto
2
6

Tamanho do
projeto

Pequeno, no
complexo, ou
facilmente
decomposto

Mdio,
complexidade
moderada, pode
ser decomposto

Grande, altamente
complexo, ou no
pode ser
decomposto

2
7

Restries de
Hardware

Poucas ou
nenhuma restrio
de hardware ou
plataforma nica
imposta

Algumas
imposies de
restrio de
hardware; vrias
plataformas

Imposies de
restries de
hardware
significativas;
mltiplas
plataformas

2
8

Componentes
reutilizveis

Componentes
disponveis e
compatveis com a
estratgia

Componentes
disponveis, mas
precisam de
alguma reviso

2
9

Componentes
fornecidos

Components
disponveis e
diretamente
usveis

Componentes
trabalham na
maior parte das
circustncias

Componentes
identificados,
preciso de
modificaes
srias para serem
usados
Componentes
falham em certos
casos, esto
atrasados, ou
incompatveis com
partes da
estratgia

3
0

Tamanho do
oramento

Oramento
alocado suficiente

Oramento
alocado
questionvel

Oramento
duvidvel est
disponvel

3
1

Restries do
oramento

Fundos alocasdos
sem restries

Algumas questo
sobre a
disponibilidade
dos fundos

Alocao em
dvida ou
provavelmente ir
mudar sem notcia
prvia

3
2

Controle de
custos

Bem estabilizados,
Existem

Sistema existe,
fraco nas areas

Ausncia de
sistema ou no
existe

3
3

Comprom etiment
o de entrega

3
4

Desenvolvimento
do cronograma

Datas de
comprometimento
estveis
Time concorda
que o cronograma
aceitvel e pode
ser cumprido

Alguns
comprometimento
s incertos
Time acha que
uma fase do plano
est bastante
agressiva

Instveis,
comprometimento
s flutuantes
Time concorda
que duas ou mais
fases do
cronograma esto
impossveis de ser
atingidas

Alto

No Aplicvel

Mdio

Classificao
Baixo

Indcios

Notas

Fontes de Risco

Baixo

Mdio

Alto

Alto

No Aplicvel

Mdio

Classificao
Baixo

Indcios

Notas

Produto
3
5

Estabilidade dos
requisitos

3
6

Requisitos
completos e
claros

3
7

Testabilidade

3
8

Pouca ou
nenhuma
mudana
esperada ao
projeto aprovado
(baseline)
So
completamente
especificados e
claramente
escritos

Alguma mudana
esperada em
relao ao
baseline definido

Muitas mudanas
ou baseline
definida sem
acordo

Alguns requisitos
so incompletos
ou no so claros

Alguns requisitos
esto apenas na
cabea do cliente

Requisitos do
produto so fceis
de testes, planos
de teste esto a
caminho

Parte do produto
dificil de teste, ou
pouco plano est
sendo feito

Maior parte do
produto dificil de
teste, ou nenhum
plano est sendo
feito

Dificuldade de
Design

Interfaces bem
definidas; design
bem entendido

Incerteza de como
elaborar o design,
ou aspectos do
design ainda
precisam ser
definidos

Interfaces no
esto definidas ou
controladas;
tendem a mudar

3
9

Dificuldade de
implementao

Algoritimos e
design so
razoveis para o
time implementer

Algoritimos e/ou
design tem
elem entos que
so dificeis para o
time implementar

4
0

Dependncias do
sistema

Dependncia de
outras partes do
sistema e da
esforo de
software
(hardware,
mudanas de
processo,
documentao,
) esto
claramente
definidas

Alguns elementos
do sistema esto
bem entendidos e
planejados; outros
ainda no so
compreendidos

Algoritimos e/ou
design tem
componentes que
este time ter
dificuldade de
implementar
Nenhum plano
claro ou prazo
para integrar o
sistema inteiro

Implantao
4
1

Recursos de
hardware para
implantao

Maduros, sistema
com capacidade
de crescimento,
flexvel

Disponvel,
alguma
capacidade de
crescimento

Sem possibilidade
crescimento, ou
flexibilidade

4
2

Resposta a outros
fatores de
desempenho

Rapidamente se
adapta aos limites
necessrios;
anlises foram
feitas

Opera
ocasionalmente
nos limites

Opera
continuamente
nos nveis de
limite

Fontes de Risco

Baixo

Mdio

Alto

4
3

Impacto no
service do cliente

Requer pouca
mudana ao
service do cliente

Requer algumas
mudanas ao
service do cliente

Requer grandes
mudanas
estratgia do
servio do cliente
ou aos produtos
oferecidos

4
4

Migrao de
dados requerida

Pouco ou nenhum
dado precisa ser
migrado

Muitos dados para

serem migrados,
mas descries da
estrutura e do uso
esto disponveis

Muitos dados para

serem migrados;
muitos tipos de
bases de dados
ou no h boas
descries de
onde est o que

4
5

Plano piloto

Lugar ou time para

plano piloto est
disponvel e
interessado em
participar

Os lugares
disponveis no
so cooperativos
ou j esto em
crise

4
6

Interfaces
externas de
hardware e
software

Pouca ou
nenhuma
integrao ou
interface
necessria

Plano piloto
precisa ser feito
com vrios lugares
(interessados em
participar) ou com
um que precisa de
muita ajuda
Alguma integrao
ou interface
necessria

4
7

Anlise de
alternative

Anlise de
alternativas
completa, todas
consideradas,
suposies
verificadas

Anlise no est
completa, nem
todas as
alternativas foram
consideradas, ou
suposies com
defeitos

4
8

Processo de
comprometimento

Mudanas aos
comprometimento
s so feitas sem
reviso ou
envolvimento do
time

4
9

Abordagem de
Garantia de
Qualidade

Mudanas de
comprometimento
s em escopo,
contedo, prazo
so revisadas e
aprovadas pelos
envolvidos
Sistema de
Garantia de
Qualidade
estabilizado,
seguido, efetivo

Anlise de
alternativas
completa, algumas
suposies
questionveis ou
alternativas no
foram
completamente
consideradas
Mudanas aos
comprometimento
s so
comunicadas a
todos os
envolvidos
Procedimentos
estabelecidos,
mas no so
seguidos ou
efetivados

No h processo
de garantia de
qualidade ou
procedimentos
estabelecidos

5
0

Documentao de
desenvolvimento

Algumas
deficiencias, mas
disponvel

No existe

Alto

No Aplicvel

Mdio

Classificao
Baixo

Indcios

Notas

Interface
extensivas
requeridas

Processo de Desenvolvimento

Correta e
disponvel

Fontes de Risco

Baixo

Mdio

Alto

5
1

Uso de um
processo de
engenharia
definido

Processo de
Desenvolvimento
existe,
estabiilizado,
efetivo, seguido
por um time

Processo
estabelecidos,
mas no
seguido ou no
efetivo

Nenhum processo
formal usado

5
2

Identificao
prvia de defeitos

peer reviews so
feitas

peer reviews so
usadas
esporadicamente

Time espera que

os defeios sejam
encontrados
durante a fase de
testes

5
3

Rastream ento de
defeitos

Rastreamento de
defeitos definido,
consistente e
efetivo

Nenhum processo
existe para
rastrear defeitos

5
4

Controle de
mudanas para
produtos de
trabalho

Processo de
controle de
mudanas formal
existe, seguido,
efetivo

Processo de
Rastream ento de
defeitos definido,
porm usado de
forma
inconsistente
Proceso de
controle de
mudanas existe,
mas no
seguido ou no
efetivo

Nenhum processo
de controle de
mudanas
usado

Ambiente de desenvolvimento
5
5

Facilidades
fsicas

Pouca ou
nenhuma
modificao
necessria

Alguma
modificao
necessrial;
algumas existents

Vrias
modificaes
necessrias, ou
facilidades no
existentes

5
6

Plataforma de
hardware

Estvel, nenhum a
mudana
esperada,
capacidade
suficiente

Algumas
mudanas esto
evoluindo, mas
controladas

Plataforma sendo
desenvolvida junto
com o software

5
7

Disponibilidade
de ferramentas

Existem,
documentadas,
validadas

Disponvel,
validada, algum
desenvolvimento
necessrio (ou
pouca
documentao)

5
8

Suporte do
fornecedor

Suporte complete
por um preo
razovel, e no
tempo necessrio

5
9

Adequabilidade
do contrato

Contrato com o
cliente tem bons
termos,
comunicao com
o time boa

Suporte adequado
ao preo
contratado, tempo
de resposta
adequado
Contrato tem
algumas questes
em aberto que
poderiam
interromper
esforos de
trabalho do time

No esto
validadas,
proprietrias ou
muito
desenvolvimento
necessrio; no
h documentao
Pouco ou nenhum
suporte, alto
custom, e/ou
tempo de resposta
no adequado
Contrato tem
requisitos
incmodos ou que
causam trabalho
extra para estar
em conformidade

6
0

Recuperao de
desastre

Todas as reas
seguem diretrizes
de segurana;
backup de dados

Algumas medidas
de segurana
existe; backups
so feitos;

Nenhuma medida
de segurana
existe; no h
backup;

Alto

No Aplicvel

Mdio

Classificao
Baixo

Indcios

Notas

Fontes de Risco

Baixo

Mdio

Alto

so feitos; sistema
de recuperao de
desastre existe;
procedimentos
so seguidos;
all areas following
security
guidelines; data
backed up;
disaster recovery
system in place;
procedures
followed

recuperao de
desastre
considerada, mas
h ausncia de
procedim entos ou
no so seguidos

recuperao de
disastre no
considerada.

Gerncia de Projeto
6
1

Abordagem de
Gerncia de
Projeto

Planejamento de
produto e
processo e
monitorao
existem

Planejamento e
monitorao
precisam de
melhorias

Planejamento ou
monitorao fraca
ou no existente

6
2

Comunicao da
gerncia de
projeto

Claramente
comunica
objetivos e status
entre o time e o
resto da
organizao

Comunica alguma
das informaes
algumas vezes

Raramente
comunica
claramente com o
time ou com os
outros que
precisam ser
informados sobre
o status do time

6
3

Experincia da
gerncia de
projeto

Gerncia de
projeto muito
experiente em
projetos similares

Gerncia de
projeto tem uma
experincia
moderada ou tem
experincia com
diferentes tipos de
projeto

Gerncia de
projeto no tem
experincia com
este tjpo de
projeto ou novo
na gerncia de
projetos

6
4

Atitude da
gerncia de
projeto

Fortemente
comprometida
com o sucesso do
projeto

Interessada em
fazer o que
necessrio

No se preocupa
muito com o
projeto

6
5

Autoridade da
gerncia de
projeto

Tem uma linha de

gerenciamento ou
autoridade official
que permite a
efetividade da
liderana de
projeto

Tem a
possibilidade de
influenciar os
indivduos,
baseando-se nas
relaes pessoais

6
6

Suporte a
gerncia de
projeto

Suporte completo
do time

Suporte da maior
parte do time, com
algumas reservas

Tem pouca
autoridade na
estrutura da
organizao, e
pouco poder
pessoal para
influenciar
decises e
recursos
Nenhum suporte
visvel, gerente
apenas no nome

Time do projeto

Alto

No Aplicvel

Mdio

Classificao
Baixo

Indcios

Notas

Fontes de Risco

Baixo

Mdio

Alto

6
7

Disponibilidade
dos membros do
time

Existe, poucas
mudanas
esperada; poucas
interrupes para
apagar fogo

Disponvel,
alguma mudana
esperada; algum
apagar fogo
esperado;

Alta mudana
esperada, no
est disponvel;
time gasta a maior
parte do tempo em
apagar fogo.

6
8

Conjunto de
habilidades do
time

Bom conjunto de
disciplinas

Algumas
disciplinas
representadas de
forma inadequada

Algumas
disciplinas no
so representadas

6
9

Experincia na
aplicao

Experincia
extensive no time
em projetos como
este

Alguma
experincia em
projetos similares

Pouca ou
nenhuma
experincia em
projetos similares

7
0

Experincia com
hardware e
software do
projetos

Alta experincia

Mdia experincia

Baixa experincia

7
1

Experincia com
o processo

Experincia
extensive com o
processo

Alguma
experincia com o
processo ou
extensive
experincia com
outro processo

Pouca ou
nenhuma
experincia com
um processo
definido

7
2

Treinam ento do
time

Plano de
treinamento
existe,
treinam ento est
sendo realizado

Nenhum plano de
treinamento ou
treinamento est
disponvel

7
3

Esprito e atitude
do time

Fortemente
comprometido
com o sucesso do
projeto;
cooperativo

Treinamento de
algumas reas
no est
disponvel, ou
treinamento
planejado para o
futuro
Interessado em
fazer o que
necessrio ser
feito para o
trabalho ser
completado.

7
4

Produtividade do
time

Todos os marcos
foram atendidos,
entregas no tempo
certo,
produtividade alta

Marcos atendidos,
alguns atrasos nas
entregas,
produtividade
aceitvel

Produtividade
baixa, marcos no
atendidos, atrasos
nas entregas

7
5

Experincia no
domnio (rea da
aplicao)

Time com bom

background com o
domnio da
aplicao

Alguma
experincia com o
domnio no time,
ou habilidade em
chamar
especialistas
quando

Nenhuma
experincia no
domnio no time,
nenhuma
disponibilidade de
especialistas

Pouco ou nenhum
comprometimento
no projeto; no
um time coeso

Alto

No Aplicvel

Mdio

Classificao
Baixo

Indcios

Notas

Fontes de Risco

Baixo

Mdio

Alto

necessrio

Tecnologia
7
6

Tecnologia
aplicada ao
projeto

Tecnologia
planejada para o
projeto foi bem
aplicada as
necessidades do
cliente e ao
problem a

Alguma da
tecnologia
aplicada no
adequada ao
problema ou
cliente

Tecnologia
seleciona no
adequada ao
cliente ou ao
problema

7
7

Experincia do
time com a
tecnologia

Bom nvel de
experincia do
time com a
tecnologia

Alguma
experincia com a
tecnologia

Nenhuma
experincia com a
tecnologia

7
8

Disponibilidade
de um
especialista na
tecnologia

Especialistas na
tecnologia esto
disponveis

Especialistas
disponveis em
outros locais da
organizao

7
9

Maturidade da
tecnologia

Tecnologia vem
sendo utilizada na
indstria por
algum tempo

Tecnologia bem
entendida na
indstria

Ser necessrio
conseguir ajuda
com especialistas
fora da
organizao
Tecnologia de
ponta

Manuteno
8
0

Complexidade de
design

Estruturalmente
mantido (baixa
complexidade
medida ou
projetada)

Alguns aspectos
so difceis de
manter
(complexidade
mdia)

Dificuldade
extrema de manter
(alta
complexidade)

8
1

Suporte de
pessoal

Existe, com
experincia,
nmero suficiente

Falta algumas
reas de
conhecimento

8
2

Suporte do
fornecedor

Suporte completo,
em um preo
razovel, e em um
tempo adequada

Suporte adequada
por um preo
contratado, e um
tempo de resposta
aceitvel

rea de
conhecimento
significante est
faltando
Pouco ou nenhum
suporte, alto
custom, e tempo
de resposta no
aceitvel

Alto

No Aplicvel

Mdio

Classificao
Baixo

Indcios

Notas

Anexo B Taxonomia de riscos baseada em questionrio [CARR93]

Esta taxonomia apresentada no artigo Taxonomy-Base Risk Identification [CARR93] e foi
traduzida livremente e adaptada pelo autor deste trabalho. Esta taxonomia foi criada pela
SEI e serve como um mtodo para facilitar a identificao sistemtica de riscos em um
projeto de software, por meio de um questionrio. As respostas ajudam o time do projeto a
identificar as fontes de risco do projeto.
A. Engenharia do produto
Aspectos tcnicos do trabalho a ser realizado
1.

Requisitos
a.

Estabilidade
[Os requisitos esto mudando medida que o produto est sendo produzido?]
[1] Os requisitos so estveis?
(No) (1.a) Qual o efeito no sistema?
Qualidade
Funcionalidade
Cronograma
Integrao
Design
Teste
[2] Interfaces externas esto mudando?

b.

Completos
[Existem requisitos ausentes ou especificados de forma incompleta?]
[3] Existe algum requisito a ser definido?
[4] Existem requisitos que deveriam estar na especificao mas no esto?
(Sim) (4.a) Voc capaz de incluir estes requisitos no sistema?
[5] O cliente tem requisitos no escritos ou esperados?
(Sim) (5.a) Existe alguma forma de capturar estes requisitos?
[6] As interfaces externas esto completamente definidas?

c.

Clareza
[Os requisitos no so claros ou precisam de interpretao?]
[7] Voc capaz de incluir entender estes requisitos da forma que foram escritos?
(No) (7.a) As ambiguidades esto sendo resolvidas de forma satisfatria?
(Sim) (7.b) No existe problemas de ambiguidade ou problemas de interpretao?

d.

Validade
[Os requisitos direcionam para o produto que o cliente tem em mente?]
[8] Existe algum requisito que pode no especificar o que o cliente realmente quer?
(Sim) (8.a) Como voc est resolvendo isso?
[9] Voc e o cliente entendem a mesma coisa sobre os requisitos?
(Sim) (9.a) Existe um processo para determiner isso?
[10] Como voc valida estes requisitos?
Prototipao
Anlise

 Simulao
e.

Implementvel
[Requisitos so implementveis a partir de uma viso analtica?]
[11] Existe algum requisito que dificil tecnicamente de implementar?
(Sim) (11.a) Quais so eles?
(Sim) (11.b) Porque elas so difceis de implementar?
(No) (11.c) Foram feitos estudos de viabilidade para estes requisitos?
(Sim) (11.c.1) O quanto confidente voc est a respeito das questes feitas nestes estudos?

f.

Histrico
[Os requisitos especificam algo nunca feito anteriormente, ou antes, ou que a sua organizao no tenha
feito antes?]
[12] Existe algum requisito do tipo estado da arte (Tecnologias, mtodos, linguagens, hardware)?
(No) (12.a) Algum destes novo para voc?
(Sim) (12.b) O programa tem conhecimento suficiente nestas reas?
(No) (12.b.1) Existe um plano de aquisio destas conhecimentos nestas reas?

g.

Grau de Dificuldade
[Os requisitos especificam um produto maior, mais complexo, ou requerem uma organizao maior do que
na experincia da companhia?]
[13] O tamanho e a complexidade do sistema uma preocupao?
(No) (13.a) Voc j fez algo deste tamanho e complexidade antes?
[14] O tamanho requer uma organizao maior que o usual para a sua empresa?

2.

Design
a.

Funcionalidade
[Existem problemas em potencial em atingir os requisitos de funcionalidade?]
[15] Existe algum algoritmo que pode no satisfazer os requisitos?
(No) (15.a) Algum dos algoritmos ou designs que no respeitem os requisitos?
[16] Como voc determina a implentabilidade dos algoritmos e designs?
Prototipao
Modelagem
Anlise
Simulao

b.

Dificuldade
[O design e a implementao sero difceis de ser alcanados?]
[17] Algum design depende de suposies realisticas ou otimistas?
[18] Existe algum requisito ou funo que so difceis de realizar o design?
(No) (18.a) Voc tem solues para estes requisitos?
(Sim) (18.b) Quais so os requisitos?
Porqu eles so difceis?

c.

Interfaces
[Existe interfaces internas (hardware and software) bem definidas e controladas?]
[19] As interfaces internas so bem definidas?
Software-para-software
Software-para-hardware
[20] Existe um processo para definir estas interfaces internas?
(Sim) (20.a) Existe um processo de controle de mudana para interfaces internas?

[21] O hardware est sendo desenvolvido em paralelo com o software?

(Sim) (21.a) Existem especificaes de hardware mudando?
(Sim) (21.b) Todas as interfaces com software foram definidas?
(Sim) (21.c) Existiro modelos de design que podem ser usados para testar o software?
d.

Desempenho
[Existe uma exigncia rigorosa de tempo de resposta ou taxa de transmisso?]
[22] Existem problem as com desempenho?
Taxa de transmisso
Program a eventos de tempo real assincronos;
Resposta em tempo real;
Tempo de recuperao;
Tempo de resposta;
Resposta, conteno ou acesso ao banco de dados
[23] Anlise de desempenho foi feita?
(Sim) (23.a) Qual o seu nvel de confiana na anlise de desempenho?
(Sim) (23.b) Voc tem um modelo para rastrear o desempenho no design e na implementao?

e.

Testvel
[ possvel ou impossvel testar o produto?]
[24] O software sera fcil de ser testado?
[25] O design inclue facilidades para ajudar no teste?
[26] Os testadores esto envolvidos na anlise de requisitos?

f.

Restries de hardware
[Existem restries fortes no hardware a ser utilizado?]
[27] O hardware limita sua habilidade de alcanar requisitos?
Arquitetura
Capacidade de Memria
Taxa de transmisso
Resposta em tempo real
Tempo de resposta
Tempo de recuperao
Desempenho do banco
Funcionalidade
Confiana
Disponibilidade

g.

Softwares de terceiros
[Existe problemas com softwares usados pelo programa, mas no foram desenvolvidos pelo programa?]
Se software reutilizado ou refeito existe...
[28] Voc est usando software reutilizvel ou refeito no desenvolvido pelo programa?
(Sim) (28.a) Voc prev algum problema?
Documentao
Desempenho
Funcionalidade
Entrega a tempo
Customizao

Se software COTS est sendo usado...

[29] Existe algum problema em usar software COTS (commercial off-the-shelf)?
Documentao insuficiente para determinar interfaces, tamanho ou desempenho
Pouca documentao
Requer uma grande quantidade de memria para armazenamento
Dificuldade de realizar interfaces com a aplicao
No foi totalmente testado
Possui problemas (bugs)
No mantido de forma adequada
Resposta do vendedor lenta
[30] Voc prev algum problem a em integrar atualizaes ou revises do software COTS?
3.

Codificao e teste de unidade

a.

Implemenvel
[A implementao do design difcil ou impossvel?]
[31] Existe alguma parte da implementao do produto no completamente definida pelo design?
[32] Os algoritimos selecionados e o design so fceis de implementar?

b.

Testes
[O nvel e o tempo para os testes de unidade est adequado?]
[33] Voc com ea os testes de unidade antes de verificar o cdigo em relao ao design?
[34] Testes de unidades suficientes foram especificados?
[35] Existe tempo suficiente para executar todos os testes de unidade que voc esta pensando em
realizar?
[36] Caso exista problems de prazo, compromissos futuros sero feitos em relao aos testes de
unidade?

c.

Codificao/Implementao
[Existe algum problema com codificao ou implementao?]
[37] As especificaes de design possuem detalhes suficiente para escrever o cdigo?
[38] O design est sendo alterado enquanto o cdigo est sendo feito?
[39] Existem limitaes que fazem com que o cdigo seja difcil de escrever?
Tempo de resposta
Memria
Armazenamento externo
[40] A linguagem adequada para produzir o software neste programa?
[41] Existem mltiplas linguagens usadas neste programa?
(Sim) (41.a) Existe compatibilidade de interface entre os cdigos produzidos pelos diferentes
compiladores?
[42] O computador de desenvolvimento o mesmo que o computador que ser usado em produo?
(No) (42.a) Existem diferenas de compiladores entre os dois?
Se hardware produzido pelo programa est sendo usado...
[43] As especificaes de hardware adequadas para codificar o software?
[44] As especificaes de hardware esto mudando enquanto o cdigo est sendo escrito?

4.

Integrao e teste
a.

Ambiente
[O ambiente de teste e integrao adequado?]
[45] Existir hardware suficiente para realizar a integrao e o teste de forma adequada?
[46] Existe algum problema em crier cenrios realisticos e testar os dados para demonstrar algum

requisito?
Trfego de dados especificado
Resposta de tempo real
Tratamento de eventos assncronos
Interao multi-usurio
[47] Voc capaz de verificar o desempenho com facilidade?
[48] Hardware ou software facilita o teste?
(Sim) (48.a) o suficiente para todos os testes?
b.

Produto
[A definio da interface inadequada, facilidades inadequadas ou tempo insuficiente?]
[49] O hardware especificado para produo estar disponvel quando necessrio?
[50] Critrios de aceitao foram acordados para todos os requisitos?
(Sim) (50.a) Existe um acordo formal?
[51] As interfaces externas esto definidas, documentadas e indicadas na baseline?
[52] Existem algum requisito que sera difcil de testar?
[53] Suficientes integraes do produto foram especificadas?
[54] Tempo adequado foi alocado para integrao do produto ou teste?
Se COTS...
[55] Os dados do fornecedor sero aceitos na verificao de requisitos alocados para produtos COTS?
(Sim) (55.a) O contrato est claro em relao a isto?

c.

Sistema
[A integrao de sistema est no coordenada, com pouca definio de interfaces, ou facilidades
inadequadas?]
[56] Integraes de sistema suficiente foram especificadas?
[57] Tempo necessrio foi alocado para integrao e teste de sistema?
[58] Todos os contratados fazem parte do time de integrao?
[59] O produto ser integrado a um sistema existente?
(Sim) (59.a) Existe um perodo paralelo de paralizao deste sistema?
(No) (59.a.1) Como voc ir garantir que o produto ir funcionar de forma correta quando integrado?
[60] A integrao do sistema acontecer na organizao do cliente?

5.

Especialidades da Engenharia
a.

Manutenibilidade
[A implementao sera dificil de entender ou manter?]
[61] A arquitetura, design ou cdigo criam alguma dificuldade de manuteno?
[62] Existem pessoas de manuteno envolvidas logo no incio do design?
[63] A documentao do produto adequada para manuteno por uma organizao externa?

b.

Confiana
[Os requisitos de confiana e disponibilidade so difceis de ser alcanada?]
[64] Requisitos de confiana foram incorporados ao software?
[65] Requisitos de disponibilidade foram incorporados ao software?
(Sim) (65.a) H problemas de tempo de recuperao?

c.

Proteo contra falha

[Os requisitos de proteo contra falha no so implementveis ou no so demonstrados?]
[66] Os requisitos de proteo contra falha foram incorporados ao software?
(Sim) (66.a) Voc v alguma dificuldade em alcanar os requisitos de proteo contra falha?

[67] Ser difcil verificar a satisfao dos requisitos de proteo contra falha?
d.

Segurana de acesso
[Os requisitos de segurana de acesso so mais rigorosos do que a prtica ou experincia do programa?]
[68] Existe requisitos de segurana de acesso sem precedncia?
[69] Este um sistema Orange Book?
[70] Voc j implementou este nvel de segurana antes?

e.

Fatores humanos
[Este sistema sera difcil de ser usado por causa de uma interface homem-mquina mal definida?]
[71] Voc v dificuldade em alcanar os requisitos de fatores humanos?
(No) (71.a) Como voc est garantindo que voc ir alcanar os requisitos de fatores humanos?
Se estiver sendo feita uma Prototipao...
(Sim) (71.a.1) um prottipo throw-away?
(No) (71.a.1a) Est sendo feito desenvolvimento evolucionrio?
(Sim) (71.a.1a.1) Voc tem experincia com este tipo de desenvolvimento?
(Sim) (71.a.1a.2) Existem verses intermedirias disponveis para entrega?
(Sim) (71.a.1a.3) Isto complica o controle de mudana?

f.

Especificaes
[A documentao adequada para elabora o design, implementer, e testar o sistema?]
[72] As especificaes dos requisitos de software adequadas para o design do sistem a?
[73] As especificaes de hardware so adequadas para o design e implementao do software?
[74] Os requisitos de interfaces externas esto bem especificados?
[75] As especificaes de teste so adequadas para testar totalm ente o sistema?
Se est ou passou da fase de implementao...
[76] As especificaes de design so adequadas para implem entar o sistema?
interfaces internas

B.

Ambiente de desenvolvimento
1.

Processo de desenvolvimento
a.

Formalidade
[A implementao ser difcil de entender ou manter?]
[77] Est sendo usado mais de um modelo de desenvolvimento?
Espiral
Cascata
Incremental
(Sim) (77.a) Coordena-los um problemas?
[78] Existem planos formais e controlados para todas as atividasdes de desenvolvimento?
Anlises de requisitos
Design
Codificao
Integrao e teste
Instalao
Garantia de qualidade
Gerncia de configurao
(Sim) (78.a) Os planos especificam bem o processo?
(Sim) (78.b) Os desenvolvedores so familiar com o plano?

b.

Adequabilidade
[O processo adequado para o modelo de desenvolvimento escolhido, ex., espiral, prototipao?]
[79] O processo de desenvolvimento adequado para este produto?
[80] O processo de desenvolvimento suportado por um conjunto de procedimentos, mtodos, e
ferramentas compatveis?

c.

Controle do Processo
[O processo de desenvolvimento e software cumprido, monitorado, e controlado usando mtricas?
Locais distribudos de desenvolvimento so coordenados?]
[81] Todos seguem o processo?
(Sim) (81.a) Como isto garantido?
[82] Voc pode m edir quando o processo de desenvolvimento est alcanado seus objetivos de qualidade
e produtividade?
Se existe locais distribudos de desenvolvimento...
[83] Existe coordenao adequada entre os locais distribudos de desenvolvimento?

d.

Experincia
[Os membros do projeto possuem experincia de uso do processo? O processo entendido por todos os
membros?]
[84] As pessoas esto confortveis com o processo de desenvolvimento?

e.

Controle de produto
[Existem mecanismos para controlar as mudanas no produto?]
[85] Existem mecanismos de rastramento de requisitos que rastreiam requisitos da especificao da fonte
at os casos de testes?
[86] Este mecanisco de rastreabilidade usado para avaliar a anlise de impacto nas mudanas de
requisitos?
[87] Existe um processo de controle formal?
(Sim) (87.a) Este processo cobre todas as mudanas os requisitos, design, cdigo e documentao do
baseline?
[88] As mudanas, em qualquer nvel, so mapeadas para o nvel de sistema e para o nvel de testes?
[89] Existe anlise adequada quando novos requisitos so adicionados ao sistema?
[90] Voc tem uma forma de rastrear interfaces?
[91] Os planos de teste e procedimentos alterados como parte do processo de alterao?

2.

Ferramenta de desenvolvimento

a.

Capacidade
[Existe estaes de trabalho suficientes, com poder de processamento, memria e armazenamento?]
[92] Existe estaes de trabalho suficientes, e com poder de processamento para todos os membros do
projeto?
[93] Existe capacidade suficiente de executar vrias etapas ao mesmo tempo, tal com o codificao,
integrao e testes?

b.

Adequabilidade
[As ferramentas de desenvolvimento suportam todas as fases, atividades e funes?]
[94] As ferramentas de desenvolvimento suportam todos os aspectos do programa?
Anlise de requisitos
Anlise de desempenho
Design
Codificao
Testes
Documentao
Gerncia de configurao

 Acompanhamento de gerncia
Rastream ento de requisitos
c.

Usabilidade
[O quanto fcil de usar as ferramentas de desenvolvimento?]
[95] As pessoas acham as ferramentas de desenvolvimento fceis de serem usadas?
[96] Existe boa documentao das ferramentas de desenvolvimento?

d.

Experincia
[Existe experincia da empresa ou de membros do projeto com as ferramentas de desenvolvimento?]
[97] As pessoas usaram estes ferramentas e mtodos antes?

e.

Disponibilidade
[O sistema possui bugs, down-time, ou backup interno no suficiente?]
[98] O sistema considerado disponvel?
Compilador
Ferramentas de desenvolvimento
Hardware

f.

Suporte do sistema
[Existe algum suporte de especialista ou fornecedor ao sistema?]
[99] As pessoas esto treinadas para usar as ferramentas de desenvolvimento?
[100] Voc possui acesso a experts quanto ao uso do sistema?
[101] Os fornecedores respondem de rapidam ente aos problemas?

g.

Entrega
[A definio e os requisitos de aceitao esto definidos para a entrega das ferramentas de
desenvolvimento para o cliente no oramento do cliente?]
[102] Voc est entregando as ferramentas de desenvolvimento ao cliente?
(Sim) (102.a) H um oramento adequado, prazo, e recursos alocados para esta entrega?

3.

Processo de gerncia
a.

Planejamento
[Os planejamento feito a tempo, lideres tcnicos so includos, planos de contingncia feitos?]
[103] O programa gerenciado de acordo com o plano?
(Sim) (103.a) As pessoas normalmente so pegas de surpresa com situaes apaga fogo?
[104] Re-planejamento feito quando distores acontecem?
[105] Pessoas de todos os nveis so includas no planejamento do prprio trabalho?
[106] Existem planos de contingncia para riscos conhecidos?
(Sim) (106.a) Como voc determina quando executar um plano de contingncia?
[107] Questes que necessitam de mais tempo para serem resolvidas so endereadas de forma
adequada?

b.

Organizao do projeto
[Os papis e as relaes de trabalho so claras?]
[108] A organizao do programa efeitva?
[109] As pessoas entendem seu prprio papel e o papel dos outros no programa?
[110] As pessoas sabem quem tem autoridade para o que?

c.

Experincia de gerncia
[Os gerentes so experientes em desenvolvimento de software, gerenciamento de software ou em
programas maiores?]
[111] O programa possui gerentes experientes?
Gerenciamento de software
Participao ativa em Desenvolvimento de software
Com este processo de desenvolvimento

 No domnio da aplicao
Em um programa com tamanho e complexidade similar
d.

Interfaces do programa
[Existe pouca interface com o cliente, outros contratados, outros gerentes ou alta gerncia?]
[112] A gerncia comunica os problemas tanto para cima ou para baixo hierarquicamente?
[113] Os conflitos com o cliente so documentados e resolvidos em tempo hbil?
[114] A gerncia envolve membros do programa apropriados em reunies com o cliente?
Lideres Tcnicos
Desenvolvedores
Analistas
[115] A gerncia trabalha para garantir que todas as faces de consumidores esto representadas
quanto a funcioinalidade e operao?
[116] Existem boas polticas para apresentar uma posio otimista para o cliente ou a alta gerncia?

4.

Mtodos de gerenciamento
a.

Monitorao
[As mtricas de gerenciamento esto definidas e o progresso do desenvolvimento acompanhado?]
[117] Existe relatrios de status peridicos estruturados?
(Sim) (117.a) As pessoas conseguem uma resposta dos seus relatrios de status?
[118] Informaes apropriadas so reportadas para os nveis corretos da organizao?
[119] Voc acompanha o progresso em relao ao plano?
(Sim) (119.a) A gerncia tem uma viso clara do que est acontecendo?

b.

Gerenciamento de Pessoal
[As pessoas do projeto esto treinadas e sendo usadas adequadamente?]
[120] As pessoas esto sendo treinadas em habilidades necessitadas pelo programa?
(Sim) (120.a) Isto faz parte do plano do program a?
[121] As pessoas recebem trabalho foram da sua area de experincia?
[122] fcil para os membros do programa tomar attitudes de gerenciamento?
[123] Os membros do programa, em todos os nveis, esto sabendo do status do programa em relao ao
plano?
[124] As pessoas sentem que imortante seguir o plano?
[125] A gerncia consulta as pessoas antes de tomar decises que afetem o trabalho destas pessoas?
[126] A gerncia do programa envolve membros do programa adequados em reunies com o cliente?
Lderes Tecnicos
Desenvolvedores
Analistas

c.

Garantia de qualidade
[Existem procedimentos adequados e recursos para assegurar a qualidade do produto?]
[127] Is the software quality assurance function adequately staffed on this program?
[128] Voc tem mecanismos definidos para assegurar a qualidade?
(Sim) (128.a) Todas as areas e fases tem procedimentos de qualidade?
(Sim) (128.b) As pessoas esto acostumadas a trabalhar com estes procedimentos?

d.

Gerncia de configurao
[Os procedimentos de mudana ou controle de verso, incluindo locais de instalao, so adequadas?]
[129] Voc tem um sistema de gerenciam ento de configurao adequado?
[130] A funo de gerenciamento de configurao possui membros adequados?
[131] Uma coordenao requerida com um sistema instalado?

(Sim) (131.a) Existe gerenciamento de configurao adequada para o sistema instalado?

(Sim) (131.b) O sistema de gerenciamento de configurao sincroniza seu trabalho com as mudanas no
local?
[132] Voc est instalando em multiplos locais?
(Sim) (132.a) A gerncia de configurao est disponvel para multiplos locais?
5.

Ambiente de Trabalho
a.

Atitude de Qualidade
[Existe uma ausncia de orientao quanto a qualidade do trabalho?]
[133] Todos os nveis de pessoal so orientados a procedimentos de qualidade?
[134] O cronograma est considerando a qualidade?

b.

Cooperao
[Existe ausncia de espirito de time? Resoluo de conflitos exisgem interveno da gerncia?]
[135] As pessoas trabalham de forma cooperativa entre os limites funcionais?
[136] As pessoas trabalham com objetivos comuns?
[137] necessria interveno da gerncia para que as pessoas trabalhem juntas?

c.

Comunicao
[Existe pouco conhecimento da misso ou objetivos, pouca comunicao de informaes tcnicas entre
os gerentes?]
[138] Existe boa comuicao entre os membros do programa?
Gerentes
Lderes tcnicos
Desenvolvedores
Testadores
Gerncia de configurao
Garantia de qualidade
[139] Os gerentes so receptivos para comunicados dos membros do programa?
(Sim) (139.a) Voc se sente a vontade de pedir ajuda a seus gerentes ?
(Sim) (139.b) Os membros do programa podem levanter riscos sem ter uma soluo em mos?
[140] Os membros do programa recebem notificaes de eventos, em tempo hbil, que podem afetar o
trabalho deles?
(Sim) (140.a) Isto forma ou informal?

d.

Moral
[Existe uma atmosfera no criativa ou no produtiva? As pessoas sente que no tem reconhecimento ou
no tem recompensa por um bom trabalho realizado?]
[141] Como est a moral do programaHow is morale on the program?
(No) (141.a) Qual a principal contribuio para o baixo fator de moral?
[142] Existe algum problema em manter as pessoas que voc precisa?

C.

Definies do programa
1.

Recursos
a.

Cronograma
[O cronograma inadequado ou instvel?]
[143] O cronograma tem sido estvel?
[144] O crongorama realista?
(Sim) (144.a) Existe um mtodo de estimao baseado em dados histricos?
(Sim) (144.b) O mtodo funcionou bem no passado?
[145] Existe algo no cronograma que no foi adequadamente planejado?
Anlise e estudos

 Garantia de qualidade
Treinamento
Cursos e treinamento de manuteno
Equipamentos
Ferramentas de desenvolvimento disponveis
[146] Existem dependencia externas que podem afetar o cronograma?
b.

Equipe
[A equipe no tem experincia, no tem conhecimento no domnio, no tem habilidades, ou est
sobrecarregada?]
[147] Existe alguma area em que habilidades tcnicas esto ausente?
Engenharia de software e mtodos de anlise de requisitos
Experincia em algoritmos
Design e mtodos de design
Linguagens de programao
Mtodos de teste e integrao
Confiabilidade
Manutenabilidade
Disponibilidade
Fatores humanos
Gerncia de configurao
Garantia de qualidade
Ambiente de produo
Nveis de segurana
COTS
Software reutilizvel
Sistema operacional
Banco de dados
Domnio da aplicao
Anlise de Desempenho
Aplicaes de tempo crtico
[148] Voc tem pessoal adequado para a equipe do program a?
[149] A equipe estvel?
[150] Voc tem acesso s pessoas certas quando voc precisa delas?
[151] Os membros do programa implementaram sistemas desse tipo?
[152] O programa dependente de um pequeno numero de pessoas chaves?
[153] Existe algum problema em conseguir pessoas livres?

c.

Oramento
[O fundo insufficiente ou instvel?]
[154] O oramento estvel?
[155] O oramento baseado em uma estimativa realista?
(Sim) (155.a) Is O mtodo de estimativa baseado em dados histricos?
(Sim) (155.b) O mtodo funcionou bem no passado?
[156] Algumas funcionalidades ou funes foram apagadas como parte de uma poltica de design
baseado em custos?
[157] Existe algo para qual o oramento no foi alocado?

 Anlise e estudos
Garantia de qualidade
Treinamento
Curos de manuteno
Equipamento
Ferramentas de desenvolvimento
[158] As mudanas nos requisitos so acompanhadas de mudanas no oramento?
(Sim) (158.a) Esta uma parte no processo padro de controle de mudanas?
d.

Facilidades
[As facilidades so adequadas para construir e entregar o produto?]
[159] As facilidades de desenvolvimento so adequadas?
[160] O ambiente de integrao adequado?

2.

Contrato
a.

Tipo do contrato
[O tipo de contrato uma fonte de risco para o programa?]
[161] Que tipo de contrato voc tem? (Custo mais taxas, preo fixo, etc.)
(161a) Isto representa um problema?
[162] O contrato rigoroso em algum aspecto do programa?
Declaraco de trabalho
Especificaes
Descries de itens
Partes do contrato
Envolvimento excessivo do cliente
[163] A documentao requerida rigorosa?
Excesso de documentao
Cliente detalhista
Longo ciclo de aprovao

b.

Restries
[O contrato causa alguma restrio?]
[164] Existe algum problema com direitos autorais?
Software COTS
Software desenvolvido pela organizao
Itens no desenvolvidos

c.

Dependncias
[O programa tem alguma dependncia em outros produtos ou servios externos?]
[165] Existe alguma dependencia em produtos ou servios externos que podem afetar o produto,
oramento ou cronograma?
Contratados associados
Contratado principal
Subcontratados
Fornecedores
Equipamento ou software do cliente

3.

Interfaces do programa
a.

Cliente
[Existe algum problema com o cliente, tais como: longo ciclo de aprovao, pouca comunicao, e
experincia no dominio da aplicao?]

[166] O ciclo de aprovao do cliente funciona em tempo hbil?

Documentao
Reviso do programa
Revises formais
[167] Voc continua antes de receber uma aprovao do cliente?
[168] O cliente entende os aspectos tcnicos do sistem a?
[169] O cliente entende o software?
[170] O cliente interfere no processo ou nas pessoas?
[171] A gerncia trabalha com o cliente para alcanar decises acordadas em tempo hbil?
Entendimento dos requisitos
Critrio de testes
Ajustes no calendrio
Interface
[172] O quanto efetivo so seus mecanismos em conseguir acordos com o cliente?
Grupos de trabalho (Previsto em contrato?)
Reunies de intercmbio tcnico (Previsto em contrato?)
[173] As faces de cliente esto envolvidas em alcanar acordos?
(Sim) (173.a) Este um processo definido formalmente?
[174] A gerncia apresenta uma viso realista ou otimista para o cliente?
b.

Contratados associados
[Existe algum problema com contratados associados, tais como: definies inadequadas ou interfaces
instveis, pouca comunicao, ou ausncia de cooperao?]
[175] As interfaces externas esto mudando sem notificao adequada, coordenao, ou procedimentos
formais de mudana?
[176] Existe um plano adequado de transio?
(Sim) (176.a) suportado por todos os contratados e pessoal do local?
[177] Existe algum problema em conseguir prazos ou dados de interface com o contratados associados?
(No) (177.a) So precisos?

c.

Subcontratados
[O programa dependente de subcontratados em areas crticas?]
[178] Existe alguma ambiguidade em definies de tarefa para subcontratados?
[179] O procedimento de relatrio e m onitorao dos subcontratados diferente dos procedimentos
requeridos pelo program a?
[180] A administrao do subcontratado e a gerncia tcnica so feitas por organizaes distintas?
[181] Voc fortemente dependente do conhecimento de um subcontratado em alguma rea?
[182] O conhecimento do subcontratado est sendo transferido para a companhia?
[183] Existe algum problema em conseguir prazos ou dados de interface com os subcontratados?

d.

Contratante Principal (Se o programa um subcontratado)

[O programa est tendo dificuldades com o seu contratante principal?]
[184] As definies de tarefas do contratante principal esto ambiguas?
[185] Voc tem interfaces com duas organizaes principais separadas para administrao e gerncia
tcnica?
[186] Voc fortemente dependente do contratante principal para alguma area de conhecimento?
[187] Existe algum problema em conseguir prazos ou dados de interface com o contratante principal?

e.

Gerncia da Organizao
[Est faltando um suporte ou micro gerenciamento da alta gerncia?]
[188] A gerncia do programa tem problemas de comunicao com a alta gerncia?

(Sim) (188.a) Isto parece ser efetivo?

[189] A alta gerncia d a voc suporte em tempo hbil para resolver seus problem as?
[190] A alta gerncia tem tendncia a fazer micro gerenciamento?
[191] A gerncia apresenta uma viso realista ou otimista do programa?
f.

Fornecedores
[Os fornecedores so responsveis por necessidades do programa?]
[192] Voc est dependendo de fornecedores para entrega de components crticos do programa?
Compiladores
Hardware
COTS

g.

Poltica
[Poltica est causando problemas no programa?]
[193] Polticas esto afetando o programa?
Compania
Cliente
Contratados associados
Subcontratados
[194] Decises polticas esto afetando decises tcnicas?

Anexo C Os 10 principais riscos em projetos de software [BOEHM91]

Esta taxonomia apresentada por Boehm [BOEHM91] no artigo Software Risk Management:
Principles and Practices, apresenta os 10 principais riscos em projetos de software,
baseada em uma pesquisa entre vrios gerentes de projetos. Alm das fontes de risco, so
apresentadas tcnicas de gerncias de risco usadas com sucesso, em cada fonte de risco,
para mitigar ou evitar os riscos.
Item de risco

Tcnica de Gerncia de Risco

Mo de obra abaixo do esperado

Equipe com talento e qualificado para o trabalho, desenvolvimento do time,

treinamento e acordos pessoais

Cronograma e oramento irreais

Estimativa de oramento e cronograma detallhadas, projetos com base no custo,

desenvolvimento incremental, re-utilizao de software e limpeza dos requisitos

Desenvolvimento
de
propriedades erradas;

funes

ou

Anlise da organizao, anlise da misso, formulao do conceito de operao,

pesquisa com o usurio, participao do usurio, prototipao, manual para os
usurios, anlise de desempenho, analise do fator de qualidade

Desenvolvimento de uma interface com o

usurio errada

Prottipos, cenrios, anlise de tarefas, participao do usurio

Projetar funcionalidades sem requisitos

includos por analistas, ou por preciosismo
(Gold-Plating);

Limpeza dos requisitos, prototipao, anlise de custo benefcio, projetar com

base no custo

Criao de requisitos contnua

Definio de marcos para mudanas, esconder informaes, desenvolvimento

incremental (postergando mudanas para prximas iteraes)

Componentes externos por exemplo,

equipamentos adquiridos - abaixo da
expectativa

Anlise de desempenho,
compatibilidade

inspees,

checar

Atividades externas por exemplo,

fornecedores - abaixo da expectativa

Checar a referncia, contratos com

competitivos, desenvolvim ento de time

multa,

prototipaes

Desempenho em tempo real abaixo da

expectativa

Simulao, anlise de desempenho, m odelagem, prototipao, instrumentao,

melhoria fina de desempenho

Requisitos que vo alm da capacidade

computacional

Anlise tcnica, anlise de custo benefcio, prototipao, checar referncia

referncia,

anlise

ou

de

projetos

Anexo D Taxonomia de Riscos [JONES94]

A taxonomia de riscos a seguir foi apresentada por Caper Jones no livro Assessment and
Control of Software Risks [JONES94]. Este livro apresenta 60 fatores de risco. Para cada
risco so apresentados as seguintes informaes:

Definio do risco;

Grau de severidade;

Freqncia em que o risco aparece;

Ocorrncia;

Susceptibilidade e resistncia ao risco;

Causas-Raiz do risco;

Riscos associados;

Impacto no custo;

Mtodos de preveno;

Mtodos de controle;

Suporte de ferramentas;

Suporte de consultores;

Suporte educacional;

Suporte de publicaes;

Suporte de peridicos;

Suporte de padres;

Associaes de profissionais;

Efetividade de terapias conhecidas;

Custo de terapias conhecidas;

Prognstico a longo prazo do risco.

A tabela a seguir apresenta todos os riscos apresentados por [JONES94]. A primeira coluna
apresenta o risco, a segunda coluna indica quais so os riscos mais comuns encontrados
em projetos e o tipo de projeto de software onde so encontrados (conforme lista de cdigos
a seguir) e a terceira coluna indica quais so os riscos mais srios em projetos de software.
Aps a tabela apresentado, de uma forma mais completa, um dos riscos citados por
[JONES94].
Tipos de projetos de software
M = Sistemas de Gerencia de Informao
S = Software de Sistema (Sistemas Operacionais, aplicaes que controlam dispositivos)
C = Softwares Comerciais
D = Softwares Militares
O = Softwares desenvolvidos por terceiros (contratados)
E = Softwares desenvolvidos pelo prprio usurio

Risco

Mais Comum

Mais Srio

Objetivos de melhoria de qualidade ou produtividade no so claros

Nveis de maturidade artificiais
Projetos Cancelados
Disputas polticas dentro da organizao
Estouro no custo

Requisitos interminveis dos usurios

D,M,O

Escritrio com muitas pessoas

Mdulos ou componentes de sistema com um nmero elevado de erros

E,S

Excesso de Documentao

D,S

Excesso de Presso no Prazo

Demora do software chegar ao mercado

C,D,S

Falsos indicadores de produtividade

Problemas entre clientes e fornecedores de software

Problemas entre gerente de projeto e gerncia snior

Alto custo de manuteno

Estimativa de custo no acurada

Mtricas no acuradas

X
X

Estimativa de qualidade no acurada

Estimativa de tamanho de software no acurada
Avaliaes de software inadequadas
Planos de compensao inadequados
Controle de configurao e repositrios de projetos inadequados

Currculo Inadequado do Engenheiro de Software

Currculo Inadequado do Gerente de Software
Medio inadequada
Mtodos de aquisio de pacotes inadequados
Referncias Bibliogrficas e Pesquisa inadequada
Padres e polticas de software inadequadas
Anlise de Risco do projeto de software inadequada
Anlise de valores do projeto de software inadequada
Mtodos e ferram entas de gerncia de projeto inadequadas
Mtodos e ferram entas de garantia de qualidade inadequadas
Mtodos e ferram entas de engenharia de software inadequadas
Mtodos e ferram entas de documentao tcnica inadequadas
Ausncia de arquiteturas reutilizveis
Ausncia de cdigos reutilizveis
Ausncia de dados reutilizveis
Ausncia de designs reutilizveis
Ausncia de documentao reutilizvel
Ausncia de Templates de estimativas reutilizveis

Risco

Mais Comum

Mais Srio

Ausncia de intefaces homem-mquina reutilizveis

Ausncia de Planos de Projetos reutilizveis
Ausncia de Requisitos reutilizveis
Ausncia de Planos de Testes, Casos de Testes e Dados de Testes reutilizveis
Ausncia de Especializao
Sistemas Obsoletos em uso por um longo tempo

D,E

Produtividade Baixa

Qualidade Baixa

Baixo Status hierrquico na organizao das pessoas responsveis pelo projeto

Baixo grau de satisfao do usurio
Pssimas Prticas na gerncia de projeto

C
X

Pssimas Prticas pela equipe tcnica do projeto

Prazos perdidos
Definies incompletas de ciclos de vida que omitem atividades importantes
Organizao sem estrutura adequada
Falta de investimento de tecnologia
Dispensas e cortes excessivos na equipe do projeto
Planejamentos de melhorias a curto prazo
Sndrome de Bala de Prata (Ferram enta ou metodologia que faz milagre)
Transferncia de tecnologia lenta

Requisitos interminveis dos usurios

1. Definio: a) Requisitos novos ou modificaes significantes aos requisitos existentes
que so criados aps os requisitos acordados entre clientes e desenvolvedores; b) Falha ao
antecipar requisitos que poderiam ser modificados, e falha tambm ao no fazer planos para
lidar com estes requisitos;
2. Severidade: A severidade mdia deste risco de 3.5 considerando a escala a seguir:
Severidade 1: Requisitos novos ou modificaes excedem 50% dos requisitos originais;
Severidade 2: Requisitos novos ou modificaes excedem 40% dos requisitos originais;
Severidade 3: Requisitos novos ou modificaes excedem 30% dos requisitos originais;
Severidade 4: Requisitos novos ou modificaes excedem 20% dos requisitos originais;
Severidade 5: Requisitos novos ou modificaes excedem 10% dos requisitos originais;
3. Frequncia: Tipicamente acontece em mais de 70% das aplicaes com mais de 1000
pontos de funo. A mdia de requisitos novos ou modificaes foi de 35% em uma amostra
de 60 projetos.

4. Ocorrncia: Todas as classes de softwares possuem experincia com este risco.

Softwares militares apresentam mais este risco do que as outras classes, pois os projetos de
softwares so mais longos.
5. Susceptibilidade e resistncia: Aplicaes que so novas ou onde os usurios esto
incertos do que necessrio so as mais susceptveis ao risco. E aplicaes que j foram
feitas diversas vezes, tais como compiladores, so as mais resistentes.
6. Causas Raiz: 1) Cada vez que novos usurios entram no projeto, haver alguma
incerteza em resolver as necessidades; 2) Para projetos que durem anos, pode acontecer
novas mudanas como parte da aplicao
7. Riscos associados: Associados aos riscos de Problemas entre clientes e fornecedores
e Problemas entre gerente de projeto e gerncia snior. Requisitos interminveis tambm
so tipicamente causas para Prazos perdidos, Tempo excessivo de entrega ao mercado,
e Estouro no custo. E tambm contribuem para problemas como presso excessiva no
prazo e moral baixo da equipe. Requisitos interminveis so causados por Usurios sem
experincia, Gerncia sem experincia, Metodologias inadequadas, Estimativa de custo
inadequado.
8. Impacto no custo: Pode ser quantificado por mtricas de pontos de funo.
Considerando que o custo por ponto de funo $1000, e o projeto comea com requisitos
com o total de 1000 pontos de funo, ento o projeto tem o custo de $1 milho. Caso sejam
adicionados novos requisitos, 25% alm do inicial, o projeto ir custar $1,25 milhes.
9. Mtodos de preveno: um programa de medida baseados em mtricas funcionais a
melhor preveno. Softwares que estimem pontos de funo tambm so ferramentas que
apresentam benefcios.
10. Mtodos de controle: O uso de prottipos ajuda a controlar este risco. Para projetos
muito grandes (> 5000 pontos de funo), estabelecer um controle de mudanas formal
tambm ajuda.
11. Suporte de Ferramentas: Ferramentas que estimam pontos de funo, por exemplo:
ACT/1, Case Dictionary, FirstCASE etc.
12. Suporte de Consultores: Existem diversos consultores para servios de prototipao e
treinamento nesta tcnica.
13. Suporte educacional: Diversas universidades esto estudando este risco: Case
Western University, George Mason University etc.

14. Suporte de publicaes: Exploring Requirements: Quality Before Design de Donald

Gause e Gerald Weinberg uma excelente viso geral com dicas importantes..
15. Suporte de peridicos: Algumas revistas como Times, Business Week, e Fortune
apresentam este risco apenas quando acontece grandes problemas. Outros jornais e
revistas apresentam alguns artigos sobre o problema: Cross Talk, Metrics Views etc.
16. Suporte de padres: Nenhum dos padres (E, 1994) cobre este problema: ANSI, IEE,
IEEE, DoD ou ISO. Porm DoD especifica tcnicas formais para pedidos de mudanas nos
requisitos.
17. Associaes de profissionais: Existem diversas associaes de profissionais que
lidam com custos acima do previsto, porm no com requisitos interminveis. ISPA
(International Society of Parametric Analysis) est comeando a lidar com este problema.
18. Efetividade de terapias conhecidas: A efetividade de terapias conhecidas so
excelente para aplicaes pequenas e mdias, mas no para grandes sistemas com mais
de 10.000 pontos de funo. Prottipos podem reduzir requisitos interminveis em 10%.
19. Custo de terapias conhecidas: Aprender a contar pontos de funo, custa em mdia
$1000 dlares americanos por estudante. Ferramentas para estimar pontos de funo
custam entre $1000 e $40000.
20. Prognstico a longo prazo: Com o tempo os requisitos interminveis devem reduzir.
Tcnicas de prototipao devem reduzir o nmero de novos requisitos, e mais formalidade
para lidar com novos requisitos tambm devem ajudar a reduzir o problema.

Anexo E Taxonomia de Riscos [LEOPOLDINO04]

Esta taxonomia foi elaborada por Cludio Bezerra Leopoldino [LEOPOLDINO04] no trabalho
Avaliao de riscos em desenvolvimento de software por meio de uma pesquisa realizada
com empresas nacionais. A lista de riscos e os tipos foram desenvolvidas com base em
outras taxonomias existentes.
1.

Ambiente Corporativo
a.

2.

3.

4.

5.

6.

7.

Mudana na propriedade do produto ou no gerente snior do projeto: Alterao na chefia do comprador do

software ou do prprio projeto, com mudanas de necessidades que influenciam o seu andamento

Propriedade do Projeto
a.

Falta de comprometimento da alta gerncia com o projeto: O compromisso da alta gerncia com o projeto no
pode ser negligente ou superficial, devendo ser marcante e visvel. Envolve tambm a disponibilidade dos
recursos necessrios.

b.

Falha em obter comprom etimento do cliente por parte do gerente do projeto: Neste caso o gerente tem a culpa
por no conseguir maior comprometimento do cliente.

c.

Conflito de interesses entre departamentos do usurio: Departamentos do cliente apresentam necessidades

diferentes de requisitos, prioridades, metas, etc. Torna-se um problema conciliar a propriedade compartilhada de
um projeto.

Gerncia de Relacionamentos
a.

Falha em gerenciar as expectativas dos usurios finais: A expectativa sobre um projeto define seu sucesso ou
fracasso. Expectativas muito baixas ou muito altas afetam negativamente o projeto.

b.

Falta de envolvimento adequado do usurio (pouco tempo disponvel e/ou m qualidade na participao):
Usurios devem ativamente participar da equipe de desenvolvimento, com responsabilidade e compromissos
com suas metas.

c.

Falta de Cooperao dos Usurios: Recusa dos usurios em colaborar com a equipe de desenvolvimento.

Gerncia de Projeto
a.

Gerenciam ento imprprio de mudanas: Todas as alteraes no projeto, por quaisquer razes, devem ser feitas
sem que se perca controle sobre escopo e oramento e de forma harmnica.

b.

Falta de habilidades para o gerenciam ento de projetos: Gerente no tem habilidades suficientes para ser bem
sucedido.

c.

Falta de poderes efetivos para o gerenciamento de projetos: Gerente no tem poderes suficientes para ser bem
sucedido.

d.

Falta de um a metodologia efetiva de gerenciamento de projetos: Equipe no emprega tcnicas e/ ou processos

necessrios ao desenvolvimento.

e.

Definio imprpria de papis e responsabilidades: Falta de clareza de papis e responsabilidades entre os

membros da equipe, consultores e terceirizados.

f.

Controle pobre ou inexistente: Causa falta de informao sobre o estado atual do projeto decorrente do
acompanhamento indevido/ insuficiente das atividades desempenhadas.

Escopo
a.

Escopo/ objetivos pouco claros ou equivocados: Antes de se ter clareza, no se consegue estabilizar os
requisitos.

b.

Mudana de Escopo/ objetivos: Mudanas de regras de negcio no decorrer do projeto.

c.

Envolvimento de grande nmero de unidades organizacionais do cliente: Escopo do software cresce em virtude
de muitas unidades organizacionais do cliente estarem envolvidas.

Requerimentos
a.

Volatilidade nos requisitos: Alteraes contnuas no que se espera do software.

b.

Requisitos mal entendidos e/ou mal definidos no incio do desenvolvimento: Pode levar a estimativas e escolhas
equivocadas de tecnologia, tempo recursos e funcionalidade do sistema.

c.

Assunto novo ou no familiar tanto para usurios quanto para desenvolvedores: A falta de conhecimento pode
levar a uma pobre especificao de requisitos.

Financiamento

a.
8.

a.
9.

10.

11.

12.

a.

Falta de metodologia/ processo efetivo de desenvolvimento: Os mtodos empregados no podem retardar a

implementao nem tampouco ser leves a ponto de ser frgeis. Tambm devem ser abrangentes para todo o
processo de desenvolvimento.

b.

Tentativa de adoo de novo mtodo/ tecnologia durante o projeto. Aumenta a incerteza inerente ao projeto.

Pessoal
a.

Falta de conhecimentos/ habilidades necessrios ao pessoal do projeto: Tais como conhecimento de negcios,
tecnologia, experincia, etc.

b.

Falta de habilidades interpessoais pelo gestor na liderana da equipe do projeto: Lidar com as pessoas merece
cuidado da mesm a forma que calendrio, oram ento e tecnologia.

Pessoal de Apoio
a.

Pessoal envolvido insuficiente/ inapropriado: Pessoal insuficiente numericam ente ou com habilidades erradas/
inapropriadas.

b.

Volatilidade do pessoal da equipe: Troca constante de membros da equipe ou perda de pessoas importantes
para a equipe.

Tecnologia

Dependncias complicadas em projetos de mltiplos fornecedores (integrao de tecnologias de vrias fontes):

Nem sempre os fornecedores de vrias tecnologias tem compatibilidade adequada entre si.

Planejamento
b.

15.

Introduo de Nova Tecnologia de desenvolvimento: Agregao ao projeto de novas tecnologias, tecnologias de

ponta ou uso de mudanas radicais de verso de uma tecnologia conhecida.

Dependncias Externas
a.

14.

Prazos e tempo de execuo de tarefas mal estimados: Tempo adequado deve ser determinado para cada
tarefa, inclusive para testes e documentao.

Processo de Desenvolvimento

a.
13.

Custos mal estimados: M definio de custos pode levar a planejamento e decises errneas

Agenda e Tempo

Ausncia de planejamento ou planejamento inadequado: Viso de que planejamento pouco prtico ou sem
importncia.

Novos Itens
a.

Ferramentas inapropriadas para o desenvolvimento: A m definio de linguagem, plataforma de

desenvolvimento e ferramentas em geral afeta o ritmo de produo e os requisitos.

b.

Falta de motivao da equipe de desenvolvim ento: Equipes desmotivadas produzem menos e com menor
qualidade.

Anexo F Questionrio de de Riscos [THOMSETT02]

Esta taxonomia de riscos baseada em questionrio, foi desenvolvida com base em outras
taxonomias existentes e est disponvel no livro Radical Project Management
[THOMSETT02]. Esta taxonomia aconselhvel a ser usada em pequenos projetos
(menores que 3 meses). O autor do livro aconselha que para projetos maiores, seja feito
uma reunio entre os gerentes de projetos mais experientes, e com a aplicao da tcnica
de brainstorming sejam adicionados considerados novos riscos. Com base na respostas do
questionrio, o time do projeto consegue identificar quais riscos so aplicveis ao projeto, e
identificar o risco geral do projeto.

Risco de Produto / Sistema

1.

Viso geral do sistema / servio / produto

Simples

Mdio

Complexo

2.

Dados lgicos (inclui arquivos)

3.

I/O e questes ou impacto organizacional

4.
Interface com outros sistemas / servios /
produtos

5.

Funo e processos

6.

Novos procedimentos e alteraes no negcio

Nenhum

Algum

Extensivo

7.

Estabilidade dos requisitos

Estvel

Mdio

Instvel

8.

Requisitos de desempenho (incluir qualidade)

Pouco

Mdio

Alto

9.

Requisitos de tecnologia

Simples

Mdio

Complexo

10.

Nvel de inovao

Nenhum

Algum

Extensivo

Risco de Ambiente do Cliente

11.

Nvel de suporte do cliente / usurio

Alto

Mdio

Baixo

12.

Experincia do cliente com o produto / sistema

Extensive

Some

Nenhum

13.

Suporte do patrocionador do cliente / projeto

Alto

Mdio

Pouco
Nenhum

14.
Impacto nas operaes do cliente (tecnologia
nova, poltica)

Pouco

Mdio

Alto

15.
negcio

Participao de especialistas do cliente /

Tempo integral

Tempo Parcial

Quando
requisitado (adhoc)

16.

Stakeholders crticos

1a3

4 a 10

Mais de 10

Alto

Mdio

Pouco

18.
Nvel de habilidade relevante (com aplicao /
produto)

Extensivo

Algum

Nenhum

19.

Experincia do gerente do projeto

Extensivo

Algum

Nenhum

20.

Quantidade de pessoas do projeto

1a4

5 a 10

Mais de 10

Risco de Time

17.

Habilidades gerais

21.
Uso de contratados / membros do time em
tempo parcial

Nenhum

Algum

Extensivo

22.

Tempo de desenvolvimento do projeto

1 a 3 meses

4 a 6 meses

Mais
de
meses

23.

Cronograma / Prazos

Flexvel

Firme

Fixo

24.

Prioridade do projeto para o time

Alto

Mdio

Baixo

25.

Experincia do time com hardware / tecnologia

Extensivo

Mdio

Algum

26.

Ambiente fsico / de suporte para o time

Excelente

Mdio

Pobre

LOW

MEDIUM

HIGH

RISCO GERAL

Anexo G Taxonomia de Riscos para projetos de manuteno [OLIVEIRA06]

Esta taxonomia apresentada por Kathia Oliveira [OLIVEIRA06] voltada para projetos de
manuteno de software. So 42 riscos, no categorizados. apresentado o fator de risco,
e a sua descrio.
Fatores de Risco

Descrio do Risco

1.

Baixa qualidade do sistema a ser

mantido

Quando a qualidade do sistema a ser mantido pobre e qualquer mudana pode

acarretar em problemas imprevisveis.

2.

Falta de ferramentas de apoio

apropriadas

Falta de ferram entas apropriadas e de ambiente para apoiar a manuteno de

sistemas, tais com o: metodologias, padres, procedimentos e ferramentas.

3.

Falta de Profissionais treinados

Falta de profissionais na equipe treinados com habilidades para utilizao de

ferramentas, metodologias e modelos requeridos para manuteno de sistemas.

4.

Dificuldade em reter pessoas

A instabilidade das mudanas, a falta de controle, a falta de informao e a falta de

tempo. Faz com que as pessoas no dem continuidade nas atividades de
manuteno de sistemas.

5.

Falta de oram ento

Falta ou insuficincia de oramento para assegurar a implementao das

mudanas

6.

Resistncia
mudana

7.

Estratgia Organizacional

Determinar o oramento de uma manuteno baseado na concorrncia com outras

empresas rivais. Muitas vezes o desejo de ganhar faz com que o oramento seja
determinado por estratgias organizacionais e no por uma anlise objetiva dos
problemas

8.

Prioridades de gerenciamento

A equipe de manuteno compara os desejos dos clientes com as necessidades

do sistema. Freqentemente, as prioridades de gerenciamento se sobrepem s
necessidades tcnicas. Algumas vezes os gerentes consideram a manuteno e o
aprimoramento mais importantes que a construo de novas aplicaes

9.

Dificuldade para realizao dos

testes

O nvel de especificao e o tempo para a realizao dos testes so inadequados

ou falta de dados precisos para testar as mudanas efetuadas

10.

Escassez de recursos no mercado

Poucos so os recursos experientes com habilidades em atividades de

manuteno de software esto disponveis no mercado

11.

Entendimento limitado

O entendimento do sistema a ser mantido limitado. Por exemplo, a taxa de limite

que uma pessoa pode estudar uma documentao e extrair material relevante ao
problema que est sendo resolvido

12.

Moral da equipe

Baixa m oral e baixa produtividade da equipe pelo fato das pessoas no sentirem
reconhecidas ou recompensadas pelos superiores. A equipe pode sentir
desmotivada pela pouca importncia dada atualmente para as atividades de
manuteno de sistemas

13.

Pouca ou nenhuma documentao

O sistema a ser mantido no possui documentao ou quando a documentao

existente insuficiente ou confusa

14.

Efeitos colaterais (sistemas)

A execuo de mudanas impacta funcionalidades de outros sistemas

15.

Efeitos colaterais (funcionalidade)

execuo de mudanas impacta funcionalidades do prprio sistema

16.

Inovao tecnolgica

Refere-se as mudanas de hardware e/ou software durante as atividades de

manuteno de sistemas

17.

Falta de entendimento do usurio

Os usurios no entendem como o sistema funciona e eles podem fornecer dados

incompletos ou errados quando relatarem os efeitos de um problem a aos
mantenedores

18.

Usurios desinteressados

Falta de comprometimento ou interesse do usurio com relao s atividades de

manuteno de sistemas

19.

Mudanas da organizao usuria

Mudana da organizao usuria durante a execuo da manuteno do sistema

20.

Treinam ento

Treinam ento insuficiente ou inadequado.

dos

usurios

A resistncia que os usurios tem com relao s mudanas de um produto de

software, por mais importante ou lucrativa que tal mudana possa ser.

Fatores de Risco

Descrio do Risco

21.

BACKLOG

Grande acmulo de trabalho a serem executados pelos mantenedores. A equipe

de manuteno est sempre tentando equilibrar objetivos distintos

22.

Execuo

Grande nmero de falhas no sistema ou no hardware antes da mudana ser

executada

23.

Processamento

Tempo de resposta ou requisitos de processamento restrito do sistema a ser

mantido

24.

Confiabilidade do hardware e do
software

O hardware ou software ou suporte tcnico no so confiveis e podem dificultar a

soluo de um problema

25.

Apoio do suporte

Falta de apoio do suporte para ou ocorrem em tempo inoportuno

26.

Oramento

Presses oramentrias

27.

Mudana de prioridade

Dificuldade em gerenciar mudanas em ergenciais. Neste caso, os recursos chaves

podem no estar disponveis e na m aioria das vezes as solues emergenciais
afetam o custo e o cronograma das atividades de manuteno

28.

Dificuldade de medir desempenho

Dificuldade de medir o desempenho das mudanas realizadas

29.

Sistema e tecnologia antiquados

O sistema e tecnologia a serem mantidos esto obsoletos

30.

Plano estratgico

Plano estratgico inexistente ou inadequado

31.

Adaptaes
empresarias

32.

Integrao

Integrar ou sobrepor sistemas incompatveis.

33.

Falta de apoio gerencial

Falta de compreenso e apoio gerencial.

34.

Alta complexibilidade

Alta complexidade do programa a ser mantido.

35.

Mtricas inexatas

As mtricas so subestimadas, devido a vrios fatores: dentre eles: no

entendimento da mudana, complexibilidade do sistema a ser mantido, nm ero de
linhas de cdigo do sistema a ser mantido

36.

Falta de tempo

Falta ou insuficincia de tempo para assegurar a implementao das mudanas

37.

Requisitos instveis

Os requisitos de necessrios para a manuteno do sistema so instveis, ou seja,

esto sempre mudando

das

mudanas

Adaptar as mudanas referentes ao ambiente empresarial rapidam ente

Anexo H Riscos identificados na modernizao de sistemas legados

[SANTOS04]
Nesta taxonomia, Cssio Santos [SANTOS04] identificou os riscos inerentes
modernizao de sistemas legados, com o objetivo de deixar o processo de modernizao
previsvel e com mais probabilidade de sucesso. So 13 riscos riscos identificados, com as
possveis perdas associadas.
Riscos

Possvel perda

Risco e desempenho

Perda de desempenho, lentido na execuo.

Risco de manuteno

Esforo envolvido na Manuteno

Risco do conhecimento tcnico da

equipe

Introduo de problemas ou atrasos no projeto em funo do conhecimento da

tecnologia pela equipe envolvida.

Risco da
tecnologia

complexidade

da

Introduo de problemas ou atrasos no projeto em funo da complexidade da

tecnologia envolvida

Risco
de
aplicao

inflexibilidade

da

Perda de liberdade de modernizar no sentido de dependncia da estrutura do

legado (interface, dados ou lgica)

Risco de integridade de dados

Risco de
aplicao

Risco de implem entao

Introduo de problemas ou atrasos no projeto em funo do conhecimento

inadequado da parte modernizada.

Risco de segurana

Perda de segurana da aplicao

10

Risco de qualidade

Introduo de novos defeitos na aplicao, ou no resolver os erros existentes na

aplicao antiga.

11

Risco de sincronism o

Perda de sincronismo entre a parte modernizada e a aplicao legada

12

Risco de custo

Alto custo para implem entar o projeto de modernizao

13

Risco de cronogram a

Soluo demorada para implem entar o projeto de modernizao

indisponibilidade

Possvel divergncia de dados entre as bases de dados.

da

A aplicao pode ficar parada por alguma falha.

Anexo I Taxonomia de Riscos [MACHADO02]

Esta taxonomia apresenta por Cristina Machado [MACHADO02] foi baseada em diversas
outras taxonomias, entre estas a taxonomia apresentada por Caper Jones [JONES94]. So 7
categorias, e 63 fontes de riscos identificados.
1.

2.

3.

4.

Cliente
a.

Ausncia da participao do cliente

b.

Cliente resistente a mudanas

c.

Conflitos entre clientes

d.

Clientes com atitudes negativas em relao ao projeto

e.

Clientes no comprometidos com o projeto

f.

Ausncia de cooperao entre os clientes

Equipe de Desenvolvimento
a.

Conflitos entre cliente e organizao desenvolvedora

b.

Membros da equipe de desenvolvimento treinados inadequadamente

c.

Ausncia de comprometimento da equipe de desenvolvimento em relao ao projeto

d.

Membros da equipe inexperientes

e.

Falta de boas prticas da equipe tcnica

f.

Conflitos entre os membros da equipe de desenvolvimento

g.

Freqente rotao de pessoal na equipe de projeto

h.

Equipe de desenvolvimento no familiarizada com as ferramentas

i.

Membros da equipe de desenvolvimento no familiarizados com o negcio do cliente

j.

Atitudes negativas da equipe de desenvolvimento

k.

Ausncia de perfil especializado na equipe de projeto para atender aos requisitos do projeto

Poltica Organizacional
a.

Recursos retirados do projeto por causa de mudanas nas prioridades organizacionais

b.

Mudanas na gerncia da organizao durante o projeto

c.

Polticas corporativas com efeito negativo no projeto

d.

Influncia poltica no projeto

e.

Ambiente organizacional instvel

f.

Reestruturao organizacional durante o projeto

g.

Ausncia de suporte gerencial de alto nvel para o projeto

h.

Ausncia ou perda do compromisso organizacional com o projeto

Complexidade do projeto
a.

Dependncia de fornecedores externos

b.

Muitos fornecedores externos envolvidos com o projeto

c.

Alto nvel de complexidade tcnica

d.

Tarefas a serem automatizadas altamente complexas

e.

Projeto afetando um grande nmero de departamentos ou unidades do usurio

f.

Grande quantidade de interao com outros sistemas

g.

Projeto envolvendo o uso de novas tecnologias

h.

Inadequada transferncia de tecnologia para o projeto

i.

Condies de trabalho inadequadas

5.

6.

7.

Processo
a.

Padres, polticas e metodologias de engenharia de software inadequados

b.

Mtodos e ferramentas de engenharia de software inadequados

c.

Burocracia excessiva

d.

Falta de suporte para a resoluo de problemas tcnicos

e.

Falta de estrutura para reuso

f.

Falta de prtica de reuso

g.

Repositrios de projeto e controle de configurao inadequados

h.

Ausncia de uma metodologia efetiva de gerncia de projetos

Gerncia de Projeto
a.

Planejamento inadequado do prazo

b.

Planejamento inadequado dos recursos necessrios

c.

Planejamento inadequado do oramento

d.

Presso excessiva de prazo

e.

Baixa produtividade

f.

Baixa qualidade dos produtos intermedirios e finais

g.

Ausncia de pessoas com perfil para liderar o projeto

h.

Acompanhamento do progresso do projeto insuficiente

i.

Fraco planejamento de projeto

j.

Falta de definio dos marcos do projeto

k.

Gerente do projeto ineficiente

l.

Gerente do projeto inexperiente

m.

Comunicao ineficiente

Requisitos
a.

Requisitos conflitantes

b.

Mudanas contnuas dos objetivos e escopo do projeto

c.

Mudanas contnuas dos requisitos

d.

Requisitos no definidos de forma adequada

e.

Requisitos no esto claros

f.

Requisitos incorretos

g.

Deficincia no entendimento dos usurios quanto s limitaes ou capacidades do sistema

Anexo J Templates usados na gerncia de riscos do Guia

1 Estratgia de gerncia de riscos
Um documento de estratgia de gerncia de riscos um documento que incorpora os
objetivos, estratgias e mtodos para executar a gerncia de riscos. A estratgia de
gerncia de riscos descreve todos os aspectos para o processo de identificao, avaliao e
controle de riscos.
ESTRATGIA DA GERNCIA DE RISCOS
1 Escopo da Gerncia da Risco
<<Determinar o escopo da gerncia de risco que ser utilizado pelo projeto, de acordo com as polticas de gerncia de risco
organizacional. Nesta atividade sero definidos recursos de hardware, software e pessoal necessrio realizao da gerncia
de risco, baseando no escopo do projeto.>>
2 Tempo de reavaliao e monitorao de riscos
<<Intervalo de tempo para monitoramento e reavaliao dos riscos>>
3 Mtodos e ferramentas

<<Mtodos e ferramentas a serem utilizadas para a identificao, anlise, mitigao, monitoramento e comunicao de riscos.
Estes mtodos so apresentados ao longo deste guia, tais como taxonomia de riscos, clculo do fator de exposio,
entrevistas, brainstorming, delphi, estratgias de tratamento de riscos, emisso de relatrios de risco etc.>>
4 Organizao dos riscos
<<Como estes riscos so organizados (por exemplo, por meio de uma taxonomia), categorizados, comparados e consolidados
(por exemplo, riscos menores que fazem parte de outros riscos podem ser includos nos riscos maiores) >>
5 Parmetros
<<Parmetros, incluindo a probabilidade, impacto e limites>>

2 Taxonomia de riscos da organizao

A taxonomia de riscos da organizao permite que o projeto selecione as categorias e fontes
de riscos que so aplicveis a diversos projetos da organizao. Esta taxonomia pode ser
baseada em taxonomias j existentes no mercado, e, principalmente, na experincia da
prpria organizao. Com base nesta taxonomia, taxonomias especficas para cada projeto
devem ser elaboradas, e taxonomias para cada tipo de projeto (manuteno,
desenvolvimento, aquisio etc.) podem ser criadas.
Taxonomia de riscos da organizao

Categoria
<< categoria
do risco>>

Fonte de
Risco
<< fonte de
risco dentro
da
categoria>>

Justificativa
<< justificativa
para ter includo
o risco dentro
desta categoria
>>

Tcnicas de
tratamento de
riscos
<< tcnicas que
podem ser
aplicadas para
tratar riscos
desta fonte de
riscos >>

Limites para monitorao

<< limites que podem ser
monitorados para verificar se
o risco est prximo, ou
aconteceu >>

Procedimento de
medio
<< procedimentos de
coletar dados para
as mtricas que
podem ser usadas
para verificar se os
limites foram
atingidos >>

3 Registro de Riscos
O formulrio de registro de riscos dever conter todas as informaes extradas durante as
etapas de identificao e anlise dos riscos do projeto (SG2).
Riscos identificados
Categoria
Id
<<
<< categoria
identificador
do risco
nico do
encontrado
risco >>
>>

Fonte de
Risco
<< fonte de
risco >>

Se...
<< se
determinada
condio
acontecer >>

Ento...
<< ento
determinado
impacto
acontecer
>>

Probabilidade
<<
probabilidade
do risco
acontecer com
base na
escala
definida >>

Impacto
<<
impacto
caso o
risco
acontea
com base
na escala
definida
>>

Fator de
Exposio
<< clculo
baseado na
probabilidade
e no impacto
definido >>

4 Planos de mitigao dos riscos

O formulrio de definio dos planos de mitigao dos riscos dever conter todas as
informaes extradas durante a etapas de desenvolvimento dos planos de mitigao de
riscos (SG3 - SP3.1).
Plano de Mitigao de Riscos
Responsvel
Id
<<
<<
identificador
responsvel
nico do
pela
risco >>
preveno dos
riscos >>

Estratgia
<< mitigar,
transferir,
aceitar, etc.
>>

Preveno
<< tcnica de prevena escolhida para
tentar mitigar o risco >>

Limite
<< limite a
ser
monitorado
para verificar
se o risco
aconteceu ou
est prximo
de acontecer
>>

Plano de
Contingncia
<< ao a ser
executada
caso o risco
acontea >>

5 Relatrio de progresso dos riscos

O relatrio de progresso dos riscos deve apresentar o status atual do risco (probabilidade,
impacto, fator de exposio) e o progresso das aes escolhidas para migiat o risco (SG3
SP3.2). Alm deste formulrio, podem ser apresentados grficos que ajudem no
entendimento do progresso das atividades de mitigao e no status dos riscos do projeto. O
progresso pode ser indicado por meio de semforos, onde verde indica progresso nas aes
de tratamento, vermelho indica que no est tendo progresso, e os riscos que acontecerem
podem ter seu progresso atualizado para aconteceu ou caso tenha sido eliminados
eliminado.

Progresso dos Riscos

Prob.
Id
Inicial
<< identificador
<< pronico do risco
babi>>
lidade
inicial >>

Imp.
Inicial
<< impacto
inicial >>

F.E.
Inicial
<< fa-tor
de exposio
inicial >>

Prob.
Atual
<< probabilidade
atual >>

Imp.
Atual
<< impacto
atual
>>

F.E.
Atual
<< fator de
exposio
atual
>>

Progresso

Observaes

<<verde,
vermelho,
eliminado ou
aconteceu >>

<< observaes
sobre o prorgresso
ou sobre o motivo
dos riscos terem
acontecido >>

6 Relatrio de acompanhamento de aes corretivas

O relatrio de acompanhamento de aes corretivas deve conter todos os riscos que
aconteceram, e onde foi necessrio executar os planos de contingncia.
Aes Corretivas
Id
Risco
<< identificador nico
do risco >>

Data Final
Responsvel
<< responsvel pela
ao corretiva >>

Data Inicial
<< data da
ao
corretiva >>

<< data
final da
ao
corretiva
>>

Ao corretiva
<< pro-babi-lidade atual
>>

Impacto
<< impacto do
risco >>

7 Relatrio de lies aprendidas

O relatrio de lies aprendidas importante para armazenar todas as lies aprendidas
durante a gerncia de risco no RCO, para que outros projetos possam consultar estas
informaes.
Lies Aprendidas
Id
Risco
Risco
(Se.. Ento...)
<< identificador
<< se determinada
nico do risco >>
condio acontecer,
ento determinado
impacto acontecer
>> >>

Aconteceu?
<< indica se o risco
aconteceu ou no
>>

Lio Aprendida
<< lies aprendidas com o risco >>