Estimativa de prazo e esforço

Estimar significa declarar um valor aproximado de alguma quantidade e é baseado em pressuposição imperfeita e incompleta do que ocorrerá no futuro (GALORATH; EVANS, 2006, p. 34). Não se espera que a previsão seja exata, mas que ela seja próxima o suficiente do número correto para permitir uma tomada de decisão (FENTON; PFLEEGER, 1997, p. 428).

A estimativa de software é realizada em dois níveis: de sistema e de componente (CSCI13_{). A estimativa no nível de sistema é realizada na fase inicial do desenvolvimento}

quando todos os detalhes relacionados com a arquitetura e com o projeto ainda não estão disponíveis. Muitas vezes o sistema pode ser somente um conceito e os requisitos a serem alocados aos componentes não são bem conhecidos. A estimativa ao nível de componente é realizada quando o desenvolvimento já possui claro entendimento dos requisitos e estes são alocados aos componentes dos subsistemas. Nesse momento todas as informações para a definição de cronograma, alocação de recursos e para a construção do componente já estão definidos (STSC, 2008, p.20). A estimativa ao nível de componente é muito mais precisa que a estimativa realizada ao nível do sistema, visto que possui maior grau de informação, entretanto, só pode ser realizada em estágio avançado do processo de desenvolvimento.

O Standish Group publicou o The Chaos Report 2009, que descreve o resultado de projetos de software. Pode-se observar, no gráfico 1, que, ao longo dos últimos anos, há um crescimento dos projetos que foram realizados dentro do prazo previsto. Por outro lado, embora houvesse uma tendência de redução dos projetos que falham, nos últimos três anos, houve um aumento de 5%. Quanto aos projetos que atrasam, percebe-se ainda um grande caminho a ser trilhado no que tange a melhoria das métricas de estimativas, visto que a grande maioria dos projetos – 44% – atrasa e, certamente, um percentual não conhecido desse número se deve a falha na estimativa total do esforço e, por conseguinte, do prazo do projeto.

13

Computer Software Configuration Item – Um grupo de software tratado como uma simples entidade por um

sistema de gerenciamento de configuração (Disponível em: <http://encyclopedia2.thefreedictionary.com/CSCI>. Acesso em: 25 ago. 2009).

Resultado alcançado pelos projetos de software 16% 27% _26% 28% 34% 29% 35% 32% 53% 33% 46% 49% 51% 53% 46% 44% 31% 40% 28% 23% 15% 18% 19% 24% 0% 10% 20% 30% 40% 50% 60% 1994 1996 1998 2000 2002 2004 2006 2009 Ano P e r c e n t u a l Suces s o Atras ou Falhou Font e: The Curious Case of t he CHA OS Report 2009 por Jorge Dominguez

Gráfico 1 – Resultado alcançado pelos projetos de software

McConnell (2006, p. 36) apresenta gráfico com o posicionamento de 80 projetos de software concluídos por uma indústria (gráfico 2). A análise do gráfico demonstra que somente um projeto foi entregue antes do prazo, poucos no prazo e os demais, quase totalidade, foram entregues atrasados. Ou seja, nessa indústria, 75% dos projetos de software ultrapassam o tempo de sua estimativa (MCCONNELL, 2006, p. 18).

Gráfico 2 – Posicionamento dos projetos quanto à estimativa prevista (MCCONNELL, 2006, p. 36)

Por outro lado, o erro na estimativa não é um privilégio da área de software. Inúmeros são os exemplos de projetos que extrapolaram o prazo e os custos. Um projeto em que os

custos ficaram superiores a 400% do valor original foi a construção de uma rodovia – Boston´s Big Dig – o projeto originalmente estimado em $2.6 bilhões de dólares custou perto de $15 bilhões. A área de software também conta com projetos que apresentam números dramáticos, como é o caso do sistema Irish Personnel, Payrol and Related Systems (PPARS) que foi cancelado após ter ultrapassado em mais de 1500% o custo inicialmente projetado de €8.8 milhões de euros (MCCONNELL, 2006, p. 43).

Shukla e Misra (2008, p. 107) apontam que problemas relacionados com turnover dos mantenedores, recrutamento, custo e tempo gasto na licitação da manutenção e otimização na alocação dos recursos tem tornado a estimativa de manutenções de longo prazo um grande desafio para as organizações de manutenção. Por outro lado, pode ser que a indústria de software esteja subestimando o problema a ser trabalhado no projeto de manutenção, o que levaria a estimativas irreais e, em decorrência, a atrasos nos projetos.

Já Fenton e Pfleeger (1997, p. 433) declaram que nem sempre os erros nas estimativas decorrem da natureza do problema. Capers Jones (1998 apud MCCONNELL, 2006, p. 35), contribuindo com a análise de atraso dos projetos, apresenta uma visão de que quanto maior o projeto, maior o risco de atraso e também de falha, conforme pode ser observado na tabela 2, a seguir.

Tabela 2 - Resultado alcançado pelos projetos em função do tamanho

Tamanho em Pontos por Função (e linhas de código aproximada)

Cedo No Prazo Atrasado Falhou (Cancelado) 10 PF14 ( 1.000 LOC) 11% 81% 6% 2% 100 PF (10.000 LOC) 6% 75% 12% 7% 1.000 PF (100.000 LOC) 1% 61% 18% 20% 10.000 PF (1.000.000 LOC) <1% 28% 24% 48% 100.000 PF (10.000.000 LOC) 0% 14% 21% 65%

Fonte: Estimating Software Costs (Jones 1998).

(Fonte: MCCONNELL, 2006, p. 35)

McConnell (2006, p.43) aponta que o erro na estimativa provém de quatro origens genéricas:

a) informação incompleta sobre o projeto que se está estimando;

b) informação incompleta sobre as capacidades da organização que irá executar o projeto; c) ausência de processo adequado para a condução do projeto e da própria estimativa –

14 _{Pontos por função (PF) - Function Point (FP) – é uma unidade de medida para expressar o conjunto de}

confusão entre a estimativa e o alvo do projeto;

d) inexatidão proveniente do próprio processo de estimativa.

DeMarco sugere que a definição padrão da estimativa é apresentar sempre o menor tempo em que uma dada tarefa pode ser realizada. Ocorre que a estimativa é resultante da probabilidade e portanto, deve possuir uma determinada faixa onde o resultado pode efetivamente ser obtido (DEMARCO, 1982, p. 15). Para resolver essa distorção propõe a adoção de uma mudança conforme demonstrado pelo gráfico 3, do contrário, se considerada somente a definição padrão, a tendência será sempre do resultado da estimativa ficar abaixo do resultado real.

Gráfico 3 – Estimativa proposta em substituição a estimativa padrão (DEMARCO, 1982, p. 15)

Considerando essa abordagem, um dos problemas da estimativa dever-se-ia ao momento indicativo do prazo de entrega, muito antes do tempo correto, considerando os conceitos da probabilidade. Motivo que justificaria a existência de grande quantidade de projetos que atrasam quando comparados com a estimativa inicial.

Outro aspecto a ser considerado é a diferença entre alvo e compromisso. Enquanto o alvo é uma descrição de um objetivo de negócio desejável, um compromisso é a promessa de entregar determinada funcionalidade em um nível específico de qualidade em certa data. Os negócios estabelecem seus alvos com base em importantes razões e nem sempre consideram as estimativas do desenvolvimento do software. Isso quer dizer que, embora um alvo seja desejável, não significa que necessariamente será alcançado. Um compromisso pode ser o mesmo que o estimado, mais agressivo ou mais conservador que o estimado (MCCONNELL, 2006, p. 14).

Corroborando McConnell, Fenton e Pfleeger (1997, p. 433) declaram que alguns problemas da estimativa decorrem de aspectos políticos quando as estimativas são convertidas em alvos ou quando são manipuladas para chegarem em resultados previamente estabelecidos. A estimativa, portanto, deve ser independente (DEMARCO, 1982, p. 36) da vontade e desejo das pessoas envolvidas a fim de ser útil para as organizações.

Outra diferença importante é entre a meta da estimativa e a meta do planejamento. Enquanto a estimativa é imparcial e resultante de um processo analítico – a meta da estimativa é a obtenção da acurácia – o planejamento é parcial e resultante de um processo voltado para o alcance de uma meta – a meta do planejamento é atingir um resultado específico. Daí que, estimativas corretas permitem a criação de um cronograma detalhado, a identificação adequada do caminho crítico do projeto, criação de uma projeção completa de entrega de pacotes, priorização de entrega de funcionalidade e também a quebra de um projeto em iterações (MCCONNELL, 2006, p. 15). Ou seja, a estimativa é elemento importante para a construção do planejamento e não pode ser confundido com este sem correr o risco de não se alcançar o resultado desejado.

Fenton e Pfleeger (1997, p. 105) declaram que sistemas de predição para estimativa de custo de software e estimativa de esforço são muito estocásticos15 e suas margens de erros são bastante amplas. O padrão mais comum para avaliar a precisão de uma estimativa é o modelo proposto por Conte, Dunsmore e Shen em 1986 (apud FENTON; PFLEEGER 1997, p. 431), em que sugerem que uma boa abordagem de estimativa provê estimativas que estão dentro de 25% dos resultados atuais em 75% das vezes. Jones (1998 apud MCCONNELL, 2006, p. 21) aponta que há relatos de estudiosos que têm encontrado empresas que conseguem melhorar essa precisão, entretanto isso se dá em projetos bem controlados.

Para se ter projetos bem controlados é importante ter um processo bem definido. Conforme pode ser visto pelos gráficos 4 e 5, decorrentes do resultado das estimativas de projetos e o nível de maturidade CMM16_{, que quanto maior o nível de maturidade da}

organização no processo de desenvolvimento de software, melhor é o resultado das suas estimativas e a obtenção de projetos no prazo.

15 _{Modelo Estocástico – a partir de um mesmo conjunto de dados de entrada o resultado varia}

probabilisticamente. Contrapõe-se ao modelo determinístico para o qual o resultado não varia (FENTON; PFLEEGER 1997, p. 105).

16 _{Capability Matutity Model desenvolvido pelo SEI - Software Engineering Institute da Universidade Carnegie}

Gráfico 4 – Melhoria na estimativa de projetos na Força Aérea dos Estados Unidos

(MCCONNELL, 2006, p. 21)

Gráfico 5 – Melhoria na estimativa de projetos na Boeing Company

(MCCONNELL, 2006, p. 21)

McConnell (2006, p. 25) declara que uma boa estimativa provê uma visão clara o suficiente da realidade do projeto a fim de permitir que sejam tomadas boas decisões acerca de como controlar o projeto para alcançar os seus objetivos. Galorath e Evans (2006, p. 16) reforçam a importância do compromisso do líder do projeto em gerenciar, controlar e acompanhar o processo, o trabalho, a qualidade do produto e a produtividade do pessoal.

Portanto, para a obtenção de um resultado adequado, são necessários uma boa previsão da estimativa, um bom cenário-alvo, um bom processo de controle e acompanhamento do projeto e um líder compromissado com o projeto. Trata-se de um conjunto de fatores que fazem que o projeto alcance o resultado pretendido no esforço estimado.

McConnell (2006, p. 38) destaca como benefícios decorrentes de uma estimativa precisa do esforço no desenvolvimento de software:

a) melhora a visibilidade dos projetos: estimativas realistas permitem a elaboração de planos que podem ser acompanhados e controlados;

b) provê alta qualidade: 40% de todos os erros de software são decorrentes do stress relacionado à pressão pelo prazo a que os desenvolvedores são submetidos;

c) melhor coordenação com outras áreas do negócio: campanhas de marketing, entre outras; d) melhora o orçamento: com boa estimativa, o orçamento é corretamente previsto;

e) melhora a credibilidade da área de TI: estimativas realísticas, aumentam a confiança da organização na equipe;

f) informação antecipada de risco: a percepção de diferença entre as metas do projeto – negócio – e da estimativa do projeto, permite que, cedo no projeto possa ser tomadas medidas que possibilitem concluir o projeto no prazo ou definir estratégias para evitar impacto no negócio.

A estimativa de software é relevante para as organizações a fim de antecipar os custos envolvidos com a mudança a ser realizada, de modo que decisões relacionadas com priorização e planejamento possam ser tomadas de forma mais adequada. Por outro lado, há uma série de problemas e fatores que devem ser considerados para os quais ainda não há uma resposta certa, nem um único caminho a ser seguido.

Considerando o estágio atual da maturidade dos processos de estimativa, é relevante entender quão confiante podem ser as estimativas de esforço de desenvolvimento e manutenção de software.

2.4 NÍVEL DE CONFIABILIDADE DA ESTIMATIVA DE ESFORÇO DE SOFTWARE