En los últimos días he dedicado algún tiempo a buscar información sobre mecanismos de Estimación Objetiva de proyectos de construcción de software.
Es algo recurrente en mí. Cada año, más o menos, me entra esta ansiedad por encontrar la bola de cristal que me permita saber cuanto tiempo y esfuerzo va a costar construir el sistema A, B o C. Y cada año, tras el peregrinaje de rigor por las páginas, artículos y libros que versan sobre el tema, regreso a casa con la misma frustración.
El “Secreto de la Estimación Objetiva” dice:
Utiliza algún sistema homogéneo para medir el tamaño de un sistema.
¡Já! Empezamos por algo fácil. Es sencillo utilizar un sistema de medida homogéneo cuando las aplicaciones a medir son también homogéneas. Se pueden contar páginas, si se trata de aplicaciones web o, refinándolo más, contar los elementos que las generan (JSPs, ASPs, ficheros HTML, clases, EJBs, o lo que sea), asignándoles incluso un orden de complejidad. Esto nos permite comparar el tamaño de dos aplicaciones (“la aplicación A es el doble de grande que la aplicación “B”).
Pero ¿qué hacer si se trata de medir cosas algo diferentes? Hala! Compárenme una aplicación COBOL/CICS, con sus pantallas, transacciones, y todas sus cositas, con la aplicación web de antes. En este caso cuesta algo más comparar los tamaños de ambas.
Para salvarnos de este aprieto, aparece allá por 1979 (gracias, Allan Albrecht), los Puntos Función. En todos los casos, con algo de práctica, seremos capaces de contar los EO, EI, EQ, ILF, EIF y demás elementos. Aunque al no tratarse de pantallas, programas, rutinas, páginas, clases, etc. sino un nivel de abstracción superior, cuesta algo más de esfuerzo tomar las medidas.
Esto es otra muestra más de que cuando intentamos simplificar algo, como es el homogeneizar la medida de tamaño de sistemas heterogéneos, nos llevamos la complejidad a otra parte. Vamos, que hay que hacer un curso para medir bien con Puntos Función.
Traduce la medida resultante a algo tangible.
Es posible, por tanto, obtener una medida de tamaño de un sistema de software. Eso sí, no se consigue el tamaño en líneas de código, megabytes de los ficheros de código fuente o, lo que es mucho más util, horas de esfuerzo a realizar por un equipo de trabajo con una productividad media (otra variable más).
Para convertir los Adjusted Function Point -que tendremos que calcular a partir de los Unadjusted Function Point considerando los parámetros del entorno del proyecto- en algo útil, habrá que multiplicarlos por un “Número Mágico” que nos dará una aproximación al esfuerzo necesario de desarrollo, es decir, su coste (es decir, su precio).
Para obtener este factor -que, además no es inmutable- es preciso contar con una cierta historia en desarrollo de software. Si se conoce el esfuerzo que resultó necesario y los puntos función de cada uno de los sistemas desarrollados en el pasado, es posible obtener un factor de conversión suficientemente fiable como para ser capaces de predecir lo que costará un sistema nuevo.
Claro que es preciso que los proyectos analizados sean más o menos homogéneos, que no hayan tenido circunstancias excepcionales que desvirtúen la estimación, desarrollados preferiblemente en la misma compañía y entorno, y preferiblemente por el mismo equipo o equipos de cualificaciones semejantes.
Fácil ¿eh?
En resumen, que yo sigo contando pantallas y multiplicando por cincuenta.
Tags: Métricas, Metodología
