INGENIERIA EN SISTEMAS DE INFORMACION

Cátedra: Análisis de sistemas

Monografía : “CICLO DE VIDA: CLÁSICO O EN

CASCADA”

AUTORES:
CASANOVA, CARLOS
GUIFFREY, CLAUDIO
ROSENBERG, SEBASTIAN
MOSNA, ALEJANDRO

2007
Ciclo de vida del software

Un Ciclo de Vida son todos estados por los que pasa el

producto (en nuestro caso un sistema de software) desde
que nace hasta que muere, es el proceso que describe que
hacer en cada fase del desarrollo de un proyecto. Las fases
del ciclo de vida, representan períodos distintos y sucesivos
con entradas y criterios de salida.

El desarrollo de cualquier sistema de software, incluso el de

sistemas triviales, es una actividad estructurada. Se dan
varios pasos, desde que el sistema es diseñado y
programado hasta que es validado. A esta secuencia de
actividades, incluyendo sus entradas y salidas, es a lo que
se denomina proceso de software, desarrollo de software, y
en su conjunto, y a veces indistinguiblemente, el ciclo de
vida del software. Cada organización sigue su propio
proceso de software, pero estos métodos particulares
suelen seguir a procesos de software mas abstractos y
generales: los modelos de desarrollo de software. Un
modelo de desarrollo de software es una representación
abstracta de las actividades y documentos a realizar en el
desarrollo de software. Dependiendo del nivel de detalle, el
modelo puede también mostrar los papeles responsables de
estas actividades, las herramientas que se usan para
desarrollarlas, los tipos de comunicación entre las
actividades y los papeles y situaciones excepcionales a
considerar como parte de los procesos.
El desarrollo del software es una actividad muy compleja,
que demanda una gran actividad intelectual y puede exigir
gran creatividad a los participantes del mismo.

2
Modelos orientados hacia la especificación

Entre los años 50 y 60 el desarrollo del software fue un

proceso muy informal alejado de otras metodologías
seguidas en procesos de ingeniería. Usualmente se seguían
descripciones informales de las necesidades a programar.
Conforme se iban ampliando las necesidades de software
esta carencia de modelos y estructura fue haciéndose más
y más costosa. Basándose en otros procesos de ingeniería
las organizaciones fueron adoptando procesos de desarrollo
para el software mas estructurados. Así se definieron
actividades delimitadas de especificación, diseño y
desarrollo con tiempos intermedios de separación entre
ellas, en los cuales se suponían acabadas las actividades de
las etapas anteriores.
Es necesario aclarar que no hay un modelo de ciclo de vida
que sirva para todos los proyectos, el modelo por el que se
opte va a depender de distintos aspectos tales como:

– la cultura de la organización
– el deseo de asumir riesgos
– el área de aplicación
– la volatilidad de los requisitos
– la comprensión de los requisitos
– la experiencia previa

La primera discusión pública acerca de este “ciclo de vida”

del software se debe a Royce, en 1970. Hoy día se
denomina a este modelo de desarrollo: “Modelo clásico o
en Cascada”.

3
Se caracteriza principalmente por mantener un orden lineal
en las transiciones entre fases.
En una situación ideal, cada una de las fases podría
realizarse individualmente hasta su terminación y en
secuencia.
Otra característica importante es que el producto se conoce
al final y si no se ajusta a las necesidades del cliente, una ó
más fases se repiten, hasta que el sistema es correcto o
próximo a ello.

Asume que:

– Los requisitos se pueden conocer completamente y sin

ambigüedad al principio del proceso de desarrollo
– Los requisitos no varían
– Cada etapa implica una revisión
– No se pasa a la siguiente etapa hasta que se completa la
actual

Implica que:

– Los requisitos pueden quedarse obsoletos

– No hay un ejecutable que enseñar al usuario hasta el final
– 99% de recursos consumidos - errores irremediables

Este modelo consta de varias etapas:

4
1. Definición de requisitos: Se definen los servicios a
prestar y las restricciones a cumplir.

2. Diseño del software y del sistema: Se identifican los

subsistemas y la estructura global del sistema.
Dependiendo de la envergadura de la organización se
podría llegar a mayores detalles o a descripciones
abstractas. Se pueden seguir métodos de diseño
estructurado para el desarrollo del diseño del software.

3. Implementación y prueba de unidades: Se

desarrollan individualmente los módulos que conforman el
sistema en (uno o varios) lenguajes de programación
elegidos. Se prueban los módulos por separado.

4. Integración y prueba del sistema: Se integran y

prueban todos los módulos como un sistema completo.

5. Mantenimiento: Se instala y pone en funcionamiento el

sistema. Durante su tiempo de vida, el software será
modificado siguiendo los requisitos del usuario y reparando
los fallos que se van descubriendo.

Las Ventajas se ven cuando:

Poseemos:
• una Definición estable de Producto.
• Tecnologías conocidas.

5
 • Requisitos de calidad más importantes que el costo y
el calendario.
Nos permite Superar deficiencias técnicas:
- provee estructura
- beneficia a grupos dispersos

Desventajas:

• Rígido del comienzo al fin.

• Difícil para definir requerimientos desde el comienzo.
• Puede producir documentación excesiva.
• No hay signos concretos del resultado hasta el final

Entre las muchas variantes surgidas de este ya bien

asentado modelo están el modelo en V, que resuelve en
parte el problema de la simplicidad del modelo de cascada
que sólo muestra una salida por proceso y el hecho de que
esta salida
no puede ser reinsertada como parte de la entrada de
etapas anteriores.
Una modificación que permite la iteración en el modelo de
cascada se muestra en la imagen siguiente, es el modelo
iterativo en cascada:

En el cual, en caso de equivocaciones, se puede acceder a

cualquier etapa del ciclo sin que sea necesario recorrerlo
nuevamente.

6
BIBLIOGRAFIA:
• APUNTES DE LA CATEDRA

• Programación Modular. ETSIT. 1o C. Apuntes del

profesor Juan Falgueras. Curso 2005 del 21 de febrero
de 2005.

• CICLO DE VIDA Y PROCESO SOFTWARE.

Planificación y Gestión del Desarrollo de
Sistemas Informáticos
Curso 2000/2001
• Análisis Orientado a Objetos
Ingeniería del Software
M.C. José Martín Olguín Espinoza