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 sin realizar una enumeración o medición detallada"

(5).

Una estimación es una predicción basada en un modelo probabilístico, no un modelo

determinístico; es decir, la cantidad que se está estimando puede tomar no solamente

un valor sino distintos valores, con algunos de ellos con mayor probabilidad (de ser

correctos) que otros.

En resumen, entonces, podríamos decir que una estimación es "una aproximación

estadística a la realidad" (como se postula como paradigma en una Guía para la

Estimación (6). O que una estimación es una predicción que tiene igual probabilidad de

estar por encima o por debajo del resultado real (7).

Los pasos básicos en el proceso de estimación de proyectos de software son los

siguientes:

1. Estimación del tamaño del producto que se va a desarrollar, o a implantar. Hay

distintas formas de estimar ese tamaño. Las más comunes son Cantidad de

Instrucciones (o Miles de Líneas de Código: KLOC – Kilo Lines of Code) y Puntos

de Función.

2. Estimación del esfuerzo requerido para el desarrollo del proyecto en tiempo-

hombre (normalmente en meses-hombre o, mejor aun (pienso yo), en horas-

hombre. Del esfuerzo surge comúnmente el costo, ya que típicamente (aunque

no siempre) el costo de la mano de obra será el costo principal en los proyectos

de desarrollo.

3. Estimación del plazo de realización del proyecto, normalmente en meses.

3. Problemas en el proceso de estimación.

3.1. Problemas Generales

A qué se deben los serios problemas que se presentan con las estimaciones en el

desarrollo de sistemas? Se pueden enumerar los siguientes (8, 9) :

Estimaciones - Conrado Estol - 3 de 3

-No se tiene en general un adecuado conocimiento de lo que debe ser una estimación;

-No se desarrollan o cultivan las habilidades requeridas para hacer estimaciones

razonables;

-No se toman recaudos para compensar el efecto de nuestros prejuicios y sesgos

"optimistas";

-No se manejan bien los problemas políticos que dificultan el proceso de la estimación;

-No se quiera entrar en situaciones de potencial conflicto con superiores jerárquicos;

-No se piensa en uno o dos años en el futuro;

-No se utilizan normalmente como base de referencia casos anteriores (experiencias

anteriores).

En muchos casos, por ejemplo, en una estimación determinada se incluye el tiempo de

programación en un proyecto pero no el altamente significativo tiempo necesario para

las pruebas de todo tipo (unitarias de módulos o programas, de integración, de

regresión,

...