Modelos Ciclo de Vida de los Sistemas.

1.1 Segmentación y modalidad
1.2 Criterios y elementos de conexión entre las partes

Ciclo de vida del software

“Una aproximación lógica a la adquisición, el suministro,
el desarrollo, la explotación y el mantenimiento del software”.

IEEE 1074

“Un marco de referencia que contiene los procesos, las actividades
y las tareas involucradas en el desarrollo, la explotación y el
mantenimiento de un producto de software, abarcando la vida del
sistema desde la definición de los requisitos hasta la finalización de
su uso”.

ISO 12207-1
De acuerdo a la definición anterior el ciclo de vida de un sistema es un enfoque por fases del análisis y diseño que sostiene que los sistemas sean desarrollados de mejor manera mediante el uso de un ciclo en especifico; determina el orden de las etapas involucradas y los criterios de transición asociadas entre estas etapas.
Jaime APV.

Lista de modelos

1.-Modelo en cascada
2.-Modelo incremental
3.-Modelo en espiral
4.-Prototipado
5.- Concurrente
6.- Modelo de Prototipado de Requerimientos
7.- Modelo De Desarrollo Evolutivo
8.- La reutilización en el Ciclo de Vida
9.- Síntesis automática de Software
10. Comparación de Ciclos de Vida
11. Modelos para desarrollo de sistemas Orientados a
Objetos.

Modelo en cascada

-Flujo secuencial entre las fases.
-Cada etapa tiene un input y un output.
-Se supone que para comenzar con una
etapa deben haber finalizado las
anteriores.

Contribuciones:
-El proceso debe ser disciplinado, planeado
y gerenciado
-La implementación debe posponerse hasta
que los objetivos se hayan comprendido


Ingeniería de requerimientos

-Identificar y documentar los requerimientos
exactos del sistema según las necesidades de
los usuarios finales.
-Cualidades del sistema.
-Funcionales, no−funcionales, del proceso y del
mantenimiento

Diseño- Especificación
-Dividir el sistema en partes y establecer las
relaciones entre ellas.
-Arquitectura y diseño detallado.
-Establecer qué hará exactamente cada parte.
-En esta fase se crea un modelo funcional−
estructural de los requerimientos.
-El diseño debe permitir implementaciones que
verifiquen los requerimientos.

Críticas:
-No refleja realmente el proceso de desarrollo del software
-Se tarda mucho tiempo en pasar por todo el ciclo
-Perpetua el fracaso de la industria del software en su
comunicación con el usuario final
-El mantenimiento se realiza en el código fuente
-Las revisiones de proyectos de gran complejidad son muy
difíciles
-Impone una estructura de gestión de proyectos

Modelo Espiral

El modelo espiral de los procesos software es un modelo del ciclo de meta-vida. En este modelo, el esfuerzo de desarrollo es iterativo. Tan pronto como uno completa un esfuerzo de desarrollo, otro comienza. Además, en cada desarrollo ejecutado, puedes seguir estos cuatros pasos:
-Determinar qué quieres lograr.
-Determinar las rutas alternativas que puedes tomar para lograr estas metas.
-Por cada una, analizar los riesgos y resultados finales, y seleccionar la mejor.
-Seguir la alternativa seleccionada en el paso 2.
-Establecer qué tienes terminado.

La dimensión radial en la figura refleja costos acumulativos incurridos en el proyecto.
Observemos un escenario particular. Digamos que en este proyecto, nosotros viajaremos a resolver un conjunto particular de problemas del cliente. Durante el primer viaje alrededor de la espiral, analizamos la situación y determinamos que los mayores riesgos son la interfaz del usuario. Después de un cuidadoso análisis de las formas alternativas de direccionar esto (por ejemplo, construir un sistema y esperar lo mejor, escribir una especificación de requerimientos y esperar que el cliente lo entienda, y construir un prototipo), determinamos que el mejor curso de acción es construir un prototipo.
Lo realizamos. Luego proveemos el prototipo al cliente quien nos provee con retroalimentación útil. Ahora, comenzamos el segundo viaje alrededor de la espiral. Este tiempo decidimos que el mayor riesgo es ese miedo a que muchos nuevos requerimientos comiencen a aparecer sólo después de que el sistema sea desplegado. Analicemos las rutas alternativas, y decidimos que la mejor aproximación es construir un incremento del sistema que satisfaga sólo los requerimientos mejor entendidos. Hagámoslo ya. Después del despliegue, el cliente nos provee de retroalimentación que dirá si estamos correctos con esos requerimientos, pero 50 nuevos requerimientos ahora se originarán en las cabezas de los clientes. Y el tercer viaje alrededor de la espiral comienza.
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 compatible.

Modelo Concurrente
Como el modelo espiral, el modelo concurrente provee una meta-descripción del proceso software. Mientras que la contribución primaria del modelo espiral es en realidad que esas actividades del software ocurran repetidamente, la contribución del modelo concurrente es su capacidad de describir las múltiples actividades del software ocurriendo simultáneamente.
Esto no sorprende a nadie que ha estado involucrado con las diversas actividades que ocurren en algún tiempo del proceso de desarrollo de software. Discutamos un poco tales casos:
Los requerimientos son usualmente "líneas de base", cuando una mayoría de los requerimientos comienzan a ser bien entendidos, en este tiempo se dedica un esfuerzo considerable al diseño. Sin embargo, una vez que comienza el diseño, cambios a los requerimientos son comunes y frecuentes (después de todo, los problemas reales cambian, y nuestro entendimiento de los problemas desarrollados también). Es desaconsejado detener el diseño en este camino cuando los requerimientos cambian; en su lugar, existe una necesidad de modificar y rehacer líneas de base de los requerimientos mientras progresa el diseño. Por supuesto, dependiendo del impacto de los cambios de los requerimientos el diseño puede no ser afectado, medianamente afectado o se requerirá comenzar todo de nuevo.
Durante el diseño de arquitectura, es posible que algunos componentes comiencen a ser bien definidos antes que la arquitectura completa sea estabilizada. En tales casos, puede ser posible comenzar el diseño detallado en esos componentes estables. Similarmente, durante el diseño detallado, puede ser posible proceder con la codificación y quizás regular testeando en forma unitaria o realizando testeo de integración previo a llevar a cabo el diseño detallado de todos los componentes.