Análise e Gestão do Risco Aula 12 Sumário Introdução – – – – – 2 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 Introdução (I) O quê é? – – Série de passos que permitem compreender e gerir a incerteza Um risco é um problema potencial Quem faz? – – 3 convém identificá-lo avaliar a sua probabilidade de ocorrência e estimar o seu impacto Gestores e Engenheiros de Software Clientes Introdução (II) Porquê é importante? – – – Qual o produto? – A produção de software é difícil Muita coisa pode correr mal.. e corre mesmo mal.. Portanto, devemos estar preparados! Plano de redução, supervisão e gestão do risco - RSGR Como fazer bem? – O risco deve ser analisado e gerido a partir dos 4 ‘P’s: 4 pessoal, produto, processo e projecto Risco do SW - aspectos importantes Incerteza: o facto que caracteriza o risco pode não acontecer – 5 Não há riscos com 100% de probabilidade de ocorrência Perda: Se o risco se converter em realidade – Implicará consequências não desejadas ou perdas Categorias de Risco 6 Projecto: ameaças ao plano do projecto. Técnico: ameaças à qualidade e o planeamento temporal do software Negócio: ameaças à viabilidade do software Conhecidos: após avaliações do plano, condições técnicas e comerciais Previsíveis: extrapolados de experiências anteriores Imprevisíveis: difíceis de prever com antecedência Identificação do Risco 7 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 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: 8 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 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 9 Negócio Comum Especial X Equipamento não disponível Requisitos incompletos Técnico X X Uso de metodologias especiais X X Problemas na busca da confiabilidade requerida X X Retenção de pessoas chave X X Sub-estimativa do esforço X X Desistência do único cliente potencial X X Avaliação Global do Risco - também adicionar ao item 3.1 1. 2. 3. 4. 5. 6. 10 Os Gestores de Software e clientes dão suporte ao projecto? Os Clientes estão entusiasmados com o projecto e o produto? Os Engenheros de Software e os clientes compreenderam bem os requisitos? Os Clientes estiveram envolvidos na definição dos requisitos? As expectativas dos utilizadores são realistas? O âmbito do projecto é estável? 7. 8. 9. 10. 11. Os Engenheros de Software têm as competências requeridas? Os requisitos do projecto são estáveis? A Equipa de Desenvolvimento tem experiência na tecnologia a implementar? É adequado o número de pessoas da equipa de trabalho? Concordam os Clientes/utilizadores quanto à importância do projecto? e nos requisitos do sistema ou produto a construir? 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. 2. 3. 4. 12 Estabelecimento de uma escala para reflectir probabilidade percebida do risco Definição das consequências do risco Estimação do impacto do risco no projecto e no produto Apontar exactidão geral da estimação Tabela de Risco - Exemplo-modelo para o item 3.2 do Plano de Projecto Risco 13 Categoria Prob. Impacto 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 RSGR Redução do Risco Risco identificado: “rotação de pessoal” Plano de redução: – – – – – 14 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 Supervisão do Risco - Risco identificado: “rotação de pessoal” Factores a supervisionar – – – – – 15 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 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: 16 Evitar o risco Supervisionar o risco Gerir o risco e planos de contingência RSGR - Redução, Supervisão e Gestão do Risco outro exemplo de risco identificado: – – usar este modelo para o item 3.3 do Plano de Projecto da Lacertae SW descrever as actividades de RSGR somente para 2 ou 3 dos riscos identificados Risco: 1-010-77 Prob: 10% Impacto: muito alto Descrição: hardware especializado pode não estar disponível Estrategia de redução: Acelerar desenvolvimento de HW, construir simulador Plano de contigência: ter desenvolvimento externo de hardware como backup, implantar sistemas num simulador Pessoa responsável: Fred Jones (criação 1-01-01) Status: Simulação completada 10-02-01 17