Ingenieria De Software

Ingenieria de Software I

_____________________________________________________________________________________________________

UNIDAD IV

ESTIMACION Y PLANIFICACION TEMPORAL

DEL PROYECTO DE SOFTWARE

Contenido:

4.1 Introducción

4.2 Factores que influyen en el costo del software

4.3 El proceso de Estimación

4.4 Métricas del Software

4.5 Tecnicas de estimación de costos

• Juicio Experto

• Tecnica DELFI

• Método Histórico

• Modelo de Costos COCOMO

• Ecuación de Primer Orden de Jones

• Técnica Iterativa

4.5 Consejos sobre estimaciones

4.7 Calendarización

4.8 Especificación del Plan del Proyecto

Ingenieria de Software I

_____________________________________________________________________________________________________

4.1 Introducción

Algunas estimaciones se hacen cuidadosamente, pero otras simplemente se hacen a ojo. La mayoría de los proyectos rebasan sus límites de sus planes estimados de un 25 a un 100%, son muy pocas las organizaciones que han logrado realizar una predicción con una precisión de un 10%.

Una estimación precisa del plan de desarrollo constituye una de las bases para obtener una velocidad máxima de desarrollo.

Ejemplo. Estimación de proyectos a ojo

Carl había sido encargado de la versión 1 del sistema de control de Inventario de Giga Safe (SCI). Tenía ideas generales sobre las funciones deseadas cuando asistió a la primera reunión del comité de supervisión del proyecto. Bill era el responsable principal del comité de supervisión. “Carl, cuánto durará el SCT 1.0?», preguntó.

“Creo que tardará unos 9 meses, pero sólo es una estimación a ojo” dijo Carl.

«No puede tardar tanto», dijo Bill. «Esperaba que dijera 3 o 4 meses. Necesitarnos absolutamente tener el sistema dentro de 6 meses ¿Puede hacerlo en seis meses?»

«No estoy seguro», dijo Carl honestamente. «Tendría que mirar el proyecto con más detalle, pero puedo intentar tenerlo en 6 meses.»

«Entonces considero un plazo de 6 meses», dijo Bill. «De todas maneras, eso es lo que tenía que ser.» El resto del comité asintió.

Pasadas 5 semanas, el trabajo adicional realizado sobre el concepto del producto había convencido a Carl de que el proyecto iba a necesitar más bien los 9 meses iniciales, en vez de en 6 meses, pero pensó que con un poco de suerte aún podría estar finalizado en 6 meses. El no deseaba consideraran como una persona problemática, de forma que decidió apretarse el cinturón.

El equipo de Carl hacía grandes progresos, pero el análisis de requerimientos necesitó más tiempo de lo que se esperaba. Llevaban casi 4 meses de lo que se suponía un proyecto de 6 meses. «No hay forma de realizar el resto del trabajo en 2 meses», le dijo a Bill. Carl le comentó a Bill que llevaban un retraso de dos meses respecto a la planificación y que el proyecto tardaría 8 meses.

Unas semanas más tarde, Carl comprobó que el diseño tampoco se estaba realizando tan rápidamente como se esperaba. «Implementen las partes que se puedan hacer rápidamente», le dijo al equipo. «Nos preocuparemos del resto de las partes cuando lleguemos a ellas,»

Carl se reunió con el comité de supervisión. «Vamos por el séptimo mes de los 8 que dura el proyecto. El diseño detallado está casi finalizado, y se van haciendo grandes progresos. Pero no podemos terminar el proyecto en los 8 meses.» Carl anunció su segundo aplazamiento, esta vez a 10 meses. Bill se quejó y requirió a Carl que buscara formas de volver a la planificación de 8 meses.

Al límite del noveno mes, el equipo había finalizado el diseño detallado, pero la codificación de algunos módulos aún no había comenzado. Estaba claro que Carl tampoco podría cumplir la planificación de los 10 meses. Anunció un tercer aplazamiento (a 12 meses). Cuando Carl le anunció el aplazamiento, la cara de Bill se puso roja, y la presión llegó a ser más intensa. Carl empezó a sentir que su trabajo estaba en juego.

Ingenieria de Software I

_____________________________________________________________________________________________________

La codificación iba bastante bien, pero unas cuantas partes necesitaban volver a ser diseñadas e implementadas. En esas partes, el equipo no había coordinado bien los detalles del diseño, y algunas de sus implementaciones entraban en conflicto. En la reunión de los 11 meses del comité de supervisión, Carl anunció el cuarto aplazamiento, a 13 meses. Bill se quedó lívido. «¿Tiene alguna idea de lo que está haciendo?», le dijo a gritos. «¡Obviamente no tiene ni idea! ¡No tiene ni idea de cuándo va a terminar el proyecto! ¡Ahora mismo le voy a decir cuándo va a estar terminado! ¡Va a estar terminado en 13 meses, o lo voy a despedir! ¡Estoy cansado de ser manipulado por los tipos del software! ¡Usted y su equipo van a trabajar 60 horas a la semana hasta que terminen!»

Carl sintió cómo subía su presión arterial, especialmente porque Bill insistió en la planificación tan poco realista que habían hecho al principio. Pero él sabía que con cuatro aplazamientos en su haber, había perdido toda credibilidad. Sabía que tendría que hacer horas extras a la fuerza o le echarían del trabajo.

Carl le comentó a su equipo lo que sucedió en la reunión. Ellos trabajaron duro y consiguieron entregar el software en 13 meses. La implementación adicional no cubrió los flecos del diseño adicional, pero trabajando todo el mundo 60 horas a la semana, a sangre y fuego, entregaron el producto.

Naturaleza de la estimación del software

La estimación de software es difícil. Los jefes, directivos, clientes y desarrolladores no parecen entender porqué la estimación es tan difícil.

El argumento básico de la estimación de software es que es un PROCESO DE REFINAMIENTO GRADUAL.

Se comienza con una imagen borrosa de lo que se desea construir y se pasa el resto del proyecto intentando aclarar esa imagen. La estimación del tiempo y el esfuerzo necesarios para desarrollar el software es también borrosa.

¿Cuánto cuesta desarrollar un sistema de facturación ?. Depende de cómo sea.

No se puede estimar con precisión el costo de un programa hasta que se comprendan con detalle cada una de las funciones que realizará el sistema. La incertidumbre sobre la naturaleza del producto aporta incertidumbre a la estimación.

Ingenieria de Software I

_____________________________________________________________________________________________________

4.2. FACTORES QUE INFLUYEN EN EL COSTO DEL SOFTWARE

La estimación de

...