Crisis del Software Historia Síntomas Factores de Influencia Posibles Causas Historia El término “crisis del software” se acuñó en 1968, en la primera conferencia organizada por la OTAN sobre desarrollo de software y con él se etiquetaron los problemas que surgían en el desarrollo de sistemas de software. En la misma conferencia se utilizó por primera vez el término "ingeniería del software" para describir el conjunto de conocimientos que existían en aquel estado inicial. Algunas referencias útiles para comprender cuáles eran los conocimientos estables para el desarrollo de software en 1968 son: En 1962 se publicó el primer algoritmo para búsquedas binarias. C.Böhm y G. Jacopini publicaron en 1966 el documento que creaba una fundación para la eliminación de "GoTo" y la creación de la programación estructurada. En 1968 los programadores se debatían entre el uso de la sentencia GoTo, y la nueva idea de programación estructurada; ese era el caldo de cultivo en el que Edsger Dijkstra escribió su famosa carta "GoTo Statement Considered Harmful" en 1968. La primera publicación sobre programación estructurada no vio la luz hasta 1974, publicada por Larry Constantine, Glenford Myers y Wayne Stevens. El primer libro sobre métrica de software fue publicado en 1977 por Tom Gilb. El primer libro sobre análisis de requisitos apareció en 1979. El término fue usado para referirse a los rápidos incrementos de la tecnología en la computación y la complejidad de los problemas a los cuales pudieran enfrentarse. En efecto, se refiere a la dificultad de escribir correcta, entendible y verificablemente los lenguajes de programación. Las raíces de la crisis del software son complejas y variables. Uno de los principales problemas en el desarrollo de software de hoy, es que muchos proyectos empiezan la programación tan pronto se definen y concentran mucho de su esfuerzo en la escritura de código. Últimamente el desarrollo de software se a ralentizado. El estudio de este fenómeno es importante porque la existencia de software científico libre facilita que cualquier laboratorio del mundo pueda desarrollar ciencia libre usando este software como herramienta de trabajo. Algunos “síntomas” que indican que el software se encuentra en un periodo de crisis son: Baja Calidad del Software. Tiempo y Presupuesto Excedido. Confiabilidad Cuestionable. Altos Requerimientos de Personal para desarrollo y mantenimiento. FACTORES DE INFLUENCIA Para poder llevar el estado del proceso de software como un estado de crisis, los críticos han destacado ciertas características que han permitido esta postura del software respecto a otras etapas de su corta historia. Algunos de esos factores son: Aumento del poder computacional. Reducción del costo del hardware. Rápida obsolescencia de hardware y software. Aceptación de la computarización en las empresas. Incremento en el número de usuarios de los sistemas de software. Tipo de usuario no homogéneo aun en sistemas hechos a la medida. Personal desarrollado y mantenimiento diferente. La magnitud del proyecto impacta en: Tiempo costo y número de desarrolladores Control administrativo y detalles técnicos Aumento en el conocimiento del problema. Cambios en el entorno: Tecnológicos (Internet, redes, ERP, CRM, SCM). Económicos (crisis económicas, globalización, etcétera). Sociales (nuevas necesidades, costumbres nuevas, etcétera). POSIBLES CAUSAS DE LA CRISIS DEL SOFTWARE Hay varias razones que pueden ser propuestas como causa de la crisis. No son mutuamente excluyentes; de hecho, es posible que la verdadera causa sea una mezcla de todas ellas. Sin embargo, todas tienen en común que son causadas por el método de valorar los avances científicos y el mecanismo actual de financiación de la actividad científica. Las causas de la crisis del software fueron vinculadas a la complejidad en general del proceso de software y a la relativa inmadurez de la ingeniería de software como una profesión. La crisis se manifestó a sí misma en varias maneras: Proyectos gestionados con un sobrepresupuesto. Proyectos gestionados con sobre tiempo. Software de baja calidad. El software a menudo no satisfacía los requerimientos deseados. Los proyectos fueron inmanejables, con un código difícil de mantener. La crisis del software fue dirigida por la implementación de varios procesos y metodologías, siendo la más notable el modelo de cascada de Royce.
