Estimación
Una estimación precisa de la planificación
¾ Historia de la estimación del software
¾ Introducción al proceso de estimación
¾ Estimación del tamaño
¾ Estimación del esfuerzo
¾ Estimación de la planificación
¾ Estimaciones simples de planificación
¾ Refinamiento de las estimaciones
Historia de la estimación
del software
La estimación del software es difícil, y lo que
algunas personas intentan hacer con ella no
es ni siquiera teóricamente posible. Los
altos cargos, los ejecutivos, los clientes y
algunos desarrolladores no parecen
entender por qué la estimación es tan difícil.
Las personas que no entienden las
dificultades inherentes a la estimación del
software pueden, de forma involuntaria,
hacerla incluso más difícil de lo que ya es.
Historia de la estimación
del software
La estimación del tiempo y del esfuerzo
necesarios para construir el software
también es borrosa, debido a que la imagen
del software que se está intentando construir
lo es.La estimación se puede enfocar junto
con el software, lo que significa que la
estimación del proyecto del software es
también un proceso de refinamiento gradual.
Estimación
constituye una de las bases para obtener
una velocidad máxima de desarrollo. Sin
una estimación precisa de la planificación,
no se establecen las bases para una
planificación efectiva, y no hay soporte para
el desarrollo rápido. Alcanzar una
estimación perfecta no es suficiente si la
estimación no es aceptada.
Historia de la estimación
del software
Las personas recuerdan mejor las historias que los
hechos aislados, y hay una historia que se debe
contar para explicar por qué la estimación del
software es tan difícil.
El argumento básico de la estimación del software es
que el desarrollo del software es un proceso de
refinamiento gradual. Se comienza con una
imagen borrosa de lo que se desea construir, y se
pasa el resto del proyecto intentando aclarar esa
imagen.
Historia de la estimación
del software
Software y construcción
Es difícil saber si es posible construir el producto que
el cliente desea en el tiempo esperado hasta que
se comprenda perfectamente lo que el cliente
quiere.
El desarrollo del software como un proceso de
refinamiento
Depende de como sea el sistema. Algunas
organizaciones desean estimar el costo con un
margen de un 10 por 100, además antes de
trabajar en la definición de requerimientos»
1
 Historia de la estimación
del software
Aunque sería interesante tener ese grado de
precisión al comienzo del proyecto, no es
teóricamente posible. Al principio, se realizará una
buena estimación con un factor 2.
No se puede estimar con precisión el costo del
programa hasta que se comprenda con detalle
cada una de las prestaciones. El desarrollo del
software es un proceso en el que se van tomando
decisiones cada vez más detalladas.
Historia de la estimación
del software
A continuación se muestran algunos ejemplos de la
clase de preguntas que aportan incertidumbre a la
estimación:
• ¿Deseará el cliente la prestación X?
• ¿Deseará el cliente una versión cara o económica
de la prestación X? Normalmente hay al menos un
factor de diferencia 10 en la dificultad de la
implementación de las diferentes versiones de la
misma prestación.
Historia de la estimación
del software
• ¿Cuánto tiempo se tardará en depurar y corregir los
errores cometidos en la implementación de la
prestación X? Dependiendo del programador, aun
teniendo el mismo nivel de experiencia, el
rendimiento en la depuración y corrección de los
mismos problemas puede variar con un factor de
10.
• ¿Cuánto tiempo se empleará en integrar la
prestación X con las demás prestaciones?
Historia de la estimación
del software
El concepto del producto se refina en la fase de
requerimientos, los requerimientos en el diseño
preliminar, el diseño preliminar en el diseño
detallado y el diseño detallado en el código. En
cada una de estas fases se toman decisiones que
afectan al costo final y a la planificación del
proyecto. La incertidumbre sobre la naturaleza del
producto aporta incertidumbre a la estimación, ya
que no se pueden conocer las decisiones que se
van a tomar hasta que no se tomen.)
Historia de la estimación
del software
• Si se implementa la versión económica de la
prestación X, ¿deseará el cliente implementar la
versión cara después de todo?
• ¿Cómo diseñará la prestación X? Normalmente hay
un factor de diferencia 10 en la complejidad del
diseño de los diferentes tipos para la misma
prestación.
• ¿Cuál será el nivel de calidad de la prestación X?
Dependiendo de la atención que se preste durante
la implementación, puede haber un factor de
diferencia 10 en el número de defectos contenidos
en la implementación original.
Historia de la estimación
del software
Como se puede observar, la incertidumbre sobre una
sola prestación puede introducir bastante duda en
la estimación inicial del proyecto. Multiplicado a lo
largo de todo el proyecto, se realizarán miles de
decisiones sobre especificaciones, diseño e
implementación antes de determinar el costo final
del proyecto. Sin embargo, conforme aumenta el
porcentaje de decisiones tomadas, se puede afinar
el rango de estimación.
2
 Historia de la estimación Gráfica de Convergencia
del software de estimación
Cantidad de refinamiento posible
Los investigadores han descubierto que las
estimaciones de proyectos entran dentro de
precisiones previsibles en varios estados del
proyecto.

En el momento que se pide a los desarrolladores

que den una estimación bruta, puede haber un
factor de diferencia de 16 entre la mayor y la
menor estimación del esfuerzo.

Historia de la estimación Historia de la estimación

del software del software
Esfuerzo y tamaño Planificación Incluso después de finalizar los requerimientos, sólo
FASE Optinista Pesimista Optimista Pesimista se puede saber la cantidad del esfuerzo necesario
Concepto inicial del 0.25 4.0 0.60 1.60 en un 50 por 100, y en la mayoría de las
producto organizaciones desean que esa estimación se dé
Concepto del producto 0.50 2.0 0.80 1.25
aprobado
en dólares.
Especificación de 0.67 1.5 0.85 1.15
requerimientos
La estimación del proyecto debería comenzar de
Especificación del diseño 0.80 1.25 0.90 1.10
del producto forma muy general e ir refinándose conforme
Especificación del diseño 0.90 1.10 0.95 1.05 avanza el proyecto.
detallado

Historia de la estimación Historia de la estimación

del software
Los intervalos son amplios, pero, aun así, hay
algunos casos extremos que no estarán dentro.
Para utilizar los factores de la tabla, simplemente se
multiplica la estimación puntual «más probable»
por el factor optimista para obtener la estimación
optimista, y por el factor pesimista para obtener la
estimación pesimista. La estimación se puede
presentar entonces como un intervalo en lugar de
como un punto de estimación.
del software
Si la estimación «más probable» es de 50 personas-
mes y ya se ha finalizado la especificación de los
requerimientos, habría que multiplicar por 0,67 y
1,5 y estimar un intervalo de 34 a 75 personas-
mes. A veces los clientes insistirán en que se les
dé una estimación «más probable», y habrá que
dársela. Pero si esto no sucede, no es necesario
publicar un único punto de estimación, excepto en
las notas personales.

3
 Historia de la estimación
del software
Estimación frente a control
La mayoría de los clientes de software desean
inicialmente más de lo que se pueden permitir. Los
clientes tienen que adaptar sus ideas sobre el
producto a los recursos con los que están
dispuestos a comprometerse. A veces el cliente
deseará adaptar tanto los recursos como el
conjunto de prestaciones para llegar a un acuerdo
entre ambos.
Historia de la estimación
del software
Los constructores del software eligen entre la
exactitud de la estimación y el control del proyecto.
Si se puede ser flexible en cuanto a las
características del producto, se puede tener cierto
control sobre el costo y la planificación y se puede
«desarrollar según el presupuesto». Pero cada vez
que haya que elegir entre incorporar una
prestación o dejarla fuera, se tendrá que dejar
fuera. Cada vez que haya que escoger entre
implementar la mejor prestación o una de menor
costo, habrá que elegir la de menor costo.
Historia de la estimación
del software
Cooperación
La historia de la estimación se ha centrado en indicar
las razones por las que no se puede dar una
estimación tan precisa como se desearía. Éstas
son razones interesantes; sin embargo, las
personas que deseen una estimación precisa
también tienen buenas razones para esperarla, y
hay que pensar que se tiene la responsabilidad de
ofrecer tanta información como se pueda.
Historia de la estimación
del software
Historia de la estimación
del software
Y habrá que seguir el patrón firmemente. Si unas
veces se implementan las mejores prestaciones y
otras veces las de menor costo, no se estará
desarrollando el presupuesto. Se está haciendo un
desarrollo del software normal. Si no se pueden
aceptar la disciplina y los compromisos implicados
en la aproximación a la construcción del
presupuesto, simplemente se tendrá que aceptar
mucha imprecisión en la estimación inicial del
proyecto.
Historia de la estimación
del software
Se debe ayudar a los clientes indicándoles las partes
del proyecto que hay posibilidad de estimar. Si hay
posibilidad de estimar el final de la fase en curso,
lo mejor es decírselo. También hay que decirle
cuándo se tiene una mejor estimación. No se debe
dejar que se sientan completamente perdidos. Hay
que indicarles dónde está el siguiente hecho
importante.
Hay que hacerle comprender al cliente la estrategia
a seguir, según el conjunto de estimaciones que
se intenten proporcionar.
4
 Historia de la estimación
del software
Comentarle que se actualizarán las estimaciones al
final de las fases de definición del producto,
especificación de requerimientos, diseño del
producto y diseño detallado. Intente preparar el
presupuesto, si eso le ayuda, pero hay que
asegurarse de que los clientes comprendan todos
los compromisos que supone esa aproximación.
Si los clientes aún preguntan por una estimación
más precisa de la que se les ha proporcionado, se
debe decir que no puede dar porque aún no se
conoce. Pero dejar bien claro que se desea
colaborar.
Historia de la estimación
del software
Historia de la estimación
del software
Cuanto antes se junten los dos caminos,
podrán tomarse mejores decisiones sobre la
gestión y el producto; la planificación del
proyecto y sus interdependencias será más
ajustada; se podrá dar una mejor relación
entre los desarrolladores, gestores, clientes,
vendedores y usuarios finales; se podrá
alcanzar una mayor velocidad de desarrollo.
Historia de la estimación
del software
Convergencia entre estimación y realidad
Los clientes también tienen que cooperar. Si los
clientes desean la planificación más corta posible,
no deberían presionar para reducir la estimación o
proporcionar unas estimaciones precisas
equivocadas.
La planificación real más corta resulta de la
programación planificada más precisa. Si la
estimación es demasiado baja, la planificación
ineficiente conducirá al costo real del proyecto.
Historia de la estimación
del software
Si la estimación es demasiado alta, según la ley de
Parkinson (el trabajo se reparte para cubrir el
tiempo disponible), conducirá al costo real del
proyecto.
El truco consiste en no realizar la estimación ni
demasiado alta ni demasiado baja, sino en el
punto exacto. El objetivo de la estimación consiste
en buscar la convergencia entre la estimación y la
realidad. Por definición, la estimación y la realidad
convergen en la entrega del software.
Historia de la estimación
del software
Resumen
Para contar la historia de la estimación, es necesario
explicar estos cuatro puntos:
• En la construir el software no se puede decir con
exactitud cuánto va a costar hasta que no se
conozca con exactitud cómo va a ser.
• Si se desea construir según un presupuesto, hay
que ser flexible en cuanto a las características del
productor
5
 Historia de la estimación
del software
• Tanto si se construye según un presupuesto o no,
el desarrollo del software es un proceso de
refinamiento gradual, de forma que es inevitable
que se produzca alguna imprecisión. En el
software la única forma de refinar el concepto del
producto, y por lo tanto la estimación, es
construyendo el software.
• La estimación se puede ir refinando a lo largo del
proyector Se puede prometer al cliente que en
cada paso se irá dando una estimación más
refinada.
Introducción al proceso de
estimación
2. Estimar el esfuerzo (personas-mes). Si tiene una
estimación exacta del tamaño y los datos previos
de la organización en proyectos similares, es
fácil realizar la estimación del esfuerzo.
3. Estimar la planificación (meses). Una vez que se
han estimado el tamaño y el esfuerzo, estimar la
planificación resulta casi trivial. Pero obtener la
aceptación de una estimación de la planificación
realista puede ser la parte más difícil del
proyecto.
Estimación del tamaño
Se puede estimar el tamaño de un proyecto de
varias formas:
¾ Utilizar un enfoque algorítmico, como los puntos
de función, para estimar el tamaño del programa a
partir de las prestaciones.
¾ Utilizar un software de estimación para estimar el
tamaño del programa, a partir de la descripción de
las prestaciones del programa (pantallas, diálogos,
archivos, tablas de la base de datos, etc.).
Introducción al proceso de
estimación
El proceso para crear una planificación de desarrollo
exacta consta de tres pasos:
1. Estimar el tamaño del producto (número de
líneas de código o puntos de función). Algunos
proyectos saltan directamente a la estimación de
la planificación, pero una estimación efectiva
necesita estimar primero el tamaño del software
para poder construirlo. Este paso es con
diferencia el más difícil intelectualmente, y ésta
podría ser una de las razones por las que se lo
suelen saltar.
Introducción al proceso de
estimación
Estos tres pasos se pueden englobar dentro
de un paso más general:
4. Dar un intervalo de estimación e ir
refinando periódicamente ese intervalo,
para ir aumentando la precisión a medida
que avanza el proyecto.
Estimación del tamaño
¾ Si ya se ha trabajado en proyectos similares, y se
conoce el tamaño, estimar cada una de las partes
principales del nuevo sistema como un porcentaje
del tamaño de una parte similar del sistema
antiguo. Estimar el tamaño total del sistema nuevo
sumando los tamaños estimados de cada una de
las partes.
La mayoría de programas software y algunos de los
enfoques algorítmicos requieren que el método de
estimación se ajuste al entorno, antes de utilizarlo.
6
 Estimación del tamaño
La medida exacta de proyectos anteriores es
la clave para obtener el éxito a largo plazo,
utilizando cualquier tipo de estimación
(véase el recuadro de la página siguiente).
Estimación de los puntos de función
Un punto de función es una medida sintética
del tamaño del programa, que se suele
utilizar en los primeros estados del proyecto.
Estimación del tamaño
¾ Entradas. Pantallas, formularios, cuadros de
diálogo, controles o mensajes, a través de los
cuales un usuario final o cualquier otro programa
pueda añadir, borrar o cambiar datos del
programa. Esto incluye cualquier entrada que
tenga un formato único o un solo procesamiento.
¾ Salidas. Pantallas, informes, gráficos o mensajes
que el programa genera para el usuario final o
cualquier otro programa. Esto incluye cualquier
salida que tenga un formato diferente o requiera
un procesamiento diferente a otros tipos de salida.
Estimación del tamaño
¾ Archivos lógicos internos. Los principales grupos
lógicos de datos de usuarios finales o información
de control que están completamente controlados
por el programa. Un archivo lógico podría constar
de un único archivo plano o de una sola tabla en
una base de datos relacional.
¾ Archivos de interfaz externos. Archivos
controlados por otros programas, con los que el
programa va a interactuar. Esto incluye cada uno
de los principales grupos de datos lógicos o
información de control que entre o salga del
programa.
Estimación del tamaño
Los puntos de función son más fáciles de determinar
a partir de la especificación de los requerimientos
que las líneas de código, y proporcionan una
medida más exacta sobre el tamaño del programa.
Existen diferentes métodos para contar los puntos
de función.
El número de puntos de función en un programa se
basa en el número y la complejidad de cada uno
de los elementos siguientes:
Estimación del tamaño
¾ Consultas. Combinaciones de entrada/salida, en
las que cada entrada genera una salida simple e
inmediata. En las aplicaciones GUI modernas, la
separación entre las consultas y las salidas es
confusa; sin embargo, generalmente las consultas
recuperan datos directamente de una base de
datos y muestran sólo el formato elemental,
mientras que las salidas pueden procesar,
combinar o resumir datos complejos y presentar
muchos formatos.
Estimación del tamaño
La terminología que se utiliza en el enfoque de los
puntos de función está poco orientada a las bases
de datos. El enfoque básico funciona bien para
toda clase de software, pero si no se están
construyendo sistemas intensivos de bases de
datos tendrá que ajustarse al propio entorno.
Para calcular el número de puntos de función en un
programa, se toma el número de entradas de
menor complejidad y se multiplica por 3, el número
de salidas de menor complejidad y se multiplica
por 4, y así sucesivamente con todos los demás.
7
 Estimación del tamaño Estimación del tamaño

Puntos de Fusión
La suma de estos números da «el total de los puntos
Caracteristicas del de función sin ajustar».
programa Complejidad Complejidad Complejidad
baja media alta Posteriormente se calcula un «multiplicador de
Número de entradas x3 x4 x6 influencia» basado en la influencia que tienen 14
factores sobre el programa, factores que incluyen
Número de salidas x4 x5 x7 comunicaciones de datos, entrada de datos en
línea, complejidad del procesamiento y facilidad de
Consultas x3 x4 x6
instalación. El intervalo del multiplicador de
Archivos lógicos internos x7 x10 x15 influencia es de 0,65 a 1,35.
Cuando se multiplica el total sin ajustar por el
Archivos de interfaz externos x5 x7 x10
multiplicador de influencia, se obtiene la suma total
de los puntos de función.

Estimación del tamaño Estimación del tamaño

Puntos de Fusión
Caracteristicas del programa Complejidad Complejidad Complejidad
Consejos sobre estimaciones
baja media alta A continuación se muestran algunas
Número de entradas 6x3 2x4 3x6
directrices generales para realizar la
Número de salidas 7x4 7x5 0x7
estimación del tamaño.
Consultas 0x3 2x4 4x6
Archivos lógicos internos 5x7 2x10 3x15
Archivos de interfaz externos 9x5 0x7 2x10 Evite las estimaciones de improviso. En
Total de puntos de función sin ajustar 304 ocasiones, los desarrolladores son
Multiplicador 1.15
Total de puntos de función ajustados
atrapados por estimaciones de improviso.
350

Estimación del tamaño Estimación del tamaño

Reserve tiempo para la estimación, y Use datos de proyectos anteriores. El método más
planifíquela. Las estimaciones por intuición común utilizado para la estimación es la
son poco precisas. Si está estimando un comparación con proyectos similares realizados
anteriormente, basándose únicamente en la
proyecto grande, trate la estimación como si memoria personal. Este método está asociado con
fuera un miniproyecto, y tome el tiempo el retraso de la planificación y el incremento del
necesario para planificar la actividad de costo. Sin embargo, el uso de datos
estimación, de forma que se pueda hacer documentados de proyectos anteriores similares
bien. contribuye a reducir el retraso de la planificación y
del costo.

8
 Estimación del tamaño
Use estimaciones basadas en el desarrollador.
Las estimaciones hechas por personas diferentes
a los desarrolladores que van a realizar el trabajo
son menos precisas que las realizadas por los
propios desarrolladores. Cuando los
desarrolladores estimadores realizan la estimación
y el trabajo, cumplir sus propias estimaciones se
refleja positivamente en su estimación y su
capacidad de trabajo. Los estimadores ajenos
suelen subestimar el trabajo del otro más que los
estimadores desarrolladores.
Estimación del tamaño
Estime por categorías. Simplemente se realiza una
clasificación de las partes en categorías sencillas,
medias y difíciles. Se asigna un tamaño fijo a cada
una de las categorías, y luego se suman esos
tamaños.
Estime a un bajo nivel de detalle. Debemos basar
la estimación en el examen detallado de las
actividades del proyecto. En general, cuanto más
detallado sea el examen, más precisa será la
estimación.
Estimación del tamaño
soporte técnico de los sistemas existentes
durante el proyecto, corrección de defectos,
administración relacionada con el
seguimiento de defectos, coordinación con
control de calidad, soporte para la
documentación de usuario, revisión de
documentación técnica, integración, días
festivos, vacaciones, días de baja por
enfermedad, reuniones de la empresa y
departamentales y formación.
Estimación del tamaño
Estime por consenso. Cada miembro del
equipo tiene que realizar la estimación de
una parte del proyecto de forma individual, y
luego en una reunión se comparan las
estimaciones. Se deben discutir
suficientemente las diferentes estimaciones
para comprender las fuentes de tales
diferencias. Se trabaja hasta que se llega a
un acuerdo sobre los valores mayores y
menores del intervalo de la estimación.
Estimación del tamaño
No omita tareas comunes. La gente no suele omitir
las tareas a propósito, pero cuando se tiene que
desarrollar el producto en el menor tiempo posible,
nadie se entretiene en buscar tareas extras. A
continuación, se muestra una lista de tareas que
normalmente se omiten: recortes, conversión de
datos, instalación, personalización, gestión del
programa de pruebas beta, demostración del
programa a los clientes o usuarios, espera de
reuniones para control de cambios, trabajos de
mantenimiento en los sistemas existentes durante
el proyecto,
Estimación del tamaño
Use herramientas de estimación de software. Las
herramientas de estimación de software pueden
generar estimaciones para una gran variedad de
tamaños de proyectos, tipos de proyectos, tamaño
del equipo, contratación de personal y otras
variables del proyecto. En proyectos grandes, las
herramientas de estimación de software
proporcionan una planificación más precisa y una
menor incidencia en los retrasos del costo que los
métodos de estimación manual.
9
 Estimación del tamaño
Use varías técnicas distintas para la estimación y
comparación de los resultados. Pruebe
diferentes técnicas de estimación, y estudie los
resultados que se obtengan. Los productores de
software comercial tienden a utilizar como mínimo
tres herramientas de estimación y a buscar la
convergencia o dispersión entre las estimaciones
de planificación. La convergencia entre las
estimaciones indica que hay probabilidad de una
buena estimación. La dispersión indica que
probablemente hay factores que no se han tenido
en cuenta y necesitan comprenderse mejor.
Estimación del tamaño
Estilos de presentación de estimaciones
La forma en que inicialmente se presente la
estimación influye enormemente en lo que suceda
cuando posteriormente se necesite modificar esa
estimación. La estimación de software
normalmente conlleva una gran cantidad de riesgo
e incertidumbre, y una buena estimación capta ese
riesgo y esa incertidumbre.
Estimación del tamaño
Una estimación de 6 meses, +1/2 mes, - 1/2
mes, indica que la estimación es bastante
precisa y que hay bastante probabilidad de
conseguirla. Una estimación de 6 me-ses, +
3 meses, - 2 meses, indica que la
estimación no es muy precisa y que es
menos probable conseguirla. Una
estimación de 6 meses, + 6 me-ses, - 0
meses, indica que la estimación es bastante
optimista; probablemente poco realista.
Estimación del tamaño
Cambie de métodos de estimación conforme
avanza el proyecto. En los primeros estados del
proyecto, será más precisa la estimación con
algoritmos o las tablas de consulta. Durante estas
etapas, lo mejor es utilizar el software de
estimación o tablas de estimación. A la mitad del
diseño, la suma de las estimaciones individuales
de cada una de las tareas permitirá obtener la
estimación más precisa del proyecto, que se
mantendrá hasta el final del mismo.
Estimación del tamaño
A continuación se muestran algunas técnicas para
presentar la estimación de la planificación.
Modificadores más-o-menos. Utilice una
estimación del estilo más-o-menos para indicar
tanto la cantidad como la tendencia de la
incertidumbre en la estimación. Es posible conocer
cómo va a ser de arriesgada la planificación,
incluso cuando nos veamos obligados a prometer
que se va a tener el software en un marco de
tiempo poco realista, presentando una estimación
del estilo más-o-menos.
Estimación del tamaño
Intervalos. Uno de los problemas de la estimación
con el estilo más-o-menos es que a veces en la
organización sólo se difunde la parte nominal de la
estimación. Se eliminan los factores más-o-menos,
cuyo resultado pierde información de forma
significativa. Si ése es el caso, una alternativa es
utilizar un intervalo de estimación, en vez de la
estimación del estilo más-o-menos. Por ejemplo, si
la estimación es de 6 meses, + 3 meses / - 1 mes,
se podría presentar la estimación como de 5-9
meses.
10

Estimación del tamaño
Cuantificación de riesgos. Una extensión de la
estimación más-o-me-nos consiste en explicar lo
que representan los signos más y menos. En vez
de decir simplemente «6 meses, + 3 meses, — 2
meses».
Cuando se documentan en la estimación las fuentes
de la incertidumbre, se proporciona a los clientes
información que se utiliza para reducir los riesgos
en el proyecto y sentar las bases para poder
explicar los cambios de la planificación, si
cualquiera de los riesgos se hiciera realidad.
Estimación del tamaño
Cuando la estimación se presenta de esta forma,
hay que prepararse para poder contestar
preguntas sobre cómo realizar la planificación para
gestionar los riesgos y beneficiarse de las
reducciones de la planificación.
Casos. Una variante de la estimación de la
cuantificación de riesgos es la estimación basada
en casos. Se presenta la estimación para el mejor
y peor caso, para el caso planificado y para el
caso real. Las relaciones entre las diferentes
estimaciones serán muy interesantes.
Ejemplo de estimación
basada en casos
Caso Estimación
Mejor Caso 1 Abril
Caso planificado 15 de Mayo
Caso real 30 de Mayo
Peor caso 15 de Julio
Ejemplo de estimación de
cuantificación de riesgos
Estimación: 6 meses, + 3 meses, -2 meses
+1 mes por el retraso en la entrga del - 1 mes por menos retraso del que se
subsistema de gráficos esperaba en la contratación de los
nuevos desarrolladores
+ 1 mes por las nuevas herramientas - 1 mes por las nuevas herramientas
de desarrollo que no están de desarrollo que funcionan mejor de
funcionando como se planificó lo que se planificó
+ 0.5 mes por baja de personal
+ 0.5 mes por subestimación del
tamaño
Estimación del tamaño
Por ejemplo, si el caso planificado y el mejor son el
mismo, y el caso real y el peor también coinciden,
¡el proyecto tiene problemas!
En la práctica la estimación del «caso planificado» o
«el más probable» tiende a acercarse al final del
intervalo del «mejor caso», y los resultados reales
tienden a agruparse al final del intervalo del «peor
caso». Esto hay que tenerlo en cuenta cuando se
vaya a crear y a revisar el conjunto de casos.
Estimación del tamaño
Hay que estar preparado para explicar a los clientes
lo que tendría que haber ocurrido para conseguir
el «mejor caso» o caer en el «peor caso». Los
clientes desearán tener información de las dos
posibilidades.
Fechas poco precisas y períodos de tiempo. Si
las estimaciones son aproximadas, es claramente
mejor usar números poco precisos, como tercer
trimestre del 97 o 10 personas-año, que usar
números precisos engañosos, como 19 de julio de
1997 o 520 personas-semana.
11
 Estimación del tamaño
Además de indicar que las fechas son aproximadas,
los números poco precisos tienen la ventaja de
que no se arriesga a perder información cuando se
simplifican. Una estimación de «6 meses, + 3
meses, - 1 mes» se puede reducir a «6 meses».
Una estimación de «tercer trimestre del 97» está
exenta de tal reducción.
Factores de confianza. Una de las preguntas que la
gente se suele hacer sobre una planificación es:
«¿Qué probabilidad hay de mantener esta fecha?»
Estimación del tamaño
Fecha de entrega Probabilidad en la
entrega en la fecha
planificada o antes de la
misma
1 Abril 5%
1 Mayo 50 %
1 Junio 95 %
Estimación del esfuerzo
Derivar la estimación del esfuerzo es un proceso
sencillo. A continuación se muestran algunas de
las formas para convertir la estimación del tamaño
en la del esfuerzo:
¾ Utilización de software de estimación para crear
directamente la estimación del esfuerzo a partir de
la del tamaño.
¾ Utilización de las tablas de planificación para
convertir la estimación del tamaño en líneas de
código a una estimación del esfuerzo.
Estimación del tamaño
Si se utiliza un enfoque con factores de
confianza, se puede responder a la pregunta
proporcionando una estimación.
Se pueden aproximar estos intervalos de
confianza utilizando la estimación del punto
«más probable» y los multiplicadores de
estimación por fase del proyecto.
Estimación del esfuerzo
Una vez que se tiene la estimación del tamaño, se
puede pasar al segundo paso de estimación,
derivar la estimación del esfuerzo. Aunque la
estimación no es estrictamente necesaria para
estimar una planificación del software, se
necesitará estimar el esfuerzo para poder saber a
cuántas personas hay que incorporar en el
proyecto; y además, teniendo una estimación del
esfuerzo, se facilita la estimación de la
planificación.
Estimación del esfuerzo
¾ Utilización de datos anteriores de la organización
para estimar cuánto esfuerzo se realizó en
proyectos anteriores del tamaño estimado. A
menos que tenga fuertes razones para pensar que
el proyecto nuevo será diferente a los proyectos
anteriores de tamaño similar, se supone que
llevará una cantidad de esfuerzo similar. De
nuevo, la mayoría de la información útil que se
tenga en este estado son datos históricos (no en la
memoria del personal) de proyectos dentro de la
propia organización.
12

Estimación del esfuerzo
¾ Utilización de un método algorítmico de
aproximación como el modelo COCOMO de Barry
Boehm o el modelo del ciclo de vida de Putnam y
Myers para convertir la estimación de las líneas de
código en estimación del esfuerzo.
Para la estimación del esfuerzo también se pueden
aplicar muchos de los consejos de estimación del
tamaño.
Estimación de la
planificación
Esto implica un tamaño óptimo del equipo de 65
personas-mes dividido por 12 meses de
planificación: un equipo con 5 o 6 miembros.
A diferencia de otros temas en la estimación de
proyectos software, se han publicado resultados
extraordinariamente similares en este tema. Las
opiniones varían sobre si el «3.0» de la ecuación
debería ser 3.0 o 4.0 o 2.5, y sobre lo que
sucedería si se intentara desarrollar más rápido de
lo que se indica en la ecuación.
Estimación de la
planificación
Si se mantiene constante el tamaño del equipo, el
intervalo de planificación tendría la misma amplitud
que el del esfuerzo.
A continuación se muestran algunos métodos
alternativos para calcular la planificación del
software a partir de la estimación del esfuerzo:
¾ Utilización de software de estimación para calcular
la planificación, a partir de la estimación del
tamaño y del esfuerzo.
Estimación de la
planificación
El tercer paso en la estimación de un proyecto de
software es calcular la estimación de la
planificación. Una regla es calcular la planificación
a partir de la estimación del esfuerzo, utilizando la
Ecuación siguiente
planificación en meses = 3.0 x (personas-mes)1/3
Si ha estimado que serán necesarias 65 personas-
mes para construir el proyecto, la Ecuación
muestra que la planificación óptima es de 12
meses (3,0 x 651/3).
Estimación de la
planificación
Esta ecuación es la razón de que el intervalo de
estimación por fases del proyecto sea más amplio
para el esfuerzo que para la planificación. Los
proyectos más grandes tienen un intervalo mayor,
pero también tienen los equipos más grandes; y las
ineficiencias asociadas a los equipos grandes
implican que el esfuerzo aumenta
desproporcionadamente más rápido que la
planificación. El intervalo de planificación que se
muestra en la estimación por fases del proyecto
supone que se añadirán o quitarán miembros del
equipo conforme se vaya aprendiendo sobre el
l d l t
Estimación de la
planificación
¾ Utilización de datos anteriores de la organización.
¾ Utilización de tablas de planificación para buscar
una estimación de la planificación basada en la
estimación del tamaño.
¾ Utilización del paso de estimación de la
planificación a partir de uno de los enfoques
algorítmicos (por ejemplo, COCOMO), para
proporcionar una estimación más afinada que la
que se obtendría con la Ecuación de la estimación
en meses.
13
 Estimación de la
planificación
Uno de los problemas comunes con los que se
encuentra la estimación de la planificación es que
generalmente se realiza tan fríamente que se
completa asignándole un margen de error. A veces
se completa lo suficiente y otras veces no.
La Ecuación de la planificación por mes y los
refinamientos periódicos aproximados permiten no
utilizar el relleno. El relleno no es una buena
opción porque les da a los clientes unas nociones
equivocadas sobre por qué las planificaciones son
imprecisas.
Estimación de la
planificación
Planificación basada en compromiso
Algunas organizaciones se saltan el paso intermedio
que consiste en estimar el esfuerzo, pasando
directamente de los requerimientos a la
planificación. Normalmente lo hacen basándose en
el compromiso, en donde se conversa con los
desarrolladores para realizar más bien un
compromiso de planificación que una estimación.
Este método asigna a los desarrolladores la
responsabilidad de crear las estimaciones de
tamaño y esfuerzo.
Estimación de la
planificación
Dentro de este tipo de planificación, este optimismo
se fomenta y no se le somete a ninguna prueba
para ver si está en consonancia con la realidad. En
conjunto, el efecto que causa es que da lugar a
grandes errores de estimación.
El compromiso tiene su sitio en el desarrollo rápido,
pero tal y como se lleva a cabo este tipo de
planificación, no sirve de gran ayuda en las
planificaciones pequeñas.
Estimación de la
planificación
El relleno dice: «No creo que nuestras estimaciones
sean muy buenas.» Un intervalo de estimación con
refinamientos periódicos dice: «Las estimaciones
son buenas, pero no es posible que en este estado
del proyecto una estimación sea precisa. Será más
precisa conforme vaya avanzando.»
La utilización de herramientas de estimación de
software, métodos algorítmicos y tablas de
consulta combinados con la utilización de
estimaciones con intervalos elimina la necesidad
de relleno, y ayuda a explicar claramente la
Estimación de la
planificación
Tiene la ventaja de incrementar la implicación de los
desarrolladores en la planificación, tiende a
aumentar la moral en el período inmediato al
compromiso y ayuda a que los desarrolladores
hagan bastantes horas extras totalmente
voluntarias.
Este método también tiene varios inconvenientes. En
lo que a la estimación se refiere, los estudios de la
estimación en relación con la planificación real han
demostrado que la estimación de los
desarrolladores tiende a tener un factor de
Estimación de la
planificación
Es esencial que el compromiso sea realista y
factible, de forma que el equipo pueda
conseguir grandes éxitos en lugar de
fracasar. El único tipo bueno de planificación
(basada en compromiso u otra distinta) es
una planificación exacta.
14
 Estimación de la Estimación de la
planificación planificación
Método de estimación de primer orden de Clase de Mejor Media Peor caso
Jones Software Caso
Si tiene la suma total de todos los puntos de función, Sistemas 0.43 0.45 0.48
puede realizar a partir de ellos un cálculo
aproximado de la planificación, utilizando un
método que Capers Jones ha denominado Gestión 0.41 0.43 0.46
«estimación de primer orden». Para utilizarlo,
simplemente hay que tomar el total de los puntos
de función y elevarlo a la potencia apropiada, A la medida 0.39 0.42 0.45
seleccionándola en la Tabla.

Estimación de la
planificación
Los exponentes de la tabla se han derivado del
análisis de Jones de su base de datos de miles de
proyectos.
Si estima que el número total de puntos de función
en el proyecto es de 350 y está trabajando en una
organización media de software a la medida,
elevaría 350 a 0.42 (3500.42), obteniendo una
planificación aproximada de 12 meses. Si está
trabajando en una empresa de software a la
medida muy organizada, elevaría 350 a 0.39,
obteniendo una planificación de 10 meses.
Estimación de la
planificación
Éste no es el mejor método en la estimación de la
planificación, pero ayuda a obtener una aproximación,
lo cual es mejor que hacerlo a ojo. También
proporciona una comprobación rápida de la realidad.
Si se desea desarrollar un producto a la medida con
350 puntos de función en 8 meses, tendría que
pensarlo bien antes. La planificación con el mejor caso
sería de 10 meses, y la mayoría de las organizaciones
no son un modelo a seguir. El método de estimación
de primer orden de Jones permite saber pronto si es
necesario ajustar el conjunto de prestaciones, las
previsiones de la planificación o ambas.

Estimaciones simples de Estimaciones simples de

planificación
Uno de los principales obstáculos con que se
encuentra la planificación del software es la
dificultad para obtener información concreta y útil
sobre la misma. La información disponible
normalmente se encuentra en uno de estos
formatos: bien está incorporada en programas de
estimación del software, que tienden a ser caros
(de 1,000 a 10,000 dólares o más), o se encuentra
en libros con docenas de ecuaciones y
multiplicadores , pudiendo tardar días en aprender
a realizar una estimación simple.
planificación
Muchas personas desean una estimación
sencilla para conocer cuánto tiempo durará
un programa de un tamaño determinado, y
eso es lo que proporcionan las Tablas. Los
datos de las tablas no suelen tener la misma
precisión que los datos de otros proyectos
dentro de la misma organización. Pero si la
organización no ha guardado con cuidado
los proyectos anteriores, estos datos son
más precisos que los que se obtienen a ojo.

15
 Estimaciones simples de
planificación
Conceptos básicos
Las Tablas describen tres clases de proyectos:
• Software de sistemas.
• Software de gestión.
• Software a la medida.
El software de sistemas, tal y como se ha definido,
no incluye fíreware, software en tiempo real,
aviónica, control de procesos y cosas por el estilo.
La productividad con esta clase de sistemas sería
mucho más baja.
Estimaciones simples de
planificación
Planificaciones
La planificación se obtiene en meses. Incluye
todo el tiempo de diseño, construcción y
prueba hasta finalizar el proyecto. No
incluye el tiempo necesario para la
especificación de requerimientos. En la
planificación se suelen dar uno o dos dígitos
significativos; una mayor precisión no sería
significativa.
Estimaciones simples de
planificación
Si no piensa entregar el software antes del tiempo
planificado en las tablas, se puede reducir el costo
del proyecto completo prolongando la planificación
y reduciendo el tamaño del equipo. Cuanto menor
sea el equipo, requiere menos gestión y
comunicación con los superiores, de forma que se
puede trabajar más productivamente.
Prolongar la planificación más allá de lo nominal y
conservar el mismo tamaño del equipo no
producen el mismo tipo de ahorro.
Estimación de la
planificación
Si el proyecto no se engloba dentro de ninguna de
estas categorías, se puede aproximar la
estimación combinando números de dos o tres
columnas. Por ejemplo, si el proyecto es un
producto de mercado vertical que puede tener un
60 % de producto de gestión y un 40 % de
producto a la medida, para calcular la planificación
del producto se añadiría un 60 % de la
planificación de gestión y un 40 % de la
planificación a la medida
Estimaciones simples de
planificación
Esfuerzos
El esfuerzo se representa en personas-mes de
desarrollo con dos o tres dígitos significativos.
(Sólo se dan con tres dígitos significativos cuando
se necesitan representar con mayor precisión las
relaciones entre las distintas posibilidades.)
Se puede calcular el tamaño medio del equipo
dividiendo los meses del esfuerzo por los meses
de la planificación. La planificación no representa
el intervalo completo de posibles combinaciones
del tamaño de la planificación y del equipo.
Estimaciones simples de
planificación
Tamaño de los sistemas
El tamaño de los sistemas que se muestran en las
Tablas se da en líneas de código, que son
sentencias fuente sin comentarios y sin espacios
en blanco. En C, una aproximación sería el
número de puntos y comas en el archivo. En
Basic, sería el número de líneas de texto fuente
sin comentarios y sin espacios en blanco. Según
estas tablas, una sentencia que esté compuesta
por más de una línea física se cuenta como una
sola «línea de código».
16
 Estimaciones simples de
planificación
Proyectos pequeños
Las tablas no contemplan las planificaciones
para proyectos menores de 10,000 líneas de
código. Los proyectos pertenecientes a este
intervalo generalmente son realizados por
una persona, y la estimación de la
planificación y el esfuerzo de tales proyectos
dependen en gran medida de la capacidad
del individuo que realiza el trabajo.
Estimaciones simples de
planificación
Los puntos de función no se utilizarán en este tipo de
tablas, ya que si no se sabe bien el lenguaje que
se va a utilizar, no se puede derivar bien el
esfuerzo. Quince puntos de función en una macro
en ensamblador tendrán tres o cuatro veces más
trabajo de implementación que quince puntos de
función en C++, pero 1,000 líneas de código
tendrán la misma cantidad de código en ambos
lenguajes. Las líneas de código son, por tanto, tan
buena medida para el tamaño del programa como
cualquier otra (de todos modos, el objetivo es
estimar la planificación y el esfuerzo en estas
t bl )
Estimaciones simples de
planificación
Planificaciones lo más cortas posible
Cuando se enfrenta a un proyecto grande, un año o
dos puede parecer una cantidad de tiempo infinita.
Podría parecer que es posible finalizar cualquier
tipo de proyecto en un año, pero esto no es cierto.
Utilice las planificaciones de la Tabla 1 como una
prueba, para ayudarle a asegurarse que la
planificación esté al menos dentro del terreno de
juego.
Estimaciones simples de
planificación
Líneas de código
En las tablas, el tamaño de los proyectos se indica
en líneas de código. Las métricas basadas en
líneas de código han sido criticadas, por lo que
algunas personas sugieren que en su lugar se
utilicen «los puntos de función».
Las métricas basadas en líneas de código
generalmente se asimilan mejor que los puntos de
función, y para algunos lenguajes en particular hay
una gran correlación entre las líneas de código y
los puntos de función.
Estimaciones simples de
planificación
Calidad de las estimaciones
Algunas personas también podrían criticar estas tablas,
en el sentido de que siendo tan simples, no es posible
que generen estimaciones útiles. Es cierto que estas
tablas son bastante simples. Ése es su objetivo.
También es cierto que los datos históricos de su
propia industria, organización o grupo permitirán hacer
una estimación más exacta que la que se realiza en
estas tablas. Pero tan simples como son, las Tablas
proporcionan estimaciones que, para el objetivo que
se pretende, son casi tan exactas como las obtenidas
con algunos de los modelos de estimación más
complicados.
Estimaciones simples de
planificación
Si cree que no tendrá ningún problema en
desarrollar una aplicación a la medida de 75,000
líneas en 9 meses con 10 desarrolladores, ¡vuelva
a pensarlo! La planificación más corta para esta
aplicación es de 10 meses con 14 desarrolladores.
Todos los métodos de reducción de la planificación
ya se han incluido en esa planificación más corta
posible. Las planificaciones óptimas alcanzables
pueden causar muchos problemas, pero ¡tendrá
una mayor probabilidad de éxito si se asegura de
que la estimación inicial se encuentra, al menos,
dentro del rango de lo posible!
17
 Estimaciones simples de
planificación
Éstas son las planificaciones más cortas posible que
se pueden desarrollar en una organización ideal
de desarrollo de software. Serán inalcanzables
para la mayoría de las organizaciones. Como se
puede observar en la Figura, incluso una
organización que tiene la oportunidad de
desarrollar la planificación más corta posible sigue
corriendo un gran riesgo de retrasarse.
Estimaciones simples de
planificación
Hipótesis
Como las planificaciones de la Tabla 1 son las más
cortas posible, éstas contienen una serie de
hipótesis extremadamente optimistas.
Plantilla. Las planificaciones de la Tabla 1 suponen
que el equipo tiene un increíble talento y ha
utilizado sus aptitudes al máximo, al 100 %. Esto
significa que los analistas que han especificado los
requerimientos son de los mejores, y los
desarrolladores también.
Estimaciones simples de
planificación
Gestión. Estas planificaciones suponen que el
proyecto tiene una gestión ideal, y que los
desarrolladores no pierden el tiempo con
actividades que no estén relacionadas con
el trabajo técnico del desarrollador. El
proyecto se plantea utilizando un patrón de
plantilla rectangular, es decir, la plantilla al
completo comienza trabajando desde el
primer día del proyecto y continúa hasta la
entrega del proyecto.
Estimaciones simples de
planificación
Estimaciones simples de
planificación
Todos tienen muchos años de experiencia con
el lenguaje de programación que se está
utilizando y con el entorno de programación
en el que se desarrolla. Los desarrolladores
tienen un conocimiento detallado sobre el
área de aplicación. Todos están motivados,
comparten la misma visión del producto,
todos se llevan muy bien, trabajan tanto
como pueden y no hay ningún cambio del
personal.
Estimaciones simples de
planificación
Herramientas de apoyo. Se dispone de una serie
de herramientas software avanzadas, y los
desarrolladores tienen un acceso ilimitado a los
recursos informáticos. El entorno de la oficina es
ideal y todo el equipo del proyecto está situado en
la misma área. Todas las herramientas de
comunicación necesarias, como los teléfonos,
mensajes de voz, fax, redes y correo electrónico
con inclusión de documentos, están integradas en
el entorno de trabajo.
18
 Estimaciones simples de
planificación
Metodología. También se utilizan los métodos y las
herramientas de desarrollo más eficientes del
momento. Tiene conocimiento de todos los
requerimientos al inicio del diseño, y luego no
cambian.
Compresión. Estas planificaciones han sido
comprimidas al máximo para este conjunto de
hipótesis, por debajo de la planificación nominal.
No se pueden comprimir más.
Estimaciones simples de
planificación
Piense en lo siguiente: si una persona puede escribir
1,000 líneas de programa en una semana,
¿pueden cinco personas escribir el mismo
programa en un día? ¿Pueden 40 personas
escribirlo en una hora?
Es fácil reconocer en este ejemplo tan simple el
efecto que causa la necesidad de comunicación e
integración. Sería más difícil reconocer el efecto
en un proyecto más grande, con una planificación
mayor, pero los factores de limitación son los
mismos.
Estimaciones simples de
planificación
Estimaciones simples de
planificación
Dos hechos reales
Cuando se va a realizar una planificación, hay unas
cuantas cosas que nos gustaría que fueran
distintas, pero que no podemos cambiar. Podemos
consolamos conociendo cuáles son estas cosas. A
continuación se citan las dos más importantes.
Hay una planificación lo más corta posible, y no se
puede reducir. A partir de cierto punto, aumentar el
número de desarrolladores de software alenta el
proyecto, en vez de hacerlo más rápido.
Estimaciones simples de
planificación
Como muestra la Figura, para un proyecto de un
tamaño en particular, hay un punto a partir del cual
la planificación del desarrollo no se puede reducir.
No es cuestión de trabajar más duro, ni de trabajar
con más habilidad, tampoco de encontrar
soluciones creativas, ni de ampliar el equipo.
Simplemente, no se puede hacer.
Es difícil imaginar un proyecto que tenga todas las
características que se han supuesto en esta
planificación, de forma que es difícil imaginar que
un proyecto podría realmente conseguir la
planificación más corta posible.
Estimaciones simples de
planificación
Si el proyecto no satisface las hipótesis hechas en
esta planificación, no se debería programar dentro
del intervalo de la planificación más corta posible.
Ningún proyecto debería programarse con una
planificación menor que la mostrada en la Tabla 1.
Los costos se incrementan rápidamente al
reducir la planificación por debajo de la
nominal. Una vez que se dispone de las
herramientas y los métodos, se puede reducir la
planificación, simplemente aumentando el número
de desarrolladores o la cantidad de tiempo extra.
19
 Estimaciones simples de
planificación
A esto se le denomina «compresión de la
planificación». Sin embargo, como muestra
la Figura, el otro hecho inevitable es que
reducir mucho el tiempo de desarrollo por
debajo del nominal pasa a ser
prohibitivamente caro. Esto se debe a que
se tiene más carga por comunicaciones y
gestión, y se deben utilizar patrones de
plantilla relativamente ineficientes.
Estimaciones simples de
planificación
Si la planificación inicial del proyecto es de 12 meses
y quiere te-minarlo en 10, el factor de compresión
sería 0,83 (10/12). Suponiendo que la estimación
del esfuerzo inicial era de 78 personas-mes, se
puede considerar como constante el 0.83 en la
ecuación del esfuerzo de la planificación
comprimida.
Esfuerzo de planificación comprimida =
esfuerzo inicial/factor de compresión de planificación
Estimaciones simples de
planificación
Si el factor de compresión es menor del 0.75, será
necesario reducir el tamaño del producto o
aumentar la planificación en vez de depender
solamente de la compresión de la planificación.
De igual forma, los factores de compresión de la
planificación también pueden funcionar al revés. Si
está intentando estirar ligeramente la planificación,
puede reducir el costo del proyecto reduciendo
desproporcionadamente el tamaño del equipo. Se
pueden utilizar las Ecuaciones anteriores para
calcular el efecto que se produce al descomprimir
la planificación de un proyecto.
Estimaciones simples de
planificación
Los investigadores utilizan diferentes métodos para
estimar el costo de la compresión de la
planificación. Una regla suficientemente exacta
para la mayoría de los objetivos fue introducida por
Charles Symons. Primero estima el esfuerzo y la
planificación iniciales. Luego combina estas
estimaciones con la planificación deseada para
calcular el factor de compresión de la planificación,
utilizando la Ecuación.
Factor de compresión de la planificación =
Planificación deseada/Planificación inicial
Estimaciones simples de
planificación
Esto genera un esfuerzo de planificación comprimida
de 94 personas-mes (78/0,83), lo que significa que
una reducción de un 17 % en la planificación
necesitaría un aumento de un 21 % en el esfuerzo.
La mayoría de los investigadores han llegado a la
conclusión de que no es posible alcanzar un factor
de compresión de la planificación por debajo de
0.75 o un 0.80. Esto significa que hay un límite en
cuanto a la cantidad que se puede reducir una
planificación, añadiendo personas y exigiendo
mayor tiempo extra, y ese límite está en un 25 por
Estimaciones simples de
planificación
Planificaciones eficientes
Dado que las planificaciones lo más cortas
posible están fuera del alcance de la gran
mayoría de las organizaciones, planificar
según las planificaciones eficientes o
nominales, es una alternativa más realista.
Tabla 2
20
 Estimaciones simples de
planificación
Hipótesis
Las planificaciones eficientes suponen que la
mayoría de las cosas se realizan bien, pero se
abstienen de basarse en unas hipótesis tan
ideales como aquellas en las que se basa la
planificación lo más corta posible.
Estos tipos de planificaciones suponen que el equipo
pertenece al grupo del 25 por 100 de mejores
profesionales, tanto en los analistas como en los
desarrolladores.
Estimaciones simples de
planificación
Aparte de estas hipótesis, las planificaciones
de la Tabla 2 utilizan las mismas hipótesis
que en las planificaciones lo más cortas
posible: utilización eficiente de las
herramientas de programación, utilización
de métodos de programación modernos,
gestión activa de riesgos, excelente entorno
físico, uso integrado de herramientas de
comunicación, utilización de métodos de
desarrollo rápido, etc.
Estimaciones simples de
planificación
Relación entre las planificaciones eficientes y las
más cortas posible
Un aspecto bastante interesante en cuanto a las
planificaciones de la Tabla 2 es que los proyectos
descritos necesitan, en conjunto, menos esfuerzo
que los de la tabla de las planificaciones lo más
cortas posible (Tabla 1), a pesar de que las
planificaciones lo más cortas posible utilizan unas
hipótesis más optimistas. Ésta es la causa de que
las planificaciones más cortas posible estén
comprimidas al máximo, y esa compresión tiene
un precio.
Estimaciones simples de
planificación
Todos han trabajado con el lenguaje de
programación y el entorno durante unos
cuantos años. El cambio de personal es
menor de un 6 % por año. Es posible que el
equipo no sea ideal no el mejor, pero hay un
consenso sobre las tareas del proyecto y no
hay demasiados conflictos. El proyecto se
basa en el uso de un patrón de plantilla
bastante eficiente, conocido como un patrón
de capacidad del personal de Rayleigh.
Estimaciones simples de
planificación
Estas planificaciones no se han comprimido
por debajo de las planificaciones nominales
para este conjunto de hipótesis. Se pueden
comprimir hasta un 25 % utilizando el
método descrito junto con las Ecuaciones
del factor de comprensión y la del esfuerzo
de la planificación comprimida.
Estimaciones simples de
planificación
Comprimir las planificaciones eficientes al máximo
(reduciéndolas un 25 por 100) producirá
planificaciones de duración similar a las más
cortas posible, pero serán más costosas porque
las hipótesis son menos optimistas.
Para la mayoría de los proyectos, las planificaciones
eficientes representarán «el mejor caso» posible
de las planificaciones. Las planificaciones lo más
cortas posible simplemente serán inalcanzables.
Estas planificaciones solamente se podrán dar si
prácticamente todas las cosas van bien.
21
 Estimaciones simples de
planificación
Planificaciones nominales
Las planificaciones nominales están pensadas
para proyectos medios. Dado que, por
definición, la mayoría de los proyectos son
medios, la mayoría de los proyectos deben
utilizar las planificaciones nominales en vez
de las eficientes o las más cortas posible.
Tabla 3
Estimaciones simples de
planificación
Hay posibilidad de que estos equipos no se
entiendan perfectamente y podrían experimentar
algún que otro conflicto. Pueden tener un cambio
de personal de un 10 a un 12 % por año.
Las herramientas y los métodos de programación
modernos se utilizan algunas veces, pero no tanto
como se haría en un proyecto de desarrollo
eficiente. Se podrían utilizar algunos de los
métodos de desarrollo rápido, pero no se utilizan
aprovechando sus principales ventajas. Los
riesgos se pueden gestionar menos activamente
que en el caso ideal.
Estimaciones simples de
planificación
Al igual que las planificaciones de desarrollo
eficientes, estas planificaciones no se han
comprimido por debajo de las nominales, de forma
que se pueden comprimir hasta un 25 %.
Estas planificaciones no son tan rápidas como las de
desarrollo eficiente, pero no son en absoluto el
peor de los casos. Se supone que muchas cosas
se hacen bien, y el llevar a cabo algunas de estas
planificaciones nominales será una apuesta de un
50/50 para un proyecto medio.
Estimaciones simples de
planificación
Hipótesis
Las planificaciones nominales utilizan hipótesis
menos optimistas que las otras. Se supone que el
equipo tiene un talento medio o alto. Los miembros
normales del equipo están familiarizados con el
lenguaje de programación y con el entorno, pero
no es necesario que estén excesivamente
familiarizados. El equipo, por término medio, tiene
alguna experiencia en el área de la aplicación (de
nuevo, no es necesario que estén excesivamente
familiarizados).
Estimaciones simples de
planificación
Las herramientas de comunicación, como
teléfonos, mensajes de voz, fax, redes y
correo electrónico están disponibles, pero
podrían no estar integradas dentro del
entorno de trabajo normal. El entorno de la
oficina es algo peor que en el caso ideal,
pero es adecuado: los desarrolladores
estarían más bien en oficinas compartidas
que en oficinas privadas, pero no están en
compartimentos abiertos ni con biombos.
Estimaciones simples de
planificación
¿Por qué llevar a cabo el desarrollo de forma
eficiente?
Estas planificaciones no sólo necesitan mucho más
tiempo que las planificaciones eficientes
correspondientes, sino que además son mucho
más caras. El desarrollo eficiente de una
aplicación a la medida de 250,000 líneas de
código necesitaría unas 470 personas-mes en 22
meses. El mismo proyecto desarrollado de forma
nominal necesitaría unas 800 personas-mes en un
periodo de 26 meses.
22
 Estimaciones simples de
planificación
Comprimir las planificaciones nominales puede
generar planificaciones con una duración similar a
las planificaciones eficientes, pero que son mucho
más costosas por utilizar unos métodos de
desarrollo menos eficientes. Comprimir una
planificación nominal para una aplicación a la
medida de 250,000 líneas de código para finalizar
en los mismos 22 meses como desarrollo eficiente
necesitaría 950 personas-mes, el doble que en el
desarrollo eficiente. Las organizaciones pueden
obtener beneficios significativos utilizando los
métodos de desarrollo eficiente.
Estimaciones simples de
planificación
Es lo mejor que se puede hacer, porque ésta
es la mejor forma de adquirir conocimiento
de los proyectos. Si los números de las
tablas dan estimaciones mayores o menores
que las de su último proyecto, se conocerá
cómo calibrarlas antes de usarlas para
estimar su próximo proyecto
Refinamiento de las
estimaciones
Esto es lógico, ya que cuanto mejor definido está el
sistema, hay menos incertidumbre en la
estimación.
La investigación de Laranjeira implica que el trabajo
que hay que realizar para retinar la definición del
software es el trabajo del propio proyecto software:
especificación de requerimientos, diseño del
producto y diseño detallado. Simplemente no es
posible conocer una planificación con una
precisión de ± 10 % en la fase de especificación
de los requerimientos.
Estimaciones simples de
planificación
Primer paso a dar en las
planificaciones simples
El primer paso que la mayoría de las personas
suelen dar cuando ven este tipo de
planificación será sacar las anotaciones de
un proyecto reciente y compararlo con los
números de esas tablas. ¿Fue un proyecto
lo más rápido posible? ¿Eficiente?
¿Nominal?
Refinamiento de las
estimaciones
Una pregunta que los directivos y clientes se hacen
es; «Si se le da otra semana para trabajar sobre la
estimación, ¿se puede refinar, de forma que
contenga menos incertidumbre?» Es una pregunta
razonable, pero desafortunadamente no es posible
actuar de la forma en que nos gustaría. Las
investigaciones realizadas por Luiz Laranjeira
sugieren que la calidad de la estimación del
software depende del nivel de refinamiento de la
definición del software. Cuanto más refinada sea la
definición, la estimación será de mayor calidad.
Refinamiento de las
estimaciones
Se puede controlar para que esté en el margen
inferior, pero si se deja el proyecto a su aire
mientras se avanza, no se obtendrá una precisión
mejor del + 50, - 33 %.
Es posible refinar la estimación de un proyecto a
medida que va avanzando, y además sería
conveniente hacerlo. El proceso típico que sigue
cualquier persona es dejarse forzar a hacer una
estimación con valores puntuales, y luego
responsabilizarse de eso.
23
 Estimación del tamaño Estimación del tamaño
Calcular la planificación, el esfuerzo y las personas para un Calcular la planificación, el esfuerzo y las personas para un
proyecto de sistema con los siguientes datos, considerando proyecto a la medida con los siguientes datos, considerando
una influencia de 1.31. Obtener los mismos valores para una influencia de 0.86. Obtener los mismos valores para una
una compresión de 17% y una descompresión del 22%. compresión de 23% y una descompresión del 15%.
Puntos de Fusión Puntos de Fusión
Caracteristicas del programa Complejidad Complejidad Complejidad Caracteristicas del programa Complejidad Complejidad Complejidad
baja media alta baja media alta
Número de entradas 8x3 10x4 9x6 Número de entradas 8x3 6x4 7x6
Número de salidas 9x4 5x5 8x7 Número de salidas 5x4 5x5 4x7
Consultas 7x3 6x4 9x6 Consultas 6x3 5x4 4x6
Archivos lógicos internos 10x7 7x10 5x15 Archivos lógicos internos 6x7 4x10 5x15
Archivos de interfaz externos 6x5 9x7 4x10 Archivos de interfaz externos 3x5 5x7 2x10

24