MODELOS DE

CICLO DE VIDA
Ingeniera del Software
Descripcin breve
El presente informe contiene descripciones y
conclusiones de modelos de ciclos de vida
de un software.

Hans Wellington Prada

Hans_prada@hotmail.com
Contenido
Modelo Cascada...................................................................................2
Anlisis de requisitos.........................................................................2
Diseo del Sistema............................................................................2
Diseo del Programa.........................................................................2
Codificacin.......................................................................................3
Pruebas.............................................................................................3
Verificacin........................................................................................3
Mantenimiento..................................................................................3
Modelo V...............................................................................................3
Modelo Interativo o Incremental...........................................................4
Modelo Espiral......................................................................................5
1. Determinar o fijar los objetivos.....................................................5
2. Anlisis del riesgo..........................................................................5
3. Desarrollar, verificar y validar.......................................................5
4. Planificar........................................................................................6
Modelo de Prototipos............................................................................6
Comparacin y Conclusin...................................................................7

1
Modelo Cascada

Anlisis de requisitos
En esta fase se analizan las necesidades de los usuarios finales del
software para determinar qu objetivos debe cubrir. De esta fase
surge una memoria llamada SRD (documento de especificacin de
requisitos), que contiene la especificacin completa de lo que debe
hacer el sistema sin entrar en detalles internos.
Es importante sealar que en esta etapa se debe consensuar todo lo
que se requiere del sistema y ser aquello lo que seguir en las
siguientes etapas, no pudindose requerir nuevos resultados a mitad
del proceso de elaboracin del software de una manera.
Diseo del Sistema
Descompone y organiza el sistema en elementos que puedan
elaborarse por separado, aprovechando las ventajas del desarrollo en
equipo. Como resultado surge el SDD (Documento de Diseo del
Software), que contiene la descripcin de la estructura relacional
global del sistema y la especificacin de lo que debe hacer cada una
de sus partes, as como la manera en que se combinan unas con
otras.
Es conveniente distinguir entre diseo de alto nivel o arquitectnico y
diseo detallado. El primero de ellos tiene como objetivo definir la
estructura de la solucin (una vez que la fase de anlisis ha descrito
el problema) identificando grandes mdulos (conjuntos de funciones
que van a estar asociadas) y sus relaciones. Con ello se define la
arquitectura de la solucin elegida. El segundo define los algoritmos
empleados y la organizacin del cdigo para comenzar la
implementacin...

2
Diseo del Programa
Es la fase en donde se realizan los algoritmos necesarios para el
cumplimiento de los requerimientos del usuario as como tambin los
anlisis necesarios para saber qu herramientas usar en la etapa de
Codificacin
Codificacin
Es la fase en donde se implementa el cdigo fuente, haciendo uso de
prototipos as como de pruebas y ensayos para corregir errores.
Dependiendo del lenguaje de programacin y su versin se crean las
bibliotecas y componentes reutilizables dentro del mismo proyecto
para hacer que la programacin sea un proceso mucho ms rpido.
Pruebas
Los elementos, ya programados, se ensamblan para componer el
sistema y se comprueba que funciona correctamente y que cumple
con los requisitos, antes de ser entregado al usuario final.
Verificacin
Es la fase en donde el usuario final ejecuta el sistema, para ello el o
los programadores ya realizaron exhaustivas pruebas para comprobar
que el sistema no falle.
En la creacin de desarrollo de cascada se implementa los cdigos de
investigacin y pruebas del mismo.
Mantenimiento
Una de las etapas mas criticas, ya que se destina un 75% de los
recursos, es el mantenimiento del Software ya que al utilizarlo como
usuario final puede ser que no cumpla con todas nuestras
expectativas.

Modelo V

3
La corriente de especificacin (parte izquierda, Project definition)
consiste principalmente de:
Conceptos de operaciones: que debe hacer el sistema a grandes
rasgos.
Requisitos del sistema y arquitectura del mismo.
Diseo detallado.
La corriente de pruebas (parte derecha, Project test and integration),
por su parte, suele consistir de:
Integracin de las distintas partes, prueba y verificacin de las
mismas.
Verificacin y validacin del sistema en conjunto.
Mantenimiento del sistema.
La corriente de desarrollo puede consistir (depende del tipo de
sistema y del alcance del desarrollo) en personalizacin,
configuracin o codificacin.

Modelo Interativo o Incremental

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 del Usuario 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

4
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.

Modelo Espiral
El desarrollo en espiral es un modelo de ciclo de vida del software
definido por primera vez por Barry Boehm en 1986, utilizado
generalmente en la Ingeniera de software. Las actividades de este
modelo se conforman en una espiral, en la que cada bucle o iteracin
representa un conjunto de actividades. Las actividades no estn
fijadas a ninguna prioridad, sino que las siguientes se eligen en
funcin del anlisis de riesgo, comenzando por el bucle interior.

5
1. Determinar o fijar los objetivos.
En este paso se definen los objetivos especficos para posteriormente
identifica las limitaciones del proceso y del sistema de software,
adems se disea una planificacin detallada de gestin y se
identifican los riesgos.
2. Anlisis del riesgo.
En este paso se efecta un anlisis detallado para cada uno de los
riesgos identificados del proyecto, se definen los pasos a seguir para
reducir los riesgos y luego del anlisis de estos riesgos se planean
estrategias alternativas.
3. Desarrollar, verificar y validar.
En este tercer paso, despus del anlisis de riesgo, se eligen un
paradigma para el desarrollo del sistema de software y se lo
desarrolla.
4. Planificar.
En este ltimo paso es donde el proyecto se revisa y se toma la
decisin si se debe continuar con un ciclo posterior al de la espiral. Si
se decide continuar, se desarrollan los planes para la siguiente fase
del proyecto.

Modelo de Prototipos
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

6
cliente. Esto permite que al mismo tiempo el desarrollador entienda
mejor lo que se debe hacer y el cliente vea resultados a corto plazo.

Comparacin y Conclusin
Si queremos buscar cosas en comn dentro de los modelos antes
descritos, podemos ver que todos funcionan con una entrada y una
salida. Con entrada me refiero a que todos necesitan o nacen de un
requerimiento que da lugar a que todo el modelo comience a
funcionar, y con Salida me refiero a que al terminar o pasar por todos
los procesos del modelo, tenemos que obtener un software o producto
final.
Tambin podemos ver que los modelos son muy similares y
particulares a la vez, puesto que muchos de sus procesos pueden ser
igualables como: determinar objetivos (espiral), anlisis requisitos
(cascada), comunicacin (prototipos), entre otros.

7
Pienso yo, que la particularidad de cada modelo debe ser bien usada
segn el proyecto que tengamos en mente o requerida. Si por
ejemplo tenemos un proyecto pequeo, deberamos de usar e
implementar un modelo de prototipos, puesto que al ser pequeo
puede darse una buena cantidad de ciclos, para tener un resultado
bueno y que agrade al cliente. En cambio se hablamos de un proyecto
de mayo envergadura, es un poco ms difcil decidir por un modelo,
puesto que muchos podran dar un buen resultado, en un tiempo
medido, y con una calidad de software complaciente.
Para finalizar, hemos podido ver en el conjunto de modelos que
algunos pasan por distintos procesos y otros por otros diferentes pero
el resultado final debe ser un software de calidad, bien documentado,
accesible, escalable, y de fcil uso, puesto que finalmente el usuario
es el que le da uso al software y es el que debe quedar satisfecho con
este.

8
Bibliografa
http://es.wikipedia.org. (s.f.). Obtenido de
http://es.wikipedia.org/wiki/Modelo_de_prototipos
http://es.wikipedia.org. (s.f.). Obtenido de
http://es.wikipedia.org/wiki/Desarrollo_en_espiral
http://es.wikipedia.org. (s.f.). Obtenido de
http://es.wikipedia.org/wiki/M%C3%A9todo_en_V
http://es.wikipedia.org. (s.f.). Obtenido de
http://es.wikipedia.org/wiki/Desarrollo_en_cascada
http://es.wikipedia.org/. (s.f.). Obtenido de
http://es.wikipedia.org/wiki/M%C3%A9todo_en_V
http://es.wikipedia.org/. (s.f.). Obtenido de
http://es.wikipedia.org/wiki/Desarrollo_iterativo_y_creciente
http://osc.co.cr. (s.f.). Obtenido de http://osc.co.cr/analisis-y-diseno-
de-sistemas-modelos-para-el-desarrollo-de-software/
http://prezi.com/. (s.f.). Obtenido de http://prezi.com/wdx-
avo5jmls/modelos-de-desarrollo-de-software/
http://procesosoftware.wikispaces.com. (s.f.). Obtenido de
http://procesosoftware.wikispaces.com/Modelo+Iterativo
http://www.ojovisual.net. (s.f.). Obtenido de
http://www.ojovisual.net/galofarino/modeloespiral.pdf
https://sites.google.com/site/programacion1electronica. (s.f.).
Obtenido de
https://sites.google.com/site/programacion1electronica/metodol
ogias-de-desarrollo-de-software/modelo-incremental-o-evolutivo