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
Jueves, 31 dUTC Enero dUTC 2008 at 00:04
Si alguien te da una estimación de la duración del proyecto, formúlale las siguientes preguntas:
- ¿Esta estimación la ha hecho el equipo que va a hacer el trabajo?
- ¿Cuánto tiempo lleva trabajando junto este equipo?
- ¿Este equipo ha medido su capacidad real y ha utilizado esta medida para hacer la estimación?
- ¿Qué conocimientos tiene el equipo de las herramientas, tecnologías, etc. que se van a utilizar?
Si las respuestas a estas preguntas no son satisfactorias, entonces el cálculo es pura fantasía, es una mentira. ;-)
Las estimaciones o más bien “predicciones” en el desarrollo de software no son muy diferentes de las predicciones meteorológicas. En ambas existen un gran número de variables y factores desconocidos (teoría del caos).
Uno de los mayores beneficios propuestos por las metodologías ágiles (Scrum, Extreme Programming, …) es la estimación mejorada. En lugar de tratar de proporcionar una estimación precisa de todo el proyecto, estos métodos proporcionan una forma de realizar la estimación a corto plazo, maximizar la funcionalidad entregable de manera continua y proporcionar variables de control a largo plazo.
El desarrollo de un producto software modifica sus propios requisitos. Tan pronto como los clientes ven la primera versión, descubren lo que quieren para la segunda versión, … o mejor dicho lo que realmente querían en la primera. Y este aprendizaje es valioso, ya que posiblemente no podría haber tenido lugar sobre la base de la especulación. Este aprendizaje sólo puede venir de la experiencia.
¿Qué pasa si vemos la “debilidad” de los requisitos como una oportunidad y no como un problema?
De las cuatro variables de control (calidad, coste, tiempo y alcance), podríamos ver el alcance como la más fácil de controlar. Debido a su “debilidad”, podríamos ir dándole forma. Si se acerca una fecha de entrega, siempre se puede aplazar algo menos prioritario para la siguiente versión (o iteración). No intentando abordar demasiada funcionalidad, se puede conservar la capacidad de entregar con la calidad requerida en el tiempo estimado.
Además, entregando más frecuentemente se puede garantizar que el cliente va a tener el mejor producto posible en el mínimo tiempo (Build half a product, not a half-ass product). ;-)
Y pienso que esto es lo que deberíamos inculcar a nuestros clientes para que poco a poco se fuera estableciendo una relación de confianza basada en nuestra experiencia con ellos, que llevara a estimar iteraciones de tiempo en lugar de proyectos completos, ofreciendo al final un mejor resultado de las cuatro variables que indudablemente se traduciría en captación y retención de más clientes satisfechos.
Jueves, 31 dUTC Enero dUTC 2008 at 22:09
Claro. Si añades el factor humano entonces no hay estimación que resista.
Yo me conformaría con obtener una valoración que un equipo humano con una cualificación media (¿que entiendo por media? pues vaya usted a saber) pueda cumplir.
Y por cierto. Lo de las metodologías ágiles (ya escribiré algún otro post sobre el tema)están muy bien para clientes con el bolsillo tambiñen ágil, es decir, que va gastando iterativamente hasta que obtiene algo decente. Pero cuando el alcance y el precio son cerrados… ¡ah querido amigo!
Sábado, 2 dUTC Febrero dUTC 2008 at 21:41
Efectivamente, lo normal es que el cliente quiera cerrar el alcance y el precio.
También es verdad que no hay “predicción” que resista, sólo hay que ver las estadísticas de los proyectos que terminan en plazo y coste.
Por eso utilizando una metodología tradicional, en el mejor de los casos, para evitar los riesgos derivados de la “predicción”, el cliente pagará un “colchón” de, digamos, ¿un 30%?, o incluso, como he llegado a ver, un 50%.
Porque imagino que multiplicar por 50 tendrá un margen suficiente para evitar riesgos.
Es una lástima que el cliente tenga que pagar un colchón de una estimación imprecisa y obtener un producto que en muchos casos no quería (porque no sabía lo que quería con exactitud).
Todo dependerá de la relación de confianza que tengas con el cliente, pero algunos preferirán pagar por el trabajo realizado (en forma de iteraciones cortas de tiempo) en lugar de pagar “colchones”. ;-)
De esa manera, el cliente sabe (utilizando extranets de seguimiento) que va a pagar por el valor justo del servicio y el proveedor evitará los riesgos derivados de intentar adivinar el futuro (todos ganan).
Además, con la aproximación ágil, si el cliente no está satisfecho en alguna de las iteraciones, puede parar el proyecto. Esto también es una ventaja que puede facilitar la venta del modelo.
No se, de cualquier manera es un tema complejo. ;-)