1

RATIONAL UNIFIED PROCESS Fernando Lpez Moscoso praetorian666@hotmail.com

AbstractRUP es la metodologa ms utilizada para el desarrollo de software, en este mbito analizaremos sus distintas caractersticas y fundamentos, para poder develar las ventajas y desventajas a la hora de implementar la metodologa RUP en el desarrollo de sistemas.
III.

EL PROCESO UNIFICADO Y SUS FASES

Como sealo anteriormente RUP constituye una metodologa 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 interactuarn con el sistema y definir estas interacciones. Esta informacin 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 Elaboracin. Los objetivos de esta fase son comprender el dominio del problema para poder establecer un marco de trabajo arquitectnico 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 descripcin arquitectnica y un plan de desarrollo del software. Construccin. Esta fase comprende el diseo del sistema, la programacin, las pruebas. En esta fase se desarrollan e integran las partes del sistema. Al terminarla, obtenemos el sistema funcional y su respectiva documentacin. Transicin: Es la fase final donde se cambia de la etapa de desarrollo a la implementacin del usuario y para que este trabaje en un entorno real. Esta actividad constituye un alto costo y problemtica. Como resultado tenemos un Sistema de Software documentado, que funciona correctamente en su entorno operativo. Como complemento RUP emplea a UML como medio de comunicacin entre el rea de los desarrolladores con los usuarios finales para facilitar

I. INTRODUCCIN RUP o proceso unificado es un proceso unificado para desarrollo de software, RUP constituye la metodologa estndar ms utilizada para el anlisis, diseo, implementacin y documentacin de sistemas orientados a objetos. Como sealamos RUP no es un sistema con pasos predefinidos si no es un conjunto de metodologas adaptables al contexto y las necesidades de cada organizacin.
II. ANTECEDENTES HISTRICOS

A mediados de la dcada de los 80s se contempl la idea de la crisis del software, hecho que hizo evidente la necesidad de un paradigma mejor para el diseo de software. El paradigma orientado a objetos prob ser la solucin. Y durante los 10 aos siguientes se publicaron ms de 50 metodologas diferentes, dentro de las cuales destacaron el mtodo de Botch, el Objectory de Jacobson y la tcnica OMT de Rumbaugh. Botch, Jacobson y Rumbaugh unieron esfuerzos para publicar una metodologa completa de anlisis y diseo orientado a objetos que unificara sus tres metodologas, 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 trmino proceso unificado se utiliza como abreviacin en la actualidad.

la comprensin del sistema y as avanzar en sus fases. IV. DIMENSIONES DE RUP

dimensiones La primera dimensin representa el aspecto dinmico del proceso conforme se va desarrollando, en esta apreciamos las fases e iteraciones. La segunda dimensin representa el aspecto esttico del proceso: cmo es descrito en trminos de componentes del proceso, disciplinas, actividades, flujos de trabajo, artefactos y roles. V. CARACTERSTICAS DEL RUP Las principales caractersticas a resaltar de RUP son las siguientes Forma disciplinada de asignar tareas y responsabilidades (quin hace qu, cundo y cmo) Pretende implementar las mejores prcticas en Ingeniera de Software Desarrollo iterativo Administracin de requisitos Uso de arquitectura basada en componentes Control de cambios Modelado visual del software Verificacin de la calidad del software VI. ARTEFACTOS 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 cdigo ejecutable RUP en cada una de sus fases (pertenecientes a la estructura dinmica) realiza una serie de artefactos que sirven para comprender la funcionalidad del sistema. Entre dichos artefactos generados podemos resaltar los siguientes:: Inicio: Documento Visin Especificacin de Requisitos Elaboracin:

Fig1 Esfuerzo de actividades segn 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 lgica. En este ejemplo se dividen los workflows de proceso y de soporte De esta representacin podemos diferenciar dos

3 Diagramas de caso de uso Construccin: Documento Arquitectura que trabaja con las siguientes vistas: Vista Lgica o Diagrama de clases o Modelo E-R (Si el sistema as lo requiere) Vista de Implementacin o Diagrama de Secuencia o Diagrama de estados o Diagrama de Colaboracin Vista Conceptual o Modelo de dominio Vista fsica o Mapa de comportamiento a nivel de hardware. 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 comprensin 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 especificacin funcional del sistema. Para aclarar una especificacin 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 implicacin importante, nos fuerzan a pensar en trminos del valor a los usuarios y no solamente en trminos de las funciones que sera bueno que tuviera. Sin embargo, los casos de uso no son solamente una herramienta para especificar los requerimientos del sistema, tambin dirigen su diseo, implementacin y pruebas, esto es, dirigen el proceso de desarrollo. An 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 eleccin 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.

VII.

DESARROLLO ITERATIVO E INCREMENTAL

El Proceso Unificado es un marco de desarrollo iterativo e incremental, es decir es una implementacin del modelo de desarrollo en espiral, como lo sealamos 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 clsico o en cascada de desarrollo de software: Anlisis de requisitos, Diseo, Implementacin y Prueba. Aunque todas las iteraciones suelen incluir trabajo en casi todas las disciplinas, el grado de esfuerzo dentro de cada una de ellas vara 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 ingeniera 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.

RUP EST CENTRADO EN LA ARQUITECTURA

En trminos conceptuales podramos sealar 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

est centrado en la elaboracin 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 diseado. El concepto de arquitectura de software involucra los aspectos estticos y dinmicos ms 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 estn reflejadas en los casos de uso. Sin embargo, tambin est influenciada por muchos otros factores, tales como la plataforma de software en la que se ejecutar, la disponibilidad de componentes reutilizables, consideraciones de instalacin, sistemas legados, requerimientos no funcionales (ej. desempeo, confiabilidad). La arquitectura es la vista del diseo completo con las caractersticas ms importantes hechas ms 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 reso. Los casos de uso se relacionan con la arquitectura en la forma en que un producto puede tener una funcin y forma. Pero uno slo de los dos no es suficiente. Estas dos fuerzas deben estar balanceadas para obtener un producto exitoso. En este caso funcin 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 realizacin 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 crticos en una etapa temprana del ciclo de vida. Los

resultados de cada iteracin, en especial los de la fase de Elaboracin deben ser seleccionados en un orden que asegure que los riesgos principales son considerados primero. X. VENTAJAS DE RUP Es muy til para ser aplicado en proyectos bastante extensos, debido a que proporciona un lenguaje comn para la comprensin del cliente o entre desarrolladores y el proceso que este plantea es muy completo y ayuda a documentar de manera apropiada dichos sistemas Otro aspecto a resaltar es que nos permite asignar tareas y responsabilidades (quin?, cundo? y cmo?), permitiendo as una buena gestin 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 pequeos, debido a que el esfuerzo y el tiempo dedicado no es muy rentable si se lo puede lograr de manera ms sencilla. El RUP es generalmente mal aplicado en el estilo cascada. Requiere conocimientos del proceso y de UML. XII. CONCLUSIONES La metodologa RUP proporciona una serie de conceptos bastante tiles y aplicables para la correcta elaboracin de software como que este est dirigido a los casos de uso lo cual facilita la definicin de metas y el entendimiento del sistema por parte de los clientes o usuarios potenciales, adems 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 documentacin del sistema es bastante extensa y entendible.

Sin lugar a dudas es una metodologa ideal para implementar en proyectos bastante extensos por las bondades que incluye, pero no es muy recomendable para proyectos pequeos 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.] Ingeniera del software: Un enfoque practico 5a. ed. Madrid: MCGRAW-HILL INTERAMERICANA 2002. [Carlos Alberto Fernndez y F.] El proceso Unificado Racional para el desarrollo de software Huajuapan de Len, Oaxaca 2000 [Sommerville Ian.] Ingeniera del software Ed. Pearson 2005 [Schach, Stephen R.] Anlisis y diseo orientado a objetos con UML y el Proceso Unificado: Mxico: MCGRAW-HILL INTERAMERICANA 2005. [Booch,2000] BOOCH, Grady, El proceso Unificado de desarrollo de software, 1a. ed. Madrid: Pearson Educacin, 2002. [Pressman, Roger S.] Ingeniera del software: Un enfoque practico 7ma ed. Boston: MCGRAW-HILL HIGHER EDUCATION 2010.