INSTITUTO POLITCNICO NACIONAL

UNIDAD PROFESIONAL
INTERDISCIPLINARIA DE INGENIERA Y
CIENCIAS SOCIALES Y ADMINISTRATIVAS

Herramientas Automatizadas

Metodologa RUP

Vejero Don Pablo Rosa Maria

Antecedentes de la Metodologa RUP

RUP fue creado por Grady Booch (creador del mtodo Booch), Ivar Jacobson y James Jacobson
(Creador de la Tcnica de Modelado de Objetos), la misma aparece en Junio de 1998 con el
acrnimo RUP 5.0 y puesto a la disposicin del pblico a inicios de 1999 y su funcionamiento se
centraba en las personas, los procesos y las herramientas.

Su funcionalidad parte de una serie de mtodos los cuales se puede comentar, el mtodo ericcson,
mtodo utilizado por la compaa del mismo nombre para el proceso unificado de desarrollo, a
este proceso se le anexa un proceso denominado Objetory creado por Jacobson. En el ao 1995 se
anexa el enfoque Rational dando paso a ROP 4.0 (Rational Objetory Process) que junto a la OMT
(Objects Modeling Technique) de Rumbaugh y Booch lo que permiti dar origen a UML, esta
herramienta fortaleci mucho ms a ROP en el empleo de caso de usos. Para el ao 1996, surge
ROP 4.1 con la integracin de actividades SQA (Software Quality Assurance, Software de Control
de Calidad por sus siglas en ingles), esto permita el aseguramiento de un software de calidad que
se adapte a las necesidades del usuario final por medio de la actualizacin de UML. Para 1998 se
lanza al mercado una fase de prueba, con un UML fortalecido y la integracin de los enfoques de
la ingeniera de Negocios y la Ingeniera de Datos a partir de aqu nace RUP, con los lineamientos y
vertientes que hoy da conocemos.

Lnea de tiempo

- Objectory Process 1.0-3.8 (1987-1995)

- Metodologa de Ericsson

- Rational Objectory Process 4.1 (1996-1997)

- Metodologa de Rational

- UML 1.1

- Rational Unified Process 5.0 (1998)

- Pruebas de Ejecucin

- Administracin de requerimientos

- Administracion de configuracin y cambios

- Ingeniera de negocios

- Diseo de Interfaz con el usuario

- UML 1.2
- Rational Unified Process 5.5 (1999)

- Desarrollo basado en Web Sistemas de Tiempo Real

- UML 1.3

- Rational Unified Process (2000)

Evolucin de Rup en acontecimientos ms importantes

1967

- Con la Metodologa Ericsson (Ericsson Approach) elaborada por Ivar Jacobson, una aproximacin
de desarrollo basada en componentes, que introdujo el concepto de Caso de Uso.

1987 a 1995

- Jacobson fund la compaa Objectory AB y lanza el proceso de desarrollo Objectory (abreviacin

de Object Factory).

1995

- Rational Software Corporation adquiere Objectory AB y entre 1995 y 1997 se desarrolla Rational
Objectory Process (ROP) a partir de Objectory 3.8 y del Enfoque Rational (Rational Approach)
adoptando UML como lenguaje de modelado.

1998

- Se lanza Rational Unified Process.

Estructura del proceso

El proceso puede ser descrito en dos dimensiones o ejes

Eje horizontal: Representa el tiempo y es considerado el eje de los aspectos dinmicos del
proceso. Indica las caractersticas del ciclo de vida del proceso expresado en trminos de fases,
iteraciones e hitos. Se puede observar en la Figura 6 que RUP consta de cuatro fases: Inicio,
Elaboracin, Construccin y Transicin. Como se mencion anteriormente cada fase se subdivide a
la vez en iteraciones.

Eje vertical: Representa los aspectos estticos del proceso. Describe el proceso en trminos de
componentes de proceso, disciplinas, flujos de trabajo, actividades, artefactos y roles
Estructura Dinmica del proceso. Fases e iteraciones

RUP se repite a lo largo de una serie de ciclos que constituyen la vida de un producto. Cada ciclo
concluye con una generacin del producto para los clientes. Cada ciclo consta de cuatro fases:
Inicio, Elaboracin, Construccin y Transicin. Cada fase se subdivide a la vez en iteraciones, el
nmero de iteraciones en cada fase es variable. Cada fase se concluye con un hito bien definido,
un punto en el tiempo en el cual se deben tomar ciertas decisiones crticas y alcanzar las metas
clave antes de pasar a la siguiente fase, ese hito principal de cada fase se compone de hitos
menores que podran ser los criterios aplicables a cada iteracin

La duracin y esfuerzo dedicado en cada fase es variable dependiendo de las caractersticas del
proyecto. Sin embargo, la Figura 8 ilustra porcentajes frecuentes al respecto. Consecuente con el
esfuerzo sealado, la Figura 9 ilustra una distribucin tpica de recursos humanos necesarios a lo
largo del proyecto
Inicio

Durante la fase de inicio se define el modelo del negocio y el alcance del proyecto. Se identifican
todos los actores y Casos de Uso, y se disean los Casos de Uso ms esenciales (aproximadamente
el 20% del modelo completo). Se desarrolla, un plan de negocio para determinar que recursos
deben ser asignados al proyecto. Los objetivos de esta fase son:

Establecer el mbito del proyecto y sus lmites.

Encontrar los Casos de Uso crticos del sistema, los escenarios bsicos que definen la
funcionalidad.

Mostrar al menos una arquitectura candidata para los escenarios principales.

Estimar el coste en recursos y tiempo de todo el proyecto.

Estimar los riesgos, las fuentes de incertidumbre

Elaboracin

El propsito de la fase de elaboracin es analizar el dominio del problema, establecer los

cimientos de la arquitectura, desarrollar el plan del proyecto y eliminar los mayores riesgos. En
esta fase se construye un prototipo de la arquitectura, que debe evolucionar en iteraciones
sucesivas hasta convertirse en el sistema final. Este prototipo debe contener los Casos de Uso
crticos identificados en la fase de inicio. Tambin debe demostrarse que se han evitado los riesgos
ms graves. Los objetivos de esta fase son:

Definir, validar y cimentar la arquitectura.

Completar la visin.

Crear un plan fiable para la fase de construccin. Este plan puede evolucionar en sucesivas
iteraciones. Debe incluir los costes si procede.

Demostrar que la arquitectura propuesta soportar la visin con un coste razonable y en un

tiempo razonable.
En esta fase se debe tratar de abarcar todo el proyecto con la profundidad mnima. Slo se
profundiza en los puntos crticos de la arquitectura o riesgos importantes. En la fase de
elaboracin se actualizan todos los productos de la fase de inicio.

Los criterios de evaluacin de esta fase son los siguientes:

La visin del producto es estable.

La arquitectura es estable.

Se ha demostrado mediante la ejecucin del prototipo que los principales elementos de riesgo
han sido abordados y resueltos.

El plan para la fase de construccin es detallado y preciso. Las estimaciones son crebles.

Todos los interesados coinciden en que la visin actual ser alcanzada si se siguen los planes
actuales en el contexto de la arquitectura actual.

Los gastos hasta ahora son aceptables, comparados con los previstos. Si no se superan los
criterios de evaluacin quiz sea necesario abandonar el proyecto o replanterselo
considerablemente.

Construccin

La finalidad principal de esta fase es alcanzar la capacidad operacional del producto de forma
incremental a travs de las sucesivas iteraciones. Durante esta fase todos los componentes,
caractersticas y requisitos deben ser implementados, integrados y probados en su totalidad,
obteniendo una versin aceptable del producto.

Los objetivos concretos incluyen:

Minimizar los costes de desarrollo mediante la optimizacin de recursos y evitando el tener que
rehacer un trabajo o incluso desecharlo.

Conseguir una calidad adecuada tan rpido como sea prctico.

Conseguir versiones funcionales (alfa, beta, y otras versiones de prueba) tan rpido como sea
prctico.

Los resultados de la fase de construccin deben ser:

Modelos Completos (Casos de Uso, Anlisis, Diseo, Despliegue e Implementacin)

Arquitectura ntegra (mantenida y mnimamente actualizada)

Riesgos Presentados Mitigados

Plan del Proyecto para la fase de Transicin.

 Manual Inicial de Usuario (con suficiente detalle)

Prototipo Operacional beta

Caso del Negocio Actualizado

Los criterios de evaluacin de esta fase son los siguientes:

El producto es estable y maduro como para ser entregado a la comunidad de usuario para ser
probado.

Todos los usuarios expertos estn listos para la transicin en la comunidad de usuarios.

Son aceptables los gastos actuales versus los gastos planeados.

Transicin

La finalidad de la fase de transicin es poner el producto en manos de los usuarios finales, para lo
que se requiere desarrollar nuevas versiones actualizadas del producto, completar la
documentacin, entrenar al usuario en el manejo del producto, y en general tareas relacionadas
con el ajuste, configuracin, instalacin y facilidad de uso del producto.

Algunas de las cosas que puede incluir esta fase:

Prueba de la versin Beta para validar el nuevo sistema frente a las expectativas de los usuarios
Funcionamiento paralelo con los sistemas legados que estn siendo sustituidos por nuestro
proyecto

Conversin de las bases de datos operacionales.

Entrenamiento de los usuarios y tcnicos de mantenimiento.

Traspaso del producto a los equipos de marketing, distribucin y venta.

Los principales objetivos de esta fase son:

Conseguir que el usuario se valga por s mismo.

Un producto final que cumpla los requisitos esperados, que funcione y satisfaga suficientemente
al usuario.

Los resultados de la fase de transicin son:

Prototipo Operacional

Documentos Legales

Caso del Negocio Completo

 Lnea de Base del Producto completa y corregida que incluye todos los modelos del sistema

Descripcin de la Arquitectura completa y corregida

Las iteraciones de esta fase irn dirigidas normalmente a conseguir una nueva versin.

Los criterios de evaluacin de esta fase son los siguientes:

El usuario se encuentra satisfecho.

Son aceptables los gastos actuales versus los gastos planificado

Caractersticas

Las caractersticas esenciales de la metodologa RUP son tres: dirigida por casos de uso, iterativos
e incrementales y centrados en la arquitectura.

Caso de Uso

Los casos de uso describen cmo los usuarios interactan con el sistema a desarrollar. Donde un
usuario, puede ser una persona u otro sistema que utilice las funcionalidades del sistema a
desarrollar. Un caso de uso representa una funcionalidad puntual del sistema. Por ejemplo, una
funcionalidad puntual, en un sistema para cajeros automticos, es la de retiro.

Iterativo e Incremental

RUP se basa en la evolucin de prototipos ejecutables o versiones del producto final que se
muestran a los usuarios e inversionistas del proyecto. Cada paso por el ciclo de vida produce una
versin del producto que incrementalmente se va refinando en las iteraciones de las diferentes
fases. Si llegado el final del ciclo de vida de RUP, el producto no cumple con los objetivos
planteados, se puede realizar un ciclo ms para refinar, corregir y agregar funcionalidades que
lleven al software a cumplir con las expectativas o cancelar el proyecto en base a los resultados
obtenidos. Lo que indica que con un enfoque iterativo e incremental, se tiene un mejor manejo de
los riesgos y un refinamiento ms efectivo del producto final.
 Centrado en la Arquitectura

En RUP el proceso se basa en disear tempranamente una arquitectura base ejecutable. La

arquitectura de un sistema, es la organizacin o estructura de sus partes (componentes) ms
relevantes dejando de lado los detalles, incluye los aspectos estticos y dinmicos del sistema.

Elementos Bsicos De RUP

Con RUP, un proceso de desarrollo es representado usando un conjunto de elementos de

modelado, tales como: roles, actividades, artefactos y flujos de trabajo (workflows), entre otros.
Un rol expresa quin (individuo o grupo) hace un trabajo, una actividad describe cmo es hecho el
trabajo y un artefacto captura el trabajo realizado. En RUP se encuentran 4 elementos bsicos: los
roles (el quin), las actividades (el cmo), los artefactos (el qu) y los flujos de trabajo (el cundo).

La estructura esttica de RUP maneja cmo los elementos del proceso (actividades, disciplinas,
artefactos y roles) estn lgicamente agrupados dentro del corazn de las disciplinas del proceso.
1. Roles

Un rol es una definicin abstracta del conjunto de responsabilidades, para las actividades a ser
desempeadas y artefactos a ser producidos dentro del proyecto por un individuo o grupo.
 Analistas: Agrupa los roles que estn principalmente involucrados en la captura de
requerimientos (investigan). Por ejemplo analista de procesos de negocios.

Desarrolladores: Agrupa a los roles principalmente involucrados en el diseo e

implementacin del software. Algunos de los roles de esta categora son el arquitecto de
software, el diseador, el integrador, etc.

Gerentes: Agrupa los roles principalmente involucrados en la direccin y configuracin de

los procesos de ingeniera. Por ejemplo, gerente de proyecto, gerente de publicacin
(deployment).

Produccin y Soporte: Agrupa los roles para dar soporte al proceso de desarrollo del
software. Ejemplos: escritor tcnico, especialista de herramientas, administrador de
sistema, etc.

Probadores: Agrupa los roles que dirigen las pruebas para habilidades especficas a medir.
Ejemplos: probador, analista de pruebas, etc.

Roles Adicionales: Agrupa los roles que no se ajustan en ninguno de los grupos anteriores.

2. Actividades

Una actividad es una unidad de trabajo que se asigna a un rol, la cual se requiere sea ejecutada
por el individuo asociado a ese rol. Cada actividad es asignada a un rol especfico.
Pasos:

Las actividades estn fraccionadas en pasos y estos agrupados en tres categoras:

Pasos de Anlisis: Son aquellos que se refieren a cuando el individuo que desempea el rol
comprende la naturaleza de la tarea, recolectando y examinando los artefactos de entrada
y formulando resultados o solucin.

Pasos de Ejecucin: El rol crea o actualiza algn artefacto.

Pasos de Revisin: Donde el rol verifica los resultados contra algn criterio.

No todos los pasos son necesariamente ejecutados cada vez que una actividad es invocada, as los
pasos pueden ser expresados en forma de flujos alternativos.

3. Artefactos

Un artefacto es una pieza de informacin que es producida o utilizada por procesos. Los artefactos
son los elementos tangibles de un proyecto, elementos que el proyecto produce o usa mientras se
trabaja en busca del producto final.
4. Disciplina

Una disciplina es una coleccin de actividades relacionadas a un rea de inters principal, dentro
de todo el proyecto; por ejemplo, la administracin de los requerimientos.

5. Flujos de Trabajo (Workflows)

Un flujo de trabajo es una secuencia de actividades que producen un resultado de valor

observable. Una de las grandes dificultades de describir un proceso de software, es que hay
muchas formas de organizar el conjunto de actividades dentro de un flujo de trabajo. No siempre
es posible representar flujos de trabajo. En RUP se utilizan flujos de trabajo detallados y disciplinas
para organizar el proceso de software.

Flujos de Trabajo Detallados

Son flujos de trabajo dentro de una disciplina. Muestran el grupo de actividades que
frecuentemente se ejecutan juntas. Estos diagramas muestran los roles involucrados, artefactos
de entrada y salida, as como las actividades ejecutadas. Los diagramas de flujo de trabajo
detallado estn all por las siguientes razones:

Tpicamente, en las reuniones de un equipo de proyecto se trabaja en paralelo algunas

actividades, mientras se hace esto, se observa ms de un artefacto. Un flujo de trabajo detallado,
da una visin ms clara de ese trabajo en paralelo. Esto significa que hay varios diagramas de flujo
de trabajo detallado para una disciplina.

Es complicado el mostrar los artefactos de entrada y salida para todas las actividades de una
disciplina en un diagrama. El diagrama de flujo de trabajo detallado, permite mostrar las
actividades y los artefactos juntos, para una parte del flujo de trabajo.
Evolucin y tendencias

Ms presencia de asistentes virtuales controlados por voz

Los grandes avances en tecnologas de inteligencia artificial, aprendizaje automtico (machine

learning en ingls) y procesamiento de voz han llevado a que los asistentes virtuales por voz sean
cada vez ms precisos, y, por tanto, ms utilizados.

Siri de Apple fue el primer asistente virtual por voz en llegar a las masas, y para mediados del 2015
ya manejaba ms de 1.000 millones de solicitudes de voz semanales. Luego Amazon puso a Alexa
en el mercado, seguido por Microsoft con Cortana, y Google con Now y Assistant.

En 2017, los asistentes virtuales controlados por voz se integrarn ms al ecosistema del hogar
inteligente a travs de altavoces inteligentes como Amazon Echo, Amazon Echo Dot, y Google
Home. Estos se convertirn en compaeros de hogar que nos apoyarn en tareas rutinarias como
encontrar una receta para preparar la comida, revisar el email, controlar las luces de la casa,
escuchar recordatorios y otras 3 mil habilidades distintas. De hecho, Echo y Echo Dot, fueron los
productos ms vendidos por Amazon en 2016.

Sabiendo que es ms fcil hablar que teclear o hacer click, los gigantes de tecnologa quieren llevar
sus asistentes virtuales por voz al mayor nmero de hogares posibles, por lo que estn abriendo
sus plataformas para fabricantes de hardware y desarrolladores de apps.
Taxis autnomos circularn por las calles

En 2016, 70 mil personas recorrieron 1,255 millones de kilmetros en el modo autopiloto de los
vehculos semi-autnomos Tesla. Google complet otro ao ms con 60 vehculos semiautnomos
rodando por las calles. El saldo fue notable: un accidente por compaa atribuible al vehculo y
sobretodo, una cantidad brutal de informacin recolectada para ayudar a mejorar la ingeniera y el
marco normativo global de esta tecnologa. Adems, Uber comenz a experimentar con
automviles en Pittsburgh y San Francisco.

El 2017 ser decisivo para la industria, pues veremos ms alianzas entre compaas de software,
de manufactura de chips y de automviles. Las marcas tradicionales de automviles anunciaron
que comercializarn sus vehculos entre el 2018 y 2021. A este ritmo exponencial, se esperara que
los automviles totalmente autnomos lleguen entre 2022 y 2023, y que estuvieran en todo el
mundo para el 2025.

Para esa poca, los coches autnomos estarn circulando todo el tiempo y permitirn prescindir
del 80% de los automviles, ganando el espacio que ocupan por estacionarse. Ms an, quedar
en el pasado el nmero de percances por conduccin humana de automvil, que en 2016 lleg a
1.1 millones de fallecimientos alrededor del mundo y a 31 millones de lesionados.

La principal preocupacin actual de los tecnlogos es demostrar que la tecnologa es segura. Esto
ayudar a que la regulacin sea ms amigable a sus intereses, sabiendo que la mayora de pases
no tienen regulacin al respecto. Otros debates futuros incluirn el papel de la privacidad, el
riesgo de hackeo y la baja significativa de empleos como chofer de taxi, triler o autobs.