Hace unos pocos días nos dejaba Barry Boehm unos de los pioneros de la Ingeniería de Software. Como pequeño homenaje a su figura, hoy hablaremos de la estimación del coste de proyectos software.
El dinero mueve el mundo y el software no es la excepción. Antes de empezar un nuevo proyecto de desarrollo, el cliente siempre va a preguntar: ¿y esto cuánto me va a costar?. Dependiendo de vuestro rol en el equipo de desarrollo, a lo mejor esta pregunta (y las preguntas en cascada que genera) no os llegan todavía pero para progresar en la carrera de ingeniero software es imprescindible entender mejor las economías del software.
Este tema fue el principal foco del trabajo de Barry. Su obsesión siempre fue mover el desarrollo de software de un arte a una ingeniería. Y para esto se necesitaba un modelo que permitiera estimar los costes de un proceso de desarrollo y así poder evaluar y planificar su ejecución. Sobretodo una vez empezó a quedar claro (hablamos del año 1972) que su predicción de que el coste del software desplazaría al coste del hardware como principal preocupación y limitación en nuevos proyectos era totalmente acertada. Y lo sigue siendo, incluyo para proyectos de machine learning.
Barry Boehm’s critical insight was to see that, if building software was engineering, it needed a cost modelling discipline. This when most were mesmerised by being able to build it at all and narrowly concerned simply with correctness.
— Anthony Finkelstein (@profserious) August 22, 2022
Hoy en día la importancia de los aspectos económicos de la ingeniería de software está plenamente aceptada. El propio Software Engineering Body of Knowledge (SWEBOK) dedica un capítulo entero a estos temas.
Ejemplo de modelo de estimación de costes: COCOMO
Barry se hizo “famoso” (vaya, lo que hoy llamaríamos “influencer“) con su propuesta de modelo de estimación de costes llamado COCOMO presentado en su libro, ya todo un clásico, Software Engineering Economics.
No es mi intención explicar COCOMO (ni sus variantes, después de COCOMO vino COCOMO II y luego muchas más “spin-offs” del modelo inicial) sinó simplemente daros una idea de como funcionan este tipo de modelos.
Simplificando, estos modelos son modelos paramétricos, donde hay dos tipos de parámetros fundamentales:
- El tamaño del proyecto, medido principalmente en función de líneas de código
- Los “cost drivers”, es decir todos los factores (requisitos de calidad, de seguridad, aspectos y limitaciones organizacionales de la empresa como la disponibilidad y experiencia de desarrolladores con la tecnología a utilizar,…) que pueden empeorar el coste del proyecto.
El coste del proyecto sale de aplicar una fórmula que combine estos parámetros. Normalmente multiplicando el tamaño con factores de (de)crecimiento derivados de los demás parámetros más alguna suma adicional.
La idea es que dos proyectos del mismo tamaño pueden tener costes diferentes en función de su contexto.
Ya, ya, ahora váis a empezar a criticar el modelo. Empezando por decir que el número de líneas de código no es una buena métrica. Y estoy de acuerdo. Pero se han probado muchas cosas (puntos de función, número de clases, hasta número de commits en proyectos parecidos anteriores) y todos tienen sus problemas. Como mínimo, el concepto de líneas de código es algo que todo el mundo entiende.
En todo caso, como os decía, la idea no es defender COCOMO, sino explicaros que sea cual sea el modelo que vayáis a utilizar, al final hay que tener en cuenta no sólo el tamaño y complejidad del proyecto sino todo el entorno donde éste se vaya a desarrollar. Cuando yo trabajaba de programador mi método adhoc era pensar cuanto creía yo que me iba a tomar desarrollar la funcionalidad (eran funcionalidades razonablemente pequeñas y muy repetitivas con la que me podía basar en mis experiencias anteriores) y multiplicar el resultado por dos. Lo de multiplicar por dos era para tener en cuenta las interrupciones que iba a sufrir durante el desarrollo y que me harían perder el tiempo hasta duplicar el tiempo estimado inicialmente. En vuestro caso a lo mejor el “2” no es el número adecuado y hay que multiplicar por 3 o 4 o …
Y aunque la estimación en sí pueda acabar saliendo muy desviada, el ejercicio de hacerla será útil en si mismo. Os obligará a definir bien los límites del proyecto, a detectar las partes más inciertas y a tener más argumentos para poder empezar a negociar con clientes que lo quieran todo bueno, bonito, barato y para ayer.
Más allá de costes
Calcular el coste de un proyecto no es sólo útil para enviar la factura al cliente. Barry defendió siempre una visión más global, donde conocer el coste permitía comparar ese coste con el valor que iba a generar el software. Y decidir así si era una buena idea llevarlo a cabo. Veía el software como una parte clave de la empresa. Desde esta perspectiva, el software no hay que verlo como un coste sino como una contribución al modelo de negocio. Esta idea se ha ido popularizando (entre otros por el CEO de Microsoft) bajo el lema “every company is a software company“, es decir, toda empresa hoy en día es una empresa software.
También reconoció que basarlo todo en una estimación inicial (cuando todavía mucha información era incierta) generaba unos riesgos enormes en los resultados de la estimación, con lo que defendió la idea de abandonar el modelo en cascada clásico y moverse a métodos de desarrollo iterativos e incrementales, en definitiva más ágiles ;-). Podéis leer más acerca de las contribuciones de Barry en este artículo tributo.
Últimos comentarios