Baixe Análise dos Riscos e outras Notas de estudo em PDF para Informática, somente na Docsity!
ÍNDICE
Introdução ............................................................................... 03
1 Análise dos Riscos ............................................................................... 04
1.1 Identificação dos Riscos
1.2 Projeção dos Riscos
1.3 Avaliação dos Riscos
1.4 Gerenciamento e monitoração dos Riscos
Conclusão ............................................................................... 11
Bibliografia ............................................................................... 12
INTRODUÇÃO
Análise dos Riscos
Sempre que um programa de computador for construído haverá áreas de incerteza. As necessidades do computador são de fato atendidas? As funções que devem ser implementadas podem ser antes do prazo final do projeto? Surgirão problemas técnicos difíceis que atualmente estão de nossa visão? As mudanças que invariavelmente ocorrem durante qualquer projeto farão com que a programação se desvie muito do curso? Essas são algumas questões pela qual surgiu a análise de riscos. A análise dos riscos é crucial para um bom gerenciamento de projeto de software e, contudo, muitos projetos são levados a efeito sem nenhuma consideração específica dos riscos. Onde tem como uma das principais características a preocupação com acontecimentos futuros o qual você nunca saberá o que vai acontecer com determinado projeto.
perguntas que seja pertinente a cada fator de risco. Por exemplo, o planejador poderia atingir uma compreensão dos riscos de composição do pessoal ao responder às seguintes perguntas:
- São as melhores pessoas disponíveis?
- As pessoas têm a combinação certa de habilidades?
- Há pessoas suficientes à disposição?
- O pessoal está comprometido com toda a duração do projeto?
- Algum membro do pessoal do projeto estará trabalhando somente em tempo parcial nesse projeto?
- O pessoal tem as expectativas certas sobre o trabalho que tem à mão?
- Os membros do pessoal receberam o treinamento necessários?
- A rotatividade entre os membros do pessoal será baixa o bastante para permitir continuidade? A certeza relativa das respostas a essas perguntas permitirá que o planejador estime o impacto dos riscos na composição da equipe.
1.2 - Projeção dos Riscos
A projeção dos riscos, também chamada estimativa dos riscos, tenta classificar cada risco de duas maneiras – a probabilidade de que o risco seja real e as conseqüências dos problemas associados ao risco, caso ele ocorra. O planejador do projeto, juntamente com outros gerentes e o pessoal técnico, executa quatro atividades de projeção dos riscos:
- estabelecimento de uma escala que reflita a probabilidade percebida de ocorrência de um risco;
- delineamento das conseqüências do risco;
- estimativa do impacto do risco sobre o projeto e o produto;
- anotação da precisão global da projeção dos riscos de forma que não haja mal-entendidos. Uma escala pode ser definida em termos booleanos, qualitativos ou quantitativos. Ao extremo, cada pergunta da lista de conferência (checklist) de itens de riscos poderia ser respondida com um “sim” ou “não”, mas isso é altamente irrealístico. Raramente é possível avaliar-se aos riscos em termos absolutos. Uma abordagem melhor poderia ser a de dar uma resposta de acordo com uma escala de probabilidades qualitativa que tivesse os seguintes valores:
- altamente improvável;
- improvável;
- moderado;
- provável;
- altamente provável. Alternativamente, o planejador poderia calcular a probabilidade , matemática de que o risco venha a ocorrer (por exemplo, uma probabilidade de 0,90 implica um risco altamente provável). Probabilidades numéricas podem ser estimadas usando-se a análise estatística das métricas compiladas de experiências passadas, da intuição e de outras informações. Por exemplo, se as medidas compiladas de 45 projetos indicam que 37 projetos experimentaram o dobro de mudanças feitas pelo cliente do que as originalmente previstas, a
probabilidade de que um novo projeto experimente números de mudança excessivos é de 37/45=0,82, muito provavelmente. Finalmente, os riscos são ponderados em função do possível impacto percebido (sobre o projeto) e depois colocados em ordem de prioridade. Três fatores afetam o impacto: sua natureza, seu escopo e seu tempo de ocorrência. A natureza do risco indica os problemas prováveis se ele ocorrer. Por exemplo, uma interface externa com o hardware do cliente mal definida (um risco técnico) frustrará a realização do projeto e dos testes e provavelmente levará a problemas na integração do sistema posteriormente. O escopo de um risco combina a gravidade (quão sério ele é?) com sua distribuição global (quanto do projeto será afetado ou quantos clientes serão prejudicados?). E o tempo de ocorrência de um risco considera quando e por quanto tempo o impacto será sentido. Na maioria dos casos, o gerente de projetos talvez queira que as “más notícias” cheguem tão logo seja possível, mas, em alguns casos, quanto mais tempo elas se atrasarem, melhor.
Consultando a Figura 1, observamos que o impacto e a probabilidade de riscos exercem uma pressão diferente sobre a preocupação gerencial. Um fator de risco que tenha um peso de elevado impacto, mas uma probabilidade de ocorrência muita baixa, não observará uma significativa quantidade de tempo gerencial. Porém, os riscos de elevado impacto com probabilidade de ocorrência variando de moderada a alta e os riscos de baixo impacto com probabilidade elevada devem ser transportados para as etapas de análise dos riscos que se seguem. Figura 1 – Risco e preocupação gerencial.
1.3 - Avaliação dos Riscos
A essa altura do processo de análise dos riscos, estabelecemos um conjunto de termos que tem a forma: ri - é o risco li - é a probabilidade do risco xi - é o impacto do risco Durante a avaliação dos riscos, examinaremos mais detalhadamente a precisão das estimativas que foram feitas durante a projeção dos riscos, tentaremos determinar uma ordem de prioridade para os riscos que foram descobertos e começaremos a pensar em maneiras de controlar e/ou evitar riscos que têm a probabilidade de ocorrer. Afim de que a avaliação seja útil, um nível de risco referente deve ser definido. Para a maioria dos projetos de software, o custo, os prazos e o desempenho representam três níveis de risco típicos. Ou seja, há um nível para o excesso de custos, para o descumprimento do cronograma ou para a degradação do desempenho (ou qualquer combinação dos três) que fará com que o projeto seja encerrado. Se uma combinação de riscos criar problemas que façam com que um ou mais desses níveis referentes sejam ultrapassados, o trabalho encerrar-se-á. No contexto da análise de riscos de software um nível de risco referente tem um ponto simples, denominado ponto referente ou Break Point, em que as decisões de continuar o projeto ou encerra-lo (os problemas são grandes demais) são igualmente aceitáveis.
É importante observar que esses passos de administração dos riscos acarretam custos de projeto adicionais. Por exemplo, o tempo gasto para prover o backup para cada profissional crítico custa dinheiro. Parte da administração dos riscos, portanto, significa avaliar quando os benefícios advindos das atividades tomadas para evitá-los são ultrapassados pelos custos associados à implementação dos mesmos. Essencialmente, o planejador de projetos executa uma análise de custo-benefício clássica. Se as providências para evitar os riscos da alta rotatividade de pessoal aumentarem o custo e a duração do projeto em 15%, e o fator de custo predominante for o backup, a administração poderá decidir não implementar esse passo. Por outro lado, se os passos de administração dos riscos forem projetados para aumentar os custos em 5% e a duração em apenas 3%, a administração provavelmente os colocará em prática.
Figura 3 – Gerenciamento e monitoração dos riscos
Para um grande projeto, 30 ou 40 riscos podem ser identificados. Se entre três sete passos de administração de riscos forem identificadas para cada um, a administração dos riscos pode tornar-se um projeto em si mesma! Por essa razão, adaptamos a regra 80/20 de Pareto aos riscos do software. A experiência indica 80% dos riscos globais do projeto (isto é, 80% do potencial de fracasso do projeto) podem ser correspondentes a apenas 20% dos riscos identificados. O trabalho executado durante os primeiros passos da análise dos riscos ajudará o planejador a determinar quais dos riscos residem nesses 20%. Por essa razão, alguns dos riscos identificados, avaliados e projetados podem não se encaixar no plano de administração dos riscos – eles não compreendem os 20% críticos (os riscos com prioridade mais alta no projeto). Consultando novamente a Figura 3, observa-se que os passos de administração dos riscos estão organizados num Plano de Administração e Monitoração do Riscos (PAMR). O PAMR documenta todo o trabalho executado como parte da análise de riscos e é usado pelo gerente de projetos como parte do Plano de Projeto global. Assim que o PAMR tiver sido desenvolvido e o projeto iniciado, começa a monitoração dos riscos. A monitoração dos riscos é uma atividade de rastreamento dos projeto com três objetivos primordiais:
- (^) Avaliar se um risco previsto, de fato, ocorre;
- Garantir que os passos de reversão definidos para o risco estejam sendo adequadamente aplicados;
- Coletar informações que possam ser usadas em análises de riscos futuras. Em muitos casos, os problemas que ocorrem durante um projeto podem relacionar-se a muitos riscos. Outra tarefa da monitoração dos riscos é tentar atribuir “culpa” [qual risco causou (ou quais riscos causaram) problemas] ao longo do projeto.
Esboço do plano de administração e monitoração dos riscos: I. Introdução. I..1 Escopo e propósito do documento. I..2 Visão geral. I..2..a (^) Objetivos. I..2..b Prioridades para evitar os riscos. I..3 Organização.
I..3..a Administração. I..3..b Responsabilidades. I..3..c Descrições de trabalho. I..4 Descrição do programa para evitar os riscos. I..4..a Cronograma. I..4..b Marcos de referência e revisões importantes. I..4..c Orçamento. II. (^) Análise dos riscos. II..1 Identificação. II..1..a Exame dos riscos. II..1..a.()i Finte de riscos II..1..b Taxonomia dos riscos. II..2 Estimativa dos riscos. II..2..a Estimar a probabilidade dos riscos. II..2..b Estimar a conseqüência dos riscos. II..2..c Critérios de estimativa. II..2..d Possíveis fontes de erros de estimativa. II..3 Avaliação. II..3..a Métodos de avaliação a serem usados. II..3..b Pressuposições e limitações do método de avaliação. II..3..c Riscos referentes da avaliação. III. Administração dos riscos. III..1 Recomendações. III..2 Opções para evitar os riscos. III..3 Recomendações para evitar os riscos. III..4 Procedimentos de monitoração dos riscos. IV. (^) Apêndices. IV..1 Estimativa dos riscos da situação. IV..2 Plano de redução dos riscos.
BIBLIOGAFIA
PRESSMAN, Roger S. – “ Engenharia de Software ” - Makron Books do Brasil Editora Ltda
