Ciclo de vida clásico.

El ciclo de vida clásico es el paradigma más antiguo y más ampliamente

usado en la ingeniería del software. Entre los problemas que se presentan en este paradigma se
encuentran: 1. Los proyectos reales raramente siguen el flujo secuencial que propone el modelo.
Siempre hay iteraciones y se crean problemas en la aplicación del paradigma. 2. Normalmente es
difícil para el cliente establecer explícitamente al principio todos los requisitos. El ciclo de vida
clásico lo requiere y tiene dificultades para acomodar posibles incertidumbres que pueden existir
al comienzo de muchos proyectos. 3. El cliente debe tener paciencia. Hasta llegar a las etapas
finales del desarrollo del proyecto, no estará disponible una versión operativa del programa. Un
error importante no detectado hasta que el programa esté funcionando puede ser desastroso.

CICLO DE VIDA SEMIESTRUCTURADO:

La secuencia ascendente de CODIFICACIÓN, la PRUEBA DE MÓDULOS y PRUEBA DEL SISTEMA se

reemplazan por una IMPLANTACIÓN DESCENDENTE, enfoque en el cual se codifican y prueban
primero los módulos de alto nivel, seguidos por los de bajo nivel, mas detallados. Se reemplaza el
diseño clásico por el DISEÑO ESTRUCTURADO. La IMPLANTACIÓN DESCENDENTE significa que se
ejecutan paralelamente parte de la CODIFICACIÓN y de las PRUEBAS. Puede darse una
retroalimentación entre la CODIFICACIÓN, la PRUEBA y la eliminación de fallas.

CICLO DE VIDA ESTRUCTURADO:

Los Terminadores son los Usuarios, los Administradores y el personal de Operaciones.

Proporcionan las entradas al equipo de Proyecto, y son los beneficiados finales del sistema.
Interactúan con las 9 actividades del Ciclo de Vida Estructurado. Actividad 1: La encuesta Empieza
cuando el usuario solicita que una o más partes de su sistema se automaticen. Objetivos:
Identificar los usuarios iniciales (entrevistar). Posiblemente, desarrollar un Diagrama de Contexto
inicial. Identificar las deficiencias actuales. Establecer metas y objetivos para un nuevo sistema.
Determinar si es factible automatizar el sistema, y de ser así, sugerir escenarios (estimar). Preparar
el esquema que se usará para guiar el resto del Proyecto. Actividad 2: El análisis de sistemas
Objetivo: Transformar las dos entradas principales: las políticas del Usuario y el esquema del
Proyecto, en una ESPECIFICACIÓN ESTRUCTURADA. Implica modelar el ambiente de Usuario.
Modelo Esencial: ---Modelo Ambiental ---Declaración de Propósitos ---Diagrama de Contexto ---
Lista de Acontecimientos (de Flujo, de control, Temporales) ---Diccionario de Datos ---Modelo de
Entidad Relación Modelo de Comportamiento ---DFD por niveles ---Diagrama ER (DER) ---DTE
(Diagrama de Transición de Estados - Sistema de Tiempo Real) ---Especificaciones, Diccionarios ---
Frontera de automatización. Actividad 3: El diseño Asigna el Modelo Esencial a procesadores
adecuados (máquinas o humanos). Para cada tarea se crea una jerarquía de módulos de programas
e interfases para implantar las especificaciones de la etapa de ANÁLISIS. Además se transforman
los Modelos Entidad - Relación en un Diseño de Base de Datos. Implica el desarrollo de: Modelo
de Implantación del Usuario: describe la especificación de la frontera humano - máquina (separa
las partes del Modelo Esencial que llevará a cabo una persona, de las partes que se implantarán en
una o más computadoras) y de la interfaz hombre - máquina (describe el formato y las secuencias
de entradas que los Usuarios proporcionan a la computadora, además del formato y la secuencia
de salida). Modelo de Implantación de Sistemas ---Modelo del Procesador (se asignan los procesos
y almacenes a los procesadores) ---Modelo de Tareas (se asignan los procesadores a las tareas) ---
Modelo de Implantación de Programas - Diagrama de Estructura (DE) (Jerarquía de Módulos
dentro de una Tarea). Actividad 4: Implantación Incluye la Codificación y la Integración de Módulos
en un esqueleto progresivamente más completo del Sistema final. Actividad 5: Generación de
pruebas de aceptación Se realiza desde el punto de vista del Usuario, es decir, desde la
Especificación Estructurada. Actividad 6: Garantía de calidad Se aplican las Pruebas de Aceptación
generadas en la etapa anterior al nuevo sistema. Actividad 7: Descripción del procedimiento
Implica la producción de Manuales de Usuario. Actividad 8: Conversión de bases de datos En
general esta actividad requiere como entrada la base de datos actual del usuario. Actividad 9:
Instalación Las entradas para la Instalación son: los Manuales de Usuario (Actividad 7: Descripción
de Procedimientos), la Base de Datos convertida (Actividad 8: Conversión de la Base de Datos), y el
Sistema aceptado producido por la Actividad 6 (Control de Calidad). En algunos casos sólo significa
un cambio de la noche a la mañana al nuevo Sistema; en otros, puede ser un proceso gradual, en
el que un grupo tras otro de Usuarios van recibiendo Manuales y entrenamiento y comenzando a
usar el nuevo Sistema.

PROTOTIPO: Es una versión operativa preliminar (un modelo piloto) del Sistema de Información
que se emplea con fines de demostración y evaluación. Tiene las características esenciales pero no
todos los detalles necesarios en la interfase con el usuario ni tampoco un desempeño eficiente.
Etapas en la construcción de Prototipos: Etapa 1. Identificar los requerimientos básicos del usuario:
El diseñador del sistema trabaja con el usuario sólo lo suficiente para obtener sus necesidades
básicas de información. Etapa 2. Desarrollo de un prototipo inicial: El diseñador del sistema crea
rápidamente un Prototipo operativo, usando las herramientas de software de 4º generación, las
que aceleran el desarrollo de aplicaciones. El prototipo sólo puede llevar a cabo las funciones más
importantes del sistema propuesto, o puede ser todo el sistema con un archivo restringido. Etapa
3. Uso del prototipo: Se estimula al usuario a que trabaje con el sistema con el objeto de
determinar qué tan bien satisface sus necesidades y para hacer recomendaciones para mejorarlo.
Etapa 4. Revisión y mejora del prototipo: Quien desarrolla el sistema anota todos los cambios
solicitados por el usuario y afina el Prototipo de acuerdo con ellos. Luego de que el Prototipo ha
sido revisado, el ciclo regresa a las etapas 3 y 4 en las que el analista de sistemas junto con el
usuario evalúan los resultados con la finalidad de identificar deficiencias, características faltantes y
realizar los ajustes necesarios. Estas etapas se repiten hasta que el usuario queda satisfecho
(DESARROLLO ITERATIVO). Cuando ya no se requieren iteraciones, el Prototipo aprobado se
transforma en un Prototipo operativo que proporciona las especificaciones finales para la
aplicación y se opta por una de las siguientes opciones: El Prototipo se convierte en la versión
definitiva del sistema deseado. Algo no deseado ya que generalmente el Prototipo no puede
trabajar eficientemente con grandes volúmenes de transacciones, y porque carece de detalles
operacionales tales como recuperación de errores, auditorias, documentación para el Usuario, etc.
Además si no queda registrada la información de los requerimientos se dificulta el posterior
Mantenimiento. Se utiliza la información obtenida con el Prototipo operativo para comenzar el
desarrollo detallado de un nuevo sistema (es como si reemplazara el Análisis Estructurado). Se
emprende el desarrollo de un nuevo Prototipo. Se toma la decisión de abandonar el sistema en su
totalidad.