Se você desenvolve software provavelmente já esbarrou nessa questão alguma vez. Já li e ouvi muitas pessoas reclamando da utilidade das técnicas existentes, dizendo que não basta utilizar apenas uma estimativa para se obter um prazo para desenvolvimento de software, ou pior, que não adianta estimar software pois a criação de programas de computador é uma atividade totalmente empírica, não mensurável.
Há quem acredite que as estimativas acabam incluindo muita gordura em um projeto. Outras que simplesmente não funcionam. Porém, Brooks em seu livro “O Mítico Homem-Mês” afirma que todo engenheiro de software tem a tendência de ser otimista demais com relação a prazos utilizando apenas o feeling, porque o engenheiro não costuma enxergar as complexidades de uma implementação em um primeiro momento. O resultado disso são prazos infundados que acabam por se mostrar extremamente sensíveis.
Uma estimativa serve para estimar, e não para estabelecer um contrato. Porém, o mercado exige escopo, custo e prazo na prestação de serviço. Algumas questões surgem – O que vai ser feito, quanto tempo você vai precisar, quanto isso vai custar? – e nada mais natural para o prestador de serviços que utilizar-se de uma ferramenta para estimar um determinado trabalho que será realizado. Todos os clientes querem um prazo, todas as atividades necessitam de alguma espécie de estimativa e todas as partes, sem exceção, conquistam algum sucesso ou fracasso nesse caminho. Seja na construção de uma casa, de um forno petroquímico ou da linha de produção uma cadeira. Acho muito difícil ser diferente com desenvolvimento de software porque o mundo simplesmente não funciona de outra forma.
Atualmente estou experimentando algumas técnicas de estimativas de desenvolvimento de software. A primeira delas, Análise de Pontos de Função, considera funções do software, arquivos lógicos internos e transações para estabelecer o tamanho funcional do software. Com base nesse tamanho, e dadas algumas variáveis do ambiente humano e técnico no qual o trabalho se desenvolverá, é possível obter uma estimativa. Ela foi criada em 1977 por Alan Albrecht na IBM, e hoje é uma unidade de medida reconhecida pela ISO.
A segunda, Pontos de Caso de Uso, tem mais aderência com a Análise Orientada a Objetos e presume a utilização de um diagrama UML chamado Diagrama de Casos de Uso para mapeamento de funcionalidades do software. Essa técnica também utiliza variáveis do ambiente humano e técnico envolvido com o projeto para se obter uma estimativa final.
Eu particularmente fiquei mais empolgado com o Pontos de Caso de Uso pela possibilidade de utilizá-lo logo no início do projeto, obtendo uma estimativa sem ter que detalhar demais as funcionalidades de um software prematuramente, antes do cliente fechar o contrato. Estou empregando essa técnica em um projeto de Software de Gestão da Qualidade, e estou obtendo bons resultados.
Vinicius Serpa 