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.

Conciliação de Modelos de Estimativas

Normalmente, estimativas de projeto precisas usam pelo menos duas das técnicas de estimativas apresentadas anteriormente. Valores médios (conciliação) de estimativas são então calculados através dos valores de estimativa obtidos das técnicas consideradas.

A conciliação é realizada quando a variação máxima a partir da média obtida não ultrapassa 20%. Nesses casos, há forte razão para acreditar que as estimativas são confiáveis. Caso contrário, mais pesquisa e análise devem ser realizadas.

Pela comparação e conciliação das estimativas derivadas usando diferentes técnicas, é mais provável que o planejador consiga derivar uma estimativa precisa. Vale lembrar que a estimativa de projetos de software não é uma ciência exata. Mas, conforme vimos, dados históricos e técnicas sistemáticas podem melhorar a precisão da estimativa.

O que são Pontos por Caso de Uso (ou Use Case Points)?

Até o início da década de 1990 havia a falsa noção de que a APF não era adequada para medir sistemas orientados a objetos. Aqueles que compartilhavam desta noção, na prática, desconheciam a APF.

Com a disseminação da construção e projeto de sistemas orientados a objetos, houve também uma mudança na forma de se especificar e modelar os sistemas. A UML e os casos de uso rapidamente tornaram-se padrão na indústria de software.

Dentro deste contexto, em 1993 Gustav Karner propôs em um trabalho acadêmico: a metodologia dos Pontos por Caso de Uso (baseado na Análise de Pontos de Função) com o intuito de estimar recursos para projetos de software orientados a objeto desenvolvidos utilizando o processo Objectory.

Fonte: <fattocs>

Estimativa com Pontos de Caso de Uso ou Use Case Points (UCPs)

Conforme já dissemos, os UCs podem ser utilizados na estimativa do tamanho planejado de um projeto de software. Embora não seja fácil utilizá-los, é possível calcular os Pontos de Caso de Uso ou Use Case Points (UCPs). Pressman e Maxim (2016, p. 741) descrevem os passos para o cálculo de UCPs como apresentado a seguir.

• Passo 1: Cada UC é avaliado para determinar sua complexidade relativa, podendo ser classificado como:
• UC Simples: possui fator de ponderação 5 e corresponde a uma interface de usuário simples, um único banco de dados com 3 ou menos transações e 5 ou menos implementações de classe.
• UC Médio: possui fator de ponderação 10 e corresponde a uma interface de usuário mais elaborada, 2 ou 3 banco de dados com 4 a 7 transações e 6 a 10 implementações de classe.
• UC Complexo: possui fator de ponderação 15 e corresponde a uma interface complexa, vários banco de dados com 8 ou mais transações e 11 ou mais implementações de classe.
• Deste passo resulta o Unadjusted Use Case Weight – UUCW, que é a soma de todas as contagens de UCs multiplicadas pelos correspondentes fatores de ponderação.

• Passo 2: cada ator é avaliado,podendo ser classificado como:
• Ator Simples: possui fator de ponderação 1 e corresponde a autômatos (outros sistemas, máquinas ou dispositivos) que se comunicam por meio de uma API.
• Ator Médio: possui fator de ponderação 2 e corresponde a autômatos que se comunicam por meio de um protocolo ou depósito de dados.
• Ator Complexo: possui fator de ponderação 3 e corresponde a seres humanos que se comunicam por meio de uma interface gráfica ou outra interface envolvendo pessoas.
• Deste passo resulta o Unadjusted Actor Weight – UAW, que é a soma de todas as contagens de atores multiplicadas pelos correspondentes fatores de ponderação.

• Passo 3: os fatores não ajustados UUCW e UAW são modificados considerando-se fatores de complexidade técnica ou Technical Complexity Factors – TCFs e fatores de complexidade ambiental ou Environmental Complexity Factors – ECFs. Uma vez determinados estes fatores, o valor final do UCP é calculado de acordo com a fórmula:

UCP = (UUCW + UAW) x TCP x ECF