Modelos de estimación de costes en proyectos de desarrollo de software
|
Una mujer puede tener un hijo en nueve meses, pero nueve mujeres no pueden tener un hijo en un mes.
|
1.- INTRODUCCION
Desde el comienzo de la informática, a mediados del siglo XX, la escritura de software ha ido ganando peso en esta industria. Los productos y aplicaciones son cada vez mas complejos y por tanto cada vez más costosos de construir y mantener.
Se trate de un software con objetivo comercial, o de una aplicación desarrollada internamente para su uso en una organización, resulta básico disponer de una estimación razonablemente precisa de los costes y los plazos en que se va a ejecutar un proyecto.
Si hay una palabra clave en la industria de las TI, esta es Predictibilidad.
Tan importante, o más, que desarrollar rápidamente un software es hacerlo en el plazo previsto. Aunque el usuario o cliente siempre desea tener disponible su producto o aplicación cuanto antes, el auténtico reto de la gestión de software es cumplir con las fechas comprometidas. Tampoco está de mas cumplir con los costes.
De hecho, la rapidez en el desarrollo de software se encuentra con límites objetivos si se desea obtener una calidad adecuada. Las posibilidades de paralelización de trabajos se ven limitadas por la necesidad de integración y reutilización.
Como formuló, de forma tal vez exagerada pero muy gráfica, Frederick Brooks [4]: "Añadir gente a un proyecto de software retrasado consigue aumentar el retraso". De aquí se desprende el corolario (todavía mas exagerado): En vez de añadir gente, selecciona a los importantes y echa a todos los demás".
A lo largo de la (corta) historia del desarrollo de software se han desarrollado diferentes modelos para la estimación de costes y plazos de proyectos. Entre ellos destacan el de Putnam y el COCOMO.
En las páginas siguientes describiremos someramente estos dos modelos y luego el modelo simplificado desarrollado en ATCA.
2.- COCOMO
El COnstructive COst Model (COCOMO) fué desarrollado por Barry Boelm en TRW Aerospace, y publicado [5] en 1981.
Según DeMarco [1] se trata de un modelo paramétrico de factor simple derivado de la observación de una muestra de proyectos.
Calcula el esfuerzo requerido en un proyecto como:
Esfuerzo = a * Tamañob * m(X)
Duración = c * Esfuerzod
donde:
Esfuerzo = esfuerzo requerido en meses-hombre (un mes-hombre = 152 horas-hombre)
Tamaño = tamaño del desarrollo en miles de lineas de código
m(X) = factor corrector que depende de 15 atributos
Duración = duración del proyecto en meses
a, b, c, d = constantes según las tablas que siguen
El modelo se puede aplicar en tres modos: básico, intermedio y detallado. En el modelo básico no se consideran los 15 factores correctores y en el detallado se desglosan a nivel de módulo.
Además, el ambiente de desarrollo puede ser de tres tipos: orgánico, semilibre y rígido, dependiendo de si se trata de un desarrollo "por libre" o dentro de un ambiente muy controlado y restrictivo.
Las constantes utilizadas son:
| Modelo Básico | Modelo Intermedio | |||||
| Modo | a | b | c | d | a | b |
| Orgánico | 2,40 | 1,05 | 2,50 | 0,38 | 3,20 | 1,05 |
| Semilibre | 3,00 | 1,12 | 2,50 | 0,35 | 3,00 | 1,12 |
| Rígido | 3,60 | 1,20 | 2,50 | 0,32 | 2,80 | 1,20 |
El significado de los atributos es el siguiente, según su tipo:
- De software
RELY: Criticidad del software en operación
DATA: Tamaño de la base de datos en relación con el tamaño del programa fuente.
CPLX: Complejidad del producto.
- De hardware
TIME: Limitaciones en el uso de CPU.
STOR: limitaciones en el uso de memoria.
VIRT: volatilidad de la máquina virtual.
TURN: tiempo de respuesta requerido.
- De personal
ACAP: Cualificación de los analistas.
AEXP: Experiencia del equipo en aplicaciones similares.
PCAP: Culificación de los programadores.
VEXP: Experiencia del personal en la máquina virtual.
LEXP: Experiencia en el lenguaje de programación.
- De proyecto
MODP: Uso de prácticas modernas de programación.
TOOL: Uso de herramientas de desarrollo de software.
SCED: Limitaciones en el cumplimiento de la planificación.
Este modelo, aunque útil desde el punto de vista conceptual por su simplicidad, adolece de algunos defectos que lo hacen poco útil en la actualidad. Algunas razones serían:
- El uso del número de lineas de código como métrica del tamaño de un producto software. Si bien pudo ser útil en una época en que la mayoría del software se escribía en lenguajes procedurales (COBOL, PL1, etc..) sobre mainframes, en la actualidad la industria lo considera mayoritariamente una práctica obsoleta.
- Considerar la productividad como una constante universal (en realidad tres). La experiencia indica que la productividad en el desarrollo de software es una métrica terriblemente compleja que varía fuertemente según factores que no son sólo del proyecto sino, especialmente, de la organización de desarrollo y sus procesos.
- Los atributos del proyecto que se utilizan para matizar la productividad y calcular el esfuerzo están, lógicamente, obsoletos.
3.- MODELO DE PUTNAM
Este modelo fué propuesto por Lawrence Putnam [2] a partir de 1978, y es calificado por DeMarco [1] como un modelo de costes sensible al tiempo.
La gran diferencia respecto al COCOMO es que considera la productividad como una variable más de la "ecuación del software".
A partir también de la observación de una base de datos de proyectos muy amplia, dedujo empíricamente la siguiente ecuación:
Tamaño (con cierto nivel de defectos) = (Esfuerzo / Beta)1/3 * Duración4/3 * Productividad del proceso
donde:
Tamaño = tamaño del producto software en Lineas de Código o Puntos-Función
Esfuerzo = dedicación de personal en meses-hombre o horas-persona
Beta = parámetro que depende del tamaño del proyecto
Duración = duración del proyecto en meses o dias
Productividad del proceso = tamaño desarrollado por unidad de esfuerzo para una determinada duración del proyecto
Si una organización dispone de una base de datos de proyectos finalizados suficiente, puede, se supone, calibrar este modelo para calcular los valores posibles de Beta y la productividad del proceso de software a distintos plazos.
Supone ciertos avances conceptuales respecto a modelos simples, dado que no considera la productividad una constante universal, sino propia de cada organización y dependiente de la duración de cada proyecto. Por otra parte, no está anclado a la obsoleta métrica de lineas de código, admitiendo el uso de puntos-función.
Sin embargo, el hecho de utilizar un parámetro (Beta) diferente para cada organización y dependiente del tamaño del proyecto, hace que resulte compleja y poco intuitiva, requiriendo una calibración al menos laboriosa.
4.- MODELO DE ATCA
A partir de 2004 se desarrolló en ATCA (Asociación Técnica Cajas de Ahorros, AIE), en Zaragoza (España) un modelo de estimación de costes y plazos como parte del proceso de implantación y certificación del modelo CMMI-SW/SE hasta nivel 5.
El punto de partida previo fué la implantación de la métrica de punto función según el "Funtion Point Counting Practices Manual r 4.1" del IFPUG (International Funtion Point Users Group). Se realizó un recuento general de la funcionalidad de la base instalada de las aplicaciones, que dió un resultado de más de 130.000 pf. y se pasó a contar los puntos función en las fases de diseño de todos los proyectos, con un recuento final en el momento de la implantación.
Hay que tener en cuenta que ATCA es una organización de TI cuyo fin es operar, mantener y ampliar un conjunto de aplicaciones muy integradas, que soportan la actividad de cuatro Cajas de Ahorros españolas. En consecuencia, el tipo de proyectos de software que se realizan son relativamente pequeños (pocos requieren un esfuerzo de más de 10.000 horas-persona).
A medida que se fué disponiendo de datos de productividad en términos de horas-persona por punto-función desarrollado, se observó que, en un rango de coste de proyectos de entre 200 y 10.000 horas-persona, la productividad es predecible con suficiente fiabilidad, siempre que se matice con determinados factores de ajuste que dependen de las características del proyecto.
Los parámetros de los modelos se calibran una vez al año, dado que afectan a los objetivos que se fijan a todo el personal y por tanto a su remuneración variable.
4.1.- Estimación del esfuerzo
Esfuerzo = Tamaño * Productividad estándar * (f1 * f2 * ....* fn)
donde:
Esfuerzo = dedicación estimada en horas-persona
Tamaño = tamaño de la aplicación a desarrollar en puntos-función no ajustados (unadjusted funtion points)
Productividad estándar = productividad de un proyecto medio en horas-persona por punto-función
fx = 10 factores de ajuste del esfuerzo dependientes de las características del proyecto
Los factores de ajuste son:
| Factor | Descripción | Valor (x) |
Observaciones |
| 1 | Número de entidades en las que se va a instalar la aplicación |
1: 0% 2: 10% 3: 15% 4: 17,5% |
|
| 2 | Experiencia del equipo de trabajo | Del -20% al 20% | Según la experiencia media del equipo en relación a la media de la empresa |
| 3 | Disponibilidad del usuario | Del -20% al 20% | Según disponibilidad y compromiso del usuario |
| 4 | Dominio de la tecnología utilizada | 0% al 40 % | Según las necesidades de formación |
| 5 | Criticidad del servicio para el negocio | del -10% al + 10% | |
| 6 | Complejidad de la migración de datos | del +0% al + 20% | |
| 7 | Dependencias externas | del +0% al + 20% | |
| 8 | Procesos contables o con movimiento de cuentas de clientes | del +0% al +50% | En base a un escalado de número de procesos |
| 9 | Nivel de reutilización de código existente | del -60% al 0% | En proporción al porcentaje de código reutilizado |
| 10 | Complejidad de las pruebas | del 0% al 20% |
Nota: los factores se utilizan en la fórmula como fx = 1 + x/100
Los rangos en los que se mueven los factores de ajuste pueden parecer muy amplios, pero se establecen en cada proyecto en base a la comparación con proyectos anteriores similares y se auditan para asegurar que su uso está justificado.
Los puntos función se calculan incluyendo los de nuevo desarrollo, los que suponen modificación y los que se da de baja.
La productividad estándar para un proyecto depende de la plataforma sobre la que se va a desarrollar. En la mayoría de las aplicaciones ATCA la lógica de negocio y los datos radican en los servidores centrales, mientras que la interfase de usuario reside en una aplicación local denominada "terminal financiero" o en una aplicación web.
En aplicaciones que manejan tanto los datos como la lógica de negocio y la interfase de usuario se utiliza la productividad estándar "host".
La tabla de valores de la productividad estándar es para 2009, y en horas-persona por punto-función:
| Accion sobre la funcionalidad | |||
| Entorno | Alta | Modificación | Baja |
| Host | 5,0 | 1,5 | 1,0 |
| Terminal | 2,0 | 0,5 | 0,3 |
| Web | 3,5 | 1,5 | 0,5 |
Aunque la productividad estándar para un proyecto en que los factores de ajuste no tengan incidencia es de 5 horas-persona por punto-función, la productividad real media observada en los 40 últimos proyectos cerrados antes de fin de junio de 2009 es de 6,58 horas-persona por punto-función, con una desviación típica de 2,25 hh/pf. Este valor se refiere a la productividad en proyectos de nueva funcionalidad sobre entorno host. Las funcionalidades modificadas o eliminidas y las creadas en otros entornos implican una puesta en equivalencia de acuerdo a la tabla anterior.
Este mayor valor observado es debido a que, realmente, los factores sí son aplicables.
En la imagen que sigue se observa el Control Chart de la productividad a junio de 2009.
4.2.- Estimación de la duración
4.2.1.- Ecuación esfuerzo-duración.
A partir de una completa base de datos de proyectos de diferentes tamaños y características, desarrollados a lo largo de mas de 10 años, se comprobó empíricamente que, para un rango de proyectos con coste de desarrollo entre las 200 y las 10.000 horas-persona, y descartando los que habían sufrido incidencias "anormales", la relación entre estas dos variables seguía la forma de la siguiente curva:
Esfuerzo = k * Duración2
donde:
Duración = plazo estimado en dias naturales entre el inicio del diseño y la entrega para pruebas de usuario
k = constante de agilidad en el desarrollo. (Valor en 2009: 0,1).
Aunque aceptamos que la agilidad varía con el tamaño del proyecto, en el rango de tamaños que se realizan en ATCA (entre 200 y 10000 h-h), se ha demostrado válido asumir que es constante.
Esta ecuación se ha formulado así por la facilidad con la que es recordada, dada su similitud con la ecuación de Einstein: e = m * c2 .
En el gráfico a continuación se representa la forma de esta curva para diferentes valores de k.
En ATCA se ha comprobado que el valor de k mas realista es de 0,1.
4.2.2.- Valor de los parámetros
Denominamos la contante k como la agilidad en el desarrollo. Una k mayor implica que un proyecto que requiere un determinado esfuerzo somos capaces de desarrollarlo en menos tiempo.
Esta constante de agilidad nos marca la relación entre las dos variables existente si queremos mantener una calidad y una productividad uniforme en todos los proyectos de la organización. Nos indica el número de personas que, de promedio, deben trabajar en el proyecto desde su inicio a su entrega. Lógicamente, la dirección puede, si así lo juzga oportuno o las circunstancias lo obligan, asignar mas o menos personal del "adecuado". En este caso, puede ocurrir que el proyecto termine antes o después del plazo estandar, pero seguramente la calidad y/o la productividad se verán perjudicadas.
Este planteamiento es válido en una organización que tenga todos sus procesos gestionados (o, en terminología CMMI, institucionalizados), de forma que obtenga unos resultados suficientemente uniformes a lo largo de todos los proyectos que aborda.
El objetivo de una gestión de calidad no es ser capaces de terminar rápido y bien algunos proyectos, sino entregar los proyectos con una calidad predecible, un coste predecible y un plazo predecible. Seguro que esto, además, permitirá mejorar de forma paulatina pero firme la calidad, productividad y velocidad de las entrega.
Se puede plantear las razones que hacen que planificar un proyecto alejándose de la k estándar perjudica la calidad y la productividad. Se ha observado que un equipo de trabajo mayor del adecuado ocasiona dificultades de coordinación que provocarán retrabajo, despilfarro de recursos e incidencias. En el caso contrario, si planificamos a demasiado plazo, se pierde la "tensión creativa" y baja la productividad. También se incrementa el riesgo de otro gran enemigo de un proyecto, que es el cambio de especificaciones una vez comenzado el desarrollo.
4.3.- Comparación del modelo de ATCA con el de Putnam y COCOMO
4.3.1.- ATCA vs. COCOMO
Como se ha comentado, no es posible comparar la estimación de esfuerzo de un proyecto entre los modelos de ATCA y COCOMO dado que este último utiliza como base el número de lineas de código, algo que no se utiliza para nada en ATCA. Además, considera la productividad como una constante universal, mientras que en ATCA es un parámetro que se va ajustando con el tiempo, aunque lentamente. Por último, las características o atributos del proyecto que matizan la productividad, aún respondiendo a conceptos similares, son muy diferentes.
Sin embargo, el cálculo de la relación entre el esfuerzo y la duración del proyecto si son muy similares.
Si transformamos la ecuación de COCOMO a unidades "europeas", es decir, horas-persona y días naturales de proyecto, la ecuación queda como:
Duración = 12,69 * hh0,35
esto para valores de c y d correspondientes a un proyecto "semilibre".
En la gráfica que sigue se observa la curva de duración de proyectos en función de su esfuerzo en ambos modelos. Como se puede observar, en proyectos de hasta 10.000 hh las curvas son casi paralelas. El hecho de que COCOMO asigne una duración mayor al proyecto que lo observado en ATCA, lo podemos atribuir a que la práctica de desarrollo de software ha avanzado en los 28 años que hay entre los dos modelos. También a que en el modelo de ATCA no se incluye el tiempo de test de usuario.
4.3.2.- ATCA vs. Modelo de Putnam
Como se ha dicho, la mayor diferencia entre el modelo utilizado en ATCA y el de Putnam radica en que en ATCA se asume que la productividad, en un rango de tamaño de proyectos desarrollados en un plazo razonable, es un parámetro predecible en función de determinadas características del proyecto.
Si en la ecuación del software de Putnam asumimos que la Productividad = Tamaño / Esfuerzo, podemos sustituir la productividad por esta relación, quedando dos variables y el parámetro Beta, con la siguiente ecuación final:
Esfuerzo = Beta-1/2 * Duración2
de forma que la k de ATCA es igual a la Beta-1/2 de Putnam, y por tanto, en esas circunstancias, el modelo es el mismo. Igualmente, se puede asumir que es una constante dentro de un rango determinado de tamaño de proyectos.
Conviene insistir en que si un proyecto se aleja de la relación teórica entre Duración y Esfuerzo debido a que se asigna un número sustancialmente mayor o menor de personas al equipo de trabajo de las que son correctas, la productividad (y posiblemente la calidad) se ve perjudicada, de forma que las asunciones anteriores ya no serían válidas.
5.- CONCLUSIONES
Como resultado del análisis realizado observamos que a lo largo de la historia del desarrollo de sofware no se ha avanzado demasiado en la definición de modelos de estimación, probablemente debido a la dificultad intrínseca asociada a la medición de los procesos de software.
La experiencia de ATCA, con la implantación de un modelo propio simplificado, es razonablemente positiva. Es mejor en la estimación del esfuerzo requerido en un proyecto de software que en la estimación del plazo.
Comparando los modelos vemos que realmente tienen un gran paralelismo, subyaciendo en los tres los mismos conceptos.
Por último, hay que insistir en que los valores de productividad o agilidad que se puedan obtener en distintas organizaciones raramente serán directamente comparables, dado que dependen del nivel de madurez, la industria en que se desenvuelven, su cultura y tamaño.
REFERENCIAS
Bibliografia
[1] Controlling Software Projects de Tom DeMarco. El capítulo 17 trata sobre modelos de relación coste-plazo o staffing.
[2] Five core metrics de Lawrence H. Putnam y Ware Myers. Proponen la ecuación del software base del modelo de Putnam.
[3] Estimating Software-Intensive Systems, de Richard D. Stutzke trata en el capítulo 12 la relación entre el coste, plazo y personal asignado a un proyecto de software de manera profunda y rigurosa.
[4] The mythical man-month, de Frederick P. Brooks explica las razones por las que el equipo de trabajo no puede aumentar de forma eficiente por encima de determinado umbral.
[5] Software engineering economics, de Barry Boehm, donde se propone el modelo COCOMO.
[6] Measuring the Software Process de William Florac y Anita Carleton, explican la gestión estadística de procesos y la construcción de "control charts".
Wikipedia
Modelos paramétricos de software
Webs
International Funtion Point Users Group
International Software Benchmarking Standards Group
Versión para impresión
Enviar a un amigo
Versión en PDF