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

Modelo COCOMO II

De acordo com Pressman e Maxim (2016, p. 745), COCOMO –COnstructive COst MOdel (Modelo Construtivo de Custo) é uma hierarquia de modelos de estimativa de software proposto por Barry Boehm em 1981. Este modelo evoluiu para um modelo mais abrangente denominado COCOMO II.

O modelo COCOMO II foi derivado dos dados de produtividade coletados de milhares de projetos de software e, com base nestes dados, foi derivado um modelo de estimativa E representado pela equação:

Onde:

E= esforço em pessoas-mês ou pessoas-ano

t = duração do projeto em meses ou anos

B = fator de habilidades especiais (para programas pequenos em torno de 5 a 15 KLOC, B= 0.16 e para programas grandes maiores que 70 KLOC B= 0.39)

P = parâmetro de produtividade (valores típicos podem ser P=2mil para software embarcado ou de tempo real, P= 10mil para softwares de telecomunicações e sistemas e P=28mil para aplicações comerciais).

Modelos de Estimativa Empíricos

Alguns modelos de estimativa para software usam fórmulas empíricas. Essas fórmulas são derivadas usando análise de regressão de dados coletados de projetos anteriores. Normalmente usa-se uma amostra limitada de dados de projetos.

Cada modelo de estimativa é adequado para um determinado conjunto de classes de software e ambientes de desenvolvimento, ou seja, são dependentes dos dados dos projetos que foram usados para obtê-los. Devido a isso, geralmente esses modelos de estimativa devem ser adaptados para as condições locais da organização.

É claro que, antes de serem usados na sua empresa, esses modelos devem ser testados usando resultados de projetos finalizados. Os dados estimados pelo modelo devem ser comparados aos resultados reais e a eficácia do modelo deve ser analisada para as condições locais.

De acordo com Pressman e Maxim (2016, p. 744), a estrutura geral dos modelos empíricos tem a forma:

E = A + B x (ev)c

Onde:

A, B, c são constantes derivadas empiricamente

E esforço em pessoas-mês

ev variável de estimativa (LOC ou PF)

A maioria dos modelos de estimativa tem alguma forma de fator de ajuste ao projeto. Isso permite que a variável E seja ajustada por características específicas do projeto, tais como complexidade do problema, experiência da equipe e ambiente de desenvolvimento.

A seguir, apresentamos alguns exemplos de modelos empíricos orientados a FP para esforço (E):

E = -13.39 + 0.0545 x (PF) (modelo de Albrecht e Gaffney)

E = 60.62 + 7.728 x 10-8 x (PF)3 (modelo de Kemerer)

E = 587.7 + 15.12 x (PF) (modelo de Matson, Barnett e Mellichamp)

E agora, alguns exemplos de modelos empíricos orientados a LOC para esforço (E):

E = 5.2 x (KLOC)0,91 (modelo de Walston-Felix)

E = 5.5 + 0.73 x (KLOC)1,16 (modelo de Bailey-Basili)

E = 3.2 x (KLOC)1,05 (modelo de Boehm simples)

E = 5.288 x (KLOC)1,047 (modelo de Doty para KLOC > 9)

É importante ressaltar que para os mesmos valores de FP ou LOC, os modelos vão gerar resultados diferentes (porque foram gerados, cada qual, em alguns domínios de aplicação específicos). Portanto, para utilizar esses modelos, eles devem ser adaptados para as necessidades locais.

Exemplos de Estimativas Baseadas em LOC (parte 2)

Exemplo 2:

A tabela 1 apresenta as estimativas de tamanho otimista, mais provável e pessimista para cada uma das funções a serem implementadas no software CAD do exemplo 1. Considerando que a empresa de software responsável em desenvolver o projeto produz 400 LOC/por mês, com um valor bruto de mão de obra de R$ 3000,00 por pessoa-mês, podemos, com base nesses dados, obter a estimativa de custo e esforço necessários para construir o software usando a técnica de estimativa baseada em LOC.

Tabela 1 – Estimativas de Tamanho Otimista, Mais Provável e Pessimista (em LOC)

Função	Otimista(Tot)	Mais Provável(Tmp)	Pessimista(Tpess)
Recursos de Visualização	3000	4400	6000
Recursos de Análise 2D	5000	5500	6500
Recursos de Análise 3D	6400	7000	6900
Recursos de Controle e Interface com o usuário	3300	2500	2300
Administração da Base de Dados	6000	4100	2600
Recursos de Controle de Periféricos	1000	2800	4200
Recursos de Análise de Projetos	7700	7900	8200

A tabela 2 apresenta o cálculo do tamanho de cada uma das funções (em LOC) utilizando a expressão apresentada anteriormente T=(Tot + 4Tmp + Tpess)/6.

Tabela 2 – Cálculo do tamanho de cada função

Função	Estimativa de LOC
Recursos de Visualização	T1 = ( Tot + 4Tmp + Tpess ) / 6 @4433
Recursos de Análise 2D	T2 = ( Tot + 4Tmp + Tpess ) / 6 @5583
Recursos de Análise 3D	T3 = ( Tot + 4Tmp + Tpess ) / 6 @6883
Recursos de Controle e Interface com o usuário	T4 = ( Tot + 4Tmp + Tpess ) / 6 @2600
Administração da Base de Dados	T5 = ( Tot + 4Tmp + Tpess ) / 6 @4167
Recursos de Controle de Periféricos	T6 = ( Tot + 4Tmp + Tpess ) / 6 @2733
Recursos de Análise de Projetos	T7 = ( Tot + 4Tmp + Tpess ) / 6 @7197
Estimativa das Linhas de Código (Total)	34317 LOC

Utilizando as estimativas de tamanho e os dados do valor bruto da mão de obra e produtividade fornecidos anteriormente, podemos calcular as estimativas de esforço e custo total conforme indicado a seguir.

Esforço necessário estimado=(Estimativa de LOC)/(produtividade média)

= (34317 LOC)/(400 LOC/pessoas-mês)

@ 86 pessoas-mês

Custo por LOC = (valor bruto da mão de obra) / (produtividade média)

= (3000 reais/pessoas-mês) / (400 LOC/pessoas-mês)

= 7.50 reais/LOC

Custo total estimado do projeto=(Estimativa de LOC) * (Custo por LOC)

= (34317 LOC) * (7.50 reais/LOC)

@ 257400.00 reais

Exemplos de Estimativas Baseadas em LOC

Exemplo 1:

Suponha um determinado software que será desenvolvido. Este software é do tipo CAD – Computer-Aided Design, ou seja, tem uma aplicação científica. Após a análise do escopo do software, suas funções principais foram identificadas e são relacionadas na tabela.

Principais funções identificadas no software CAD

Função	Estimativa de LOC
Recursos de Visualização	3000
Recursos de Análise 2D	5000
Recursos de Análise 3D	6400
Recursos de Controle e Interface com o usuário	3300
Administração da Base de Dados	6000
Recursos de Controle de Periféricos	1000
Recursos de Análise de Projetos	7700
Estimativa das Linhas de Código (Total)	32400

Em seguida, um intervalo de estimativa de LOC é desenvolvido para cada função. Esse intervalo considera as estimativas como otimista, mais provável e pessimista.

Os valores das estimativas apresentados na tabela 3, para cada função, foram obtidos utilizando a expressão para T já apresentada (T =(Tot + 4Tmp + Tpess)/6).

Por exemplo, para a função “Recursos de Análise 3D”, foram obtidas: estimativa otimista Tot= 3800 LOC; mais provável Tmp= 6500 LOC; pessimista TPess= 8600 LOC. Estes valores, aplicados na equação T= (3800 + 4x6500 + 8600)/ 6, produzem um valor esperado de T= 6400 LOC.

Após o cálculo das estimativas de LOC para cada função, foi identificada uma estimativa de 32400 LOC para o sistema a ser desenvolvido.

Considerando que uma análise de dados históricos revelou que a produtividade organizacional média para sistemas desse tipo é de 500 LOC/pessoas-mês e que o valor bruto da mão de obra é de R$ 4000,00 por pessoa-mês, o custo por linha de código é de aproximadamente:

Custo por LOC = (valor bruto da mão de obra)/(produtividade média)

= (4000 reais/pessoas-mês)/(500 LOC/pessoas-mês)

= 8 reais/LOC

Portanto, o custo total estimado para o projeto é de:

Custo total estimado do projeto = (Estimativa de LOC)*(Custo por LOC)

= (32400 LOC) * (8 reais/LOC)

= 25920.00 reais/mês

O esforço necessário estimado para desenvolver o projeto é de:

Esforço necessário estimado=(Estimativa de LOC)/(produtividade média)

= (32400 LOC)/(500 LOC/pessoas-mês)

@ 65 pessoas-mês