Metodologia RUP - Aspectos importantes de la metodología RUP para principiantes PDF

Preview

Summary

Aspectos importantes de la metodología RUP para principiantes...

Description

ANÁLISIS DE SISTEMAS II

METODOLOGIA RUP (RATIONAL UNIFIED PROCESS) INTRODUCCIÓN. En la actualidad, la utilización de metodologías 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 elaboración de las aplicaciones, por lo tanto, seguir metodologías y estándares nos llevan a estar en competitividad en todo momento. Es de suma importancia conocer el modo como se interrelacionan metodologías con estándares y herramientas siguiendo un único propósito, el cual consiste en la elaboración de aplicaciones de manera eficiente, ordenada y con el menor número de defectos. La metodología RUP nos proporciona disciplinas en las cuales se encuentran artefactos con lo cual se podrá contar con guías para poder documentar e implementar de una manera fácil y eficiente, todas las guías para un buen desarrollo, todo esto dentro de las respectivas fases con las cuales cuenta. RESUMEN. Las metodologías y estándares utilizados en un desarrollo de software nos proporcionan las guías para poder conocer todo el camino a recorrer desde antes de empezar la implementación, con lo cual se asegura la calidad del producto final, así como también el cumplimiento en la entrega del mismo en un tiempo estipulado. Es de suma importancia elegir la metodología adecuada, así como las herramientas de implementación adecuadas, es por ello que la metodología RUP basada en UML nos proporciona todas las bases para llevar al éxito la elaboración del software, para ello la utilización de la herramienta RUP para el desarrollo rápido de aplicaciones. Este trabajo consta de siete capítulos, los cuales se describen a continuación: 

   



En el capítulo uno se abarcará la explicación de la metodología RUP con sus bases en el UML, las partes que la conforman, su funcionalidad; con lo cual podremos observar la interrelación entre ambos y la importancia de su uso en el desarrollo de aplicaciones. En el capítulo dos se abarcará lo que son las dimensiones de RUP dentro de ello específica los casos de uso y el proceso modelado a una arquitectura y los procesos iterativos. En el capítulo tres se abarca lo que son las fases y sus planeaciones los esfuerzos a los flujos de trabajo y a los de su respecto. En el capítulo cuatro se abarca lo que son las disciplinas como modelado de negocio, requerimientos, análisis, etc. En el capítulo cinco se abarca a lo que son las organizaciones del RUP como actores, artefactos y grados de artefacto. En el capítulo seis se trata de lo que es el Lenguaje Unificado de Modelado (UML) que se extiende hasta los casos de uso y diagramas y más ámbito de desarrollos de software. 1 - 25

ANÁLISIS DE SISTEMAS II

 

Y como final el capítulo siete se abarca a lo que son las metodologías de diseño y Análisis de software con RUP y UML.

Rational Unified Process (RUP) Las siglas RUP en ingles significa Rational Unified Process (Proceso Unificado de Racional) es un producto del proceso de ingeniería de software que proporciona un enfoque disciplinado para asignar tareas y responsabilidades dentro de una organización del desarrollo. Su meta es asegurar la producción del software de alta calidad que resuelve las necesidades de los usuarios dentro de un presupuesto y tiempo establecidos. Según Jacaboson, I., Booch, G., Rumbaugh J. (1998)1 El nombre Proceso Unificado se usa para describir el proceso genérico que incluye aquellos elementos que son comunes a la mayoría de los refinamientos existentes. También permite evitar problemas legales ya que Proceso Unificado de Rational o RUP son marcas registradas por IBM (desde su compra de Rational Software Corporation en 2003). Según Grady Booch(2000)2 un reflejo de lo que hemos visto en el trabajo con literalmente decenas de miles de proyectos en los últimos 20 años, la codificación de lo que funciona en las organizaciones exitosas y lo que está notablemente ausente en los fallidos. Capítulo 1: Historia. La Figura 1 ilustra la historia de RUP. El antecedente más importante se ubica en 1967 con la Metodología Ericsson (Ericsson Approach) elaborada por Ivar Jacobson, una aproximación de desarrollo basada en componentes, que introdujo el concepto de Caso de Uso. Entre los años de 1987 a 1995 Jacobson fundó la compañía Objectory AB y lanza el proceso de desarrollo Objectory (abreviación de Object Factory).

Figura 1: Historia de RUP Posteriormente en 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. 2 - 25

ANÁLISIS DE SISTEMAS II

Desde ese entonces y a la cabeza de Grady Booch, Ivar Jacobson y James Rumbaugh, Rational Software desarrolló e incorporó diversos elementos para expandir RUP, destacándose especialmente el flujo de trabajo conocido como modelado del negocio. En junio del 1998 se lanza Rational Unified Process. Autores Jacaboson, I., Booch, G., Rumbaugh J., El Proceso Unificado de Desarrollo de Software, 2000 Addison Wesley 2 Grady Booch, diseñador de software, un metodologista de software y entusiasta de diseño de patrones. Es director Científico de Rational Software (ahora parte de IBM) y editor de una serie de Benjamin/Cummings. Capítulo 2: Proceso de Desarrollo, Dimensiones del RUP. El RUP tiene 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 Lógicamente por la naturaleza. La primera dimensión representa el aspecto dinámico del proceso y se expresa en términos de fases, de iteraciones, y la finalización de las fases. La segunda dimensión representa el aspecto estático del proceso: cómo se describe en términos de componentes de proceso, las disciplinas, las actividades, los flujos de trabajo, los artefactos, y los roles. En la figura 2 se puede observar como varía 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 más tiempo en requerimientos, y en las últimas iteraciones pasamos más tiempo en poner en práctica la realización del proyecto en si.

Figura 2. Disciplinas, fases, iteraciones del RUP

3 - 25

ANÁLISIS DE SISTEMAS II

Se puede hacer mención de las tres características esenciales que definen al RUP: 2.1.- Características esenciales Los autores de RUP destacan que el proceso de software propuesto por RUP tiene tres características esenciales: está dirigido por los Casos de Uso, está centrado en la arquitectura, y es iterativo e incremental. 2.1.1.- Proceso dirigido por Casos de Uso Según Kruchten, P.(2000)3, los Casos de Uso son una técnica de captura de requisitos que fuerza a pensar en términos de importancia para el usuario y no sólo en términos de funciones que seria bueno contemplar. Se define un Caso de Uso como un fragmento de funcionalidad del sistema que proporciona al usuario un valor añadido. Los Casos de Uso representan los requisitos funcionales del sistema. En RUP los Casos de Uso no son sólo una herramienta para especificar los requisitos del sistema. También guían su diseño, implementación y prueba. Los Casos de Uso constituyen un elemento integrador y una guía del trabajo como se muestra en la Figura 3.

Figura 3: Los Casos de Uso integran el trabajo Los Casos de Uso4 no sólo inician el proceso de desarrollo sino que proporcionan un hilo conductor, permitiendo establecer trazabilidad entre los artefactos que son generados en las diferentes actividades del proceso de desarrollo. Como se muestra en la Figura 3, basándose en los Casos de Uso se crean los modelos de análisis y diseño, luego la implementación que los lleva a cabo, y se verifica que efectivamente el producto implemente adecuadamente cada Caso de Uso. Todos los modelos deben estar sincronizados con el modelo de Casos de Uso.

4 - 25

ANÁLISIS DE SISTEMAS II

Figura 4: Trazabilidad a partir de los Casos de Uso 2.1.2- Proceso centrado en la arquitectura La arquitectura de un sistema es la organización o estructura de sus partes más relevantes, lo que permite tener una visión común entre todos los involucrados (desarrolladores y usuarios) y una perspectiva clara delsistema completo, necesaria para controlar el desarrollo [Kru00]. La arquitectura involucra los aspectos estáticos y dinámicos más significativos del sistema, está relacionada con la toma de decisiones que indican cómo tiene que ser construido el sistema y ayuda a determinar en qué orden. Además la definición de la arquitectura debe tomar en consideración elementos de calidad del sistema, rendimiento, reutilización y capacidad de evolución por lo que debe ser flexible durante todo el proceso de desarrollo. La arquitectura se ve influenciada por la plataforma software, sistema operativo, gestor de bases de datos, protocolos, consideraciones de desarrollo como sistemas heredados. Muchas de estas restricciones constituyen requisitos no funcionales del sistema. En el caso de RUP además de utilizar los Casos de Uso para guiar el proceso se presta especial atención al establecimiento temprano de una buena arquitectura que no se vea fuertemente impactada ante cambios posteriores durante la construcción y el mantenimiento. Cada producto tiene tanto una función como una forma. La función corresponde a la funcionalidad reflejada en los Casos de Uso y la forma la proporciona la arquitectura. Existe una interacción entre los Casos de Uso y la arquitectura, los Casos de Uso deben encajar en la arquitectura cuando se llevan a cabo y la arquitectura debe permitir el desarrollo de todos los Casos de Uso requeridos, actualmente y en el futuro. Esto provoca que tanto arquitectura como Casos de Uso deban evolucionar en paralelo durante todo el proceso de desarrollo de software. En la Figura 5 se ilustra la evolución de la arquitectura durante las fases de RUP. Se tiene una arquitectura más robusta en las fases finales del proyecto. En las fases iniciales lo que se hace es ir consolidando la arquitectura por medio de baselines y se va modificando dependiendo de las necesidades del proyecto.

5 - 25

ANÁLISIS DE SISTEMAS II

Figura 5: Evolución de la arquitectura del sistema Es conveniente ver el sistema desde diferentes perspectivas para comprender mejor el diseño por lo que la arquitectura se representa mediante varias vistas que se centran en aspectos concretos del sistema, abstrayéndose de los demás. Para RUP, todas las vistas juntas forman el llamado modelo 4+1 de la arquitectura según Kruchten, P.(19986), el cual recibe este nombre porque lo forman las vistas lógica, de implementación, de proceso y de despliegue, más la de Casos de Uso que es la que da cohesión a todas.

Figura 6: Los modelos se completan, la arquitectura no cambia drásticamente Al final de la fase de elaboración se obtiene una baseline7 de la arquitectura donde fueron seleccionados una serie de Casos de Uso arquitectónicamente relevantes (aquellos que ayudan a mitigar los riesgos más importantes, aquellos que son los más importantes para el usuario y aquellos que cubran las funcionalidades significativas) Como se observa en la Figura 6, durante la construcción los diversos modelos van desarrollándose hasta completarse (según se muestra con las formas rellenas en la 6 - 25

ANÁLISIS DE SISTEMAS II

esquina superior derecha). La descripción de la arquitectura sin embargo, no debería cambiar significativamente (abajo a la derecha) debido a que la mayor parte de la arquitectura se decidió durante la elaboración. Se incorporan pocos cambios a la arquitectura (indicados con mayor densidad de puntos en la figura inferior derecha) [JBR00].8 2.1.3.- Proceso iterativo e incremental El equilibrio correcto entre los Casos de Uso y la arquitectura es algo muy parecido al equilibrio de la forma y la función en el desarrollo del producto, lo cual se consigue con el tiempo. Para esto, la estrategia que se propone en RUP es tener un proceso iterativo e incremental en donde el trabajo se divide en partes más pequeñas o mini proyectos. Permitiendo que el equilibrio entre Casos de Uso y arquitectura se vaya logrando durante cada mini proyecto, así durante todo el proceso de desarrollo. Cada mini proyecto se puede ver como una iteración (un recorrido más o menos completo a lo largo de todos los flujos de trabajo fundamentales) del cual se obtiene un incremento que produce un crecimiento en el producto. Una iteración puede realizarse por medio de una cascada como se muestra en la Figura 6. Se pasa por los flujos fundamentales (Requisitos, Análisis, Diseño, Implementación y Pruebas), también existe una planificación de la iteración, un análisis de la iteración y algunas actividades específicas de la iteración. Al finalizar se realiza una integración de los resultados con lo obtenido de las iteraciones anteriores.

Figura 7: Una iteración RUP El proceso iterativo e incremental consta de una secuencia de iteraciones. Cada iteración aborda una parte de la funcionalidad total, pasando por todos los flujos de trabajo relevantes y refinando la arquitectura. Cada iteración se analiza cuando termina. Se puede determinar si han aparecido nuevos requisitos o han cambiado los existentes, afectando a las iteraciones siguientes. Durante la planificación de los detalles de la siguiente iteración, el equipo también examina cómo afectarán los riesgos que aún quedan al trabajo en curso. Toda la retroalimentación de la iteración pasada permite reajustar los objetivos para las siguientes iteraciones. Se continúa con esta dinámica hasta que se haya finalizado por completo con la versión actual del producto. 7 - 25

ANÁLISIS DE SISTEMAS II

RUP divide el proceso en cuatro fases, dentro de las cuales se realizan varias iteraciones en número variable según el proyecto y en las que se hace un mayor o menor hincapié en los distintas actividades. En la Figura 8 se muestra cómo varía el esfuerzo asociado a las disciplinas según la fase en la que se encuentre el proyecto RUP.

Figura 8: Ciclo de vida Las primeras iteraciones (en las fases de Inicio y Elaboración) se enfocan hacia la comprensión del problema y la tecnología, la delimitación del ámbito del proyecto, la eliminación de los riesgos críticos, y al establecimiento de una baseline 10de la arquitectura. Durante la fase de inicio las iteraciones hacen ponen mayor énfasis en actividades modelado del negocio y de requisitos. En la fase de elaboración, las iteraciones se orientan al desarrollo de la baseline de la arquitectura, abarcan más los flujos de trabajo de requerimientos, modelo de negocios (refinamiento), análisis, diseño y una parte de implementación orientado a la baseline de la arquitectura. En la fase de construcción, se lleva a cabo la construcción del producto por medio de una serie de iteraciones. Para cada iteración se selecciona algunos Casos de Uso, se refina su análisis y diseño y se procede a su implementación y pruebas. Se realiza una pequeña cascada para cada ciclo. Se realizan tantas iteraciones hasta que se termine la implementación de la nueva versión del producto. En la fase de transición se pretende garantizar que se tiene un producto preparado para su entrega a la comunidad de usuarios. Como se puede observar en cada fase 8 - 25

ANÁLISIS DE SISTEMAS II

participan todas las disciplinas, pero que dependiendo de la fase el esfuerzo dedicado a una disciplina varía.

Figura 9. Fases del RUP Capítulo 3: Desarrollo de Etapas (Fases). El ciclo de vida del software del RUP se descompone en cuatro fases secuenciales (figura 9). En cada extremo de una fase se realiza una evaluación (actividad: Revisión del ciclo de vida de la finalización de fase) para determinar si los objetivos de la fase se han cumplido. Una evaluación satisfactoria permite que el proyecto se mueva a la próxima fase. 3.1.- Planeando las fases El ciclo de vida consiste en una serie de ciclos, cada uno de los cuales produce una nueva versión del producto, cada ciclo está compuesto por fases y cada una de estas fases está compuesta por un número de iteraciones, estas fases son: 3.1.1.- Concepción, Inicio o Estudio de oportunidad Define el ámbito y objetivos del proyecto Se define la funcionalidad y capacidades del producto. 3.1.2.- Elaboración Tanto la funcionalidad como el dominio del problema se estudian en profundidad Se define una arquitectura básica Se planifica el proyecto considerando recursos disponibles. 3.1.3.- Construcción El producto se desarrolla a través de iteraciones donde cada iteración involucra tareas de análisis, diseño e implementación Las fases de estudio y análisis sólo dieron una arquitectura básica que es aquí refinada de manera incremental conforme se construye (se permiten cambios en la estructura) Gran parte del trabajo es programación y pruebas. Se documenta tanto el sistema construido como el manejo del mismo. Esta fase proporciona un producto construido junto con la documentación.

9 - 25

ANÁLISIS DE SISTEMAS II

3.1.4.- Transición Se libera el producto y se entrega al usuario para un uso real Se incluyen tareas de marketing, empaquetado atractivo, instalación, configuración, entrenamiento, soporte, mantenimiento, etc. Los manuales de usuario se completan y refinan con la información anterior, estas tareas se realizan también en iteraciones Todas las fases no son idénticas en términos de tiempo y esfuerzo. Aunque esto varía considerablemente dependiendo del proyecto, un ciclo de desarrollo inicial típico para un proyecto de tamaño mediano debe anticipar la distribución siguiente el esfuerzo y horario:

Tabla I. Esfuerzo-horario contra fases del RUP Lo cual se puede representar gráficamente como se muestra en la figura 10:

Figura 10. Recursos utilizados en las fases del RUP en el tiempo. El modelo cascada según Winston Royce(1970)13, es un secuencial modelo del desarrollo del software (un proceso para la creación del software) en que el desarrollo se considera como fluyendo constantemente hacia abajo (como a cascada) con las fases de análisis de requisitos, diseño, puesta en práctica, prueba (validación), integración, y mantenimiento. Las fases de concepción y elaboración serían considerablemente más pequeñas. Algunas herramientas que pueden automatizar una cierta porción del esfuerzo de la fase de construcción pueden atenuar esto, haciendo que la fase de construcción sea mucho más pequeña que las fases de concepción y elaboración juntas. Este es precisamente el objetivo del trabajo. Cada paso con las cuatro fases produce una generación del software. A menos que el producto "muera", se desarrollará nuevamente repitiendo la misma secuencia las fases de concepción, elaboración, construcción y transición, pero con diversos énfasis cada fase.

10 - 25

ANÁLISIS DE SISTEMAS II

Estos ciclos subsecuentes se llaman los ciclos de la evolución. Mientras que el producto pasa durante varios ciclos, se producen las nuevas generaciones. En la figura 11 se muestre este ciclo evolutivo.

Figura 11. Ciclo evolutivo en la elaboración de software basado en el RUP Los ciclos evolutivos pueden ser iniciados por las mejoras sugeridas por el usuario, cambios en el contexto del usuario, cambios en la tecnología subyacente, reacción a la competición, etcétera. Los ciclos evolutivos tienen típicamente fases de concepción y elaboración mucho más cortas, puesto que la definición y la arquitectura básicas del producto son determinadas por los ciclos de desarrollo anteriores. Las excepciones a esta regla son los ciclos evolutivos en los cuales ocurre o surge un producto significativo o una redefinición arquitectónica. 3.1.4.1.- Esfuerzo respecto de los flujos de trabajo En la figura 5 se muestran ciertos porcentajes, de forma vertical se muestra el esfuerzo que se tiene que realizar por cada una de las disciplinas o flujos de trabajo14, y los dos porcentajes que ...