Análise e Gestão do Risco

Apresentação em tema: "Análise e Gestão do Risco"— Transcrição da apresentação:

1 Análise e Gestão do Risco
Aula 12

2 Sumário Introdução Riscos do software
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

3 Introdução (I) O quê é? Quem faz?
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

4 Introdução (II) Porquê é importante? Qual o produto? Como fazer bem?
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 - RSGR Como fazer bem? O risco deve ser analisado e gerido a partir dos 4 ‘P’s: pessoal, produto, processo e projecto

5 Risco do SW - aspectos importantes
Incerteza: o facto que caracteriza o risco pode não acontecer 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

6 Categorias de Risco 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 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

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

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 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

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 Uso de metodologias especiais Problemas na busca da confiabilidade requerida Retenção de pessoas chave Sub-estimativa do esforço Desistência do único cliente potencial 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

10 Avaliação Global do Risco - também adicionar ao item 3.1
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? 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? 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

11 Componentes e Impacto do Risco
Componentes do Risco elaborados pela FAA (Fed Aviation Administration, USA) Performance Custo Suporte Planeamento temporal para cada componente o Impacto pode ser: Catastrófico Crítico Marginal Desprezável 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)

12 Estimação do Risco Medição do risco em termos da sua probabilidade de ocorrência e das suas consequências Tarefas a cumprir: 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

13 Tabela de Risco - Exemplo-modelo para o item 3.2 do Plano de Projecto
Categoria Prob. Impacto RSGR Baixa estimação do tamanho Tamanho 60% Crítico Mais utilizadores que os previstos 30% Marginal Menos reutilização que a prevista 70% Resistência dos utilizadores Negócio 40% Data de entrega muito ajustada 50% Perda dos orçamentos Catastróf. Mudança nos requisitos Cliente 80% Expectativas não satisfeitas Falta de formação nas ferramentas Pessoal Falta de experiência do pessoal Alta rotação de pessoal 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.

14 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

15 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

16 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 Gerir o risco e planos de contingência

17 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: 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 ) Status: Simulação completada