2

Definições

• Risco : (s.m) perigo; possibilidade de correr perigo.

• Risco está ligado à possibilidade de um evento

indesejável (evento de risco)
Análise de Riscos • Em um projeto, um risco é qualquer coisa que
Conceitos Básicos
possa estar no caminho para se atingir os
objetivos traçados.

• Gerenciar riscos é gerenciar o futuro do projeto e

Profs. Ivan Granja e Cristiano Portella do produto.
Engenharia de Software II

3 4
Correndo Riscos em Projetos Postura em relação a riscos....

• Riscos são inevitáveis em qualquer projeto. Cabe REATIVA

• Riscos são tratados à medida em que surgem. A
ao gerente deste projeto lidar com os riscos e equipe gasta muito tempo analisando e tentando
avaliar seu verdadeiro grau de impacto sobre o solucionar os riscos que aparecem (bombeiros
apagando incêndio).
projeto e sua probabilidade de ocorrência.

PROATIVA
• Evitar riscos ou controlar sua ocorrência é uma
• Identificação, Eliminação e Mitigação de riscos é
atividade do desenvolvimento de software,
uma atividade tipicamente de gerenciamento do realizada de maneira eficiente, por meio da Análise
e Gerenciamento de Riscos.
projeto

5 6
Cuidado com os riscos.... Tipos e Atributos de Riscos

Tipos de Riscos:
• Os Riscos devem ser continuamente avaliados, • Diretos – podem ser controlados e considerados
pois podem mudar no transcorrer do tempo.
no projeto
• Pequenos problemas podem mascarar os reais • Indiretos – Pouco grau ou nenhum controle no
projeto
problemas a serem enfrentados..... (ou: conhecidos, previsíveis e imprevisíveis)

Atributos de Riscos:
• Probabilidade de Ocorrência
• Impacto sobre o projeto (Severidade)

1
 7 8
Ricos e o RUP® Ricos e o RUP®

Perfil dos Riscos por fase do Processo no RUP:

Filosofia do RUP: • Iniciação: Riscos para o Negócio e também os
ainda desconhecidos
Os maiores riscos devem ser tratados nas
• Elaboração: Riscos para a Arquitetura do
primeiras iterações do software. Quanto mais Software e Cenários Críticos
tarde um risco for descoberto, mais caro ele • Construção: Ricos associados ao
custará. desenvolvimento e conclusão do sistema
• Transição: Riscos baseados nos indicadores de
qualidade do produto final (Controle de
Qualidade)

9 10
Gerenciamento de Riscos Atitudes frente aos Riscos

• Projetos não devem ser (e nunca serão) artefatos Exemplo de péssima atitude gerencial para uma
de software congelados. efetiva redução dos riscos:
• Todo projeto precisará de replanejamento, sem
que o gerente se culpe por isso. Gerente: E aí fulano e aquele risco que
identificamos??? Sob controle???
• Identificação de riscos durante as etapas do
projeto deve necessariamente implicar em
Analista (com os dedos cruzados): Claro
reorganização do projeto para que ele não seja
Chefia...... Tudo sob controle.....
afetado pelo risco identificado.

• Não há como evitar riscos. Aceite e conviva com Bons exemplos vêm de cima.......
eles.

11 12
Medidas simples para gerenciar riscos Classes de Riscos

• Monitorar os riscos e ter certeza que eles foram Riscos para o Negócio
eliminados. Manter uma lista de riscos do projeto
em andamento • Concorrência

• Confrontar riscos com outros já vividos e projetos

anteriores. Guardar uma lista de riscos já
solucionados e as medidas tomadas para conviver
com ele.
• Manter PLANO DE CONTINGÊNCIA. Um plano B
muitas vezes pode salvar um projeto quando um
risco insiste em nos pregar peças.
• Condições de Competição
• Legislação
• Político (tais como mudança de governo, de
diretoria...)
• Interação com outros sistemas (Internos ou de
parceiros, fornecedores, clientes etc..)

2
 13
Classes de Riscos
Riscos de Recursos
• Pessoas
• Habilidades
• Disponibilidade
• Capital e Budget (”orçamento”)
15
Classes de Riscos
Riscos de Gerenciamento do Dia-a-Dia
• Funcionários Descontentes
• Baixa produtividade
• Tempo e Cronograma (regra da Gestação: É
impossível gerar um filho em 3 meses, mesmo
usando 3 mulheres ao mesmo tempo.....)
• “Deadlines” e Prazos de Entrega
• Garantia de qualidade e aderência a padrões
• Garantia de SLA (Acordo de Nível de Serviço)
17
Identificação de Riscos
• Riscos estão associados ao projeto e não a partes
de um projeto.
• A grade maioria dos Riscos podem ser listados
logo nas fases preliminares.
• Riscos identificados tardiamente não podem ser
ignorados ou desprezados.
Risco Identificado, plano traçado!
14
Classes de Riscos
Riscos Técnicos e Tecnológicos
• Tecnologia não comprovada ou maturada
• Tecnologia recém implantada na empresa
• Escopo de Sistema Incerto
16
Classes de Riscos
Riscos Imprevisíveis (ou de baixa previsibilidade)
• Pedidos de Demissão
• Doenças (simples e Graves)
• Desvios de pessoal experiente para projetos
prioritários
• Alocação de pessoal pouco experiente em
projetos de menor prioridade
• etc....
18
Mitigação de Riscos
MITIGAR: (verbo transitivo direto e pronominal)
• tornar(-se) mais brando, mais suave, menos intenso (dor, sofrimento
etc.); aliviar, suavizar, aplacar.
• Ex.: m. a saudade, a sede, a ira etc.
• É uma estratégia pró-ativa (prévia, ativa) de diminuir a
probabilidade da ocorrência de um risco ou o impacto de
sua ocorrência.
• Já que não existe mágica no gerenciamento de riscos,
tentar resolver os riscos o mais cedo possível é uma
estratégia inteligente.
3
 19 20
Técnicas para Lidar com Riscos Análise de Riscos por Casos de Uso

RUP é dirigido por Caso de Uso; toda iteração só

• Técnicas Estruturadas e Não-Estruturadas poderá focar na mitigação de riscos que estiverem
ligados a estes Casos de Uso.
• Exemplo:
• Baseadas em Conhecimento prévio e dados • Risco 1 (tecnológico): Uso de Sistema
históricos Gerenciador de Banco de Dados nunca usado
antes.
• Risco 2 (Gerenciamento de Projeto): SLA (24x7)
Altíssimo.
• Checklists e recomendações podem ser obtidos e
• Casos de Uso
refinados como produto da experiência acumulada • Cadastrar Clientes
• Realizar Compra por Internet
no gerenciamento de riscos
• Qual a relação entre os riscos e os Casos de
Uso???

21 Tabela Riscos versus Casos de Uso: 22

Tabela Risco por Casos de Uso
Prós e Contras
UC# UC# UC# UC# UC# UC# ..... Prós:
1 2 3 4 5 6 • Identificação de Casos de Uso que podem ser
Risco #1 x x usados para um plano de mitigação de riscos
Risco #2 x x • Permite o Planejamento detalhado das fases e
Iterações
Risco #3 x Contras:
• Não existe graduação de riscos (0-10) ou
Risco #4 x x
(severo, médio e baixo).
Risco #5 x • Permite uso de Critério de Escolha inapropriado.
• Ex: Escolher um caso de uso que mitiga 50% da lista
Risco #6 x x x de riscos. Porém, se analisarmos a graduação destes
....... 50% de riscos, concluímos que a maioria deles são
riscos de baixa graduação.

23 24
Mais considerações... RUP® e Mitigação de Riscos

• Mesmo que ainda não seja possível prever a
severidade e os reais impactos de alguns tipos de
riscos, como por exemplo associadas à arquitetura
do software ou novas tecnologias que deverão ser
usadas, faça análise de risco.
• RUP® é aderente ao conceito de mitigação de
riscos
• Cada fase tem seu perfil de risco associado.
• O milestone (marco de projeto) de LCA (de
transição de elaboração para construção) toma
como ideal que 100% dos riscos tecnológicos e de
arquitetura tenham sido mitigados.

• Os homens que tomam decisões devem estar

cientes desses riscos, mesmo que ainda saibamos
muito pouco sobre o real impacto de alguns
deles... Release do
LCO LCA IOC
Produto

4
 25 Ciclos de Vida de Software 26
Outras Ferramentas para Análise de Riscos
Análise de Riscos no Modelo Espiral
Análise de Riscos:
1o) Probabilidade da ocorrência de um evento.
• Elaboração de Diretrizes e uso de planilhas para
graduação de riscos 2o) Conseqüente perda estimada (exposição ao
risco)

• Análise de Probabilidade e Exposição aos Riscos

1o) Probabilidade “p” de que um determinado evento
ocorra (1=< p >= 0)
Se existir probabilidade do evento ocorrer (> 0),
será um evento aleatório e deve ser estimado.

Ciclos de Vida de Software 27 Ciclos de Vida de Software 28

Análise de Riscos no Modelo Espiral Análise de Riscos no Modelo Espiral
Probabilidade de um evento ocorrer pr(E):
no _ de _ eventos _ favoráveis
pr ( E ) = No de falhas em instruções
no _ de _ eventos _ possíveis de comando, em razão da
perda do sensor
Por exemplo, o robô Sojourner (antiga missão Nasa pr(E) = ________________________
em Marte) estava exposto ao risco do No total de instruções de
congelamento de um sensor de impacto comando que necessitam
de entrada do sensor
(temperatura ambiente de –58ºC) e caso isso
ocorresse, o impacto poderia danificar esse
sensor. Nesse caso, equipes de Terra teriam pr(E) = 6.552 / 18.820 = 0,35
que modificar o código para que o programa
executasse sem esse sensor.

Ciclos de Vida de Software 29 Ciclos de Vida de Software 30

Análise de Riscos no Modelo Espiral Análise de Riscos no Modelo Espiral
Assumindo que uma falha no módulo de comando Se for risco excessivo, o que precisará ser feito no
resulte uma perda de $ 45.000 (custo de projeto para eliminar esse risco ?
homens/mês necessários para modificar o • Reforçar o sensor
módulo de comando de forma que ele volte a • Colocar sensor reserva
funcionar sem o sensor quebrado .. • Proteger o sensor
• Mudar projeto do sensor
Exposição ao Risco
• Criar módulo de software flexibilizado para
ER = (0,35 * 45.000)/10 = 1.575
executar sem falhas, com e sem o sinal do
O coeficiente 1.575 indica risco excessivo ou pode sensor.
ser “bancado” ? • etc

5
 Ciclos de Vida de Software
Análise de Riscos no Modelo Espiral
O modelo em espiral preconiza o desenvolvimento
de software através da avaliação de riscos obtidos
através de sucessivas prototipagens (e/ou
simulações e benchmarking).
Desvantagem:
Aumento de prazo Ö custos no projeto.
Justificativa para isso:
• Complexidade do projeto
• Incerteza nos requisitos
33
Identificação de Riscos
Identificação de Riscos
• É uma tentativa sistemática de se especificar
ameaças ao plano do projeto (prazo, custos, carga
de recursos, etc.)
• Identificando-se os possíveis riscos pode-se tentar
evitá-los, quando possível, e controlá-los quando
necessário
• Podemos identificar dois grandes grupos de risco:
riscos genéricos e riscos específicos do
produto.
35
Identificação de Riscos
Riscos relativos ao tamanho do produto
• grau de confiança na variável de dimensionamento
do sistema
• desvio relativo da variável de dimensionamento do
real realizado em projetos anteriores
• tamanho dos bancos de dados criados e/ou
usados pelo produto
• número de usuários do produto
• número de alterações projetadas aos requisitos do
produto, antes e depois da entrega
• quantidade de reutilização de software
implementada
31 32
Gerenciamento de Riscos
Classes de riscos:
• Riscos do Software / riscos de projeto:
ameaçam o planejamento do projeto, com perda
de controle sobre o cronograma e sobre os custos.
• Riscos tecnológicos: ameaçam a qualidade e o
cronograma de uso do software.
• Riscos de negócio: ameaçam a viabilidade do
software a ser desenvolvido.
34
Identificação de Riscos
Identificação de Riscos
Um dos métodos utilizados na identificação de riscos
consiste na criação de listas de verificação,
baseadas nas seguintes subcategorias:
• tamanho do produto
• impacto no negócio
• características do cliente
• definição do processo
• ambiente de desenvolvimento
• tecnologia a ser construída
• tamanho e experiência da equipe de
desenvolvimento.
36
Identificação de Riscos
Riscos devidos ao impacto no negócio
• conflitos entre as metas de marketing e realidades
técnicas
• impacto do produto no faturamento/lucro da
empresa
• visibilidade do produto/projeto à gerência principal
• realismo da data final de entrega
• número de clientes que irão utilizar o produto
• consistência de suas necessidades em relação ao
número de outros sistemas com os quais o produto
precisa operar em conjunto
• sofisticação dos usuários finais
6
 37
Identificação de Riscos
Riscos devidos ao impacto no negócio
• quantidade e qualidade da documentação do
produto a ser produzida e entregue ao usuário
• limitações legais à produção do produto
• custos associados à entrega atrasada do
projeto/produto
• custos associados à entrega do produto com
defeito
39
Identificação de Riscos
Riscos devido às características do cliente
• projetos com o mesmo cliente no passado – o
cliente deve conhecer suas necessidades (por
escrito)
• deve haver concordância na especificação formal
dos requisitos, ainda que através de processo
formal – o cliente deve facilitar a comunicação com
o desenvolvedor
• o cliente deve participar das revisões técnicas
• o cliente deve manter-se afastado da equipe de
desenvolvimento, quando da execução de serviços
técnicos detalhados (internos)
• o cliente precisa entender o processo de software
41
Identificação de Riscos
Riscos do Processo
• relacionados à condução interna do processo
• processo padrão como política organizacional
• extensiva documentação do processo adotado
• ampla divulgação dos padrões adotados
• comprometimento da equipe técnica com o
processo adotado
• utilização efetiva do processo nos projetos
• treinamento técnico e gerencial da equipe
• desenvolvimento de modelos de documentos a
serem entregues em cada fase do processo de
software
38
Identificação de Riscos
Riscos devido às características do cliente
• Desempenha um papel importante no contexto do
desenvolvimento
• Clientes têm diferentes necessidades
• Clientes têm diferentes personalidades
• Clientes têm diferentes formas de relacionamento
com seus fornecedores
• Um “mau” cliente pode causar um grande impacto
na produção do sistema no prazo e nos custos
previstos
40
Identificação de Riscos
Riscos do Processo
Estão especialmente presentes se:
• o processo é conduzido de forma ad hoc;
• todos concordam com o aspecto qualidade mas
ninguém trabalha para obtê-la
42
Identificação de Riscos
Riscos do Processo
• condução de revisões técnicas formais para cada
documento produzido em cada atividade do
desenvolvimento
• documentar os resultados das revisões técnicas formais
• mecanismo de verificação de conformidade das atividades
desenvolvidas com os padrões de engenharia de software
• utilização de gerenciamento de configuração, de forma a
manter consistência entre os documentos, através das
diversas atividades e versões
• utilização de mecanismo para controle de alterações ao
sistema e avaliação de seu impacto gerenciamento de sub-
contratos, com desenvolvimento de um planejamento para
cada sub-contratado
7
 43
Identificação de Riscos
Riscos do Processo
• deve existir um procedimento padrão para
acompanhamento e revisão de desempenho dos
sub-contratados:
• relativos à condução técnica e
• utilização de técnicas para melhorar a comunicação
com o cliente
• utilização de métodos específicos para análise
• utilização de métodos específicos para o projeto
da modelagem de dados e de arquitetura
• Legibilidade e manutebilidade do código fonte
• existência de padrões específicos para
documentação de código
45
Identificação de Riscos
Riscos Tecnológicos
• existência de interfaces com hardware não testado
• existência de interfaces com sistemas de outros
fabricantes e ainda não testados
• existência de interação com bancos de dados
ainda não testados na área de aplicação do projeto
em desenvolvimento
• necessidade do desenvolvimento de uma interface
com usuário especializada
• necessidade de desenvolvimento de componentes
diferentes dos desenvolvidos pela empresa em
projetos anteriores
47
Identificação de Riscos
Riscos associados ao tamanho e qualificação da
equipe técnica
• disponibilidade de pessoas de alto nível técnico (as
melhores)
• correta combinação de qualificações para cada membro da
equipe
• pessoas disponíveis e em quantidade suficiente
• compromisso da equipe com o cumprimento de prazos
(tempo de duração do projeto)
• existência de pessoas que estarão trabalhando em regime
de meio período no projeto
• equipe extensamente treinada
• alta rotatividade (turn-over) na equipe
44
Identificação de Riscos
Riscos Tecnológicos
Avançar os limites da tecnologia é desafiador e
excitante – é também muito arriscado.
Alguns riscos associados à tecnologia:
• projetos desenvolvidos em uma tecnologia nova
para a organização
• requisitos que demandem a construção de novos
algoritmos ou o desenvolvimento de novas
tecnologias de entrada e saída
46
Identificação de Riscos
Riscos Tecnológicos
• utilização de novos métodos de análise, projeto e
teste
• utilização de métodos não convencionais, tais
como métodos formais, enfoques de inteligência
artificial, e redes neurais
• presença de importantes e elevadas restrições de
desempenho
• incerteza do cliente quanto a possibilidade de se
produzir um sistema com a funcionalidade
solicitada
48
Gerenciamento dos Riscos
Gerenciamento dos Riscos
Consiste em se fazer uma estimativa dos riscos para
o projeto. Os riscos são avaliados em duas
dimensões:
• probabilidade de o risco acontecer
• conseqüências dos problemas associados aos
riscos
De forma cíclica os riscos são reavaliados de
forma a verificar se ainda estão presentes e se as
probabilidades atribuídas são ainda válidas ou
precisam ser revistas.
8
 49 50
Gerenciamento dos Riscos Gerenciamento dos Riscos

Gerenciamento dos Riscos Gerenciamento dos Riscos

• Tabela de riscos é uma técnica simples para o • os riscos são levantados pela equipe técnica
gerenciamento de riscos
• são classificados em um dos cinco grupos
• consiste de uma tabela contendo todos os riscos,
sua categoria (de acordo com os critérios • cada integrante da equipe estima a probabilidade
estabelecidos), sua probabilidade de ocorrência e de ocorrência do risco e uma média é tomada
seu impacto no projeto de software como a probabilidade daquele risco
• Um critério para classificação dos riscos pode ser: • uma possibilidade é calcular o impacto no projeto,
1 - catastrófico
usando-se tabelas divulgadas na literatura técnica.
2 - crítico
3 - marginal O exemplo a seguir utiliza-se de um tabela
4 - negligenciável desenvolvida pela U.S. Air Force (DoD).

1-catastrófico 2-crítico 51 52
Gerenciamento dos Riscos 3-marginal 4-negligenciável Gerenciamento dos Riscos

PS -project size BU -business risk TE -technological risk

DE -development environment ST -staff risk

53 54
Gerenciamento dos Riscos Gerenciamento dos Riscos

• A tabela de risco deve ser ordenada por Avaliando o impacto do risco

probabilidade e impacto Três fatores afetam as prováveis conseqüências se
• deve ser definida uma linha de corte que define os um risco ocorrer
riscos que serão acompanhados de perto • sua natureza indicam os problemas que podem
• riscos de alto impacto mas com baixa ocorrer caso um risco se materialize
probabilidade de ocorrência não devem consumir • seu escopo combina sua severidade (quão grave é
tempo significativo de gerenciamento o problema) com sua distribuição global no projeto
• riscos com probabilidade de moderada a alta e (quanto do projeto será afetado)
com baixos impactos de alta probabilidade devem • sua ocorrência (timing) relaciona-se com quando
ser gerenciados e por quanto tempo o problema será percebido

9
 55 56
Gerenciamento dos Riscos Gerenciamento dos Riscos

Calculando um valor para o risco Plano de Contingência

• envolve a definição de um nível de referência para
o risco
• existe um limite para a ocorrência dos fatores de
risco que ensejarão o fim do projeto
• no contexto de análise de risco, existe um ponto
denominado ponto de referência ou ponto de
ruptura, no qual a decisão de continuar com o
projeto ou encerrá-lo são igualmente aceitáveis
• o plano de contingência assume que o risco
ocorreu
• as atitudes dependerão do risco e de seu impacto
no projeto
• deve-se notar que os passos do RMMM (Risk
Mitigation, Monitoring and Management)
aumentam os custos
• é parte do gerenciamento de riscos avaliar a
viabilidade econômica de sua implementação

57
Gerenciamento dos Riscos

Diminuição, monitoramento e gerenciamento de

riscos
Como regra prática (Pareto 80/20) podemos
adotar:
• 80% dos riscos gerais do projeto podem ser
atribuídos a apenas 20% dos riscos
identificados
• Assim, parte das atividades de gerenciamento de
risco envolve a determinação desses 20% de
riscos críticos, que irão compor as atividades de
RMMM.

10