RUP Caracteristicas

RUP

RUP es una metodología que tiene como objetivo ordenar y estructurar el desarrollo de software, en la cual se tienen un conjunto de actividades necesarias para transformar los requisitos del usuario en un sistema Software (Amo, Martínez y Segovia, 2005). Inicialmente fue llamada UP (Unified Process) y luego cambió su nombre a RUP por el respaldo de Rational Software de IBM. Ésta metodología fue lanzada en 1998 teniendo como sus creadores a Ivar Jacobson, Grady Booch y James Rumbaugh. El RUP nació del UML (Unified Modeling Language) y del UP (Sommerville, 2005).

Características del RUP

El RUP es un proceso basado en los modelos en Cascada y por Componentes, el cual presenta las siguientes características: Es dirigido por los casos de uso, es centrado en la arquitectura, iterativo e incremental (Booch, Rumbaugh y Jacobson, 2000), lo cual es fundamental para el proceso de desarrollo de software.

• Dirigido por Casos de Uso: –Los casos de uso son los artefactos primarios para establecer el comportamiento deseado del sistema

• Centrado en la Arquitectura: –La arquitectura es utilizada para conceptualizar, construir, administrar y evolucionar el sistema en desarrollo

• Iterativo e Incremental:

–Maneja una serie de entregas ejecutables

–Integra continuamente la arquitectura para producir nuevas versiones mejoradas

• Conceptualmente amplio y diverso

• Enfoque orientado a objetos

• En evolución continua

• Adaptable

• Repetible

• Permite mediciones:

–Estimación de costos y tiempo, nivel de avance, etc.

a) Casos de Uso: Describe un servicio que el usuario requiere del sistema, incluye la secuencia completa de interacciones entre el usuario y el sistema.

b) Centrado en la arquitectura: Comprende las diferentes vistas del sistema en desarrollo, que corresponden a los modelos del sistema: Modelos de casos de uso, de análisis, de diseño, de despliegue e implementación. La arquitectura del software es importante para comprender el sistema como un todo y a la vez en sus distintas partes (Abrahamsson, Salo, Ronkainen y Warsta, 2002), sirve para organizar el desarrollo, fomentar la reutilización de componentes y hacer evolucionar el sistema, es decir, agregarle más funcionalidad (Pressman y Murrieta, 2006)

En la figura 1 se aprecia la forma en que los modelos de la arquitectura se completan en cada ciclo, ejemplo: se ve en la “línea base de la arquitectura” que la barra que denota el modelo de despliegue está clara e incompleta, evidenciándose una implementación parcial del sistema, lo cual mostraría solo algunas funciones y propiedades del software en construcción. A esta parcialidad en la implementación se le conoce como arquitectura ejecutable. En la misma gráfica que se encuentra arriba se ve la misma barra pero un poco más oscura, lo cual muestra que el modelo se ha estado mejorando progresivamente, mostrando que durante la construcción los diferentes modelos se van desarrollando hasta completarse.

De igual forma se aprecia la misma barra en la “línea base al final de la construcción” en la cual se ve la barra del modelo de despliegue completa y con un color más oscuro, esto obedece a los refinamientos sucesivos que hace la metodología RUP a la arquitectura ejecutable, proporcionando de esta manera un prototipo evolutivo y funcional. De la misma manera la arquitectura como tal no cambia drásticamente pues gran parte de la arquitectura se definió durante la fase de elaboración, pero puede agregar modelos así como lo muestra la gráfica con la adición del modelo de pruebas a la misma arquitectura:

Figura 1. Arquitectura RUP. Fuente: Adaptado de RUP (Booch, Rumbaugh y Jacobson, 2000)

c) Iterativo e Incremental: Significa que la aplicación se divide en pequeños proyectos, los cuales incorporan una parte de las especificaciones, y el desarrollo de la misma es una iteración que va incrementando la funcionalidad del sistema de manera progresiva (Silva, Barrera, Arroyave y Pineda, 2007)

Tal como lo muestra la figura 2, una iteración está compuesta por los requisitos, análisis, diseño, implementación y pruebas; pero dicha iteración sólo entrega una parte pequeña pero funcional del sistema, de tal forma que los requisitos y demás modelos no se desarrollan en una sola iteración sino progresivamente, ello con la finalidad de poder garantizar entregas funcionales e iterativas y de tal forma ir completando el sistema software paso a paso. Cabe aclarar que una iteración también incluye otros artefactos que no están explícitamente en la gráfica, tales como la planificación y el análisis de la iteración, entre otras actividades específicas concebidas dentro de esa iteración.

Las Iteraciones en RUP. Fuente: Adaptado de RUP (Booch, Rumbaugh y Jacobson, 2000)

Estructura del RUP

El proceso del RUP se ejecuta en tres perspectivas: La perspectiva dinámica, la cual contiene las fases del modelo sobre el tiempo; la estática que muestra las actividades del proceso y la práctica, que muestra las buenas prácticas durante el proceso del RUP (IBM, s. f.)

La figura 3 muestra la estructura de RUP y la forma en que se relacionan sus tres perspectivas. En ésta se aprecia la forma en que las disciplinas se aplican a cada una de las fases hasta lograr su completitud, y a su vez, cómo cada fase se completa de forma iterativa para así avanzar a la fase siguiente. De igual forma se aprecia que la perspectiva de buenas prácticas está en un eje “z” que es transversal a las perspectivas dinámica “x” y estática “ y ”, funcionando de manera permanente en el proceso de desarrollo de software.

En cuanto a tiempo el ciclo de vida de RUP se descompone en 4 FASES secuenciales, cada cual concluye con un producto intermedio.

Al terminar cada fase se realiza una evaluación para determinar si se ha cumplido o no con los objetivos de la misma.

Estructura de RUP. Fuente: Adaptado de RUP (IBM, s. f.)

Para aclarar esta relación, a continuación se presenta una descripción de las tres perspectivas:

a) La perspectiva dinámica se compone por las fases de Inicio, Elaboración, Construcción y Transición, cada fase se subdivide en iteraciones (Rational Software Corporation, 1998) y comprenden los siguientes objetivos:

• Fase de inicio: Su objetivo es la comunicación con el cliente y las actividades de planeación. Se establece el caso del negocio para el sistema, así como la identificación de todas las entidades externas que interactúan con el sistema y sus respectivas iteraciones.

• Fase de elaboración: Tiene como fin desarrollar un entendimiento del dominio del problema, crear un marco de trabajo arquitectónico para el sistema, desarrollar el plan del proyecto e identificar los riesgos claves. Al finalizar esta fase se debe tener el modelo de requerimientos del sistema (UML), una arquitectura y un plan de desarrollo.

• Fase de construcción: Su objetivo es el diseño del sistema, la programación, las pruebas y la integración de todas las partes del sistema software. Al final de esta fase se debe tener un software operativo con su respectiva documentación.

• Fase de transición: En esta fase el sistema software se entrega a los usuarios finales para sus respectivas pruebas en un entorno real. Al terminar esta fase se debe tener un software documentado y funcionando correctamente.

b) La perspectiva estática define dentro del proceso de desarrollo de software el quién hace qué, cómo y cuándo (Booch, Jacobsony Rumbaugh, 2006). El “quién” corresponden a los roles, el “qué” y el “cómo” corresponde a las actividades y artefactos, y el “cuándo” corresponde al flujo de trabajo. Para ello es necesario tener claro los siguientes elementos:

• Roles: Definen el comportamiento y las responsabilidades de cada individuo o de un grupo. Una persona puede desempeñar varios roles y un rol puede ser desempeñado por varias personas. Los roles definidos en RUP son: Analistas, desarrolladores, gestores, apoyo, especialista en pruebas y cualquier otro rol del cual se tuviera necesidad.

• Actividades: Es una unidad de trabajo que una persona que desempeña un rol puede realizar. Las actividades tienen objetivos concretos tales como: Planear una iteración, revisar el diseño, ejecutar pruebas de rendimiento, entre otras.

• Artefactos: También denominado producto, es un modelo de información que es producido o modificado durante el proceso de desarrollo de software. Los artefactos son los resultados tangibles del proyecto, las cosas que se van creando y usando hasta tener el producto software terminado. Algunos artefactos pueden ser: un modelo de casos de uso, el documento de la arquitectura, etc.

• Flujo de trabajo: Es la relación entre los roles y los artefactos o productos que producen resultados observable en el desarrollo del sistema software. Estos se dividen en flujos de trabajo de proceso y flujos de trabajo de soporte, los primeros reflejan actividades propias del modelo en cascada y contiene el modelado de negocios, requerimientos, análisis y diseño, implementación, pruebas y despliegue; y los segundos contienen la configuración

...