INSTITUTO TECNOLOGICO SUPERIOR

AGUIRRE ABAD

DESARROLLO DE SOFWARE
CICLOS DE VIDA DEL DESARROLLO DE UN
SISTEMA TRADICIONAL Y ORIENTADO A
OBJETOS

NOMBRE:

Arnaldo Arguello

CURSO:

1° Vespertino

CATEDRÁTICO:

Ing. Hugo Vargas

CICLOS DE VIDA ORIENTADOS A OBJETOS Y TRADICIONALES

CICLOS DE VIDA TRADICIONALES

Los ciclos de vida que se orientan a objetos son parte importante dentro de cada modelo que se
desarrolla, éstos ayudan a tener una mejor perspectiva sobre la forma de trabajar y los objetivos
que se pueden alcanzar. Normalmente los ciclos de vida se basan en el análisis y diseño
estructurado, aunque los objetos tienen particularidad y se basan en componentes relacionados
entre sí, por medio de interfaces, también comprendidas como modulares, ofreciendo la
posibilidad de la división del trabajo en mini proyectos.

También podemos contar con ciclos de vida clásicos o tradicionales, los cuales se centran en el
proyecto, el desarrollo orientado a objetos el cual se estructura con el producto, éste no
comprende de procesos como funciones, sino que arma módulos basados en componentes, esto
permite una relación entre los elementos por medio de interfaces, por lo que son más modulares
y se dividen en mini proyectos como se ha mencionado anteriormente.

Ciclo de vida en cascada

Propuesto por Winston Royce en el año 1970. Es un ciclo de vida que admite iteraciones,
contrariamente a la creencia de que es un ciclo de vida secuencial como el lineal. Después de
cada etapa se realiza una o varias revisiones para comprobar si se puede pasar a la siguiente. Es
un modelo rígido, poco flexible, y con muchas restricciones.

Ciclo de vida incremental

Este modelo de ciclo de vida se basa en la filosofía de construir incrementando las
funcionalidades del programa.

Se realiza construyendo por módulos que cumplen las diferentes funciones del sistema. Esto
permite ir aumentando gradualmente las capacidades del software.

Este ciclo de vida facilita la tarea del desarrollo permitiendo a cada miembro del equipo
desarrollar un módulo particular en el caso de que el proyecto sea realizado por un equipo de
programadores.

Es una repetición del ciclo de vida en cascada, aplicándose este ciclo en cada funcionalidad del
programa a construir. Al final de cada ciclo le entregamos una versión al cliente que contiene
una nueva funcionalidad. Este ciclo de vida nos permite realizar una entrega al cliente antes de
terminar el proyecto.

Ciclo de vida por prototipos

El uso de programas prototipo no es exclusivo del ciclo de vida iterativo. En la práctica los
prototipos se utilizan para validar los requerimientos de los usuarios en cualquier ciclo de vida.

Si no se conoce exactamente cómo desarrollar un determinado producto o cuáles son las

especificaciones de forma precisa, suele recurrirse a definir especificaciones iniciales para hacer
un prototipo, o sea, un producto parcial y provisional. En este modelo, el objetivo es lograr un
producto intermedio, antes de realizar el producto final, para conocer mediante el prototipo cómo
responderán las funcionalidades previstas para el producto final.

Antes de adoptar este modelo de ciclo debemos evaluar si el esfuerzo por crear un prototipo vale
realmente la pena adoptarlo.

Este modelo nos permite suavizar la transición entre los requerimientos iniciales y finales que
surgen en la creación de un proyecto con grandes innovaciones

Ciclo de vida evolutivo

Este modelo acepta que los requerimientos del usuario pueden cambiar en cualquier momento.

La práctica nos demuestra que obtener todos los requerimientos al comienzo del proyecto es
extremadamente difícil, no sólo por la dificultad del usuario de transmitir su idea, sino porque
estos requerimientos evolucionan durante el desarrollo y de esta manera, surgen nuevos
requerimientos a cumplir. El modelo de ciclo de vi- da evolutivo afronta este problema mediante
una iteración de ciclos requerimientos–desarrollo–evaluación.
CICLOS DE VIDA ORIENTADOS A OBJETOS

Modelo Fuente

Fue creado por Henderson-Sellers y Edwards en 1990. Es un tipo de ciclo de vida pensado para
la orientación a objetos y posiblemente el más seguido.

Modelo de Agrupamiento

Propuesto por Bertrand Meyer (Meyer, 1990).

Concepto Clave: Agrupamiento, que es un conjunto de clases relacionadas con un objetivo

común.

Clúster: Unidad organizativa básica. Es un grupo de clases relacionadas o, recursivamente,

clústeres relacionados. El clúster es la unidad natural para el desarrollo por parte de un único
desarrollador.

 Evita el efecto todo nada propio del modelo en cascada.

 Tiene un componente secuencial y un componente concurrente.
 Existencia de diferentes subciclos de vida, que pueden solaparse en el tiempo.
 Se aplica al clúster no al sistema completo.

El mini ciclo de vida que gobierna el desarrollo de un clúster está formado por Especificación,
Diseño, Implementación, Verificación/Validación y Generalización.

Enfoque Ascendente.
La ocultación de la información posibilita la forma del modelo de clústeres de ingeniería
concurrente.

Modelo Remolino

Definido por James Rumbaugh. Las metodologías de desarrollo no ofrecen una visión real del
ciclo de vida en el desarrollo orientado al objeto. El ciclo de vida de un desarrollo orientado al
objeto es desordenado, involucrando múltiples iteraciones interrelacionadas.

El modelo en cascada asume una sola dimensión de iteración, consistentes en la fase de proceso.

Pueden Identificarse otras dimensiones:

 Amplitud: tamaño del desarrollo, por ejemplo, en número de elementos.

 Profundidad: referida al nivel de abstracción o detalle.
 Madurez: grado de complexión, corrección y elegancia.
 Alternativas: Diferentes soluciones a un problema.
 Alcance: Propósitos y objetivos del sistema, ya que los requisitos van cambiando a lo
largo del tiempo.
Modelo PinBall

Propuesto por Ambler (Ambler, 1994). Modelo muy didáctico señala que el pinball refleja la
forma que se desarrolla el software.

Pelota ====> Proyecto o subproyecto

Jugador ====> Equipo de desarrollo

Se procede de forma iterativa a encontrar clases, atributos, métodos y relaciones (actividades que
pueden englobarse en la fase de análisis) y definir colaboraciones, herencia, agregación y

subsistemas (actividades de diseño), y por último se pasa a la programación, prueba e

implementación.

Como en el pinball los pasos se pueden dar en cualquier orden y de forma simultánea.

Existen dos estilos a la hora de jugar

A lo seguro ===> Con tecnologías y métodos probados

Al límite ===> Con más riesgo (se pueden conseguir beneficios espectaculares)
Los ciclos de vida tradicionales son estructurados lo que hace difícil dividirlos en subsistemas
para ser implementados independientemente, en cambio los ciclos de vida orientado a objetos
son modulares, es decir, se dividen en módulos formados por componentes, donde cada
componente es independiente del otro y se relacionan a través de las interfaces; esta división
eventualmente facilita la construcción del software, puesto que se puede avanzar en distintas
partes del proyecto a la vez.

Los Ciclos de vida Orientados a Objetos tienen permiten la reutilización del código, algo con lo
que no cuentan los tradicionales.

Los Ciclos de vida Orientados a Objetos son más fáciles de mantener porque los cambios están
localizados en cada uno de estos componentes. De esta forma si el cliente tiene nuevos
requerimientos es mucho más fácil agregarlos sin tener que hacer demasiados cambios en lo que
ya se tiene. En cambio, los tradicionales tienen más complicaciones para detectar y corregir los
errores a tiempo, más aún la modificación o incremento de requerimientos ocasiona crisis en el
proyecto pues no suelen ser muy flexibles al cambio.
Bibliografía
88mary256. (13 de Mayo de 2012). Gestión Operativa de la Calidad del Software. Obtenido de
http://maestria-modulo7.blogspot.com/2012/05/ciclo-de-vida-orientado-objetos-vs.html

Glass, R. L. (2003). Facts and Fallacies of Software Engineering.