Análise dos Riscos - Engenharia de software
1 Análise dos Riscos
1.1 Identificação dos Riscos
1.2 Projeção dos Riscos
1.4 Gerenciamento e monitoração 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.
1 - Análise dos Riscos
Quando o risco é considerado no contexto da engenharia de software, os três pilares conceituais que sempre estarão em evidência serão: o futuro, a mudança e a escolha. O futuro pelo fato de quais riscos poderiam fazer com que o projeto de software não saísse como planejado? A mudança , como as mudanças nos requisitos do cliente, nas tecnologias de desenvolvimento, nos computadores de destino e em todas as demais entidades ligadas ao projeto afetarão o sucesso global e o cumprimento do cronograma? E a escolha, qual o método e ferramentas devemos usar, quantas pessoas devem ser envolvidas, quanta ênfase sobre a qualidade é suficiente?
A análise dos riscos é, de fatos, uma série de passos de administração de riscos que nos possibilita atacar o risco, que tem como função quatro atividades distintas: identificação dos riscos, projeção do riscos, avaliação dos riscos, gerenciamento e monitoração dos riscos.
1.1 - Identificação dos Riscos
Antes que possamos identificar os "riscos certos" a serem assumidos durante um projeto de software, é importante identificar todos os riscos que sejam óbvios tanto aos gerentes como aos profissionais.
É possível dividir os riscos em categorias de muitas maneiras diferentes. Em nível macroscópico, podem ser definidos os riscos de projeto, riscos técnicos e riscos de negócio. Os riscos de projeto identificam problemas orçamentários, de cronograma, de pessoal (composição do pessoal e organização), de recursos, de clientes e de requisitos, e o impacto dos mesmos sobre o projeto do software.Os riscos técnicos identificam potenciais problemas de projeto, implementação, interface, verificação e manutenção. Além disso, a ambigüidade de especificação, incerteza técnica, obsolescência técnica e tecnologia "de ponta" também são fatores de riscos. Os riscos técnicos ocorrem porque um problema é mais difícil de ser resolvido do que imaginávamos. Os riscos de negócio são insidiosos, porque podem distribuir os resultados até mesmo dos melhores projetos de software. Entre os candidatos aos cinco riscos de negócio de maior destaque encontram-se:
construir um excelente produto que ninguém realmente quer (risco de mercado);
construir um produto que não mais se encaixe na estratégia global de produtos da empresa;
construir um produto que a equipe de vendas não sabe como vender;
perder o apoio da alta administração devido à mudança de enfoque ou mudança de pessoas (risco administrativo);
perder o compromisso orçamentário ou de pessoal (risco orçamentário).
É extremamente importante observar que a simples divisão em categorias nem sempre funcionará. Alguns riscos são simplesmente impossíveis de ser prognosticados antecipadamente.
A identificação dos riscos envolve a relação dos riscos específicos de projeto dentro das amplas categorias acima esboçadas. Um dos melhores métodos para se entender cada um dos riscos é usar um conjunto de perguntas que ajude o planejador do projeto a compreender os riscos em termos técnicos ou de projeto. O uso de um "checklist de itens de riscos" – um conjunto de 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;
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.
A Figura 2, representa essa situação graficamente. Se uma combinação de riscos levar a problemas que façam com que o custo ou os prazos sejam ultrapassados, haverá um nível, representado pela curva da figura, que (ao ser ultrapassado) provocará o encerramento do projeto (a região mais escura). No break point, as decisões de prosseguir ou encerrar o projeto têm igual peso.
Figura 2 – Nível de risco referente
Na realidade, o break point raramente poderá ser representado como uma linha uniforme sobre um gráfico. Na maioria dos casos, ele é uma região em que há áreas de incerteza, isto é, tentar prever uma decisão administrativa baseando-se na combinação dos valores referentes muitas vezes é impossível.
Portanto, durante a avaliação dos riscos, efetuamos as seguintes etapas:
Definimos os níveis de risco referentes para o projeto;
Tentamos desenvolver um relacionamento entre cada [Ri, Li, Xi] e cada um dos níveis referentes
Prevemos o conjunto de pontos referentes que define uma região de encerramento, delimitados por uma curva ou área de incerteza; e
Tentamos prever como associações combinadas dos riscos afetarão um nível referente.
1.4 - Gerenciamento e Monitoração dos Riscos
A atividade de gerenciamento e monitoração dos riscos é ilustrada esquematicamente na Figura 3. O trio (descrição, probabilidade e impacto dos riscos) associado a cada risco é usado como uma base a partir da qual os passos de gerenciamento dos riscos (ou aversão sos riscos) são desenvolvidos. Por exemplo, suponhamos que a alta rotatividade de pessoal seja observada como um risco ao projeto, r1. Baseando-se na história passada e na intuição administrativa, a probabilidade, l1, de elevada rotatividade de pessoal é estimada como sendo de 0,70 (70%, bastante elevada) e o impacto, x1, é projetado para aumentar a duração do projeto em 15% e o custo global em 12%. Colocados esses dados, os seguintes passos de administração dos risco são propostos:
Reunir-se com o pessoal atual para determinar as causas da rotatividade de pessoal (por exemplo, condições de trabalho ruins, salários baixos, mercado de trabalho competitivo).
Tomar providências para mitigar aquelas causas que estejam sob nosso controle antes que o projeto se inicie.
Assim que o projeto se iniciar, pressupor que haverá rotatividade de pessoal e desenvolver técnicas para garantir a continuidade quando as pessoas saírem.
Organizar equipes de projeto de forma que as informações a respeito de cada atividade sejam amplamente difundidas.
Definir padrões de documentação e estabelecer mecanismos para se certificar de que os documentos sejam desenvolvidos de maneira oportuna.
Realizar revisões de todo o trabalho com os colegas de forma que mais de uma pessoa esteja a par das atividades desenvolvidas.
Definir um membro do pessoal que sirva de backup para cada profissional mais crítico.
É 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:
Escopo e propósito do documento.
Prioridades para evitar os riscos.
Descrições de trabalho.
Descrição do programa para evitar os riscos.
Marcos de referência e revisões importantes.
Exame dos riscos.
Finte de riscos
Taxonomia dos riscos.
Estimativa dos riscos.
Estimar a probabilidade dos riscos.
Estimar a conseqüência dos riscos.
Critérios de estimativa.
Possíveis fontes de erros de estimativa.
Métodos de avaliação a serem usados.
Pressuposições e limitações do método de avaliação.
Riscos referentes da avaliação.
Administração dos riscos.
Opções para evitar os riscos.
Recomendações para evitar os riscos.
Procedimentos de monitoração dos riscos.
Estimativa dos riscos da situação.
Plano de redução dos riscos.
De fato a análise dos riscos é fundamental na resolução de um projeto de software. Um bom projeto deve ser analisado, preocupando-se com acontecimentos futuros. Por isso é necessário uma estratégia para atacar o problema, estabelecendo um mecanismo para avaliar a construção do produto usando quatro atividades (identificação dos riscos, projeção dos riscos, avaliação dos riscos e administração dos riscos), podemos eliminar os riscos.
Com essas atividades, diminuímos os riscos que podem prejudicar os projetos de software. Tendo assim maior poder de gerenciar o desenvolvimento e garantir um produto final de qualidade.