Universidad de Costa Rica

Sede Guanacaste
Bachillerato en Informtica Empresarial.
IF7100. Ingeniera de Software.
M.C.I Kenneth Snchez Snchez.





Proceso Unificado Racional
R.U.P




Grupo # 1:
Bustos Muoz Stacy de los ngeles A91109
Cordero Gmez Elvis Michael A81885
Gallegos Barrantes Fabricio A82499




I ciclo 2012

Liberia, 09 de Mayo del 2012
1

Tabla de Contenido
OBJETIVO GENERAL: .................................................................................................................................... 3
OBJETIVOS ESPECFICOS:.............................................................................................................................. 3
METODOLOGA. ........................................................................................................................................... 4
INTRODUCCIN. .......................................................................................................................................... 5
1. PROCESO PARA EL DESARROLLO DE SOFTWARE .................................................................................. 6
1.1. DEFINICIN DE PROCESO ......................................................................................................................... 6
1.2. PROCESO DE DESARROLLO DE SOFTWARE .................................................................................................... 6
1.3. LAS CUATRO P EN EL DESARROLLO DE SOFTWARE: PERSONAS, PROYECTO, PRODUCTO Y PROCESO ....................... 7
2. RESEA HISTRICA DEL PROCESO UNIFICADO RACIONAL (RUP). ........................................................ 9
3. PROCESO UNIFICADO RACIONAL (RUP) ............................................................................................. 12
3.1. INTRODUCCIN AL PROCESO UNIFICADO RACIONAL (RUP) .......................................................................... 12
3.2. PROCESO UNIFICADO RACIONAL (RUP), QU ES? .................................................................................... 13
3.3. DIMENSIONES. .................................................................................................................................... 14
3.4. CARACTERSTICAS. ................................................................................................................................ 15
3.5. LA VIDA DEL PROCESO UNIFICADO RACIONAL. ........................................................................................... 16
3.6. EL PRODUCTO DEL PROCESO UNIFICADO RACIONAL .................................................................................... 16
4. PRINCIPIOS DEL PROCESO UNIFICADO RACIONAL (RUP). ................................................................... 18
4.1. RUP: DIRIGIDO POR CASOS DE USO. ......................................................................................................... 18
4.2. RUP: CENTRADO EN LA ARQUITECTURA .................................................................................................... 20
4.3. RUP: ITERATIVO E INCREMENTAL ............................................................................................................ 22
5. FASES................................................................................................................................................. 25
5.1. FASE DE INICIO .................................................................................................................................... 26
5.2. FASE DE ELABORACIN.......................................................................................................................... 28
5.3. FASE DE CONSTRUCCIN ........................................................................................................................ 30
5.4. FASE DE TRANSICIN ............................................................................................................................ 32
6. FLUJOS DE TRABAJO .......................................................................................................................... 34
6.1. CAPTURA DE REQUISITOS ....................................................................................................................... 34
6.2. ANLISIS ............................................................................................................................................ 35
6.3. DISEO .............................................................................................................................................. 37
6.4. IMPLEMENTACIN ................................................................................................................................ 38
6.5. PRUEBA ............................................................................................................................................. 40
7. ARTEFACTOS ...................................................................................................................................... 42
7.1. CONJUNTOS DE ARTEFACTOS .................................................................................................................. 42
7.2. ARTEFACTOS DE REQUERIMIENTOS .......................................................................................................... 42
7.3. ARTEFACTOS DE ANLISIS ...................................................................................................................... 43
7.4. ARTEFACTOS DE DISEO: ....................................................................................................................... 44
7.5. ARTEFACTOS DE IMPLEMENTACIN .......................................................................................................... 45
2

7.6. ARTEFACTOS DE PRUEBA ........................................................................................................................ 46
CONCLUSIN. ............................................................................................................................................ 48
GLOSARIO. ................................................................................................................................................. 49
BIBLIOGRAFA. ........................................................................................................................................... 50
TABLA DE EVALUACIN. ............................................................................................................................ 51


3

Objetivo General:
Explicar la metodologa de trabajo del Proceso Unificado Racional (RUP), como
proceso de desarrollo de sistemas de software.
Objetivos Especficos:
Describir a manera introductoria, una resea histrica del contexto en el que surgi
la metodologa RUP.
Conceptualizar el Proceso Unificado Racional, sus caractersticas, ciclo de vida, y el
producto final que genera.
Definir los principios que forman los cimientos sobre el que se edific la
metodologa RUP.
Describir las fases de trabajo en las que se subdivide el Proceso Unificado Racional
Describir los flujos de trabajo que interactan a travs de las fases del Proceso
Unificado Racional.
Describir los artefactos que emplea el RUP en cada una de sus fases.

4

Metodologa
La metodologa empleada en el siguiente trabajo con el propsito de cumplir los
objetivos planteados para esta investigacin, es de carcter bibliogrfico, puesto que la
informacin que se tom para la elaboracin de la misma, proviene de libros, tesis
universitarias, entre otros elementos de ndole bibliogrfica.
Al utilizar esta metodologa, se garantiza en gran medida que la informacin que se
presenta dentro de este trabajo de investigacin sea veraz y segura con el fin de sustentar
esta investigacin.


5

Introduccin
La tendencia actual en el software lleva a la construccin de sistemas ms grandes y
ms complejos. Por ello, la utilizacin de metodologas para el desarrollo de aplicaciones
es casi imposible omitirla, debido a la gran necesidad de control de variables que conlleva
el mismo desarrollo, y para la ordenada elaboracin de las aplicaciones, por lo tanto,
seguir metodologas y estndares nos llevan a estar en competitividad en todo momento.
Es de suma importancia conocer el modo como se interrelacionan metodologas con
estndares y herramientas siguiendo un nico propsito, el cual consiste en la elaboracin
de aplicaciones de manera eficiente, ordenada y con el menor nmero de defectos.
Entre los desarrolladores de software, existe la necesidad de desarrollar su trabajo bajo
una forma que les permita coordinar sus actividades de trabajo; se requiere de un proceso
que les permita integrar todas las facetas que presenta el desarrollo de software, una
metodologa comn que les permita tener una gua para ordenar las actividades de un
equipo, que ofrezca criterios tanto para el control de los productos software como las
actividades del proyecto de desarrollo como tal.
El empleo de un proceso bien definido y gestionado en el desarrollo de software, es una
mxima que establecera una diferencia entre proyectos de software que se finiquiten con
un resultado de alta calidad y otros que fracasen. La metodologa RUP nos proporciona un
estndar basado en el Lenguaje Unificado de Modelado (UML), la cual presta de guas para
poder documentar e implementar de una manera eficiente, todas las guas para un buen
desarrollo, todo esto dentro de las respectivas fases en las que se desarrolla.

6

1. Proceso para el desarrollo de software
1.1. Definicin de proceso
Un proceso es un conjunto de actividades o eventos (coordinados u organizados) que se
realizan o suceden (alternativa o simultneamente) bajo ciertas circunstancias con un fin
determinado. Este trmino tiene significados diferentes segn la rama de la ciencia o la
tcnica en que se utilice.
1.2. Proceso de desarrollo de software
Un proceso define quin est haciendo qu, cundo, y cmo alcanzar un determinado
objetivo. En la ingeniera de software el objetivo es construir un producto software o
mejorar uno existente. Un proceso efectivo proporciona normas para el desarrollo eficiente
de software de calidad. Captura y presenta las mejores prcticas que el estado actual de la
tecnologa permite. En consecuencia, reduce el riesgo y hace el proyecto ms predecible. El
efecto global es el fomento de una visin y una cultura comunes.
Es necesario un proceso que sirva como gua para todos los participantes clientes,
usuarios, desarrolladores y directores ejecutivos. No nos sirve ningn proceso antiguo;
necesitamos uno que sea el mejor proceso que la industria pueda reunir en este punto de su
historia. Por ltimo, necesitamos un proceso que est ampliamente disponible de forma que
todos los interesados puedan comprender su papel en el desarrollo en el que se encuentran
implicados.
Ahora bien, dentro del mbito que nos compete desarrollarnos, Qu es un proceso de
desarrollo de software? Veamos;
Proceso de negocio o caso de uso de negocio, de un negocio
de desarrollo de software. Conjunto total de actividades
necesarias para transformar los requisitos de un cliente en un
conjunto consistente de artefactos que representan un producto
software y en un punto posterior en el tiempo para
transformar cambios en dichos requisitos en nuevas versiones
del producto software (Jacobson, Booch, & Rumbaugh, 2000)
A manera de sntesis, un proceso de desarrollo de software es el conjunto de actividades
necesarias para transformar los requisitos de un usuario en un sistema de software.

Figura 1.2.1 Proceso de desarrollo de software.
7

Un proceso de desarrollo de desarrollo de software debera tambin ser capaz de
evolucionar durante muchos aos. Durante esta evolucin debera limitar su alcance, en un
momento del tiempo dado, a las realidades que permitan las tecnologas, herramientas,
personas y patrones de organizacin.
Tecnologas. El proceso debe construirse sobre las tecnologas lenguajes de
programacin, sistemas operativos, computadores, estructuras de red, entornos de
desarrollo, etc.
Herramientas. Los procesos y las herramientas deben desarrollarse en paralelo; las
herramientas son esenciales en el proceso. Dicho de otra forma, un proceso
ampliamente utilizado puede soportar la inversin necesaria para crear las
herramientas que lo soporten.
Personas. Un creador del proceso debe limitar el conjunto de habilidades necesarias
para trabajar en el proceso a las habilidades que los desarrolladores actuales poseen,
o apuntar aquellas que los desarrolladores pueden obtener rpidamente.
Patrones de organizacin. Aunque los desarrolladores de software no pueden ser
expertos tan independientes como los msicos de una orquesta, estn muy lejos de
los trabajadores autmatas en los cuales Frederick W. Taylor baso su direccin
cientfica hace cien aos. El creador del proceso debe adaptar el proceso a las
realidades del momento hechos como las empresas virtuales; el trabajo a distancia
a travs de lneas de alta velocidad; la mezcla (en empresas pequeas) de socios de
la empresa, empleados asalariados, trabajadores por obra y subcontratas de
outsourcing; y la prolongada escasez.
Los ingenieros del proceso deben equilibrar estos cuatro conjuntos de circunstancias.
Adems, el equilibrio debe estar presente no solo ahora, sino tambin en el futuro; el
creador del proceso debe disearlo de forma que pueda evolucionar, de igual forma que
el desarrollador de software intenta desarrollar un sistema que no slo funciona este
ao, sino que evoluciona con xito los aos venideros. Un proceso debe madurar
durante varios aos antes de alcanzar el nivel de estabilidad y madurez que le permitir
resistir a los rigores del desarrollo de productos comerciales, manteniendo a la vez, un
nivel razonable de riesgo en su utilizacin. El desarrollo de un producto nuevo es
bastante arriesgado en s mismo como para aadirle el riesgo de un proceso que est
poco validado por la experiencia de su uso. En estas circunstancias un proceso puede
ser estable. Sin este equilibrio de tecnologas, herramientas, personas y organizacin, el
uso del proceso sera bastante arriesgado.
1.3. Las cuatro P en el desarrollo de software: personas, proyecto,
producto y proceso
El resultado final de un proyecto software es un producto que toma forma durante su
desarrollo gracias a la intervencin de muchos tipos distintos de personas. Un proceso de
8

desarrollo de software gua los esfuerzos de las personas implicadas en el proyecto, a modo
de plantilla que explica los pasos necesarios para terminar el proyecto. Tpicamente el
proceso est automatizado por medio de una herramienta o de un conjunto de ellas. Vase
la figura 1.3.1.
A lo largo de esta investigacin los trminos personas, proyecto, producto, proceso, y
herramientas, que definimos a continuacin:
Personas. Los principales autores de un proyecto software son los arquitectos,
desarrolladores, ingenieros de prueba, y el personal de gestin que les da soporte,
adems de los usuarios, clientes, y otros interesados.
Proyecto. Elemento organizativo a travs del cual se gestiona el desarrollo de
software. El resultado de un proyecto es una versin de un producto.
Producto. Artefactos que se crean durante la vida del proyecto, como los modelos,
cdigo fuente, ejecutables y documentacin.
Proceso. Un proceso de ingeniera de software es una definicin del conjunto
completo de actividades necesarias para transformar los requisitos de un usuario en
producto. Un proceso es una plantilla para crear proyectos.
Herramientas. Software que se utiliza para automatizar las actividades definidas en
el proceso.

Figura 1.3.1 Las cuatro P en el desarrollo de software.

9

2. Resea histrica del Proceso Unificado Racional (RUP)
El Proceso Unificado est equilibrado por ser el producto final de tres dcadas de
desarrollo de uso prctico. Su desarrollo como producto sigue un camino desde el proceso
Objectory (Primera publicacin en 1987) pasando por el proceso Objectory de Rational
(Publicado en 1997) hasta el Proceso Unificado de Rational (Publicado en 1998). Su
desarrollo ha recibido influencias de muchas fuentes. No se pretende tratar de identificar
todas (realmente no sabemos cules son todas), trabajo que dejamos a la investigacin de
los arquelogos del software.

Figura 2.1 El desarrollo del Proceso Unificado.
10

Durante la dcada de 1980 y al principio de la dcada siguiente, los mtodos y
lenguajes de programacin orientados a objetos (OO) obtuvieron una amplia difusin entre
la comunidad de la ingeniera del software. Durante el mismo periodo se propuso una
amplia variedad de anlisis y diseo orientados a objetos (AOO y DOO) y se introdujo un
modelo de proceso orientado a objetos de propsito general. Al igual que la mayora de los
paradigmas "nuevos" para la ingeniera del software. Los seguidores de cada uno de los
mtodos de AOO y DOO argumentaban acerca de cul de ellos era el mejor, pero ningn
mtodo o lenguaje domin la escena de la ingeniera del software.
Al principio de la dcada de 1990, James Rumbaugh, Grady Booch e Ivar Jacobson
comenzaron a trabajar en un "mtodo unificado" que combinara las mejores caractersticas
de cada uno de sus mtodos individuales y adoptara caractersticas adicionales que
propusieran otros expertos. El resultado fue el lenguaje de modelado unificado (UML,por
sus siglas en ingls) -que contiene una notacin robusta para el modelado y el desarrollo de
sistemas OO-. Para 1997, el UML se convirti en un estndar de la industria para el
desarrollo de software orientado a objetos. Al mismo tiempo, Rational Corporation y otras
firmas desarrollaron herramientas automticas para apoyar los mtodos del UML.
El UML proporciona la tecnologa necesaria para apoyar la prctica de la ingeniera del
software orientada a objetos, pero no provee el marco de trabajo del proceso que gue a los
equipos en la aplicacin de la tecnologa. En los aos siguientes, Jacobson, Rumbaugh y
Booch desarrollaron el proceso unificado, un marco de trabajo para la ingeniera del
software orientada a objetos, mediante la utilizacin del UML. En la actualidad, el proceso
unificado y el UML se emplean de forma amplia en proyectos OO de todos los tipos. El
modelo iterativo e incremental que propone el RUP puede y debe adaptarse para satisfacer
necesidades de proyecto especficas.
Como consecuencia de la aplicacin del UML se puede producir un arreglo de
productos de trabajo (por ejemplo, modelos y documentos). Sin embargo, stos los reducen
los ingenieros de software para lograr que el desarrollo sea ms gil y reactivo ante el
cambio.
11


Figura 2.2 Lnea de tiempo de los acontecimientos que dieron paso a la aparicin del Proceso Unificado Racional.
1967
SDL se
convierte en
un estndar
1987
Proceso
Objectory
1.0
1995
Unin entre
Jacobson,
Booch y
Rumbaugh
para
desarrollar
UML
1996
Proceso
Objectory
de Rational
4.1
1998
Proceso
Unificado de
Rational 5.0
1999
Proceso
Unificado de
Rational 5.5
2000
Proceso
Unificado de
Rational
2000
12

3. Proceso Unificado Racional (RUP)
La tendencia actual en el software lleva a la construccin de sistemas ms grandes y
ms complejos. Esto es debido en parte al hecho de que los computadores son ms potentes
cada ao, y los usuarios, por tanto, esperan ms de ellos. Esta tendencia tambin se ha visto
afectada por el uso creciente de Internet para el intercambio de todo tipo de informacin
de texto sin formato, fotos, diagramas y multimedia. Nuestro apetito de software an ms
sofisticado crece a medida que vemos cmo pueden mejorarse los productos de una versin
a otra. Queremos un software que est mejor adaptado a nuestras necesidades, pero esto, a
su vez, simplemente hace el software ms complejo. En breve querremos ms.
Tambin lo querremos ms rpido. El tiempo de salida al mercado es otro conductor
importante.
Conseguirlo, sin embargo, es difcil. Nuestra demanda de software potente y complejo
no se corresponde con cmo se desarrolla el software. Hoy, la mayora de la gente
desarrolla software mediante los mismos mtodos que llevan utilizndose desde hace ms
de 25 aos. Esto es un problema. A menos que renovemos nuestros mtodos no podremos
cumplir con el objetivo de desarrollar el software complejo que se necesita actualmente.
El problema del software se reduce a la dificultad que afrontan los desarrolladores para
coordinar las mltiples cadenas de trabajo de un gran proyecto de software. La comunidad
de desarrolladores necesita una forma coordinada de trabajar. Necesita un proceso que
integre las mltiples facetas del desarrollo. Necesita un mtodo comn, un proceso que:
Proporcione una gua para ordenar las actividades de un equipo.
Dirija las tareas de cada desarrollador por separado y del equipo como un todo.
Especifique los artefactos que deben desarrollarse.
Ofrezca criterios para el control y la mediacin de los productos y actividades del
proyecto.
La presencia de un proceso bien definido y bien gestionado es una diferencia esencial
entre proyectos hiperproductivos y otros que fracasan. El Proceso Unificado Racional
(RUP) el resultado de ms de 30 aos de experiencia es una solucin al problema del
software. Este apartado proporciona una visin general del Proceso Unificado Racional
completo.
3.1. I ntroduccin al Proceso Unificado Racional (RUP)
De manera informal, un proceso de desarrollo de software describe un enfoque para la
construccin, desarrollo y, posiblemente, mantenimiento del software. El Proceso
Unificado se ha convertido en un proceso de desarrollo de software de gran xito para la
construccin de sistemas orientados a objetos. En particular, se ha adoptado ampliamente el
13

Proceso Unificado de Rational o RUP (Rational Unified Process), un refinamiento
detallado del Proceso Unificado.
El Proceso Unificado (UP) combina las prcticas comnmente aceptadas como buenas
prcticas, tales como ciclo de vida iterativo y desarrollo dirigido por el riesgo, en una
descripcin consistente y bien documentada. Es un marco de trabajo genrico que puede
especializarse para una gran variedad de sistemas software, para diferentes reas de
aplicacin, diferentes tipos de organizaciones, diferentes niveles de aptitud y diferentes
tamaos de proyecto.
El Proceso Unificado est basado en componentes, lo cual quiere decir que el sistema
software en construccin est formado por componentes software interconectados a travs
de interfaces bien definidas.
El Proceso Unificado utiliza el Lenguaje Unificado de Modelado (Unified Modeling
Language, UML) para preparar todos los esquemas de un sistema software. De hecho,
UML es una parte esencial del Proceso Unificado sus desarrollos fueron paralelos.
No obstante, los verdaderos aspectos definitorios del Proceso Unificado se resume en
tres frases clave dirigido por casos de uso, centrado en la arquitectura, e iterativo e
incremental.
3.2. Proceso Unificado Racional (RUP), Qu es?
Las siglas RUP en ingles significa Rational Unified Process (Proceso Unificado de
Rational) es un producto del proceso de ingeniera de software que proporciona un enfoque
disciplinado para asignar tareas y responsabilidades dentro de una organizacin del
desarrollo. Su meta es asegurar la produccin del software de alta calidad que resuelve las
necesidades de los usuarios dentro de un presupuesto y tiempo establecidos.
El Proceso Unificado Racional (RUP), desde una perspectiva ms tcnica y un anlisis
ms profundo con relacin en sus bases y principios se puede definir de la siguiente
manera, veamos;
Proceso de desarrollo de software basado en el Lenguaje
Unificado de Modelado, y que es iterativo, centrado en la
arquitectura y dirigido por los casos de uso y los riesgos.
Proceso que se organiza en cuatro fases: inicio, elaboracin,
construccin y transicin, y que se estructura en torno a cinco
flujos de trabajo fundamentales: recopilacin de requisitos,
anlisis, diseo, implementacin y pruebas. Proceso que se
describe en trminos de un modelo de negocio, el cual est a su
vez estructurado en funcin de tres bloques de construccin
14

primordiales: trabajadores, actividades y artefactos.
(Jacobson, Booch, & Rumbaugh, 2000)
El RUP no es un proceso apropiado para todos los tipos de desarrollo sino que
representa una nueva generacin de procesos genricos. Las innovaciones ms importantes
son la separacin de fases y los flujos de trabajo, y el reconocimiento de que la utilizacin
de software en un entorno del usuario es parte del proceso. Las fases son dinmicas y tienen
objetivos. Los flujos de trabajo son estticos y son actividades tcnicas que no estn
asociadas con fases nicas sino que pueden utilizarse durante el desarrollo para alcanzar los
objetivos de cada fase.
3.3. Dimensiones
En funcin de sus fases y flujos de trabajo que analizaremos posteriormente dentro de
este documento, el Proceso Unificado Racional presenta dos dimensiones:
El eje horizontal representa tiempo y demuestra los aspectos del ciclo de vida del
proceso.
El eje vertical representa las disciplinas, que agrupan actividades definidas
lgicamente por la naturaleza.
La primera dimensin representa el aspecto dinmico del proceso y se expresa en
trminos de fases, de iteraciones, y la finalizacin de las fases. La segunda dimensin
representa el aspecto esttico del proceso: cmo se describe en trminos de componentes
de proceso, las disciplinas, las actividades, los flujos de trabajo, los artefactos, y los roles.
En la figura 3.3.1 se puede observar como vara el nfasis de cada disciplina en un
cierto plazo en el tiempo, y durante cada una de las fases. Por ejemplo, en iteraciones
tempranas, pasamos ms tiempo en requerimientos, y en las ltimas iteraciones pasamos
ms tiempo en poner en prctica la realizacin del proyecto en s.
15


Figura 3.3.1 Dimensiones del Proceso Unificado Racional
3.4. Caractersticas
El Proceso Unificado Racional se define y caracteriza por tres principios claves y
fundamentales: iterativo e incremental, dirigido por casos de uso y centrado en la
arquitectura (a los cuales nos referiremos de manera ms amplia en el punto cuatro de este
documento), no obstante, aunado a estos principios bsicos, el RUP presenta caractersticas
que lo definen an ms como proceso de desarrollo de software:
Forma disciplinada de asignar tareas y responsabilidades (quin hace qu, cundo y
cmo)
Pretende implementar las mejores prcticas en Ingeniera de Software
Desarrollo iterativo
Administracin de requisitos
Uso de arquitectura basada en componentes
Control de cambios
Modelado visual del software
Verificacin de la calidad del software
Cabe destacar que el RUP Incluye artefactos (que son los productos tangibles del
proceso como por ejemplo, el modelo de casos de uso, el cdigo fuente, etc.) y roles (papel
que desempea una persona en un determinado momento, una persona puede desempear
distintos roles a lo largo del proceso).
16

3.5. La vida del Proceso Unificado Racional
El Proceso Unificado Racional se repite a lo largo de una serie de ciclos que
constituyen la vida de un sistema, como se muestra en la figura 3.5.1. Cada ciclo concluye
con una versin del producto para los clientes
Cada ciclo consta de cuatro fases: inicio, elaboracin, construccin y transicin (las
cuales abordaremos en el punto 5 de este documento). Cada fase se subdivide a su vez en
iteraciones, como se ha dicho anteriormente. Vase la figura 3.5.2.

Figura 3.5.1 La vida de un proceso consta de ciclos desde su nacimiento hasta su muerte.



Figura 3.5.2 Un ciclo con sus fases e iteraciones.
3.6. El Producto del Proceso Unificado Racional
En el contexto del Proceso Unificado Racional, el producto que se obtiene es un sistema
software. El trmino producto aqu hace referencia al sistema entero y no slo al cdigo
que se entrega.
17

Cada ciclo produce una nueva versin del sistema, y cada versin es un producto
preparado para su entrega. Consta de un cuerpo de cdigo fuente incluido en componentes
que puede compilarse y ejecutarse, adems de manuales y otros productos asociados. Sin
embargo, el producto terminado no slo debe ajustarse a las necesidades de los usuarios,
sino tambin a las de todos los interesados, es decir, toda la gente que trabajar con el
producto. El producto software debera ser algo ms que el cdigo mquina que se ejecuta.
El producto terminado incluye los requisitos, casos de uso, especificaciones no
funcionales y casos de prueba. Incluye el modelo de la arquitectura y el modelo visual
artefactos modelados con el Lenguaje Unificado de Modelado. De hecho, incluye todos los
elementos que ya se han mencionado, debido a que son esos elementos los que permiten a
los interesados clientes, usuarios, analistas, diseadores, programadores, ingenieros de
prueba, y directores especificar, disear, implementar, probar y utilizar un sistema. Es
ms son esos elementos los que permiten a los usuarios utilizar y modificar el sistema de
generacin en generacin.
Aunque los componentes ejecutables sean los artefactos ms importantes desde la
perspectiva del usuario, no son suficientes por s solos. Esto se debe a que el entorno
cambia. Se mejoran los sistemas operativos, los sistemas de bases de datos y las mquinas
que los soportan. A medida que el objetivo del sistema se comprende mejor, los propios
requisitos pueden cambiar. De hecho, el que los requisitos cambien es una de las constantes
del desarrollo de software. Al final los desarrolladores deben afrontar un nuevo ciclo, y los
directores deben financiarlo. Para llevar a cabo el siguiente ciclo de manera eficiente, los
desarrolladores necesitan todas las representaciones del producto software.

18

4. Principios del Proceso Unificado Racional (RUP)
En definitiva, el RUP es una metodologa de desarrollo de software que intenta
integrar todos los aspectos a tener en cuenta durante todo el ciclo de vida del
software, con el objetivo de hacer abarcables tanto pequeos como grandes proyectos
software. Adems proporciona herramientas para todos los pasos del desarrollo as
como documentacin en lnea para sus clientes.
El Proceso Unificado Racional est fundamentado en tres principios clave, mismos, que
lo dotan de una estructura y metodologa robusta, capaz de satisfacer las necesidades de
organizacin y coordinacin de las actividades que competen en el desarrollo de software
de alta calidad. Estos principios son:
Dirigido por casos de uso. El objetivo del Proceso Unificado Racional es guiar a los
desarrolladores en la implementacin y distribucin eficiente de sistemas que se
ajusten a las necesidades de los clientes. La eficiencia se mide en trminos de coste,
calidad, y tiempo de desarrollo. El paso desde la determinacin de las necesidades
del cliente hasta la implementacin no es trivial. En primer lugar, las necesidades
del cliente no son fciles de discernir. Esto nos obliga a que tengamos algn modo
de capturar las necesidades de usuario de forma que puedan comunicarse fcilmente
a todas las personas implicadas en el proyecto. Despus, debemos ser capaces de
disear una implementacin funcional que se ajuste a esas necesidades. Por ltimo,
debemos verificar que las necesidades del cliente se han cumplido mediante la
prueba del sistema. Debido a esta complejidad, el proceso se describe como una
serie de flujos de trabajo que construyen el sistema gradualmente.
Centrado en la arquitectura.
Iterativo e incremental.
Estos principios sientan las bases de toda gestin de actividades que se coordine en los
equipos de trabajo de desarrollo de software dentro del marco del Proceso Unificado
Racional. En los siguientes puntos de este apartado se analizarn y explicarn cada uno de
estos principios de forma ms amplia.
4.1. RUP: dirigido por casos de uso
Con esto se refiere a la utilizacin de los Casos de Uso para el desenvolvimiento y
desarrollo de las disciplinas con los artefactos, roles y actividades necesarias. Los Casos
de Uso son la base para la implementacin de las fases y disciplinas del RUP. Un Caso de
Uso es una secuencia de pasos a seguir para la realizacin de un fin o propsito, y se
relaciona directamente con los requerimientos, ya que un Caso de Uso es la secuencia de
pasos que conlleva la realizacin e implementacin de un Requerimiento planteado por el
Cliente.
19

Un sistema software ve la luz para dar servicio a sus usuarios. Por tanto, para construir
un sistema con xito debemos conocer lo que sus futuros usuarios necesitan y desean.
El trmino usuario no slo hace referencia a usuarios humanos, sino a otros sistemas.
En este sentido, el trmino usuario representa alguien o algo (como otro sistema fuera del
sistema en consideracin) que interacta con el sistema que estamos desarrollando. Un
ejemplo de interaccin sera una persona que utiliza un cajero automtico. l (o ella)
insertar una tarjeta de plstico, responde a las preguntas que le hace la mquina en su
pantalla, y recibe una suma de dinero. En respuesta a la tarjeta del usuario y a sus
contestaciones, el sistema lleva a cabo una secuencia de acciones que proporcionan al
usuario un resultado importante, en este caso la retirada del efectivo.
Una interaccin de este tipo es un caso de uso. Un caso de uso es un fragmento de
funcionalidad del sistema que proporciona al usuario un resultado importante. Los casos de
uso juntos constituyen el modelo de casos de uso, el cual describe la funcionalidad del
sistema. Puede decirse que una especificacin funcional contesta a la pregunta Qu debe
hacer el sistema? La estrategia de los casos de uso puede describirse tres palabras al final de
esta pregunta para cada usuario? Estas tres palabras albergan una implicacin
importante. Nos fuerza a pensar en trminos de importancia para el usuario y no slo en
trminos de funciones que sera bueno tener. Sin embargo los casos de uso no son slo una
herramienta para especificar los requisitos de un sistema. Tambin guan su diseo,
implementacin y prueba; esto es guan el proceso de desarrollo. Basndose en el modelo
de casos de uso, los desarrolladores crean una serie de modelos de diseo e implementacin
que llevan a cabo los casos de uso. Los ingenieros de prueba, prueban la implementacin
para garantizar que los componentes del modelo de implementacin implementan
correctamente los casos de uso. De este modo los casos de uso no slo inician el proceso de
desarrollo sino que le proporcionan un hilo conductor. Dirigido por casos de uso quiere
decir que el proceso de desarrollo sigue un hilo avanza a travs de una serie de flujos de
trabajo que parten de los casos de uso. Los casos de uso se especifican, se disean, y los
casos de uso finales son la fuente a partir de la cual los ingenieros de prueba construyen sus
casos de prueba.
Los casos de uso han sido adoptados casi universalmente para la captura de requisitos
de sistemas software en general, y de sistemas basados en componentes en particular, pero
los casos de uso son mucho ms que una herramienta para capturar requisitos como ya se
ha visto. Dirigen el proceso de desarrollo en su totalidad. Los casos de uso son la entrada
fundamental cuando se identifican y especifican clases, casos de prueba, subsistemas e
interfaces, y cuando se planifican las iteraciones del desarrollo y la integracin del sistema.
Para cada iteracin, nos gua a travs del conjunto completo de flujos de trabajo, desde la
captura de requisitos, pasando por el anlisis, diseo e implementacin, hasta la prueba, en
lazando estos diferentes flujos de trabajo.
20

La captura de requisitos tiene como objetivos: encontrar los verdaderos requisitos y
representarlos de un modo adecuado para los usuarios, clientes y desarrolladores.
Entendemos por verdaderos requisitos aquellos que cuando se implementen aadirn el
valor esperado para los usuarios. Con representarlos de un modo adecuado para los
usuarios, clientes y desarrolladores queremos decir en concreto que la descripcin
obtenida de los requisitos debe ser comprensible por usuarios y clientes
Ahora bien, Por qu casos de uso?, veamos;
Existen varios motivos por los cuales los casos de uso son buenos, se han hecho
populares y se han adoptado universalmente. Las dos razones fundamentales son:
Proporcionan un medio sistemtico e intuitivo de capturar requisitos funcionales
centrndose en el valor aadido para el usuario.
Dirigen todo el proceso de desarrollo debido a que la mayora de las actividades
como el anlisis, diseo y prueba se llevan a cabo partiendo de los casos de uso. El
diseo y la prueba pueden tambin planificarse y coordinarse en trminos de casos
de uso. Esta caracterstica es an ms evidente cuando la arquitectura se ha
estabilizado en el proyecto, despus del primer conjunto de iteraciones.
Aunque es cierto que los casos de uso guan el proceso, no se desarrollan aisladamente.
Se desarrollan a la vez que la arquitectura del sistema. Es decir, los casos de uso guan la
arquitectura del sistema y sta influye en la seleccin de casos de uso. Por ende, tanto la
arquitectura del sistema como los casos de uso maduran segn avanza el ciclo de
desarrollo.
4.2. RUP: centrado en la arquitectura
Los casos de uso solamente no son suficientes. Se necesitan ms cosas para conseguir
un sistema de trabajo. Esas cosas son la arquitectura. Podemos pensar que la arquitectura
de un sistema es la visin comn en la que todos los empleados (desarrolladores y otros
usuarios) deben estar de acuerdo, o como poco, deben aceptar. La arquitectura nos da una
clara perspectiva del sistema completo, necesaria para controlar el desarrollo.
El papel de la arquitectura de software es parecido al papel que juega la arquitectura en
la construccin de edificios. El edificio se contempla desde varios puntos de vista:
estructura, servicios, conduccin de la calefaccin, fontanera, electricidad, etc. Esto
permite a un constructor ver una imagen completa antes de que comience la construccin.
Anlogamente, la arquitectura en un sistema software se describe mediante diferentes vistas
del sistema en construccin.
Necesitamos una arquitectura, bien. Pero, qu quiere decir exactamente arquitectura
de sistemas software? El concepto de arquitectura software incluye los aspectos estticos y
21

dinmicos ms significativos del sistema. La arquitectura surge a las necesidades de la
empresa, como la perciben los usuarios y los inversores, y se refleja en los casos de uso. Sin
embargo, tambin se ve influida por muchos otros factores, como la plataforma en la que
tiene que funcionar el software (arquitectura hardware, sistema operativo, sistema de
gestin de base de datos, protocolos para comunicaciones en red), los bloques de
construccin reutilizables de que se dispone (por ejemplo un marco de trabajo para
interfaces grficas de usuario), consideraciones de implantacin, sistemas heredados, y
requisitos no funcionales (por ejemplo, rendimiento, fiabilidad). La arquitectura es una
vista del diseo completo con las caractersticas ms importantes resaltadas, dejando los
detalles de lado. Debido a que lo que es significativo depende en parte de una valoracin,
que a su vez, se adquiere con la experiencia, el valor de una arquitectura depende de las
personas que se hayan responsabilizado de su creacin. No obstante, el proceso ayuda al
arquitecto a centrarse en los objetivos adecuados, como la comprensibilidad, la capacidad
de adaptacin al cambio, y la reutilizacin.
Cmo se relacionan los casos de uso y la arquitectura? Cada producto tiene tanto una
funcin como una forma. Ninguna es suficiente por s misma. Estas dos fuerzas deben
equilibrarse para obtener un producto con xito. En esta situacin la funcin corresponde a
los casos de uso y la forma a la arquitectura. Debe haber interaccin entre los casos de uso
y la arquitectura. Es un problema del tipo el huevo y la gallina. Por un lado los casos de
uso deben encajar en la arquitectura cuando se llevan a cabo. Por otro lado, la arquitectura
debe permitir el desarrollo de todos los casos de uso requeridos. Ahora y en el futuro. En
realidad tanto la arquitectura como los casos de uso deben evolucionar en paralelo.
Por tanto, los arquitectos moldean el sistema para darle forma. Es esta forma, la
arquitectura, la que debe disearse para permitir que el sistema evolucione, no slo en su
desarrollo inicial, sino tambin a lo largo de las futuras generaciones. Para encontrar esa
forma, los arquitectos deben trabajar sobre la comprensin general de las funciones clave,
es decir, sobre los casos de uso claves del sistema. Estos casos de uso clave pueden suponer
solamente entre el 5 y el 10 por ciento de todos los casos de uso, pero son los significativos,
los que constituyen las funciones fundamentales del sistema. De manera resumida podemos
decir que el arquitecto:
Crea un esquema en borrador de la arquitectura, comenzando por la parte de la
arquitectura que no es especfica de los casos de uso (por ejemplo, la plataforma).
Aunque esta parte de la arquitectura es independiente de los casos de uso, el
arquitecto debe poseer una comprensin general de los casos de uso antes de
comenzar la creacin del esquema arquitectnico.
A continuacin, el arquitecto trabaja con un subconjunto de los casos de uso
especificados, con aquellos que representen las funciones clave del sistema en
desarrollo. Cada caso de uso se especifica en detalle y se realiza en trmino de
subsistemas, clases, y componentes.
22

A medida que los casos de uso se especifican y maduran, se descubre ms de la
arquitectura. Esto a su vez, lleva a la maduracin de ms casos de uso.
Este proceso contina hasta que se considere que la arquitectura es estable.
Ahora bien, Por qu se debe centrar en la arquitectura?, veamos;
El saber identificar que hace un sistema, casi siempre con poca o ninguna
documentacin, y que cdigo pueden reutilizar los desarrolladores, aade complejidad al
desarrollo.
Se necesita una arquitectura para:
Comprender el sistema.
Organizar el desarrollo.
Fomentar la reutilizacin.
Hacer evolucionar el sistema.
Los casos de uso dirigen la arquitectura para hacer que el sistema proporcione la
funcionalidad y usos deseados, alcanzando a la vez objetivos de rendimiento razonables.
Una arquitectura debe ser completa, pero tambin debe ser suficientemente flexible como
para incorporar nuevas funciones, y debe soportar la reutilizacin del software existente.

4.3. RUP: I terativo e incremental
Un proceso de desarrollo de software debe tener una secuencia de hitos claramente
articulados para ser eficaz, que proporcionen a los directores y al resto del equipo del
proyecto los criterios que necesitan para autorizar el paso de una fase a la siguiente dentro
del ciclo del producto.
Dentro de cada fase, el proceso pasa por iteraciones e incrementos que nos conducen a
esos criterios.
El desarrollo de un producto software comercial supone un gran esfuerzo que puede
durar entre varios meses hasta posiblemente un ao o ms. Es prctico dividir el trabajo en
partes ms pequeas o miniproyectos. Cada miniproyecto es una iteracin que resulta en un
incremento. Las iteraciones hacen referencia a pasos en el flujo de trabajo, y los
incrementos, al crecimiento del producto. Para una efectividad mxima, las iteraciones
deben estar controladas; esto es, deben seleccionarse y ejecutarse de una forma planificada.
Es por esto por lo que son mini-proyectos.
Este tercer principio proporciona la estrategia para desarrollar un producto software en
pasos pequeos manejables:
23

Planificar un poco.
Especificar, disear, e implementar un poco.
Integrar, probar, y ejecutar un poco cada iteracin.
Si estamos contentos con un paso, continuamos con el siguiente. Entre cada paso,
obtenemos retroalimentacin que nos permite ajustar nuestros objetivos para el siguiente
paso. Despus se da el siguiente paso, y despus otro. Cuando se han dado todos los pasos
que habamos planificado, tenemos un producto desarrollado que podemos distribuir a
nuestros clientes y usuarios.
Las iteraciones en las primeras fases tratan en su mayor parte con la determinacin del
mbito del proyecto, la eliminacin de los riesgos crticos, y la creacin de la lnea base de
la arquitectura. Despus, a medida que avanzamos a lo largo del proyecto y vamos
reduciendo gradualmente los riesgos restantes e implementando los componentes, la forma
de las iteraciones cambia, dando incrementos como resultados.
Un proyecto de desarrollo software transforma una delta (un cambio) de los requisitos
de usuario en una delta del producto software. Con el mtodo de desarrollo iterativo e
incremental esta adaptacin de los cambios se realiza poco a poco. Dicho de otra forma,
dividimos el proyecto en un nmero de miniproyectos, siendo cada uno de ellos una
iteracin. Cada iteracin tiene todo lo que tiene un proyecto de desarrollo de software:
planificacin, desarrollo en una serie de flujos de trabajo (requisitos, anlisis y diseo,
implementacin y prueba), y una preparacin para la entrega.
Pero una iteracin no es una entidad completamente independiente es una etapa dentro
de un proyecto, y se ve fuertemente condicionada por ello. Decimos que es un miniproyecto
porque no es por s misma algo que nuestros usuarios nos hayan pedido que hagamos.
Adems, cada uno de estos miniproyectos se parece al antiguo ciclo de vida en cascada
dado que se desarrolla a travs de actividades en cascada. Podramos llamar una
minicascada a cada iteracin.
El ciclo de vida iterativo produce resultados tangibles en forma de versiones internas
(aunque preliminares), y cada una de ellas aporta un incremento y demuestra la reduccin
de los riesgos con los que se relaciona. Estas versiones pueden presentarse a los clientes y
usuarios en cuyo caso proporcionan una retroalimentacin valiosa para la validacin del
trabajo.
Los jefes de proyecto tratarn de ordenar las iteraciones para conseguir una va directa
en la cual las primeras iteraciones proporcionen la base del conocimiento para las
siguientes. Las primeras iteraciones del proyecto consiguen incrementar la comprensin de
los requisitos, el problema, los riesgos, y el dominio de la solucin, mientras que las
restantes aaden incrementos que al final conformarn la versin externa, es decir el
producto para el cliente. El xito fundamental para los jefes de proyecto es conseguir
24

una serie de iteraciones que siempre avanzan; es decir, que nunca hay que volver dos o tres
iteraciones atrs para corregir el modelo debido a algo que hemos aprendido en la ltima
iteracin. No queremos escalar una montaa de nieve que se funde, dando dos pasos
adelante y resbalando uno hacia atrs.
En resumen, un ciclo de vida se compone de una secuencia de iteraciones. Algunas de
ellas, especialmente las primeras, nos ayudan a comprender los riesgos, determinar a
viabilidad, construir el ncleo interno del software, y realizar el anlisis de negocio. Otras,
en especial las ltimas, incorporan incrementos hasta conseguir un producto preparado para
su entrega.
Las iteraciones ayudan a la direccin a planificar, a organizar, a hacer el seguimiento y
a controlar el proyecto. Las iteraciones se organizan dentro de las cuatro fases (que
desarrollaremos ms adelante en el punto 5), cada una de ellas con necesidades concretas
de personal, financiacin y planificacin, y con sus propios criterios de comienzo y fin. Al
comienzo de cada fase, la direccin puede decidir cmo llevarla a cabo, los resultados que
deben entregarse, y los riesgos que deben reducirse.
Ahora bien, por qu un desarrollo iterativo e incremental? Veamos;
En dos palabras: para obtener un mejor software. Dicho con unas cuantas palabras ms,
para cumplir los hitos principales y secundarios con los cuales controlaremos el desarrollo.
Y dicho con algunas palabras ms:
Para tomar las riendas de los riesgos crticos y significativos desde el principio.
Para poner en marcha una arquitectura que gue el desarrollo del software.
Para proporcionar un marco de trabajo que gestione de mejor forma los inevitables
cambios en los requisitos y en otros aspectos.
Para construir el sistema a lo largo del tiempo en lugar de hacerlo de una sola vez
cerca del final, cuando el cambiar algo se ha vuelto costoso.
Para proporcionar un proceso de desarrollo a travs del cual el personal puede
trabajar de manera ms eficaz.
Y finalmente, Por qu RUP se edifica sobre los cimientos de estos tres principios
fundamentales?
Estos conceptos los de desarrollo dirigido por los casos de uso, centrado en la
arquitectura, iterativo e incremental son de igual importancia. La arquitectura
proporciona la estructura sobre la cual guiar las iteraciones, mientras que los casos de uso
definen los objetivos y dirigen el trabajo de cada iteracin. La eliminacin de una de las
tres ideas reducira drsticamente el valor del Proceso Unificado Racional. Es como un
taburete de tres patas. Sin una de ellas el taburete se cae.
25

5. Fases
Cada ciclo se desarrolla a lo largo del tiempo. Este tiempo, a su vez, se divide en cuatro
fases, como se muestra en la figura 5.1. A travs de una secuencia de modelos, los
implicados visualizan lo que est sucediendo en esas fases. Dentro de cada fase, los
directores o los desarrolladores pueden descomponer adicionalmente el trabajo en
iteraciones con sus incrementos resultantes. Cada fase termina con un hito. Cada hito se
determina por la disponibilidad de un conjunto de artefactos; es decir, ciertos modelos o
documentos han sido desarrollados hasta alcanzar un estado predefinido.
Los hitos tienen muchos objetivos. El ms crtico es que los directores deben de tomar
ciertas decisiones cruciales antes de que el trabajo pueda continuar con la siguiente fase.
Los hitos tambin permiten a la direccin, y a los mismos desarrolladores, controlar el
progreso del trabajo segn pasa por esos cuatro puntos clave. Al final, se obtiene un
conjunto de datos a partir del seguimiento del tiempo y esfuerzo consumido en cada fase.
Estos datos son tiles en la estimacin del tiempo y los recursos humanos para otros
proyectos, en la asignacin de los recursos durante el tiempo que dura el proyecto, y en el
control del progreso contrastado con las planificaciones.
La figura 5.1 muestra en la columna izquierda los flujos de trabajo (que sern
explicados en el punto 6 de este documento) requisitos, anlisis, diseo, implementacin y
prueba. Las curvas son una aproximacin (no deben considerarse muy literalmente) de
hasta dnde se llevan a cabo los flujos de trabajo en cada fase. Recurdese que cada fase se
divide normalmente en iteraciones o mini proyectos. Una iteracin tpica pasa por los
cinco flujos de trabajo.
26



Figura 5.1 Los cinco flujos de trabajo (requisitos, anlisis, diseo, implementacin y prueba). Tienen lugar
sobre las cuatro fases: inicio, elaboracin, construccin y transicin.

Figura 5.2 Trminos orientados a la planificacin del RUP en sus fases.

5.1. Fase de I nicio
El objetivo global de la fase de inicio es poner en marcha el proyecto. Antes de esta
fase puede que tenga simplemente una idea interesante rondndole la cabeza. La fase de
27

inicio puede tratarse de algo tan sencillo como una persona que recopile una
declaracin de objetivos, esboce una arquitectura usando diversos diagramas, desarrolle
un anlisis de negocio razonable. O puede ser tan complejo como un proyecto de
investigacin completo. Lo importante es que no consideremos la fase de inicio como
algo que ha de desarrollarse de una nica forma.
Durante la fase de inicio se desarrolla una descripcin de la fase final a partir de una
buena idea y se presenta el anlisis de negocio para el producto. Esencialmente esta fase
responde a las siguientes preguntas:
Cules son las principales funciones del sistema para sus usuarios ms
importantes?
Cmo podra ser la arquitectura del sistema?
Cul es el plan de proyecto y cunto costar desarrollar el producto?
La respuesta de la primera pregunta se encuentra en un modelo de casos de uso
simplificado que contenga los casos de uso ms crticos. Cuando lo tengamos, la
arquitectura es provisional, y consiste tpicamente en un simple esbozo que muestra los
subsistemas ms importantes. En esta fase se identifican y priorizan los riesgos ms
importantes, se planifica en detalle la fase de elaboracin y se estima el proyecto de manera
aproximada.
Intentamos desarrollar el anlisis inicial de negocio para considerar el sistema previsto
en trminos econmicos, es decir, estimaciones iniciales de costes, agenda y recuperacin
de la inversin. Nos preguntaremos:
Compensarn las ganancias procedentes del uso o la venta del producto software,
los costos de su desarrollo?
Llegar el producto al mercado (o a su aplicacin interna) a tiempo de obtener esas
ganancias?
28




Figura 5.1.1 El trabajo de una iteracin en la fase de inicio transcurre a travs de los cinco flujos de trabajo
fundamentales. Los tamaos relativos de los rectngulos solo indican qu flujos de trabajo requieren ms
atencin.
5.2. Fase de Elaboracin
Segn entramos en la fase de elaboracin, dejamos atrs un hito principal que seala
tres logros:
Hemos formulado la arquitectura inicial.
Hemos identificado los problemas ms serios o crticos.
Hemos realizado el anlisis inicial de negocio con el suficiente grado de detalle
como para entrar en sta segunda fase.
Durante la fase de elaboracin, se especifican en detalle la mayora de casos de uso del
producto y se disea la arquitectura del sistema. La relacin entre la arquitectura del
sistema y el propio sistema es primordial. Una manera simple de expresarlo es decir que la
arquitectura es anloga al esqueleto cubierto por la piel pero con muy poco msculo
(software) entre los huesos y la piel, solo lo necesario para permitir que el esqueleto haga
movimientos bsicos. El sistema es el cuerpo entero con esqueleto, piel y msculo. Por
tanto, la arquitectura se expresa en forma de vistas de todos los modelos del sistema, los
29

cuales juntos representan al sistema entero. Esto implica que hay vistas arquitectnicas del
modelo de casos de uso, anlisis, diseo, implementacin, y de despliegue. La vista del
modelo de implementacin incluye componentes para probar que la arquitectura es
ejecutable. Durante esta fase del desarrollo se realizan los casos de uso ms crticos que se
identificaron en la fase de inicio. El resultado de esta fase es una lnea base de la
arquitectura.
Al final de la fase de elaboracin, el director de proyecto est en disposicin de
planificar las actividades y estimar los recursos necesarios para terminar el proyecto. Aqu
la cuestin fundamental es: Son suficientemente estables los casos de uso, la arquitectura y
el plan, y estn los riesgos suficientemente controlados como para que seamos capaces de
comprometernos al desarrollo mediante un contrato?
En esta fase los principales objetivos son:
Recopilar la mayor parte de los requisitos que an queden pendientes, formulando
los requisitos como casos de uso.
Establecer una base de arquitectura slida (la lnea base de la arquitectura) para
guiar el trabajo durante las fases de construccin y transicin, as como en las
posteriores generaciones del sistema.
Continuar la observacin y control de los riesgos crticos que an queden, e
identificar los riesgos significativos hasta el punto de que se pueda estimar su
impacto en el anlisis de negocio, y en particular en la puesta econmica.
Completar los detalles de plan de proyecto.
Esta fase supone desarrollar alrededor del 80 por ciento de los casos de uso y abordar
los riesgos que interfieran en la consecucin de este objetivo. En esta fase presentaremos el
entorno de desarrollo, no slo para llevar acabo las actividades de esta fase, sino para estar
preparados para la fase de construccin. As al final de esta fase, habremos acumulado la
informacin necesaria para planificar la fase de construccin. Tambin, en ese momento
tendremos informacin suficiente para realizar un anlisis de negocio fiable, trabajo que
comenzamos durante la fase de inicio.
30




Figura 5.2.1 El trabajo de una iteracin en la fase de elaboracin discurre a lo largo de los cinco flujos de
trabajo fundamentales. La mayor parte del esfuerzo se realiza durante la recopilacin de requisitos, anlisis y
diseo; es necesario comprender la mayora de los requisitos y disear el sistema. En comparacin,
implementacin y pruebas precisa menos recursos.
5.3. Fase de construccin
El propsito primordial de esta fase es dejar listo un producto software en su versin
operativa inicial, a veces llamada versin beta. El producto debera tener la calidad
adecuada para su aplicacin y asegurarse de cumplir los requisitos. La construccin debera
tener lugar dentro de los lmites del plan de negocio.
Durante la fase de construccin se crea el producto. En esta etapa, la lnea base de la
arquitectura, crece hasta convertirse en el sistema completo. La descripcin evoluciona
hasta convertirse en un producto preparado para ser entregado a la comunidad de usuarios.
El grueso de los recursos requeridos son empleados durante esta fase del desarrollo. Sin
embargo, la arquitectura del sistema es estable, aunque los desarrolladores pueden
descubrir formas mejores de estructurar el sistema, ya que los arquitectos recibirn
sugerencias de cambios arquitectnicos de menor importancia. Al final de esta fase, el
producto contiene todos los casos de uso que la direccin y el cliente han acordado para el
desarrollo de esta versin. No obstante, puede que no est completamente libre de defectos.
Muchos de estos defectos se descubrirn y solucionaran durante la fase de transicin. La
31

pregunta decisiva es: cubre el producto las necesidades de algunos usuarios de manera
suficiente como para hacer una primera entrega?
Durante la fase de construccin, el jefe de proyecto, el arquitecto y los desarrolladores
se aseguran de establecer la prioridad de los casos de uso, que son agrupados en
construcciones e iteraciones y desarrollados segn un orden que evita las vueltas atrs.
Adems, mantendrn actualizada la lita de riesgos, mediante su continuo refinamiento,
de forma que refleje los riesgos reales del proyecto. Su objetivo es acabar esta fase con
todos los riesgos mitigados (exceptuando aquellos que se derivan de la operacin, que son
tratados en la fase de transicin). El arquitecto vigila que la construccin se ajuste a la
arquitectura y si es necesario modifica dicha arquitectura para incorporar los cambios que
surgen durante el proceso de construccin.

Figura 5.3.1 El trabajo de una iteracin durante la fase de construccin discurre a lo largo de los cinco flujos
de trabajo fundamentales. Aqu se detallan y analizan los requisitos restantes, pero la carga de trabajo en estos
flujos, es relativamente leve. La mayor parte de este trabajo fue realizada en las dos fases anteriores; el diseo
juega un papel importante y es en esta fase en la que tiene lugar la mayor parte del trabajo de los flujos de
implementacin y pruebas. (El tamao de las barras tiene un carcter meramente ilustrativo, y ser distinto en
diferentes proyectos).

32

5.4. Fase de Transicin
Una vez que el proyecto entra en la fase de transicin, el sistema ha alcanzado la
capacidad operativa inicial.
La fase de transicin cubre el perodo durante el cual el producto se convierte en
versin beta. En la versin beta un nmero reducido de usuarios con experiencia prueba el
producto e informa de defectos y deficiencias. Los desarrolladores corrigen los problemas e
incorporan algunas de las mejoras sugeridas en una versin general dirigida a la totalidad
de la comunidad de usuarios. La fase de transicin conlleva actividades como la
fabricacin, formacin del cliente, el proporcionar una lnea de ayuda y asistencia, y la
correccin de los defectos que se encuentren tras la entrega. El equipo de mantenimiento
suele dividir esos defectos en dos categoras. Los que tienen suficiente impacto en la
operacin para justificar una versin incrementada (versin delta) y los que pueden
corregirse en la siguiente versin normal.
Esta fase se centra en implantar el producto en su entorno de operacin. La forma en
que el proyecto lleva a cabo su objetivo vara con la naturaleza de la relacin del producto
con su mercado.
En esta fase no se busca reformular el producto. El cliente y el equipo del proyecto
deberan haber incorporado cambios significativos en los requisitos durante las fases
anteriores. Por el contrario, el equipo busca pequeas deficiencias que pasaron
desapercibidas durante la fase de construccin y que pueden ser corregidas en el marco de
la lnea base de la arquitectura existente.
En el caso de productos para muchos usuarios (para el mercado del software
enlatado) estos servicios se construyen en el programa de instalacin que es parte del
producto, complementado con el servicio de asistencia tcnica.
La fase de transicin finaliza con el lanzamiento del producto.

33


Figura 5.4.1 El trabajo de una iteracin durante la fase de transicin discurre a lo largo de los cinco flujos de
trabajo fundamentales. (El tamao de las barras tiene un carcter meramente ilustrativo, y ser distinto en
diferentes proyectos). Los flujos de trabajo e implementacin y pruebas son los que reciben mayor atencin
en esta fase. Es aqu donde los defectos encontrados durante las pruebas beta o las de aceptacin se
identifican, corrigen y prueban de nuevo. En unos pocos casos ser necesario redisear, para corregir los
defectos, lo que llevara a un pequeo aumento en el flujo de trabajo de diseo. Los requisitos no se ven muy
afectados.

34

6. Flujos de trabajo
6.1. Captura de Requisitos
Llamamos captura de requisitos al acto de descubrimiento. Es el proceso de averiguar,
normalmente en circunstancias difciles. De hecho, es tan difcil que todava no es poco
comn para los equipos de un proyecto el comenzar a escribir cdigo (lo cual es bastante
fcil) antes de que hayan firmado simplemente lo que se supone debe hacer el cdigo (lo
cual es difcil de determinar).
La captura de requisitos entendida como un flujo de trabajo, tiene como propsito
esencial orientar el desarrollo hacia el sistema correcto. Esto se lleva a cabo mediante la
descripcin de los requisitos del sistema de forma tal que se pueda llegar a un acuerdo entre
el cliente (incluyendo los usuarios) y los desarrolladores del sistema, acerca de lo que el
sistema debe hacer y lo que no.
La posibilidad de tener puntos de partida tan dispares como una vaga nocin y una
especificacin de requisitos detallada sugiere que los analistas necesitan ser capaces de
adaptar sus tcnicas a la captura de requisitos en cada situacin. Los diferentes puntos de
partida plantean tipos diferentes de riesgos, por lo que los analistas deberan elegir las
tcnicas que reduzcan esos riesgos de la mejor forma.
Aparte de las diferencias en los puntos de partida, ciertos pasos son factibles en la
mayora de los casos, lo que nos permite sugerir un flujo de trabajo arquetpico. Este flujo
de trabajo incluye los siguientes pasos, que en realidad no se llevan a cabo separadamente:
Enumerar los requisitos candidatos.
Comprender el contexto del sistema.
Capturar requisitos funcionales.
Capturar requisitos no funcionales.
La figura 6.1.1 ilustra cmo el flujo de trabajo de captura de requisitos y sus artefactos
resultantes adquieren formas durante las distintas fases y sus iteraciones.
35


Figura 6.1.1 El trabajo de los requisitos se hace fundamentalmente durante el inicio y la elaboracin.
Durante la fase de inicio, los analistas capturan la mayora de los casos de uso para
delimitar el sistema y el alcance del proyecto y para detallar los ms importantes
(menos del 10 por ciento).
Durante la fase de elaboracin, los analistas capturan la mayora de los requisitos
restantes para que los desarrolladores puedan estimar el tamao del esfuerzo de
desarrollo que se requerir. El objetivo es haber capturado sobre un 80 por ciento de
los requisitos y haber descrito la mayora de los casos de uso al final de esta fase de
elaboracin. (Obsrvese que slo entre un 5 y un 10 por ciento de los requisitos
debera estar implementado en la lnea base en ese momento.)
Los requisitos restantes de captura (e implementan) durante la fase de construccin.
Casi no hay captura de requisitos en la fase de transicin, a menos que haya
requisitos que cambien.
6.2. Anlisis
Durante este flujo de trabajo, analizamos los requisitos que se describieron en la
captura de requisitos, refinndolos y estructurndolos. El objetivo de hacerlo es conseguir
una comprensin ms precisa de los requisitos y una descripcin de los mismos que sea
fcil de mantener y ayude a estructurar el sistema entero, incluyendo su arquitectura.
Las iteraciones iniciales de la elaboracin se centran en el anlisis (vase la
figura6.2.1). Eso contribuye a obtener una arquitectura estable y slida y facilita una
36

comprensin en facilidad de los requisitos, el nfasis pasa en cambio al diseo y a la
implementacin.

Figura 6.2.1 El anlisis.
El propsito y objetivo del anlisis debe alcanzarse de algn modo en todo proyecto.
Pero la manera exacta de ver y de emplear el anlisis puede diferir de un proyecto a otro, y
nosotros distinguimos tres variantes bsicas:
1. El proyecto utiliza el modelo de anlisis para describir los resultados del mismo, y
mantiene la consistencia de este modelo a lo largo de todo el ciclo de vida del
software. Esto puede hacerse, por ejemplo, de manera continua en cada iteracin del
proyecto.
2. El proyecto utiliza el modelo de anlisis para describir los resultados del anlisis
pero considera a este modelo como una herramienta transitoria e intermedia. Ms
adelante, cuando el diseo y la implementacin estn en marcha durante la fase de
construccin, se deja de actualizar el anlisis. En su lugar, cualquier tema de
anlisis que an quede se resuelve como parte integrada dentro del trabajo de
diseo en el modelo de diseo resultarte.
3. El proyecto no utiliza en absoluto el modelo de anlisis para describir los resultados
del anlisis. En cambio el proyecto analiza los requisitos como parte integrada en la
captura de requisitos o en el diseo. En el primero de los casos, har falta un mayor
formalismo en el modelo de casos de uso. Esto puede ser justificable si el cliente es
37

capaz de comprender los resultados, aunque creemos que rara vez se da el caso. El
segundo caso podra complicar el trabajo de diseo, sin embargo, esto puede ser
justificable si, por ejemplo, los requisitos son muy simples y/o son bien conocidos,
si es fcil identificar la forma del sistema (incluyendo su arquitectura), o si los
desarrolladores cuentan con una cierta comprensin, intuitiva pero correcta, de los
requisitos, y son capaces de construir un sistema que los encarne de una manera
bastante directa.

6.3. Diseo
En el diseo modelamos el sistema y encontramos su forma (incluida la arquitectura)
para que soporte todos los requisitos incluyendo los requisitos no funcionales y otras
restricciones que se le suponen. Una entrada esencial en el diseo es el resultado del
anlisis, esto es, el modelo de anlisis. El modelo de anlisis proporciona una comprensin
detallada de los requisitos. Y lo que es ms importante, impone una estructura del sistema
que debemos esforzarnos por conservar lo ms fielmente posible cuando demos forma al
sistema. En concreto los propsitos del diseo son:
Adquirir una comprensin en profundidad de los aspectos relacionados con los
requisitos no funcionales y restricciones relacionadas con los lenguajes de
programacin.
Crear una entrada apropiada y un punto de partida para actividades de
implementacin subsiguientes capturando los requisitos o subsistemas individuales,
interfaces y clases.
Ser capaz de descomponer los trabajos de implementacin en partes ms manejables
que puedan ser llevadas a cabo por diferentes equipos de desarrollo, teniendo en
cuanta la posible concurrencia
Capturar las interfaces entre los subsistemas antes en el ciclo de vida del software.
Ser capaces de visualizar y reflexionar sobre el diseo utilizando una notacin
comn.
Crear una abstraccin sin costuras de la implementacin del sistema, en el sentido
de que la implementacin es un refinamiento directo del diseo que rellena lo
existente sin cambiar la estructura.
38



Figura 6.3.1 El diseo.
El diseo es el centro de atencin al final de la fase de elaboracin y el comienzo de las
iteraciones de construccin. Esto contribuye a una arquitectura estable y slida y a crear un
plano del modelo de implementacin. Ms tarde, durante la fase de construccin, cuando la
arquitectura es estable y los requisitos estn bien entendidos el centro de atencin se
desplaza a la implementacin.
No obstante, el modelo de diseo est muy cercano al de implementacin, lo que es
natural para guardar y mantener el modelo de diseo a travs del ciclo de vida completo del
software. Esto es especialmente cierto en la ingeniera de ida y vuelta, donde el modelo de
diseo se puede utilizar para visualizar la implementacin y para soportar las tcnicas de
programacin grfica.
6.4. Implementacin
En la implementacin empezamos con el desarrollo del diseo e implementamos el
sistema en trminos de componentes, es decir, ficheros de cdigo fuentes, scripts, ficheros
de cdigo binario, ejecutables y similares.
39

Afortunadamente, la mayor parte de la arquitectura del sistema es capturada durante el
diseo, siendo el propsito principal de la implementacin el desarrollar la arquitectura y el
sistema como un todo. De forma ms especfica, los propsitos de la implementacin son:
Planificar las integraciones de sistema necesarios en cada iteracin. Seguimos para
ello un enfoque incremental, lo que da lugar a un sistema que se implementa en una
sucesin de pasos pequeos y manejables.
Distribuir el sistema asignando componentes ejecutables a nodos en el diagrama de
despliegue. Esto se basa fundamentalmente en las clases activas encontradas
durante el diseo.
Implementar las clases y subsistemas encontrados durante el diseo. En particular,
las clases se implementan como componentes de fichero que contienen cdigo
fuente.
Probar los componentes individualmente, y a continuacin integrarlos
compilndolos y enlazndolos en uno o ms ejecutables, antes de ser enviados para
ser integrados y llevar a cabo las comprobaciones del sistema.
La implementacin es el centro durante las iteraciones de construccin, aunque tambin
se lleva a cabo trabajo de implementacin durante la fase de elaboracin, para crear la lnea
base ejecutable de la arquitectura, y durante la fase de transicin para tratar efectos tardos
como los encontrados con distribuciones betas del sistema (como se indica en la figura
6.4.1 con un pico en la columna de transicin).

Figura 6.4.1 La implementacin.
40

Ya que el modelo de implementacin denota la implementacin actual del sistema en
trminos de componentes y subsistemas de implementacin, es natural mantener el modelo
de implementacin a lo largo de todo el ciclo de vida del software
6.5. Prueba
En el flujo de trabajo de la prueba verificamos el resultado de la implementacin
probando cada construccin, incluyendo tanto construcciones internas como intermedias,
as como las versiones finales del sistema a ser entregadas a terceros. Ms concretamente
los objetivos de la prueba son:
Planificar las pruebas necesarias en cada iteracin, incluyendo las pruebas de
integracin y las pruebas de sistema. Las pruebas de integracin son necesarias para
cada construccin dentro de la iteracin, mientras que las pruebas de sistema son
necesarias solo al final de la iteracin.
Disear e implementar las pruebas creando los casos de prueba que especifican qu
probar, creando los procedimientos de prueba que especifican como realizar las
pruebas y creando, si es posible, componentes de prueba ejecutables para
automatizar las pruebas.
Realizar las diferentes pruebas y manejar los resultados de cada prueba
sistemticamente.
Durante la fase de inicio puede hacerse parte de la planificacin inicial de las pruebas
cuando se define el mbito del sistema. Sin embargo, las pruebas se llevan a cabo sobre
todo cuando una construccin (como un resultado de implementacin) es sometida a
pruebas de integracin y de sistema. Esto quiere decir que la realizacin de prueba se centra
en las fases de elaboracin cuando se prueba la lnea base de la arquitectura y de
construccin, cuando el grueso del sistema est implementando. Durante la fase de
transicin el centro se desplaza hacia la construccin de defectos durante los primeros usos
y a las pruebas de regresin. Vase la figura 6.5.1
Debido a la naturaleza iterativa del esfuerzo de desarrollo, algunos de los casos de
prueba que especifican como probar las primeras construcciones pueden ser utilizadas
tambin como casos de prueba de regresin que especifican como llevar a cabo las pruebas
de regresin sobre las construcciones siguientes. El nmero de pruebas de regresin
necesarias crece por tanto de forma estable a lo largo de las iteraciones, lo que significa que
las ltimas iteraciones requerirn un gran esfuerzo en pruebas de regresin. Es natural, por
tanto, mantener el modelo de pruebas a lo largo del ciclo de vida del software completo,
aunque el modelo de pruebas cambia constantemente debido a:
La eliminacin de caos de prueba obsoletos (y los correspondientes procedimientos
de prueba y componentes de prueba).
41

El refinamiento de algunos casos de prueba en casos de prueba de regresin.
La creacin de nuevos casos de uso para cada nueva construccin.

Figura 6.5.1 Las pruebas.

42

7. Artefactos
Un artefacto es una pieza de informacin tangible que es creada, modificada y usada
por los trabajadores al realizar actividades; representa un rea de responsabilidad, y es
candidata a ser tenida en cuenta para el control de la configuracin. Un artefacto puede ser
un modelo, un elemento de un modelo o un documento.
Los artefactos son el resultado parcial o final que es producido y usado por los actores
durante el proyecto. Son las entradas y salidas de las actividades, realizadas por los actores,
los cuales utilizan y van produciendo estos artefactos para tener guas. Un artefacto puede
ser un documento, un modelo o un elemento de modelo.
7.1. Conjuntos de artefactos
Se tiene un conjunto de artefactos definidos en cada una de las disciplinas y utilizadas
dentro de ellas por lo actores para la realizacin de las mismas, a continuacin se definen
cada una de estas categoras o grupos de artefactos dentro de las disciplinas del RUP:
Requerimientos Los artefactos de requerimientos del sistema capturan y presentan
la informacin usada en definir las capacidades requeridas del sistema.
Anlisis y diseo del sistema Los artefactos para el anlisis y del diseo capturan
y presenta la informacin relacionada con la solucin a los problemas se
presentaron en los requisitos fijados.
Implementacin Los artefactos para la implementacin capturan y presentan la
realizacin de la solucin presentada en el anlisis y diseo del sistema.
Pruebas Los artefactos desarrollados como productos de las actividades de prueba
y de la evaluacin son agrupadas por el actor responsable, con el cual se lleva un
conjunto de documentos de informacin sobre las pruebas realizadas y las
metodologas de pruebas aplicadas.

7.2. Artefactos de requerimientos
Los artefactos fundamentales que se utilizan en la captura de requisitos son el modelo
de caso de uso, que incluye los casos de uso y los actores. Tambin puede haber otros tipos
de artefactos, como prototipos de interfaz de usuario.
Artefacto: modelo de casos de uso. El modelo de casos de uso permite que los
desarrolladores de software y los clientes lleguen a un acuerdo sobre los requisitos,
es decir, sobre las condiciones y posibilidades que debe cumplir el sistema. El
modelo de casos de uso sirve como acuerdo entre clientes y desarrolladores, y
proporciona la entrada fundamental para el anlisis, el diseo y las pruebas.
43

Un modelo de casos de uso es un modelo del sistema que contiene actores casos de
uso y sus relaciones.
Artefacto: descripcin de la arquitectura (vista del modelo de casos de uso). La
descripcin de la arquitectura del modelo de casos de uso, que representa los casos
de uso significativos para la arquitectura.
La vista de la arquitectura del modelo de casos de uso debera incluir los casos de
uso que describan alguna funcionalidad importante y crtica, o que impliquen algn
requisito importante que deba desarrollarse pronto dentro del siclo de vida del
software.
Artefacto: glosario. Podemos utilizar un glosario para definir trminos comunes
importantes que los analistas (y otros desarrolladores) utilizan al describir el
sistema. Un glosario es muy til para alcanzar un consenso entre los desarrolladores
relativo a la definicin de los diversos conceptos y nociones, y para reducir en
general el riesgo de confusiones.
Habitualmente podemos obtener un glosario a partir de un modelo de negocio o un
modelo del dominio.
Artefacto: prototipo de interfaz de usuario. Los prototipos de interfaz de usuario
nos ayudan a comprender y especificar las interacciones entre actores humanos y el
sistema durante la captura de requisitos. No solo nos ayuda a desarrollar una
interfaz grfica mejor, sino tambin a comprender mejor los casos de uso. A la hora
de especificar la interfaz de usuario tambin pueden utilizarse otros artefactos, como
los modelos de interfaz grfica y los esquemas de pantallas.

7.3. Artefactos de Anlisis
Artefacto: modelo de anlisis. El modelo de anlisis se representa mediante un
sistema de anlisis que denota el paquete de ms alto nivel del modelo. La
utilizacin de otros paquetes de anlisis es por tanto una forma de organizar el
modelo de anlisis en partes ms manejables que representan abstracciones de
subsistemas y posiblemente capas completas del diseo del sistema. Dentro del
modelo de anlisis, los casos de uso se describen mediante clases de anlisis y sus
objetos. esto se representa mediante colaboraciones dentro del modelo de anlisis
que llamamos realizaciones de casos de uso-anlisis.
Artefacto: realizacin de casos de uso-anlisis. Una realizacin de caso de uso-
anlisis es una colaboracin dentro del modelo de anlisis que describe cmo se
lleva a cabo y se ejecuta un caso de uso determinado en trminos de las clases del
anlisis y sus objetos del anlisis e interaccin. una realizacin de caso de uso
proporciona por tanto una traza directa hacia un caso de uso concreto del modelo de
casos de uso.
44

Artefacto: paquete del anlisis. Los paquetes del anlisis proporcionan un medio
para organizar los artefactos del modelo de anlisis en piezas manejables. Un
paquete de anlisis puede constar de clases de anlisis, de realizaciones de caso de
uso, y de otros paquetes del anlisis (recursivamente)
Artefacto: descripcin de la arquitectura (vista del modelo de anlisis): la
descripcin de la arquitectura contiene una vista de la arquitectura del modelo de
anlisis que muestra artefactos significativos para la arquitectura. La descripcin de
la arquitectura contiene una vista arquitectnica del modelo de anlisis.

7.4. Artefactos de Diseo:
Artefacto: modelo de diseo. El modelo de diseo es un modelo de objetos que
describe la realizacin fsica de los casos de uso centrndose en cmo los requisitos
funcionales y no funcionales, junto con otras restricciones relacionadas con el
entorno de implementacin, tienen impacto en el sistema a considerar. Adems, el
modelo de diseo sirve de abstraccin en la implementacin del sistema y es, de ese
modo, utilizada como una entrada fundamental de las actividades de
implementacin.
Artefacto: clase del diseo. Una clase de diseo es una abstraccin sin costuras de
una clase o construccin similar en la implementacin del sistema.
Artefacto: realizacin de caso de uso-diseo. Una realizacin de caso de uso
diseo es una colaboracin en el modelo de diseo que describe como se realiza un
caso de uso especfico, y cmo se ejecuta en trminos de clases de diseo y sus
objetos. Una realizacin de caso de uso-diseo proporciona una traza directa a una
realizacin de caso de uso-anlisis en el modelo de anlisis. Ntese que una
realizacin de caso de uso-diseo de esta forma tambin puede tener una traza a un
caso de uso en el modelo de casos de uso a travs de una realizacin de caso de uso-
anlisis.
Artefacto: subsistema de diseo. Los subsistemas de diseo son una forma de
organizar los artefactos del modelo de diseo en piezas ms manejables. Un
subsistema puede constar de clases del diseo, realizaciones de caso de uso,
interfaces, y otros subsistemas (recursivamente). Por otro lado, un subsistema puede
proporcionar interfaces que representan la funcionalidad que exportan en trminos
de operaciones.
Artefacto: interfaz. Las interfaces se utilizan para especificar las operaciones que
proporcionan las clases del diseo.
Las interfaces constituyen una forma de separar la especificacin de la
funcionalidad en trminos de operaciones de sus implementaciones en trminos de
mtodos. Esta distincin hace independiente de la implementacin de la interfaz a
cualquier cliente que dependa de ella. Podemos sustituir una implementacin
45

completa de una interfaz como puede ser una clase o un subsistema del diseo, por
otra implementacin sin tener que cambiar los clientes.
Artefacto: descripcin de la arquitectura (vista del modelo de diseo). La
descripcin de la arquitectura del modelo de diseo, que muestra sus artefactos
relevantes para la arquitectura.
Artefacto: modelo de despliegue. El modelo de despliegue es un modelo de
objetos que describe la distribucin fsica del sistema en trminos de cmo se
distribuye la funcionalidad entre los nodos de cmputo. El modelo de despliegue se
utiliza como entrada fundamental en las actividades de diseo e implementacin
debido a que la distribucin del sistema tiene una influencia principal en su diseo.
Artefacto: descripcin de la arquitectura (vista del modelo de despliegue). La
descripcin de la arquitectura contiene una vista de la arquitectura del modelo de
despliegue, que muestra sus artefactos relevantes para la arquitectura.
Debido a su importancia, debera mostrarse todos los aspectos del modelo de
despliegue en la vista arquitectnica, incluyendo la correspondencia de los
componentes sobre los nodos tal como se identific durante la implementacin.
7.5. Artefactos de implementacin
Artefacto: modelo de implementacin. El modelo de implementacin describe
cmo los elementos del modelo de diseo, como las clases, se implementan en
trminos de componentes, como ficheros de cdigo fuente, ejecutables, etc. El
modelo de implementacin describe tambin como se organizan los componentes de
acuerdo con los mecanismos de estructuracin y modularizacin disponibles en el
entorno de implementacin y en el lenguaje de programacin utilizados, y cmo
dependen los componentes unos de otros.
Artefacto: componente. Un componente es el empaquetamiento fsico de los
elementos de un modelo, como son las clases en el modelo de diseo.
Artefacto: subsistema de implementacin. Los subsistemas de implementacin
proporciona una forma de organizar los artefactos del modelo de implementacin en
trozos ms manejables. Un subsistema puede estar formado por componentes,
interfaces, y otros subsistemas (recursivamente). Adems, un subsistema puede
implementar las interfaces que representan la funcionalidad que exportan en forma
de operaciones.
Artefacto: interfaz. Las interfaces pueden ser utilizadas en el modelo de
implementacin para especificar las operaciones implementadas por componentes y
subsistemas de implementacin. Adems, como se mencion anteriormente, los
componentes y los subsistemas de implementacin pueden tener dependencias de
uso sobre interfaces.
46

Artefacto: descripcin de arquitectura (vista del modelo de implementacin).
La descripcin de arquitectura contiene una visin de la arquitectura del modelo de
implementacin, el cual representa sus artefactos significativos arquitectnicamente.
Artefacto: plan de integracin de construcciones. Es importante construir el
software incrementalmente en pasos manejables, de forma que cada paso d lugar a
pequeos problemas de integracin o prueba. El resultado de cada paso es llamado
construccin, que es una versin ejecutable del sistema, usualmente una parte
especfica del sistema. Cada construccin es entonces sometida a pruebas de
integracin antes de que se cree ninguna otra construccin. Para prepararse ante el
fallo de una construccin se lleva un control de versiones de forma que se pueda
volver atrs a una construccin anterior.
7.6. Artefactos de prueba
Artefacto: modelo de pruebas. El modelo de pruebas principalmente cmo se
prueban los componentes ejecutables (como las construcciones) en el modelo de
implementacin con pruebas de integracin y de sistema. El modelo de pruebas
puede describir cmo han de ser probados aspectos especficos del sistema, por
ejemplo, si la interfaz de usuario es utilizable y consistente o si el manual de usuario
del sistema cumple con su cometido. El modelo de pruebas es una coleccin de
casos de prueba, procedimientos de prueba y componentes de prueba.
Artefacto: caso de prueba. Un caso de prueba especifica una forma de probar el
sistema, incluyendo la entrada o resultado con que se ha de probar y las condiciones
bajo las que ha de probarse.
Artefacto: procedimiento de prueba. Un procedimiento de prueba especifica
cmo realizar uno o varios casos de prueba o partes de stos. Por ejemplo, un
procedimiento de prueba puede ser una instruccin para un individuo sobre cmo ha
de realizar un caso de prueba manualmente, o puede ser una especificacin de cmo
interaccionar manualmente con una herramienta de automatizacin de pruebas para
crear componentes ejecutables de prueba.
Artefacto: componente de prueba. Un componente de prueba automatiza uno o
varios procedimientos de prueba o partes de ellos. Los componentes de prueba
pueden ser desarrollados utilizando un lenguaje de guiones o un lenguaje de
programacin, o pueden ser grabados con una herramienta de automatizacin de
pruebas. Tambin se utilizan para probar los componentes en el modelo de
implementacin, proporcionando entradas de prueba, controlando y monitorizando
la ejecucin de los componentes a probar y, posiblemente, informando de estos
resultados de las pruebas.
Artefacto: plan de prueba. El plan de prueba describe las estrategias, recursos y
planificacin de la prueba. La estrategia de prueba incluye la definicin del tipo de
pruebas a realizar para cada iteracin y sus objetivos, el nivel de cobertura de
47

prueba y de cdigo necesario y el porcentaje de pruebas que deberan ejecutarse con
un resultado especfico.
Artefacto: defecto. Un defecto es una anomala del sistema, como por ejemplo un
sntoma de un fallo software o un problema descubierto en una revisin. Un defecto
puede ser utilizado para localizar cualquier cosa que los desarrolladores necesitan
registrar como sntoma de un problema en el sistema que ellos necesitan controlar y
resolver.
Artefacto: evaluacin de prueba. Una evaluacin de prueba es una evaluacin de
los resultados de los esfuerzos de prueba, tales como la cobertura del caso de
prueba, la cobertura de cdigos y el estado de defectos.


48

Conclusin

La alta demanda de software de calidad ha generado con el paso del tiempo la
necesidad de modelos de desarrollo de software cada vez ms rpidos y eficientes, esto fue
lo que impulso a los creadores de la metodologa RUP.
Esta metodologa se desarroll obteniendo lo mejor de cada modelo y adaptndolo de
forma que contemple el proceso completo, desde el diseo y modelado del sistema, hasta la
planificacin y desarrollo del sistema completo.
RUP se organiza por medio de fases y flujos de trabajo, y estos a su vez, generan
artefactos; adems cuenta con caractersticas importantes como trabajo por iteraciones
incrementales, se centra en la arquitectura y se dirige por casos de uso, los cuales son la
base del sistema; esto lo convierte en un proceso muy eficaz que logra como resultado
productos de muy alta calidad.
Tambin, cuenta con algunos puntos negativos, entre los cuales se pueden mencionar la
gran cantidad de recursos que demanda, el costo elevado de produccin e implementacin,
la dificultad de comprensin de la estructura y forma de trabajo del proceso como tal,
adems de que debe contar con personal altamente calificado en las respectivas reas que
abarca.
Para la implementacin de este proceso, es necesario que tanto el cliente como el
desarrollador, tomen en cuenta el costo de produccin, la cantidad de recursos humanos y
tiempo que requiere, adems de valorar la inversin que va a realizar, sin embargo, la
correcta aplicacin del proceso, garantiza que el resultado sea un producto de muy alta
calidad, que responde a la necesidades reales del cliente y se logre convertir en una
herramienta productiva para la empresa.


49

Glosario
AOO: Anlisis Orientado a Objetos.
DOO: Diseo Orientado a Objetos.
Hito: un punto de terminacin de la iteracin cuando se toma alguna decisin o evaluacin
importante.
Incremento: La diferencia (delta) entre las versiones de dos iteraciones seguidas. Es el
resultado final de una iteracin.
Mtodo de Ericsson: es esencialmente el que actualmente se conoce como desarrollo
basado en componentes. Comprob su efectividad de diseo modular al brindar la
posibilidad de instalar cada bloque ejecutable o modificado sobre la marcha de un sistema
de telecomunicaciones en ejecucin el 100 por ciento de su tiempo (era sumamente
improductivo detener un sistema de tal magnitud simplemente para hacer cambios).
OO: Programacin Orientada a Objetos.
Requerimiento funcional: define el comportamiento interno del software: clculos,
detalles tcnicos, manipulacin de datos y otras funcionalidades especficas que muestran
cmo los casos de uso sern llevados a la prctica
Requerimiento no funcional: o atributo de calidad es, en la ingeniera de sistemas y
la ingeniera de software, un requisito que especifica criterios que pueden usarse para
juzgar la operacin de un sistema en lugar de sus comportamientos especficos, ya que
stos corresponden a los requisitos funcionales. Por tanto, se refieren a todos los requisitos
que ni describen informacin a guardar, ni funciones a realizar.
SDL: Lenguaje de especificacin formal. El lenguaje SDL est diseado para la
especificacin de sistemas complejos, interactivos, orientados a eventos, de tiempo real o
que presenten un comportamiento paralelo, y donde mdulos o entidades independientes se
comuniquen por medio de seales para efectuar su funcin
UML: Lenguaje Unificado de Modelado (LUM o UML, por sus siglas en ingls, Unified
Modeling Language) es el lenguaje de modelado de sistemas de software ms conocido y
utilizado en la actualida
Versin: un subconjunto estable y ejecutable del producto final. El final de cada iteracin
es una versin pequea.



50


Bibliografa
Jacobson, I., Booch, G., & Rumbaugh, J. (2000). El proceso unificado de desarrollo de
software. Madrid , Espaa: Pearson Educacin S.A.
Larman, C. (2003). UML y Patrones. Una introduccin al anlisis y diseo orientado a
objetos y al proceso unificado. Madrid, Espaa: Pearson Educacin S.A.
Pressman, R. (2005). Ingeniera del Software. Un enfoque prctico (Sexta edicin ed.).
Madrid, Espaa: MacGraw-Hill Interamericana S.A.
Rueda Chacn, J. C. (Marzo de 2006). Aplicacin de la metodologa RUP para el
desarrollo rpido de aplicaciones basado en el estndar J2EE. Trabajo de graduacin
presentado a la junta directiva de la acultad de ingenira de la Universidad de San Carlos de
Guatemala. San Carlos, Guatemala.
Sommerville, I. (2005). Ingeniera del Software (Sptima Edicin ed.). Madrid, Espaa:
Pearson Educacin S.A.

51

Tabla de Evaluacin.
Puntos de Evaluacin para las Exposiciones
Escala Calificacin de 1 a 10.
Grupo # 1
Tema: Proceso Unificado Racional (R.U.P)
tem a Evaluar Nota
1. Objetivos y metodologa (relacionado con tema).
2. Revisin bibliogrfica (incluye trabajo escrito).
3. Preparacin y organizacin del material.
4. Presentacin y orden en el desarrollo del tema (incluye puntualidad
logstica y apariencia personal).

5. Utilizacin del tiempo.
6. Estmulo del inters por parte del auditorio.
7. Dominio del Tema.
Total de puntos obtenidos: