Algún tiempo atrás, un cliente me solicitó realizar contar los puntos de función (PF) para un proyecto de gran envergadura. Debido a que ya he realizado este tipo de estimaciones varias
veces, intuí que lo que me estaban pidiendo no
era factible.
En vez de iniciar
la cuenta de manera similar a como lo había hecho en otros proyectos
(siguiendo principalmente los lineamientos del manual gratuito
de Longstreet Consulting), comencé a estimar el esfuerzo asociado a
la estimación en sí, que preliminarmente resultó de un par de meses
de dedicación exclusiva.
En este artículo explicaré cómo
logre de todos modos aproximar el tamaño en puntos de función para el proyecto, las razones que me llevaron a anticipar que realizar una cuenta de la forma
tradicional no era posible, para terminar explicando por qué no es
aconsejable realizar una cuenta de puntos de función para proyectos
de gran envergadura.
En primer lugar, lograr una
aproximación (que necesariamente incorpora un error, pero que de
todos modos resulta aceptable) de un proyecto en puntos de función
es extremadamente fácil utilizando una técnica que se llama
backfiring. La técnica del backfiring se sustenta en que hay miles
de instituciones que han entregado a instituciones, como la Software
Productivity Research, sus cuentas de puntos de función y el tamaño
en líneas de código de sus proyectos. Esto ha permitido establecer
un “promedio industrial de líneas de código en un lenguaje X
necesario para producir 1 punto de función”. La Software Productivity Research publica año a año una tabla con
tasas de conversión para más de 700 lenguajes y dialectos de
programación.
En el caso de Java, este número mágico
es 53. Es decir, se requieren 53 líneas de código Java, con toda su
documentación y artefactos asociados (casos de uso, análisis, diseño, pruebas, matrices
de trazabilidad, javadoc, y un largo etc.), para producir el
equivalente a un punto de función.
Con esto, la estimación es sencilla:
Se cuentan las líneas de código en Java, y se dividen por 53, y se
obtiene la aproximación a PF.
Dado esto, considerando que el proyecto para el cual se me pidió la estimación tiene 1.119.124 LOCs al día de hoy, su cuenta en puntos de
función es de aproximadamente 21.115,5 PFs.
(El proyecto que menciono,
probablemente tenga un tamaño en PFs mayor al mencionado, debido a
que si bien la mayor parte está construida en Java, hay una parte
considerable – que estimo sobre el 30% – que está construida en
base a otros lenguajes que no consideré para el estudio.)
Obviamente, el backfiring tiene una
limitación severa (además de su falta de precisión): El software
al que se le quiere estimar el tamaño en PFs debe tener un tamaño
en LOCs conocido para poder aplicarlo, lo que no obviamente no está
disponible si uno estimando un software a construir en el futuro.
Es por eso que su uso principal es en actividades de benchmarking, y
no de estimación. Sin embargo, cabe destacar que también puede ser
utilizado con un buen grado de precisión para estimar el esfuerzo de modificaciones de
software de tamaño inferior a 15 PFs.
Para entender por qué supe que la cuenta que me estaban pidiendo no era factible de realizar, consideren que un equipo auto-organizado, siguiendo metodologías ágiles tiene una productividad promedio de 15 PFs por miembro al mes. Para equipos donde todos son expertos, esto puede llegar a 20 PFs por miembro al mes, y cuando son novatos, puede bajar a 10 PFs por miembro al mes.
Si tomamos el promedio (15 PF), y
asumimos una metodología ágil (en particular SCRUM, complementado
con cualquier técnica ágil con excepción de pair programming), un
equipo de 5 personas tendrá una productividad mensual de 75 PFs, y
una anual de 900 al año, lo que cae en el rango de los proyectos
pequeños.
Considerando que en Chile el sueldo
promedio de un Ingeniero Civil en Informática con 5 años de
experiencia es de $1,532.210, es decir, al dólar de hoy U$3.167,7,
el costo de un punto de función es en promedio de $102.147 pesos, o
U$211 aprox. Por lo que el proyecto pequeño del que hablo, costaría
aproximadamente $91.932.300, o U$189.900
Si comparamos los $189.900 de este
proyecto pequeño y ficticio, con los más de U$24.000.000 del proyecto grande y real para el cual se me pidió la estimación (haciendo la abstracción no menor del markup de las empresas
proveedoras), no parece irracional asumir que realizar una cuenta de
PFs para este proyecto es un desafío mayor e involucrará un consumo
de recursos probablemente difícil de justificar.
Pero ¿Por qué generalizar a que no se
deben hacer cuentas de PFs para proyectos de gran envergadura (más
de 10.000 PFs)? (a menos que obviamente hayan razones informadas para
hacerlo)
Consideren lo siguiente:
- Un experto en contar PFs es capaz de contar entre 400 y 600 por día
- La tasa promedio del mercado (al año 2010) para las firmas especializadas en contar PFs era de U$3000 al día (en USA), lo que lleva a un costo entre U$5 y U$7 por cada PF contado.
Con estos antecedentes, y a modo de ejemplo, se deduce que
contar los puntos de función para el proyecto que estaba analizando habría tenido un
costo de U$105.577,5 y U$147.808,5 (considerando el dólar de hoy a
$483,7 pesos chilenos por dólar, sólo contar los PFs habría salido
entre $51.067.836,75 y $71.494.971).
El esfuerzo asociado a la actividad de
contarlos además habría oscilado entre los 35 y lo 53 días –
persona.
Generalizando, se puede afirmar que,
tomando un costo promedio de U$6 por PF, un proyecto de más de
10.000 PFs costará inmediatamente U$60,000 más si se cuentan sus
puntos de función.
A lo anterior, se debe agregar que si los requerimientos no están aceptablemente completos y correctamente levantados, la estimación tendrá fuertes retrasos y errores.
A lo anterior, se debe agregar que si los requerimientos no están aceptablemente completos y correctamente levantados, la estimación tendrá fuertes retrasos y errores.
Esto lleva a la siguiente conclusión: Si bien teóricamente, es posible estimar los puntos de función de cualquier proyecto, en la práctica para proyectos grandes, los costos, tiempo y riesgo involucrados se elevan tanto que esta actividad se vuelve difícil de justificar.
Es por esto que en la práctica, los
puntos de función se utilizan para proyectos de un tamaño
proyectado inferior a los U$5.000, y la mayoría de las veces para
proyectos pequeños de menos de U$1.000.
Pero, si entonces los proyectos de gran
escala (más de 10.000 PFs) no se pueden estimar de manera
económicamente conveniente usando puntos de función, ¿Existe una
forma de hacerlo?
La respuesta es sí, y la forma es
la siguiente…
(Fin a lo Matrix Reloaded)
Referencias:
- Software Productivity Research
- ISBSG
- www.mifuturo.cl
- Banco Central de Chile
- Longstreet Consulting Inc.
- Software Engineering Best Practices: Lessons from Successful Projects in the Top Companies
2 comentarios:
Jaime,
Muy buen artículo. Efectivamente el cálculo de Puntos de Función es usado muchas veces a diestra y siniestra, casi sin consideraciones y lo peor, creemos en ello como un Dogma. Hoy en día, aparte de las razones que das, existen múltiples herramientas que generan código por sí mismas a partir de interfaces gráficos de desarrollo, y en consecuencia, la fórmula de línea de código versus tiempo o sea, PF versus tiempo y costo de ejecución tienden a desconfigurarse. Me imagino que en próximo artículo abarcarás esta temática al indicar el método que propones.
Saludos
Rafael
Gracias por tu comentario Rafael.
Coincido con tu apreciación acerca de lo poco conducente que puede llegar a ser el uso de los PF sin una adecuada consideración de lo que implica. Una organización que decide conscientemente usar PFs puede obtener grandes beneficios debido a la gran cantidad de estadísticas disponibles contra las cuales se puede hacer benchmarking, pero hacerlo sin contar con expertos, sin contar con la capacidad de realizar una adecuada ingeniería de requerimientos, y sin una estrategia general tras su uso rara vez brinda una relación costo beneficio aceptable.
Con una estrategia adecuada, incluso lo que planteas respecto a la distorsión que introducen las IDES puede ser usado a favor de la organización, para determinar temas como la competitividad relativa, el retorno a la inversión sobre la compra de plataformas de desarrollo, la efectividad de las iniciativas de mejora de procesos, etc.
Saludos
Publicar un comentario