O documento discute a análise e gestão de riscos em projetos de software. Aborda conceitos-chave como identificação, estimativa e avaliação de riscos, além de métodos para reduzir, supervisionar e gerir riscos ao longo do projeto. O objetivo é antecipar problemas potenciais e suas consequências para que medidas corretivas possam ser tomadas e minimizar impactos negativos no projeto.
2. Sumário
Introdução
– O quê é?
– Quem faz?
– Porquê é importante?
– Qual é o produto?
– Como saber se está bem feita?
Riscos do software
Método de Identificação e estimação dos riscos
Avaliação Global do Risco
Tabela de Risco
Explorando as actividades de RSGR
2
3. Introdução (I)
O quê é?
– Série de passos que permitem compreender e gerir a
incerteza
– Um risco é um problema potencial
convém identificá-lo
avaliar a sua probabilidade de ocorrência
e estimar o seu impacto
Quem faz?
– Gestores e Engenheiros de Software
– Clientes
3
4. Introdução (II)
Porquê é importante?
– A produção de software é difícil
– Muita coisa pode correr mal.. e corre mesmo mal..
– Portanto, devemos estar preparados!
Qual o produto?
– Plano de redução, supervisão e gestão do risco
Como fazer bem?
– O risco deve ser analisado e gerido a partir dos 4 ‘P’s:
pessoal, produto, processo e projecto
4
5. Risco do SW
- aspectos importantes
Incerteza: o facto que Perda: Se o risco se
caracteriza o risco pode converter em realidade
não acontecer – Implicará consequências
– Não há riscos com 100% não desejadas ou
de probabilidade de perdas
ocorrência
5
6. Categorias de Risco
Projecto: ameaças ao Conhecidos: após
plano do projecto. avaliações do plano,
Técnico: ameaças à condições técnicas e
qualidade e o comerciais
planeamento temporal Previsíveis:
do software extrapolados de
Negócio: ameaças à experiências anteriores
viabilidade do software Imprevisíveis: difíceis
de prever com
antecedência
6
7. Identificação do Risco
Tentativa sistemática para uma especificação das
ameaças ao plano do projecto
Permite dar um passo à frente para evitá-los e
controlá-los
Riscos genéricos: ameaças potencias para todos os
projectos de software
Riscos específicos do produto: identificados só por
quem tem uma clara visão da tecnologia, o pessoal
e o ambiente específico do projecto
7
8. Método de Identificação do Risco
Criar lista de comprovação de elementos de risco
– focada num subconjunto de riscos conhecidos
– previsíveis segundo as seguintes subcategorias:
Tamanho do produto
Impacto no negócio
Características do cliente
Definição do processo
Ambiente de desenvolvimento
Tecnologia a construir
Tamanho e experiência do pessoal
8
9. Método de Identificação do Risco
- riscos gerais e do projecto pedidos no
Plano de Projecto da Lacertae SW (item 3.1)
Risco Projecto Técnico Negócio Comum Especial
Equipamento não disponível X
Requisitos incompletos X X
Uso de metodologias especiais X X
Problemas na busca da X X
confiabilidade requerida
Retenção de pessoas chave X X
Sub-estimativa do esforço X X
Desistência do único cliente X X
potencial
9
10. Avaliação Global do Risco
- também adicionar ao item 3.1
1. Os Gestores de Software e 7. Os Engenheros de Software
clientes dão suporte ao têm as competências
projecto? requeridas?
2. Os Clientes estão 8. Os requisitos do projecto são
entusiasmados com o projecto estáveis?
e o produto? 9. A Equipa de Desenvolvimento
3. Os Engenheros de Software tem experiência na tecnologia a
e os clientes compreenderam implementar?
bem os requisitos? 10. É adequado o número de
4. Os Clientes estiveram pessoas da equipa de trabalho?
envolvidos na definição dos 11. Concordam os
requisitos? Clientes/utilizadores quanto à
5. As expectativas dos importância do projecto? e nos
utilizadores são realistas? requisitos do sistema ou produto
6. O âmbito do projecto é a construir?
estável?
10
11. Estimação do Risco
Medição do risco em termos da sua probabilidade de
ocorrência e das suas consequências
Tarefas a cumprir:
1. Estabelecimento de uma escala para reflectir probabilidade
percebida do risco
2. Definição das consequências do risco
3. Estimação do impacto do risco no projecto e no produto
4. Apontar exactidão geral da estimação
12
12. Tabela de Risco
- Exemplo-modelo para o item 3.2 do Plano de Projecto
Risco Categoria Prob. Impacto RSGR
Baixa estimação do tamanho Tamanho 60% Crítico
Mais utilizadores que os previstos Tamanho 30% Marginal
Menos reutilização que a prevista Tamanho 70% Crítico
Resistência dos utilizadores Negócio 40% Marginal
Data de entrega muito ajustada Negócio 50% Crítico
Perda dos orçamentos Negócio 40% Catastróf.
Mudança nos requisitos Cliente 80% Crítico
Expectativas não satisfeitas Cliente 30% Marginal
Falta de formação nas ferramentas Pessoal 80% Marginal
Falta de experiência do pessoal Pessoal 30% Crítico
Alta rotação de pessoal Pessoal 60% Crítico
13
13. Redução do Risco
Risco identificado: “rotação de pessoal”
Plano de redução:
– Reunião com o pessoal para determinar causas da mobilidade
– Gestor de Software decide sobre a mobilidade
– Desenvolver técnicas para assegurar a continuidade
– Organizar as equipas por forma a garantir a distribuição de
informação
– Definir standards de documentação e estabelecer mecanismos
para assegurar o cumprimento das actividades de documentação
14
14. Supervisão do Risco
- Risco identificado: “rotação de pessoal”
Factores a supervisionar
– Atitude geral dos membros da equipa
– Grau de compenetração da equipa
– Relações interpessoais entre os membros
– Problemas potenciais com compensações e
benefícios
– Oferta de emprego dentro e fora da companhia
15
15. Gestão do Risco
- Risco identificado: “rotação de pessoal”
A gestão do risco e os planos de contingência
assumem que os esforços de redução falharam
Plano de Contingência:
– Cópias de segurança disponíveis
– Informação devidamente documentada
– Conhecimento disperso pela equipa
– Actividades de transferência de conhecimento entre os que
saem e os que entram
As actividades de RSGR devem ser justificadas em
termos de custos e benefícios
– Estratégia eficaz para tratar os riscos:
Evitar o risco
Supervisionar o risco
16 Gerir o risco e planos de contingência
16. RSGR
- Redução, Supervisão e Gestão do Risco
outro exemplo de risco
identificado: Risco: 1-010-77 Prob: 10% Impacto: muito alto
– usar este modelo para o
item 3.3 do Plano de Descrição: hardware especializado pode não estar disponível
Projecto da Lacertae SW
Estrategia de redução: Acelerar desenvolvimento de HW, construir
– descrever as actividades simulador
de RSGR somente para Plano de contigência: ter desenvolvimento externo de hardware como
2 ou 3 dos riscos backup, implantar sistemas num simulador
identificados
Pessoa responsável: Fred Jones (criação 1-01-01)
Status: Simulação completada 10-02-01
17
17. Avaliação do Impacto
Método da FAA (Federal Aviation Exposição ao Risco
Administration, USA)
– Determinar probabilidade
– ER = P x C
média de ocorrência de – P = probabilidade de
cada componente de risco ocorrência
– Empregando a figura da – C = custo em caso de
FAA determinar o impacto ocorrência
baseados nos critérios
mostrados
Desprezível
Marginal
Crítico
Catastrófico
– Completar a tabela de
18 risco e analisar resultados
18. Avaliação do Impacto
Identificação do risco:
– “Somente 70% dos componentes do software planeados para
reutilização, podem integrar-se na aplicação. A funcionalidade
restante será desenvolvida”
Probabilidade do Risco:
– 80%
Calculando o Custo:
– Se temos algo como 60 componentes planeados para reutilização, 30
% equivale a 18 componentes (que devem ser desenvolvidos)
– Se a quantidade (média) de Classes x componente = 3 Classes
– Se o custo de implementação x Classe = £ 317,00
– Custo global = 18 x 3 x 317 = £ 17.118
Exposição ao Risco (ER = P x C) = 0,80 x 17.118 ~ £ 13.700,00
19 A avaliação do impacto não será cobrada no Plano de Projecto..
20. Métricas para o
Processo e o Projecto de SW
Introdução
– O quê é?
– Quem faz?
– Porquê é importante?
– Qual é o produto?
– Como saber se está bem feita?
Medidas, métricas e indicadores
21
Notas del editor
Categoria 1: Riscos do projecto: Problemas de orçamento, planeamento temporal, pessoal, recursos, cliente e requisitos. Riscos técnicos: Os riscos técnicos identificam problemas potenciais a nível de desenho, implementação, de interface, verificação e de manutenção. Também ambiguidades nas especificações, incerteza técnica, técnicas antigas ou tecnologias de ponta não bem conhecidas. Os riscos técnicos ocorrem porque o problema é mais difícil de resolver do previsto Riscos do negócio: construir um produto que ninguém quer, ou não alinhado com a estratégia da empresa ou que o departamento de vendas não sabe como vender , perder o apoio de uma boa gestão devido a mudanças de foco ou de pessoal ou perder orçamento ou o pessoal atribuído Categoria 2: Riscos conhecidos: podem-se descobrir após avaliações cuidadosas do plano do projecto, do ambiente técnico e comercial do projecto e outras fontes de informação confiáveis (datas de entrega pouco realistas, falta de especificação dos requisitos o do âmbito do software) Riscos previsíveis: extrapolados da experiencia de projectos anteriores (mudanças de pessoal, má comunicação com o cliente, diminuição do esforço do pessoal a medida que atendem pedidos de manutenção) Riscos imprevisíveis: muito difíceis de predizer em avanço
Tamanho do produto: obvio Impacto no negócio: limitações impostas pela gestão ou pelo mercado Cliente: sofisticação do cliente e habilidade do informático para se comunicar com o cliente Definição do processo: grau de definição do processo e a sua monitorização Ambiente de desenvolvimento: disponibilidade e qualidade das ferramentas empregues na construção do produto Tecnologia: complexidade do sistema e a sua tecnologia associada Tamanho e experiência do pessoal: experiência técnica e de gestão de projectos dos engenheiros de software
Tamanho do produto: obvio Impacto no negócio: limitações impostas pela gestão ou pelo mercado Cliente: sofisticação do cliente e habilidade do informático para se comunicar com o cliente Definição do processo: grau de definição do processo e a sua monitorização Ambiente de desenvolvimento: disponibilidade e qualidade das ferramentas empregues na construção do produto Tecnologia: complexidade do sistema e a sua tecnologia associada Tamanho e experiência do pessoal: experiência técnica e de gestão de projectos dos engenheiros de software
As perguntas surgem dos dados do risco obtidos através de inquéritos realizados à gestores de projectos de software peritos de todas partes. As perguntas estão ordenadas segundo a sua importância relativa para o sucesso do projecto
A FAA de USA fez um documento com excelentes indicações para a identificação e previsão de riscos de software. O enfoque da FAA requer que o gestor identifique os controladores do risco que afectam os componentes do risco (performance, custo, suporte e planeamento temporal) Componentes do risco: Performance: grau de incerteza com que o produto cumprirá os seus requisitos e adequar-se-a ao seu objectivo Custo: grau de incerteza que manterá o orçamento do projecto Suporte: grau de incerteza da facilidade do software para ser corrigido, adaptado e melhorado Planeamento temporal: grau de incerteza associado ao cumprimento de prazos e gastos O impacto de cada controlador do risco no seu componente divide-se em 4 categorias (desprezável, marginal, crítico e catastrófico)
Primeiro, faz-se a lista de riscos. Pode-se fazer com a ajuda de uma lista de comprovação. Cada risco é classificado na segunda coluna. A probabilidade de aparição se põe na coluna 3. A probabilidade de risco pode determinar-se a partir de estimativas individuais e desenvolvendo depois um único valor de consenso mediante um processo de round-robin. Há outras técnicas mais sofisticadas como a valoração de escalas qualitativas (impossível, improvável, provável e frequente) que depois são associadas com esses valores qualitativos.