ÍNDICE

Introdução ............................................................................... 0
3
1 Análise dos Riscos ............................................................................... 0
4
1.1 Identificação dos ............................................................................... 0
Riscos 4
1.2 Projeção dos Riscos ............................................................................... 0
5
1.3 Avaliação dos Riscos ............................................................................... 0
7
1.4 Gerenciamento e
monitoração dos Riscos ............................................................................... 0
8
Conclusão ............................................................................... 11
Bibliografia ............................................................................... 1
2
 INTRODUÇÃO

Análise dos Riscos

Sempre que um programa de computador for construído haverá áreas

de incerteza. As necessidades do computador são de fato atendidas? As
funções que devem ser implementadas podem ser antes do prazo final do
projeto? Surgirão problemas técnicos difíceis que atualmente estão de nossa
visão? As mudanças que invariavelmente ocorrem durante qualquer projeto
farão com que a programação se desvie muito do curso? Essas são algumas
questões pela qual surgiu a análise de riscos.
A análise dos riscos é crucial para um bom gerenciamento de projeto de
software e, contudo, muitos projetos são levados a efeito sem nenhuma
consideração específica dos riscos. Onde tem como uma das principais
características a preocupação com acontecimentos futuros o qual você nunca
saberá o que vai acontecer com determinado projeto.
 1 - Análise dos Riscos

Quando o risco é considerado no contexto da engenharia de software,

os três pilares conceituais que sempre estarão em evidência serão: o futuro, a
mudança e a escolha. O futuro pelo fato de quais riscos poderiam fazer com
que o projeto de software não saísse como planejado? A mudança , como as
mudanças nos requisitos do cliente, nas tecnologias de desenvolvimento, nos
computadores de destino e em todas as demais entidades ligadas ao projeto
afetarão o sucesso global e o cumprimento do cronograma? E a escolha, qual
o método e ferramentas devemos usar, quantas pessoas devem ser
envolvidas, quanta ênfase sobre a qualidade é suficiente?
A análise dos riscos é, de fatos, uma série de passos de administração
de riscos que nos possibilita atacar o risco, que tem como função quatro
atividades distintas: identificação dos riscos, projeção do riscos, avaliação dos
riscos, gerenciamento e monitoração dos riscos.

1.1 - Identificação dos Riscos

Antes que possamos identificar os “riscos certos” a serem assumidos

durante um projeto de software, é importante identificar todos os riscos que
sejam óbvios tanto aos gerentes como aos profissionais.
É possível dividir os riscos em categorias de muitas maneiras diferentes.
Em nível macroscópico, podem ser definidos os riscos de projeto, riscos
técnicos e riscos de negócio. Os riscos de projeto identificam problemas
orçamentários, de cronograma, de pessoal (composição do pessoal e
organização), de recursos, de clientes e de requisitos, e o impacto dos mesmos
sobre o projeto do software.Os riscos técnicos identificam potenciais problemas
de projeto, implementação, interface, verificação e manutenção. Além disso, a
ambigüidade de especificação, incerteza técnica, obsolescência técnica e
tecnologia “de ponta” também são fatores de riscos. Os riscos técnicos ocorrem
porque um problema é mais difícil de ser resolvido do que imaginávamos. Os
riscos de negócio são insidiosos, porque podem distribuir os resultados até
mesmo dos melhores projetos de software. Entre os candidatos aos cinco
riscos de negócio de maior destaque encontram-se:
1. construir um excelente produto que ninguém realmente quer (risco de
mercado);
2. construir um produto que não mais se encaixe na estratégia global de
produtos da empresa;
3. construir um produto que a equipe de vendas não sabe como vender;
4. perder o apoio da alta administração devido à mudança de enfoque
ou mudança de pessoas (risco administrativo);
5. perder o compromisso orçamentário ou de pessoal (risco
orçamentário).
É extremamente importante observar que a simples divisão em
categorias nem sempre funcionará. Alguns riscos são simplesmente
impossíveis de ser prognosticados antecipadamente.
A identificação dos riscos envolve a relação dos riscos específicos de
projeto dentro das amplas categorias acima esboçadas. Um dos melhores
métodos para se entender cada um dos riscos é usar um conjunto de
perguntas que ajude o planejador do projeto a compreender os riscos em
termos técnicos ou de projeto. O uso de um “checklist de itens de riscos” – um
conjunto de perguntas que seja pertinente a cada fator de risco. Por exemplo, o
planejador poderia atingir uma compreensão dos riscos de composição do
pessoal ao responder às seguintes perguntas:
• São as melhores pessoas disponíveis?
• As pessoas têm a combinação certa de habilidades?
• Há pessoas suficientes à disposição?
• O pessoal está comprometido com toda a duração do projeto?
• Algum membro do pessoal do projeto estará trabalhando somente
em tempo parcial nesse projeto?
• O pessoal tem as expectativas certas sobre o trabalho que tem à
mão?
• Os membros do pessoal receberam o treinamento necessários?
• A rotatividade entre os membros do pessoal será baixa o bastante
para permitir continuidade?
A certeza relativa das respostas a essas perguntas permitirá que o
planejador estime o impacto dos riscos na composição da equipe.

1.2 - Projeção dos Riscos

A projeção dos riscos, também chamada estimativa dos riscos, tenta

classificar cada risco de duas maneiras – a probabilidade de que o risco seja
real e as conseqüências dos problemas associados ao risco, caso ele ocorra. O
planejador do projeto, juntamente com outros gerentes e o pessoal técnico,
executa quatro atividades de projeção dos riscos:
1. estabelecimento de uma escala que reflita a probabilidade percebida
de ocorrência de um risco;
2. delineamento das conseqüências do risco;
3. estimativa do impacto do risco sobre o projeto e o produto;
4. anotação da precisão global da projeção dos riscos de forma que não
haja mal-entendidos.
Uma escala pode ser definida em termos booleanos, qualitativos ou
quantitativos. Ao extremo, cada pergunta da lista de conferência (checklist) de
itens de riscos poderia ser respondida com um “sim” ou “não”, mas isso é
altamente irrealístico. Raramente é possível avaliar-se aos riscos em termos
absolutos. Uma abordagem melhor poderia ser a de dar uma resposta de
acordo com uma escala de probabilidades qualitativa que tivesse os seguintes
valores:
• altamente improvável;
• improvável;
• moderado;
• provável;
• altamente provável.
Alternativamente, o planejador poderia calcular a probabilidade ,
matemática de que o risco venha a ocorrer (por exemplo, uma probabilidade de
0,90 implica um risco altamente provável). Probabilidades numéricas podem
ser estimadas usando-se a análise estatística das métricas compiladas de
experiências passadas, da intuição e de outras informações. Por exemplo, se
as medidas compiladas de 45 projetos indicam que 37 projetos
experimentaram o dobro de mudanças feitas pelo cliente do que as
originalmente previstas, a probabilidade de que um novo projeto experimente
números de mudança excessivos é de 37/45=0,82, muito provavelmente.
Finalmente, os riscos são ponderados em função do possível impacto
percebido (sobre o projeto) e depois colocados em ordem de prioridade. Três
fatores afetam o impacto: sua natureza, seu escopo e seu tempo de ocorrência.
A natureza do risco indica os problemas prováveis se ele ocorrer. Por exemplo,
uma interface externa com o hardware do cliente mal definida (um risco
técnico) frustrará a realização do projeto e dos testes e provavelmente levará a
problemas na integração do sistema posteriormente. O escopo de um risco
combina a gravidade (quão sério ele é?) com sua distribuição global (quanto do
projeto será afetado ou quantos clientes serão prejudicados?). E o tempo de
ocorrência de um risco considera quando e por quanto tempo o impacto será
sentido. Na maioria dos casos, o gerente de projetos talvez queira que as “más
notícias” cheguem tão logo seja possível, mas, em alguns casos, quanto mais
tempo elas se atrasarem, melhor.
Consultando a Figura 1, observamos que o impacto e a probabilidade de
riscos exercem uma pressão diferente sobre a preocupação gerencial. Um fator
de risco que tenha um peso de elevado impacto, mas uma probabilidade de
ocorrência muita baixa, não observará uma significativa quantidade de tempo
gerencial. Porém, os riscos de elevado impacto com probabilidade de
ocorrência variando de moderada a alta e os riscos de baixo impacto com
probabilidade elevada devem ser transportados para as etapas de análise dos
riscos que se seguem.

Figura 1 – Risco e preocupação gerencial.

1.3 - Avaliação dos Riscos

A essa altura do processo de análise dos riscos, estabelecemos um

conjunto de termos que tem a forma:
ri - é o risco
li - é a probabilidade do risco
xi - é o impacto do risco
Durante a avaliação dos riscos, examinaremos mais detalhadamente a
precisão das estimativas que foram feitas durante a projeção dos riscos,
tentaremos determinar uma ordem de prioridade para os riscos que foram
descobertos e começaremos a pensar em maneiras de controlar e/ou evitar
riscos que têm a probabilidade de ocorrer.
Afim de que a avaliação seja útil, um nível de risco referente deve ser
definido. Para a maioria dos projetos de software, o custo, os prazos e o
desempenho representam três níveis de risco típicos. Ou seja, há um nível
para o excesso de custos, para o descumprimento do cronograma ou para a
degradação do desempenho (ou qualquer combinação dos três) que fará com
que o projeto seja encerrado. Se uma combinação de riscos criar problemas
que façam com que um ou mais desses níveis referentes sejam ultrapassados,
o trabalho encerrar-se-á. No contexto da análise de riscos de software um nível
de risco referente tem um ponto simples, denominado ponto referente ou Break
Point, em que as decisões de continuar o projeto ou encerra-lo (os problemas
são grandes demais) são igualmente aceitáveis.
A Figura 2, representa essa situação graficamente. Se uma combinação
de riscos levar a problemas que façam com que o custo ou os prazos sejam
ultrapassados, haverá um nível, representado pela curva da figura, que (ao ser
ultrapassado) provocará o encerramento do projeto (a região mais escura). No
break point, as decisões de prosseguir ou encerrar o projeto têm igual peso.

Figura 2 – Nível de risco referente

Na realidade, o break point raramente poderá ser representado como
uma linha uniforme sobre um gráfico. Na maioria dos casos, ele é uma região
em que há áreas de incerteza, isto é, tentar prever uma decisão administrativa
baseando-se na combinação dos valores referentes muitas vezes é impossível.
Portanto, durante a avaliação dos riscos, efetuamos as seguintes
etapas:
1. Definimos os níveis de risco referentes para o projeto;
2. Tentamos desenvolver um relacionamento entre cada [Ri, Li, Xi] e
cada um dos níveis referentes
3. Prevemos o conjunto de pontos referentes que define uma região de
encerramento, delimitados por uma curva ou área de incerteza; e
4. Tentamos prever como associações combinadas dos riscos afetarão
um nível referente.
 1.4 - Gerenciamento e Monitoração dos Riscos

A atividade de gerenciamento e monitoração dos riscos é ilustrada

esquematicamente na Figura 3. O trio (descrição, probabilidade e impacto dos
riscos) associado a cada risco é usado como uma base a partir da qual os
passos de gerenciamento dos riscos (ou aversão sos riscos) são
desenvolvidos. Por exemplo, suponhamos que a alta rotatividade de pessoal
seja observada como um risco ao projeto, r1. Baseando-se na história passada
e na intuição administrativa, a probabilidade, l1, de elevada rotatividade de
pessoal é estimada como sendo de 0,70 (70%, bastante elevada) e o impacto,
x1, é projetado para aumentar a duração do projeto em 15% e o custo global
em 12%. Colocados esses dados, os seguintes passos de administração dos
risco são propostos:
• Reunir-se com o pessoal atual para determinar as causas da
rotatividade de pessoal (por exemplo, condições de trabalho ruins,
salários baixos, mercado de trabalho competitivo).
• Tomar providências para mitigar aquelas causas que estejam sob
nosso controle antes que o projeto se inicie.
• Assim que o projeto se iniciar, pressupor que haverá rotatividade
de pessoal e desenvolver técnicas para garantir a continuidade
quando as pessoas saírem.
• Organizar equipes de projeto de forma que as informações a
respeito de cada atividade sejam amplamente difundidas.
• Definir padrões de documentação e estabelecer mecanismos para
se certificar de que os documentos sejam desenvolvidos de
maneira oportuna.
• Realizar revisões de todo o trabalho com os colegas de forma que
mais de uma pessoa esteja a par das atividades desenvolvidas.
• Definir um membro do pessoal que sirva de backup para cada
profissional mais crítico.
É importante observar que esses passos de administração dos riscos
acarretam custos de projeto adicionais. Por exemplo, o tempo gasto para
prover o backup para cada profissional crítico custa dinheiro. Parte da
administração dos riscos, portanto, significa avaliar quando os benefícios
advindos das atividades tomadas para evitá-los são ultrapassados pelos custos
associados à implementação dos mesmos. Essencialmente, o planejador de
projetos executa uma análise de custo-benefício clássica. Se as providências
para evitar os riscos da alta rotatividade de pessoal aumentarem o custo e a
duração do projeto em 15%, e o fator de custo predominante for o backup, a
administração poderá decidir não implementar esse passo. Por outro lado, se
os passos de administração dos riscos forem projetados para aumentar os
custos em 5% e a duração em apenas 3%, a administração provavelmente os
colocará em prática.
Figura 3 – Gerenciamento e monitoração dos riscos

Para um grande projeto, 30 ou 40 riscos podem ser identificados. Se

entre três sete passos de administração de riscos forem identificadas para cada
um, a administração dos riscos pode tornar-se um projeto em si mesma! Por
essa razão, adaptamos a regra 80/20 de Pareto aos riscos do software. A
experiência indica 80% dos riscos globais do projeto (isto é, 80% do potencial
de fracasso do projeto) podem ser correspondentes a apenas 20% dos riscos
identificados. O trabalho executado durante os primeiros passos da análise dos
riscos ajudará o planejador a determinar quais dos riscos residem nesses 20%.
Por essa razão, alguns dos riscos identificados, avaliados e projetados podem
não se encaixar no plano de administração dos riscos – eles não compreendem
os 20% críticos (os riscos com prioridade mais alta no projeto).
Consultando novamente a Figura 3, observa-se que os passos de
administração dos riscos estão organizados num Plano de Administração e
Monitoração do Riscos (PAMR). O PAMR documenta todo o trabalho executado
como parte da análise de riscos e é usado pelo gerente de projetos como parte
do Plano de Projeto global.
Assim que o PAMR tiver sido desenvolvido e o projeto iniciado, começa
a monitoração dos riscos. A monitoração dos riscos é uma atividade de
rastreamento dos projeto com três objetivos primordiais:
1. Avaliar se um risco previsto, de fato, ocorre;
2. Garantir que os passos de reversão definidos para o risco estejam
sendo adequadamente aplicados;
3. Coletar informações que possam ser usadas em análises de riscos
futuras.
Em muitos casos, os problemas que ocorrem durante um projeto podem
relacionar-se a muitos riscos. Outra tarefa da monitoração dos riscos é
tentar atribuir “culpa” [qual risco causou (ou quais riscos causaram)
problemas] ao longo do projeto.

Esboço do plano de administração e monitoração dos riscos:

I. Introdução.
1. Escopo e propósito do documento.
2. Visão geral.
a. Objetivos.
b. Prioridades para evitar os riscos.
3. Organização.
a. Administração.
 b. Responsabilidades.
c. Descrições de trabalho.
4. Descrição do programa para evitar os riscos.
a. Cronograma.
b. Marcos de referência e revisões importantes.
c. Orçamento.
II. Análise dos riscos.
1. Identificação.
a. Exame dos riscos.
(i) Finte de riscos
b. Taxonomia dos riscos.
2. Estimativa dos riscos.
a. Estimar a probabilidade dos riscos.
b. Estimar a conseqüência dos riscos.
c. Critérios de estimativa.
d. Possíveis fontes de erros de estimativa.
3. Avaliação.
a. Métodos de avaliação a serem usados.
b. Pressuposições e limitações do método de avaliação.
c. Riscos referentes da avaliação.
III. Administração dos riscos.
1. Recomendações.
2. Opções para evitar os riscos.
3. Recomendações para evitar os riscos.
4. Procedimentos de monitoração dos riscos.
IV. Apêndices.
1. Estimativa dos riscos da situação.
2. Plano de redução dos riscos.
 CONCLUSÃO

Análise dos Riscos

De fato a análise dos riscos é fundamental na resolução de um projeto

de software. Um bom projeto deve ser analisado, preocupando-se com
acontecimentos futuros. Por isso é necessário uma estratégia para atacar o
problema, estabelecendo um mecanismo para avaliar a construção do produto
usando quatro atividades (identificação dos riscos, projeção dos riscos,
avaliação dos riscos e administração dos riscos), podemos eliminar os riscos.
Com essas atividades, diminuímos os riscos que podem prejudicar os
projetos de software. Tendo assim maior poder de gerenciar o desenvolvimento
e garantir um produto final de qualidade.
 BIBLIOGAFIA
PRESSMAN, Roger S. – “ Engenharia de Software ” - Makron Books do Brasil
Editora Ltda