Exemplo de cálculo de Exposição ao Risco Total (ERT)

Problema:

Utilizando a tabela de riscos apresentada na tabela, estabeleça uma linha de corte adotando o seguinte critério: riscos de primeira ordem terão probabilidade de ocorrência acima de 30% (a tabela deve ser ordenada para determinar a linha de corte). A seguir, verifique se o projeto é viável ou se novas análises devem ser realizadas, considerando que o Custo Total Estimado do projeto é de R$ 120.000,00 (120 mil reais).

Solução:

Uma vez que a tabela tenha sido ordenada e estabelecida a linha de corte, os riscos de primeira ordem são os listados na tabela, que traz os valores estimados de custo para o projeto dos riscos listados.

Riscos de primeira ordem

Riscos	Categoria	Probabilidade	Impacto	Custo para o projeto
Cliente modificará os requisitos	Tamanho do produto	80%	2	15000.00
Menos reúso que o planejado	Tamanho do produto	70%	2	12000.00
Estimativa de tamanho pode ser baixa	Tamanho do produto	60%	2	5000.00
Rotatividade alta	Tamanho e experiência da equipe	60%	2	10000.00
Prazo de entrega apertado	Impacto do negócio	50%	2	10000.00
Usuários finais resistem ao sistema	Impacto do negócio	40%	3	8000.00

Fonte: elaborado pelo autor.

A seguir, calculamos a Exposição ao Risco (ER) de cada fator de risco, de acordo com a tabela.

Cálculo da Exposição ao Risco – ER

Riscos	Probabilidade	Impacto	Custo para o projeto	Exposição ao Risco (ER)
Cliente modificará os requisitos	80%	2	15000.00	12000.00
Menos reúso que o planejado	70%	2	12000.00	8400.00
Estimativa de tamanho pode ser baixa	60%	2	5000.00	3000.00
Rotatividade alta	60%	2	10000.00	6000.00
Prazo de entrega apertado	50%	2	10000.00	5000.00
Usuários finais resistem ao sistema	40%	3	8000.00	3200.00
ERT (Exposição ao Risco Total) →				37600.00

Fonte: elaborado pelo autor.

Uma vez que o Custo Total Estimado do projeto é de R$ 120.000,00 notamos que a Exposição ao Risco Total está abaixo dos 50% estabelecidos como critério de viabilidade do projeto, ou seja, R$ 37.600,00 < 50% de R$ 120.000,00 = R$ 60.000,00. Assim, a princípio, em relação aos riscos avaliados, o projeto se mostra viável.

Avaliação do Impacto do Risco (Exposição ao Risco ou Risk Exposure)

A Exposição ao Risco (ER) ou Risk Exposure (RE) é determinada através da seguinte expressão:

ER = P * C

onde:

P = Probabilidade de ocorrência do risco

C = Custo para o projeto no caso de o risco ocorrer

A ER pode ser calculada para cada risco da tabela de riscos. A exposição total ao risco, para todos os riscos (acima da linha de corte na tabela de riscos), pode fornecer um modo de ajustar a estimativa final de custo de um projeto.

Exemplo de cálculo de Exposição do Risco - ER

Problema:

Considere que no desenvolvimento de um software apenas 60% dos componentes de software programados para reutilização (em um total de 50 componentes planejados) serão, de fato, integrados à aplicação. Com isso, as funcionalidades restantes (40% de 50) terão que ser desenvolvidas pela equipe. Através de técnicas de estimativa de probabilidade, determinou-se que a probabilidade desse risco acontecer é de 70%. Estimativas de LOC determinaram que o tamanho médio de cada componente é de 150 LOC e que o custo/LOC é de 8.00 reais/LOC. Calcule a ER para esse risco.

Solução:

Como 40% dos componentes previstos para reutilização terão que ser efetivamente desenvolvidos pela equipe, isso implica um total de:

Componentes a serem desenvolvidos = 0.40 * 50

= 20

O custo para o projeto (C) desses componentes a serem desenvolvidos pela equipe será de:

C = 20 (componentes) * 150 (LOC/componente) * 8 (reais/LOC)

C =24000.00 reais

Dessa forma, a ER será de:

ER = P * C

= 0.70 * 24000.00

= 16800.00 reais

Exposição ao Risco Total (ERT)

A Exposição ao Risco Total (ERT), para todos os riscos acima da linha de corte na tabela de riscos pode fornecer um modo de ajustar a estimativa final de custo de um projeto. Pode também ser usada para prever o aumento provável nos recursos de pessoal necessários em vários pontos do cronograma do projeto.

Uma estratégia de análise da exposição ao risco total pode ser: se ERT for maior do que 50% do custo estimado do projeto, a viabilidade do projeto deve ser avaliada.

As técnicas de previsão e análise de riscos são aplicadas iterativamente à medida que o projeto de software prossegue. Cada risco deve ser reavaliado em intervalos regulares para determinar se novas circunstâncias podem causar modificações na sua probabilidade e impacto (pode ser necessário remover alguns riscos e mudar as posições relativas de outros).

Estimativa, Análise e Priorização de Risco (parte 2)

Um fator de risco que tem alto impacto, mas probabilidade de ocorrência muito baixa, não demandará muita atenção.

Riscos de alto impacto, com probabilidade moderada a alta e riscos de baixo impacto, com alta probabilidade, demandarão maior atenção.

O guia PMI/PMBoK (2013, p. 331) apresenta uma matriz probabilidade x impacto, conforme mostra a tabela, que pode ser utilizada, com a explicação:

cada risco é classificado de acordo com a sua probabilidade de ocorrência e impacto, se ele realmente ocorrer, em um objetivo. A organização deve determinar que combinações de probabilidade e impacto resultam em uma classificação de alto risco, risco moderado e baixo risco. Em uma matriz em preto e branco, essas condições são indicadas pelos diferentes tons de cinza.

Na tabela, a área cinza-escura traz números maiores e representa alto risco; a área cinza-médio traz números menores e representa baixo risco; a área cinza-clara, com números intermediários, representa risco moderado.

Matriz de Probabilidade x Impacto

	Probabilidade	Ameaças					Oportunidades
	0,90	0,05	0,09	0,18	0,36	0,72	0,72	0,36	0,18	0,09	0,05
	0,70	0,04	0,07	0,14	0,28	0,56	0,56	0,28	0,14	0,07	0,04
	0,50	0,03	0,05	0,10	0,20	0,40	0,40	0,20	0,10	0,05	0,03
	0,30	0,02	0,03	0,06	0,12	0,24	0,24	0,12	0,06	0,03	0,02
	0,10	0,01	0,01	0,02	0,04	0,08	0,08	0,04	0,02	0,01	0,01
		0,05/ Muito baixo	0,10/ Baixo	0,20/ Moderado	0,40/ Alto	0,80/ Muito alto	0,80/ Muito alto	0,40/ Alto	0,20/ Moderado	0,10/ Baixo	0,05/ Muito baixo
Impacto (escala numérica) em um objetivo (por exemplo, custo, tempo, escopo ou qualidade) Cada risco é avaliado de acordo com a sua probabilidade de ocorrência e o impacto em um objetivo se ele realmente ocorrer. Os limites de tolerância da organização para riscos baixos, moderados ou altos são mostrados na matriz e determinam se o risco é alto, moderado ou baixo para aquele objetivo.

Fonte: PMI (2013, p. 331).

Conforme dissemos, a probabilidade de risco pode ser determinada fazendo-se estimativas individuais e depois desenvolvendo um único valor de consenso. Existem técnicas mais sofisticadas para determinação de probabilidades que fazem uso da Estatística para seus cálculos.

Um exemplo de avaliação qualitativa de risco é a avaliação do risco global do projeto, que foi derivada de dados de risco obtidos por levantamento feito com gerentes de projeto de software experientes, em várias partes do mundo. De acordo com Pressman e Maxim (2016, p. 781), essa avaliação consiste em observar as respostas dadas às questões a seguir, as quais estão ordenadas por sua importância relativa ao sucesso de um projeto:

1. A alta administração e o cliente estão formalmente comprometidos em apoiar o projeto?
2. Os usuários finais estão comprometidos com o projeto e o produto a ser criado?
3. Os requisitos estão bem entendidos pela equipe de desenvolvimento e pelo cliente?
4. Os clientes envolveram-se na definição dos requisitos?
5. Os usuários finais têm expectativas realistas?
6. O escopo do projeto é estável?
7. A equipe de desenvolvimento tem a combinação de aptidões adequadas?
8. Os requisitos do projeto são estáveis?
9. A equipe de projeto tem experiência com a tecnologia a ser implementada?
10. A quantidade de pessoas na equipe de desenvolvimento é adequada para fazer o trabalho?
11. Os clientes e usuários concordam com a importância do projeto e com os requisitos do produto a ser construído?

Se qualquer uma das questões for respondida negativamente, devem ser providenciados e formalizados com urgência processos de mitigação, monitoramento e gestão. O grau em que o projeto está em risco é diretamente proporcional ao número de respostas negativas dadas às questões.

Todo este conjunto de atividades consiste na Avaliação de Riscos. Esta é uma importante etapa principalmente quando se está diante de um grande número de possibilidades de risco, exigindo esforço adicional de filtragem e priorização.

Estimativa, Análise e Priorização de Risco

A previsão (estimativa) de risco busca classificar cada risco de dois modos:

• a probabilidade de que o risco seja real e ocorrerá; e
• as consequências dos problemas associados ao risco, se ele ocorrer.

Normalmente, nenhuma equipe de software dispõe de recursos para tratar todos os riscos possíveis com o mesmo grau de rigor. Categorizando os riscos (para uma posterior priorização), a equipe pode alocar recursos onde eles vão ter maior impacto.

Uma tabela de riscos pode ser utilizada como uma técnica para estimativa de risco. A tabela é um exemplo de tabela para estimativa/previsão de risco.

A elaboração da tabela de riscos segue os passos:

• a listagem de todos os fatores de risco (não importando quão remotos sejam) é colocada na 1ª coluna da tabela – Riscos;
• cada fator de risco é categorizado na 2ª coluna – Categoria;
• na 3ª coluna – Probabilidade, coloca-se a probabilidade de ocorrência de cada fator de risco. Para isso, várias técnicas podem ser utilizadas. Dentre elas, a técnica Delphi, que utiliza valores estimados individualmente por cada membro da equipe para se chegar em um valor de “consenso”.
• na 4a coluna – Impacto é estimado o impacto de cada risco, seguindo, por exemplo, as seguintes categorias:
1. Catastrófico (Valor de Impacto = 1)
2. Crítico (Valor de Impacto = 2)
3. Marginal (Valor de Impacto = 3)
4. Negligenciável (Valor de Impacto = 4)

Tabela de Riscos

Riscos	Categoria	Probabilidade	Impacto
Estimativa de tamanho pode ser baixa	Tamanho do produto	60%	2
Número de usuários maior que o planejado	Tamanho do produto	30%	3
Menos reúso que o planejado	Tamanho do produto	70%	2
Usuários finais resistem ao sistema	Impacto do negócio	40%	3
Prazo de entrega apertado	Impacto do negócio	50%	2
Financiamento perdido	Impacto do negócio	30%	1
Cliente modificará os requisitos	Tamanho do produto	80%	2
Tecnologia não satisfará expectativas	Tecnologia a ser usada	30%	1
Pessoal inexperiente	Tamanho e experiência da equipe	30%	2
Rotatividade alta	Tamanho e experiência da equipe	60%	2

Fonte: baseada em Pressman; Maxim (2016, p. 784).

Uma vez criada a tabela de riscos, a análise de riscos pode ser feita de forma quantitativa ou qualitativa.

De acordo com o PMI/PMBoK (2013, p. 328) realizar a análise qualitativa dos riscos

é o processo de priorização de riscos para análise ou ação adicional através da avaliação e combinação de sua probabilidade de ocorrência e impacto. O principal benefício deste processo é habilitar os gerentes de projetos a reduzir o nível de incerteza e focar os riscos de alta prioridade.

Ainda de acordo com o PMI/PMBoK (2013, p. 328) realizar a análise quantitativa dos riscos

é o processo de analisar numericamente o efeito dos riscos identificados nos objetivos gerais do projeto. O principal benefício desse processo é a produção de informações quantitativas dos riscos para respaldar a tomada de decisões, a fim de reduzir o grau de incerteza dos projetos.

Para realizar a priorização dos riscos, a tabela de riscos é ordenada por probabilidade e por impacto. Os riscos com alta probabilidade e alto impacto vão para o alto da tabela e os riscos com baixa probabilidade vão para a parte de baixo. Esse procedimento é denominado “priorização de riscos de primeira ordem”.

Em seguida, uma linha de corte é estabelecida: riscos situados acima da linha receberão atenção subsequente. Riscos que ficam abaixo são reavaliados para se chegar a uma priorização de segunda ordem.

Identificação de Risco

De acordo com o PMI/PMBoK (2013, p. 319),

identificar os riscos é o processo de determinação dos riscos que podem afetar o projeto e de documentação de suas características. O principal benefício desse processo é a documentação dos riscos existentes e o conhecimento e a capacidade que ele fornece à equipe do projeto de antecipar os eventos.

De acordo com Pressman e Maxim (2016), a identificação dos riscos envolve a definição de ameaças ao planejamento do projeto (estabelecer o escopo do projeto, determinar a viabilidade do projeto, definir os recursos necessários, realizar as estimativas do projeto, desenvolver o cronograma do projeto etc).

Um método para identificar riscos, ainda de acordo com Pressman e Maxim (2016, p. 780), é criar uma checklist de itens dentre os riscos conhecidos e previsíveis, em subcategorias genéricas como:

• Tamanho do produto: riscos associados ao tamanho do software a ser criado ou modificado.
• Impacto no negócio: riscos associados às restrições impostas pela gerência ou mercado.
• Características de pessoas envolvidas: riscos associados aos clientes e às habilidades de comunicação dos desenvolvedores.
• Definição de qualidade e processo: riscos associados à influência da gestão de qualidade do projeto.
• Ambiente de desenvolvimento: riscos associados à qualidade e disponibilidade das ferramentas de suporte ao software.
• Tecnologia a ser criada: riscos associados à complexidade do sistema e às novidades tecnológicas incorporadas no software.
• Tamanho e experiência da equipe: riscos associados à experiência técnica da equipe que desenvolverá o software.

Essa checklist pode ser organizada de diversas formas, de maneira que questões importantes a cada um dos tópicos possam ser respondidas, facilitando o processo de estimar riscos e seus impactos.

Gestão de Riscos de Software

A gestão de riscos é uma atividade que visa fornecer uma cobertura em relação às variáveis que podem levar aos riscos capazes de comprometer o desenvolvimento de software. Fatores que podem aumentar a probabilidade de falha ou de fracasso total em projetos são previamente estabelecidos, avaliados e acompanhados constantemente, com a redução ou eliminação da sua ocorrência e dos seus efeitos adversos.

Gestão de Riscos

 

Fonte: Photon photo/Shutterstock

A gestão de riscos é crucial para um bom gerenciamento de projeto de software. Tanto as empresas quanto os profissionais de software têm se mobilizado no sentido de tornar mais claras as questões relativas a essa área. Cada vez se torna mais comum medidas como treinamentos específicos, incentivos à certificação de profissionais, implantação de programas de qualidade, padronizações etc.

Em relação às estratégias de gestão de risco, Pressman e Maxim (2016, p. 778) definem:

• Estratégia de Risco Reativa: nada é feito em relação aos riscos até que algo dê errado. Se algo der errado, são tomadas atitudes na tentativa de corrigir o problema rapidamente.
• Estratégia de Risco Proativa: a análise de riscos começa antes de o trabalho técnico ser iniciado. Riscos potenciais são identificados, suas probabilidades e impactos são avaliados e eles são classificados por importância. Em seguida, é estabelecido um plano para administrar os riscos.

O objetivo principal da gestão de riscos é evitar riscos. Como nem todos os riscos podem ser evitados, um plano de contingência deve ser elaborado visando ações controladas e efetivas.

Eventos imprevistos podem causar efeitos adversos e, em muitos casos, catastróficos no andamento de um projeto. As técnicas e procedimentos de Gestão de Risco surgiram como uma tentativa de resposta à necessidade de prever, compreender e prevenir a ocorrência de riscos, bem como reduzir quaisquer efeitos negativos caso eles venham a ocorrer.

Algumas das práticas mais difundidas na gestão de risco são:

• Identificação sistemática de riscos através de revisões de documentação, técnicas de coleta de informações, análise SWOT – Strenghts, Weaknesses, Opportunities and Threats (Forças, Fraquezas, Oportunidades e Ameaças).
• Análise probabilística de riscos, incluindo o grau de possibilidade de ocorrência e de sua gravidade.
• Planejamento detalhado para a redução do grau de incerteza da ocorrência e da gravidade dos eventos de risco a um valor aceitável.
• Metódica análise de trade-offs resultando em um plano de resposta a riscos.
• Designação de um Gerente de Riscos.

Boehm (1991) propõe a subdivisão de atividades, mostrada na figura, para a gestão de riscos.

Gestão de Riscos

 

Fonte: baseada em Boehm (1991).

Neste material, vamos abordar as seguintes atividades de Gestão de Riscos:

1. Identificação de Riscos.
2. Estimativa, Análise e Priorização de Riscos.
3. RIMM – Risk Mitigation, Monitoring and Management.

Gestão de Riscos

Conceitos básicos sobre riscos em projetos de software

Estudos e a prática comprovam que uma série de fatores podem ameaçar o sucesso dos processos de desenvolvimento de software. Taxas relativamente altas de projetos atrasados, custos que ultrapassam as estimativas, implementações que não correspondem ao que foi exigido e projetos que são abortados antes da sua conclusão são problemas frequentemente encontrados na área de desenvolvimento de software.

De acordo com levantamento realizado pelo Standish Group, em 2015, dos projetos acompanhados, 29% foram completados com sucesso e 19% fracassaram. A tabela ilustra estes números desde 2011.

Resultados do Chaos Report do StandishGroup

	2011	2012	2013	2014	2015
Successful	29%	27%	31%	28%	29%
Challenged	49%	56%	50%	55%	52%
Failed	22%	17%	19%	17%	19%

Fonte: Hastie; Wojewoda (2015).

Estes números deixam claro que projetos de software envolvem riscos e são esses riscos que podem comprometer o projeto. Assim, é importante entender os riscos e tomar medidas para evitá-los ou administrá-los.

Mas o que se entende por risco?

Segundo Pethia et al. (2000, p. 45), “risco é a medida da probabilidade e severidade de efeitos adversos”.

Riscos de software

 

Fonte: Olivier Le Moal/Shutterstock

Ropponen; Lyytinen (2000, p. 100) definem variável de risco como “um estado ou propriedade de uma tarefa de desenvolvimento ou do ambiente que, uma vez ignorada, aumentará a probabilidade de falha do projeto”.

Pressman e Maxim (2016, p. 779) afirmam que, embora haja debate em relação à melhor definição de risco, há um consenso de que o risco

sempre envolve duas características: incerteza, pois o risco pode ou não ocorrer, ou seja, não existem riscos com 100% de probabilidade; e perda, pois se o risco se tornar realidade, consequências ou perdas indesejadas ocorrerão.

Os autores dizem que quando um risco for analisado, é importante que sejam quantificados tanto o nível de incerteza quanto o grau de perda associados. Para isso, devem ser consideradas as diferentes categorias de risco:

• Riscos de Projeto: identificam problemas potenciais orçamentários, de cronograma, de pessoal (quantidade e organização), de recursos, de clientes e de requisitos e seu impacto em um projeto de software. Ameaçam o plano do projeto.
• Riscos Técnicos: identificam problemas potenciais de implementação, de interface, de verificação e de manutenção. Ameaçam a qualidade e a data de entrega do software a ser produzido.
• Riscos do Negócio: ameaçam a viabilidade do software a ser construído. Os principais riscos do negócio são:
• Risco de Mercado: construir um produto ou sistema excelente que não interesse a ninguém.
• Risco Estratégico: construir um produto que não se encaixa mais na estratégia geral de negócios da empresa.
• Risco de Vendas: construir um produto que a equipe de vendas não sabe como 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 pessoal.

Ainda segundo os autores, outra categorização possível de risco inclui os seguintes:

• Riscos Conhecidos: podem ser descobertos após a avaliação do plano de projeto, do ambiente técnico e comercial (prazo de entrega irreal, falta de documentação dos requisitos e/ou do escopo, ambiente de desenvolvimento ruim ou desfavorável etc.).
• Riscos Previsíveis: obtidos de experiência de projetos anteriores (rotatividade de pessoal, diluição do esforço de pessoal à medida que os pedidos de manutenção surgem).
• Riscos Imprevisíveis: extremamente difíceis de serem identificados antecipadamente.