Desarrollo de software.

Ciclo de vida
RUP (Rational Unified Process)
RUP es un marco de desarrollo, te indica una forma de enfocar un proyecto de desarrollo de
software y despus en funcin de la naturaleza del mismo haces las adaptaciones oportunas (sin
salirte de las fronteras que te marca la metodologa porque de lo contrario estaramos hablando
de algo que no sera RUP).
RUP sigue principios de ingeniera del software para la obtencin de sistemas de informacin de
calidad y de esta forma proporcionar una alternativa que permita evitar que los productos que se
obtengan caigan en los aspectos que caracterizan a la crisis del software (todava muy presente en
nuestros das).
RUP sigue una estrategia de ciclo de vida iterativo e incremental, pero de una forma un tanto
peculiar, como vamos a ver a continuacin.
El ciclo de vida RUP se divide en 4 fases: Iniciacin, Elaboracin, Construccin y Transicin.
En cada fase se realizan una o ms iteraciones (con el objeto de ir perfeccionando los objetivos,
mediante el feedback del usuario) y hasta que no finaliza una fase no se comienza con la siguiente.
Por regla general, la fase en la que se realizan ms iteraciones es la Construccin.
En cada fase se refinan los objetivos de las fases anteriores en el proceso de conseguir el objetivo
u objetivos de la fase, por ejemplo, en la fase de construccin se pueden modificar, aadir o
eliminar requisitos, casos de uso, etc lo que tiene un impacto en lo obtenido en fases anteriores,
acercndonos cada vez ms a un sistema que satisfaga las necesidades de los usuarios.
En cada fase y en cada iteracin se realiza un ciclo de vida en cascada con las siguientes etapas:
Anlisis, Diseo, Construccin (las tareas de programacin que se realizan, sobre todo las fases de
Construccin y Transicin son perfectamente compatibles con la utilizacin de tcnicas de
integracin continua y anlisis esttico de cdigo), Pruebas/Integracin/Implantacin. El alcance
del ciclo de vida depende en la fase en la que nos encontremos, es decir, aunque se realice un
ciclo de vida en cascada en la fase de Iniciacin, lo ms probable es que no se llegue a construir
nada o se llegue a algn a hacer algn prototipo de muy alto nivel.
Los objetivos que se persiguen en cada fase son los siguientes:
- Iniciacin: Obtencin de los objetivos, catlogo de requisitos, identificacin de casos de uso.
- Elaboracin: Refinamiento de los objetivos de la fase anterior, casos de uso, anlisis, diseo,
definicin y establecimiento de la arquitectura base del sistema.
- Construccin: Refinamiento de los objetivos de las fases anteriores y construccin del sistema de
informacin.

- Transicin: Refinamiento de los objetivos de las fases anteriores e implantacin del sistema de
informacin (preparacin del producto para su entrega y pasos a produccin de versiones no
finales (porque hay que hacer ajustes) y de la versin final prevista).
Por tanto, como se coment anteriormente, en cada etapa y en cada iteracin se perfeccionan los
productos previos que hayan requerido algn cambio, todo eso mientras se intentan conseguir los
objetivos concretos de la fase. De esta forma el ciclo de vida RUP sigue un modelo adaptativo de
desarrollo de software.
De esta forma, el reparto de esfuerzos entre actividades vara de una fase a otra.

Una caracterstica importante del RUP es que todo el proceso est guiado por los casos de uso,
algo que resulta lgico cuando hablamos de modelos incrementales, ya que estn orientados al
usuario y como tal es importante tener siempre presente el esquema de interaccin
usuarios/sistema, los cuales vienen definidos por los casos de uso y sus escenarios.
RUP pretende la obtencin de productos de muy alta calidad (extendindose esta no solo al
cumplimiento de las expectativas del usuario, sino a la obtencin de productos con una deuda
tcnica aceptable), si bien sus caractersticas: varias fases, mltiples iteraciones por fases, pueden
provocar que el proceso de desarrollo sea costoso y que no se adapte a proyectos de pequea
escala, aunque el hecho de que siga un esquema incremental permitira dar flexibilidad en el caso
de que fuera necesario.
Los flujos de trabajo de RUP
Modelado del negocio
Con este flujo de trabajo pretendemos llegar a un mejor entendimiento de la organizacin donde
se va a implantar el producto.

Los objetivos del modelado de negocio son [RSC02]:

Entender la estructura y la dinmica de la organizacin para la cual el sistema va ser desarrollado
(organizacin objetivo).
Entender el problema actual en la organizacin objetivo e identificar potenciales mejoras.
Asegurar que clientes, usuarios finales y desarrolladores tengan un entendimiento comn de la
organizacin objetivo.
Derivar los requisitos del sistema necesarios para apoyar a la organizacin objetivo.
Para lograr estos objetivos, el modelo de negocio describe como desarrollar una visin de la nueva
organizacin, basado en esta visin se definen procesos, roles y responsabilidades de la
organizacin por medio de un modelo de Casos de Uso del negocio y un Modelo de Objetos del
Negocio. Complementario a estos modelos, se desarrollan otras especificaciones tales como un
Glosario.
Requisitos
Este es uno de los flujos de trabajo ms importantes, porque en l se establece qu tiene que
hacer exactamente el sistema que construyamos. En esta lnea los requisitos son el contrato que
se debe cumplir, de modo que los usuarios finales tienen que comprender y aceptar los requisitos
que especifiquemos.
Los objetivos del flujo de datos Requisitos es [RSC02]:
Establecer y mantener un acuerdo entre clientes y otros stakeholders sobre lo que el sistema
podra hacer.
Proveer a los desarrolladores un mejor entendimiento de los requisitos del sistema.
Definir el mbito del sistema.
Proveer una base para la planeacin de los contenidos tcnicos de las iteraciones.
Proveer una base para estimar costos y tiempo de desarrollo del sistema.
Definir una interfaz de usuarios para el sistema, enfocada a las necesidades y metas del usuario.
Los requisitos se dividen en dos grupos. Los requisitos funcionales representan la funcionalidad del
sistema. Se modelan mediante diagramas de Casos de Uso. Los requisitos no funcionales
representan aquellos atributos que debe exhibir el sistema, pero que no son una funcionalidad
especfica. Por ejemplo requisitos de facilidad de uso, fiabilidad, eficiencia, portabilidad, etc.
Para capturar los requisitos es preciso entrevistar a todos los interesados en el proyecto, no slo a
los usuarios finales, y anotar todas sus peticiones. A partir de ellas hay que descubrir lo que
necesitan y expresarlo en forma de requisitos.
En este flujo de trabajo, y como parte de los requisitos de facilidad de uso, se disea la interfaz
grfica de usuario. Para ello habitualmente se construyen prototipos de la interfaz grfica de
usuario que se contrastan con el usuario final.
Anlisis y Diseo
El objetivo de este flujo de trabajo es traducir los requisitos a una especificacin que describe
cmo implementar el sistema.
Los objetivos del anlisis y diseo son [RSC02]:
Transformar los requisitos al diseo del futuro sistema.
Desarrollar una arquitectura para el sistema.

 Adaptar el diseo para que sea consistente con el entorno de implementacin, diseando para el
rendimiento.
El anlisis consiste en obtener una visin del sistema que se preocupa de ver qu hace, de modo
que slo se interesa por los requisitos funcionales. Por otro lado el diseo es un refinamiento del
anlisis que tiene en cuenta los requisitos no funcionales, en definitiva cmo cumple el sistema sus
objetivos.
Al principio de la fase de elaboracin hay que definir una arquitectura candidata: crear un
esquema inicial de la arquitectura del sistema, identificar clases de anlisis y actualizar las
realizaciones de los Casos de Uso con las interacciones de las clases de anlisis. Durante la fase de
elaboracin se va refinando esta arquitectura hasta llegar a su forma definitiva. En cada iteracin
hay que analizar el comportamiento para disear componentes. Adems si el sistema usar una
base de datos, habr que disearla tambin, obteniendo un modelo de datos.
El resultado final ms importante de este flujo de trabajo ser el modelo de diseo. Consiste en
colaboraciones de clases, que pueden ser agregadas en paquetes y subsistemas.
Otro producto importante de este flujo es la documentacin de la arquitectura de software, que
captura varias vistas arquitectnicas del sistema.
Implementacin
En este flujo de trabajo se implementan las clases y objetos en ficheros fuente, binarios,
ejecutables y dems. Adems se deben hacer las pruebas de unidad: cada implementador es
responsable de probar las unidades que produzca. El resultado final de este flujo de trabajo es un
sistema ejecutable.
En cada iteracin habr que hacer lo siguiente:
Planificar qu subsistemas deben ser implementados y en que orden deben ser integrados,
formando el Plan de Integracin.
Cada implementador decide en que orden implementa los elementos del subsistema.
Si encuentra errores de diseo, los notifica.
Se prueban los subsistemas individualmente.
Se integra el sistema siguiendo el plan.
La estructura de todos los elementos implementados forma el modelo de implementacin. La
integracin debe ser incremental, es decir, en cada momento slo se aade un elemento. De este
modo es ms fcil localizar fallos y los componentes se prueban ms a fondo. En fases tempranas
del proceso se pueden implementar prototipos para reducir el riesgo. Su utilidad puede ir desde
ver si el sistema es viable desde el principio, probar tecnologas o disear la interfaz de usuario.
Los prototipos pueden ser exploratorios (desechables) o evolutivos. Estos ltimos llegan a
transformarse en el sistema final.
Pruebas
Este flujo de trabajo es el encargado de evaluar la calidad del producto que estamos
desarrollando, pero no para aceptar o rechazar el producto al final del proceso de desarrollo, sino
que debe ir integrado en todo el ciclo de vida.

Esta disciplina brinda soporte a las otras disciplinas. Sus objetivos son [RSC02]:
Encontrar y documentar defectos en la calidad del software.
Generalmente asesora sobre la calidad del software percibida.
Provee la validacin de los supuestos realizados en el diseo y especificacin de requisitos por
medio de demostraciones concretas.
Verificar las funciones del producto de software segn lo diseado.
Verificar que los requisitos tengan su apropiada implementacin.
Las actividades de este flujo comienzan pronto en el proyecto con el plan de prueba (el cual
contiene informacin sobre los objetivos generales y especficos de las prueba en el proyecto, as
como las estrategias y recursos con que se dotar a esta tarea), o incluso antes con alguna
evaluacin durante la fase de inicio, y continuar durante todo el proyecto.
El desarrollo del flujo de trabajo consistir en planificar que es lo que hay que probar, disear
cmo se va a hacer, implementar lo necesario para llevarlos a cabo, ejecutarlos en los niveles
necesarios y obtener los resultados, de forma que la informacin obtenida nos sirva para ir
refinando el producto a desarrollar.
Despliegue
El objetivo de este flujo de trabajo es producir con xito distribuciones del producto y distribuirlo a
los usuarios. Las actividades implicadas incluyen:
Probar el producto en su entorno de ejecucin final.
Empaquetar el software para su distribucin.
Distribuir el software.
Instalar el software.
Proveer asistencia y ayuda a los usuarios.
Formar a los usuarios y al cuerpo de ventas.
Migrar el software existente o convertir bases de datos.
Este flujo de trabajo se desarrolla con mayor intensidad en la fase de transicin, ya que el
propsito del flujo es asegurar una aceptacin y adaptacin sin complicaciones del software por
parte de los usuarios. Su ejecucin inicia en fases anteriores, para preparar el camino, sobre todo
con actividades de planificacin, en la elaboracin del manual de usuario y tutoriales.

(material complementario)

RUP (Rational Unified Process) vs

Desarrollos agiles
El hecho de RUP siga un ciclo de vida que se puede considerar iterativo e incremental no implica
que se le pueda considerar una metodologa gil y eso que sobre el papel podra considerarse que
verifica los principios del manifiesto gil.
Por ese motivo quien considere que RUP es gil tienen una buena coartada. Se est o no de
acuerdo con que se considere una metodologa gil, lo que no deja dudas es que se trata de una
metodologa de carcter adaptativo, fruto de su vocacin iterativa, incremental y unificada.
Por qu no lo considero una metodologa gil? Principalmente porque el marco de trabajo que
define, implica liberaciones muy tardas en entornos de produccin. Es cierto que en la etapa de
construccin en cada iteracin se pueden liberar versiones en entornos de desarrollo (o incluso
preproduccin) y que en las etapas finales de la construccin se pueden incluso hacer
implantaciones en produccin (si bien esta es la responsabilidad principal de la siguiente, la de
transicin).
Es decir, los usuarios seleccionados para participar en el proyecto de desarrollo de software,
pueden proporcionar feedback en todas las etapas, siendo el ms importante el que pueden
proporcionar cuando estn probando/trabajando con el sistema. Sin embargo, este feedback
cuando resulta realmente valioso es cuando se est haciendo un uso real del sistema en un
entorno de produccin.
Esta caracterstica, junto al hecho de que RUP plantea un marco de trabajo donde el proceso cobra
una importancia especial, hace que la respuesta al cambio no sea gil, ya que principalmente en la
etapa de transicin es donde se itera sobre el producto para ir adaptando el sistema a las
necesidades y expectativas del usuario en aquellos aspectos en los que no se ha acertado en fases
anteriores o como consecuencia de cambios en el negocio que se hayan producido durante el
proceso de desarrollo.
Estas iteraciones se hacen sobre la versin del producto en la que se ha trabajado durante el ciclo
de vida RUP, por lo que el esfuerzo necesario para hacer las modificaciones es mayor y en
consecuencia el tiempo que tarda el usuario en poder disfrutar de ellos en el entorno de
produccin.
Tambin se puede plantear el desarrollo como una secuencia de RUP, de manera que el proceso
de desarrollo sea ms liviano, de esta forma s que se acercara ms a las metodologas giles, sin
embargo, soy de la opinin de que RUP en origen tena un enfoque ms tipo big bang,
orientndose a la entrega de una versin finalista del producto.