Modelos del ciclo de vida del Software

l. Modelo en V
Es una representacin grfica del ciclo de vida del desarrollo del sistema. Resume
los pasos principales que hay que tomar en conjuncin con las correspondientes
entregas de los sistemas de validacin.

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 en espiral
En cada vuelta o iteracin hay que tener en cuenta:

Los Objetivos: qu necesidad debe cubrir el producto.

Alternativas: las diferentes formas de conseguir los objetivos de forma exitosa,

desde diferentes puntos de vista como pueden ser:

1. Caractersticas: experiencia del personal, requisitos a cumplir, etc.

2. Formas de gestin del sistema.
3. Riesgo asumido con cada alternativa.

Desarrollar y Verificar: Programar y probar el software.

Si el resultado no es el adecuado o se necesita implementar mejoras o
funcionalidades:

Se planificaran los siguientes pasos y se comienza un nuevo ciclo de la espiral. La

espiral tiene una forma de caracola y se dice que mantiene dos dimensiones, la
radial y la angular:

1. Angular: Indica el avance del proyecto del software dentro de un ciclo.

2. Radial: Indica el aumento del coste del proyecto, ya que con cada nueva iteracin
se pasa ms tiempo desarrollando.

ll. Modelo en espiral

Este sistema es muy utilizado en proyectos grandes y complejos como puede ser,
por ejemplo, la creacin de un Sistema Operativo.
Al ser un modelo de Ciclo de Vida orientado a la gestin de riesgo se dice que uno
de los aspectos fundamentales de su xito radica en que el equipo que lo aplique
tenga la necesaria experiencia y habilidad para detectar y catalogar correctamente
los riesgos.
Tareas

Para cada ciclo habr cuatro actividades:

1. Determinar Objetivos.
2. Anlisis del riesgo.
3. Desarrollar y probar.
4. 'Planificacin.'

Determinar o fijar objetivos

Fijar tambin los productos definidos a obtener: requerimientos, especificacin,

manual de usuario.

Fijar las restricciones.

Identificacin de riesgos del proyecto y estrategias alternativas para evitarlos.

Hay una cosa que solo se hace una vez: planificacin inicial.
Desarrollar, verificar y validar(probar)

Tareas de la actividad propia y de prueba.

Anlisis de alternativas e identificacin resolucin de riesgos.

Dependiendo del resultado de la evaluacin de los riesgos, se elige un modelo

para el desarrollo, el que puede ser cualquiera de los otros existentes, como
formal, evolutivo, cascada, etc. As si por ejemplo si los riesgos en la interfaz de
usuario son dominantes, un modelo de desarrollo apropiado podra ser la
construccin de prototipos evolutivos. Si lo riesgos de proteccin son la principal
consideracin, un desarrollo basado en transformaciones formales podra ser el
ms apropiado.
Anlisis del riesgo

Se lleva a cabo el estudio de las causas de las posibles amenazas y probables

eventos no deseados y los daos y consecuencias que stas puedan producir. Se
evalan alternativas. Se debe tener un prototipo antes de comenzar a desarrollar y
probar.
En resumen, es para tener en cuenta de los riesgos de cada uno de los mbitos
Mecanismos de Control

La dimensin radial mide el coste.

La dimensin angular mide el grado de avance del proyecto.

Variaciones del modelo en espiral
Modelo en Espiral Tpico de seis regiones
El modelo en espiral puede adaptarse y aplicarse a lo largo de la vida del software
de computadora, a diferencia del modelo de proceso clsico que termina cuando
se entrega el software.
Las 6 regiones que componen este modelo son las siguientes:

Comunicacin con el cliente - Tareas necesarias para plantear la comunicacin

entre el desarrollador y el cliente.

Planificacin - Tareas inherentes a la definicin de recursos, el tiempo y otras

informaciones relacionadas con el proyecto. Son todos los requerimientos.

Anlisis de riesgos Tareas para evaluar riesgos tcnicos y otras informaciones

relacionadas con el proyecto.

Ingeniera - Tareas para construir una o ms representaciones de la aplicacin.

Construccin y adaptacin - Tareas requeridas para construir, probar, instalar y

proporcionar soporte a los usuarios.

Evaluacin del cliente - Tareas requeridas para obtener la reaccin del cliente
segn la evaluacin de las representaciones del software creadas durante la etapa
de ingeniera e implementacin durante la etapa de instalacin. 3
Modelo en espiral WIN WIN (Ganar Ganar)
El modelo Win-Win es una adaptacin del modelo espiral que se enfatiza en la
participacin del cliente en el proceso de desarrollo de un producto de software.

En un caso ideal, el desarrollador simplemente pregunta al cliente lo que se

requiere y el cliente proporciona suficiente informacin y detalles para proceder.
Sin embargo esto no suele ocurrir en la mayora de los casos y es necesario que
se establezcan negociaciones significativas entre ambas partes para equilibrar la
funcionalidad y rendimiento con los costos y tiempo de salida al mercado del
producto. El modelo Win-Win deriva su nombre del objetivo de estas
negociaciones, es decir, "ganar-ganar". El cliente recibe el producto que satisface
la mayora de sus necesidades, y el desarrollador trabaja para alcanzar
presupuestos y fechas de entrega. Para lograr este objetivo, se realizan varias
actividades de negociacin al principio de cada paso alrededor de la espiral. 4

lll. Modelo en Cascada

Fases:
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...
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 ms crticas, 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.

lV. Modelo de proceso unificado

El Proceso Unificado de Desarrollo Software o simplemente Proceso
Unificado es un marco de desarrollo de software que se caracteriza por estar
dirigido por casos de uso, centrado en la arquitectura y por ser iterativo e
incremental. El refinamiento ms conocido y documentado del Proceso Unificado
es el Proceso Unificado de Rational o simplemente RUP.
El Proceso Unificado no es simplemente un proceso, sino un marco de trabajo
extensible que puede ser adaptado a organizaciones o proyectos especficos. De
la misma forma, el Proceso Unificado de Rational, tambin es un marco de trabajo
extensible, por lo que muchas veces resulta imposible decir si un refinamiento
particular del proceso ha sido derivado del Proceso Unificado o del RUP. Por dicho
motivo, los dos nombres suelen utilizarse para referirse a un mismo concepto.
El nombre Proceso Unificado se usa para describir el proceso genrico que
incluye aquellos elementos que son comunes a la mayora de los refinamientos
existentes. Tambin permite evitar problemas legales ya que Proceso Unificado de
Rational o RUP son marcas registradas por IBM (desde su compra deRational
Software Corporation en 2003). El primer libro sobre el tema se denomin, en su
versin espaola, El Proceso Unificado de Desarrollo de Software(ISBN 84-7829036-2) y fue publicado en 1999 por Ivar Jacobson, Grady Booch y James
Rumbaugh, conocidos tambin por ser los desarrolladores del UML, el Lenguaje
Unificado de Modelado. Desde entonces los autores que publican libros sobre el
tema y que no estn afiliados a Rational utilizan el trmino Proceso Unificado,
mientras que los autores que pertenecen a Rational favorecen el nombre
de Proceso Unificado de Rational.

Caractersticas
Iterativo e Incremental
El Proceso Unificado es un marco de desarrollo iterativo e incremental compuesto
de cuatro fases denominadas Inicio, Elaboracin, Construccin y Transicin. Cada
una de estas fases es a su vez dividida en una serie de iteraciones (la de inicio
puede incluir varias iteraciones en proyectos grandes). Estas iteraciones ofrecen
como resultado un incremento del producto desarrollado que aade o mejora las
funcionalidades del sistema en desarrollo.
Cada una de estas iteraciones se divide a su vez en una serie de disciplinas que
recuerdan a las definidas en el ciclo de vida clsico o en cascada: Anlisis de
requisitos, Diseo, Implementacin y Prueba. Aunque todas las iteraciones suelen
incluir trabajo en casi todas las disciplinas, el grado de esfuerzo dentro de cada
una de ellas vara a lo largo del proyecto.

Diagrama ilustrando como el nfasis relativo en las distintas disciplinas cambia a

lo largo del proyecto.
Dirigido por los casos de uso
En el Proceso Unificado los casos de uso se utilizan para capturar los requisitos
funcionales y para definir los contenidos de las iteraciones. La idea es que cada
iteracin tome un conjunto de casos de uso o escenarios y desarrolle todo el
camino a travs de las distintas disciplinas: diseo, implementacin, prueba, etc.
El proceso dirigido por casos de uso es el rup. Nota: en UP se est Dirigido por
requisitos y riesgos de acuerdo con el Libro UML 2 de ARLOW, Jim que
menciona el tema.
Centrado en la arquitectura
El Proceso Unificado asume que no existe un modelo nico que cubra todos los
aspectos del sistema. Por dicho motivo existen mltiples modelos y vistas que
definen la arquitectura de software de un sistema. La analoga con la construccin
es clara, cuando construyes un edificio existen diversos planos que incluyen los
distintos servicios del mismo: electricidad, fontanera, etc.
Enfocado en los riesgos
El Proceso Unificado requiere que el equipo del proyecto se centre en identificar
los riesgos crticos en una etapa temprana del ciclo de vida. Los resultados de
cada iteracin, en especial los de la fase de Elaboracin deben ser seleccionados
en un orden que asegure que los riesgos principales son considerados primero.
Lenguaje unificado de modelado
El Lenguaje unificado de modelado, no es el sucesor de la oleada de mtodos de
anlisis y diseo orientados a objetos que surgi a finales de la dcada de los
1980 y principios de la siguiente. El UML unifica, sobre todo, los mtodos de

Booch, Rumbaugh, Brhl (OMT) y Jacobson, pero su alcance ha llegado a formar

parte fundamental de la Ingeniera de Software tras su estandarizacin en 1997
con el OMG (Object Management Group o Grupo de administracin de objetos).
Fases
El Proceso Unificado de desarrollo puede ser dividido en cuatro fases para su
mejor desarrollo. Estas fases ayudando tanto a la elaboracin como a la
resolucin de problemas.
Inicio
En la fase de inicio se define el negocio: facilidad de realizar el proyecto, se
presenta un modelo, visin, metas, deseos del usuario, plazos, costos y viabilidad.
Elaboracin
En esta fase se obtiene la visin refinada del proyecto a realizar, la
implementacin iterativa del ncleo del de la aplicacin, la resolucin de riesgos
altos, nuevos requisitos y se ajustan las estimaciones.
Construccin
Esta abarca la evolucin hasta convertirse en producto listo incluyendo requisitos
mnimos. Aqu se afinan los detalles menores como los diferentes tipos de casos o
los riesgos menores.
Transicin
En esta fase final, el programa debe estar listo para ser probado, instalado y
utilizado por el cliente sin ningn problema. Una vez finalizada esta fase, se debe
comenzar a pensar en futuras novedades para la misma.
Desde el punto de vista Tcnico: el proyecto est formado por los flujos de trabajo
fundamentales: captura de requerimientos, anlisis, diseo, implementacin y
pruebas.
Tantos el punto de vista Gerencial como el Tcnico concuerdan en: La iteracin.