Rup

1

RATIONAL UNIFIED PROCESS Fernando López Moscoso [email protected] Abstract—RUP es la metodología más utilizada para el desarrollo de software, en este ámbito analizaremos sus distintas características y fundamentos, para poder develar las ventajas y desventajas a la hora de implementar la metodología RUP en el desarrollo de sistemas.

I. INTRODUCCIÓN RUP o proceso unificado es un proceso unificado para desarrollo de software, RUP constituye la metodología estándar más utilizada para el análisis, diseño, implementación y documentación de sistemas orientados a objetos. Como señalamos RUP no es un sistema con pasos predefinidos si no es un conjunto de metodologías adaptables al contexto y las necesidades de cada organización. II. ANTECEDENTES HISTÓRICOS

A mediados de la década de los 80’s se contempló la idea de la crisis del software, hecho que hizo evidente la necesidad de un paradigma mejor para el diseño de software. El paradigma orientado a objetos probó ser la solución. Y durante los 10 años siguientes se publicaron más de 50 metodologías diferentes, dentro de las cuales destacaron el método de Botch, el Objectory de Jacobson y la técnica OMT de Rumbaugh. Botch, Jacobson y Rumbaugh unieron esfuerzos para publicar una metodología completa de análisis y diseño orientado a objetos que unificara sus tres metodologías, esta fue denominada como rational unified process, la palabra “Rational” se usó porque ellos trabajaban para Rational Inc. no porque las otras propuestas fueran irracionales. En 1999 publicaron su libro proceso unificado de desarrollo de software o (USDP), el término proceso unificado se utiliza como abreviación en la actualidad. 

III.

EL PROCESO UNIFICADO Y SUS FASES

Como señalo anteriormente RUP constituye una metodología para el desarrollo de software dentro del mismo podemos identificar cuatro fases diferentes en el proceso del software Inicio. El objetivo de esta fase es establecer un caso de negocio para el sistema. Se deben identificar todas las entidades externas (personas y sistemas) que interactuarán con el sistema y definir estas interacciones. Esta información se utiliza entonces para evaluar qué aporte hace el sistema al negocio. Si este aporte es de poca importancia, se cancela el proyecto. R.U.P.: Sus Fases Elaboración. Los objetivos de esta fase son comprender el dominio del problema para poder establecer un marco de trabajo arquitectónico del sistema a desarrollar. Identificar los riesgos clave del proyecto. Al terminar esta fase, conseguimos un modelo de los requerimientos del sistema (se especifican los casos de uso en UML), una descripción arquitectónica y un plan de desarrollo del software. Construcción. Esta fase comprende el diseño del sistema, la programación, las pruebas. En esta fase se desarrollan e integran las partes del sistema. Al terminarla, obtenemos el sistema funcional y su respectiva documentación. Transición: Es la fase final donde se cambia de la etapa de desarrollo a la implementación del usuario y para que este trabaje en un entorno real. Esta actividad constituye un alto costo y problemática. Como resultado tenemos un Sistema de Software documentado, que funciona correctamente en su entorno operativo. Como complemento RUP emplea a UML como medio de comunicación entre el área de los desarrolladores con los usuarios finales para facilitar

2

la comprensión del sistema y así avanzar en sus fases. IV. DIMENSIONES DE RUP

dimensiones La primera dimensión representa el aspecto dinámico del proceso conforme se va desarrollando, en esta apreciamos las fases e iteraciones. La segunda dimensión representa el aspecto estático del proceso: cómo es descrito en términos de componentes del proceso, disciplinas, actividades, flujos de trabajo, artefactos y roles. V. CARACTERÍSTICAS DEL RUP Las principales características a resaltar de RUP son las siguientes • Forma disciplinada de asignar tareas y responsabilidades (quién hace qué, cuándo y cómo) • Pretende implementar las mejores prácticas en Ingeniería de Software • Desarrollo iterativo • Administración de requisitos • Uso de arquitectura basada en componentes • Control de cambios • Modelado visual del software • Verificación de la calidad del software VI. ARTEFACTOS

Fig1 Esfuerzo de actividades según las fases del proyecto En la figura 1 podemos apreciar las fases de desarrollo, el tiempo y las iteraciones. · El eje horizontal representa el tiempo y muestra los aspectos del ciclo de vida del proceso a lo largo de su desenvolvimiento · El eje vertical representa los workflows o flujos de trabajo los cuales agrupan las actividades de acuerdo a su naturaleza y de manera lógica. En este ejemplo se dividen los workflows de proceso y de soporte De esta representación podemos diferenciar dos

Un artefacto se refiere a los resultados tangibles que genera el desarrollo del software, como los diagramas UML que ayudan a comprender la funcionalidad del sistema, e incluso puede referirse a un producto terminable como el código ejecutable RUP en cada una de sus fases (pertenecientes a la estructura dinámica) realiza una serie de artefactos que sirven para comprender la funcionalidad del sistema. Entre dichos artefactos generados podemos resaltar los siguientes:: Inicio: • Documento Visión • Especificación de Requisitos Elaboración:

3 • Diagramas de caso de uso Construcción: • Documento Arquitectura que trabaja con las siguientes vistas: Vista Lógica o Diagrama de clases o Modelo E-R (Si el sistema así lo requiere) Vista de Implementación o Diagrama de Secuencia o Diagrama de estados o Diagrama de Colaboración Vista Conceptual o Modelo de dominio Vista física o Mapa de comportamiento a nivel de hardware.

VII.

DESARROLLO ITERATIVO E INCREMENTAL

El Proceso Unificado es un marco de desarrollo iterativo e incremental, es decir es una implementación del modelo de desarrollo en espiral, como lo señalamos anteriormente las cuatro fases son divididas por una serie de iteraciones. Estas iteraciones nos ofrecen como resultado un incremento paulatino en el sistema que se está desarrollando. Cada una de estas iteraciones se divide a su vez en una serie de disciplinas asociadas al ciclo de vida clásico o en cascada de desarrollo de software: Análisis de requisitos, Diseño, Implementación y Prueba. Aunque todas las iteraciones suelen incluir trabajo en casi todas las disciplinas, el grado de esfuerzo dentro de cada una de ellas varía a lo largo del proyecto y dependiendo de la fase en que se encuentre. Como ejemplo la etapa inicial en proyectos grandes se torna bastante extensa por la ingeniería de requerimientos que se emplea. Vale resaltar que todo el proceso iterativo de RUP, proviene de los principales aportes que lo inspiraron, como es el ciclo de vida en espiral de Barry Boehm. Ken Hartman.

VIII. DIRIGIDO

PARA LOS CASOS DE USO

Un sistema de software se crea para satisfacer las necesidades de los usuarios. Por lo tanto, para construir un sistema exitoso se debe conocer qué es lo que quieren y necesitan los usuarios prospectos, es por esto que se utilizan los casos de uso para facilitar su comprensión y para poder definir las metas u objetivos que el sistema pretende alcanzar. Un caso de uso es un artefacto que explica una parte de la funcionalidad del sistema Los casos de uso capturan los requerimientos funcionales. Dentro de UML este conjunto constituye el modelo de casos de uso el cual describe la funcionalidad completa del sistema. Este modelo reemplaza la tradicional especificación funcional del sistema. Para aclarar una especificación funcional tradicional se concentra en responder la pregunta: ¿Qué se supone que el sistema debe hacer? La estrategia de casos de uso puede ser definida agregando tres palabras al final de la pregunta: ¿por cada usuario? Estas tres palabras tienen una implicación importante, nos fuerzan a pensar en términos del valor a los usuarios y no solamente en términos de las funciones que sería bueno que tuviera. Sin embargo, los casos de uso no son solamente una herramienta para especificar los requerimientos del sistema, también dirigen su diseño, implementación y pruebas, esto es, dirigen el proceso de desarrollo. Aún y cuando los casos de uso dirigen el proceso, no son elegidos de manera aislada. Son desarrollados a la par con la arquitectura del sistema, esto es, los casos de uso dirigen la arquitectura del sistema y la arquitectura del sistema influencia la elección de los casos de uso. Por lo tanto, al arquitectura del sistema y los casos de uso maduran conforme avanza el ciclo de vida. IX.

RUP ESTÁ CENTRADO EN LA ARQUITECTURA

En términos conceptuales podríamos señalar que la arquitectura de un sistema son las diferentes vistas del sistema que se está construyendo. De esta forma podemos ver que el papel del arquitecto de sistemas

4

está centrado en la elaboración de la estructura del sistema a nivel conceptual, proporcionando de esta manera los diferentes puntos de vista para que los programadores elaboren el sistema. En este sentido podemos recalcar que RUP está centrado en la arquitectura de los sistemas dado que todo lo que se desarrolle debe ser previamente diseñado.

resultados de cada iteración, en especial los de la fase de Elaboración deben ser seleccionados en un orden que asegure que los riesgos principales son considerados primero.

El concepto de arquitectura de software involucra los aspectos estáticos y dinámicos más significativos del sistema. La arquitectura surge de las necesidades de la empresa, tal y como las interpretan los usuarios y otros stakeholders, y tal y como están reflejadas en los casos de uso. Sin embargo, también está influenciada por muchos otros factores, tales como la plataforma de software en la que se ejecutará, la disponibilidad de componentes reutilizables, consideraciones de instalación, sistemas legados, requerimientos no funcionales (ej. desempeño, confiabilidad). La arquitectura es la vista del diseño completo con las características más importantes hechas más visibles y dejando los detalles de lado. Ya que lo importante depende en parte del criterio, el cual a su vez viene con la experiencia, el valor de la arquitectura depende del personal asignado a esta tarea. Sin embargo, el proceso ayuda al arquitecto a enfocarse en las metas correctas, tales como claridad (understandability), flexibilidad en los cambios futuros (resilience) y reúso.

Es muy útil para ser aplicado en proyectos bastante extensos, debido a que proporciona un lenguaje común para la comprensión del cliente o entre desarrolladores y el proceso que este plantea es muy completo y ayuda a documentar de manera apropiada dichos sistemas

Los casos de uso se relacionan con la arquitectura en la forma en que un producto puede tener una función y forma. Pero uno sólo de los dos no es suficiente. Estas dos fuerzas deben estar balanceadas para obtener un producto exitoso. En este caso función corresponde a los casos de uso y forma a la arquitectura. Existe la necesidad de intercalar entre casos de uso y arquitectura. Es un problema del “huevo y la gallina”. Por una parte, los casos de uso deben, cuando son realizados, acomodarse en la arquitectura. Por otra parte, la arquitectura debe proveer espacio para la realización de todos los casos de uso, hoy y en el futuro. En la realidad, ambos arquitectura y casos de uso deben evolucionar en paralelo.enfocado en los riesgos El Proceso Unificado requiere que el equipo del proyecto se centre en identificar los riesgos críticos en una etapa temprana del ciclo de vida. Los

X. VENTAJAS DE RUP

Otro aspecto a resaltar es que nos permite asignar tareas y responsabilidades (¿quién?, ¿cuándo? y ¿cómo?), permitiendo así una buena gestión a lo largo del desarrollo de las aplicaciones XI. DESVENTAJAS DE RUP Por el grado de complejidad puede no resultar muy adecuado implementar RUP en proyectos pequeños, debido a que el esfuerzo y el tiempo dedicado no es muy rentable si se lo puede lograr de manera más sencilla. El RUP es generalmente mal aplicado en el estilo cascada. Requiere conocimientos del proceso y de UML. XII. CONCLUSIONES La metodología RUP proporciona una serie de conceptos bastante útiles y aplicables para la correcta elaboración de software como que este está dirigido a los casos de uso lo cual facilita la definición de metas y el entendimiento del sistema por parte de los clientes o usuarios potenciales, además ser centra en la arquitectura y de esta manera podemos observar de mejor forma en que ambiente donde será desarrollado el sistema y su desarrollo es iterativo e incremental lo cual nos permite evitar errores en la etapa de desarrollo del sistema. Sin mencionar que este incluye UML y gracias a esto la documentación del sistema es bastante extensa y entendible.

5

Sin lugar a dudas es una metodología ideal para implementar en proyectos bastante extensos por las bondades que incluye, pero no es muy recomendable para proyectos pequeños si el principal factor de riesgo del proyecto es el tiempo o la cantidad de recursos disponibles.

• •

• •

•

• •

•

•

XIII. REFERENCIAS http://www.ia.uned.es/ia/asignaturas/adms/ GuiaDidADMS/node60.html http://books.google.com.bo/books? id=gQWd49zSut4C&pg=PA76&lpg=PA7 6&dq=www.proceso+unificado+racional& source=bl&ots=s537vuxtuf&sig=lgaYFC8 nWgR1AnXGdzlTD2adQ4&hl=es#v=onepage&q=www.pr oceso%20unificado%20racional&f=false http://yaqui.mxl.uabc.mx/~molguin/as/RU P.htm [Pressman, Roger S.] Ingeniería del software: Un enfoque practico 5a. ed. Madrid: MCGRAW-HILL INTERAMERICANA 2002. [Carlos Alberto Fernández y F.] El proceso Unificado Racional para el desarrollo de software Huajuapan de León, Oaxaca 2000 [Sommerville Ian.] Ingeniería del software Ed. Pearson 2005 [Schach, Stephen R.] Análisis y diseño orientado a objetos con UML y el Proceso Unificado: México: MCGRAW-HILL INTERAMERICANA 2005. [Booch,2000] BOOCH, Grady, El proceso Unificado de desarrollo de software, 1a. ed. Madrid: Pearson Educación, 2002. [Pressman, Roger S.] Ingeniería del software: Un enfoque practico 7ma ed. Boston: MCGRAW-HILL HIGHER EDUCATION 2010.