MODELOS DEL CICLO DE VIDA MSc Raúl Córdova Bayas

DE DESARROLLO DE SOFTWARE 2016

08/06/2016 1
Procesos prescriptivos
Los modelos de proceso prescriptivo fueron propuestos para poner
orden en el caos del desarrollo de software.
Se conocen como modelos tradicionales.
Han dado cierta estructura útil al trabajo de ingeniería de software.
Constituyen un soporte razonablemente eficaz para los equipos de
software.
Sin embargo, el trabajo de ingeniería de software y el producto que
genera siguen “al borde del caos”.

08/06/2016 2
Procesos prescriptivos
Se llaman prescriptivos porque prescriben un conjunto de elementos
del proceso:
 Actividades estructurales
 Acciones de ingeniería de software
 Tareas
 Productos del trabajo
 Aseguramiento de la calidad
 Mecanismos de control del cambio para cada proyecto

También prescriben un flujo del proceso o flujo de trabajo, que

prescribe la manera en que los elementos del proceso se relacionan
entre sí.
Cada modelo pone distinto énfasis en las actividades estructurales
generales y define en forma diferente el flujo de proceso que invoca
cada actividad estructural (así como acciones y tareas de ISW).

08/06/2016 3
Modelo en cascada - Waterfall
Se aplica cuando los requerimientos del problema se comprenden
bien.
Cuando el trabajo desde la comunicación hasta el despliegue fluye
en forma razonablemente lineal.
Esto se puede dar cuando deben hacerse adaptaciones o mejoras
bien definidas a un sistema ya existente.
Ejemplo:
 la adaptación para un software de contabilidad que es obligatorio hacer debido a
cambios en las regulaciones gubernamentales.

También ocurre en cierto número limitado de nuevos esfuerzos de

desarrollo, pero sólo cuando los requerimientos están bien definidos y
tienen una estabilidad razonable.

08/06/2016 4
Comunicación
inicio del proyecto
recabar los requerimientos

Planeación
estimación
programación
seguimiento

Modelado
análisis
diseño

Construcción
código
pruebas

Despliegue
entrega
asistencia
retroalimentación
08/06/2016 5
08/06/2016 6
Modelo en cascada (cont.)
También se llama ciclo de vida clásico.
Sugiere un enfoque sistemático y secuencial para el desarrollo del
software.
Comienza con la especificación de los requerimientos por parte del
cliente.
Avanza a través de planeación, modelado, construcción y despliegue.
Concluye con el apoyo del software terminado (asistencia).
Una variante se denomina modelo en V.
Este modelo muestra la relación entre las acciones para el
aseguramiento de la calidad y aquellas asociadas con la
comunicación, modelado y construcción temprana.

08/06/2016 7
Modelo en V

08/06/2016 8
Modelo en V (cont.)
A medida que se avanza hacia abajo por el lado izquierdo de la V,
los requerimientos básicos del problema mejoran hacia
representaciones técnicas cada vez más detalladas.
Una vez generado el código, el equipo sube por el lado derecho de
la V ejecutando una serie de pruebas.
Las pruebas o acciones para asegurar la calidad validan cada uno
de los modelos creados cuando se pasó por el lado izquierdo de la V.
Los modelos cascada y en V no tienen diferencias.
El modelo en V proporciona una forma de visualizar el modo de
aplicación de las acciones de verificación y validación al trabajo de
ingeniería inicial.

08/06/2016 9
Modelo en cascada: problemas
Es raro que los proyectos reales sigan el flujo secuencial propuesto
por el modelo:
 Aunque se aceptan repeticiones, éstas se las hace indirectamente.
 Los cambios generan confusión conforme se avanza en el proyecto.

A menudo es difícil para el cliente enunciar todos los requerimientos

en forma explícita y desde el principio.
El cliente debe tener paciencia:
 No se dispondrá de una versión funcional del sistema hasta que el proyecto esté muy
avanzado.
 Un error grande sería desastroso si se lo detecta solamente en la fase de pruebas.

Se generan estados de bloqueo entre equipos.

08/06/2016 10
Modelo en cascada: ventajas y usos
Es un modelo sistemático y ordenado para generar software
Genera una documentación completa del proyecto.
Una etapa se inicia solamente si la anterior se termina.
Permite hacer un control de calidad en cada hito del proyecto.
Es útil en situaciones en las que los requerimientos son fijos y el
trabajo avanza en forma lineal hacia el final.
Apropiado para sistemas muy complejos en que los requerimientos no
cambian desde el principio:
 Problemas de ingeniería y científicos que ameritan el trabajo de varios equipos,
inclusive ubicados en diferentes lugares geográficos.

08/06/2016 11
Modelo de proceso incremental
Usado cuando los requerimientos del software están razonablemente
bien definidos, pero el alcance del esfuerzo de desarrollo imposibilita
un proceso lineal.
También cuando hay la necesidad imperiosa de dar rápidamente
cierta funcionalidad limitada a los usuarios y aumentarla en entregas
posteriores.
Combina elementos de los flujos de proceso lineal y paralelo.
Aplica secuencias lineales en forma escalonada a medida que
avanza el calendario de actividades del proyecto.
Cada secuencia produce incrementos de software susceptibles de
entregarse de manera similar a los incrementos producidos en un flujo
de proceso evolutivo, que se lo verá posteriormente.

08/06/2016 12
Modelo de proceso incremental (cont.)
El flujo de proceso para cualquier incremento puede incorporar el
paradigma del prototipo.
Es frecuente que el primer incremento sea el producto fundamental:
 Se abordan los requerimientos básicos, pero no se proporcionan muchas
características suplementarias (algunas conocidas y otras no).
 El cliente usa el producto fundamental o lo somete a una evaluación detallada.
 En función de esta evaluación se desarrolla un plan para el incremento que sigue.
 El plan incluye la modificación del producto fundamental para cumplir con las
necesidades del cliente, así como la entrega de características adicionales y más
funcionalidad.

El proceso se repite después de entregar cada incremento, hasta

terminar el producto final.

08/06/2016 13
Modelo de proceso incremental

08/06/2016 14
Modelo de proceso incremental (cont.)
El modelo se centra en que en cada incremento se entrega un
producto que ya opera.
Es útil cuando no se dispone de personal para la implementación
completa del proyecto en el plazo establecido.
Los primeros incrementos se desarrollan con poco personal.
Si el producto básico es bien recibido, se agrega más personal (si se
requiere) para que labore en el siguiente incremento.
Los incrementos se planean para administrar riesgos técnicos.

08/06/2016 15
Modelo de proceso incremental: ventajas y
desventajas
VENTAJAS:
 Tiene participación permanente del usuario.
 Permite cambio de requerimientos a lo largo del proceso.
 Permite entregas funcionales del sistema por cada incremento.
 Está ideado para manejar los incrementos en función de los riesgos del proyecto.

DESVENTAJAS:
 Con muchos incrementos se puede perder la visión del producto final.
 La integración es particularmente importante en cada incremento.

08/06/2016 16
Modelos de procesos evolutivos
Los requerimientos del negocio y del producto cambian en el tiempo.
Los plazos apretados del mercado hacen imposible la terminación de
un software perfecto.
Por lo que debe lanzarse una versión limitada a fin de aliviar la
presión de la competencia o del negocio.
Se comprenden bien los requerimientos pero los detalles del producto
o extensiones del sistema están aún por definirse.
Se necesita un modelo de proceso diseñado explícitamente para
adaptarse a un producto que evoluciona con el tiempo.
Estos son los modelos evolutivos que son iterativos.
Se caracterizan por la manera en la que permiten desarrollar
versiones cada más completas del software.

08/06/2016 17
Modelos de procesos evolutivos:
prototipos
Se lo puede usar como una técnica que puede implementarse en el
contexto de cualquiera de los modelos de proceso descritos antes.
Este paradigma ayuda a mejorar la comprensión de los que hay que
elaborar cuando los requerimientos no están claros.
También puede usarse para determinar la eficiencia de un algoritmo,
de la adaptabilidad de un sistema operativo o de la forma que debe
adoptar una interfaz de usuario.
También puede usarse el modelo de prototipos como un modelo de
proceso aislado.
En este último caso, sirve fundamentalmente para desarrollar sistemas
de software pequeños.

08/06/2016 18
Modelo de prototipos

08/06/2016 19
Modelos de procesos evolutivos:
prototipos (cont.)
Este paradigma comienza con la comunicación cuando se reúnen los
participantes para:
 Definir los objetivos generales del software,
 Identificar cualesquiera de los requerimientos que se conozcan y
 Detectar las áreas en las que es imprescindible una mayor definición.

Luego se planea rápidamente una iteración para hacer el prototipo y

se lleva a cabo el modelado, en la forma de un «diseño rápido».
El diseño rápido se centra en la representación de aquellos aspectos
del software que serán visibles para los usuarios finales (interfaces de
usuario).
El diseño rápido lleva a la construcción del prototipo.
Este es entregado y evaluado por el usuario, quien da
retroalimentación para mejorar o ampliar los requerimientos.

08/06/2016 20
Modelos de procesos evolutivos:
prototipos (cont.)
La iteración ocurre a medida que el prototipo es afinado para
satisfacer las necesidades de distintos participantes, permitiendo un
entendimiento mejor de lo que se necesita hacer.
El uso mayor del prototipo se da para identificar los requerimientos
del sistema software.
También se lo puede usar para probar herramientas, o para generar
rápidamente código (usando generadores de reportes y
administradores de ventanas) que permiten generar rápidamente
programas que funcionen.
Existen prototipos desechables, que se los deja de usar una vez
cumplidos los objetivos para los cuales fue construido.
También existen los prototipos evolutivos, que poco a poco se
transforman en el sistema real.

08/06/2016 21
Modelos de procesos evolutivos:
prototipos (cont.)
DESVENTAJAS:
1. Falta de calidad general del software:
 Generada por la prisa en hacer que funcionara.
 Puede generarse un producto difícil de mantener.
 Los clientes consideran al prototipo como el producto final.
 El gerente de desarrollo cede ante las demandas de los clientes.

2. Compromisos respecto de la implementación:

• Sistema operativo inapropiado.
• Lenguaje de programación conocido o porque es el único con el que cuenta.
• Algoritmo ineficiente sólo para demostrar capacidad.
• Puede llevar a comodidad en las elecciones, olvidando las razones por las que eran
inadecuadas.

08/06/2016 22
Modelos de procesos evolutivos:
prototipos (cont.)
VENTAJAS:
1. Participación permanente del cliente
2. Rapidez en la elaboración del producto
3. No se requieren tener todos los requerimientos desde el inicio
4. Facilidad para hacer cambios durante el proceso.

08/06/2016 23
Modelos de procesos evolutivos:
modelo espiral
Fue propuesto por Barry Boehm en 1988.
Combina la naturaleza iterativa de los prototipos con los aspectos
controlados y sistemáticos del modelo en cascada.
Permite hacer un desarrollo rápido de versiones cada vez más
completas.
Es un modelo que se basa en los riesgos del proceso.
El software se desarrolla en una serie de entregas evolutivas.
En las primeras iteraciones lo que se entrega puede ser un modelo o
prototipo.
En las iteraciones posteriores se producen versiones cada vez más
completas del sistema.

08/06/2016 24
Modelo espiral

08/06/2016 25
Modelos de procesos evolutivos:
modelo espiral (cont.)
El proceso comienza en el centro y sigue un sentido horario.
El riesgo se considera conforme se desarrolla cada vuelta.
En la primera vuelta se desarrolla una especificación del producto.
En las vueltas siguientes se desarrolla un prototipo y luego versiones
cada vez más completas del producto final.
Cada vez que se pasa por planeación se hacen ajustes al plan del
proyecto.
El costo y el cronograma se ajustan en base a la retroalimentación
obtenida del cliente después de la entrega para su evaluación.

08/06/2016 26
Modelos de procesos evolutivos:
modelo espiral (cont.)
El modelo puede adaptarse para aplicarse a lo largo del ciclo de
vida del software.
En este caso, el primer circuito puede representar un «proyecto de
desarrollo del concepto» que comienza en el centro de la espiral y
continúa por iteraciones múltiples hasta terminar el desarrollo del
concepto.
Si el concepto va a desarrollarse en un producto real, el proceso
sigue hacia fuera de la espiral y comienza un «proyecto de desarrollo
de producto nuevo».
Este producto nuevo evolucionará a través de varias iteraciones.
Luego puede aplicarse el circuito para que represente un «proyecto
de mejora del producto».
Así, la espiral se aplica hasta que se retira el producto.
08/06/2016 27
Modelos de procesos evolutivos:
modelo espiral (cont.)
VENTAJAS:
Este modelo es un enfoque realista para el desarrollo de sistemas y
de software a gran escala.
Se comprende y se reacciona mejor ante los riesgos en cada nivel de
evolución.
Usa los prototipos como mecanismo de reducción de riesgos.
Permite aplicar el enfoque de hacer prototipos en cualquier etapa de
la evolución del producto.
Sigue el modelo cascada, pero incorporado en una estructura
iterativa que refleja al mundo real en una forma más realista.
Demanda una consideración directa de los riesgos técnicos en todas
las etapas del proyecto, esperando reducirlos antes que se vuelvan un
problema.
08/06/2016 28
Modelos de procesos evolutivos:
modelo espiral (cont.)
DESVENTAJAS:
Es difícil convencer a los clientes de que el enfoque evolutivo en
espiral es controlable: se sabe cuándo comienza pero no se sabe
cuándo termina.
Demanda mucha experiencia en la evaluación del riesgo y se basa
en ella para alcanzar el éxito del proyecto.
Existen problemas cuando no se detectan riesgos y no se los
administra.
Es útil solamente para grandes proyectos.

08/06/2016 29
Modelos de procesos evolutivos:
conclusiones
Son idóneos para sistemas que cambian continuamente, que requieren
tiempos de entrega muy apretados y una necesidad apremiante de
la satisfacción del cliente o usuario.
En muchos casos, el tiempo para llegar al mercado es el
requerimiento administrativo más importante.
Si se pierde nicho de mercado, todo el proyecto podría carecer de
sentido.

08/06/2016 30
Modelos de procesos evolutivos:
conclusiones
Estos modelos, sin embargo, tienen demasiadas debilidades:
1. Hacer prototipos o seguir el proceso en espiral plantea un
problema para la planeación del proyecto debido a la
incertidumbre en el número de ciclos que se requieren para
elaborar el producto: La mayor parte de técnicas de
administración y estimación de proyectos se basa en un
planteamiento lineal de las actividades, por lo que no se ajustan
por completo.
2. Los procesos evolutivos no establecen la velocidad máxima de la
evolución. Si ocurren demasiado rápido, sin un periodo de
relajamiento, es seguro que el proceso se volverá un caos. Pero si
la velocidad es muy lenta, se verá perjudicada la productividad.

08/06/2016 31
Modelos de procesos evolutivos:
conclusiones
Debilidades:
3. Los procesos de software deben centrarse en la flexibilidad y
capacidad de extensión en lugar de alta calidad. Sin embargo,
debe darse prioridad a la velocidad del desarrollo con el
enfoque de cero defectos. Extender el desarrollo a fin de lograr
alta calidad podría dar como resultado la entrega tardía del
producto, cuando haya desaparecido el nicho de oportunidad.
Este cambio de paradigma es impuesto por la competencia al
borde del caos.

08/06/2016 32
Modelos de procesos evolutivos:
conclusiones
El objetivo de los modelos evolutivos es desarrollar software de alta
calidad en forma iterativa e incremental.
También se puede usar un proceso evolutivo para hacer énfasis en la
flexibilidad, expansibilidad y velocidad del desarrollo.
El reto es establecer un balance apropiado entre estos parámetros
críticos del proyecto y el producto, y la satisfacción del cliente (que
determina finalmente la calidad del software).

08/06/2016 33
Modelos de proceso especializado
Estos modelos tienen muchas de las características de uno o más de
los modelos tradicionales.
Se aplican cuando se elige un enfoque de ingeniería de software
especializado o definido muy específicamente.
Se consideran tres tipos de modelos especializados:
 Desarrollo basado en componentes
 El modelo de métodos formales
 Desarrollo de software orientado a aspectos

08/06/2016 34
Modelos de proceso especializado:
desarrollo basado en componentes
El modelo de desarrollo basado en componentes incorpora muchas
de las características del modelo espiral.
Es de naturaleza evolutiva y demanda un enfoque iterativo para la
creación de software.
Este modelo construye aplicaciones a partir de fragmentos de
software prefabricados, conocidos como componentes comerciales de
software general (COTS – Commercial off-the-shelf).
Los componentes COTS son desarrollados por vendedores que los
ofrecen como productos y brindan una funcionalidad con interfaces
bien definidas que permiten que el componente se integre en el
software que se va a construir.

08/06/2016 35
Modelos de proceso especializado:
desarrollo basado en componentes (cont.)
Las actividades de modelado y construcción comienzan con la
identificación de candidatos de componentes que pueden diseñarse
como:
 Módulos de software convencional
 Clases orientadas a objetos
 Paquetes de clases

Sin importar la tecnología usada para crear los componentes, el

modelo incorpora cinco etapas, basadas en un enfoque evolutivo.

08/06/2016 36
Desarrollo basado en componentes

08/06/2016 37
Modelos de proceso especializado:
desarrollo basado en componentes (cont.)
Etapas del modelo evolutivo:
1. Se investigan y evalúan, para el tipo de aplicación de que se
trate, productos disponibles basados en componentes.
2. Se consideran los aspectos de integración de los componentes.
3. Se diseña una arquitectura del software para que reciba los
componentes.
4. Se integran los componentes en la arquitectura.
5. Se efectúan pruebas exhaustivas para asegurar la funcionalidad
apropiada.

08/06/2016 38
Modelos de proceso especializado:
desarrollo basado en componentes (cont.)
El modelo del desarrollo basado en componentes lleva a la
reutilización de software.
Si este proceso se vuelve repetitivo, se tiene la posibilidad de reducir
el tiempo para el desarrollo así como el costo del proyecto.

08/06/2016 39
Modelos de proceso especializado:
Modelo de métodos formales
Este modelo agrupa actividades que llevan a la especificación
matemática formal del software.
Los métodos formales permiten especificar, desarrollar y verificar un
sistema software por medio del empleo de una notación matemática
rigurosa.
Permite eliminar algunos de los problemas de la especificación de
requerimientos que no han sido resueltos con otros paradigmas de la
ingeniería de software:
 La ambigüedad
 La completitud
 La inconsistencia

En diseño sirven como base para la verificación del software,

permitiendo descubrir y corregir errores que de otro modo no serían
detectados.
08/06/2016 40
Modelos de proceso especializado:
Modelo de métodos formales (cont.)
La mayor ventaja de estos métodos es que permiten construir sistemas
de alta confiabilidad.
Sin embargo, tienen algunas desventajas:
 El desarrollo de modelos formales consume mucho tiempo y es caro.
 Se requiere de mucha capacitación en métodos formales.
 La comunicación con el cliente es difícil.

Se aplican fundamentalmente para desarrollar software que no

puede fallar (software crítico), tales como:
 Control electrónico de aeronaves
 Software para equipos de monitoreo de pacientes
 Software para sistemas de seguridad en empresas y domicilios
 Control de centrales nucleares
 Vuelos aeroespaciales

08/06/2016 41
Modelos de proceso especializado:
Desarrollo de software orientado a
aspectos
Los aspectos manejan los componentes no funcionales o características
no funcionales de los sistemas.
Permiten una mejor modularidad de los sistemas, facilitando el
manejo de la funcionalidad del software independientemente de la
parte no funcional.
Las características no funcionales del software que se implementan
como aspectos pueden ser:
 Propiedades de alto nivel del sistema: seguridad, tolerancia a fallas.
 Aplicación de las reglas de negocios.
 Sincronización de tareas y administración de memoria (propiedades del sistema)

La Programación Orientada a Aspectos (POA) se la implementa con

Lenguajes Orientados a Aspectos (LOA), tal como AspectJ.
Se programa con lenguajes funcionales la parte funcional y con LOA
la parte no funcional de un sistema.
08/06/2016 42
Modelos de proceso especializado:
Desarrollo de software orientado a
aspectos (cont.)
Aunque no existe un proceso definido basado en aspectos, se puede
pensar en un proceso que adopte características de los modelos de
proceso evolutivo con concurrencia inmersa.
El modelo evolutivo es apropiado en tanto los aspectos se identifican
y después se construyen.
La concurrencia es esencial porque la ingeniería de aspectos se hace
en forma independiente de los componentes funcionales, pero siempre
relacionada.
Es esencial entonces disponer de comunicación asincrónica entre las
actividades del proceso software aplicadas a la ingeniería, y la
construcción de los aspectos y componentes.

08/06/2016 43
 RUP
08/06/2016 44
¿Qué es RUP?

Requisitos del usuario Proceso de desarrollo Sistema de software

de software

• RUP es un proceso de desarrollo de software:

– Forma disciplinada de asignar tareas y responsabilidades en una empresa
de desarrollo (quién hace qué, cuándo y cómo).

• Objetivos:
– Asegurar la producción de software de calidad dentro de plazos
y presupuestos predecibles. Dirigido por casos de uso, centrado en la
arquitectura, iterativo (mini-proyectos) e incremental (versiones).

• Es también un producto:
– Desarrollado y mantenido por Rational.
– Actualizado constantemente para tener en cuenta las mejores prácticas de
acuerdo con la experiencia.
 ¿Qué es RUP?

• Aumenta la productividad de los desarrolladores mediante

acceso a:
– Base de conocimiento, plantillas y herramientas.

• Se centra en la producción y mantenimiento de modelos del

sistema más que en producir documentos.

• RUP es una guía de cómo usar UML de la forma más efectiva.

• Existen herramientas de apoyo a todo el proceso:

– Modelamiento visual, programación, pruebas, etc.
 ¿Qué es RUP?
Pruebas de rendimiento y carga Diseño OO de IU
(Performance Awareness)
1998 Rational Unified Ingeniería de Datos
Ingeniería de Negocios Process 5.0 (Vigortech)
Administración de
Configuración y Cambios UML 1.2
(Pure-Atria)
Escuela de Rational Objectory Proceso SQA
1997 Requerimientos Process 4.1 (SQA Inc.)
(Requisite Inc.)
UML 1.0

OMT Rational Objectory UML 0.8

1996 Booch Process 4.0

Rational
1995 Approach Objectory
Process
1987 Ericsson
1967 method
Las mejores prácticas

• RUP pretende implementar las mejores prácticas

actuales en ingeniería de software:

– Desarrollo iterativo del software

– Administración de requerimientos
– Uso de arquitecturas basadas en componentes
– Modelamiento visual del software
– Verificación de la calidad del software
– Control de cambios
Desarrollo iterativo

• El software moderno es complejo y novedoso. No es realista

usar un modelo lineal de desarrollo como el de cascada.
• Un proceso iterativo permite una comprensión creciente de los
requerimientos a la vez que se va haciendo crecer el sistema.
• RUP sigue un modelo iterativo que aborda las tareas más
riesgosas primero.
• Con esto se logra reducir los riesgos del proyecto y tener un
subsistema ejecutable tempranamente.
 Administración de requerimientos

• RUP describe cómo:

– Obtener los requerimientos
– Organizarlos
– Documentar requerimientos de funcionalidad y restricciones
– Rastrear y documentar decisiones
– Captar y comunicar requerimientos del negocio

• Los casos de uso y los escenarios indicados por el proceso han

probado ser una buena forma de captar requerimientos y guiar
el diseño, la implementación y las pruebas.
Arquitecturas basadas en componentes

• El proceso se basa en diseñar tempranamente una

arquitectura base ejecutable.

• La arquitectura debe ser:

– Flexible
– Fácil de modificar
– Intuitivamente comprensible
– Promueve la reutilización de componentes

• RUP apoya el desarrollo basado en componentes, tanto

nuevos como preexistentes.
Modelamiento visual

• Modelamiento visual de la estructura y el

comportamiento de la arquitectura y los componentes.

• Bloques de construcción:
– Ocultan detalles
– Permiten la comunicación en el equipo de desarrollo
– Permiten analizar la consistencia:
• entre las componentes
• entre diseño e implementación

• UML es la base del modelamiento visual de RUP.

Verificación de cualidades

• No sólo la funcionalidad es esencial, también el

rendimiento y la confiabilidad.

• RUP ayuda a planificar, diseñar, implementar, ejecutar y

evaluar pruebas que verifiquen estas cualidades.

• El aseguramiento de la calidad es parte del proceso de

desarrollo y no la responsabilidad de un grupo
independiente.
Control de cambios

• Los cambios son inevitables, pero es necesario evaluar si

éstos son necesarios y rastrear su impacto.

• RUP indica como controlar, rastrear y monitorear los

cambios dentro del proceso iterativo de desarrollo.
Ciclos y fases

• RUP divide el proceso de desarrollo en ciclos, teniendo

un producto al final de cada ciclo.

• Cada ciclo se divide en cuatro Fases:

– Inicio
– Elaboración
– Construcción
– Transición

• Cada fase concluye con un hito bien definido donde

deben tomarse ciertas decisiones.
Fases de RUP
Fases de RUP: Inicio

• Se establece la oportunidad y alcance el proyecto.

• Se identifican todas las entidades externas con las que se

trata (actores) y se define la interacción a un alto nivel de
abstracción:
– Identificar todos los casos de uso
– Describir algunos en detalle

• La oportunidad del negocio incluye:

– Criterios de éxito
– Identificación de riesgos
– Estimación de recursos necesarios
– Plan de las fases incluyendo hitos
Fases de RUP: Inicio

Productos:

• Un documento de visión • Caso de negocio:

general:
– Requerimientos generales del
proyecto
– Características principales
– Restricciones
• Modelo inicial de casos de uso
(10% a 20 % listos).
• Glosario.
– Contexto
– Criterios de éxito
– Pronóstico financiero
• Identificación inicial de riesgos.
• Plan de proyecto.
• Uno o más prototipos.
Fases de RUP: Inicio

Hito:
Objetivos del
Ciclo de Vida

Inicio Elaboración Construcción Transición

• Las partes interesadas deben acordar el alcance y la

estimación de tiempo y costo.

• Comprensión de los requerimientos plasmados en casos

de uso.
Fases de RUP: Elaboración

• Objetivos:
– Analizar el dominio del problema
– Establecer una arquitectura base sólida
– Desarrollar un plan de proyecto
– Eliminar los elementos de mayor riesgo para el desarrollo
exitoso del proyecto

• Visión de “una milla de amplitud y una pulgada de

profundidad” porque las decisiones de arquitectura
requieren una visión global del sistema.
Fases de RUP: Elaboración
Productos:
• Es la parte más crítica del
proceso:
– Al final toda la ingeniería
“dura” está hecha
– Se puede decidir si vale la pena
seguir adelante
• A partir de aquí la arquitectura,
los requerimientos y los planes
de desarrollo son estables.
• Ya hay menos riesgos y se
puede planificar el resto del
proyecto con menor
incertidumbre.
• Se construye una arquitectura
ejecutable que contemple:
– Los casos de uso críticos
– Los riesgos identificados
 Fases de RUP: Elaboración

Productos:

• Modelo de casos de uso (80% • Un prototipo ejecutable de la

completo) con descripciones arquitectura.
detalladas. • Lista revisada de riesgos y del
• Otros requerimientos no funcio- caso de negocio.
nales o no asociados a casos de uso. • Plan de desarrollo para el resto
• Descripción de la Arquitectura del del proyecto.
Software. • Un manual de usuario
preliminar.
Fases de RUP: Elaboración

Hito: Arquitectura de
Ciclo de Vida

Concepción Elaboración Construcción Transición

• Condiciones de éxito de la elaboración:

– ¿Es estable la visión del producto?
– ¿Es estable la arquitectura?
– ¿Las pruebas de ejecución demuestran que los riesgos han sido
abordados y resueltos?
– ¿Es el plan del proyecto algo realista?
– ¿Están de acuerdo con el plan todas las personas involucradas?
Fases de RUP: Construcción

• En esta fase todas las componentes restantes se desarrollan

e incorporan al producto.

• Todo es probado en profundidad.

• El énfasis está en la producción eficiente y no ya en la

creación intelectual.

• Puede hacerse construcción en paralelo, pero esto exige

una planificación detallada y una arquitectura muy estable.
Fases de RUP: Construcción

Productos:

• El producto de software integrado y corriendo en la plataforma

adecuada.

• Manuales de usuario.

• Una descripción del “release” actual.

Fases de RUP: Construcción

Hito:
Capacidad
Operacional

Concepción Elaboración Construcción Transición

• Se obtiene un producto Beta que debe decidirse si puede

ponerse en ejecución sin mayores riesgos.
• Condiciones de éxito:
– ¿El producto está maduro y estable para instalarlo en el ambiente
del cliente?
– ¿Están los interesados listos para recibirlo?
Fases de RUP: Transición

• El objetivo es traspasar el software desarrollado a la

comunidad de usuarios.
• Una vez instalado surgirán nuevos elementos que
implicarán nuevos desarrollos (ciclos).
• Incluye:
– Pruebas Beta para validar el producto con las expectativas del
cliente
– Ejecución paralela con sistemas antiguos
– Conversión de datos
– Entrenamiento de usuarios
– Distribuir el producto
Fases de RUP: Transición

Objetivos:

• Obtener autosuficiencia de parte de los usuarios.

• Concordancia en los logros del producto de parte de las
personas involucradas.
• Lograr el consenso cuanto antes para liberar el producto al
mercado.

Concepción Elaboración Construcción Transición

Producto
Definiciones

Trabajador
• Un trabajador define el comportamiento y las
responsabilidades de un individuo.
• Es como un “sombrero” que la persona usa durante el
proyecto:
– Una persona puede tener varios sombreros
– Es el rol que desempeña en un momento dado
• Responsabilidades:
– Hacer una serie de actividades
– Ser el responsable de una serie de artefactos
 Definiciones
Actividades
• Una actividad es una unidad de
trabajo que se asigna a un
trabajador. Ej.:
– Crear o modificar un artefacto
• Una actividad lleva entre un par
de horas y un par de días,
involucra un solo trabajador y
un número pequeño de
artefactos.
• Las actividades se consideran en la
planificación y evaluación del progreso
del proyecto.
• Ejemplos:
– Planificar una iteración - Administrador
de proyecto
– Encontrar actores y casos de uso -
Analista
– Revisar el diseño - Revisor de diseño
– Ejecutar pruebas de performance - Ing.
de pruebas de performance
Asignación de actividades

Recurso Trabajador Actividad

Pablo Diseñador Diseño de Objetos

María Autor de Casos de Uso Detallar un Caso de Uso

José Diseñador de Casos de Uso Diseñar un Caso de Uso

Silvia Revisor de Diseño Revisar el Diseño

Eduardo Arquitecto Análisis de Arquitectura

Diseño de Arquitectura
 Artefactos
• Elementos de información
producidos, modificados o
usados por el proceso.
• Son los productos tangibles del
proyecto.
• Son usados por los trabajadores
para realizar nuevas actividades y
son el resultado de esas
actividades.
• Ejemplos:
– Un modelo, como el modelo de
casos de uso o el modelo de
diseño.
– Un elemento del modelo, como
una clase o un caso de uso.
– Un documento tal como el Caso
del Negocio o la Arquitectura
del Software.
– Código fuente.
– Código ejecutable.
 Flujos de trabajo

Análisis de Diseño de Describir Describir

• Una lista de actividades, Arquitectura Arquitectura Concurrencia Distribución

trabajadores y artefactos Arquitecto

constituye un proceso.
Análisis de Diseño de
Casos de Uso Casos de Uso

• Un flujo de trabajo es una Diseñador de

Casos de Uso
secuencia de actividades que
produce un resultado valioso. Análisis de
Objetos Diseño de
Objetos

Diseñador
• No siempre es posible
representar flujos de trabajo.
Revisor de Revisar el Revisar el Revisar la
Diseño Análisis Diseño Arquitectura
 Flujos de trabajo esenciales
Flujos de Trabajo
de Ingeniería

Flujos de Trabajo
de Apoyo
Flujos de trabajo

• Existen habitualmente problemas de comunicación entre

ingenieros de software e ingenieros de negocios.

• RUP proporciona un lenguaje y proceso común para estos

dos ámbitos.

• Para el modelamiento del negocio se usan “business use

cases” (casos de uso del negocio):
– La forma en que el software dará apoyo al negocio.
 Requerimientos

Imprimir Informe
• Los desarrolladores y
Reciclar Operador
clientes deben acordar qué Cliente

es lo que el sistema debe Administrar Depósito

hacer:
– Relevar requerimientos • Los casos de uso describen
– Documentar funcionalidad la funcionalidad.
y restricciones • Los requerimientos no
– Documentar decisiones funcionales se incluyen en
– Identificar actores una especificación
– Identificar casos de uso complementaria.
Análisis y diseño
• Descripción de cómo se
implementará el sistema: un plano
• Debe:
– Ejecutar las tareas y funciones
descritas en los casos de uso
– Satisfacer todos los requerimientos
– Flexible a cambios
• El diseño se centra en la noción de
arquitectura.
• Diseñar y validar la arquitectura
es una tarea esencial.
• El modelo de diseño consta de
– Clases estructuradas en paquetes
– Diseños de subsistemas con
interfaces definidas
(componentes)
– Forma de colaboración entre las
clases.
Implementación

• Propósito:
– Definir la organización del código
– Implementar clases y objetos en forma de componentes
(fuente, ejecutables, etc.)
– Probar las componentes desarrolladas
– Integrar las componentes en un sistema ejecutable
 Pruebas

• Propósito:
• RUP propone probar las componentes
– Verificar la interacción entre los
desde el principio:
objetos
– Confiabilidad, funcionalidad y
– Verificar la integración apropiada
performance
de componentes
– Verificar que se satisfacen los • Las pruebas de regresión son
requerimientos
importantes en desarrollos iterativos.
– Identificar los defectos y
corregirlos antes de la instalación
• Rational tiene herramientas para
automatizar algunas pruebas.
• RUP describe como planear y
ejecutar estas pruebas.
Distribución
• Producir un producto y hacerlo
llegar a sus usuarios finales.
• Incluye varias actividades:
– Producir un “release”
– Empaquetar el software
– Distribuir el software
– Instalar el software
– Apoyar a los usuarios
• A veces también incluye:
– Realizar pruebas beta
– Migración de datos
– Aceptación formal
• La mayor parte de la distribución
ocurre durante la transición.
• Este es uno de los flujos de
trabajo menos documentados en
RUP.
Administración de proyectos

• Es el arte de balancear objetivos contrarios, manejar

riesgos y producir software que satisface a clientes y
usuarios.

• Existen pocos proyectos realmente exitosos.

• RUP incluye:
– Un framework para manejo de proyectos de software
– Guías para planificación, provisión de personal, ejecución y
monitoreo de planes
– Un framework para manejar riesgos
Administración de configuración y cambios

• Forma de controlar los artefactos producidos por las

personas que trabajan en el proyecto.

• Algunos problemas habituales:

– Actualizaciones simultáneas
– Múltiples versiones

• RUP da guías para:

– Desarrollos en paralelo
– Automatizar la construcción
– Administrar defectos
Ambiente

• Ambiente y herramientas de desarrollo que harán

posible llevar a cabo el proyecto.

• RUP guía en la configuración de un ambiente de

proceso apropiado a cada proyecto.