Pages Menu
Categories Menu

Posted by on Jun 6, 2011 in estimacion | 2 comments

Una breve introducción a la estimación software. El proceso (3/4)

Enlace al post Estimación software, una breve introducción (2/4)

“No se puede controlar lo que no se puede medir” (Tom De Marco)

Vistos en post anteriores los métodos de estimación de esfuerzo y de cálculo de tamaño, normalmente, todo proceso de estimación sigue un esquema como el de la siguiente figura:

Lo normal es empezar estimando el tamaño. El tamaño suele estimarse en función de la funcionalidad que se espera que tenga el software (con PF, contando requisitos, etc.). Muchas veces las estimaciones iníciales se hacen sobre requisitos muy ambiguos (un pliego de pocas líneas) y ahí se aplican PF ligeros o, por ejemplo, se estiman los casos de uso para aplicar puntos casos de uso, y siempre se trabaja con un error mayor de estimación (ver en el post de mañana el cono de incertidumbre y las unidades de estimación).

Estimado el tamaño, se estima el tiempo de proyecto (los meses de duración) y el esfuerzo (las horas hombre). Con los anteriores, ajustando el plazo en el que quiero terminar un proyecto, variando las personas que trabajarán en él, etc., se calcula el plan real (con fechas reales aproximadas) y el coste.

Sobre cómo dado un esfuerzo total (por ejemplo 12 meses hombre) y un tiempo de proyecto (me gustaría tener el proyecto en 4 meses) se ajusta el número de personas del equipo (por ejemplo si son 12 meses hombre, se puede suponer que poniendo 3 personas el proyecto durará 4 meses) habría que escribir otros cuatro post. Esto es uno de los puntos más serios y complicados, y donde más errores se comenten. Hay quien piensa que metiendo más gente tardará menos el proyecto, pero eso no es siempre así (hacer software no es poner ladrillos en una obra), ya que a más gente más organización y canales de comunicación, por lo que la relación no es directa. También se dice que no se puede bajar del 25% de la temporalidad estimada metiendo gente. Y en cualquier caso, ya os digo que esto es un tema de profundidad, y os recomiendo leer al respecto todo y cualquier cosa escrita por Brooks.

Enlace al post Estimación software, una breve introducción (4/4)

Javier Garzás

Javier Garzás

Ph.D. en informática, Postdoctorado en la Carnegie Mellon (EE.UU) e Ingeniero en Informática.

Primera vez que me tocó hacer una gestión Ágil en una empresa... año 2001. Desde entonces he trabajado en, o para, más de 90. Y he formado a más de 2000 alumnos.

También soy profe de la Universidad Rey Juan Carlos.
Javier Garzás

2 Comments

  1. Excelente post!!! me identifico con lo que dices de que donde mas errores se comenten es en pensar que si un desarrollo tarda cierto tiempo, incluyendo mas personas se puede terminar antes. Muchas veces me pedían estimar y luego me decían que incluyera a otro compañero en la tarea, pero eso requiere coordinación adicional, ademas, de que si trabajamos mas personar en un mismo desarrollo, implica mas cuidados en la integración de lo que desarrolló cada uno, que nos costo mucho tiempo que se creía, nos íbamos a ahorrar.

  2. Es bastante interesante y útil la información que nos presenta, muchas gracias por compartirla.

    Tengo una duda al respecto y me gustaría saber su opinión.
    Una vez realizada la estimación de costos por alguna de las técnicas propuestas. ¿Seria recomendable informar al cliente un costos con un porcentaje de holgura y cuál sería este porcentaje?

Trackbacks/Pingbacks

  1. Bitacoras.com - Información Bitacoras.com... Valora en Bitacoras.com: “No se puede controlar lo que no se puede medir” (Tom De Marco) Vistos…
  2. Una breve introducción a la estimación software. Recomendaciones y buenas prácticas (4/4) - Javier Garzás, sobre calidad software y otros temas relacionados - [...] Enlace al post Estimación software, una breve introducción (3/4) [...]
  3. Los puntos función. Una breve introducción a la estimación software (2/4) - Javier Garzás, sobre calidad software y otros temas relacionados - [...] Enlace al post Estimación software, una breve introducción (3/4) [...]

Post a Reply

Tu dirección de correo electrónico no será publicada.

Share This