Rup

1RATIONAL 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. 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 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.  2 la comprensión del sistema y así avanzar en sus fases. En este ejemplo se dividen los workflows de proceso y de soporte De esta representación podemos diferenciar dos . flujos de trabajo. artefactos y roles. 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. 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. V. · 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. actividades. ARTEFACTOS Un artefacto se refiere a los resultados tangibles que genera el desarrollo del software. disciplinas. el tiempo y las iteraciones. La segunda dimensión representa el aspecto estático del proceso: cómo es descrito en términos de componentes del proceso. Entre dichos artefactos generados podemos resaltar los siguientes:: Inicio: • Documento Visión • Especificación de Requisitos Elaboración: Fig1 Esfuerzo de actividades según las fases del proyecto En la figura 1 podemos apreciar las fases de desarrollo. IV. como los diagramas UML que ayudan a comprender la funcionalidad del sistema. 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é. 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. al arquitectura del sistema y los casos de uso maduran conforme avanza el ciclo de vida. 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. esto es. DIRIGIDO PARA LOS CASOS DE USO Un sistema de software se crea para satisfacer las necesidades de los usuarios. es decir es una implementación del modelo de desarrollo en espiral. 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. Este modelo reemplaza la tradicional especificación funcional del sistema. Ken Hartman. Como ejemplo la etapa inicial en proyectos grandes se torna bastante extensa por la ingeniería de requerimientos que se emplea. como es el ciclo de vida en espiral de Barry Boehm. implementación y pruebas. 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. Dentro de UML este conjunto constituye el modelo de casos de uso el cual describe la funcionalidad completa del sistema. VIII. 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. De esta forma podemos ver que el papel del arquitecto de sistemas . no son elegidos de manera aislada. VII. proviene de los principales aportes que lo inspiraron. 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. los casos de uso no son solamente una herramienta para especificar los requerimientos del sistema. Aunque todas las iteraciones suelen incluir trabajo en casi todas las disciplinas. esto es. Estas iteraciones nos ofrecen como resultado un incremento paulatino en el sistema que se está desarrollando. para construir un sistema exitoso se debe conocer qué es lo que quieren y necesitan los usuarios prospectos. Vale resaltar que todo el proceso iterativo de RUP. como lo señalamos anteriormente las cuatro fases son divididas por una serie de iteraciones. 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. Implementación y Prueba. DESARROLLO ITERATIVO E INCREMENTAL El Proceso Unificado es un marco de desarrollo iterativo e incremental. Un caso de uso es un artefacto que explica una parte de la funcionalidad del sistema Los casos de uso capturan los requerimientos funcionales. Aún y cuando los casos de uso dirigen el proceso. dirigen el proceso de desarrollo. también dirigen su diseño.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. 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. Son desarrollados a la par con la arquitectura del sistema. Diseño. IX. Por lo tanto. Sin embargo. el proceso ayuda al arquitecto a enfocarse en las metas correctas. cuando son realizados.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. acomodarse en la arquitectura. Por otra parte. permitiendo así una buena gestión a lo largo del desarrollo de las aplicaciones XI. Estas dos fuerzas deben estar balanceadas para obtener un producto exitoso. La arquitectura surge de las necesidades de la empresa. DESVENTAJAS DE RUP Por el grado de complejidad puede no resultar muy adecuado implementar RUP en proyectos pequeños. hoy y en el futuro. Los casos de uso se relacionan con la arquitectura en la forma en que un producto puede tener una función y forma. desempeño. Existe la necesidad de intercalar entre casos de uso y arquitectura. 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. el cual a su vez viene con la experiencia. y tal y como están reflejadas en los casos de uso. ambos arquitectura y casos de uso deben evolucionar en paralelo. ¿cuándo? y ¿cómo?). Por una parte. . Ya que lo importante depende en parte del criterio. tales como la plataforma de software en la que se ejecutará. Los resultados de cada iteración. también está influenciada por muchos otros factores. 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 Otro aspecto a resaltar es que nos permite asignar tareas y responsabilidades (¿quién?. Sin mencionar que este incluye UML y gracias a esto la documentación del sistema es bastante extensa y entendible. Sin embargo. 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. XII. flexibilidad en los cambios futuros (resilience) y reúso. tales como claridad (understandability). Requiere conocimientos del proceso y de UML. requerimientos no funcionales (ej. VENTAJAS DE RUP Es muy útil para ser aplicado en proyectos bastante extensos. 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. tal y como las interpretan los usuarios y otros stakeholders. El concepto de arquitectura de software involucra los aspectos estáticos y dinámicos más significativos del sistema. la disponibilidad de componentes reutilizables. Pero uno sólo de los dos no es suficiente. Sin embargo. 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. debido a que el esfuerzo y el tiempo dedicado no es muy rentable si se lo puede lograr de manera más sencilla. la arquitectura debe proveer espacio para la realización de todos los casos de uso. el valor de la arquitectura depende del personal asignado a esta tarea. en especial los de la fase de Elaboración deben ser seleccionados en un orden que asegure que los riesgos principales son considerados primero. X. los casos de uso deben. En este caso función corresponde a los casos de uso y forma a la arquitectura. En la realidad. Es un problema del “huevo y la gallina”.4 está centrado en la elaboración de la estructura del sistema a nivel conceptual. confiabilidad). sistemas legados. consideraciones de instalación. El RUP es generalmente mal aplicado en el estilo cascada. proporcionando de esta manera los diferentes puntos de vista para que los programadores elaboren el sistema. [Booch. XIII. Boston: MCGRAW-HILL HIGHER EDUCATION 2010. Roger S. El proceso Unificado de desarrollo de software. 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.com. [Pressman.2000] BOOCH.] Ingeniería del software: Un enfoque practico 7ma ed. Grady. [Carlos Alberto Fernández y F.] Ingeniería del software: Un enfoque practico 5a.htm [Pressman.proceso+unificado+racional& source=bl&ots=s537vuxtuf&sig=lgaYFC8 nWgR1AnXGdzlTD2adQ4&hl=es#v=onepage&q=www. • • • • • • • • • .] Ingeniería del software Ed.mx/~molguin/as/RU P.ia.uned. 1a.5 Sin lugar a dudas es una metodología ideal para implementar en proyectos bastante extensos por las bondades que incluye. Madrid: MCGRAW-HILL INTERAMERICANA 2002. ed.uabc. REFERENCIAS http://www. Madrid: Pearson Educación.html http://books. ed. Stephen R.google.bo/books? id=gQWd49zSut4C&pg=PA76&lpg=PA7 6&dq=www.pr oceso%20unificado%20racional&f=false http://yaqui. Oaxaca 2000 [Sommerville Ian.es/ia/asignaturas/adms/ GuiaDidADMS/node60.mxl.] Análisis y diseño orientado a objetos con UML y el Proceso Unificado: México: MCGRAW-HILL INTERAMERICANA 2005. Roger S.] El proceso Unificado Racional para el desarrollo de software Huajuapan de León. Pearson 2005 [Schach. 2002.