La Estimaciones

LAS ESTIMACIONES – RESUMEN (Conrado Estol)

ÍNDICE

Tema 1: Introducción General

1. Antecedentes

2. Definiciones

3. Problemas en el proceso de estimación.

3.1. Problemas Generales

3.2. El sesgo optimista.

3.3. Un problema específico: La ausencia de un verdadero proceso de estimación

3.4 Ausencia de registros históricos.

4. Puntos a tener en cuenta para realizar mejores estimaciones

5. Conclusión

Tema 2: Consideraciones Básicas (¿Cuándo un mes hombre es un mes hombre?)

1. Introducción.

2. Horas nominales versus horas efectivas de trabajo.

3. La productividad y el tamaño de los grupos de trabajo (El Costo Fijo de las Comunicaciones)

Tema 3: Estimación de tamaño

1. Caveat Emptor!

2. La relación entre LOC y PF y la productividad.

3. Posibles problemas con LOC.

4. Puntos de Función:

5. “Backfiring” de PF

Tema 4: La Ecuación de Software de Putnam

1. Introducción:

2. Productividad del Proceso

3. Cantidad de personal requerido.

4. El intercambio entre esfuerzo y plazo

Apéndice: Bases para el control gerencial de los proyectos de desarrollo de software.

ANEXOS

A - Análisis con puntos de función

B - COCOMO (B. Boehm).

1. Introducción.

2. COCOMO 81.

Nota sobre COCOMO II

El modelo Walston-Felix.

C- EL MÉTODO MANUAL (“SIMPLE”) DE PUTNAM

1. Calibración.

2. Tamaño.

3. Estimaciones

D - TECNICA DE HORAS-HOMBRE ESTANDAR PARA PROGRAMACIÓN - Ejemplo

E - TECNICA BASADA EN LA DURACION DE ENTREVISTAS.

G - TÉCNICA “DELPHI”

Estimaciones – Resumen por Conrado Estol 1 de 1

Tema 1: Introducción General

1. Antecedentes

La realización de estimaciones adecuadas sobre el tamaño y esfuerzo requerido es una

de las características fundamentales de un proyecto de desarrollo de software exitoso

(de hecho, de cualquier proyecto). Como contrapartida, las malas estimaciones o más

comúnmente las no estimaciones, son posiblemente una de las principales causas de

los fracasos. Por lo menos, del ya clásico” incumplimiento de plazos y presupuestos en

la entrega de aplicaciones de computador. En muchas organizaciones (o en la

mayoría...) la no existencia de un proceso estructurado para la preparación de

estimaciones de tamaño, de esfuerzo, de costo, de calidad, hace imposible, o por lo

menos muy difícil, llegar a definir equipos de trabajo de magnitud adecuada, y plazos de

cumplimiento razonables. Además, la no existencia de registros de proyectos realizados

en el pasado contribuye fuertemente a esa situación de descontrol en cuanto a la

determinación del esfuerzo y plazo requerido para cumplir con un determinado proyecto.

Como decía Santayana (1), “los que no conocen el pasado están condenados a

repetirlo...”.

Muchísimas veces, en áreas de sistemas de distintas organizaciones, en distintos

países, alguien pregunta: “¿Puedo ver la información de tamaño, esfuerzo aplicado y

plazo empleado para algunos proyectos anteriores?” Y la respuesta, la gran mayoría de

las veces, ha sido “No la tenemos documentada, pero podemos llamar a ...... que

participó en ese proyecto”. Esto quiere decir que la empresa en ese momento se pone

en las manos – o en la memoria – de ese alguien que podrá o no recordar bien las

cosas. De todas maneras, aunque las recuerde, ese recuerdo será sólo una visión

personal, subjetiva, quizás sesgada, generalmente no confiable, de como sucedieron las

cosas (En un estudio de Lederer y Prasad que se comenta más adelante – 13 – se

recomienda específicamente a los estimadores no confiar en su memoria, que es lo que

hacen comúnmente, sino confiar en hechos documentados, en estándares y en

fórmulas).

Pero la situación es aun peor. Me explico: Lo que uno percibe en ese momento no es

sólo que no existe documentación de las mediciones que uno pide, sino que no existe un

proceso de medición. ¿Cómo se pudo haber pretendido estimar algo si al mismo tiempo

no se estaba midiendo? El proceso de medición está inextricablemente unido al proceso

de estimación. Sólo en la actividad de desarrollo de software es posible que haya gente

que se haga la fantasía de que puede estimar algo del futuro aunque nunca haya medido

nada en el pasado (2)

Como también dice DeMarco (3), la estimación de tiempos y personal requerido para el

desarrollo de sistemas es el elemento esencial de las dificultades que se presentan en

el control de los proyectos de software. Los "ingenieros" de software, y en general los

profesionales de sistemas, son notorios por sus malas dotes de estimación.

Parecería que la mayoría de las personas que se dedican al desarrollo de sistemas

íntimamente definen la estimación de tiempos (o costos) como "la predicción más

optimista con una probabilidad de ocurrir mayor que cero" (4).

Estimaciones - Conrado Estol - 2 de 2

En el presente trabajo se comentan modelos o técnicas discutidos en la literatura, y

utilizados en la práctica, aunque en general poco frecuentemente, según el país y la

organización de que se trate.

A continuación se indica el contenido general de los puntos que siguen:

El punto 2 contiene definiciones de lo que entendemos por estimación. El punto 3 indica

algunos de los problemas que dificultan el proceso de la estimación. El punto 4 contiene

una conclusión preliminar sobre el problema de las estimaciones. Finalmente, el punto 5

contiene una recomendación con los pasos a seguir para la realización de estimaciones.

Luego, en capítulos separados se incluye la descripción de técnicas para la estimación

de tamaño y de esfuerzo, de entre las cuales se deberán elegir las que se evalúen como

más convenientes para un ambiente específico.

2. Definiciones

Para nuestro uso usaremos la palabra estimación en el sentido del "proceso de llegar a

una idea de una cantidad o magnitud

...