El ciclo de vida básico de un software.

 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.

Modelos de ciclo de vidA

Para facilitar una metodología común entre el cliente y la compañía de software, los modelos de ciclo de vida se han actualizado para reflejar las etapas de desarrollo involucradas y la documentación requerida, de manera que cada etapa se valide antes de continuar con la siguiente etapa. Al final de cada etapa se arreglan las revisiones de manera que (texto faltante).

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

 El primer ciclo de vida del software, "Cascada", fue definido por Winston Royce a fines del 70.

Desde 10 a 15 años atrás, este modelo fue sujeto a críticas, por ser restrictivo y rígido.

 Se ocupa en describir las fases principales del desarrollo de software, ayudando a administrar el progreso y desarrollo, además de proveer un espacio de trabajo detallado de la elaboración del software.

 Este es el más básico de todos los modelos. su visión  dice que el desarrollo de software esa través de una secuencia simple de fases. Cada fase tiene un conjunto de metas bien definidas. Utiliza punto de control para pasar a la siguiente fase: Análisis, Diseño, Codificación, Pruebas, Implementación, Mantenimiento. Se tarda mucho tiempo en pasar todo el ciclo. El fracaso del software es la comunicación con el usuario final. Se utiliza en proyectos con requerimientos bien definidos. Las flechas muestran el flujo de información entre las fases. 

este modelo se enfrasca en los en: Planear un proyecto antes de embarcarse en él. Definir el comportamiento externo antes de diseñar su arquitectura interna. Documentar los resultados de cada actividad. Diseñar un sistema antes de codificarlo. Testear el sistema después de construirlo

Modelo V

El modelo de ciclo de vida V proviene del principio que establece que los procedimientos utilizados para probar si la aplicación cumple las especificaciones ya deben haberse creado en la fase de diseño.

 Otros modelos de Ciclo de Vida de Software.

Modelo De Desarrollo Incremental.

Existen riesgos en el desarrollo de sistemas largos y complejos. La forma de reducir los riesgos es construir una parte del sistema.

 Un sistema pequeño es siempre menos riesgoso que construir un sistema grande.es más fácil determinar si los requerimientos para los niveles subsiguientes son correctos.

Reduciendo el tiempo de desarrollo de un sistema decrecen las probabilidades que esos requerimientos de usuarios puedan cambiar durante el desarrollo. Los errores de desarrollo realizados en un incremento, pueden ser arreglados antes del comienzo del próximo incremento.

Modelo De Desarrollo Evolutivo

 El modelo de desarrollo evolutivo construye versiones sucesivas de un producto, el modelo evolutivo asume que los requerimientos no son completamente conocidos al inicio del proyecto.

Basada en esta retroalimentación, la especificación de requerimientos es actualizada. El desarrollo de software en forma evolutiva requiere un especial cuidado en la manipulación de documentos, programas, datos de test, etc. desarrollados para distintas versiones del software.

Modelo de Prototipado de Requerimientos.

 El prototipado de requerimientos es la creación de una implementación parcial de un sistema, para el propósito explícito de aprender sobre los requerimientos del sistema. Un prototipo es construido de una manera rápida tal como sea posible.

Modelo Espiral.

Basada en la necesidad continúa de refinar los requerimientos y estimaciones del proyecto. Efectivo para proyectos pequeños donde con la retroalimentación dada por el cliente, se aprueba las diferentes etapas, puede ocurrir el riesgo que no se defina bien los objetivos por el cual el desarrollo puede ser caótico.