CICLO DE VIDA LINEAL

Es el ms sencillo de todos los modelos. consiste en descomponer la actividad global del proyecto
en etapas separadas, que son realizadas de manera lineal, es decir, cada etapa se realiza una sola
vez, a continuacin de la etapa anterior y antes de la etapa siguiente. Con un ciclo de vida lineal es
muy fcil dividir las tareas, y prever los tiempos (sumando linealmente los de cada etapa).
Las actividades de cada una de las etapas mencionadas deben ser independientes entre s, es
decir, que es condicin primordial que no haya retroalimentacin entre ellas, aunque si pueden
admitirse ciertos supuestos de realimentacion correctiva.
Desde el punto de vista de la gestin requiere tambin que se conozca desde el primer momento,
con excesiva rigidez lo que va aocurrir en cada una de las distintas etapas antes de comenzarla.
Esto ultimo minimiza, tambin las posibilidades de errores durante la codificacin y reduce al
minimo la necesidad de requerir informacin del cliente o del usuario.
Se destaca como ventaja la sencillez de su gestin y administracin tanto econmica como
temporal, ya que se acomoda perfectamente a proyectos internos de una empresa para programas
muy pequeos de ABM ( sistemas que realizan altas, bajas y modificaciones sobre un conjunto de
datos). Tiene como desventaja que no es aptopara desarrollos que superen minimamente
requerimientos de retroalimentacin entre etapas, es decir es muy costoso retomar una etapa
anterios al detectar alguna falla.

CICLO DE VIDA CASCADA PURO

Editar 0 4

Ciclo cascada Puro

Es el ms antiguo de todos los modelos de ciclo de vida y sirve de modelo para otros
modelos de ciclos de vida.
En un modelo en cascada un proyecto progresa a travs de una secuencia ordenada de
pasos que son:
Concepto del software.

Anlisis de requerimientos.

Diseo global.

Diseo detallado.

Codificacin y depuracin.

Prueba del sistema.

El modelo contiene una serie de etapas que no se solapan, y el proyecto se va revisando
tras cada una de las etapas. Para poder pasar a la siguiente etapa se tiene que haber
conseguido todos los objetivos de la etapa anterior, es un proceso secuencial.
Tiene una buena aplicacin cuando el problema es estable y cuando se trabaja con
metodologas tcnicas conocidas. Este modelo ser apropiado para la migracin de una
aplicacin o a una versin de mantenimiento bien definida.
Con este modelo se tiene un seguimiento de todas las fases del proyecto y del
cumplimiento de todos los objetivos marcados en cada etapa tanto de costos, fechas de
entrega y lo ms importante que pueden comprobar al final de cada etapa si el proyecto
cumple todas las necesidades del usuario.
A su vez esto es un problema ya que si el usuario se da cuenta de que falta una tarea de
la empresa en el proyecto una vez pasada esta etapa, el trabajo que hay que realizar se
retrasa en fechas de entrega y el costo es mayor. Por lo tanto esto produce un fracaso en
la industria ya que es reacio a las modificaciones de ltima hora.
Por este motivo se puede modificar el modelo en cascada pudiendo pasar de una etapa a
la anterior, pero suele ser difcil ya que hay que rehacer la etapa anterior, este modelo es
el ciclo de vida del salmn. Por lo tanto este es un modelo poco apropiado para proyectos
con fecha de entrega corta, pero su rendimiento puede mejorar notablemente variando el
modelo de la cascada pura.

Ciclo Cascada Con Subproyectos

Si una vez que se ha llegado al diseo arquitectnico, se comprueba que el sistema se

divide en varios subsistemas independientes entre s, sera razonable suponer que a partir
de ese punto cada uno se puede desarrollar por separado y en consecuencia en paralelo
con los dems. Cada uno tendr seguramente fechas de terminacin distintas. Una vez
que han terminado todos se integran y se prueba el sistema en su conjunto. La ventaja es
que se puede tener a ms gente trabajando en paralelo de forma eficiente. El riesgo es
que existan interdependencias entre los subproyectos.

* Requiere planeacin.
* Plantea Organizacin y planeacin de un gran proyecto

Se pueden realizar varias partes del proyecto al mismo tiempo por diferentes
desarrolladores
* Adecuada para el desarrollo de proyectos complejos que estiman de 1 a 3 aos de

desarrollo

CICLO DE VIDA SASHIMI

Descripcin:
El ciclo de vida tipo Sashimi podra ser considerado como una variacin del ciclo de vida
en cascada puro, en el cual las diferentes etapas pueden ser solapadas, permitiendo as
aumentar la eficiencia mediante la retroalimentacin entre las etapas. El nombre
Sashimi' deriva del modo del estilo de presentacin de rodajas de pescado crudo en
Japn. Al utilizar este ciclo de vida se obtiene una ganancia de calidad en el producto
final, adems de que no hace necesario una documentacin detallada para cada etapa,
ya que por el mismo hecho de que estas se solapan, comparten partes de la
documentacin. Entre los problemas que se presentan al utilizar este modelo existe la
dificultad de identificar el inicio y el fin dcada etapa, adems de que en caso de
presentarse problemas de comunicacin estos van a generar inconsistencias.
Ventajas:
No requiere tanta documentacin como el ciclo de vida de cascada ya que es continuo.
Su planificacin es sencilla.

Desventajas:
Ms difcil controlar el progreso del proyecto debido a que los finales de fase ya no son
un punto de referencia claro.
La dificultad de reconocer todos los requerimientos desde un inicio.
El ciclo de vida iterativo
En cada ciclo, iteracin, se revisa y mejora el producto. Un ejemplo de desarrollo iterativo es aquel basado en
refactorizaciones (te dejo el post de introduccin a la refactorizacin), en el que cada ciclo mejora ms la
calidad del producto. Es importante sealar que este ciclo no implica aadir funcionalidades en el producto,
pero si revisin y mejora.

MODELO ITERATIVO

Este modelo, tambin conocido como Evolutivo, es una derivacin del ciclo de vida en cascada
puro, que busca reducir el riesgo que surge entre las necesidades delUsuario y el Producto
final por malos entendidos durante la etapa de solicitud de requerimientos.
En el ciclo de vida iterativo, en cada Iteracin se reproduce el ciclo de vida en cascada a menor
escala. Los objetivos de una Iteracin se establecen en funcin de la evaluacin de
las Iteraciones precedentes. Desde el principio, al final de cada Iteracin se le entrega
al Cliente una versin completa y mejorada del Producto. El Cliente es quien luego de
cada Iteracin evala el Producto y lo corrige o propone mejoras.
Estas Iteraciones irn Refinando el sistema y se repetirn hasta obtener un Producto que satisfaga
al Cliente.
La Especificacin de requisitos se realiza en forma creciente: a medida que los Usuarios logran un
mejor entendimiento del problema, ste es reflejado en el sistema software. Es decir,
el Producto de cada etapa de Especificacin de requisitos es un agregado o mejora al Producto de
la etapa de especificacin anterior.
Este modelo se basa en dos premisas:
1) Los Usuarios a menudo no saben bien lo que quieren o necesitan.
2) Por lo general, los requisitos en algn momento van a cambiar.
Para solucionar el primer punto, los requisitos se determinan en base a alguna forma operacional
del sistema (por ejemplo, un prototipo) para ser revisado por los Usuarios. Para atender el segundo
punto, se realizan entregas parciales del sistema que permiten incorporar nuevos requisitos o
cambios en requisitos existentes en la siguiente entrega. Es decir, cada versin es una mejora
sobre la predecesora.
Este modelo se utiliza cuando no se puede especificar a priori todos los requisitos del software,
sino que el proceso ayudar a ir descubriendo paso a paso los requisitos a partir de cada

nueva Entrega.

El Modelo de prototipos, en Ingeniera de software, pertenece a los modelos de desarrollo

evolutivo. El prototipo debe ser construido en poco tiempo, usando los programas adecuados
y no se debe utilizar muchos recursos.
El diseo rpido se centra en una representacin de aquellos aspectos del software que sern
visibles para el cliente o el usuario final. Este diseo conduce a la construccin de un
prototipo, el cual es evaluado por el cliente para una retroalimentacin; gracias a sta se
refinan los requisitos del software que se desarrollar. La interaccin ocurre cuando el
prototipo se ajusta para satisfacer las necesidades del cliente. Esto permite que al mismo
tiempo el desarrollador entienda mejor lo que se debe hacer y el cliente vea resultados a corto
plazo.
ndice
[ocultar]

1 Etapas

2 Ventajas

3 Inconvenientes

4 Conclusiones

5 Vase tambin

Etapas[editar]

Plan rpido.

Modelado, diseo rpido

Construccin del Prototipo

Desarrollo, entrega y retroalimentacin

Comunicacin

Entrega del desarrollo final

Ventajas[editar]

Este modelo es til cuando el cliente conoce los objetivos generales para el software,
pero no identifica los requisitos detallados de entrada, procesamiento o salida.

Tambin ofrece un mejor enfoque cuando el responsable del desarrollo del software
est inseguro de la eficacia de un algoritmo, de la adaptabilidad de un sistema operativo o
de la forma que debera tomar la interaccin humano-mquina

Se puede reutilizar el codigo

La construccin de prototipos se puede utilizar como un modelo del proceso independiente, se

emplea ms comnmente como una tcnica susceptible de implementarse dentro del contexto
de cualquiera de los modelos del proceso expuestos. Sin importar la forma en que ste se
aplique, el paradigma de construccin de prototipos ayuda al desarrollado de software y al
cliente a entender de mejor manera cul ser el resultado de la construccin cuando los
requisitos estn satisfechos. De esta manera, este ciclo de vida en particular, involucra al
cliente ms profundamente para adquirir el producto.

Inconvenientes[editar]

El usuario tiende a crearse unas expectativas cuando ve el prototipo de cara al

sistema final. A causa de la intencin de crear un prototipo de forma rpida, se suelen
desatender aspectos importantes, tales como la calidad y el mantenimiento a largo plazo,
lo que obliga en la mayor parte de los casos a reconstruirlo una vez que el prototipo ha
cumplido su funcin. Es frecuente que el usuario se muestre reaccin a ello y pida que
sobre ese prototipo se construya el sistema final, lo que lo convertira en un prototipo
evolutivo, pero partiendo de un estado poco recomendado.

En aras de desarrollar rpidamente el prototipo, el desarrollador suele tomar algunas

decisiones de implementacin poco convenientes (por ejemplo, elegir un lenguaje de
programacin incorrecto porque proporcione un desarrollo ms rpido). Con el paso del
tiempo, el desarrollador puede olvidarse de la razn que le llev a tomar tales decisiones,
con lo que se corre el riesgo de que dichas elecciones pasen a formar parte del sistema
final...

Conclusiones[editar]
A pesar de que tal vez surjan problemas, la construccin de prototipos puede ser un
paradigma efectivo para la ingeniera del software. La clave es definir las reglas del juego
desde el principio; es decir, el cliente y el desarrollador se deben poner de acuerdo en:

Que el prototipo se construya y sirva como un mecanismo para la definicin de

requisitos.

Que el prototipo se descarte, al menos en parte.

Que despus se desarrolle el software real con un enfoque hacia la calidad.

Ciclo de Vida Evolutivo

Es afrontar el problema en donde la prctica nos demuestra que obtener todos los requerimientos
al comienzo del proyecto es muy difcil; la dificultad donde el usuario es complicado transmitir su
idea ya que los requerimientos evolucionan durante el desarrollo y de esta manera, surgen nuevos
requerimientos a cumplir. Por tales motivos el modelo de ciclo de vida evolutivo realiza una
interaccin de ciclos REQUERIMIENTOS -DESARROLLO - EVALUACIN.

En el modelo evolutivo, los requerimientos son cuidadosamente examinados, y slo esos que son
bien comprendidos son seleccionados para el primer incremento. Los desarrolladores construyen
una implementacin parcial del sistema que recibe slo estos requerimientos.
El sistema es entonces desarrollado, los usuarios lo usan, y proveen retroalimentacin a los
desarrolladores. Basada en esta retroalimentacin, la especificacin de requerimientos es
actualizada, y una segunda versin del producto es desarrollada y desplegada. El proceso se repite
indefinidamente.

Ventajas
Este modelo acepta que los requerimientos del usuario se pueden cambiar en cualquier
momento.
Es un modelo es muy til cuando desconocemos la mayora de los requerimientos iniciales o cuando
los requerimientos no estn completos.
Busca reemplazar el viejo sistema con uno nuevo que tendra la propiedad de satisfacer los nuevos
requerimientos lo ms rpido posible.

El desarrollo evolutivo es 100% compatible con el modelo cascada.

Desventajas
Modelo evolutivo asume que los requerimientos no son completamente conocidos al inicio
del proyecto.
El desarrollo de software en forma evolutiva requiere un especial cuidado en la manipulacin de
documentos, programas, datos de test, etc. desarrollados para distintas versiones del software.

PROYECTO A QUE ES APLICABLE:

> Proyecto de ventas
> Proyecto de Facturacin
> Proyecto de Mercadeo

Ciclo De Vida Incremental

Una forma de reducir los riesgos es construir solo una
parte del sistema, reservando otros aspectos para niveles
posteriores.
El desarrollo incremental es el proceso de construccin siempre incrementando subconjuntos de
requerimientos del sistema.
MODELO DE DESARROLLO INCREMENTAL.
En este modelo se desarrolla el sistema para satisfacer un subconjunto de requisitos especificados
y en posteriores versiones se incrementa el sistema con nuevas funcionalidades que satisfagan
mas requisitos.
CARACTERISTICAS.
Combina elementos del modelo de cascada con la filosofa interactiva de construccin de
prototipos
Cada secuencia lineal produce un producto operacional con cada incremento de la misma forma
que progresa el tiempo en el calendario
El primer incremento es a menudo el ncleo

 Como un resultado de evaluacin y/o utilizacin se desarrolla un plan para el incremento

siguiente, este proceso se repite hasta llegar al producto completo
Este modelo es particularmente til cuando la dotacin de personal no es suficiente para una
implementacin completa
Los primeros incrementos se pueden implementar con menos recursos
Si es muy riesgoso desarrollar el sistema completo de una sola vez, entonces debera considerar
este modelo
VENTAJAS.
Construir un sistema pequeo es siempre menos riesgoso que construir un sistema grande.
Al ir desarrollando parte de las funcionalidades, es ms fcil determinar si los requerimientos
planeados para los niveles subsiguientes son correctos.
Si un error importante es realizado, slo la ltima iteracin necesita ser descartada y utilizar el
incremento previo.
DESVENTAJAS.
Se presupone que todos los requisitos se han definido al inicio.
Se requiere de una experiencia importante para definir los incrementos de forma de distribuir en
ellos las tareas en forma proporcional
Si el sistema a desarrollar es de gran magnitud y se cuenta con un nico grupo para construirlo se
corre el riesgo que el desarrollo se prolongue demasiado en tiempo

Ciclo Orientado A Objetos

Los tipos de ciclos de vida que se han visto hasta ahora son relativos al anlisis y diseo
estructurados, pero los objetos tienen una particularidad, y es que estn basados en
componentes que se relacionan entre ellos a travs de interfaces, o lo que es lo mismo, son
mas modulares y por lo tanto el trabajo se puede dividir en un conjunto de miniproyectos.
Adems, hoy en da la tendencia es a reducir los riesgos, y en este sentido, el ciclo de vida en
cascada no proporciona muchas facilidades. Debido a todo esto, el ciclo de vida tpico en una
metodologa de diseo orientado a objetos es iterativo e incremental.
En este texto slo veremos un tipo de ciclo de vida orientado a objetos, que es adems el ms
representativo, el modelo fuente.

Modelo fuente
Fue creado por Henderson-Sellers y Edwards en 1990. Es un tipo de ciclo de vida pensado
para la orientacin a objetos y posiblemente el ms seguido. Un proyecto se divide en las
fases:

1.

Planificacin del negocio

2.

Construccin: Es la ms importante y se divide a su vez en otras cinco actividades

Planificacin

Investigacin

Especificacin

Implementacin

Revisin

3.

Entrega
La primera y la tercera fase son independientes de la metodologa de desarrollo orientado a
objetos. Adems de las tres fases, existen dos periodos:

1.
2.

Crecimiento: Es el tiempo durante el cual se construye el sistema

Madurez: Es el periodo de mantenimiento del producto. Cada mejora se planifica igual
que el periodo anterior, es decir, con las fases de Planificacin del negocio, Construccin y
Entrega.
Cada clase puede tener un ciclo de vida slo para ella debido a que cada una puede estar en
una fase diferente en un momento cualquiera. La ventaja es que permite un desarrollo
solapado e iterativo. En la figura 1.7 se muestra un esquema de este tipo de ciclo de vida.