Presentación sobre RUP

1. Por: Byron Quisquinay

2. ¿Qué es?
Una vez más nos encontramos frente a un concepto, herramienta o moda en la
administración de IT.
El que ahora nos compete es RUP que viene del inglés: Rational Unified Process, que
es el Proceso Unificado «Rational» y ésta última sigla no traducible por ser un nombre propio, en
sí es una marca. Y se define como un Proceso de Ingeniería de Software.
Sus creadores y comercializadores indican que este Proceso Unificado, reúne las
mejores prácticas de la industria del Desarrollo de Software.
Hay que tener en cuenta que: Rational, el logo de Rational y Rational Unified Process
son marcas registradas de la Corporación de Software: Rational, en los Estados Unidos y en
otros países.
El objetivo según ellos indican de este «Proceso» es producir en un
calendario, presupuesto y alta calidad predecibles acorde a las necesidades de los usuarios.

3. ¡Conceptos, conceptos,
conceptos!
¿Mejores prácticas?
Cuando se evalúan las actividades (métodos, procedimientos)
«normados» que utiliza una empresa, institución, entidad o similar agrupación, que en
comparación con el resto, resultan ser las mejores en la producción o prestación de un bien o
servicio.
¿Cuáles son las mejores prácticas entonces que encierra RUP?
1.
2.
3.
4.
5.
6.
Develop software iteratively.
Manage requirements.
Use component-based architectures.
Visually model software.
Continuously verify software quality.
Control changes to software.
Desarrollar Software de forma Iterativa.
Administrar los requerimientos.
Utilizar arquitecturas basadas en componentes.
Modelado visual del Software.
Verificación continua de la calidad del Software.
Control del cambio de Software.

4. Desarrollo en forma Iterativa
Iterativa significa que es de forma «repetida, reiterada, insistida, insistente o renovada», es
decir como en un «loop» o «bucle». Pero esta buena práctica está complementada con la
INCREMENTALIDAD de esas iteraciones.

5. Desarrollo en forma Iterativa,
sus beneficios
Los beneficios adquiridos de una programación que no se hace de una sola vez, más bien, se hace en
varias fases presentables y comprobables, que van creciendo en madurez. Deberían ser:
1.
2.
3.
4.
5.
6.
7.
8.
Los malos entendidos son evidentes de forma temprana en el ciclo de vida iterativo e
incremental, cuándo aún es posible reaccionar a ellos.
Además alienta a la retroalimentación del usuario, con lo que se lograría llegar el desarrollo al ideal
esperado.
El equipo de trabajo es forzado a enfocarse en aquellos aspectos que son realmente importantes para
el proyecto. Y alejarse de aquellos que resultan en distractores que los alejan de los riesgos reales del
proyecto.
Las pruebas constantes permiten la definición asertiva del estatus del proyecto.
Las inconsistencias entre lo requerido, lo diseñado y lo implementado son detectadas de forma
temprana.
La carga de trabajo en especial del grupo de pruebas es distribuida a lo largo del ciclo de vida del
proyecto.
El equipo pude aplicar la experiencia adquirida e irlos implementando continuamente en el proceso.
Los participantes en el proyecto pueden obtener evidencia concreta del mismo avance a través del
ciclo de vida que recorre de forma iterativa e incremental.

8. Administración de
Requerimientos
Los beneficios adquiridos de una programación que no se hace de una sola vez, más bien, se hace en
varias fases presentables y comprobables, que van creciendo en madurez. Deberían ser:
1.
2.
3.
4.
5.
6.
7.
8.
Los malos entendidos son evidentes de forma temprana en el ciclo de vida iterativo e
incremental, cuándo aún es posible reaccionar a ellos.
Además alienta a la retroalimentación del usuario, con lo que se lograría llegar el desarrollo al ideal
esperado.
El equipo de trabajo es forzado a enfocarse en aquellos aspectos que son realmente importantes para
el proyecto. Y alejarse de aquellos que resultan en distractores que los alejan de los riesgos reales del
proyecto.
Las pruebas constantes permiten la definición asertiva del estatus del proyecto.
Las inconsistencias entre lo requerido, lo diseñado y lo implementado son detectadas de forma
temprana.
La carga de trabajo en especial del grupo de pruebas es distribuida a lo largo del ciclo de vida del
proyecto.
El equipo pude aplicar la experiencia adquirida e irlos implementando continuamente en el proceso.
Los participantes en el proyecto pueden obtener evidencia concreta del mismo avance a través del
ciclo de vida que recorre de forma iterativa e incremental.

9. Arquitectura de Componentes(1)
Una solución de IT, tiene distintos puntos de vista basado en el participante o actor que lo evalúa, así pues,
un usuario tendrá una concepción de la solución informática, el programador tendrá otra y así
sucesivamente.
Indican pues, que la clave para conciliar estos puntos de vista de la solución, radica en la arquitectura que
se empleará para la construcción (de la solución informática) . Y unidos los puntos de vista o expectativas
(requisitos) de los participantes y/o actores con una programación iterativa e incremental son la mezcla
idónea que fijará los objetivos revisables en cada iteración. Es decir, el horizonte está fijado por las
definiciones funcionales que nacen de la fusión de las expectativas de cada participante del proyecto.
La definición de una arquitectura te permite pues tomar decisiones sobre los siguientes aspectos:
•
•
•
•
•
Cómo está organizado el Sistema (o cómo se organizará).
La selección de los elementos estructurales y sus interfaces por los cuales está compuesto el Sistema.
El comportamiento, especificado por la colaboración de esos elementos.
La composición de esos elementos estructurales y funcionales dentro de grandes y progresivos Sub
Sistemas.
El estilo de arquitectura que guía la organización: esos elementos, sus interfaces, su colaboración y su
composición.

10. Arquitectura de Componentes(2)
¿Qué arquitecturas están basadas en el? …Desarrollo basado en componentes
(CBD: Component-based development) …
•
•
•
•
Component-based development (COM) , de Microsoft.
The Object Management Group's (OMG).
Common Object Request Broker Architecture (CORBA).
Sun Micro-systems' Enterprise Java-Beans (EJB).
El valor de una arquitectura de componentes, es que los mismos pueden ser
reutilizados en distintas soluciones. Es decir, una solución puede estar disponible
como módulo para las siguientes solicitudes.

11. Arquitectura de Componentes(2)
¿Qué arquitecturas están basadas en el? …Desarrollo basado en componentes
(CBD: Component-based development) …
•
•
•
•
Component-based development (COM) , de Microsoft.
The Object Management Group's (OMG).
Common Object Request Broker Architecture (CORBA).
Sun Micro-systems' Enterprise Java-Beans (EJB).
El valor de una arquitectura de componentes, es que los mismos pueden ser
reutilizados en distintas soluciones. Es decir, una solución puede estar disponible
como módulo para las siguientes solicitudes.

12. Arquitectura de Componentes(3)

13. Modelado Visual del Software
El modelo es la simplificación de la realidad y que presenta al Sistema desde una perspectiva.
Construimos modelos de tal suerte que podamos entender mejor el Sistema que se está modelando y dado
que no podemos comprender de forma completa lo complejo de los Sistemas o los Sistemas complejos.
Modelar es importante puesto que esto permite a los desarrolladores, visualizar, especificar, construir y
documentar la estructura y el comportamiento de la arquitectura del software. Y esto constituye un medio
sin ambigüedad, que permitirá la comunicación hacia el resto del equipo.

15. Verificación continua de la
Calidad del Software
El no tener un programa de control de calidad del producto entregado, en este
caso, software, generará a través del tiempo un costo más alto que si se le
monitorease y corrigiese de forma iterativa. Los elementos que deberían
monitorearse deberían ser: funcionalidad, eficiencia de la aplicación (presta el
soporte que se supone al proceso del negocio) y eficiencia del Sistema (cómo la
aplicación impacta a la eficiencia de ejecución de su entorno de IT).
Esta verificación involucra el tener definidos Escenarios Clave (key scenario) que
representarán aspectos funcionales del Sistema y que evidenciarán que la
iteración y el desarrollar de forma incremental están cumpliendo con el objetivo de
un avance significativo y asertivo del proyecto.

16. Control de Cambios
Uno de los retos claves al trabajar con equipos de desarrolladores que se
conforman en grupos que participan en distintas iteraciones del desarrollo, en
distintitas versiones, productos y plataformas, es realizarlo de forma
armónica, ordenada y disciplinada de manera que no reine el caos.
Entonces la coordinación permitirá el empleo eficiente de los recursos basado en
las prioridades y riesgos del proyecto. Entonces esta práctica de poder controlar
los cambios de la mano con la iteración, permitirá el manejo del impacto derivado
de los cambios y garantizar la trazabilidad de los mismos.
Para ello es necesario un control entre iteración y versión entregable del proyecto.

18. RUP, sus tres entidades
fundamentales.
Trabajadores
Actividades
Artefactos
• ¿Quién?
• ¿Cómo?
• ¿Hace qué?

20. RUP, sus tres entidades
fundamentales…
Que fundamentalmente es Quién hace qué y de qué manera…
Trabajadores
Flujo
Actividades
Artefactos
Y el Flujo de trabajo (workflow que identifica el ¿Cuándo?)

21. RUP, en pocas líneas.
1. El Proceso Unificado de Rational, es el Proceso de Desarrollo de Software que cubre todo
el ciclo de vida del Software en sí.
2. El producto de este proceso, resulta en una riqueza en conocimiento, siempre actualizado.
3. Así pues trae consigo una guía basada en varias técnicas, un acercamiento a la tecnología
basada en objetos, en el desarrollo basado en componentes, el modelado bajo UML, la
definición de una arquitectura, desarrollo iterativo y así sucesivamente.
4. No es un producto estático o congelado, más bien, es algo vivo en constante actualización.
5. Está basado en un proceso sólido de arquitectura y permite a una organización de
desarrollo configurarlo y confeccionarlo justo a la medida de sus necesidades.
6. Además soporta las seis mejores prácticas en desarrollo de software:
1. Desarrollo iterativo.
2. Administración de requerimientos.
3. Arquitectura basada en componentes.
4. Modelado visual del software.
5. Verificación continua de la calidad del Software.
6. Control de Cambios.
7. Está respaldado por una paleta extensiva de herramientas desarrolladas por Rational
Software.

22. Ciclo del Proceso