¿Y antes de Agile? Sobre los orígenes de la Ingeniería del Software

23 Junio 2020 Por JUAN MANUEL VARA MESA

Desde hace unos años, el término Agile es, sin lugar a dudas, el más utilizado en el contexto de la dirección y gestión de proyectos software.

 El número de certificaciones y de profesionales certificados aumenta constantemente y las metodologías ágiles han calado incluso en contextos tan poco propensos a los cambios como la administración. Pero, ¿cómo eran las cosas antes de la llegada de la agilidad al mundo del desarrollo software?

A finales de los 60, las drásticas mejoras que experimentó el hardware marcaron el comienzo de lo que se ha dado en denominar la Crisis del Software. Paradójicamente, aquellas mejoras provocaron que el software que esas máquinas eran capaces de ejecutar comenzara a ser cada vez más complejo. Al mismo tiempo, al aumentar la funcionalidad que podían entregar, aquellos primeros ordenadores comenzaron a utilizarse con mayor asiduidad, para cada vez más tareas. Como resultado, la demanda de software creció exponencialmente en muy poco tiempo.

No existía, sin embargo, un cuerpo de conocimiento que permitiese afrontar con garantías el reto que suponía ese aumento de la demanda. Dicho de otro modo, no existían técnicas o buenas prácticas que permitiesen abordar el desarrollo de software con ciertas garantías. Todo ello desembocó en el nacimiento de la Ingeniería del Software, como un intento de proporcionar una aproximación más sistemática para abordar el desarrollo de software. Más concretamente, la que muchos identifican como la primera conferencia sobre Ingeniería de Software, se celebró en Munich, en 1968. Como muchos de los avances en la definición de marcos normativos para el desarrollo del software, esta conferencia, financiada por la OTAN, tuvo su origen en una organización gubernamental relacionada con la defensa. No en vano la administración en general, y el ejercito en particular, han sido históricamente los clientes más importantes de los proveedores de software. Inspirados por otras ingenierías, el objetivo compartido por la mayoría de los asistentes a aquella conferencia, y la tendencia durante muchos años, pasaba por definir aproximaciones lo más “ingenieriles” posibles al desarrollo de software. Así, durante muchos años la gestión de proyectos software se ha dedicado a adaptar las prácticas propias de otras disciplinas, caracterizadas eminentemente por el uso de métodos predictivos.

En esta línea, se optaba por dividir los proyectos en fases casi independientes, que se encadenaban linealmente, de forma que cada fase predecía lo que pasaría en la siguiente. Por ejemplo, la fase de diseño tenía por objetivo producir un conjunto de planos detallados que en teoría producirían el resultado esperado cuando fueran implementados por los programadores. Este era otro rasgo característico de esta forma de abordar el desarrollo de software (que se extiende hasta nuestros días): la definición de roles claros y diferenciados para las distintas fases del desarrollo: analistas, arquitectos, programadores, testers, etc. Cada fase producía un entregable (por ejemplo la ERS) que era la entrada para la siguiente, de modo que no se iniciaba una hasta que se completaba la anterior.

En este escenario tan procedimental, UML devino en una especie de lengua franca y se convirtió en la herramienta por excelencia para la elaboración de esos planos del software que los programadores tan sólo debían traducir a código. Del mismo modo que los profesionales de la construcción se limitan a implementar los planos elaborados por arquitectos y delineantes. Los programadores se concebían como operarios de una línea de montaje, cuya productividad se correspondía con el número de líneas de código que eran capaces de escribir.

El famoso y denostado waterfall (cuyo creador apostaba curiosamente por todo lo contrario) es probablemente el mayor exponente de esta forma de abordar el desarrollo de software: fases estancas que se suceden en el tiempo. El no menos popular proceso unificado mejoraba esta forma de gestionar proyectos, proponiendo un proceso iterativo e incremental que muchos erróneamente asocian exclusivamente a las metodologías ágiles.

Classical misconceptions” en #ProjectManagement: Royce, creador del denostado cascada, apostaba por una aproximación bastante más ágil. Por contra, el desarrollo iterativo e incremental no nació con las metodologías ágiles. @jmvara Clic para tuitear

Otra de las herencias de aquella época es CMMI, resultado de una iniciativa financiada por el Departamento de Defensa de los EEUU (de nuevo una entidad gubernamental relacionada con la defensa). Cansados de los problemas en forma de proyectos retrasados o con sobrecostes que tenían con sus proveedores de software, recurrieron al Software Engineering Institute (SEI) de la Universidad Carnegie Mellon. El SEI pilotó un proyecto cuyo objetivo fue definir un modelo que permitiese evaluar a los proveedores de software para, de algún modo, asegurar la calidad del software que producían. La idea subyacente era que si las organizaciones habían institucionalizado procesos maduros y controlados, el software que producirían sería de calidad. Durante años, la mayor parte de las licitaciones de software han includo en sus pliegos la necesidad de que los proveedores contasen con una certificación CMMI para optar participar en esos concursos. No en vano, MÉTRICA, una metodología en la línea de las anteriores, ha sido el marco de referencia para el desarrollo de software en la administración española durante muchos años (y de hecho lo sigue siendo en algunos casos).

Sin embargo, a pesar de todos estos esfuerzos, avances, marcos normativos y propuestas metodológicas, los problemas han seguido sucediéndose y la gestión de proyectos, o al menos esa aproximación a la gestión de proyectos, puede considerarse como una disciplina fallida, como vienen ilustrando año tras año los diferentes informes sobre el estado de la cuestión, donde el porcentaje de proyectos que no cumplen sus objetivos, ya sea en términos de tiempo, duración o funcionalidad, siempre ha alcanzado valores muy alejados de los deseables. 

Es finalmente en este contexto donde a comienzos del año 2000, 17 reconocidos profesionales se juntaron en una estación de esquí en Utah, para dar a luz al Manifiesto Ágil, 4 reglas y 12 principios que han revolucionado el mundo de la gestión de proyectos, incluso más allá del software. Pero eso es otra historia…

Si la que hemos contado en este post os ha parecido interesante, os animamos a consultar la oferta formativa de URJConline y en particular el plan de estudios de nuestro Máster en Ingeniería de Sistemas de Información, donde hablamos sobre estos y otros temas relacionados con la gestión de proyectos y la gestión de la información en la sociedad actual.

Ampliación Edif. Rectorado
Campus de Móstoles
Calle Tulipán s/n.
28933 Móstoles. Madrid

cied@urjc.es

Recibe inspiración