Crisis del Software

El término crisis del software se usó desde finales de 1960 hasta mediados de 1980 para describir los frecuentes problemas que aparecían durante el proceso de desarrollo de nuevo software. Tras la aparición de nuevo hardware basado en circuitos integrados, comenzaron a desarrollarse sistemas y aplicaciones mucho más complejos que hasta entonces no era posible construir puesto que el hardware disponible no lo permitía. Estos nuevos proyectos de desarrollo de software, en la mayoría de ocasiones, no se terminaban a tiempo, lo cual también provocaba que el presupuesto final del software excediera de aquel que se había pactado. Algunos de estos proyectos eran tan críticos (sistemas de control de aeropuertos, equipos para medicina, etc) que sus implicaciones iban más allá de las pérdidas millonarias que causaban. Además, en muchos casos el software no daba respuesta a las verdaderas necesidades del cliente o había que ser un usuario experto para poder utilizarlo, todo ello sumado a que el mantenimiento de los productos era complejo y muy costoso.

El software no se producía como el hardware, que tenía un proceso de fabricación definido y dividido en fases. El resultado eran productos de pésima calidad en los que se habían invertido mucho tiempo y dinero pero que o bien no llegaban a terminarse o bien a la larga no daban el resultado que se esperaba. Se detectó que los métodos de desarrollo de software informales que hasta entonces habían bastado para proyectos pequeños no eran suficientes para los nuevos y grandes proyectos, y que se necesitaban profesionales especializados en esta nueva disciplina que fueran capaces de lidiar con la creciente complejidad de los nuevos sistemas.

Una de las primeras y más conocidas referencias a los conceptos crisis el software e ingeniería del software fue hecha por Edsger Dijkstra, durante la presentación de 1972 titulada “The Humble Programmer” en la Association for Computing Machinery, cuando se le hizo entrega de un Premio Turing.

Durante décadas, resolver la crisis del software desencadenó en que compañías e investigadores produjeran más y más herramientas software. Cada nueva tecnología o práctica que apareció entre 1970 y 1990 fue tratada como una “bala de plata” (en inglés, silver bullet) que solucionaría la crisis del software.

En 1986, Fred Brooks publicó el artículo No Silver Bullet, argumentando que ninguna tecnología o práctica por sí misma podría mejorar en un diez por ciento la productividad en los siguientes diez años. El debate sobre las balas de plata continuó durante la siguiente década, dando lugar a numerosas interpretaciones sobre el artículo de Brooks.

Los defensores de lenguajes como Ada, o de los procesos software continuaron apostando por que su tecnología sería la que solucionaría la crisis. Sin embargo, hubo gente que interpretó el hecho de que no se encontrara una solución única y efectiva al cien por cien como un fracaso de la ingeniería del software.

Si bien es cierto que la búsqueda de una única solución no funcionó, también había que ser consciente de que tampoco existían balas de plata en ninguna otra profesión. Así, con el transcurso de los años, casi todo el mundo aceptó que no se encontraría ninguna bala de plata, pero se tomó esto como una prueba de que la ingeniería del software finalmente había madurado y que los proyectos debían tener éxito gracias al trabajo duro y al esfuerzo. El campo de la ingeniería del software es demasiado complejo y diverso para que una única solución resuelva todos los problemas, pero el conjunto de todas las prácticas que surgieron y de las que surgen hoy en día son las que, bien aplicadas, permiten que la ingeniería del software desarrolle productos de calidad.