Comprendiendo RUP

Por: Byron Quisquinay

¿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.

¡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. Develop software iteratively. Desarrollar Software de forma Iterativa.

2. Manage requirements. Administrar los requerimientos.

3. Use component-based architectures. Utilizar arquitecturas basadas en componentes.

4. Visually model software. Modelado visual del Software.

5. Continuously verify software quality. Verificación continua de la calidad del Software.

6. Control changes to software. Control del cambio de Software.

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.

Desarrollo en forma Iterativa,

sus beneficiosLos 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. 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.

2. Además alienta a la retroalimentación del usuario, con lo que se lograría llegar el desarrollo al ideal

esperado.

3. 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.

4. Las pruebas constantes permiten la definición asertiva del estatus del proyecto.

5. Las inconsistencias entre lo requerido, lo diseñado y lo implementado son detectadas de forma

temprana.

6. La carga de trabajo en especial del grupo de pruebas es distribuida a lo largo del ciclo de vida del

proyecto.

7. El equipo pude aplicar la experiencia adquirida e irlos implementando continuamente en el proceso.

8. 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.

Administración de

RequerimientosLos 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. 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.

2. Además alienta a la retroalimentación del usuario, con lo que se lograría llegar el desarrollo al ideal

esperado.

3. 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.

4. Las pruebas constantes permiten la definición asertiva del estatus del proyecto.

5. Las inconsistencias entre lo requerido, lo diseñado y lo implementado son detectadas de forma

temprana.

6. La carga de trabajo en especial del grupo de pruebas es distribuida a lo largo del ciclo de vida del

proyecto.

7. El equipo pude aplicar la experiencia adquirida e irlos implementando continuamente en el proceso.

8. 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.

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.


¿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.

Modelado Visual del Software

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.

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.

Verificación continua de la

Calidad del SoftwareEl 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.

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.

RUP, sus tres entidades

fundamentales.

Trabajadores

• ¿Quién?

Actividades

• ¿Cómo?

Artefactos

• ¿Hace qué?

RUP, sus tres entidades

fundamentales…

Artefactos

Actividades

Trabajadores

Que fundamentalmente es Quién hace qué y de qué manera…

Flujo

Y el Flujo de trabajo (workflow que identifica el ¿Cuándo?)

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.

Ciclo del Proceso

Comprendiendo RUP

Education

Transcript of Comprendiendo RUP