Crisis del Software:

Se fundamentó en el tiempo de creación de software, ya que en la creación del mismo no se obtenían los resultados deseados, además de un gran costo y poca flexibilidad.

Básicamente, la crisis del software se refiere a la dificultad en escribir programas libres de defectos, fácilmente comprensibles, y que sean verificables. Las causas son, entre otras, la complejidad que supone la tarea de programar, y los cambios a los que se tiene que ver sometido un programa para ser continuamente adaptado a las necesidades de los usuarios.

Ciclos de Vida del Software:

Describe el desarrollo de software, desde la fase inicial hasta la fase final. El propósito de este programa es definir las distintas fases intermedias que se requieren para validar el desarrollo de la aplicación, es decir, para garantizar que el software cumpla los requisitos para la aplicación y verificación de los procedimientos de desarrollo: se asegura de que los métodos utilizados son apropiados.

El ciclo de vida básico de un software consta de los siguientes procedimientos:

• Definición de objetivos: definir el resultado del proyecto y su papel en la estrategia global.
• Análisis de los requisitos y su viabilidad: recopilar, examinar y formular los requisitos del cliente y examinar cualquier restricción que se pueda aplicar.
• Diseño general: requisitos generales de la arquitectura de la aplicación.
• Diseño en detalle: definición precisa de cada subconjunto de la aplicación.
• Programación (programación e Implementación): es la Implementación de un lenguaje de programación para crear las funciones definidas durante la etapa de diseño.
• Prueba de unidad: prueba individual de cada subconjunto de la aplicación para garantizar que se implementaron de acuerdo con las especificaciones.
• Integración: para garantizar que los diferentes módulos se integren con la aplicación. Éste es el propósito de la prueba de integración que está cuidadosamente documentada.
• Prueba beta (o validación), para garantizar que el software cumple con las especificaciones originales.
• Documentación: sirve para documentar información necesaria para los usuarios del software y para desarrollos futuros.
• Implementación
• Mantenimiento: para todos los procedimientos correctivos (mantenimiento correctivo) y las actualizaciones secundarias del software (mantenimiento continuo).

El orden y la presencia de cada uno de estos procedimientos en el ciclo de vida de una aplicación dependen del tipo de modelo de ciclo de vida acordado entre el cliente y el equipo de desarrolladores.

Modelo en cascada:

El modelo de ciclo de vida en cascada comenzó a diseñarse en 1966 y se terminó alrededor de 1970. Se define como una secuencia de fases en la que al final de cada una de ellas se reúne la documentación para garantizar que cumple las especificaciones y los requisitos antes de pasar a la fase siguiente:

Ventajas del modelo cascada:

1. Modelo y planificación fácil y sencillos.

2. Sus fases son conocidas por los desarrolladores.

3. Los usuarios lo pueden comprender fácilmente.

Desventajas del modelo cascada:

1. Alto riesgo en sistemas nuevos debido a problemas en las especificaciones y en el diseño.

2. Bajo riesgo para desarrollos bien comprendidos utilizando tecnología conocida.

Modelo Espiral:

Este es un modelo de proceso de software evolutivo, el cual enlaza la naturaleza iterativa de la construcción de prototipos, pero conservado aquellas propiedades del modelo en cascada.

El modelo en espiral fue desarrollado por Boehm, quien lo describe así:

El modelo de desarrollo en espiral es un generador de modelo de proceso guiado por el riesgo que se emplea para conducir sistemas intensivos de ingeniería de software concurrente y a la vez con muchos usuarios.

Se caracteriza principalmente por:

• Un enfoque cíclico para el crecimiento incremental del grado de definición e implementación de un sistema, mientras que disminuye su grado de riesgo.
• Un conjunto de puntos de fijación para asegurar el compromiso del usuario con soluciones de sistema que sean factibles y mutuamente satisfactorias.

El modelo espiral captura algunos principios básicos:

•  Decidir qué problema se quiere resolver antes de viajar a resolverlo.
•  Examinar tus múltiples alternativas de acción y elegir una de las más convenientes.
•  Evaluar qué tienes hecho y qué tienes que haber aprendido después de hacer algo.
•  No ser tan ingenuo para pensar que el sistema que estás construyendo será "EL" sistema que el cliente necesita, y
• Conocer (comprender) los niveles de riesgo, que tendrás que tolerar.

El modelo espiral no es una alternativa del modelo cascada, ellos son completamente compatibles.