Nesta última semana fui convidado por um colega a trocar algumas experiências sobre métricas de software, em uma empresa de TI localizada no interior do estado de SP. Durante a visita conversei com vários programadores, nota: todos formados em instituições de renome da região. Durante a conversa perguntei a eles: - Como vocês realizam estimativas de custo e prazo em projetos de software? Desculpem-me o trocadilho: "Um silêncio ensurdecedor veio à tona". Após alguns minutos fiz outra provocação: - Alguém aqui já realizou alguma estimativa em algum projeto de software? A maioria respondeu que não. De posse desta resposta, convidei a todos a realizar a seguinte experiência:
Distribui aos profissionais dois cartões, cada um deles contendo o enunciado de um algoritmo. Nada muito complexo. Solicitei a eles que implementassem os algoritmos em uma linguagem de programação qualquer. Enfatizei: - Todos devem estimar o tempo (em horas) para o desenvolvimento de cada programa. - É necessário validar as entradas dos dados.
Ressalto que todos estimaram que em uma hora os cartões estariam implementados. Vejam só os resultados da experiência:
· Foram distribuídos 20 cartões para 10 desenvolvedores.
· Tempo orçado para o desenvolvimento do projeto: 10 horas.
· Após uma hora, recebi 9 cartões implementados, 45% do projeto estava concluído.
· Restavam ainda 55%.
· Em nossa simulação, cada programador foi contratado a R$ 50,00 a hora.
· O lucro estimado com o desenvolvimento do projeto estava orçado em 60%.
· Valor total cobrado pelo projeto: R$ 800,00.
· Necessitávamos ainda de 12,22 horas de trabalho para terminar o projeto.
· Enfim, o custo total do projeto deveria ser de R$ 1411,00. (nota: o calculo só levou em consideração o custo da mão de obra)
Com base nos números apresentados é possível afirmar que um projeto de 2 horas resultou em um prejuízo de R$ 611,00.
Questionei a todos: - Como ficaria a situação da empresa em um projeto de 1000 horas?
Aproveitando a situação, fiz a mesma experiência com os alunos da disciplina de Sistemas e Tecnologias da Informação III, sexto semestre do curso de Analise de Sistemas e Tecnologias da Informação da Faculdade de Tecnologia de Ourinhos, neste caso o erro era esperado. Na turma A o prejuízo, em um projeto de 7 horas, foi de R$ 4000,00. Na turma B, o prejuízo foi de R$ 6000,00 em um projeto de 8 horas.
Analisei, superficialmente, algumas ementas das disciplinas de engenharia de software de alguns cursos de graduação em computação, pude verificar que muitos deles não abordam, ou pelo menos não citam, conceitos relacionados a métricas de software. Será que isto acontece mesmo? Será que tal fato refletiu na experiência efetuada na empresa?
Com base no contexto apresentado, acredito que parte dos profissionais de TI que trabalham, diretamente, com a produção de código não conhece a sua capacidade de produção. Realize uma experiência semelhante e confira.
José Augusto Fabri
Faculdade de Tecnologia de Ourinhos
Fundação Educacional do Município de Assis
-----
Comentário de Fábio Dias:
Caro Fabri ...
A resposta mais óbvia e curta, que todos já conhecemos, é um retumbante não.
E isso foi uma das coisas que aprendi no curso de uma universidade de renome...
Estimativas de tempo de desenvolvimento não são uma ciência exata..
(fui aconselhado sempre a dobrar minha estimativa...)
Mas além disso, fui incentivado a refletir o motivo de tanta
dificuldade... e a conclusão que cheguei foi
que somente alguém com bastante experiência em desenvolvimento, no
contexto considerado, pode conseguir
realizar uma estimativa razoável.
Podemos até ensinar nossos alunos as técnicas, métricas e demais
ferramentas... mas experiência é algo que eles conseguirão
sozinhos....
E este problema não está restrito a nossa querida área:
http://g1.globo.com/Noticias/Mundo/0,,MUL415754-5602,00.html
(e normalmente não temos o molho de chocolate para acompanhar)
Fábio
----
Comentário de Ana Paula Ludtke Ferreira
PSP é uma excelente técnica para a realização de estimativas individuais. O modelos de regressão múltipla usados para estimativas de tamanho de código produzido, tempo de desenvolvimento, quantidade e tipo de erros injetados entre outras medidas mostram-se impressionantemente acurados.
Eu recomendo :-)
----
Comentários de andreis at inf . ufrgs . br
Tem uma maxima que diz:
-Sabe como um software fica um ano atrasado?
Resposta: um dia de cada vez.
Eis uma bibliografia:
A) PARA ESTIMAR:
Software Estimation: Demystifying the Black Art (Best Practices
(Microsoft)) (Paperback)
by Steve McConnell
Microsoft Press (March 1, 2006)
B) PARA DEBUGAR
Debugging (Paperback)
by David, J Agans (Author)
Amacom (September 12, 2006)
Software Exorcism: A Handbook for Debugging and Optimizing Legacy Code
(Expert's Voice) (Hardcover)
by Reverend Bill Blunden
Apress; 1 edition (September 22, 2003)
Why Programs Fail: A Guide to Systematic Debugging (Paperback)
by Andreas Zeller
Morgan Kaufmann (October 11, 2005)
C) PARA O CASO DE O PROBLEMA NAO SER NO SOFTWARE DA MAQUINA...
Debug Your Mental Software (Paperback)
by Jay Arthur
Lifestar (April 1, 2006)
