Crisis del Software INTEGRANTES: ANA SILVIA ANDRADE SANCHEZ ANA SILVIA ANDRADE SANCHEZ FABIOLA JACINTO CASTILLIO FABIOLA JACINTO CASTILLIO LIZBETH SARAI ORNELAS LOPEZ LIZBETH SARAI ORNELAS LOPEZ TECNOLOGICO DE ESTUDIOS SUPERIORES DE HUIXQUILUCAN FUNDAMENTOS DE DESARROLLO DE SISTEMAS

HISTORIA El reconocimiento oficial de la crisis se llevó a cabo en una conferencia internacional en Garmisch (Alemania), en octubre de 1968, patrocinada por la OTAN (Organización del Tratado del Atlántico Norte) 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. Uno de los algoritmos de búsqueda más eficiente que existe en la estructura de datos es la búsqueda binaria, las características para poder implementar este algoritmo son las siguientes: Uno de los algoritmos de búsqueda más eficiente que existe en la estructura de datos es la búsqueda binaria, las características para poder implementar este algoritmo son las siguientes:  Los datos deben estar contenido en un estructura de datos tipo vector  Los datos del vector deben estar ordenados  Los datos del vector deben estar ordenados

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.

 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. SINTOMAS

 Algunos “ SINTOMAS” que indican que el software se encuentra en un periodo de crisis son: Baja Calidad del Software. Baja Calidad del Software. Tiempo y Presupuesto Excedido. Tiempo y Presupuesto Excedido. Confiabilidad Cuestionable. Confiabilidad Cuestionable. Altos Requerimientos de Personal para desarrollo y mantenimiento. Altos Requerimientos de Personal para desarrollo y mantenimiento.

 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. Aumento del poder computacional. Reducción del costo del hardware. Rápida obsolescencia de hardware y software. Rápida obsolescencia de hardware y software. FACTORES DE INFLUENCIA

--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.

POSIBLES CAUSAS DE LA CRISIS DEL SOFTWARE Hay varias razones que pueden ser propuestas como causa de la crisis. 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 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.

-- Se retrasa la detección de problemas críticos --Idealista pensar en identificar correctamente todos los requerimientos al principio --No permite implementaciones parciales --Usuario sólo involucrado al principio y al final -- Se retrasa la detección de problemas críticos --Idealista pensar en identificar correctamente todos los requerimientos al principio --No permite implementaciones parciales --Usuario sólo involucrado al principio y al final Problemas con el modelo en cascada de Royce: