C?mo determinar el costo y tiempo de un proyecto de software??

Interesante art?culo traducido al espa?ol por Leonardo De Seta (http://www.dosideas.com/noticias/desarrollo-de-software/746-como-determinar-el-costo-y-tiempo-de-un-proyecto.html) donde nos permite tener un panorama m?s amplio al momento de determinar el costo y tiempo de entrega de un proyecto de desarrollo de software…

Determinar el costo y tiempo de un proyecto de software es uno de los temas m?s importantes en el desarrollo de software. Mi opini?n seguramente va a ser pol?mica, y ac? est?:?es imposible determinar cu?l ser? el costo y el tiempo de un proyecto de desarrollo de software. M?s a?n, es muy mala idea intentar usar la planificaci?n como si fuera un contrato con nuestro cliente.

El Tri?ngulo de Hierrro es una muy buena analog?a para explicarlo. Lo que muestra el tri?ngulo es que en los proyectos de software (y, b?sicamente, en cualquier proyecto), asumiendo que la calidad queda est?tica (los proyectos siempre deber?an apuntar a tener la mayor calidad posible), hay otras tres variables en juego:?el Tiempo (qu? tan r?pido queremos entregar la soluci?n), el Costo (que tan barato queremos que sea el producto) y el Alcance (cu?ntas caracter?sticas queremos que tenga la aplicaci?n). Lo interesante es que estas tres variables dependen entre si, por lo que resulta imposible dar m?s prioridad a una sin quitarle a las dem?s.

Lo que hace que sea imposible determinar el costo y el tiempo de un proyecto es que es imposible conocer por completo el alcance de las caracter?sticas de la aplicaci?n desde el iniio, sin importar cu?nto an?lisis y recolecci?n de requerimientos hagamos (dije que iba a ser pol?mico). Y?sin estos datos, ?c?mo vamos a calcular los otros dos lados del tri?ngulo? Incluso cuando el costo es fijo, o el tiempo es fijo, es imposible calcular el otro v?rtice del tri?ngulo.

Para analizar m?s, supongamos que estoy equivocado y que realmente podemos determinar el Alcance de la aplicaci?n desde el inicio. Por lo tanto lo estimamos, y supongo que todos estamos de acuerdo en que la estimaci?n tan s?lo expresa una probabilidad;?cuando digo «estar? terminado en un mes», quiero decir algo como «hay un 80% de probabilidad de que termine en un mes». Cuando encadenamos las probabilidades (la estimaci?n de cada una de las caracter?sticas que formaban el Alcance), la probabilidad de acertar cae exponencialmente, lo que significa que incluso aunque conozcamos todas las caracter?sticas, la probabilidad combinada de acertar en todas las estimaciones es rid?culamente baja.

La planificaci?n continua

La soluci?n al problema es cambiar la perspectiva y mirar a la planificaci?n no como una actividad enorme que se hace al comienzo del proyecto, sino como una actividad continua que se realiza druante toda la vida del proyecto. Mientras m?s hayamos desarrollado la aplicaci?n, m?s podremos refinar nuestro plan.

Conclusi?n

Existe un c?rculo vicioso:?un proyecto de software no se aprueba hasta que se estime el costo y el tiempo, pero esto no se puede determinar porque reci?n conoceremos el alcance real de las caracter?sticas al momento de empezar a desarrollarlas. Igualmente, esto no debe impedirnos de empezar un proyecto y crear una estimaci?n inicial, y refinarla a medida que desarrollamos el producto. Pero tengan cuidado:?crear una planificaci?n inicial y usarla como un contrato va a afectar seriamente a todas las partes involucradas; es probable que el cliente no pueda hacer cambios durante el desarrollo, y el equipo de desarrollo trabajar? bajo presi?n para cumplir fechas, y al terminar el producto final no ser? lo que el cliente esperaba y su calidad ser? pobre.

Traducido de 😕How to determine the cost and schedule of a software project? The mythical BPUF (Big planning upfront), por Alberto Gutierrez.