LAS ESTIMACIONES

Por 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 – 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, de aceptación) que son necesarias. Muchas veces se actúa en forma similar
con respecto a la documentación.

También es común ver que se suponga una relación lineal entre el tamaño del proyecto
entre manos y la cantidad de recursos humanos requeridos. Se ignora, por ejemplo, los
importantes requerimientos adicionales de comunicación que se presentan en los
proyectos de mayor magnitud, y que hacen que disminuya la productividad de los
equipos de trabajo.

Los que estiman muchas veces basan sus cálculos de productividad en personal ideal y
no en la realidad del personal realmente disponible.

Debe tenerse en cuenta que contar con "personal apto" no es lo mismo que contar con
"el mejor personal disponible". Es sabido que la gente difiere enormemente en su
productividad.

Brooks decía hace más de veinte años (10) que era bien reconocida la existencia de
amplias variaciones entre los buenos y los malos programadores. Comentaba, no
obstante, que las experiencias que se habían realizado mostraban resultados aun más
extraordinarios de los que se había imaginado. En ese sentido, cita estudios en los que
la relación entre mayor y menor productividad era de 10 a 1 (También se pueden
encontrar citas similares en otros muchos autores). Estudios más recientes (11) indican
que las diferencias promedio en los EE.UU. son del orden de 1 a 4.

Normalmente, existe una fuerte presión sobre el plazo en que se deberá realizar el
proyecto. He formado parte de reuniones en las que un Gerente con mucha autoridad le
decía a su responsable de sistemas que el proyecto XX (y el proyecto quedaba
aparentemente YA totalmente definido por un nombre o descripción genérica) debería
estar listo indefectiblemente para dentro de 10 meses, por ejemplo. Y entonces el
responsable de sistemas rápidamente contestaba que eso era imposible y que no podría
tardarse menos de 18 meses. A lo que el Gerente, luego de un diálogo más o menos
prolongado, contestaba que estaba dispuesto a esperar 12 meses, pero no más. Y
entonces, a su vez, el Gerente de Sistemas bajaba su máximo a 16 meses... Fin de la
historia, una especie de transacción de mercado persa, en la que en sucesivas
“concesiones” se llegaba a un punto intermedio. Lo particularmente interesante de una

Estimaciones - Conrado Estol - 4 de 4

situación de ese tipo es que normalmente ni uno ni otro interlocutor tiene base alguna
para estimar que el proyecto pueda realizarse en 10, 16 o 20 meses.

El proceso podría llegar a ser uno de negociación, pero el Gerente de Sistemas, o el

Gerente del Proyecto, debería haber contado con algún tiempo mínimo para poder
realizar – o hacer realizar – estimaciones que le dieran un respaldo a su proyección de
cuánto tiempo podría demandar la ejecución del proyecto. Por supuesto, estimaciones
basadas en alguna razonable definición de requerimientos y en técnicas o modelos (no
uno solo) también razonables y “repetibles”. Y la palabra “repetible” tiene aquí (como en
el caso del CMM: Capability Maturity Model) un sentido y una importancia muy grandes.

Sólo se debe “negociar” un plazo cuando hay elementos que permitan sustentar la
estimación que se está manejando. Y sólo se debe aceptar un compromiso cuando se
ha tenido el tiempo suficiente para llegar a esa estimación razonable en base al estudio
de las variables que son de importancia en esos casos.

Cuando se plantea “desde arriba” un plazo cualquiera, o un compromiso (y e esto, como

en otras muchas cosas, vale la pena leer lo que Humphrey tiene que decir; referencia
12), que la mayor de las veces es “voluntarista”, la posición del Gerente de Sistemas o
del Gerente del futuro proyecto debiera ser la de decir – y esto no siempre es fácil - “No
sé; permítame analizar los elementos de juicio que existen y realizar una estimación, y le
daré entonces una respuesta...” Por supuesto, esto parte de la base que se ha
establecido un diálogo con una persona razonable (Hay pocas defensas posibles contra
la gente irrazonable).

3.2. El sesgo optimista.

Es posible realizar distintos “experimentos” (conocidos y mencionados en la literatura;

por ejemplo ver De Marco) para demostrar la existencia de un definido sesgo hacia la
realización de estimaciones optimistas.

En muchos experimentos de este tipo realizados, al presentar los resultados, estos

siguen siempre la misma tendencia. En el caso de experimentos sobre estimación de
tiempos para hacer algo la mayoría de las respuestas revelan una mayor probabilidad de
exceder el plazo estimado y una menor probabilidad de poder acortarlo.

La conclusión es que cuando se realiza la estimación se utiliza una definición errada de

lo que es “estimar”. El tiempo “estimado” resulta ser ya un “menor tiempo posible”, de
manera que al pedir la probabilidad de excederlo resulta fácil asignarle una “Alta”
probabilidad a ese hecho, y una “Baja” probabilidad a que ese tiempo se acortase.

Decididamente NO se emplea la definición que mencionábamos más arriba de que una

estimación es una predicción que tiene igual probabilidad de estar por encima que por
debajo del resultado real.

Estimaciones - Conrado Estol - 5 de 5

 Tiempo
"Estimación"
realizada Verdadera
Estimación

Conclusiones: 1) a realizar una estimación razonable se necesita un cierto tiempo

mínimo. 2) vez que han hecho una estimación muchas personas NO quieren cambiarla.

Aun en los casos en que se vea como "aceptable" hacer una nueva estimación, mucha
gente puede NO hacer un real esfuerzo o intento para llegar a lo que sería realmente una
NUEVA estimación. Por ejemplo, la revisión de la estimación anterior puede basarse en
lo que se cree o percibe que otros (superiores, usuarios, clientes) QUIEREN oír / ver y
no en un verdaderamente nuevo ejercicio de estimación.

Por ejemplo, si del control realizado en un proyecto determinado se ve que existe un

atraso significativo en la marcha del proyecto pero se "sabe" que el Gerente / usuario /
cliente sólo aceptará un desvío de un 20 % como máximo puede llegar a pensarse:
¿para qué preocuparse o molestarse en realizar una nueva estimación?

Esa actitud no sólo implica seguir adelante con información errónea (y no tener la
oportunidad de tomar las medidas necesarias para corregir la situación) sino que
además se pierde una oportunidad más para practicar el arte / técnica de la estimación.

Una variante de esta forma de "no estimar" es la de la "negociación" de un plazo. El

"cliente" (Gerente, usuario, real cliente) tiene un plazo preconcebido o predefinido de X
meses e insiste en su cumplimiento. El Gerente del Proyecto de software le dice que en
realidad necesita 2X para realizar ese proyecto; el cliente entonces cede pero diciendo
que no puede "dar" más de 1,5X; el Gerente del Proyecto contesta que es imposible en
menos de 1,8 X meses; el cliente dice entonces que su última "oferta" es de 1,6 X
meses y en ese punto el Gerente del Proyecto acepta el compromiso. Evidentemente,
cuando tiene lugar un proceso como el descrito se está haciendo cualquier cosa menos
"estimar".

Estimaciones - Conrado Estol - 6 de 6

La conclusión a que se quiere llegar aquí es que en realidad la mayoría de los Gerentes
de Proyecto NO hace muchas estimaciones; se trata más bien de adivinar las
expectativas de otras personas y de compatibilizarlas de alguna manera con las propias
expectativas, o de entrar en procesos de "negociación" para llegar a término medios
entre exigencias de terceros y propias expectativas, ideas o percepciones.

Otra posibilidad, también comentada por DeMarco, es que la nueva estimación se hace
de manera tal que con voluntarismo se "estima" un desvío futuro NEGATIVO que
compensará el desvío que se haya podido producir en el lapso desde la estimación o
punto de control anterior.

Es decir, existe una cierta tendencia optimista a suponer que en la siguiente fase del
proyecto se recuperará cualquier retraso que se pueda haber producido en la fase
anterior. Puede decirse a priori que este enfoque NO es el que corresponde a una
verdadera estimación.

Es importante destacar la clara existencia de SESGOS, o tendencias, en la estimación.

Normalmente, se puede apreciar una tendencia hacia las estimaciones "optimistas", es

decir, un sesgo hacia subestimar los tiempos requeridos para finalizar un proyecto
determinado. El problema aquí es que los mismos mecanismos mentales que tienden a
producir esos sesgos tienden también a ocultarnos su misma existencia (de manera
que es difícil tenerlos en cuenta y aplicar factores de corrección).

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

Una de las razones por las que la gente hace malas estimaciones es la falta de práctica
y la falta de método y conocimiento con respecto a cómo hacer estimaciones.

Un proyecto típico de software requiere una estimación inicial (como parte de la

"propuesta" o documentación de justificación del proyecto) y luego nuevas estimaciones
periódicas (cuya frecuencia dependerá, por supuesto, de la extensión del proyecto en el
tiempo). Usualmente, el tiempo asignado para ese proceso es insuficiente.

Para peor, lo que se denomina "estimación" normalmente no es lo que debería ser sino
que el verdadero proceso de realizar una estimación se reemplaza - por no
disponibilidad de tiempo o por prejuicios o sesgos personales - por distintos substitutos
inadecuados.

La conclusión a que quiero llegar es que en realidad la mayoría de los profesionales de

sistemas y Líderes o Gerentes de Proyecto no hace muchas estimaciones; se trata más
bien de encontrar analogías más o menos razonables con otros proyectos, o - en ciertos
casos - de adivinar las expectativas de otras personas y de tratar de compatibilizarlas de
alguna manera con las propias expectativas, o de entrar en procesos de "negociación"
para llegar a términos medios entre exigencias de terceros y propias expectativas, ideas
o percepciones.

Ese enfoque optimista se puede apreciar normalmente en una tendencia hacia

estimaciones que se "quedan cortas", es decir, un sesgo hacia subestimar los tiempos
requeridos para finalizar un proyecto determinado. El problema aquí es que los mismos

Estimaciones - Conrado Estol - 7 de 7

mecanismos mentales que tienden a producir esos sesgos tienden también a ocultarnos
su misma existencia (de manera que es difícil tenerlos en cuenta y aplicar factores de
corrección).

Aquí hay una solución que puede ser obvia: Es imprescindible llevar registros adecuados
de todas las estimaciones realizadas y, más tarde, de lo que realmente ha sucedido con
el esfuerzo requerido para la realización del proyecto, con los plazos, con la calidad.

3.4. Ausencia de registros históricos.

Los problemas relacionados con el proceso y técnicas de la estimación se ven

complicados, en general, por la ausencia de registros (archivos, base de datos)
relacionados con experiencias anteriores en el desarrollo de proyectos de sistemas. En
la Argentina, por ejemplo, se cuenta con casi cuarenta años de historia desde la
instalación de los primeros computadores "comerciales" en forma más o menos amplia
(el modelo 1401 de IBM) y más si tenemos en cuenta equipos como los 650 de IBM o los
de Univac y otros. No obstante, es muy raro encontrar registros históricos relacionados
con el esfuerzo, tiempo y costo empleados en el desarrollo de aplicaciones
computadorizadas. Y en aquellos pocos, poquísimos, casos en que se encuentra algo,
lo más probable es que existan serias omisiones.

La información faltante en esos casos excepcionales en que hay alguna información,

está relacionada por ejemplo con el esfuerzo no contabilizado de documentación, de
realización y depuración de pruebas de programas y del sistema final, de preparación de
esas pruebas, de participación de los usuarios (en el relevamiento, análisis, pruebas,
capacitación), inclusive de horas extra invertidas (y pagadas) principalmente durante la
implementación, y hasta del seguramente importante tiempo de administración del
proyecto. Es así que aun para aquellas pocas organizaciones en las que se encuentran
datos históricos de referencia, muy frecuentemente existen falencias que concurren a
ocultar la verdadera imprecisión de las estimaciones realizadas.

Se requiere por lo tanto la implantación de un sistema de registros de utilización del

tiempo por persona (preferentemente diario, en línea, con acumulaciones y controles
semanales, quincenales, mensuales). Deben estar codificadas las personas, los
proyectos, las fases del ciclo de vida del desarrollo de sistemas utilizado, las actividades
no directamente relacionadas con la producción de sistemas (capacitación, lectura de
manuales, vacaciones, ausencias, enfermedades). Debe además implantarse un
sistema de registro de las estimaciones realizadas y de las características específicas
de cada proyecto.

4. Puntos a tener en cuenta para realizar mejores estimaciones

En primer lugar debe tenerse presente que no puede existir un razonable proceso de
estimación si no se cuenta también con un proceso de mediciones. Parece una
perogrullada, pero no obstante me he encontrado muchas veces frente a profesionales
que me hablaban de las técnicas de estimación que se utilizaban en sus
organizaciones, en las cuales – sin embargo – no existían programas de métricas
funcionando. ¿Cómo es posible estimar si al mismo tiempo no se mide para saber cuán
cerca de la realidad están o han estado esas estimaciones?

Estimaciones - Conrado Estol - 8 de 8

Una idea que parecería dar buenos resultados – y que además parece tener lógica - es
asignar a miembros del equipo de desarrollo la tarea de las primeras estimaciones. Pero
podríamos fácilmente pasarnos al otro lado
De esta cuestión si leemos el Capítulo 3 de esa excelente obra que es Controlling
Software Projects de Tom De Marco, donde el autor justamente argumenta, con sólidas
explicaciones, la separación de la función de estimación del resto del desarrollo. No sólo
eso, sino la especialización del papel de estimador y la creación de un grupo de
estimadores con responsabilidad de la estimación de todos los proyectos, sin influencia
por parte de los gerentes o líderes de esos proyectos.

El planteo, debe decirse, está muy razonablemente respaldado por Tom DeMarco. Pero
es evidente que por lo menos en la generalidad de nuestro medio no sería nada fácil
llegar a esa solución simplemente por el costo que representaría esa especialización,
sólo factible en grupos muy grandes de desarrollo, poco comunes. Si bien, para
DeMarco los estimadores deberían ser los responsables también de todas las
mediciones, lo cual haría ya más factible la implantación práctica de esa alternativa.

Personalmente, me encuentro en teoría muy cómodo con ese enfoque y con la

justificación del mismo. Pero al mismo tiempo debo citar un trabajo realizado por
Lederer y Prasad (13) en 1992. En ese estudio de los procedimientos para la estimación
de costos de 115 gerentes y profesionales en computación.

Los autores encontraron que la asignación de la estimación inicial a los encargados del
desarrollo estaba asociada con mejores estimaciones. Concretamente, esa
combinación aseguraba una menor cantidad de presupuestos excedidos. Los autores
atribuyen una potencial explicación de ese hecho al compromiso que se genera con la
terminación del proyecto en tiempo. Otra razón para que los estimadores no
involucrados en el desarrollo produzcan estimaciones no tan buenas es que puedan
estar deliberadamente suponiendo que estimaciones más optimistas tienen mayores
probabilidades de ser aprobadas (y ellos no son personalmente responsables por el
cumplimiento de esas estimaciones). De esta conclusión debería surgir la
recomendación de asignar la estimación inicial a quienes serán los responsables finales
del desarrollo.

Posiblemente, en aquellos casos en que fuese factible económicamente, no sería malo

adoptar ese procedimiento para contrastarlo con estimaciones realizadas por el grupo
de métricas que sería sano y aconsejable tener en esos casos como parte de la función
de sistemas.

Otra de las observaciones surgidas del estudio mencionado anteriormente fue que las
sucesivas revisiones de las estimaciones no parecieron tener mucha influencia en su
mejora. La conclusión es que se debe enfatizar la necesidad de que las primeras
estimaciones sean tan exactas como posible. Al mismo tiempo, esto implica que no se
debiera difundir la primera estimación hasta que no se ha ya obtenido suficiente
información válida como para hacerla. Puede ser interesante citar algunos de los datos
relacionados con las causas de estimaciones no exactas, donde el valor asignado a
cada punto surge de una escala que va de 1 a 5 (hemos tomado solamente las causas
con valores superiores a 3,0):

Estimaciones - Conrado Estol - 9 de 9

 Causa Grado de Responsabilidad
Frecuentes solicitudes de cambios por usuarios 3,90
Actividades pasadas por alto 3,61
Falta de comprensión por los usuarios de sus
propios requerimientos 3,60
Insuficiente comunicación entre usuarios y 3,36
analistas
Mala o imprecisa definición del problema 3,35
Insuficiente análisis al desarrollar la estimación 3,24
Falta de coordinación durante el desarrollo 3,12
Ausencia de una adecuada metodología o guías
para la estimación 3,10
Por último, vale la pena mencionar un resultado paradójico de la encuesta de Lederer y
Prasad. Un 84 % de las respuestas coincidieron en que la estimación de costos era
“muy importante” o “moderadamente importante” (los valores 4 y 5 de la escala de 1 a
5). Sin embargo, un 77% de los que respondieron a la encuesta reconocieron que las
estimaciones eran significativamente distintas de la realidad (menos de un proyecto de
cada cuatro finalizaba con un costo razonablemente cercano a la estimación realizada).
Sin embargo, y a pesar del resultado aquí comentado, sólo un 35% de las respuestas
indicaron que estaban “moderadamente insatisfechos” o “muy insatisfechos” (valores 1
y 2 de la escala) con los procesos de estimación que utilizaban... El valor promedio de
las respuestas fue de 3,02. Es decir, que aparentemente los gerentes y profesionales
que contestaron la encuesta si bien no estaban muy satisfechos con sus estimaciones,
tampoco estaban muy insatisfechos. Eso a pesar de la falta de correlación entre sus
estimaciones y la realidad, y pese a que consideraban que la realización de
estimaciones era muy importante. ¿Qué conclusión puede extraerse de esas
respuestas, aparentemente no muy consistentes entre sí? ¿Qué así es la vida y hay que
resignarse? O que quizás el verdadero propósito de esas estimaciones no era obtener
un valor realista, un valor que se espera lograr, sino un valor que se simula o se “hace
de cuenta” que se puede llegar a lograr, sabiendo que no será así (consultar De Marco,
14).

5. Conclusión

En general existe un mal concepto de lo que significa realmente "estimar". Aunque se

acepte la idea de que una estimación tiene características probabilísticas, no existe el
concepto de cuantificación de esa probabilidad. Las estimaciones tienden a ser el valor
más optimista de los valores realmente posibles. De allí que se pueda percibir y
explicitar una cierta probabilidad para que un proyecto se extienda en el tiempo (o costo)
más allá de la estimación dada, pero no de que se acorte, es decir, que se complete en
menos tiempo.

Para poder llegar a mejores resultados en la estimación se requiere contar con mejores
datos de entrada al proceso; se requiere contar con métricas (medidas o elementos de
medición). Es decir, indicadores cuantificables de alcance, calidad, complejidad y
rendimiento (Esto, a su vez, permitiría desarrollar un sistema de evaluación de la
productividad).

Estimaciones - Conrado Estol - 10 de 10

Debe tenerse en cuenta que la estimación del esfuerzo requerido para el desarrollo de
un sistema es un proceso iterativo. Y ese proceso se hace más preciso cuanto mayor
es el detalle a que se llega en el planeamiento y cuanto más estructurado – y “repetible”
– se hace el proceso general de estimación a través de técnicas y modelos
generalmente aceptados.

El objetivo del estimador debería ser utilizar pautas o modelos objetivos y cuantitativos
para estimar el tamaño de una aplicación, el esfuerzo requerido para su desarrollo, y el
plazo necesario para su finalización. Un requerimiento inicial es el de determinar qué
indicadores utilizar en cada etapa o fase del proyecto. El indicador es una variable
objetiva, cuantitativa que se puede usar para predecir el costo que representará elaborar,
por ejemplo, un programa. Por ejemplo, para estimar el tamaño de una aplicación se
podrían citar tres ejemplos de indicador; 1) cantidad de líneas de programa; 2) cantidad
de elementos en una Base de Datos; 3) funciones requeridas.

En última instancia, la buena estimación del tiempo-hombre requerido para un desarrollo

de sistemas depende en buena medida de tres factores principales, a saber:

1.- La disponibilidad de registros precisos sobre proyectos anteriores,

2.- El uso de técnicas de estimación adecuadas, y

3.- La utilización de procedimientos bien definidos y repetibles para el desarrollo

de sistemas (es decir, la adopción de una metodología estándar).

Es necesario tener presente que los modelos de estimación existentes presentan

distintos problemas que originan muchas veces grandes diferencias entre lo
pronosticado y la realidad. Por lo tanto, se debe tratar de obtener una mejora
permanente en las estimaciones realizadas. Esto se puede lograr definiendo un proceso
de estimación que tenga en cuenta los siguientes puntos:

- Uso de por lo menos dos técnicas que puedan ser verificadas, o contrastadas,
una con otra;

- Realización de nuevas estimaciones durante el proyecto, a medida que se

cuenta con más información sobre el sistema;

- Re alimentación de información sobre cada proyecto para poder mejorar la

exactitud de los modelos de estimación empleados y "calibrarlos" (o adecuarlos)
al ambiente específico de trabajo;

- Re alimentación de información sobre cada proyecto para mejorar la habilidad

de los estimadores.

La utilización de técnicas de estimación requiere para su éxito que su implantación se

haga cuidadosamente. Debe tratarse de un esfuerzo iniciado con verdadera convicción y
acompañado de procedimientos que aseguren el uso permanente de esas técnicas.
Asimismo, dicho esfuerzo debe estar precedido por la implementación de un sistema
para el registro del tiempo aplicado por el personal a la realización de distintas tareas
(que NO debe ser percibido como un sistema de control INDIVIDUAL de la productividad,

Estimaciones - Conrado Estol - 11 de 11

aunque ése pueda ser un sub producto). También debería acompañarse este proceso
con un sistema de verificación de la calidad (o de "mejora permanente" de la calidad).
Todo esto, por supuesto, implica una considerable inversión que debe ser tenida en
cuenta para que la decisión de seguir adelante se haga sobre bases sólidas.

Existen, como se ha dicho, distintas técnicas para la estimación de tamaño, esfuerzo,

plazos requeridos para proyectos de desarrollo de aplicaciones. Esas técnicas deben
ser cuidadosamente analizadas y evaluadas con el fin de seleccionar aquellas que mejor
se adapten al ambiente de desarrollo propio, aunque utilizando datos históricos, y
realizando las calibraciones necesarias.

Algunas técnicas o unidades utilizadas comúnmente para realizar estimaciones son las
siguientes:

Para tamaño: Puntos de Función, Cantidad de Instrucciones (KLOC)

Para esfuerzo: COCOMO (COst COnstruction MOdel), la Ecuación de Software

de Putnam, técnica basada en "estándares de programación", técnica de
extrapolación (tomando por ejemplo como base el esfuerzo requerido para
completar entrevistas), Método “Delphi”, y otras.

Las técnica comentadas, o variantes de las mismas, son posiblemente las técnicas
“formales” más usadas en los EE.UU. y Gran Bretaña y las más comentadas en la
literatura, aunque eso no significa que constituyan "estándares" aceptados.

En cuanto a lo que posiblemente se usa más, en general, habría que hacer referencia a
la técnica de la “analogía” (este proyecto que tenemos que desarrollar, ¿a cuál se
parece de los que hayamos realizado antes, o en los que alguno de nosotros haya
intervenido antes?). Los resultados dependerán aquí fundamentalmente de la existencia
de documentación que permita realmente comparar funcionalidad y características del
entorno, y de los ajustes que se realicen para adecuar una o varias situaciones
anteriores a la presente.

Otra técnica muy simple que se ha visto aplicar en el pasado es la estimación del
tiempo-hombre requerido para programación, y en base a ese esfuerzo extrapolarlo a
todo un proyecto mediante los esquemas utilizados en las técnicas que denominamos
de “extrapolación”."

Como base para esa extrapolación se ha utilizado en distintos medios (por ejemplo
algunos consultores y empresas) la fase de entrevistas para el relevamiento inicial. Esa
información esta disponible al comienzo mismo del proyecto y puede resultar de
aplicación relativamente sencilla. Como todas las demás requiere de una "calibración" y
ajuste al ambiente de sistemas específico donde será utilizada.

En los siguientes puntos se incluye la descripción de algunas de las técnicas

mencionadas. Para obtener mayor información sobre ésas u otras técnicas se deberá
consultar las bibliografía indicadas en las referencias.

Estimaciones - Conrado Estol - 12 de 12

Los pasos a seguir en un ambiente determinado de desarrollo de sistemas, donde se
cuente ya con una metodología estándar para el desarrollo de sistemas, serían los
siguientes:

1. Seleccionar las técnicas de estimación.

2. Capacitar al personal en esas técnicas.
3. Hacer conocer al personal los problemas que origina el sesgo optimista y otros
mencionados en el punto 3.
4. Llevar a cabo el proceso de planeamiento del proyecto utilizando el ciclo de vida
de sistemas de la metodología que se haya adoptado.
5. Identificar los datos de entrada necesarios para el proceso de estimación y
obtenerlos.
6. Aplicar las técnicas de estimación y obtener los resultados para la estimación.
7. Guardar los resultados en un archivo ad hoc (o sistema de estimación / registro,
preferentemente en computador)

Es aconsejable automatizar todo lo posible los pasos mencionados e inclusive, una vez
aprobado y probado el proceso, seleccionar alguna de las herramientas de software que
apoyan muchas de las técnicas mencionadas o sus variantes. Por ejemplo, la Ecuación
de Software puede utilizarse manualmente para ciertos casos, pero la herramienta
“SLIM” de Quantitative Software Management, simplifica enormemente el proceso de
cálculo y facilita mucha más información. Comentarios similares podrían hacerse de
software disponible para el método COCOMO, o de Checkpoint, de Software
Productivity Management, o muchas otras herramientas de software existentes en el
mercado.

Resumiendo, a continuación se dan los lineamiento generales de un enfoque de

estimación simplificado propuesto como aproximación inicial:

- Evaluar el ciclo de vida de sistemas descripto en la metodología adoptada como

estándar para identificar las fases de esa metodología que serán incorporadas en el plan
de trabajo para el proyecto;

- Para las fases que quedarán excluidas, identificar claramente las tareas y
productos que no deberán ser realizados o entregados;

- Identificar también en esas mismas fases las tareas o productos que sí

deberán ser "retenidos" en el proyecto y registrar claramente este hecho para asegurar
que sean incluidos en el proyecto;

- Para las fases que han quedado incorporadas en el plan de trabajo para el
proyecto, revisar las tareas que deberán ser realizadas y los productos que deberán ser
entregados y confirmar que efectivamente son necesarios/requeridos;

- Elaborar un plan de trabajo detallado para el proyecto en el que queden

definidas todas las fases y dentro de cada fase las tareas a ser realizadas y los
productos a ser entregados;

Estimaciones - Conrado Estol - 13 de 13

 - Estimar el esfuerzo requerido para llevar a cabo el plan de trabajo, para lo cual
se deberá aplicar la técnica de estimación ya probada y adoptada (preferentemente, en
conjunto con otra técnica usada para verificar resultados).

- Contrastar la estimación anterior con otra realizada por otra persona o por otro
grupo. Si las estimaciones no son razonablemente cercanas entre sí, se deberá analizar
con mayor detalle la fase o fases sobre las que se ha basado la estimación. En este
caso conviene - si no se lo ha hecho antes - recurrir a un proceso de estimación en
conjunto por un grupo formado por personal experimentado (Grupo de estimación).-

Referencias

1. Santayana, George, Ensayo “Life of Reason”, 1906.

2. DeMarco., Tom, Why Does Software Cost so Much? Dorset House Publishing,
Co., Inc., New York, NY, EE.UU., 1995, p. 50.
3. DeMarco, Tom, Controlling Software Projects, Yourdon Press, Prentice-Hall,
Englewood Cliffs, New Jersey, 1982: p. 9.
4. DeMarco, Op. Cit., p. 14.
5. The Oxford Universal Dictionary, Third Edition, Oxford University Press, London.
6. Price Waterhouse & Co., System Management Methodology, Project
Management, 1989.
7. DeMarco, Op. Cit., p. 14.
8. DeMarco, Op. Cit., p. 9.
9. Putnam, Lawrence H. y Ware Myers, Industrial Strength Software - Effective
Management Using Measurement, IEEE Computer Society Press, 1997, p. 59.
10. Brooks, F.P., The Mythical Man-Month, Addison Wesley, Reading,
Massachusetts, 1975. Reprinted 1982: p. 30.
11. Rubin, Howard, Metrics Worldwide: Known Knowns, Known Unknowns, Unknown
Unknowns, Applications of Software Metrics Conference - ASM 95 -, Orlando,
1995.
12. Humphrey, Watts S., Managing the Software Process, Addison-Wesley
Publishing Co., Inc., EE.UU., 1989, p. 58 y siguientes.
13. Lederer, Albert L. Y Prasad, Jasesh, Better Cost Estimating, Communications of
the ACM, February 1992, Vol. 35, No. 2, p. 51-59.
14. DeMarco, Tom, Why Does Software Cost So Much, Dorset House Publishing
Co., Inc., New York, NY, 1995, p. 7.

Estimaciones - Conrado Estol - 14 de 14

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

1. Introducción.

¿Cuándo un mes hombre es un mes hombre? Es una pregunta que he formulado una
infinidad de veces, con esas palabras o con variantes parecidas (¿Cuántas horas
hombre efectivas hay en un mes hombre?, ¿cuántas horas nominales y cuántas de
trabajo efectivo hay en un mes hombre?, y otras similares).

La mayoría de las respuestas que he recibido – y que todavía recibo – a esa pregunta
me han demostrado que el concepto en general vigente (y debo aclarar que hay
honrosas excepciones, por supuesto) no tiene mucho que ver con la realidad que se vive
cuando se está desarrollando un proyecto de desarrollo de software.

Tomando poco más de 20 días hábiles por mes, digamos 21, y 8 horas por día hábil en
el mes, llegaríamos a un promedio de 168 horas en un mes tipo (poco más de 2000
horas de trabajo nominal en un año). Es decir que un mes hombre tendría 168 horas
hombre en promedio aproximado. Es decir entonces que si consideramos un proyecto
para el que se ha estimado un esfuerzo equivalente a 10 meses hombre de trabajo,
podríamos decir razonablemente que para ese proyecto se requiere aplicar 1680 horas
hombre de esfuerzo.

Ahora bien, ¿es eso equivalente a decir que el trabajo lo puede realizar una persona en
10 meses? La respuesta aquí debería ser un decidido NO. Peor sería aun el caso si
decimos que ese proyecto lo podrían llevar a cabo dos personas en 5 meses de trabajo
(el producto seguiría siendo, aparentemente 10 meses hombre).

Hay diferentes cuestiones que entran en juego y es oportuno tratarlas a continuación por
separado.

2. Horas nominales versus horas efectivas de trabajo.

Efectivamente, podríamos decir que hay 168 horas “nominales” de trabajo en un mes
tipo, pero ¿cuántas horas hay de trabajo efectivo? La respuesta depende de diversos
factores, pero en general, considerando un régimen normal de trabajo, podremos decir
que habrá que descontar de las horas nominales la parte proporcional de todo el tiempo
dedicado o empleado en actividades que NO tienen que ver con el proyecto en cuestión.
Por ejemplo, podríamos construir una pequeña tabla para dar una idea de los elementos
que afectan el tiempo útil que es posible dedicar al proyecto en cuestión (los valores
citados como ejemplo deberían ser adaptados a cada caso particular):

Elemento a Considerar Porcentaje Promedio Horas promedio

mensuales
Vacaciones 6,0 10.0
Capacitación 4,0 / 8,0 10.0
Enfermedad 1,0 / 2,0 2.5
Ausencias varias 0,5 / 1,0 1.0
Tareas administrativas 2,0 / 10,0 10.0

Estimaciones - Conrado Estol - 15 de 15

Varios 10,0 16.8
Suma 22 + 50 +
Sería posible por lo tanto decir que, en promedio y en general, habría unas 50 horas por
mes para restar de las horas nominales para determinar el máximo posible de horas que
sería posible trabajar en un proyecto determinado. Es decir, redondeando, 170 – 50 =
120 horas, o sea alrededor de un 70 por ciento del tiempo nominal. Este valor – como se
dijo antes – depende de las características del equipo, de la mezcla de categorías (por
ejemplo las categorías superiores tienen un porcentaje relativo más alto de tareas
administrativos), y la organización (por ejemplo, si ciertas personas trabajan en más de
un proyecto a la vez, lo cual normalmente genera indeficiencias).

Si bien existen circunstancias especiales, o proyectos pequeños, en los que por tiempos
cortos pueden obtenerse coeficientes de aplicación de tiempo efectivo superiores – o
muy superiores - al 70 %, como regla general para una organización trabajando en
régimen año tras año, ése parece ser un valor razonable. Quienes vean la tabla incluida
en el Anexo E - Técnica Basada en la Duración de Entrevistas – notarán que la presente
estimación se ha hecho bastante más conservadora a través del agregado de un
“varios” de 10% adicional. En el momento de incluir la tabla del anexo E se trató de hacer
que las horas efectivas finales no fuesen muy distintas de las consideradas por Boehm
en COCOMO (152 horas en un mes). En última instancia, éste será un valor que deberá
ser obtenido para cada ambiente de desarrollo a partir de las “hojas de resúmenes de
tiempo” que el personal técnico debería presentar regularmente como elemento
fundamental para la derivación de métricas de interés.

Aquí aparece entonces uno de los puntos que permitirían explicar por qué es tan difícil
cumplir los plazos estimados. Si el estimador, o estimadores, consideran por ejemplo un
proyecto que requiere un total de 1700 horas de trabajo, pero luego dan por supuesto
que un mes hombre en la organización esta compuesto por 170 horas de trabajo, el
plazo calculado será de diez meses (El esfuerzo recurrido de 1700 horas hombre se
estimará por ejemplo que podrá ser realizado por un hombre trabajando diez meses...).
En cambio, la realidad será, posiblemente, que a un ritmo real de unas 120 horas de
trabajo por mes hombre ese proyecto requerirá más bien algo más de 14 meses para
terminarse (1700 horas hombre / 120 horas hombre / mes = 14,2 meses).

Esto trae a la mente la conocida historia de Frederick Brooks (1) sobre los datos de
Charles Portman, en ese entonces gerente de la División de Software de ICL, la
empresa británica de computadores. Portman encontraba que sus equipos de
programadores tomaban para sus respectivos trabajos aproximadamente siempre el
doble del tiempo estimado (planeado cuidadosamente con cientos de tareas en
diagramas PERT).

Para poder investigar ese problema, Portman comenzó a llevar detallados registros
diarios del uso del tiempo de todo el personal. Esos registros mostraron que los errores
en las estimaciones podían ser totalmente explicados por el hecho de que sus equipos
de trabajo sólo podían cumplir con un 50 % del tiempo nominal de la semana de trabajo
en los temas asignados de programación y depuración de programas. El resto del
tiempo se invertía - o perdía - en esperas por caídas de equipo, otros trabajos cortos que
debían hacerse y que no tenían ninguna relación con el proyecto principal, reuniones,
trabajo administrativo, ausencias por enfermedad, ausencias por problemas personales,

Estimaciones - Conrado Estol - 16 de 16

etc. En resumen, las estimaciones se basaban en una suposición errónea sobre las
horas de trabajo productivo realmente disponibles. Este es un punto a tener muy en
cuenta y que se presenta muy frecuentemente en la práctica diaria.

En resumen, el “mes hombre” estimado no consistía de la cantidad de horas supuestas.

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

Comunicaciones).

La comunicación entre los miembros del equipo tiene una importante influencia sobre la
productividad. Por otra parte, la comunicación humana tiene también un fuerte impacto
sobre el producto final del desarrollo de software.

Cada persona que trabaja en un proyecto debe ser capacitada en la metodología, los
objetivos del trabajo que se está realizando, la estrategia general, y el plan de trabajo. En
general, puede haber capacitación general, grupal, pero también tendrá que haberla
individual. El esfuerzo que ese tipo de capacitación individual agrega, varía linealmente
con la cantidad de personas en el grupo.

La comunicación entre los miembros del equipo origina un problema más serio (2).
Debido a que las posibles vías de comunicación entre los miembros del equipo de
trabajo se incrementa por un factor de n (n - 1) / 2, donde n es la cantidad de integrantes
del grupo. Esto implica que aumentar el tamaño de un equipo de desarrollo de software
puede incrementar la cantidad de software producido por unidad de tiempo, pero sólo
hasta cierto punto. En un momento determinado, la necesidad (y a veces los problemas)
de comunicación entre los miembros del equipo comienzan a tener mayor influencia
sobre el proyecto y reducen la cantidad de software que está siendo producida por
unidad de tiempo. Cabe aclarar que en medidas razonables esa comunicación es lícita,
o necesaria, ya que al dividir el trabajo entre más personas - al dividir la aplicación en
más módulos - será necesario que exista comunicación entre esas personas. Otro
factor que entra a jugar, es que aumenta el tamaño del producto final, ya que existirán
también más interfaces entre los distintos módulos.

Asimismo, en los casos en que se incorpora más gente a un equipo de trabajo, esos
nuevos miembros del grupo deben ser capacitados en la aplicación entre manos, y son
justamente los integrantes del equipo de trabajo original quienes, por conocer bien el
proyecto, deben cumplir con esa tarea. De manera que mientras que los nuevos
miembros del equipo aun no tienen un rendimiento adecuado, los antiguos miembros del
grupo rinden menos porque parte de su tiempo está dedicada a capacitar a los nuevos
integrantes del equipo.
Un corolario de esto es la Ley de Brooks: “Agregar mano de obra a un proyecto
atrasado lo demora aún más” (1) -.

A continuación introducimos una tabla donde se puede ver claramente para algunos
valores el incremento muy rápido que se produce en la cantidad de posibles vías de
comunicación a medida que aumenta el n, el número de integrantes de un equipo.

Estimaciones - Conrado Estol - 17 de 17

N n-1 n (n-1) n (n - 1) / 2
1 0 0 0
2 1 2 1
3 2 6 3
4 3 12 6
5 4 20 10
6 5 30 15
7 6 42 21
8 7 56 28
9 8 72 36

Finalmente, un punto especialmente importante es la relación no lineal que existe entre

el esfuerzo y el plazo en la realización de proyectos. Por la importancia especial de este
tema lo trataremos por separado más adelante.

Referencias

1. Brooks, F.P., The Mythical Man-Month, Addison Wesley, Reading,

Massachusetts, 1975. Reprinted 1982: p.89.
2. Tarek Abdel-Hamid and Stuart Madnick, Software Project Dynamics, Prentice
Hall, Englewood Cliffs, New Jersey, EE.UU, 1991, con bibliografía (Impact on
Actual Productivity Due to Communication, p. 92: Muestra un gráfico con cantidad
de personas en el equipo de trabajo en abscisas, y Porcentaje de Pérdida por
Comunicación en ordenadas. Para 30 personas en el equipo, la pérdida que
muestra ese gráfico es de 50%. Es decir, si de 8 horas nominales de trabajo
diario, una persona rinde efectivamente para el proyecto durante 6 horas,
entonces en un grupo de treinta personas, el rendimiento final de esa persona es
de 6 x 0,50 = 3 horas).

Hay otras referencias bibliográficas en que se hace referencia general a qué es un

mes-hombre, o al aumento de las comunicaciones inter personales a medida que
crece el equipo de trabajo, por ejemplo:

- Barry W. Boehm, Software Engineering Economics, Prentice-Hall, Inc., 1981 (p. 190
“des” economías de escala en proyectos grandes, “gold plating”).
- Frederick P. Brooks, Jr., The Mythical Man-Month, Addison-Wesley, 1982 (página 16 y
siguientes, The Man-Month).
- Tom DeMarco, Controlling Software Projects, Prentice-Hall, Inc., 1982 (páginas 171,
183).
- James R. Johnson, Managing for Productivity in Data Processing, QED Information
Sciences, Inc., 1980, pp. 90, 164.
- Dick B. Simmons y otros, Software Measurement, Prentice Hall, PTR, 1998 (p. 185).

Estimaciones - Conrado Estol - 18 de 18

Tema 3: Estimación de tamaño

1. Caveat Emptor!

"Que se cuide el comprador!", es decir, que compre a su propio riesgo, donde "comprar"
puede referirse a una idea, una técnica. Esta admonición debe tenerse n cuenta en todo
lo relacionado con las técnicas de estimación. Queremos decir con esto que es preciso
considerar cuidadosamente todos los supuestos y aproximaciones contenidos en las
técnicas expuestas antes de utilizarlas.

Los resultados variarán apreciablemente en función de qué lenguaje de programación

estamos usando (Evidentemente no es lo mismo 10.000 instrucciones Assembler que
10.000 instrucciones de un 4GL; una sola línea en un Lenguaje de Cuarta Generación
puede requerir docenas de instrucciones en Assembler). Debemos aceptar que la
longitud (lo que miden las LOC o DSI) de programas elaborados en distintos lenguajes
no es comparable con la utilidad o funcionalidad de esos programas. Esto fue
justamente lo que condujo a Albrecht a formular su esquema de Puntos de Función. Es
interesante mencionar que si los PF miden realmente la funcionalidad de un sistema,
entonces se puede medir la productividad de los programadores como la cantidad de PF
dividida por el tiempo-hombre utilizado en obtener esos Puntos de Función.

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

Distintos autores citan experiencias que relacionan Puntos de Función con 1Horas-
Hombre de trabajo. El problema es que existen amplias diferencias entre valores
mínimos y máximos. Las horas-hombre por PF varían además con el tamaño de los
proyectos; se requiere un mayor esfuerzo para proyectos más grandes (Recordar que la
estimación se refiere a TODAS las etapas en el ciclo de desarrollo; es lógico entonces
esperar que proyectos más grandes, que requieren mayor cantidad de personal y por lo
tanto más intercomunicación, necesiten un mayor esfuerzo).

Por ejemplo, en la literatura se citan valores desde 10 a 50 Horas-Hombre por Punto de

Función (Este último valor para proyectos grandes, del orden de 2000 PF). En un caso
específico un autor menciona 20 horas-hombre en promedio para lograr un PF
programando en COBOL (Como detalle complementario, ese autor - Rudolph, C.,
Productivity in Computer Application Development, Unisys Corp - menciona que con un
promedio de 14 instrucciones en LINC, que se pueden programar en aproximadamente
una hora, se puede lograr un (1) Punto de Función). Es decir, que según este autor
podría existir una variación de 1 a 20 en productividad de programación dependiendo en
el uso de LINC o de COBOL. Esta variación parecería ser demasiado alta.

Fenton (Fenton, Norman: Software Metrics: A Rigorous Approach, Chapman & Hall,
London, First Edition, 1991) cita dos días hombre promedio para obtener un Punto de
Función (sin aclarar el rendimiento diario o la cantidad de horas de trabajo efectivo). A su
vez, Johnson (Johnson, James R., The Software Factory, QED Information Sciences,
Inc., 1991) cita una referencia que da un rango de 0,31 a 0,57 Puntos de Función por día-
hombre (el tiempo es el directo informado por el personal del proyecto y aplicado a todas
las fases del mismo). Agrega, no obstante que sus propios números son más altos, y
procede a mencionar 0,9 PF por día-hombre como un objetivo específico que se puede

Estimaciones - Conrado Estol - 19 de 19

lograr. Este último valor es muy cercano al mencionado por Fenton (en un ejemplo
incluido en su libro).

Por su parte Capers Jones (Applied Software Measurement, McGraw Hill, Inc, New York,
1997) menciona para EE.UU. rangos que pueden ir desde un mínimo de 0,35 PF por
mes-hombre hasta un máximo de 200 (para prototipos y aplicaciones pequeñas de
usuarios finales) y da como promedio (para el año 1995) 8,45 PF por mes-hombreOp.
Cit, p. 142). Advierte al lector, no obstante, sobre los peligros del uso de “promedios”,
que – dice ese autor – no deberían utilizarse para la realización de estimaciones de
costo o para contratos.

Resumiendo, un par de días-hombre, o unas quince horas-hombre, por cada Punto de

Función parecería ser un promedio razonable. De todas maneras, los diversos valores y
rangos citados sirven para demostrar que sólo pueden servir como una idea de la
razonabilidad de los resultados. La mayor precisión en las estimaciones al utilizas esas
técnicas sólo se podrá lograr mediante un cuidadoso registro de información histórica
para el ambiente específico de que se trate. Ese procedimiento, y el ajuste progresivo de
los estándares utilizados a medida que se va contando con mayor información, puede
permitir obtener estimaciones válidas (siempre para un determinado ambiente de
desarrollo).

El tamaño de un sistema aplicativo (software) se puede medir de distintas maneras. La

más comúnmente utilizada es la unidad “LOC” por Line of Code, o instrucción.
Normalmente se utiliza la unidad KLOC (en inglés se pronuncia: K - la letra K en inglés -
LOC), por Kilo Loc, o sea por mil instrucciones.

Se debe poner énfasis sobre el problema que se presenta con la necesidad de definir
qué es realmente una “instrucción”. ¿Se trata de una instrucción física o una lógica?
Además, en una misma línea puede haber varias instrucciones, o sólo parte de una
instrucción. No existe un estándar internacional (o nacional) que defina qué debe
considerarse UNA línea de código. Por lo tanto es esencial contar con una definición
muy clara para contar en forma consistente las líneas - o instrucciones - de una
aplicación. Existen organizaciones que así lo hacen (lo DEBEN hacer). Inclusive, ciertas
empresas - por ejemplo así lo hacía Motorola en los EE.UU. - no sólo aplicaban
estándares para contar las instrucciones de sus aplicaciones, sino que normalizaban
todas esas medidas usando como base el Assembler. De esa manera podían comparar
distintos sistemas - programados en distintos lenguajes - entre sí (consultar también
Capers Jones, Applied Software Measurement, McGraw Hill, Inc, 1997., p. 77).

Hay muchas empresas que usan esa medida de tamaño, y existen grandes bases de
datos de proyectos medidos en KLOC, como para realizar comparaciones
(“Benchmarking”). Una explicación de ese uso bastante común es que es muy fácil
contar “líneas de código” en forma automática, cuando un programa pasa de la
Biblioteca de Desarrollo a la de Producción (pueden desarrollarse distintos programas
para contar instrucciones en distintos lenguajes).

Como referencia sobre modelos de normas para contar instrucciones fuente, consultar
el Apéndice A, página 403, de Capers Jones, Op. Cit.).

Estimaciones - Conrado Estol - 20 de 20

3. Posibles problemas con LOC.

Debe visualizarse claramente que el uso de LOC presenta en muchos casos serios
problemas. Por ejemplo, cuando se pretende usarlo como medida en cálculos
económicos (por ejemplo, $ por KLOC). En primer lugar, en muchos grandes proyectos
de software la cantidad de esfuerzo que se aplica a la programación puede ser sólo un
20% del total del proyecto o aun menos. Pero además, cuando se usan LOC para
calcular productividad, resulta que se penaliza a los lenguajes de alto nivel, que
justamente son los más productivos. Esto se puede ver también con referencia a las
métricas en general, con la denominada “paradoja del costo por defecto” (una aplicación
con muchos defectos tendrá normalmente un costo por defecto MENOR que una de alta
calidad, con pocos defectos. Eso debido, como en el caso del uso de costo por KLOC, a
la influencia de los costos fijos).

Para aquellos interesados especialmente en este tema les recomiendo como referencia
a Capers Jones, obra citada, páginas 10, 53-60). Por ejemplo, para dos programas con
idéntica funcionalidad:

Versión
Assembler Versión Ada
Esfuerzo de programación, en meses hombre 3 1
Esfuerzo en OTRAS actividades de proyecto, m-h 3 3
Esfuerzo total del Proyecto, en meses hombre 6 4
Instrucciones fuente por mes hombre 1250 625

La tabla muestra la paradoja de que un sistema programado en un lenguaje de alto nivel,

que resulta en un aumento de productividad real, sin embargo muestra un (aparente)
menor rendimiento cuando se usa la métrica de instrucciones por mes hombre. Notar
que si examinamos el esfuerzo total veremos que es menor para la versión en Ada. Si le
asignamos al personal del proyecto un costo promedio, con cargas sociales, de por
ejemplo $ 4.000, los costos totales reflejan la realidad ($24.000 en un caso, y $ 16.000
en el otro). No obstante, si calculamos el costo por LOC, volvemos a entrar en
problemas: Para la versión Assembler: $24.000 / 1250 LOC = 19,20 $ por LOC, Para la
versión realmente de menor costo: $16.000 / 625 LOC = 25,60 $ por LOC. Es decir,
analizando el costo por LOC parecería que es económicamente más ventajoso usar
Assembler...

4. Puntos de Función:

Para fines de análisis económico o de productividad debería usarse Puntos de Función

como métrica de tamaño. Esta medida basada en las funciones de un sistema, es
independiente del lenguaje de programación, y fue publicada por primera vez por A.J.
Albrecht - en ese entonces de IBM - en octubre de 1979 (Ver el Anexo A).

Existen métodos simplificados para el cálculo de Puntos de Función. Por ejemplo, el

desarrollado en 1985 por Software Productivity Research (empresa entonces presidida
por Capers Jones). Este método reduce apreciablemente el tiempo requerido para el
cálculo con resultados que difieren del cálculo original en porcentajes muy bajos. En

Estimaciones - Conrado Estol - 21 de 21

esencia, ese método simplificado utiliza directamente los valores promedios para cada
función (no es necesario contar la cantidad de tipos de datos, o de archivos, o de
registros). La complejidad general de la aplicación se tienen en cuenta a través de dos
preguntas a cuyas contestaciones se les asignan valores entre 1 y 5, según su
complejidad:

1. ¿Cuán complejo es el problema o los algoritmos requeridos?

2. ¿Cuán compleja es la estructura de datos de la aplicación?

Con la suma de los valores obtenidos de las respuestas a 1 y 2, se entra en una tabla
que da el factor de ajuste por complejidad (multiplicador que varía entre 0,5 y 1,5):

Complejidad Multiplicador
1 0,5
2 0,6
3 0,7
4 0,8
5 0,9
6 1,0
7 1,1
8 1,2
9 1,3
10 1,4
11 1,5

5. “Backfiring”.

Al proceso de derivar la cantidad de Puntos de Función de programas existentes para

los que se cuenta con cantidad de KLOC se lo denomina “backfiring” en inglés. Esa
palabra se refiere al hecho de que se hace algo en una forma que no es la normal, o de
atrás para adelante, de KLOC a Puntos de Función (El significado original se usa
comúnmente para referirse a la “detonación” en un motor, es decir, la explosión
prematura de los gases de combustión en un motor).

Existen tablas publicadas (por ejemplo en Jones, op. cit., páginas 80 a 92) que dan la
equivalencia promedio entre un Punto de Función y centenares de lenguajes de
programación (464 lenguajes y sus variantes en el caso de Capers Jones). Por ejemplo
(sólo para algunos casos; ver también tabla al final del Anexo A):

Lenguaje LOC / PF (en promedio)

Assembler 320
C 128
COBOL 107
FORTRAN 107
Pascal 91
Lenguajes OO 30
4GL 20

Estimaciones - Conrado Estol - 22 de 22

Es importante destacar que estos son “promedios.” Los “sigma” (la dispersión) en
muchos casos tienen valores muy altos.

Para dar una idea más específica de lo que significan los Puntos de Función en cuanto a
tamaño de aplicaciones, puede comentarse que un banco pequeño en los EE.UU. tiene
una cartera de aplicaciones que se puede estimar en unos 125.000 Puntos de Función
(Capers Jones, op. cit., página 51).

Otros valores (siempre en PF):

Banco comercial mediano 350.000

Banco internacional grande 450.000
Operador telefónico grande 450.000
Empresa industrial mediana 200.000
Empresa industrial grande 375.000
Fabricante de computadoras, grande 1.650.000

Capers Jones NO da información adicional sobre el último caso, pero podría

sospecharse que entre las aplicaciones se cuentan quizás también sistemas operativos.

Otra información muy interesante de la misma fuente es la cantidad aproximada de

Puntos de Función utilizados en apoyo de su trabajo por distintos tipos de trabajadores
en los EE.UU. Por ejemplo:

Agente de Viajes 35.000

Funcionario de Banco (préstamos) 15.000
Ingeniero Aeronáutico 25.000
Ingeniero en Telecomunicaciones 20.000
Ingeniero de Software 15.000
Gerente de proyecto de software 3.500

Referencias:
- Fenton, Norman: Software Metrics: A Rigorous Approach, Chapman & Hall, London,
First Edition, 1991

- Johnson, James R., The Software Factory, QED Information Sciences, Inc., Wellesley
(MA,US), 1991

- Jones, Capers: Applied Software Measurement, McGraw Hill, Inc, New York, 1997.

Estimaciones - Conrado Estol - 23 de 23

Tema 4: La Ecuación de Software de Putnam

1. Introducción:

La “Ecuación de software” de Putnam (1) dice

1/3 4/3
Q = P * (E/B) * T donde

Q = Cantidad de producto desarrollado (en instrucciones fuente)

P = Productividad del proceso de desarrollo
E = Esfuerzo medido en años-hombre
B = Factor empírico de corrección por complejidad
T = Duración del desarrollo medido en años.

Esta ecuación ha sido utilizada - según Putnam & Myers (2) - por cientos de
organizaciones para proyectar plazos y esfuerzos de desarrollo. Según esos mismos
autores, la variación en los plazos reales con respecto a los estimados con la ecuación
ha estado típicamente en un rango de más / menos un 10%. Con respecto al esfuerzo,
la variación ha sido mayor pero en general menor a un 20%.

En la práctica, Putnam recomienda el uso de una herramienta de software para hacer

los cálculos - relativamente complejos - requeridos, y poder obtener la mayor
información posible del proceso. Más adelante indicamos un método manual (con
ciertas limitaciones menores).

La ecuación indica que el esfuerzo (que figura en la fórmula como una raíz cúbica) tiene
un impacto menor que el tiempo de desarrollo (que figura elevado a 4/3). En la práctica,
el efecto de que en la ecuación el esfuerzo figure como una raíz cúbica es que se puede
aumentar el esfuerzo realizado agregando más y más gente a un proyecto, pero el
impacto de ese aumento se diluye al extraer la raíz cúbica de ese mayor esfuerzo. Es
decir, la cantidad de producto desarrollado sólo aumentará en forma proporcional a la
raíz cúbica del esfuerzo:
1/3
Q  f(E )

Para mostrar un ejemplo práctico, si el esfuerzo es por ejemplo de 64 años-hombre y

prácticamente lo duplicamos, llevándolo a aproximadamente 125 años-hombre, el efecto
sobre la cantidad de producto será sólo de un 25%:
1/3
Q1 = K * 64 = K* 4
1/3
Q2 = K * 125 = K *5

Q2 / Q1 = 5 / 4 = 1,25

Es decir, para los valores específicos del ejemplo considerado, para una variación con
un factor prácticamente igual a 2 en el esfuerzo (125 en Q2 sobre 64 en Q1) se ha
obtenido una variación de 25 % (Q2 / Q1, o 5 / 4) en la cantidad de producto
desarrollado. En resumen, uno puede agregar mucha gente a un proyecto - y aumentar

Estimaciones - Conrado Estol - 24 de 24

su costo en forma considerable - y sin embargo no lograr mucho en cuanto a la mejora
del plazo original. (Esto parecería que podría ser una explicación o justificación a algo
que en parte dice la denominada Ley de Brooks: Cuando a un proyecto de software
atrasado se le agrega más gente lo que se logra es atrasarlo aun más...(3).

Por otra parte, si se mantiene constante la cantidad de producto (Q), esa duplicación
del esfuerzo - siempre para los valores específicos de este ejemplo - representará
solamente una pequeña disminución en el tiempo de desarrollo (una disminución de un
20% en ese valor). Evidentemente, el esfuerzo de desarrollo no es independiente del
tiempo, o plazo, del proyecto, por lo que ambos deben ser considerados -. planeados -
en conjunto.

Como contrapartida de lo anterior, el líder de proyecto puede reducir el esfuerzo

requerido para el desarrollo, es decir, los meses hombre estimados, y por consiguiente
el costo, planeando un plazo de desarrollo algo mayor que el mínimo posible.

Lamentablemente, el bastante común “voluntarismo” gerencial conspira contra esto con

aquello de “tiene que estar listo para ayer.” O si no es exactamente así, imponiendo
fechas de entrega que muchas veces nada tienen que ver con las reales posibilidades
de realizar un trabajo de calidad (Las consecuencias - los costos - sólo se ven más
tarde, durante el funcionamiento de la aplicación y especialmente durante su
mantenimiento, pero esas consecuencias normalmente no aparecen ni informadas, ni
registradas como asientos contables... Y el ciclo de las urgencias permanentes, y los
objetivos basados en plazos de entrega más que en cualquier otra variable, continúan
así año tras año. Como muy bien comenta Tom DeMarco, la gente trabaja para
optimizar aquel objetivo que se le plantea, o que percibe, como el fundamental. Y la
gente que trabaja para cumplir con una fecha, puede trabajar más rápidamente, pero
normalmente no trabajará mejor (4).

Aun en proyectos con plazos muy acotados, pero factibles, la gente trabaja con
ansiedad, tiene mayor cantidad de conflictos personales, se cansa más fácilmente y -
muy importante - comete más errores.

La unidad de tamaño utilizada por Putnam y Myers es SLOC (Source Lines of Code).
Los autores sin embargo mencionan otras unidades, y en particular puntos de función.
Una alternativa, si se utilizan puntos de función como métrica de tamaño, es reemplazar
esos puntos de función por el equivalente aproximado de cantidad de instrucciones
según el lenguaje, o lenguajes, usados en la aplicación.

2. Productividad del Proceso

El término P, Productividad del Proceso, merece un comentario especial. Por lo pronto,

Putnam la llama productividad del proceso porque representa la capacidad de la
organización para desarrollar una aplicación desde la definición de requerimientos y
preparación del documento de especificación, hasta la programación y pruebas finales.
Esa “productividad de proceso” se puede determinar empíricamente utilizando
información de proyectos ya realizados. Con el tamaño de productos desarrollados, el
esfuerzo que demandaron esos desarrollos, y los plazos de ejecución.

Es decir,

Estimaciones - Conrado Estol - 25 de 25

 Productividad del Proceso = Tamaño (LOC) / (Esfuerzo en años-hombre / Factor
1/3 4/3
de complejidad) x (Plazo de Desarrollo - años)

Por supuesto, esto parte de la base de que en la organización existen datos registrados
para los proyectos realizados en el pasado.

Otro supuesto fundamental es que el pasado sirve para predecir el futuro. Es decir, que
el proceso de desarrollo es razonablemente “repetible” (para usar un término que nos
puede hacer pensar en el CMM). (5)

En los registros mantenidos por Quantitative Software Management - QSM -, la firma de

Putnam, el rango de esa “productividad del proceso” es muy grande, tanto que los
extremos que ha registrado difieren por un factor de más de 2.000. Para mayor facilidad
en su uso, Putnam ha desarrollado “números índice” que representan rangos de esa
productividad del proceso (1, 6).

El “Factor de Complejidad”, que Putnam y Myers designan con la letra B, tiene los
siguientes valores empíricos para distintos tamaños de software (1):

Tamaño (SLOC) Factor “B”

5-15 L 0,16
20K 0,18
30K 0.28
40K 0,34
50K 0,37
>70 K 0,39

Veamos ahora el cálculo de ese valor de la “productividad del proceso” que se obtiene
en forma empírica, usando datos de proyectos anteriores.

Con los valores calculados para un rango de proyectos (y la empresa de Putnam tienen
una base de datos con más de 4.000 proyectos) se obtienen valores de la productividad
del proceso, y de allí, agrupando rangos de esos valores, Putnam y Myers han derivado
los que denominan “Índice de Productividad”, IP.

Las principales entradas al proceso de estimación de software con la Ecuación de

Software son el tamaño estimado para el software, los valores calibrados de
productividad del proceso específico, y la tasa de crecimiento de aplicación de personal
al proyecto (lo que Putnam y Myers llaman “Manpower Buildup - MB).

Por ejemplo, 3
MB = Esfuerzo Total / (Plazo de Desarrollo)

Estimaciones - Conrado Estol - 26 de 26

3. Cantidad de personal requerido.

La ecuación de Rayleigh es representativa del modelo de utilización de mano de obra en

el ciclo de vida de un proyecto, y describe la necesidad de personal durante el desarrollo
del proyecto. Esa ecuación tiene la siguiente forma:
2
MO = 2 aEte -at

donde MO = tasa de aplicación de mano de obra

a = constante que controla el tiempo hasta alcanzar el máximo valor de

mano de obra

E = esfuerzo (área bajo la curva)

t = tiempo de desarrollo

La idea de la utilización de esta ecuación para describir el proceso de aplicación de

recursos humanos al desarrollo de proyectos de software fue introducida por Lawrence
H. Putnam en la década de 1970 (7).

4. El intercambio entre esfuerzo y plazo

Las relaciones existentes entre tamaño, plazo, esfuerzo, y defectos no son lineales
(Esa es una más de las razones de la debilidad de la utilización de LOC por mes-
hombre como una medida de la tasa de producción de software).

La Ecuación de Software de Putnam y Myers permite apreciar, cuando se grafican

ciertos elementos, que a medida que se planea un mayor plazo para el proyecto, el
esfuerzo correspondiente es menor. En el punto del plazo mínimo de desarrollo, el
esfuerzo (y por lo tanto el costo) tendrá un valor máximo. El valor de la cantidad de
defectos también será el máximo. Evidentemente, se puede intercambiar tiempo de
desarrollo - plazo - por menor esfuerzo y menor costo (y menor cantidad de defectos).
Por supuesto, existen límites prácticos para ese intercambio. No se considera práctico
planear un plazo de desarrollo que sea mucho mayor a 1,3 veces el tiempo mínimo.

Por ejemplo, para una aplicación de tamaño mediano (unos 500 puntos de función),
desarrollada por una organización con un Índice de Productividad promedio (IP de 16 y
tasa de crecimiento de aplicación de recursos humanos - MB - de 5), Putnam (6, p. 102)
da los siguientes valores:

Plazo (meses Extensión del Esfuerzo Cantidad MTTD (días)

Plazo (%) (meses- máxima de
hombre) personal
7,62 Mínimo 143 27 0,77
8 106 118 21 0,99
9 118 74 12 1,78
10 130 48 7 3,01

Estimaciones - Conrado Estol - 27 de 27

MTTD = Mean Time to Defect (Tiempo medio hasta un defecto), Índice de calidad

En la tabla anterior, el valor final de 10 meses para el plazo corresponde a algo más de
130% (131%) del valor inicial de 7,62 meses. Es importante notar que el esfuerzo
correspondiente al mayor plazo es sólo un 34 % del requerido para el plazo mínimo... Y
algo muy importante, la calidad (representada por los valores de la última columna)
mejora en casi cuatro veces!

Para utilizar la Ecuación de Software de Putnam en primer lugar es necesario realizar

una “calibración” (como dice Putnam) del área de desarrollo de sistemas, basada en
datos sobre el tamaño, esfuerzo requerido, y plazos de ejecución para proyectos
anteriores. Esa calibración empírica permite obtener el parámetro de productividad de
esa área para utilizar en la Ecuación de Software.

Aquí tropezamos con un primer problema que no es nada trivial: Aunque pueda llamar la
atención, lamentablemente no son muchas las organizaciones en las que se pueden
encontrar esos datos (que muchos de nosotros consideramos elementales para poder
haber tenido un mínimo control sobre los proyectos desarrollados). Y cuando existen, el
grado de precisión, o la confiabilidad misma de esa información, puede dejar mucho que
desear.

Si encontramos datos de tamaño, éstos estarán dados muchas veces sólo en términos
de cantidad de programas, o de módulos. Si tenemos suerte, podrá existir algún rango
razonablemente acotado de la cantidad de instrucciones que tienen en promedio los
programas o los módulos. Si seguimos teniendo suerte puede ser que encontremos
datos sobre cantidad de instrucciones (LOC -Lines of Code -, o SLOC - Source Lines of
Code -). Tendremos que realizar algunas indagaciones sobre qué se define como
“LOC” en esa organización, y con qué grado de precisión se ha medido la cantidad de
instrucciones. Cuando encontremos esa situación veremos normalmente que ha
existido un redondeo al millar más cercano, o a la decena de miles más cercana... Y,
desde ya, no pongamos muchas esperanzas en encontrar alguna organización que
tenga información de tamaños de proyectos medida en puntos de función (Hay algunas).

En cuanto al esfuerzo requerido para el desarrollo, el problema puede ser aun mayor. No
son muchos los que hacen que su personal técnico mantenga registros sistemáticos de
la aplicación de su tiempo a proyectos, en base a algún - podríamos decir - “plan de
cuentas” pre establecido. Se nos presentarán seguramente dudas sobre el grado de
control y verificación aplicado para asegurar la confiabilidad de esos registros. Además,
qué seguridad existe sobre cuán completos son esos registros: ¿incluyen todas las
horas de supervisión y administración del proyecto? ¿hasta qué momento se siguieron
registrando esas horas? Es decir, ¿en qué momento, fecha, se consideró que el
proyecto estaba finalizado? ¿Qué unidades se utilizaron para los registros y para los
informes de tiempo acumulado? ¿Horas-hombre, meses-hombre,...? ¿Cómo se ha
redondeado? La esperanza es que existan algunos datos y que se haya utilizado un
sistema razonablemente consistente, de manera que se puedan usar esa información
para distintos proyectos.

Por último, el plazo puede ser el más sencillo de determinar. Normalmente se contará
con una fecha de inicio del proyecto y una fecha en que pasó a “Producción.” No

Estimaciones - Conrado Estol - 28 de 28

obstante, comúnmente no existirán definiciones muy exactas sobre la “finalización” del
proyecto, lo que afectará la precisión del plazo de desarrollo.

En resumen, puede esperarse que si tenemos suerte encontraremos datos - o

estimaciones - sobre tamaño, esfuerzo, y plazos para proyectos desarrollados en el
pasado. Normalmente, esos datos serán sólo aproximados, con un error que variará
según el caso pero que en promedio se podría estimar en un 20 %, si no más. En
realidad todo este proceso debería resultar en un gran aliciente para que la organización
comience a aplicar una nueva disciplina en la recolección de información sobre
proyectos, asociada a una precisa definición de los términos utilizados. De esa forma se
podrá aumentar para el futuro la confiabilidad de los registros y su precisión.

Inicialmente, Putnam y Myers (1) realizaron cálculos basados en la gran base de datos
de proyectos que poseían, y definieron valores del parámetro de productividad que iban
desde un valor menor a 1.000 hasta un valor superior a 46.000. Para mayor facilidad,
asociaron a rangos de esos valores lo que denominaron “Índices de Productividad.” En
particular 18 índices para cubrir el rango desde poco menos de 1.000 hasta poco más
de 46.000. Cuando se grafica este Índice contra el Parámetro de productividad, éste
último en una escala logarítmica, se obtendrá una línea recta.

Posteriormente, Putnam y Myers extendieron dos veces ese rango del parámetro de
productividad (debido a mejoras identificadas en los proyectos de sus clientes incluidos
en la Base de Datos). Finalmente, los números que utilizan actualmente (6, pág. 45) van
desde 754 (asociado a un Índice de Productividad de 1, hasta un valor de 9.227.465,
asociado a un Índice de Productividad de 40. En realidad, como aclaran ellos mismos (6,
pág. 46), el Índice lo calculan con un decimal, de manera que el rango total de
incrementos en su Índice, desde 0 hasta 40, abarca 410 escalones.

El valor más alto de Índice de Productividad que Putnam y Myers han encontrado es 34.
Es interesante notar que el factor multiplicador entre un Índice de Productividad (IP) de 1
y IP de 34 es nada menos que 2.889 (6). Es fácil comprender entonces el importante
peso que tiene una variación de sólo un punto en el IP.-

Referencias:

(1) Putnam, Lawrence H. & Ware Myers, Measures for Excellence - Reliable Software on
Time, Within Budget, Prentice-Hall, Inc., Englewood Cliffs, NJ 07632, EE.UU.,1992.

(2) Putnam, Lawrence H. & Ware Myers, Controlling Software Development - Executive
Briefing, IEEE Computer Society Press, Los Alamitos, CA, EE.UU., 1996.

(3) Brooks, F.P., The Mythical Man-Month, Addison Wesley, Reading, Massachusetts,
1975. Reprinted 1982.

(4) DeMarco, Tom, Controlling Software Projects, Yourdon Press, Prentice-Hall,

Englewood Cliffs, New Jersey, 1982.

(5) Humphrey, Watts S., Managing the Software Process, Addison-Wesley Publishing
Company, Inc., EE.UU., 1989.

Estimaciones - Conrado Estol - 29 de 29

(6) Putnam, Lawrence H. y Ware Myers, Industrial Strength Software - Effective
Management Using Measurement, IEEE Computer Society Press, Los Alamitos, CA,
EE.UU., 1997.

(7) Putnam, L.H., A General Empirical Solution to the Macro Software Sizing and
Estimating Problem, IEEE Transactions of Software Engineering, Vol. SE-4, No. 4, July
1978.

Estimaciones - Conrado Estol - 30 de 30

 TABLA DE PP (Parámetros de Productividad)

Parámetro de Índice de
Productividad Productividad Tipo de Aplicación a que se aplica

754 1
987 2 Microcódigo
1220 3
1597 4 “Firmware” (ROM)
1974 5 Tiempo real “embebido” / Avionics
2584 6
3194 7 Sistemas de Radar
4181 8 Comando y Control
5186 9 Control de Procesos
6765 10
8362 11 Telecomunicaciones
10946 12
13530 13 Software de Sistemas / Sistemas científicos
17711 14
21892 15
28657 16 Sistemas empresariales
35422 17
46368 18
57314 19
75025 20
92736 21
121393 22
150050 23
196418 24
242786 25 Valor más alto encontrado hasta ÷ 1990
317811 26
392836 27
514229 28
635622 29
832040 30
1028458 31
1346269 32
1664080 33
2178309 34
2692538 35
3524578 36

Estimaciones - Conrado Estol - 31 de 31

Apéndice

Bases para el control gerencial de los proyectos de desarrollo

de software.

"Cuánto menor cantidad de controles se necesiten, más efectivos

podrán ser esos controles." Peter Drucker, Management: Tasks,
Responsibilities, Practices, Harper & Row, New York, 1975.

"No se puede controlar lo que no se mide", Tom DeMarco, ......

En sus términos más elementales, la gerencia necesitará cuatro tipos de datos básicos
- cuatro métricas - para poder planear y controlar el trabajo asignado:

1. Una métrica de tamaño. Esto permitirá cuantificar la dimensión del proyecto

entre manos. Cuando se usa - y lamentablemente, quizás también podríamos
agregar "inexplicablemente" - se usa poco... - la métrica más común es la de LOC
o "Lines of Code" o instrucciones; en algunos casos, también los Puntos de
Función.

2. Una métrica de productividad. Es decir, se necesitará contar con una medida de

la capacidad de producir trabajo que tienen nuestra organización. Por ejemplo,
cantidad promedio de Kloc por mes hombre (o por día hombre), o cantidad
promedio de puntos de función por mes hombre (o por día hombre). Esta métrica,
en conjunto con la cantidad de personal disponible para cada tipo de tarea a
realizar, permitirá definir el tiempo necesario para desarrollar el proyecto (o
muchas veces en situaciones prácticas, dado el plazo disponible para finalizar el
proyecto, permitirá definir el equipo de trabajo requerido).

3. La definición del plazo necesario para cumplir con el proyecto, o la definición del
cronograma del proyecto. Es decir, la cantidad de meses calendario (o semanas,
o días, u horas) necesarios para el desarrollo del proyecto para una cierta
disponibilidad - o posibilidad - de asignación de gente al trabajo.

4. La predicción de un cierto nivel de calidad alcanzable y la medición del nivel de

calidad realmente logrado.

Al comienzo de este punto se decía que esos cuatro datos eran "elementales." De ellos
podemos derivar, por ejemplo, el esfuerzo requerido para el desarrollo. De la relación
entre el tamaño y la productividad promedio se podrá calcular el esfuerzo requerido:

Esfuerzo = Tamaño (´X´ LOC) / Productividad (´Y´ LOC / m-h) = ´X´ / ´Y´ m-h

O, Esfuerzo = Tamaño (´X´ PF) / Productividad (PF / m-h) = ´X´ / ´Y´ m-h

Y del esfuerzo, contando con el costo promedio por mes hombre y agregándole las
cargas sociales, podremos llegar al costo total del proyecto (suponiendo - como es
normalmente válido suponer - que el costo del personal es el principal costo del
desarrollo).

Estimaciones - Conrado Estol - 32 de 32

Una forma de estimar el esfuerzo es utilizar alguno de los métodos o técnicas
disponibles en la ingeniería de software (por ejemplo, la fórmula COCOMO de Barry
Boehm, o alguna de las otras técnicas disponibles).

Al llegar a este punto se habrá presentado una pregunta fundamental. Una pregunta que
no siempre aparece cuando se está estimando el tamaño, esfuerzo, o plazo para un
proyecto de desarrollo de software. Esa pregunta es ¿cuál es la calidad estimada para el
producto final? La respuesta a esta pregunta es de esencial importancia, aunque no
siempre figure entre la información de los proyectos nuevos. La métrica "calidad" del
producto a desarrollar, como valor estimado al comienzo del proyecto y como valor
calculado durante el desarrollo y a su finalización, debería ser una preocupación
importante del equipo de trabajo y de su líder. Esta métrica estará representada
normalmente por la cantidad de defectos por unidad de tamaño (defectos por KLOC, o
defectos por Punto de Función). Debemos entonces tener presente que, como se dice
antes, son cuatro los datos básicos (estimaciones) que se necesitarán para planificar y
controlar el trabajo de desarrollo de software:

1. Tamaño y esfuerzo
2. Productividad
3. Plazo
4. Calidad.

Estimaciones - Conrado Estol - 33 de 33

 ANEXOS

El siguiente material ha sido extractado (salvo la nota sobre COCOMO II) de anexos de
un documento preparado por Conrado Estol y publicado en el año 1993 por la
Universidad de Belgrano (Estimación de Tiempos y Esfuerzo para Proyectos de
Software, Documento de Trabajo, Serie Tecnología No. 2 – Agosto 1993).

Estimaciones - Conrado Estol - 34 de 34

A – ANÁLISIS CON PUNTOS DE FUNCIÓN

Específicamente en este caso se hace referencia al método desarrollado por Allan

Albrecht en IBM y publicado en 1979 (13). Albrecht desarrolló esta técnica como una
alternativa a la estimación de cantidad de líneas de programas. Una ventaja sería la de
poder contar con bases más concretas - la definición de requerimientos, por ejemplo -
para realizar una estimación, o aun un cálculo, de los puntos a asignar a un proyecto.

Para medir el tamaño de un sistema, y el consiguiente esfuerzo requerido, se utiliza un

sistema de asignación de puntos por función. Se cuenta, por ejemplo, la cantidad de
entradas y salidas, la cantidad de archivos, la cantidad de consultas, y la cantidad de
interfaces. Existen varios modelos de este tipo con distintas variantes entre las
funciones consideradas y las tablas de asignación de puntaje por función. Los dos
principales pasos para determinar el puntaje de un sistema son los siguientes: 1) Contar
las distintas funciones del sistema, y 2) realizar un ajuste según la complejidad prevista
para el proceso.

Originalmente, Albrecht previó cuatro categorías de funciones: entradas (inputs), salidas

(outputs), archivos lógicos internos, y consultas. No obstante, los elementos del
proyecto que se consideran normalmente son los cinco siguientes:

-Entradas, que proporcionan la comunicación del usuario con la aplicación; por ejemplo,
nombres de archivos y selecciones de menús.

-Salidas, que proporcionan comunicación con el usuario desde la aplicación; por

ejemplo, informes y mensajes.

-Consultas externas, que son entradas interactivas que requieren una respuesta.

-Archivos externos, que son interfaces con otros sistemas.

-Archivos internos, que son archivos maestros lógicos dentro del sistema.

Para el uso de esta técnica es necesario tener en cuenta los siguientes elementos:

-Una especificación completa del sistema constituye un requerimiento básico;

-La determinación de la cantidad de puntos de función de la aplicación es en

parte subjetiva. Es preciso establecer reglas para distinguir claramente entre "Entradas"
y "Salidas" por una parte y "Consultas" por la otra. También para poder determinar qué
constituye exactamente un "archivo lógico" desde el punto de vista del usuario;

-En general, la cantidad y complejidad de entradas, salidas, consultas, etc,

tenderá a ser subestimada;

-Los Puntos de Función no son realmente independientes de los métodos

utilizados para el análisis y diseño;

Estimaciones - Conrado Estol - 35 de 35

 -El ajuste de los Puntos de Función basado en la complejidad tecnológica de la
aplicación (evaluación del impacto de catorce factores) introduce más subjetividad en el
proceso.

No obstante lo anterior, la funcionalidad es un atributo esencial de cualquier producto y la

técnica de los Puntos de Función es una de las más útiles que se puede utilizar.

Los factores de ponderación para distintas funciones según se las califique como
simples, promedio y complejas se incluyen en una tabla (ver a continuación). El valor
dado en la tabla para una determinada función, con un determinado nivel de complejidad,
se multiplica por el número de ocurrencias. De esa manera si la ponderación para
entradas (inputs) complejas, por ejemplo, es "6", y se han contado 5 de esas entradas,
el puntaje ponderado en ese caso sería "30".

ELEMENTO SIMPLE MEDIO COMPLEJO

A. Entrada 3 4 6

B. Salida 4 5 7

C. Consulta 3 4 6

D. Archivo Externo 5 7 10

E. Archivo Interno 7 10 15

La suma de los puntajes parciales da un puntaje total inicial (PTI), que es ajustado por el
efecto que 14 factores de complejidad tienen sobre el sistema. Cada uno de esos
factores es evaluado de acuerdo con la asignación de un cierto nivel de influencia que se
califica como 0, 1, 2, 3, 4, o 5. El 0 indica que ese factor no está presente y el 5 indica
que es esencial. Los factores que contribuyen a la complejidad son los siguientes:

-Comunicación de datos

-Procesamiento distribuido

-Objetivos de rendimiento (performance)

-Configuración del computador altamente utilizada

-Respaldo y recuperación confiables

-Ingreso de datos "on-line"

-Actualización interactiva "on-line"

Estimaciones - Conrado Estol - 36 de 36

-Interface compleja

-Procesamiento complejo

-Requerimientos de "re usabilidad"

-Facilidad de conversión e instalación

-Facilidad de operación

-Cantidad de ubicaciones

-Facilidad de realizar modificaciones.

Después de haber calificado a cada uno de esos factores se suman todos los puntajes.
Finalmente, ese puntaje total se procesa para que proporcione un coeficiente de ajuste
(CA), o ponderación, de más / menos 35 por ciento (de 0,65 a 1,35).

El proceso consiste de los siguientes pasos:

1. Calcular, o evaluar, la cantidad y tipo de cada elemento (función) en la aplicación;

2. Multiplicar cada uno de los distintos tipos de elementos A, B, C, D, o E por el factor de

ponderación correspondiente, según sea evaluado como simple, promedio o complejo;

3. Obtener el puntaje funcional inicial (PFI) como la suma de todos los productos del
punto anterior;

4. Tomar la suma total de los factores de complejidad, fc(i), y multiplicarla por "0,01":

0,01xSumatoria de fc(i) = 0,01 x (fc1 + fc2 + ... + fc14),

donde fc(i) indica los factores de complejidad de 1 a 14;

5. Obtener el Factor de Complejidad Técnica (FCT), sumando 0,65 a la respuesta del

punto 1 (anterior):

FCT = 0,65 + 0,01 Sumatoria de fc(i);

(El factor de complejidad técnica toma un valor que va desde 0,65 si cada fc(i) = 0 a
1,35 si cada fc(i) = 5).

6. Multiplicar la respuesta de 5 por el total de puntos de las funciones determinado

previamente (PFI):

TPF = FCT x PFI

La última respuesta (TPF) representa el Total de Puntos de Función para el sistema.

Estimaciones - Conrado Estol - 37 de 37

Una de las debilidades del análisis a través de puntos de función lo constituye la
variación que se produce en los puntajes totales obtenidos por distintas personas para
una misma aplicación. No obstante, muchos proveedores y grupos de usuarios han
refinado las pautas del método, y con una buena capacitación y supervisión ese
problema puede llegar a ser superado.

Hay otras críticas a este método. Sin embargo, si se registran y archivan para referencia
futura los datos relacionados con los distintos esfuerzos de desarrollo que se van
realizando, ese método - como así también los basados en LOC - son importantes para
la estimación del esfuerzo requerido en proyectos de desarrollo.

NOTA:

Si se acepta que los Puntos de Función (PF) pueden realmente representar la

funcionalidad de una aplicación, entonces sería posible medir la productividad de los
programadores de la siguiente manera:

Cantidad de PF implementados / hombre-tiempo

Es interesante notar que esa medida no sólo podría reflejar el valor del producto
resultante sino que también podría en teoría ser utilizada para evaluar la productividad
del personal de desarrollo de sistemas. Por ejemplo, para medir la productividad de la
persona encargada de la Fase X de una aplicación sólo (sólo?) bastaría con calcular la
cantidad de puntos de función para las partes del sistema incluidas en la Fase X.

Un estudio empírico de C. A. Behrens publicado en 1987 y citado por Fenton (14) indica
la cantidad promedio de instrucciones fuente por PF para distintos lenguajes de
programación.

LENGUAJE CANT. INST.

FUENTE x PF
ABAP/4 16
APL 32
ANSI COBOL74 107
Assembler 320
C 128
C++ 55
Pascal Default 91
Perl 27
PowerBuider 16
Smalltalk 21
Visual C++ 34

Estimaciones - Conrado Estol - 38 de 38

B - COCOMO (B. Boehm).

1. Introducción.

Un indicador de costo es una variable objetiva, cuantificable que puede utilizarse para
predecir el costo final (o esfuerzo total requerido) de un programa o de un desarrollo. De
todos los indicadores el más utilizado es el de "líneas de código" (LOC: Lines of Code).

La estimación basada en la cantidad de líneas de programa presenta distintos

inconvenientes. Por ejemplo, los que se indican a continuación:

- La cantidad de líneas de los programas no se puede realmente estimar hasta que no

está finalizado el diseño (y no se puede realmente medir hasta que no se ha completado
el proyecto!);

- Es imprescindible definir un criterio homogéneo sobre qué debe contarse como una
línea (JCL, comentarios, múltiples comandos lógicos en una línea física, definiciones de
datos, encabezamientos);

- La cantidad de líneas para cumplir con un mismo procedimiento o proceso depende

fuertemente del lenguaje que se utilice;

- El costo total puede en cierto casos no ser función directa de la cantidad de líneas (en
lenguajes de alto nivel, para una menor cantidad de líneas puede ser mayor la tasa de
error, con lo que aumenta el costo).

- Se introduce un fuerte sesgo con respecto a la actividad de programación, sin dar

suficiente peso a las tareas de análisis, diseño, pruebas, procedimientos, capacitación,
conversión y documentación que constituyen el mayor porcentaje del proyecto.

No obstante lo anterior, y debido a que son utilizadas en la práctica, y en muchos casos

con buena convergencia con la realidad, a continuación se comentan dos técnicas de
estimación basadas en LOC. Estas técnicas son simples y han servido de base para el
desarrollo de muchos modelos complejos.

2. COCOMO 81.

El Modelo Constructivo de Costos (COnstructive COst MOdel: Ccocomo) fue

desarrollado por Barry W. Boehm (1). Este es uno de los modelos de estimación más
populares. Se centra en el problema de estimar la cantidad final de instrucciones fuente.

Los modelos Cocomo básicos para la predicción del esfuerzo requerido para el
desarrollo de sistemas tienen la siguiente forma general:
b
Esfuerzo = a (tamaño)

donde el esfuerzo se mide en meses-hombre, el tamaño se mide en miles de

instrucciones fuente finales (KDSI: Kilo Delivered Source Instructions). Los valores de a
y b dependen de la modalidad del desarrollo, según se indica más adelante.

Estimaciones - Conrado Estol - 39 de 39

Es importante destacar que se debe distinguir entre la medida de tamaño de programa
mencionada, instrucciones fuente (DSI), y la más usada generalmente de LINEAS de
Código (LOC). Esta última puede definirse de la siguiente manera (aunque hecha esta
aclaración lleguemos a usarlas indistintamente):

"Una línea de código es cualquier línea de un programa que no sea un comentario o una
línea en blanco, sin importar la cantidad de instrucciones o porciones de instrucción en
la línea. Se incluyen específicamente todas las líneas que contienen encabezamientos
de programa, declaraciones y sentencias ejecutables y no ejecutables."

Para la medida de longitud de programas utilizada en Cocomo se han propuesto

muchas definiciones; lamentablemente es muy difícil llegar a una definición no ambigua
de "línea de código" que sea aplicable a cualquier lenguaje de programación.

Las fórmulas utilizadas por Boehm se originan en datos históricos correspondientes a

63 proyectos de distinto tipo pero programados en su mayoría en Fortran o Assembler.

La fórmula del modelo Cocomo que representa el esfuerzo en meses-hombre (MH) en

función de miles de instrucciones fuente (KDSI: Kilo Delivered Source Instructions) es la
siguiente:
b
M = a * KDSI

Donde el coeficiente a y el exponente b quedan determinados empíricamente. Boehm

define tres tipos de proyectos; simplificando su definición podríamos indicarlo de la
siguiente manera:

Simples: a = 2,4 y b = 1,05,

Complejos: a = 3,6 y b = 1,20,

y para los intermedios: a = 3,0 y b = 1,12.

Por ejemplo, si podemos estimar (y aquí tenemos otra estimación!) que para una
determinada aplicación sería razonable esperar (en base a aplicaciones similares de
que tenemos conocimiento) que el total de instrucciones fuentes finales podría ser de
aproximadamente unas 15.000, y el proyecto es de complejidad intermedia, entonces

KDSI o KLOC (para ser más generales) = 15

a = 3,0

b = 1,12 , y

1,12 1,12
KLOC = 15 = 20,8

M = 3,0 * 20,8 = 62,3 Meses-Hombre

Estimaciones - Conrado Estol - 40 de 40

Esta estimación incluye las actividades de administración del proyecto, control de
calidad y documentación.

Debe mencionarse que si bien estudios empíricos han demostrado que existe una
relación proporcional entre esfuerzo y tamaño, existe poca evidencia de que el término
exponencial no pueda llegar a ser igual a 1. Es decir, como una aproximación razonable
podría aceptarse una relación lineal en ciertos ambientes.

De todas maneras, la experiencia nos dice que el elemento predictivo que se utiliza en
estas técnicas (ya sea DSI o LOC) es tan difícil de estimar como el costo mismo de los
programas. En definitiva se corre el riesgo de estar prácticamente "adivinando" la
cantidad de líneas de programa para poder llegar a lo que se denomina un cálculo (que
en realidad no es tal!) del costo de los programas y del proyecto.

Fenton (2) cita un estudio no publicado de Yourdon Inc. sobre la exactitud de las
estimaciones de tamaño producidas por gerentes experimentados. En un experimento
se les pidió a esos gerentes que estimaran el tamaño en LOC de 16 proyectos ya
terminados, basándose solamente en las especificaciones de esos proyectos. Los
promedios de esas estimaciones fueron comparados luego con los tamaños reales (era
proyectos ya finalizados). La desviación promedio entre tamaño real y estimado resultó
ser 64 % del valor real; sólo un 25 % de las estimaciones estuvieron dentro de un rango
de
desvío de 25 % del tamaño real.

Boehm ha propuesto también una ecuación para la estimación de la duración óptima de

un proyecto para un determinado esfuerzo. Esta ecuación tiene la misma forma
funcional de la anterior pero a es 2,5 y b = 0,38, b = 0,35, b = 0,32 para los tres casos
mencionados, respectivamente.

Es interesante mencionar, asimismo, que existe consenso entre los especialistas que
han investigado estos temas en que la duración óptima para un proyecto es
aproximadamente proporcional al esfuerzo elevado a una potencia de 1/3 .

Por último debe agregarse que COCOMO consiste en realidad de tres modelos, que
corresponden a la información disponible en distintas etapas del ciclo de vida del
desarrollo de sistemas. El modelo básico se aplica para obtener estimaciones globales
iniciales; el modelo intermedio, cuando se han identificado los componentes principales
del sistema; el modelo detallado, cuando se cuenta con información sobre componentes
individuales (módulos). El modelo básico es el ya comentado; en el caso de las
estimaciones de los modelos intermedio y detallado, Boehm propone el uso de 15
variables de ajuste para la corrección del modelo básico.

NOTA sobre COCOMO II

Desde la publicación del material anterior, la versión comentada de COCOMO (ahora denominada
COCOMO 81) ha pasado a ser obsoleta con la presentación, en 1995, de la primera versión de
COCOMO II (para ésa y posteriores versiones ver Boehm Barry W. et al: Software Cost Estimation
with COCOMO II, Prentice-Hall, Inc., Upper Saddle River, New Jersey, 2000).

COCOMO II es el último modelo de Boehm desarrollado para tener en cuenta nuevos procesos y
procedimientos. La fórmula general es la siguiente:

Estimaciones - Conrado Estol - 41 de 41

 PM = A x (Tamaño) E x ?(i=1, n) EMi donde

PM: Esfuerzo en meses-hombre

Tamaño: KLOC, UFP (Puntos de Función NO Ajustados)
E = B + 0,01 S (j= 1,n) SFj EM = Effort Multipliers
La fórmula NO incluye el esfuerzo (o tiempo) dedicado a la definición de requerimientos.
Los valores de A y de B son necesarios porque NO existe una relación linear entre la cantidad de
instrucciones y el esfuerzo requerido para producirlas. Se calibran para reflejar la experiencia con el
uso del modelo en un entorno específico.

Scale Factors y Effort Multipliers

Factores de Escala:

Son cinco y reflejan todos los elementos que afectan el tiempo de desarrollo de una aplicación de
tamaño estándar. El modelo incluye una larga lista de reglas para llegar a cada valor.
Similitud con otros proyectos
Flexibilidad en requerimientos
Riesgo
Integración del Equipo
Madurez del Proceso

“Effort Multipliers”
Confiabilidad requerida
Tamaño de la Base de Datos
Complejidad de la programación
Reusabilidad
Documentación
Tiempo de ejecución
Almacenamiento
Volatilidad de la plataforma
Capacidad de los analistas
Capacidad de los programadores
Rotación del personal
Experiencia en el tipo de aplicación
Experiencia con la plataforma
Experiencia en el lenguaje y herramientas
Uso de herramientas de software
Distribución geográfica del equipo
Cronograma requerido.
Factores en COCOMO II – Resumen de las siglas utilizadas en inglés:
PREC - Precedentedness
FLEX - Development Flexibility
RESL - Architecture/Risk Resolution
TEAM - Team Cohesion
PMAT - Process Maturity
RELY - Required Software Reliability
DATA - Database Size
CPLX - Product Complexity
RUSE - Required Reusability
DOCU - Documentation
TIME - Execution Time Constraint
STOR - Main Storage Constraint
PVOL - Platform Volatility

Estimaciones - Conrado Estol - 42 de 42

ACAP - Analyst Capability
PCAP - Programmer Capability
AEXP - Applications Experience
PEXP - Platform Experience
LTEX - Language and Tool Experience
PCON - Personnel Continuity
TOOL - Software Tools
SITE - Multisite Development
SCED - Required Development Schedule
Valores nominales (default)
Para A: 2,94
Para B: 0,91

El producto de los Multiplicadores de Esfuerzo es 1,0

La sumatoria de los Factores de Escala nominales es 18,97

Tiempo de desarrollo:
TDEV = C x PM (D+0,2x(E-B))
C y D son factores de “afinación” y sus valores “nominales” son 3,67 y 0,28, respectivamente.
Ejemplo para un proyecto “nominal” con un tamaño de 100.000 LOC (con valores “nominales” de los
factores de ajuste):
SF = 0,91 + (0,01 x 18,97) = 1,0997

PM = 2,94 x 100 1,0997 x 1 = 465,3 m-h

TDEV = 3,67 x 465,3 (0,28+0,2x(1,0997-0,91)) = 25,9 m

Equipo = 465,3 / 25,9 = 18 personas (aprox.)

COPSEMO (compatibiliza el modelo con con el Rational Unified Process)

CORADMO (para aplicaciones de Rapid Development Process)
COCOTS (uso con componentes COTS)
COLQUALMO (incluye métrica de calidad)
COPROMO (para medir el uso costo-eficacia del uso de nuevas tecnologías).

Estimaciones - Conrado Estol - 43 de 43

El modelo Walston-Felix.

Walston y Felix (3) analizaron 60 proyectos en IBM y propusieron un modelo de

productividad (12) que relaciona el volumen de trabajo (medido en instrucciones fuente -
source instructions) con el esfuerzo requerido medido en meses-hombre. La ecuación
es similar en forma a la de Boehm y es la siguiente:
0,91
M = 5,2 KDSI

donde, usando la misma notación que anteriormente, M se mide en meses-hombre y

KDSI representa miles de instrucciones fuente.

Aplicando esta fórmula al ejemplo del punto 2 obtendríamos el siguiente resultado:

0,91 0,91
M = KDSI = 15 = 11,8

M = 5,2 * 11,8 = 61,1 meses-hombre

En realidad, no se ha pretendido aquí demostrar la muy buena convergencia de este

método y el mencionado en el punto anterior. Simplemente, el valor de Loc (KDSI)
utilizado en el ejemplo es tal que da esa buena correlación. A medida que ese valor de
Loc aumenta, los resultados se van separando; el modelo de Walston y Felix irá dando
valores inferiores al modelo Cocomo para el esfuerzo requerido.

Walston y Felix determinaron en su estudio una muy buena correlación con los
resultados reales de proyectos desarrollados en la Federal Systems Division de IBM.
Debe destacarse que esos investigadores realizaron su estudio en un único ambiente
homogéneo de desarrollo, y aplicando estrictos estándares para el tratamiento de los
datos.

Muchos de los problemas que se presentan en la utilización de este tipo de modelos

quedan resueltos, o minimizados, cuando el ambiente de desarrollo es razonablemente
homogéneo (uniformidad en los datos relevados, proyectos de tipo similar, en general
metodologías y estándares uniformes). Además, pueden aplicarse factores de
corrección para tener en cuenta aquellos elementos que se han truncado para
simplificar la ecuación de estimación. De esa manera, calibrando el modelo para tener
en cuenta el ambiente en que se utilizará, pueden obtenerse buenos resultados.-

Referencias:

(1) Boehm, Barry W., Software Engineering Economics, Prentice-Hall, New Jersey,
1981.

(2) Fenton, Norman E., Software Metrics, Chapman & Hall, London, 1991.

(3) Walston, C.E. y Felix, C.P., "A Method of Programming Measurement and
Estimation," IBM Systems Journal, Vol. 16, No.1, January 1977.

Estimaciones - Conrado Estol - 44 de 44

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

Putnam y Myers, reconociendo la relativa complejidad de la solución de la Ecuación de

Software sin contar con una herramienta de software apropiada, indican un método
manual “muy simple” (1). También, en la misma referencia comentan un método para
estimar proyectos con equipos de trabajo de una, dos, o tres personas solamente (1, p.
238).

1. Calibración.

El propósito es obtener el parámetro de productividad de la organización, PP, en base a

datos obtenidos de proyectos anteriores.
(1/3) (4/3)
PP = SLOC / [(E / B) * td

E, esfuerzo, se refiere al esfuerzo realizado después del estudio de factibilidad y del

diseño funcional, en años-hombre. t es el tiempo calendario de desarrollo en años. B se
obtiene de la tabla ya dada y que se repite aquí:

Tamaño (SLOC) Factor “B”

5-15 L 0,16
20K 0,18
30K 0.28
40K 0,34
50K 0,37
>70 K 0,39

Con el valor de PP obtenido se selecciona el valor más cercano de la Tabla de valores

para PP que dan Putnam y Myers (ver Tabla al final).

Pasando al valor discreto más cercano de la Tabla, dicen Putnam y Myers, se aplica un
modesto valor de corrección para tener en cuenta una cantidad de incertidumbres
(probablemente NO se siguió perfectamente una curva Raleigh - se puede haber
nivelado la cantidad de personal, lo cual produce por lo menos un 10 a 15 % de gasto
de más en esfuerzo -; posiblemente ha habido interrupciones y otros problemas en el
desarrollo del proyecto).

2. Tamaño.

La cantidad de Loc (específicamente instrucciones “fuente”, es decir, SLoc) se estima

solicitando a gente que conoce ese tipo de proyectos dos estimaciones, la optimista
(mínimo posible) “a”, y la pesimista (máxima posible) “b”, para TODO el proyecto:

Con esos valores se calcula el tamaño esperado:

T e = (a + b ) / 2

y también el desvío estándar:

Estimaciones - Conrado Estol - 45 de 45

 Desvío Estándar = ( b - a ) / 6

En la etapa de Diseño Funcional, se hace que la gente más conocedora del tipo de
sistema divida a aplicación en sub sistemas (de 3 a 10) y que de una estimación de
tamaño ”de tres puntos” para cada subsistema:

a = tamaño mínimo posible

m = tamaño más probable

b = tamaño máximo posible

La idea es que desde el mínimo hasta el máximo se cubre un 99 % de los tamaños

posibles.

El tamaño esperado para cada subsistema será:

T e = (a + 4m + b) / 6 SLOC

El desvío estándar :

DE = (b - a) / 6 SLOC

El tamaño esperado del sistema total:

SLOC TOTAL = Te1 + Te2 + .... + T en

EI el desvío estándar total:

(1/2)
DE T = (DE 12 + DE 22 + . . . + Den2 )

3. Estimaciones

a) Tiempo mínimo para el desarrollo:

,43
t min = 8,14 (LOC / PP ) 0 en meses, para t min > 6 meses

b) Esfuerzo (El máximo que debería ser invertido):

3
E = 180 B (tmin) en meses-hombre, donde tmin es en años

y válido para E => 20 meses-hombre

c) Costo:

COSTO $ = ( $ / MH ) * E E en meses-hombre

$ / MH = Promedio con cargas sociales, y costos indirectos, del

personal que será asignado al proyecto (Para EE.UU., Putnam y Myers dicen que este
valor debería ser superior a $150.000 para que el método sea válido).

Estimaciones - Conrado Estol - 46 de 46

Este método permite también determinar:

d) Momento de aplicación máxima de recursos (“Peak Manpower Time):

e) Cantidad máxima de recursos aplicados (Peak Manpower):

f) Cantidad promedio de recursos (“Average Manpower”).-

Referencia:

(1) Putnam, Lawrence H. & Ware Myers, Measures for Excellence - RelIable Software
on Time, Within Budget, Prentice-Hall, Inc., 1992, Englewood Cliffs, NJ 07632, EE.UU.,
Cap. 14, p. 215.

Estimaciones - Conrado Estol - 47 de 47

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

Esta técnica se ha utilizado para estimar el esfuerzo de programación. Cuando se

empleaba se lo hacía en conjunto con la extrapolación a todo un proyecto en forma
similar al método usado en las técnicas "C" o "D". Se supone que la definición de la
aplicación es tal que se puede identificar adecuadamente cada uno de los programas
que componen esa aplicación.

Como primer paso, los programas de cada subsistema se clasifican en distintos tipos.
Por ejemplo, esos tipos podrían ser los caracterizados por los siguientes elementos:

-En línea
-Batch
-Listados
-Menúes.

A su vez, dentro de cada tipo se establecen niveles de dificultad. Por ejemplo:

-Simples
-Promedio
-Complejos.

Debería definirse, con ejemplos, lo que debe entenderse por cada nivel de complejidad
(Por ejemplo, para programas "En Línea" se considerarán como "Simples" los que
manejan una sola pantalla, aceptan y despliegan información, tienen no más de unas
200 líneas de instrucciones; serán "Complejos" los que manejan varias pantallas,
realizan una validación compleja y múltiples actualizaciones.

Se agrupan los programas de similar dificultad y similar tipo y se usan los estándares
por tipo y dificultad que se hayan definido para obtener un total de horas para
programación (incluidas las pruebas unitarias).

A continuación se incluyen dos tablas como ejemplos de estándares de horas de

programación para ADABAS NATURAL y para COBOL CICS. (Los estándares
indicados deberían ser reemplazados por estándares propios a medida que se vaya
contando con información histórica que se vaya acumulando sobre distintos
desarrollos).

1. ESTANDARES EN HORAS-HOMBRE PARA ADABAS NATURAL

SIMPLE PROMEDIO COMPLEJO

En Línea 11 28 56

Batch 11 28 56

Estimaciones - Conrado Estol - 48 de 48

 Listados 14 28 56

Menúes 7 14 28

2. ESTANDARES EN HORAS-HOMBRE PARA COBOL CICS

SIMPLE PROMEDIO COMPLEJO

En Línea 35 56 70

Menúes 21 49 70

NOTAS:

1. Las horas que se indican como estándares deben tomarse sólo como ejemplos y
deben ser calibradas para cada ambiente de desarrollo específico..

2. Se han considerado 7 horas por día de trabajo y se ha supuesto una asignación

mínima de medio día de trabajo (redondeado en horas hacia arriba).

3. Los estándares incluyen programación y pruebas unitarias.

4. Para aquellos programas que tengan una estructura muy similar a la de otros que se
puedan tomar como modelo, los tiempos deberían reducirse apreciablemente.-

5. Debe tenerse en cuenta que éste es un “método” muy aproximado y muy fácilmente
sujeto a errores.

Estimaciones - Conrado Estol - 49 de 49

E - TECNICA BASADA EN LA DURACION DE ENTREVISTAS.

1 - Promedio porcentual definido para cada una de las fases del desarrollo

Muchas metodologías de desarrollo de aplicaciones están estructuradas en cuatro

etapas básicas que son:

- Análisis
- Diseño
- Construcción
- Implantación

Es común también subdividir cada etapa en varias fases y estas en actividades y

subactividades. A continuación se incluye una tabla con las etapas y fases de un posible
ciclo de desarrollo de sistemas con el porcentaje del esfuerzo total que en promedio
puede requerir cada una de esas fases.
En la práctica, las etapas y fases para el ciclo de vida y de desarrollo deben ser las
utilizadas en la Empresa y los porcentajes individuales deben surgir de los registros
históricos que se mantengan sobre los proyectos de desarrollo.

Estimaciones - Conrado Estol - 50 de 50

TABLA N° 1

EJMPLO DE ESFUERZO PORCENTUAL PROMEDIO DE LAS FASES DE LA

METODOLOGÍA DE DESARROLLO (Debe ser adaptado a cada ambiente específico)

% Total del Proyecto

FASES DE LA METODOLOGÍA ETAPA FASE

ANÁLISIS 20

A. Estudio de Factibilidad y
B. Resumen General del Sistema 2
C. Definición de Procesos 8
D. Prototipo de Requerimientos 3
E. Definición de Datos 4
F. Definición de Tecnología 1
G. Verificación de Análisis 2

DISEÑO 20

H. Diseño de Procesos 9
I. Diseño de Datos 7
J. Diseño de Tecnología 2
K. Verificación del Diseño 2

CONSTRUCCIÓN 46

L. Procedimientos de Usuario 9
M. Generación de Programas y/o
N. Diseño de Programas 4
O. Codificación de Programas 9
P. Pruebas Unitarias 9
Q. Prueba del Sistema 15

IMPLANTACIÓN 14

R. Entrenamiento 5
S. Conversión de Datos 5
T. Implant. y Recep. del Sistema 3
U. Revisión Post-implantación 1
100% 100%

NOTA: Los porcentajes deben ser calibrados para cada ambiente específico.

Estimaciones - Conrado Estol - 51 de 51

La metodología de estimación descrita a continuación, tiene su origen en el principio
generalmente aceptado de que la etapa de análisis de un sistema de información,
representa un porcentaje conocido dentro del proceso de desarrollo. Según la tabla
anterior, la interacción con los usuarios para definir sus requerimientos (fases A, B y C)
representa el 10% del esfuerzo total del proyecto.

2. Duración de las entrevistas con los usuarios

Un enfoque práctico es adoptar la entrevista como principal técnica para la definición de

requerimientos de un sistema, para lo cual se clasifican los usuarios en dos tipos que se
definen así:

Usuarios Primarios

Son los más importante del sistema, se supone que son los que pueden definir con
seguridad y autoridad sus características fundamentales. Generalmente son
funcionarios de un nivel medio-alto dentro de la organización.

Usuarios Secundarios

Son personas que utilizan regularmente el sistema en un nivel operativo y por lo tanto no
tienen una visión global de éste, pero suministran aportes importantes en el nivel de
detalle en los procesos más comúnmente utilizados por ellos. Generalmente son
funcionarios de un nivel medio-bajo dentro de la organización.

Entrevistas

Para cada uno de estos usuarios se debe preparar un tipo de entrevista diferente,
asignando una mayor cantidad de tiempo a los usuarios primarios.

A las entrevistas con los usuarios primarios se les puede definir, por ejemplo, una
duración de 16 horas y a los usuarios secundarios una duración de 4 horas.
Adicionalmente, se supone que a cada entrevista asisten 2 personas del grupo
encargado de realizar el proyecto, lo cual implica que la estimación real es de 32 horas
para entrevistas a usuarios primarios y 8 horas a usuarios secundarios. Estas
duraciones estándar se deberán ir ajustando en base a la experiencia que se vaya
recogiendo en el uso de esta técnica.

3. Determinación de la cantidad de entrevistas

Para determinar la cantidad de entrevistas a llevar a cabo en cada sistema de

información, se toman como base dos parámetros importantes de cada aplicación: el
número de procesos administrativos que se ven influidos por la aplicación y el número
de funciones del negocio afectadas.

Cabe acotar que en algunos casos y debido a la importancia y complejidad de una

función, puede ser necesario programar dos o más entrevistas con el mismo usuario
primario. Por lo tanto, el número de entrevistas puede llegar a ser superior al número de
usuarios de un sistema.

Estimaciones - Conrado Estol - 52 de 52

4. Esfuerzo requerido para desarrollar el proyecto

La fórmula que suministra el número de horas-hombre estimado para llevar a cabo el

proyecto es la siguiente:

Esfuerzo en horas-hombre = (CEUP * 32 + CEUS * 8) * 10

Donde:

CEUP = Cantidad de entrevistas con usuarios primarios

"32" = Horas-hombre estimadas para personal de sistemas (no incluye horas-hombre

del usuario) por entrevista primaria

CEUS = Cantidad de entrevistas con usuarios secundarios

"8" = Horas-hombre estimadas para personal de sistemas (no incluye horas-hombre del
usuario) por entrevista secundaria

"10" = Factor de extrapolación para considerar el esfuerzo requerido por TODO el

proyecto (ya que las fases A, B y C representan un 10% del proyecto según la tabla 1).

Esta fórmula permite calcular una primera estimación del esfuerzo de desarrollo que
deberá luego ser sometido a ajustes de acuerdo con las características del proyecto.

5. Ajustes a la estimación del esfuerzo requerido para desarrollar el proyecto

Una vez que se ha calculado el esfuerzo nominal en horas-hombre requerido para

desarrollar el proyecto, es necesario someter esta cifra estimada a una serie de ajustes
con el fin de hacerla más cercana a la realidad.

El proceso consiste en multiplicar sucesivamente el esfuerzo nominal en horas-hombre

por un factor que se establece en cada tipo de ajuste. Se incluyen a continuación cinco
tipos de ajuste y a medida que se gane experiencia en el uso de esta técnica podrán irse
ajustando los respectivos factores multiplicadores.

5.1. Ajuste por integración

En este primer ajuste se identifica la relación que la aplicación va a tener con otros
sistemas; esta relación implica un esfuerzo adicional de desarrollo dependiendo de si la
aplicación es independiente, con interface o integrada.

Los factores de ajuste pueden ser los siguientes:

Estimaciones - Conrado Estol - 53 de 53

Aplicación Factor Multiplicador
Independiente 1,0
Interfaz 1,1
Integrada 1,3

5.2. Ajuste por tipo de lenguaje de programación

Las características del lenguaje de programación usado es un factor que puede acelerar
o retrasar el desarrollo de una aplicación.

Los factores de ajuste son los siguientes:

Lenguaje Factor Multiplicador

Cuarta Generación (4GL) 0,75

Comercial Convencional (COBOL) 1,0
Técnico Específico 1,2

Como todos los otros coeficientes mencionados aquí, los factores específicos en cada
caso deberán ser ajustados con el tiempo. De allí la importancia de mantener registros
adecuados y una "base de datos" sobre los desarrollos realizados.

5.3. Ajuste por complejidad del sistema

Como todas las aplicaciones no tienen las mismas características de complejidad, es

necesario hacer un ajuste con base en el conocimiento inicial que se tenga de las
funciones del futuro sistema.

Los dos puntos anteriores contienen factores de corrección con los que se trata de
ajustar el esfuerzo de implementación basado en su integración con otras aplicaciones y
el lenguaje a utilizar para su desarrollo. En el caso del ajuste por "complejidad", se trata
de ajustar de acuerdo con las características y procesos de las funciones que cubrirá el
nuevo sistema.

Los factores de ajuste son los siguientes:

Complejidad Factor Multiplicador

Aplicación Compleja 1,3

Aplicación Normal 1,0
Aplicación Fácil 0,75

Estimaciones - Conrado Estol - 54 de 54

5.4.Ajuste por experiencia del grupo del proyecto

La experiencia de las personas involucradas en el desarrollo de una aplicación es un

factor que debe considerarse por separado ya que puede afectar la duración (y
ciertamente también la calidad) de un proyecto.

Los factores de ajuste son los siguientes:

Experiencia Factor Multiplicador

Personal con mucha experiencia 0,25/0,75

Personal con mediana experiencia 0,75/1,25
Personal sin experiencia 1,25/1,75

5.5. Ajuste por tipo de proyecto (migración y mejoras)

Se considera que el esfuerzo requerido para llevar a cabo una migración y mejoras a
una aplicación, es un porcentaje del necesario para desarrollarlo como sistema nuevo.

Realizar la migración y mejoras de una aplicación requiere un esfuerzo diferente,

dependiendo de las nuevas funciones o cambios requeridos.

Los factores de ajuste por tipo de mejora son los siguientes:

Tipo de Mejora Factor Multiplicador

Grande 0,70
Mediana 0,50
Pequeña 0,30

Lo anterior indica que las estimaciones del esfuerzo requerido en un proyecto tipo
migración y mejoras, se hacen normalmente como si se fuera a desarrollar
completamente la aplicación y posteriormente se le aplica el ajuste definido en este
punto.

6. Cantidad de personal

Con la cantidad de horas-hombre de esfuerzo estimado para el desarrollo del proyecto,

ajustada según los factores expuestos en los puntos anteriores, queda por definir el
número de personas que participarán en el desarrollo del proyecto y su duración en
meses.

Estimaciones - Conrado Estol - 55 de 55

A medida que un proyecto pasa de cierto número de horas puede ser conveniente
aumentar el número de integrantes del grupo del proyecto para evitar así que se extienda
demasiado en el tiempo.

La tabla que se muestra a continuación podría servir como referencia para definir el
tamaño del equipo del proyecto y la duración del desarrollo en meses (donde el tamaño
de la aplicación, de pequeña a muy grande, se ha representado con números del 1 al 5)

Tamaño de la Esfuerzo Duración Tamaño del

Aplicación en Horas en Meses Equipo del
Proyecto

1 1200 4 2
2 3400 8 3
3 7000 12 4
4 13000 18 5
5 24000 24 7

Para conformar esta tabla se supuso que la cantidad de horas efectivas trabajadas por
un integrante del grupo es de 145 por mes. Esta cantidad deberá ser ajustada en función
de la experiencia que se obtenga en la instalación y en conjunto con el punto 7.

La forma de utilización de esta tabla de referencia para estimar la duración y el tamaño

del equipo del proyecto es la siguiente:

- El tamaño del equipo del proyecto se mantiene constante a partir del esfuerzo en horas
del renglón en que aparece, hasta el esfuerzo del siguiente renglón de la tabla. Por
ejemplo, a un proyecto que tenga un esfuerzo comprendido entre el rango de 3.400 a
7.000 horas se le asignarán tres personas.

- La duración de un proyecto es variable según el esfuerzo en horas y el número de

personas asignadas a él. Por ejemplo, a un proyecto con esfuerzo de 5.000 horas se le
asignarán tres personas y tendrá una duración de 12 meses.

Esta duración se calcula teniendo en cuenta que una persona trabajará en promedio
unas 145 horas al mes y por lo tanto el grupo de tres personas podrá trabajar 435 horas
mensuales. Por lo tanto, la diferencia entre 3.400 y 5.000 la ejecutarán en 4 meses,
aproximadamente.

En consecuencia, la duración del proyecto será la suma de la columna DURACIÓN EN

MESES correspondientes al renglón de 3.400 horas, más los 4 meses calculados según
el párrafo anterior. Esto da una duración de 12 meses.

- Se ha elegido trabajar con duración variable ya que es preferible en general en

proyectos de desarrollo de software aumentar el tiempo que incrementar el número de
personas Recordar la "Ley de Brooks": "Adding manpower to a late software project
makes it later".

Estimaciones - Conrado Estol - 56 de 56

Esto se debe a la naturaleza propia de este tipo de proyectos, en los que hay actividades
que requieren duraciones mínimas de tiempo (por ejemplo el análisis) y que no se
pueden llevar a cabo más rápidamente así se incremente el número de personas.

7. Ajuste a la duración (plazo) de los proyectos de desarrollo interno

Con respecto al plazo de ejecución o duración del proyecto, se debería aplicar un factor
de ajuste de por ejemplo 1,2 para tener en cuenta la incidencia de una potencial rotación
de personal y asignaciones transitorias a otras actividades, particularmente al
mantenimiento de aplicaciones.

Este ajuste no modifica el esfuerzo requerido en horas-hombre, pero sí incrementa la

duración de los proyectos.

Por ejemplo, si para pasar de las horas nominales ( 8 horas diarias por 21 días promedio
en el mes, es decir 170 horas aproximadamente) a las horas "efectivas" consideramos
los siguientes elementos:

Hs. "promedio"
Elemento a considerar % Promedio mensuales

Vacaciones 6,0 10,0

Capacitación 5,0 8,5
Enfermedad 1,0 / 2,0 2,5
Permisos 0,5 / 1,0 1,0
Varios (tareas administrativas) 2,0 3,4

Totales 14,5 / 16,0 25,0

Llegamos así a las 145 horas "efectivas" mensuales (170-25 = 145). En el caso de que
para el cálculo de las horas "efectivas" no se tome en cuenta alguno de los elementos
indicados, o se agregue otro, deberá entonces verificarse si no corresponde modificar el
factor de ajuste utilizado para corregir la duración del proyecto.-

Estimaciones - Conrado Estol - 57 de 57

F - TECNICA GENERAL DE EXTRAPOLACION

Esta técnica puede ser considerada como una generalización de la técnica "E" y como
una aproximación simplificada a la estimación de tiempos y personal requerido para el
desarrollo de una aplicación.

Se puede encontrar en la literatura, referencias a enfoques simplificados de ese tipo -

que pueden presentarse con variantes - como aproximación práctica para la estimación
del esfuerzo o costo de un proyecto (siempre válido en el entendimiento de que existirá
otro método y/o grupo que servirá para obtener una estimación alternativa, como
verificación de razonabilidad y para eventualmente poder llegar a un valor final a través
de un proceso iterativo de correcciones).

En la práctica, todo proceso de estimación es iterativo. Debe tenerse en cuenta que la

forma en que se usarán las pautas o guías adoptadas variará de proyecto a proyecto. No
obstante, los pasos a seguir que se indican más adelante son típicos de muchos
proyectos y pueden servir como modelo.

La premisa es que ya han tenido lugar reuniones y/o conversaciones con

usuarios/clientes y que sobre la base de esas conversaciones debe elaborarse un
documento o propuesta para un proyecto de desarrollo de sistemas.

Para la estimación en particular, los grandes pasos a seguir son los siguientes:

1. Seleccionar la fase del proyecto sobre la que se posea al mayor cantidad de

información (normalmente esa fase será la el estudio de factibilidad o el resumen del
sistema);

2. Identificar las tareas que puedan haber sido modificadas o que requieran un distinto
nivel de esfuerzo para su realización;

3. Calcular un esfuerzo (duración y recursos necesarios) estimativo para cada tarea y

sumar esos tiempos y costos para obtener un total general para la fase (puede ser útil
utilizar aquí una técnica probabilística como el Pert);

4. Determinar si es necesario ajustar esos tiempos teniendo en cuenta el nivel de

experiencia de los recursos humanos disponibles o la complejidad del proyecto (ver más
adelante);

5. Ajustar en un 15 % adicional el tiempo total obtenido en 4, para tener en cuenta el

tiempo requerido para la administración del proyecto;

6. Consultar los valores de las pautas de estimación porcentual que existan para las
distintas fases del proyecto y obtener, extrapolando, un total general para el proyecto
(representa el total de Meses-Hombre u Horas-Hombre y puede utilizarse para calcular
costos totales para el proyecto);

7. Aplicar al total de Horas-Hombre los recursos realmente disponibles (es decir, los
grupos de desarrollo con que se cuenta) para obtener los plazos calendario en que

Estimaciones - Conrado Estol - 58 de 58

podría desarrollarse el proyecto. Tener en cuenta las inter dependencias y precedencias
entre las distintas actividades y la posibilidad de realizar tareas en paralelo.

Los pasos mencionados permitirán llegar a una estimación inicial del esfuerzo requerido
para llevar a cabo el proyecto.

En este momento es imprescindible revisar cuidadosamente todas las cantidades y

cálculos. Esa tarea debe cumplirla preferentemente otra persona o grupo. Además, en
todos los casos en que sea posible se deberá utilizar otro método alternativo (o métodos
alternativos) para llegar a otra estimación que pueda servir como elemento de
comparación para verificar la racionabilidad de los valores obtenidos.

A continuación se indican factores de corrección por experiencia del personal que

pueden tomarse como ejemplo Notar que aquí se utilizan rangos más amplios de
corrección que en los empleados en la técnica del Apéndice C; en última instancia,
estos rangos deberán ser corregidos según la experiencia práctica que se vaya
obteniendo).

-Personal con poca experiencia (aproximadamente 1 año de experiencia en trabajos en

Tecnología de la Información),

Coeficiente: 1,50 más/menos un 20 % según vaya de 6 meses a dos años de

experiencia;

-Personal con experiencia promedio (aproximadamente 2 a 5 años),

Coeficiente: 1,00 más/menos un 20 % según tenga un mínimo de 2 años o un

máximo de 5 años de experiencia;

-Personal de nivel superior (mínimo de 5 años de experiencia en el tipo de trabajo

definido en la tarea),

Coeficiente: 0,50 más/menos un 50 % según la real experiencia en el tema

específico de que se trate.

Puede ser aquí interesante ilustrar el procedimiento comentado anteriormente con un

muy simple ejemplo, que damos a continuación:

Una empresa cuenta con la siguiente información, producto del promedio histórico para
10 proyectos anteriores, relacionada con el porcentaje de esfuerzo requerido para cada
una de las fases en que se divide el ciclo de vida de sistemas en la metodología utilizada
para desarrollo de sistemas:

FASE 1 2 3 4 5 6 7

Porcentaje 4 8 18 20 25 15 10 = 100 %

En base a relevamientos detallados y experiencia anterior, se ha estimado que la Fase 4

de un nuevo proyecto requerirían, nominalmente, unas 1200 horas-hombre de trabajo.

Estimaciones - Conrado Estol - 59 de 59

Para la realización de este proyecto se cuenta con personal con una experiencia
promedio de solamente un (1) año en esas tareas.

Estimar el esfuerzo en horas-hombre (h-h) que se puede pronosticar en una primera

aproximación para este proyecto.

1. Esfuerzo para la Fase 4: 1200 h-h

2. Ajuste por experiencia del personal

Poca experiencia, coeficiente de 1,20 a 1,80; tomar 1,50.

1,50 x 1200 h-h = 1800 h-h

3. Ajuste para tener en cuenta tiempo para la administración del proyecto

Ajuste de 15 %:

1.15 x 1800 h-h = 2070 h-h

4. Extrapolar el esfuerzo de la Fase 4 a todo el proyecto sobre la base de los datos

históricos proporcionados en el planteo:

Fase 4 = 20 % (0,20) del proyecto = 2070 h-h

Fases 1 a 7 = 100% (1,00) del proyecto. Entonces

0,20 / 2070 h-h = 1 / x ; donde x es el esfuerzo total.

x = 2070 h-h / 0.20 = 10350 h-h.-

NOTA: Como ya se ha mencionado, estos métodos son sólo aproximaciones y deben

verificarse con alguna generalmente aceptada.

Estimaciones - Conrado Estol - 60 de 60

G - TÉCNICA “DELPHI”

Según citada por Fenton (1), la estimación por Grupos puede ser realizada con una
técnica Délfica. En resumen el procedimiento indicado es el de distribuir entre
especialistas las especificaciones del proyecto y toda otra información que pueda existir.
Luego se reúne a esos expertos para discutir el tema y hacer que cada uno, en forma
anónima, presente sus estimaciones, dando un valor más probable y un valor extremo
superior e inferior. El coordinador del grupo reúne las estimaciones y las vuelve a
distribuir (dando un promedio y las estimaciones individuales). Y así sucesivamente
hasta llegar a un razonable consenso.

Es interesante mencionar que se ha sugerido que las estimaciones promedio del grupo
no deberían ser un simple promedio de las estimaciones individuales. Se propone que
sean calculadas según una ponderación basada en la siguiente fórmula (aproximación a
la distribución Beta, también usada en PERT):

Lim. Inf. + 4 (Valor Más Frec.) + Lím. Sup.

Estimación =
6

El valor de la estimación del grupo es el promedio de las estimaciones individuales

ponderadas con esa fórmula. La varianza de una estimación individual se obtiene con la
siguiente fórmula:

Lím. Superior - Lím. Inferior

Varianza =
6

La varianza de la estimación del grupo es el promedio de las varianzas individuales.

Aquellos que estén familiarizados con las estimaciones y cálculos del PERT notarán que
las fórmulas dadas aquí son las mismas que las utilizadas en ese método (una
simplificación de la fórmula para la distribución Beta).

NOTA:
Conrado Estol es ingeniero aeronáutico (Master, New York University. EE.UU.) y Doctor en Ciencias de la Administración
por la Universidad de Belgrano, Buenos Aires, Argentina). Profesor Distinguido de la Universidad Católica Argentina
(UCA).

Estimaciones - Conrado Estol - 61 de 61