Resumo Seminário Gestão de Riscos

Fazer download em pptx, pdf ou txt
Fazer download em pptx, pdf ou txt
Você está na página 1de 20

GESTÃO DE RISCOS

Equipe: Annielly Ferreira


              Raquel Lima
RESUMO
No contexto da engenharia de software

Gestão de riscos são uma série de passos que ajudam uma equipe de
software a entender e gerenciar a incerteza. Muitos problemas podem
perturbar um projeto de software. O risco é um problema em potencial –
ele pode ocorrer ou não. 

Dessa forma é aconselhável identificar, avaliar sua probabilidade de


ocorrência, estimar seu impacto e estabelecer um plano de contingência
caso o risco ocorra.
São responsáveis por realizar a gestão de riscos todos os envolvidos na
gestão da qualidade, a saber: gerentes, engenheiros de software e
outros participam da análise e gestão de risco.

Lidar com Software é algo complexo e muitas coisas podem dar errado, 
por essa razão, estar sempre alerta – entender os riscos e tomar
medidas proativas para evitá-los ou administrá-los – é um elemento-
chave do bom gerenciamento de projeto de software.
E o que seriam essas tais medidas proativas?
Na verdade existem duas estratégias quando o assunto é tomar   
medidas caso os riscos ocorram, as reativas e as proativas.
Uma estratégia reativa monitora o projeto à procura de riscos
possíveis. Nesse caso, são reservados recursos para enfrentar os riscos,
caso se tornem problemas reais. Normalmente, a equipe de software
não faz nada a respeito dos riscos até que alguma coisa dê errado.
Uma estratégia proativa começa muito antes do trabalho técnico. São
identificados os riscos em potencial, avaliados a probabilidade e o
impacto, e os riscos são classificados por ordem de importância. Então,
a equipe de software estabelece um plano para gerenciar o risco.
Embora haja muito debate sobre qual é a melhor definição para risco de
software, há um consenso geral de que o risco sempre envolve duas
características: incerteza – o risco pode ou não ocorrer; e perda – se o risco se
tornar realidade, consequências indesejadas ocorrerão. 
Quando os riscos são analisados, é importante quantificar o nível de incerteza
e o grau de perda associados a cada risco. Para tanto, consideram-se
diferentes categorias de risco: 
Riscos de projeto: identificam problemas potenciais de orçamento,
cronograma, pessoal (equipes e organização), recursos, clientes e requisitos e
seu impacto sobre o projeto de software.
Riscos técnicos: identificam problemas em potencial de projeto,
implementação, interface, verificação e manutenção.
Riscos de negócio: identificam problemas potencias
de mercado, estratégico, de vendas, gerencial e de orçamento.
É extremamente importante observar que uma simples classificação de
risco nem sempre funcionará. Alguns riscos são impossíveis de prever.
Dessa foram, outra classificação geral dos riscos foi proposta por
Charette [Cha89]. 
Riscos conhecidos: são aqueles que podem ser descobertos após uma
cuidadosa avaliação do plano do projeto (exe.: data de entrega irreal);
Riscos previsíveis: são extrapolados da experiência de projetos
anteriores (comunicação deficiente com o cliente); 
Riscos imprevisíveis: são extremamente difíceis de identificar com
antecedência.
Uma vez determinada a categoria do risco é hora de conhecer as etapas
envolvidas no processo de gestão de riscos.
Reconhecer o que pode dar errado é o primeiro passo, chamado de
“identificação do risco”. Em seguida, analisar o risco para determinar a
probabilidade de que ocorra e o dano que causará se ocorrer.
Levantadas essas informações, os riscos são classificados por
probabilidade e por impacto. Por fim, é desenvolvido um plano para
gerenciar os riscos de alta probabilidade e alto impacto. 
Analisando mais a fundo cada umas dessas etapas: 
identificação do risco: é uma tentativa sistemática de
especificar ameaças ao plano do projeto. Nessa etapa são
identificados os riscos conhecidos e previsíveis. 
Há dois tipos de riscos para cada categoria.
Riscos genéricos são ameaças em potencial a todo projeto de software.
Riscos específicos de produto podem ser identificados somente por aqueles que têm
uma visão clara da tecnologia, das pessoas e do ambiente específico para o qual o
software está sendo desenvolvido. 
Um método para identificar riscos é criar uma checklist dos itens de risco nas seguintes
subcategorias genéricas:
• Tamanho do produto 
• Impacto do negócio 
• Características do envolvido
• Definição do processo
• Ambiente de desenvolvimento
• Tecnologia a ser criada
• Quantidade de pessoas e experiência
Para se avaliar um risco de forma geral é necessária responder algumas questões tais como:

1. A alta gerência e o cliente estão formalmente comprometidos em apoiar o projeto?


2. Os usuários estão bastante comprometidos com o projeto e o sistema/ produto a ser criado?
3. Os requisitos são amplamente entendidos pela equipe de engenharia de software e seus clientes?
4. Os clientes foram totalmente envolvidos na definição dos requisitos?
5. Os usuários têm expectativas realistas? 
6. O escopo do projeto é estável?
7. A equipe de engenharia de software tem a combinação de aptidões adequada?
8. Os requisitos de projeto são estáveis?
9. A equipe de projeto tem experiência com a tecnologia a ser implementada?
10. O número de pessoas na equipe de projeto é adequado para o trabalho?
11. Todos os clientes e usuários concordam com a importância do projeto e com os requisitos do
sistema/produto a ser criado
O grau de risco do projeto é diretamente proporcional ao número de respostas negativas a essas
questões.
A Força Aérea Americana [AFC88] publicou um livreto contendo excelentes
diretrizes para identificação e combate a riscos de software. Ela exige que o
gerente de projeto identifique os fatores de risco que afetam os componentes
de risco de software.
No contexto dessa discussão, os componentes de risco são definidos da
seguinte maneira: 
• Risco de desempenho – é o grau de incerteza de que o produto atenderá aos
seus requisitos e será adequado para o uso que se pretende. 
• Risco de custo – é o grau de incerteza de que o orçamento do projeto será
mantido. 
• Risco de suporte – é o grau de incerteza de que o software resultante será
fácil de corrigir, adaptar e melhorar. 
• Risco de cronograma –– é o grau de incerteza de que o cronograma do
projeto será mantido e que o produto será entregue a tempo
O impacto de cada elemento motivador de risco sobre o componente
de risco é dividido em quatro categorias de impacto
– negligenciável, marginal, crítico ou catastrófico. 
A categoria de impacto é escolhida com base na caracterização que
melhor se adapta à descrição na tabela.
Previsão do risco: também chamada de estimativa de risco, tenta classificar
cada risco de duas maneiras:
(1) a possibilidade ou probabilidade de que o risco seja real e ocorrerá e
(2) as consequências dos problemas associados ao risco, caso ele ocorra. 
Essa avaliação acontece em 4 etapas: 
1 Estabelecer uma escala que reflita a possibilidade detectada de um risco.
2. Esboçar as consequências do risco.
3. Estimar o impacto do risco sobre o projeto e o produto.
4. Avaliar a exatidão geral da projeção de risco para que não haja mal-
entendidos.
O objetivo dessas etapas é pensar os riscos de uma maneira que leve à
definição de prioridades. 
Elaborar uma tabela de
riscos é uma técnica
simples para a projeção
de riscos.
Primeiro, são listados todos os riscos (não importa quão remotos sejam) na
primeira coluna da tabela. Cada risco é caracterizado na segunda coluna (por
exemplo, PS significa risco de tamanho de projeto). A probabilidade de cada
risco é colocada na próxima coluna da tabela. O valor da probabilidade para
cada risco pode ser estimado pelos membros da equipe individualmente. 
Em seguida, avalia-se o impacto de cada risco. É investigado cada
componente de risco e determina-se uma categoria de impacto. São tiradas as
médias 3 das categorias de cada um dos quatro componentes de risco –
desempenho, suporte, custo e cronograma – para determinar um valor de
impacto global.
Uma vez preenchidas as quatro primeiras colunas da tabela, ela é ordenada
por probabilidade e por impacto. Riscos de alta probabilidade e alto impacto
se situam no topo da tabela, e riscos de baixa probabilidade posicionam-se no
fim. Com isso, conclui-se a priorização de risco de primeira ordem.
Avaliação do impacto: Três fatores afetam as prováveis consequências
caso um risco ocorra: sua natureza, seu escopo e sua época.
A natureza do risco indica os problemas que podem surgir se ele
ocorrer. O escopo de um risco relaciona a gravidade (quão sério é ele?)
com sua distribuição geral (quanto do projeto será afetado ou quantos
clientes serão prejudicados?). Por fim, a época do risco considera
quando e por quanto tempo o impacto será sentido. 
Nesse contexto, a exposição ao risco (RE, risk exposure) geral é
determinada pela seguinte relação [Hal98]:
RE = P × C
onde P é a probabilidade de ocorrência de um risco e C é o custo para o
projeto, caso o risco ocorra.
Todas as atividades de análise de risco apresentadas até aqui têm um
único objetivo: ajudar a equipe de projeto a desenvolver uma
estratégia para lidar com o risco. Uma estratégia eficaz deve considerar
três aspectos: 
Como evitar o risco;
Como monitorar o risco; e
Como gerenciar o risco e planejar a contingência.
Uma estratégia de gestão de risco pode ser incluída no plano de projeto
de software, ou as etapas de gestão de risco podem ser organizadas em
um plano de mitigação, monitoramento e gestão separado. O plano
RMMM documenta todo o trabalho executado como parte da análise
de risco e é usado pelo gerente de projeto como parte do plano geral de
projeto.
Algumas equipes de software não desenvolvem um documento RMMM
formal. Em vez disso, cada risco é documentado individualmente
usando-se um formulário de informações de risco (RIS, risk information
sheet) [Wil97].
O RIS é mantido por meio de um sistema de banco de dados para que a
criação e introdução de informações, ordem de prioridade, pesquisas e
outras análises possam ser feitas facilmente. 
Uma vez documentado o RMMM e começado o projeto, iniciam-se as
etapas de mitigação e monitoramento de risco.
O monitoramento de risco é uma atividade de acompanhamento de
projeto com três objetivos primários:
(1) avaliar se os riscos previstos vão ocorrer de fato;
(2) assegurar que as etapas de mitigação ao risco definidas para o risco
estejam sendo aplicadas adequadamente; e
(3) coletar informações que podem ser usadas para futuras análises de
riscos. 

Você também pode gostar