En 1968 la construcción de software era una actividad caótica. Hasta finales de los 60s, el software se desarrollaba de forma “doméstica” o artesanal. Era habitual que el único usuario del software fuese el propio programador. El programador (artesano) trabajaba individualmente construyendo el software estrechamente ligado al hardware. Tampoco disponía de las poderosas herramientas con las que hoy en día contamos para el desarrollo de software, sus únicas herramientas eran un manual de programación habitualmente ofrecido por el propio fabricante del hardware y su ingenio. Cuando el software comenzó a ser utilizado por muchos usuarios y a ser ejecutado en cientos de máquinas, el software pasó a ser considerado un “producto”. El software, debido a su creciente complejidad, ya no podía ser desarrollado por un único programador sino que eran requeridos equipos multidisciplinares. Los artesanos de finales de los 60 no estaban preparados para generar un “producto software” de calidad. Los sobrecostes, los incumplimientos de plazos, el software ineficiente y de baja calidad, requisitos no satisfechos, eran habituales en el sector. Todo ello terminó por desembocar en la ”crisis del software”. Era imprescindible establecer procesos de ingeniería para el desarrollo de software.

En octubre de 1968 tuvo lugar una conferencia sobre desarrollo de software en Múnich (Garbisch) financiada por la OTAN. Allí fue donde se adoptó el término, hasta entonces prácticamente desconocido, de “ingeniería de software”.

La conferencia estudió la aplicación de las técnicas de ingeniería al desarrollo de software. La ingeniería del software pretendía ofrecer a las empresas de desarrollo de software la ventaja de la “repetitividad”: El producto es consecuencia del proceso, no de las personas. Aplicar un mismo proceso logra un mismo producto. Además, la monitorización y permanente revisión de los procesos de construcción permite mejorarlos. Para todo ello se pautó el desarrollo en fases. Cada fase no debe iniciarse sin haber terminado la anterior. Además, cada fase es desarrollada por un equipo de especialistas. 

A partir de la conferencia, la construcción de productos software pasó a sustentarse en la gestión de proyectos en base a planificaciones detalladas y en procesos de construcción estandarizados. Como consecuencia la industria propuso las “Fabricas de Software”. Los arquitectos diseñan los “planos” del software y los programadores, asumiendo el rol de operarios u obreros, se limitan a codificarlos. 

Todo ello desembocó a mediados de los 90 en el Proceso Unificado. El Proceso Unificado es un marco de desarrollo de software que se caracteriza por estar dirigido por casos de uso, centrado en la arquitectura y por ser iterativo e incremental. Prescribe una gran cantidad de roles, actividades y artefactos para la construcción de productos software.

Paralelamente surgen sistemas de evaluación, por ejemplo, CMMI, para medir la calidad del proceso usado en función de la cantidad de actividades, roles y artefactos generados. 

Pronto afloraron inconvenientes en los modelos planteados. Esta visión basada en la “predictibilidad” del proceso de construcción de software tenia graves problemas intrínsecos. Algunos ingenieros críticos señalaron estos problemas.

Fred Brooks, en su libro “El Mítico Hombre-Mes”, introdujo en 1975 algunos anti patrones de la industria como la equivocada creencia de que al aumentar el número de personas trabajando en un proyecto se logrará acortar los plazos. También explicó conceptos fundamentales como la complejidad “esencial” y la complejidad “accidental” del código.

Desde la publicación del manifiesto ágil en 2001, las metodologías ágiles han vivido una rápida y exponencial implantación en la industria. 

Los ingenieros de software han pasado a centrarse en la entrega iterativa y temprana de producto con valor funcional. Poco a poco se han eliminado los silos de conocimiento prescritos por las metodologías predictivas. Los equipos de analistas, de arquitectos, de codificadores, de testers, de operaciones han sido sustituidos por un único equipo de desarrollo plenamente autónomo y multidisciplinar cuyos integrantes suman todas las competencias necesarias para construir un producto con éxito. 

Asimismo, la industria ha sido capaz de dotarse de cada vez más potentes herramientas capaces de automatizar muchas de las tareas definidas por los modelos de desarrollo. La automatización logra la sistematización y estandarización del proceso de desarrollo de software. La automatización era la principal meta de la visión predictiva. La visión predictiva llegó a definir y clasificar las herramientas de automatización, denominadas CASE. Sin embargo, los ingenieros de los 70 y 80 no fueron capaces de prever las tareas que en el siglo XXI serían automatizadas: Integración Continua, propuesta por Martin Fowler en el 2000; contenedores de dependencias, propuestos por Martin Fowler en el 2004; Git, propuesto por Linus Torvald en 2007; Contenedores de aplicaciones en 2013; etc.

La industria está cada vez más entregada a la búsqueda de la excelencia en el código, a las buenas prácticas, al testing automatizado y a la entrega continua y temprana de producto con valor. Por ejemplo: Microsoft utiliza metodologías adaptativas a la hora de construir sus productos, Spotify concibió una nueva forma de escalar scrum en las grandes organizaciones con el “Modelo Spotify”, Netflix revolucionó la industria al adoptar exitosamente una arquitectura orientada a microservicios e implantar novedosas estrategias para evitar la degradación del servicio como su “Ejército de Simios”