Nível de confiabilidade da estimativa de esforço de software

projeto se encontra, conforme pode ser visto na figura do cone da incerteza (gráfico 6).

Gráfico 6 – Cone da Incerteza

(MCCONNELL, 2006, p. 46)

O erro na estimativa, quando realizado por especialista, pode variar em até quatro vezes (4x) quando realizada durante a fase de concepção inicial do produto. A margem de erro vai sendo reduzida com o avanço das fases seguintes na definição, ou seja, quanto maior clareza se tem do produto que se deseja construir, menor é o erro na estimativa do esforço (MCCONNELL, 2006, p. 45).

O cone da incerteza não estreita por si só, mas por meio da tomada de decisões que reduzem a variabilidade do projeto. Como pode ser visto no gráfico 7: definir a visão do

produto e o que não será feito no produto; definir requisitos e também o que não será feito; e desenhar a interface do usuário, permite reduzir o risco de variabilidade do projeto e, por conseguinte, da clareza do produto, gerando ainda maior redução no erro da estimativa (MCCONNELL, 2006, p. 47).

Gráfico 7 – Cone da Incerteza – Redução da variabilidade (MCCONNELL, 2006, p. 47)

Após a estimativa prévia, a partir do início do projeto, é necessário re-estimar periodicamente o projeto para auxiliar no seu planejamento e a fim de verificar a necessidade de realocação de recursos (FENTON; PFLEEGER, 1997, p. 432). Antonio; et al. (1999, p. 250) reforçam que a estimativa deve ser refinada continuamente, inclusive para estimar também as atividades após a liberação da versão.

McConnell (2006, p. 48) considera apropriado o estabelecimento de compromisso somente quando a estimativa estiver dentro da margem de erro de 30%, a fim de evitar que as empresas sabotem seus próprios projetos.

A previsão do esforço requerido para concluir um projeto não pode ser precisa quando os requisitos estão incompletos, o ambiente de desenvolvimento é instável, quando falta experiência para os membros do projeto e quando há perda de pessoas durante a fase de execução do projeto (JØRGENSEN; MOLØKKEN, 2002, p. 425). Nesses casos a variabilidade da incerteza permanece durante as fases do projeto, dificultando uma estimativa precisa. O cone da incerteza passa então a possuir uma nuvem da incerteza sobre o resultado de esforço a ser gasto durante o projeto, conforme pode ser observado no gráfico 8 (MCCONNELL, 2006, p. 46).

Gráfico 8 – Nuvem da Incerteza (MCCONNELL, 2006, p. 47)

Para esses casos em que a condução dos projetos é caótica – sem processo bem definido - uma série de desafios existe e não podem ser resolvidos pela melhora da estimativa, mas sim, pela melhora no controle e acompanhamento dos projetos. A incerteza gerada pelos projetos caóticos decorre dos seguintes exemplos: requisitos mal investigados no início do projeto; falta de validação dos requisitos pelo solicitante; desenho pobre que leva a um grande número de erros para o código; fraca prática de codificação aumentando a necessidade de correção de defeitos; pessoal inexperiente; planejamento do projeto incompleto; abandono do planejamento em caso de pressão; falta de automação do controle do código fonte (MCCONNELL, 2006, p. 48).

Tom DeMarco (1982, p. 11) apresenta sua lista das causas principais da pobre estimativa de software:

− falta de desenvolvimento de qualificação em estimativa;

− falta de previsão adequada para compensar os efeitos dos preconceitos; − inadequado entendimento do que uma estimativa deveria ser;

− dificuldade em se lidar com problemas políticos que atrapalham o processo de estimativa; − as estimativas não utilizam o desempenho passado.

Ou seja, dependendo da qualidade das variáveis utilizadas para a estimativa, a qualidade do resultado será a mesma; como demonstrado nas figuras 3 e 4.

Figura 3 – O dilema da estimativa

(DEMARCO, 1982, p.11)

Figura 4 – A qualidade do resultado depende da qualidade da entrada

(DEMARCO, 1982, p.16)

Dentre os principais originadores de problemas com a estimativa de esforço do software, McConnell (2006, p. 51-62) destaca:

a) instabilidade dos requisitos: as mudanças nos requisitos são reportadas como uma origem comum de problemas na estimativa. Há, nesse caso, dois desafios: o primeiro é o do ambiente em que os requisitos não se estabilizam durante o projeto, o que leva à situação da nuvem da incerteza durante todo o projeto; o segundo é o ambiente de instabilidade de requisitos que, a cada mudança, a estimativa é refeita. Nesses casos, o cone da incerteza fica semelhante ao do gráfico 9 e é um modelo praticado e utilizado por muitas organizações, inclusive pelo Laboratório de Engenharia de Software da Nasa17;

Gráfico 9 – Representação do Cone da Incerteza em ambiente de requisitos instáveis

(MCCONNELL, 2006, p.51)

b) atividades omitidas: um dos erros mais comuns na estimativa é o esquecimento de incluir de 20 a 30% das tarefas na estimativa do projeto;

c) otimismo infundado: desenvolvedores são naturalmente otimistas e tendem a estimar com um otimismo da ordem de 20 a 30%;

17 _{National Aeronautics and Space Administration - Administração Nacional do Espaço e da Aeronáutica,}

também conhecida como Agência Espacial Americana, é uma agência do Governo dos Estados Unidos da América, criada em 1958, responsável pela pesquisa e desenvolvimento de tecnologias e programas de exploração espacial.

d) subjetividade e influência: subjetividade na estimativa decorre de que o julgamento humano é influenciado pela experiência humana, enquanto a influência na estimativa decorre de uma intenção consciente ou inconsciente em direcionar uma estimativa em uma ou outra direção. Quanto mais elementos subjetivos existirem na técnica de estimativa, maior o risco de introdução de erro. O modelo de estimativa Cocomo II18 inclui 17 multiplicadores de esforço e cinco escalas de fatores que totalizam 22 variáveis que permitem fazer o ajuste fino de qualquer estimativa, entretanto, inserem 22 possibilidades de erros na estimativa. O gráfico 10 demonstra o resultado da aplicação em cerca de 100 grupos de estimadores utilizando Cocomo II para o mesmo problema de estimativa. Percebe-se uma enorme variação entre o nível mais alto e o mais baixo que alcança um fator de 4, enquanto a variação média do grupo mais baixo para o mais alto dentro de qualquer uma das sessões possui um fator de 1,7. O gráfico 11 apresenta o resultado do uso de uma técnica de estimativa que possui uma única variável subjetiva e o que se vê é uma dramática redução na variação das estimativas. A variação média do mais baixo grupo para o mais alto dentro de qualquer uma das sessões possui um fator de somente 1,1.

Gráfico 10 – Variação de estimativa com Cocomo II - 22 variáveis subjetivas

(MCCONNELL, 2006, p.57)

Gráfico 11 – Variação de estimativa com uma única variável subjetiva

(MCCONNELL, 2006, p.58)

DeMarco (1982, p. 13) sugere que quando o ego está envolvido na execução da tarefa, a habilidade da pessoa de quanto deveria levar a tarefa, fica prejudicada e normalmente será subestimada.

e) estimativa extemporânea: a estimativa média fornecida com base na memória tem um erro de magnitude relativa média (MMRE) de 67%, enquanto a média da estimativa revisada

18 _{O método COCOMO II - COnstructive COst MOdel - é a versão 2 de um modelo de estimativa do tempo de}

possui um erro de somente 30%. Os números indicam que não se deve dar estimativa de memória quando não está preparado para fazê-lo;

f) precisão não é garantida: a acurácia de uma medida é o grau pelo qual essa medida reflete a realidade (LAIRD; BRENNAN, 2006, p. 30), ou seja, quão próximo do valor verdadeiro um número está. Enquanto precisão se refere a quanto varia um número em torno de um valor médio. Uma medida pode ser precisa sem ser acurada e pode ser acurada sem ser precisa. Para refletir claramente os propósitos da estimativa, devem-se igualar os dígitos da estimativa – sua precisão – para a acurácia da estimativa, a fim de evitar confusão entre a precisão e a acurácia esperada;

g) área de negócio não familiar; h) tecnologia não familiar;

i) conversão incorreta do tempo da equipe destinada ao projeto;

j) falha no entendimento estatístico, incluindo no cálculo os melhores ou os piores projetos; k) processo orçamentário que não determina uma estimativa efetiva;

l) possuir uma estimativa de tamanho, mas cometer erro na transformação para estimativa de esforço; possuir uma estimativa correta de tamanho e de esforço, mas cometer erro na conversão para uma estimativa do prazo;

m) subestimar o uso de novas ferramentas e métodos;

n) simplificar a estimativa a partir das informações obtidas das camadas superiores de gerenciamento (MCCONNELL, 2006, p. 57).

A Sociedade Internacional de Análise Paramétrica (ISPA) (apud GALORATH; EVANS, 2006, p. 7) estabelece que os problemas de software freqüentemente ocorrem devido a: inabilidade de projetar corretamente o tamanho; inabilidade de especificar corretamente um ambiente de suporte e de desenvolvimento de software; avaliação inapropriada dos níveis de habilidades das pessoas; e ausência de requisitos bem definidos para estimar as atividades de software. Daniel Galorath e Michael Evans (2006, p. 14) incluem ainda: falta de dados históricos; excesso de otimismo da liderança do projeto decorrente de falha na construção das estimativas; falha no uso das estimativas; falha na manutenção da estimativa corrente. Norman Fenton e Shari Pfleeger (1997, p. 433) acrescentam dentre os não listados: aspectos

políticos na definição da estimativa; problemas técnicos, dentre estes, a falha no acompanhamento para melhorar o processo de estimativa.

Percebe-se um amplo leque de aspectos que levam a falha na estimativa dos projetos de software e isso ocorre devido à multidimensionalidade de aspectos que devem ser considerados a fim de se obter o software pronto. Por outro lado, o momento da estimativa é fator preponderante para o nível de precisão a ser alcançado. Quanto mais cedo na fase do ciclo de vida do software, menos precisa será a medida, mas não será menos acurada, ante a incerteza existente no momento da estimativa.

Considerando a importância da estimativa para a priorização, gerenciamento, desenvolvimento e para a manutenção do software, deve-se entender quais são os elementos mais relevantes que devem fazer parte de uma estimativa para se conhecer qual o esforço a ser despendido para a manutenção ou construção de um software, nas mais diferentes fases em que a tomada de decisão é necessária.