Análise e Projeto de Sistemas Setembrino Soares Ferreira Jr. 01a – Gestão de riscos

20/05/201020/05/2010 01a - Gestão de riscos01a - Gestão de riscos 11

Universidade Federal do ParanáUniversidade Federal do Paraná Setor de Ciências Exatas Setor de Ciências Exatas

Departamento de InformáticaDepartamento de Informática

ESPECIALIZAÇÃO EM INFORMÁTICAESPECIALIZAÇÃO EM INFORMÁTICA

Análise e Projeto de Análise e Projeto de SistemasSistemas

Setembrino Soares Ferreira Jr.Setembrino Soares Ferreira Jr.

01a – Gestão de riscos01a – Gestão de riscos


Conteúdos0. Riscos1. Tipologias de riscos2. Gestão de riscos3. Análise de riscos4. Planejamento de respostas a riscos4.1. Entradas4.2. Ferramentas e Técnicas4.3. Saídas


Conteúdos (cont.)5. Atenuação, monitoração e administração de riscos5.1. RMMM – Risks Mitigation, Monitoring and Management5.2. Plano RMMM

6. Tabela de riscos7. Exposição aos riscos8. Ferramentas de gestão de riscos9. ExercíciosReferências


0. Riscos

Termo geral para designar “Oportunidades e / ou ameaças em potencial” “+” oportunidades / “-” ameaças Podem ocorrer ou não, ou seja, sempre estão associados a certos elementos, a saber:

Incerteza: probabilidade de ocorrência ou não Ganho ou perda: valor das conseqüências de sua ocorrência

Ganho: valor de uma oportunidade Perda: valor de uma ameaça


0. Riscos (cont.)

Exemplos: Riscos (negativos)

atrasos, custos acima do previsto, produto inadequado ao cliente, desempenho aquém do esperado, ...

Oportunidades (ou riscos positivos) interesses de novos clientes no mesmo produto, antecipações de prazos de entrega, custos abaixo do previsto, desempenho acima do esperado, ...


1. Tipologias de riscos

Tipos de riscos de projetos de software

Riscos de Projeto Riscos Técnicos Riscos de Negócio


1. Tipologias de riscos (cont.)

Riscos de Projeto Ameaçam o plano do projeto Quando ocorrem, é provável que o cronograma do projeto atrase e que os custos aumentem Identificam problemas em potencial e possíveis impactos em

Orçamento Cronograma Pessoal (quantidade e organização) Recursos Interessados Requisitos



Riscos Técnicos Ameaçam a qualidade do software Quando ocorrem, podem tornar a implementação difícil ou impossível Identificam problemas em potencial e possíveis impactos em

Projeto Implementação Interface Verificação Manutenção



Riscos de Negócio Ameaçam a viabilidade do software a ser construído Normalmente comprometem o projeto ou o produto Principais

Risco de mercado: construir um produto que ninguém quer usar Risco estratégico: construir um produto que não se encaixa na estratégia geral da empresa Risco de vendas: construir um produto que a equipe de vendas não sabe vender Risco gerencial: perda de apoio da gerência superior por causa de modificação de enfoque ou de pessoal Risco de orçamento: perda de comprometimento orçamentário ou de pessoa



Outra tipologia de riscos Riscos conhecidos

Podem ser descobertos após uma avaliação cuidadosa do plano de projeto e do ambiente técnico e comercial

Riscos previsíveis São extrapolados de experiências de projetos anteriores

Riscos imprevisíveis Extremamente difíceis de identificar previamente



E... Outra tipologia de riscos: componentes / fatores de risco

Riscos de desempenho Riscos do produto não atender aos requisitos

Riscos de custo Riscos do orçamento não ser mantido

Riscos de suporte Riscos do software não ser fácil de corrigir, adaptar e aperfeiçoar

Riscos de cronograma Riscos de não serem cumpridos prazos



E... Mais outra tipologia: categorias de riscos – usada para agrupar riscos

Tamanho do produto Impacto do negócio Características do cliente Definição do processo Ambiente de desenvolvimento Tecnologia para a construção Tamanho da equipe Experiência da equipe


2. Gestão de riscos

Compreende (visão simplista) Identificação dos riscos Determinação da probabilidade de sua ocorrência Estimativa de seus impactos Estabelecimento de um plano de contingência


2. Gestão de riscos (cont.) Identificação de riscos

Tentativa sistemática de especificar os riscos conhecidos e previsíveis Considera tanto os riscos genéricos como os riscos específicos do produto (geralmente são os mais problemáticos) Método: criação de checklist de itens de risco, associados às características

Tamanho do produto, impacto no negócio, características do cliente, definição do processo, ambiente de desenvolvimento, tecnologia para a construção, tamanho e experiência da equipe


2. Gestão de riscos (cont.) Checklist alternativo - Risco global de um projeto

A alta administração do software e do cliente empenhou-se formalmente em apoiar o projeto? Os usuários finais estão entusiasmados? Os requisitos estão plenamente entendidos? Os clientes envolveram-se na definição dos requisitos? O escopo do projeto é estável? Os usuários finais têm expectativas realísticas? A equipe tem as aptidões adequadas? Os requisitos são estáveis? A equipe tem experiência com a tecnologia? A quantidade de pessoal é adequada? Todos os membros da equipe do cliente / usuário concordam em relação à importância do projeto?


2. Gestão de riscos (cont.)

Determinação da probabilidade de ocorrência de riscos

Responsabilidade Planejador do projeto, gerentes envolvidos e a equipe

Atividades Estabelecer escala que reflita a probabilidade percebida de um risco Delinear as conseqüências do risco Estimar o impacto do risco no projeto e no produto Anotar a precisão da previsão de riscoObs.: A probabilidade do risco pode ser determinada a partir de estimativas individuais e depois ser consensada



Estimativa do impacto de riscos Considera as conseqüências dos riscos em relação a cronograma, custo, suporte e desempenho Categorias

Catastrófico (4) Crítico (3) Marginal (2) Negligenciável (1)



Estimativa do impacto de riscos – fatores a considerar

Natureza: tipos de problemas que surgem Ex.: incompatibilidade com o hardware do cliente pode atrasar o início dos testes

Escopo: combina a severidade com sua distribuição geral

Quanto do projeto será afetado ou quantos clientes serão prejudicados?

Época Quando ou por quanto tempo seu impacto será sentido?



Visão mais ampla Parte da disciplina: Análise de Riscos

Qualitativa Quantitativa Medidas de tratamento

Planejamento de respostas Monitoramento de controle

Valor da informação e dos recursos Padrões e normas


3. Análise de riscos

Objetivo Auxiliar equipes no desenvolvimento de estratégias para lidar com riscos

Estratégias Reativas Pró-ativas


3. Análise de riscos (cont.)

Estratégias reativas Conhecidas como “apagar incêndios” Recursos são para lidar com os riscos quando se tornarem problemas Nada é feito enquanto os problemas não se tornam reais

Estratégias pró-ativas Atividades voltadas a riscos começam antes do trabalho técnico ser iniciado Riscos são identificados, suas probabilidades e impactos são avaliados e eles são classificados por importância Equipe de software estabelece um plano para administrar os riscos

Objetivo principal: evitar riscos É criado um plano de contingência


3. Análise de riscos (cont.)

Previsão de riscos Planejamento de gestão ... -> Plano de gestão Identificação dos riscos ... -> Registro dos riscos (RR) Análise qualitativa ... -> Atualização dos RR Análise quantitativa ... -> Atualização dos RR Planejamento de respostas a riscos ... -> Acordos contratuais / revisão do plano de gestão Monitoramento e controle


4. Planejamento de respostas a riscos

Finalidade Aumentar oportunidades ... Reduzir ameaças ... ... aos objetivos dos projetos

Meios Desenvolvimento de opções Determinação de ações


4. Planejamento de respostas a riscos (cont.)

Identificar “proprietário(s) das respostas”

Uma ou mais pessoas Responsáveis sobre cada resposta a riscos

Abordar os riscos de acordo com sua importância Inserir recursos e atividades

Orçamento Cronograma Plano de gerenciamento


4. Planejamento de respostas a riscos (cont.)

Respostas planejadas Adequadas à importância Econômicas Rápidas Realistas Acordadas por todos De propriedade de alguém

Obs.: é comum a melhor resposta ser selecionada de uma lista de opções.


4.1. Entradas

Plano de gestão Funções e responsabilidades Definições da análise de riscos Limites para caracterizar riscos baixos, moderados e altos Cronograma e orçamento


4.1. Entradas (cont.)

RR Riscos identificados Causas-raiz de riscos Listas de respostas possíveis Proprietários dos riscos Sintomas / sinais de alerta para o desenvolvimento de respostas a riscos


4.1. Entradas (cont.)

Elementos essenciais classificação relativa ou lista de prioridade de riscos do projeto lista de riscos que exigem resposta a curto prazo lista de riscos para análise e resposta adicionais tendências dos resultados da análise qualitativa de riscos causas-raiz riscos agrupados por categoria lista de observação de riscos de baixa prioridade


4.2. Ferramentas e técnicas

Várias estratégias de respostas a riscos disponíveis Para cada risco (ou ... ou ... ou ainda ...)

Seleção de uma estratégia Associação de estratégias com maior probabilidade de sucesso Plano alternativo (quando probabilidade de sucesso baixa)

Árvores de decisão -> ações para implementar estratégias

Principais De reserva

Reservas de contingência Prazo Custo


4.2. Ferramentas e técnicas (cont.)

Estratégias para riscos negativos ou ameaças

Prevenir Transferir Mitigar




Prevenir Mudar o plano de gestão para (Ou ... Ou ... Ou ainda) Eliminar a ameaça apresentada por um risco adverso Isolar os objetivos (do projeto) do impacto do risco Flexibilizar o objetivo ameaçado (extensão do cronograma; redução do escopo; ...) Ações preventivas: esclarecimento de requisitos, obtenção de informações, melhoria da comunicação, aquisição de especialização, ...



Estratégias para riscos negativos ou ameaças Transferir

Passagem do impacto negativo de uma ameaça para terceiros, juntamente com a propriedade da resposta Não elimina os riscos Transferência da responsabilidade mais eficaz quando relacionada à exposição a riscos financeiros Quase sempre envolve o pagamento de um prêmio de risco à parte que o assume Ferramentas de transferência: seguros, seguros desempenho, garantias, contratos(*), ...

(*) contrato com base no custo pode transferir risco de custo para o comprador; contrato de preço fixo pode transferir o risco para o fornecedor, caso o design do projeto esteja estável




Mitigar Exige a redução da probabilidade e / ou impacto de um evento de risco adverso até um limite aceitável Realizar ações no início para reduzir a probabilidade e / ou o impacto de um risco que está ocorrendo é freqüentemente mais eficaz do que a tentativa de reparar os danos após a ocorrência do risco Ações de mitigação: adoção de processos menos complexos, realização de mais testes, escolha de um fornecedor mais estável, ...




Mitigar Pode exigir a elaboração de protótipos para reduzir o risco decorrente do incremento de escala a partir de um modelo de bancada, para um dado processo ou produto Quando não for possível reduzir a probabilidade, uma resposta de mitigação poderá abordar o impacto do risco se concentrando nas ligações que determinam a gravidade Exemplo: projeto de redundância em um subsistema pode reduzir o impacto de uma falha do componente original



Estratégias para riscos positivos ou oportunidades

Explorar Compartilhar Melhorar




Explorar Estratégia pode ser selecionada para riscos com impactos positivos nos pontos em que a organização deseja garantir que a oportunidade seja concretizada Estratégia tenta eliminar a incerteza associada a um risco positivo específico, fazendo com que a oportunidade definitivamente aconteça Ações exploratórias: designação de recursos mais capacitados - pode reduzir o tempo de conclusão do projeto ou incorporar qualidade maior do que a originalmente planejada




Compartilhar Envolve a atribuição da propriedade a terceiros que possam capturar melhor a oportunidade (em benefício do projeto) Ações de compartilhamento: formação de parcerias, equipes, empresas de propósito específico ou joint ventures para compartilhamento de riscos




Melhorar Objetiva modificar o “tamanho” de uma oportunidade Meios: aumento da probabilidade e / ou dos impactos positivos; identificação e maximização dos principais acionadores de riscos de impacto positivo Ações de melhoria: procurar facilitar ou fortalecer a causa da oportunidade e direcionar e reforçar de forma pró-ativa suas condições de acionamento podem aumentar a probabilidade de um impacto positivo



Estratégia para ameaças e oportunidades

Aceitação Estratégia adotada por ser raramente possível eliminar todos os riscos Estratégia indica que a equipe decidiu não mudar o plano de gerenciamento para tratar um risco ou que não consegue identificar qualquer outra estratégia de resposta adequada Serve tanto para ameaças como para oportunidades



Estratégia para ameaças e oportunidades

Aceitação Estratégia pode ser passiva ou ativa Aceitação passiva:

Não exige nenhuma ação Equipe trata as ameaças ou oportunidades conforme ocorrem

Estratégia de aceitação ativa mais comum: Estabelecer uma reserva para contingências, incluindo as quantidades de tempo, dinheiro ou recursos para tratar as ameaças ou oportunidades conhecidas ou, algumas vezes, até potenciais desconhecidas



Estratégia para respostas contingenciadas Respostas projetadas para uso somente se determinados eventos ocorrerem Para alguns riscos, a equipe deve fazer um plano de respostas que será executado somente em certas condições predefinidas, se for considerado que haverá alerta suficiente para implementar o plano Eventos que provocam a resposta de contingência devem ser definidos e acompanhados. Exemplos:

Marcos intermediários não cumpridos Obtenção de prioridade mais alta de um fornecedor


4.3. Saídas

Atualização dos RR Respostas adequadas são escolhidas, acordadas e incluídas nos RR Riscos altos e moderados: abordagem detalhada Riscos de baixa prioridade: inclusão em "lista de observação" para monitoramento periódico


4.3. Saídas (cont.)

Atualização dos RR Dados dos RR

Riscos identificados, descrições, área(s) afetada(s), causas e como eles podem afetar os objetivos do projeto Proprietários dos riscos e responsabilidades designadas Lista priorizada de riscos Estratégias de resposta acordadas Ações específicas para implementar estratégias de resposta escolhidas



Atualização dos RR Dados dos RR (cont.)

Sintomas e sinais de alerta da ocorrência de cada risco Orçamento e atividades do cronograma necessários para implementar as respostas escolhidas Reservas para contingências dos custos e de tempo projetadas para fornecer as tolerâncias a risco das partes interessadas Planos de contingência e gatilhos que acionam sua execução



Atualização dos RR Dados dos RR (cont.)

Planos alternativos para serem usados como uma reação a um risco que ocorreu e cuja resposta principal foi inadequada Riscos residuais: espera-se que permaneçam após a realização das respostas planejadas, além dos que foram deliberadamente aceitos Riscos secundários: surgem como um resultado direto da implementação de uma resposta a riscos Reservas para contingências, calculadas com base na análise quantitativa dos limites de risco do projeto e da organização



Plano de gerenciamento do projeto (atualizações)

Atualizado conforme as atividades de resposta são adicionadas Estratégias de respostas a riscos, depois de acordadas, devem ser fornecidas como feedback aos processos adequados de outras áreas de conhecimento, inclusive ao orçamento e cronograma



Acordos contratuais relacionados a riscos

Contratos de seguros Serviços Outros itens, conforme adequado ...

... podem ser preparados para especificar a responsabilidade de cada uma das partes por riscos específicos, se eles ocorrerem


5. Atenuação, monitoração e administração de riscos

Estratégias efetivas para lidar com riscos devem procurar

Evitar riscos Monitorar riscos Gerenciar riscos e planejar para contingência

Evitar riscos Sempre a melhor estratégia Desenvolver plano para atenuação de riscos


5. Atenuação, monitoração e administração de riscos (cont.)

Evitar riscos Exemplo:

Alta rotatividade de pessoal é notada como um risco de certo projeto Com base em históricos e intuição, a probabilidade de alta rotatividade é estimada como sendo de 0,7 (70% - bastante alta) O impacto é previsto como crítico A alta rotatividade terá impacto crítico no custo e no cronograma do projeto



Evitar riscos Exemplo (cont.):

Para atenuar o risco, o gestor deve desenvolver uma estratégia para reduzir a rotatividade Dicas

Reunir a equipe para determinar as causas da rotatividade Atenuar as causas que puderem ser controladas antes de iniciar o projeto Iniciado o projeto, considerar que a rotatividade vai ocorrer Desenvolver técnicas para assegurar a continuidade quando as pessoas saírem (ferramentas de GC): organizar as equipes de modo que a informação sobre cada atividade seja amplamente difundida; definir padrões de documentação e mecanismos que assegurem que documentos sejam desenvolvidos em tempo



Evitar riscos Exemplo (cont.):

Dicas (cont.) Conduzir revisões de todo o trabalho por pares (para que mais de uma pessoa esteja “sabendo das coisas”) Designar um membro da equipe para dar cobertura a cada técnico essencial



Monitorar riscos À medida que o projeto avança, iniciam as atividades de monitoração de riscos O gerente de projetos deve monitorar fatores que podem indicar se um risco é mais ou menos provável



Monitorar riscos Caso de alta rotatividade de pessoal – fatores que podem ser monitorados

Atitude geral dos membros da equipe face às pressões normais de projeto Grau de união da equipe Relacionamento entre as pessoas da equipe Problemas em potencial com remuneração e benefícios Disponibilidade de emprego dentro e fora da organização



Gestão de riscos e planejamento de contingência

Considera que os esforços para atenuação falharam e que o(s) risco(s) tornou(aram)-se realidade Exemplo:

O projeto está bem avançado e algumas pessoas avisam que vão sair Se a estratégia de atenuação foi seguida, o apoio está disponível

Informações estão documentadas Conhecimento foi difundido por toda a equipe



Gestão de riscos e planejamento de contingência

Exemplo (cont): Gestor ainda pode realocar recursos temporariamente (e reajustar o cronograma do projeto) para aquelas funções que estão com todo o pessoal necessário (permite que os novatos sejam incorporados à equipe) Pessoas que estão saindo podem ser solicitadas a interromper todo o trabalho e passar suas últimas semanas envolvidas em “transferir conhecimento”

Captação de conhecimento baseada em vídeo Desenvolvimento de “documentos de comentário” Reuniões com outros membros da equipe que permanecerão no projeto


5.1. RMMM – Risks Mitigation, Monitoring and Management

Passos do RMMM implicam em custos adicionais ao projeto

Gastar tempo para “dar apoio” para cada técnico essencial custa dinheiro

Sugestão Analisar se os benefícios obtidos através do RMMM não são superados pelos custos associados com a sua implementação


5.1. RMMM – Risks Mitigation, Monitoring and Management (cont.)

Efetuar análise de custo x benefício clássica Exemplo

Se os passos para atenuação do risco de alta rotatividade aumentarem o custo e o prazo do projeto em um valor de 15% e o fator de custo predominante for “dar apoio”, a gerência pode optar por não implementar este passo Se os passos para atenuação de risco tiverem previsão de aumentar o custo em 5% e o prazo de execução em 3% do tempo, a gerência pode optar por colocá-los em ação


5.1. RMMM – Risks Mitigation, Monitoring and Management (cont.) Considerações importantes

Em projetos grandes, é comum identificar-se de 30 a 40 riscos Se de 3 a 7 passos de gestão de risco forem identificados para cada um, a gestão de risco pode tornar-se um projeto de si mesma! Adotar, se for o caso, a regra 80-20 de Pareto

A experiência indica que 80% das falhas reais dos projetos podem ser atribuídas a apenas 20% dos riscos identificados O trabalho realizado durante os primeiros passos de análise de risco pode ajudar o planejador a determinar quais dos riscos estão nestes 20%, ou seja, riscos que levam o projeto à maior exposição ao risco de insucesso Assim, alguns dos riscos identificados, avaliados e projetados podem não ir para o plano RMMM, por não se enquadrarem na faixa de 20% dos riscos críticos (riscos com mais alta probabilidade de ocorrência no projeto)


5.1. RMMM – Risks Mitigation, Monitoring and Management (cont.)

Riscos não se limitam a um único projeto e não se esgotam ao final do desenvolvimento Podem ocorrer depois que o produto / software tenha sido entregue Estes riscos são tipicamente associados com as conseqüências da falha do produto “em campo” Se imprevistos puderem ser identificados antecipadamente no projeto, eles podem ser eliminados ou controlados


5.2. Plano RMMM

Estratégias de administração de riscos podem ser incluídas nos planos de projeto

ou Os passos de gestão de risco podem ser organizados em um plano separado de atenuação, monitoração e gestão de riscos O plano RMMM documenta todo o trabalho realizado

Como parte da análise de riscoe

Pode ser usado como parte do plano geral do projeto


5.2. Plano RMMM (cont.)

Algumas equipes não desenvolvem um documento RMMM formal

Cada risco é documentado individualmente em um formulário de informação de risco (risk information sheet, RIS) O RIS pode ser mantido em um BD, de modo que a criação e a busca dos dados possa ser facilitada



Formulário de Informação de Riscos (exemplo) Identificação do Risco: XPTO 123 Data: 01/10/2007 Probabilidade: 80% Impacto: Alto Descrição: Apenas 70% dos componentes de software programados para reuso serão, de fato, integrados na aplicação. A funcionalidade restante terá que ser desenvolvida sob medida.



Formulário de Informação de Riscos (exemplo – cont.)

Refinamento / contexto Subcondição 1: certos componentes reusáveis foram desenvolvidos por terceiros sem conhecimento dos padrões internos de projeto Subcondição 2: o padrão de projeto para as interfaces de componentes não foi consolidado e pode não estar de acordo com alguns componentes reusáveis existentes Subcondição 3: certos componentes reusáveis foram implementados em uma linguagem que não está disponível no ambiente-alvo




Atenuação / monitoração1. Contrate terceiros para determinar que os padrões sejam seguidos2. Force a conclusão dos padrões de interface; considere a estrutura do componente3. Verifique a quantidade de componentes que está na categoria da subcondição 3




Administração / Plano de contingência / Disparo Exposição ao risco calculada em US$ 20.200. Reservar esta quantia para custo de contingência do projeto. Desenvolver cronograma revisado considerando que mais de 18 componentes terão que ser construídos sob medida; distribuir equipe de acordo com isso.

Disparo(s) 15/10/2007: passos de atenuação iniciados 01/11/2007: passos para atenuação improdutivos

Assinaturas

Fonte: Adaptado de Loss (2007)




Administração / Plano de contingência / Disparo Exposição ao risco calculada em US$ 20.200. Reservar esta quantia para custo de contingência do projeto. Desenvolver cronograma revisado considerando que mais de 18 componentes terão que ser construídos sob medida; distribuir equipe de acordo com isso.

Disparo(s) 15/10/2007: passos de atenuação iniciados 01/11/2007: passos para atenuação improdutivos (em observação)

Assinaturas

Fonte: Adaptado de Loss (2007)



Documentado o plano RMMM e iniciado o projeto, os passos de atenuação e monitoração têm início A atenuação do risco visa evitar problemas A monitoração é uma atividade de acompanhamento de projeto com três objetivos principais:

Avaliar se os riscos previstos de fato ocorrem Assegurar que os passos de atenuação de risco definidos estão sendo aplicados adequadamente Coletar informações que possam ser usadas para análises de risco futuras

Em muitos casos, os problemas que ocorrem durante um projeto podem ser atribuídos a mais de um risco Outro serviço da monitoração de riscos

Identificar as causas e conseqüências de riscos durante o projeto


6. Tabela de riscos

Planilha Risco Tipo Probabilidade Impacto Apontador para plano de contingência

Ordenação Probabilidade ImpactoRiscos com alta probabilidade e alto impacto aparecem antes dos outros


6. Tabela de riscos (cont.)

ExemploRiscos Categoria Prob.Impacto

Falta de treinamento Ambiente de desenvolvimento 80% 3Cl. modificará requisitos Tamanho do produto 80% 2Reuso menor que plan. Tamanho do produto 70% 2Alta rot. de pessoal Experiência da equipe 60% 2Estim. tamanho baixa Tamanho do produto 60% 2Prazo entrega apertado Impacto de negócio 50% 2Usuários resistentes Impacto de negócio 40% 3Financiamento perdido Características do cliente 40% 1... ... ... ...


6. Tabela de riscos (cont.)

Gerente deve examinar a tabela de riscos e estabelecer uma linha de corte

Apenas riscos acima da linha receberão atenção É preciso priorizar (Pareto: 80/20)

Impossível monitorar e controlar todos os riscos A tabela deve ser revista e atualizada ao longo do projeto

Novas circunstâncias podem causar modificações na probabilidade e no impacto dos riscos Novos riscos podem surgir e alguns podem desaparecer


7. Exposição aos riscos

Associar custos aos riscos Métrica de exposição aos riscos pode ser calculada:

ER = P × C P é a probabilidade de ocorrência do risco C é o custo para o projeto caso o risco ocorra

Métrica determina o custo esperado do risco A soma das ER pode ser usada para ajustar a estimativa final de custo de um projeto Também pode ser usada para prever o aumento provável de recursos


8. Ferramentas de gestão de riscos

Apóiam a identificação de riscos, fornecendo

Lista de riscos típicos de projeto e de negócio Checklists ou outras técnicas de “entrevista”

Apóiam a atribuição de probabilidades e impactos a cada risco Apóiam as estratégias de atenuação de riscos Geram relatórios relacionados a riscos Exemplos: Riskman, Risk Radar, RiskTrac, Risk+, X:PRIMER


9. Exercícios

Escolha, em consenso com sua equipe de trabalho, um projeto de software que ainda não iniciou.

1. Identifique os riscos do projeto.2. Elabore uma tabela de riscos do projeto.3. Agrupe os riscos identificados segundo a tipologia de componentes / fatores de risco apresentada.4. Proponha ações para evitar os riscos identificados.

Imagine, num segundo momento, ainda em consenso com sua equipe, que o projeto escolhido já iniciou e metade do tempo previsto no cronograma já transcorreu. Considere, ainda, que nenhuma ação proposta pela equipe foi aceita e nada foi realizado.

5. Liste os problemas que devem estar ocorrendo no andamento do projeto.


ReferênciasIC.UFF.BR Engenharia de Software. Universidade Federal Fluminense – Instituto de Computação – Disciplina Engenharia de Software II: Apresentação. Disponível em <http://www.ic.uff.br/~bianca/engsoft2/>. Acessado em 18 de maio de 2009.

LOSS, L. Análise de Riscos. SENAC – Pós-Graduação em Segurança da Informação: Apresentação. Disponível em <www.gsigma.ufsc.br/~loss/download/senac-pg/modulo7 .pdf>. Florianópolis: SENAC, 2007.

PRESSMAN, R. S. Engenharia de Software. 6. ed. São Paulo: McGraw Hill, 2006.

http://www.ic.uff.br/~bianca/engsoft2/

http://www.gsigma.ufsc.br/~loss/download/senac-pg/modulo7%20.pdf




Documents

Análise e Projeto de Sistemas Setembrino Soares Ferreira Jr. 01a – Gestão de riscos