Estimación de Desarrollo de Software

El Cliente dice: “¡Te damos tiempos límite razonables! ¿Por qué no puedes cumplirlos?”
Ese argumento es muy común en el desarrollo de software y el hecho de fijar la fecha de
entrega antes de establecer los requisitos, es el problema más antiguo de la ingeniería de
software, pero si ya estamos conscientes de todo esto ¿por qué la improvisación parece ser el
estándar? y ¿por qué no se tienen procesos de estimación bien definidos?
Hoy en día existen diversas herramientas y metodologías que nos permiten estimar costos
como SPR KnowledgePlan de Capers Jones o COCOMO II de Barry Boehm, por comentar
algunos. Sin embargo fenómenos como el “Proyecto interminable” y la “Marcha de la muerte”
siguen siendo comunes en muchos desarrollos. Existen muchos factores que afectan las
estimaciones de costo como:

 Incertidumbre en los requerimientos.

 Términos contractuales rígidos.
 Salud financiera (ganar licitaciones sacrificando costo y tiempo).
 Falta de experiencia con “X” tecnología.

No existe una forma simple de calcular el esfuerzo requerido para desarrollar un proyecto de
software. Las estimaciones iniciales se hacen bajo la base a la definición de requisitos que el
cliente provee a un alto nivel (funcionalidades o pantallas). Los pasos típicos en una estimación
son:

1. Análisis de los requisitos.

2. Predicción del tamaño.
3. Descripción de las Actividades.
4. Estimación de fallas potenciales y métodos de eliminación de defectos en el software.
5. Estimación de requisitos del personal.
6. Ajuste de suposiciones basadas en capacidades y experiencia.
7. Estimación del esfuerzo y fechas límite.
8. Estimación de costos del desarrollo.
9. Estimación de costos de mantenimiento y mejora.

A medida de que los proyectos de software aumentan en complejidad, se observa que no

existe una relación simple entre el precio de software al cliente y los costos involucrados en el
desarrollo, así como la falsa creencia que hay una relación entre el número de desarrolladores
contra el número de funcionalidades del proyecto. Por eso y para facilitar el proceso de
estimación se han establecido a lo largo del tiempo, métricas que ayudan a dar una idea
aproximada del tamaño del software:
Medidas relacionadas con el tamaño del código (LOC - Lines of code)
Esta forma de medir el tamaño de un software era utilizado cuando los lenguajes de
programación, patrones de desarrollo y entornos de desarrollo (IDE), no estaban ampliamente
desarrollados. Hoy en día es impráctico tratar de estimar el software a través de sus líneas de
código ya que depende de la experiencia de los programadores o si hablamos de lenguajes de
programación dinámicos como Ruby, Scala y Groovy o herramientas e IDEs que facilitan gran
parte del trabajo de programación.

Medidas relacionadas con la función (UFC – Puntos de Función)

El total de puntos de función no es una característica simple sino que es una combinación de
características del software a las cuales se les asigna un valor que cambia dependiendo de su
complejidad.UFC es igual a la suma de los “n” elementos evaluados por el peso asignado al
tipo de función.
Sin embargo a lo largo del proyecto las funciones cambian, las métricas de puntos de función
tienen en cuenta esto y multiplican los UFC iniciales por un factor de complejidad (asignándoles
un factor de peso que va desde 3 a 15 puntos). Una desventaja de los puntos de función se
presenta cuando el sistema está orientado por eventos. Por eso algunos autores piensan que
UFC no es muy útil para medir productividad.

Los Puntos de Objeto (PO)

Los PO se utilizan en el modelo de estimación Cocomo II con el nombre de Puntos de
Aplicación. Estos son una alternativa a los UFC, y son usados en los lenguajes orientados a
objetos y de scripts. Dan valor a cada pantalla dependiendo de su complejidad: simples = 1,
medianamente complejas = 2, muy complejas = 3. Los reportes van de 2 a 8 dependiendo del
nivel de complejidad, y los módulos en lenguaje imperativo como Java o C++ se contabilizan
como 10. Esto puede ser relacionado directamente a las historias de usuario de algunas
metodologías agiles con lo cual facilita la estimación de la iteración.

Modelo Constructivo de Costo: COCOMO II

Uno de los modelos de estimación más usados es COCOMO (Constructive Cost Model) creado
por el Dr. Barry Boehm. COCOMO apareció por primera vez en su libro Software Engineering
Economics en 1981. En 1999 se definió la segunda versión del modelo que toma en cuenta el
proyecto, el producto, el hardware y la experiencia del equipo de desarrollo en sus fórmulas de
estimación de costo, incluyendo mecanismos de predicción de tiempo.
Cocomo II provee niveles que nos permiten hacer estimaciones en diferentes momentos del
desarrollo ya que la estimación de costos debe de ser un proceso dinámico a lo largo del
desarrollo, actualizando constantemente las variables, la evolución del equipo de desarrollo, las
herramientas y lenguajes involucrados. Los distintos niveles son:
Construcción de prototipos
Las estimaciones de tamaño están basadas en puntos de aplicación con base en componentes
reutilizables, prototipos y la fórmula para estimar el esfuerzo requerido es muy simple: tamaño /
productividad.

Diseño inicial
Está basado en los requerimientos originales del sistema a un alto nivel (pantallas, reportes,
procesos, transacciones) lo que son traducidos a puntos de aplicación, esto nos sirve para
hacer una predicción temprana del costo.

Reutilización
Este nivel se utiliza para calcular el esfuerzo requerido para integrar el código generado por los
IDE’s o herramientas de generación de código reutilizable como Spring Roo o Genexus por
ejemplo, tomando en cuenta componentes reutilizables que facilitan el desarrollo como Apache
Commons.

Post-arquitectura
Ya diseñado el sistema se pueden hacer estimaciones más precisas del tamaño del software,
aquí es importante señalar que el software tiene una tasa de crecimiento de los requerimientos
del sistema entre el 2 y el 5 por ciento mensual, por lo cual no es posible hacer una estimación
exacta pero las predicciones de costo se pueden acercar mucho a la realidad gracias a la
aplicación de métricas que nos permiten tener una variación muy pequeña con respecto al
producto final.
Cocomo está basado en fórmulas para hacer las estimaciones, véase la figura 1 donde se
estima el esfuerzo del personal por mes (PM), después se hace la estimación del tamaño del
proyecto (SIZE) y finalmente se obtiene una proyección del esfuerzo requerido (B)
contemplando los factores involucrados (SF).

Obviamente el realizar los cálculos manualmente es una tarea lenta y tediosa por lo cual
existen muchas aplicaciones que se encargan de realizar todas las fórmulas, como USC
COCOMO II que es la aplicación de la página oficial de COCOMO.
Conclusión
La estimación de costos es una actividad muy importante en el desarrollo de software. Esta
actividad no es estática sino que cambia en diferentes puntos del ciclo de vida del desarrollo.
Se tienen que hacer estimaciones desde diferentes puntos de vista, desde la predicción de
costos hasta la retrospectiva de comportamiento del costo, para lo cual las herramientas de
estimación nos ayudan a agilizar la tarea. Sin duda el poder hacer predicciones con respecto al
costo del software nos da ventajas que facilitan el éxito de un proyecto, sin embargo esto no
debe de ser exhaustivo ya que se tienen variables que el modelo no contempla totalmente
como la incertidumbre, la complejidad o factores humanos de los cuales no se puede tener
control, por lo cual se deben tomar en cuenta los riesgos del proceso de desarrollo de software.
Una de las ventajas de COCOMO es el poder medir el comportamiento de costo de un proyecto
de software de forma interna para la empresa de desarrollo. Lo que nos permite tener un
referente en diferentes puntos del proyecto y así poder comprobar que las proyecciones de
costo originales se cumplan.