En el proceso iterativo e incremental[1] se supone que en las primeras iteraciones se comienza afrontando los problemas de mayor riesgo construyendo una base para que las siguientes iteraciones tengan incrementos aditivos y sean estos los musculos de un esquelo estable. Es por esto que es en la primera parte es donde se analiza y diseña usando mucha información descriptiva del problema (Pues es lo Único que hay ya que no se cuenta con modelos estables aÚn) y es allí el problema de las estimaciones iniciales: La información descriptiva no basta por que la complejidad del software involucra muchas cosas más que saber que hacer y pensar en cómo.
Se dice que [Craig Larman, 2000] las estimaciones iniciales no son fiables. Las estimaciones iniciales no abarcan la problemática en toda su dimensión simplemente porque las dimensiones no se muestran en esta altura ni probablemente se mostrarán todas nunca. Que por muy bueno que sea una estimación simplemente la naturaleza de incertidumbre no permitirá que sea ajustado a la realidad (No se puede ver que una línea es en realidad una vista en una dimensión de un aro).
Todos hemos visto que estimar es una de las tareas más dificiles y costosas de realizar(y de comprobar que se hizo, que valió la pena y venderla como actividad del proceso de desarrollo) - en especial sabiendo que normalmente se hacen al inicio con la esperanza de ser confiables - por muy bien que estén definidos los requisitos [2] y por muchas técnicas Lemmings que aparezcan como Cocomo II, Puntos de función o métodos de ifpug.
Estimar inicialmente sabe agrio, sabe a desconfianza y a necesidad de mucha experiencia, a ''juicio de experto'' y sabe peor cuando la estimación ya viene dada por el contrato de turno. La pregunta es ¿Cuanto tiempo vale la pena invertir si se sabe que las estimaciones iniciales no son fiables?, la respuesta es que puedes usar tus estimaciones para obtener una mejor visión analítica del problema puesto que las técnicas como puntos de función necesitan se identifiquen entidades, sus operaciones y atributos; y que puedes usar las estimaciones para tener un nÚmero del cual saber cuanto te equivocaste[....].
La Última frase no es tan idiota como parece, de hecho me parece muy inteligente hacer la estimación inicial y hacer análisis post mortem y comparar - salvando las distancias - cuan mal se hizo al prinicipio - Si no se mide no es ingeniería.
¿Qué opino yo de la estimación inicial ?, que hay que hacerla en conjunto a la base histórica de proyectos parecidos y que en ese caso primero se someta el problema a un consenso que de orientaciones para ajustar las estimaciones que se harán (Si esta es parte del proyecto por supuesto y si las fechas fijadas pueden cambiar en base a las estimaciones).
¿Qué propone la literatura?, que al finalizar una fase se haga una reestimación y que ya en fase de elaboración del proyecto software se puede comenzar a confiar en las estimaciones realizadas en dichas fases*.
* Nótese que la fase de elaboración probablemente comience un mes o más desde el inicio del proyecto.
Mi experiencia es que lo que mejor te sirve para un proyecto - si el objetivo es bajar riesgos - es tener un buen cliente que tenga su proceso de negocio claro, que colabore y que entienda que en el software divide y vencerás no funciona per se; a pesar que lamentablemente muchos ingenieros de software creen a pies juntos que Descartes y el método como herramienta celestial lo soluciona todo.
Notas:
[1] Por ejemplo el planteado por Jacobson, Booch y Rambaugh en Proceso de desarrollo unificado.
[2] IEEE - 830
