O desafio de calcular prazos para seu projeto

Como compor uma fórmula mágica que forneça o tamanho exato, com base em poucas linhas de um escopo maior do que você esperava e, ao final, acertar na mosca o prazo final de entrega ao cliente. Pontos de função? Pontos de caso de uso? Ferramentas? Outros?

por Roberto Capra Neto

Se você leu a introdução desse artigo e iniciou sua leitura esperando que fosse disponibilizado a você uma planilha ou programa (com fontes de preferência) que faça exatamente isso, sinto desapontá-lo, mas ele ainda não existe. E com base nos diferentes cenários de cada empresa, clientes, ambiente, fatores externos, etc., é impossível definir um padrão comum.

Para esclarecer alguns conceitos importantes para o entendimento desse artigo, é importante ressaltar que estimativas de tamanho de software existem para tentar quantificar o escopo de um projeto. Assim como temos unidades de medida para tudo que é possível ser medido (quilograma, metros quadrados, etc.), para que fosse possível mensurar o software (requisitos, funcionalidades, etc.), também foram criadas unidades de medida.

Este artigo irá se ater a apenas duas delas, embora existam inúmeras outras:

* FP - (Function Point ou Pontos de Função)
Para saber mais, clique aqui

* UCP - (Use Case Point ou Pontos de Caso de Uso)
Para saber mais, clique aqui

* Para informações adicionais sobre cada uma das técnicas além das referências acima, como empregá-las e a base de suas fórmulas, existe um material bastante rico na web abordando esse assunto.

Para entender o conceito geral é importante saber que ambas tem a mesma função básica: Formalizar uma técnica para estimar o tamanho do software. Cada uma apresenta uma abordagem particular que, basicamente, se resume na composição de fórmulas que contabilizam itens de um escopo, passíveis de medição. Ex: quantidade de requisitos, objetos, entradas, saídas, transações, relação com banco de dados, enfim, elementos mensuráveis, partes integrantes de uma especificação de escopo. A contagem desses elementos, alinhada a aplicação de fórmulas (testadas com forte base matemática e estatística), variáveis de ambiente e alguns fatores de ajuste (necessários para generalizar a fórmula para cada situação específica) nos remetem a um tamanho em pontos.

A partir daí, com base nesse tamanho, é feita uma conversão de pontos x horas (geralmente), que servirá como base para determinar a duração das atividades de desenvolvimento. Em resumo, calcula-se o tamanho do software para se chegar no esforço necessário para concebê-lo. Há diversos estudos sobre o assunto, teses de mestrado, doutorado e fóruns de discussão. Muitos sugerem a união dos dois métodos para cálculo (Pontos de Função e Caso de Uso), outros, a adoção de um terceiro como complemento, enfim, há uma infinidade de materiais sobre o assunto.

Mas voltando a nosso artigo, você deve estar se perguntando: Então é só isso? Basta aplicar fórmulas específicas de cada técnica, usar o fator de conversão para horas e temos a duração exata de cada atividade de desenvolvimento? Seria ótimo! Mas não é tão simples quanto parece.

O que ocorre é que, independente da métrica aplicada, as organizações encontram inúmeras dificuldades em aplicá-las de modo a medir efetivamente o tamanho de software. Em geral, costumam aplicar as fórmulas de acordo com os métodos traduzindo-as em ferramentas de cálculo que, quando utilizadas, não representam a realidade dos projetos. Isso sem falar daquelas que acreditam que produtos de software são abstratos ou intangíveis e que, por essa razão, não é possível obter com precisão seu tamanho com base em um escopo pré-determinado. Mas será que é assim?

Para ser preciso, o sistema de cálculo de tamanho de software deve obter o máximo possível de variáveis da especificação. Em outras palavras, é preciso detalhar o que se quer ao máximo de tal forma que seja possível minimizar os erros de cálculo do tamanho daquilo que se planeja construir. E entre essas variáveis encontra-se uma em particular, considerada instável, e que influencia significativamente nos cálculos do tamanho de um projeto de software: O cliente.

Não é raro perceber que na maioria das organizações, os responsáveis por fornecer os dados para as especificações de projetos de software não o fazem com a precisão necessária. Em geral, querem respostas imediatas para escopos pouco detalhados, aumentando significativamente a margem de erro das estimativas de tamanho. Particularmente não gosto de analogias entre Engenharia de Software e Engenharia Civil, mas a situação acima se torna equivalente a questionar um engenheiro sobre quanto tempo levaria para construir uma casa de três quartos, sem dizer mais nada além disso. A resposta certamente dependeria da experiência do engenheiro em construir casas com essa especificação, sem falar da enorme margem de erro que poderia ocorrer, por ele fornecer uma resposta imediata, sem possuir maiores detalhes da especificação (Ex: tamanho dos quartos, tipo de material, telhado ou laje, etc.).

Sem generalizar, certamente há organizações em que o detalhamento é bem feito, e o cliente consegue retratar o que precisa, graças a técnicas de levantamento estruturadas e metodologias. Porém, mesmo nessas organizações, é possível observar problemas com as estimativas. E isso é certamente causado por um outro fator significativo (talvez o mais relevante) que é o nível de detalhe da especificação. Determinar o nível de detalhe da especificação de requisitos é fundamental para a acurácia da métrica de cálculo de tamanho de software.

A variação do nível de detalhe das especificações pode se dar por inúmeras razões, que seriam suficientes para um artigo específico sobre o tema. O que ocorre é que se não há uma maneira uniforme, critérios bem definidos sobre como os responsáveis pelas definições devem efetuar especificações, não é possível obter o tamanho com precisão.

Então, qual a resposta ideal? A melhor resposta é aquela que alinha as técnicas e ferramentas existentes, uma especificação de escopo uniforme (alinhando níveis de detalhe de cada profissional) e utilizando como fatores de ajuste a base histórica de projetos da empresa. É preciso saber quanto se gastou de tempo efetivo para construção do software em projetos anteriores, para que se possa projetar o tamanho de outros que possuam características semelhantes. Vale lembrar que esse é um assunto muito complexo e que outras variáveis também podem agregar valor as suas estimativas.

Encare os conceitos desse artigo como pontapé inicial para começar a entender métricas de software.

Grande abraço a todos!

Roberto Capra Neto.