Proceso Unificado Racional (RUP)

INTRODUCCION
El Proceso Unificado Racional (Rational Unified Process en ingls, habitualmente resumido como RUP) es un proceso de desarrollo de software y junto con el Lenguaje Unificado de Modelado UML, constituye la metodologa estndar ms utilizada para el anlisis, implementacin y documentacin de sistemas orientados a objetos. El RUP no es un sistema con pasos firmemente establecidos, sino un conjunto de metodologas adaptables al contexto y necesidades de cada organizacin. Tambin se conoce por este nombre al software desarrollado por Rational, hoy propiedad de IBM, el cual incluye informacin entrelazada de diversos artefactos y descripciones de las diversas actividades. Est incluido en el Rational Method Composer (RMC), que permite la personalizacin de acuerdo a necesidades. Originalmente se dise un proceso genrico y de dominio pblico, el Proceso Unificado, y una especificacin ms detallada, el Rational Unified Process, que se vendiera como producto independiente. Caractersticas esenciales Los autores de RUP destacan que el proceso de software propuesto por RUP tiene tres caractersticas esenciales: est dirigido por los Casos de Uso, est centrado en la arquitectura, y es iterativo e incremental. Proceso dirigido por Casos de Uso

Segn Kruchten, P.(2000), los Casos de Uso son una tcnica de captura de requisitos que fuerza a pensar en trminos de importancia para el usuario y no

slo en trminos de funciones que sera bueno contemplar. Se define un Caso de Uso como un fragmento de funcionalidad del sistema que proporciona al usuario un valor aadido. Los Casos de Uso representan los requisitos funcionales del sistema. En RUP los Casos de Uso no son slo una herramienta para especificar los requisitos del sistema. Tambin guan su diseo, implementacin y prueba. Los Casos de Uso constituyen un elemento integrador y una gua del trabajo como se muestra en la figura.

Fases

RUP se divide en 4 fases, dentro de las cuales se realizan varias iteraciones segn el proyecto y en las que se hace mayor o menos esfuerzo en las distintas actividades. En las iteraciones de cada fase se hacen diferentes esfuerzos en diferentes actividades.

 Fase de inicio Se hace un plan de fases, donde se identifican los principales casos de uso y se identifican los riesgos. Se concreta la idea, la visin del producto, como se enmarca en el negocio, el alcance del proyecto. El objetivo en esta etapa es determinar la visin del proyecto. Modelado del negocio En esta fase el equipo se familiarizar ms al funcionamiento de la empresa, sobre conocer sus procesos. Entender la estructura y la dinmica de la organizacin para la cual el sistema va ser desarrollado. Entender el problema actual en la organizacin objetivo e identificar potenciales mejoras. Asegurar que clientes, usuarios finales y desarrolladores tengan un entendimiento comn de la organizacin objetivo. Requisitos

En esta lnea los requisitos son el contrato que se debe cumplir, de modo que los usuarios finales tienen que comprender y aceptar los requisitos que especifiquemos. Establecer y mantener un acuerdo entre clientes y otros stakeholders sobre lo que el sistema podra hacer. Proveer a los desarrolladores un mejor entendimiento de los requisitos del sistema. Definir el mbito del sistema. Proveer una base para estimar costos y tiempo de desarrollo del sistema. Definir una interfaz de usuarios para el sistema, enfocada a las necesidades y metas del usuario.

Fase de elaboracin Se realiza el plan de proyecto, donde se completan los casos de uso y se mitigan los riesgos. Planificar las actividades necesarias y los recursos requeridos, especificando las caractersticas y el diseo de la arquitectura. En esta etapa el objetivo es determinar la arquitectura ptima. Anlisis y Diseo En esta actividad se especifican los requerimientos y se describen sobre cmo se van a implementar en el sistema. Transformar los requisitos al diseo del sistema. Desarrollar una arquitectura para el sistema. Adaptar el diseo para que sea consistente con el entorno de implementacin.

 Fase de construccin Se basa en la elaboracin de un producto totalmente operativo y en la elaboracin del manual de usuario. Construir el producto, la arquitectura y los planes, hasta que el producto est listo para ser enviado a la comunidad de usuarios. En esta etapa el objetivo es llevar a obtener la capacidad operacional inicial. Implementacin Se implementan las clases y objetos en ficheros fuente, binarios, ejecutables y dems. El resultado final es un sistema ejecutable. Planificar qu subsistemas deben ser implementados y en qu orden deben ser integrados, formando el Plan de Integracin. Cada implementador decide en qu orden implementa los elementos del subsistema. Si encuentra errores de diseo, los notifica. Se integra el sistema siguiendo el plan. Pruebas Este flujo de trabajo es el encargado de evaluar la calidad del producto que estamos desarrollando, pero no para aceptar o rechazar el producto al final del proceso de desarrollo, sino que debe ir integrado en todo el ciclo de vida. Encontrar y documentar defectos en la calidad del software. Generalmente asesora sobre la calidad del software percibida. Provee la validacin de los supuestos realizados en el diseo y especificacin de requisitos por medio de demostraciones concretas.

 Verificar las funciones del producto de software segn lo diseado. Verificar que los requisitos tengan su apropiada implementacin.

Fase de transicin El objetivo es llegar a obtener el release del proyecto. Se realiza la instalacin del producto en el cliente y se procede al entrenamiento de los usuarios. Realizar la transicin del producto a los usuarios, lo cual incluye: manufactura, envo, entrenamiento, soporte y mantenimiento del producto, hasta que el cliente quede satisfecho, por tanto en esta fase suelen ocurrir cambios. Despliegue Esta actividad tiene como objetivo producir con xito distribuciones del producto y distribuirlo a los usuarios. Las actividades implicadas incluyen: Probar el producto en su entorno de ejecucin final. Empaquetar el software para su distribucin. Distribuir el software. Instalar el software. Proveer asistencia y ayuda a los usuarios. Formar a los usuarios y al cuerpo de ventas. Migrar el software existente o convertir bases de datos. Como filosofa RUP maneja 6 principios clave Adaptacin del proceso

El proceso deber adaptarse a las caractersticas propias de la organizacin. El tamao del mismo, as como las regulaciones que lo condicionen, influirn en su diseo especfico. Tambin se deber tener en cuenta el alcance del proyecto. Balancear prioridades Los requerimientos de los diversos inversores pueden ser diferentes, contradictorios o disputarse recursos limitados. Debe encontrarse un balance que satisfaga los deseos de todos. Colaboracin entre equipos El desarrollo de software no hace una nica persona sino mltiples equipos. Debe haber una comunicacin fluida para coordinar requerimientos, desarrollo, evaluaciones, planes, resultados, etc. Demostrar valor iterativamente Los proyectos se entregan, aunque sea de modo interno, en etapas iteradas. En cada iteracin se analiza la opinin de los inversores, la estabilidad y calidad del producto, y se refina la direccin del proyecto as como tambin los riesgos involucrados. Elevar el nivel de abstraccin Este principio dominante motiva el uso de conceptos reutilizables tales como patrn del software, lenguajes 4GL o esquemas (Frameworks) por nombrar algunos. Estos se pueden acompaar por las representaciones visuales de la arquitectura, por ejemplo con UML. Enfocarse en la calidad El control de calidad no debe realizarse al final de cada iteracin, sino en todos los aspectos de la produccin.

Niveles de documentacin de la metodologa RUP Primer nivel de documentacin Especifica en trminos generales qu actividades debern integrar el Sistema de Aseguramiento de Calidad, que ser implantado en la organizacin. Este nivel contiene los siguientes elementos: Declaracin de Visin: Proyecciones de la administracin sobre el lugar que ocupar la organizacin en el futuro. Declaracin de Misin: Compromiso de la administracin para alcanzar la Visin. Poltica de Calidad: Posicin de la organizacin, en cuanto a la manera en que la calidad afectar la manera de cumplir con la Misin. Requerimientos de Calidad: Conjunto de actividades que la organizacin debe llevar a cabo, para asegurar la calidad tanto del proceso como el producto que desarrolla La Visin, Misin y Polticas de Calidad fueron desarrolladas a partir de los lineamientos estratgicos del Departamento de Sistemas de Informacin. El Requerimiento de Calidad se identifica en modelos de calidad como ISO 9000. Segundo nivel de documentacin Este nivel incluye especificaciones detalladas, orientadas a la administracin, para explicar cmo se llevarn a cabo las actividades que integran el Sistema de Aseguramiento de Calidad. Este nivel est compuesto bsicamente por procedimientos Administrativos, que son declaraciones de direcciones sistemticas, sobre cmo la organizacin debe llevar a cabo cada uno de los Requerimientos de Calidad, definidos en el Primer Nivel de Documentacin. Tercer nivel de documentacin

Este nivel incluye especificaciones punto a punto, explcito y conciso para llevar a cabo cualquier tarea en la organizacin. Est compuesto bsicamente por Procedimientos de Operativos que describen cada paso que se debe realizar para concretar una tarea o actividad; y Estndares que se utilizan con el fin de registrar datos o informacin de algo especfico. Estos procedimientos y estndares han sido divididos en tres grupos: 1. Los relacionados con el desarrollo del curso Proyecto de Ttulo. 2. Los relacionados con el desarrollo de producto de software. 3. Los que guan la implantacin y mejoramiento del Sistema de Aseguramiento de Calidad. Esta divisin facilita el uso y mantencin del sistema. Por ejemplo, si hay cambios en las normas administrativas que afecten el desarrollo de los cursos en general, entonces slo se vern afectados los procedimientos y estndares relacionados con el desarrollo del proyecto.

Metodologas orientadas a objetos: Booch

La metodologa de Booch, desarrollada por Grady Booch en 1994, se orienta analizar el modo, documentos y requisitos del sistema en desarrollo. Para esto, sta metodologa se basa en un desarrollo iterativo e incremental de un sistema en el cual se mira el desarrollo del producto como una serie de despachos que evolucionan hacia el sistema final. Por otro lado, en sta metodologa los riesgos tcnicos son evaluados y priorizados en una fase temprana del ciclo de vida; y el desarrollo se divide en un Macro-proceso (que engloba la planificacin, agrupacin de similitudes, identificacin de situaciones relevantes y creacin

y validacin de un prototio) y un Micro-proceso (que define un conjunto de reglas que regulan el uso de operaciones, atributos y politicas de manejo de memoria, errores y funciones).

El mtodo de Booch est orientado a analizar el modo, los documentos y requisitos del sistema en desarrollo. Ha sido desarrollado por Grady Booch, sobre la base de ms de quince aos de experiencia en desarrollo con grandes y complejas aplicaciones. Segn Robert C. Martin "La notacin Booch es a la vez til y bien conocida. De todas las notaciones que he visto, contiene el mayor poder expresivo, porque contiene el mayor repertorio de conos y smbolos para la expresin de las relaciones, objetos, tipos de clase, y sus modificadores" .

Booch, para desarrollar este mtodo uni conceptos de su anterior trabajo con los conceptos de Objectory, OMT, y otros mtodos, como se muestra en la Figura No.1.

La notacin juega un papel importante en la metodologa de Booch .es el pegamento que mantiene unido el proceso.. Este mtodo provee una notacin bastante robusta, que crece del anlisis en el diseo. Ciertos elementos (como las clases, asociaciones, agregaciones, herencias) de la notacin son introducidos durante el anlisis. Otros elementos de la notacin (como categoras de clases, indicadores) son introducidos durante el diseo y evolucin La notacin cumple con tres funciones: Sirve como el idioma para comunicar las decisiones que no son obvias o no pueden deducirse del cdigo en s. Proporciona semntica suficientemente rica para capturar todas las decisiones estratgicas y tcticas. Ofrece una forma lo suficientemente concreta sobre la razn de utilizar las herramientas y cmo manipularlas.

Proceso de desarrollo Orientado a Objetos El mtodo de Booch se basa en el desarrollo iterativo (es decir, repetitivo) e incremental de un sistema. Esto implica que el mtodo de Booch es un ciclo de vida iterativo e incremental, en el cual se mira el desarrollo del producto como una serie de despacho (releases) de arquitectura que evolucionan hacia el sistema final. Los desarrolladores no asumen todos los requisitos que se conocen al comienzo del ciclo de vida, de hecho, el cambio se prevee en todas las fases. Se trata de una reduccin del riesgo en el proceso impulsado . Los riesgos tcnicos son evaluados y priorizados en una fase temprana del ciclo de vida y se examinan durante el desarrollo de cada despacho de arquitectura. Los riesgos se adjuntan a cada iteracin de manera que se podra mitigar con xito los riesgos que se adjuntan. Las emisiones estn previstas para garantizar que los mayores riesgos se abordan en primer lugar. Creando el sistema de esta forma, expone y mitiga los riesgos del sistema en una fase temprana del ciclo de vida, y la integracin de las

"piezas" del sistema es constante. El resultado de este tipo de ciclo de vida es menor el riesgo junto con una inversin mnima.

Macro-proceso En el contexto del diseo, el macro-proceso engloba una actividad de planificacin arquitectnica, que agrupa objetos similares en particiones arquitectnicas separadas, capas de objetos por nivel de abstraccin, identifica situaciones relevantes, crea un prototipo de diseo y valida el prototipo aplicndolo a situaciones de uso. El macro-proceso es un proceso de alto nivel en el que se describen las actividades de desarrollo del equipo de trabajo. ste consiste en pasos, los cuales se muestran en la Figura No.2.

Micro-proceso Por otro lado el micro-proceso define un conjunto de .reglas. que regulan el uso de operaciones y atributos y las polticas del dominio especfico para la administracin de la memoria, manejo de errores y otras funciones; desarrolla situaciones que describen la semntica de las reglas y polticas; crea un prototipo para cada poltica; instrumenta y refina el prototipo; y revisa cada poltica para as .transmitir su visin arquitectnica.

El micro-proceso es un proceso de bajo nivel que representa las actividades tcnicas del equipo de desarrollo. Al igual que el macro-proceso, este consiste en una serie de pasos, que se muestran en la Figura No. 3

Conceptos y Diagramas de la metodologa de Booch

La metodologa de Booch se basa en los siguientes tipos de diagramas para describir las decisiones de anlisis y diseo, tcticas y estratgicas, que deben ser hechas en la creacin de un sistema orientado por objetos.

Diagrama de Clases. Consiste en un conjunto de clases y relaciones entre ellas. Los tipos de relaciones son asociaciones, contenencia, herencia, uso, instanciacin y superclase.

Especificacin de Clases. Es usado para capturar toda la informacin importante acerca de una clase en formato texto. Diagrama de Categoras. Muestra clases agrupadas lgicamente bajo ciertas Categoras Diagramas de transicin de estados. Diagramas de Objetos. Muestra objetos en el sistema y su relacin lgica. Pueden ser diagramas de escenario, donde se muestra cmo colaboran los objetos en cierta operacin; o diagramas de instancia, que muestra la existencia de los objetos y las relaciones estructurales entre ellos.

Diagramas de Tiempo. Aumenta un diagrama de objetos con informacin acerca de eventos externos y tiempo de llegada de los mensajes. Diagramas de mdulos. Muestra la localizacin de objetos y clases en mdulos del diseo fsico de un sistema. Un diagrama de mdulos representa parte o la totalidad de la arquitectura de mdulos del sistema.

Subsistemas. Un subsistema es una agrupacin de mdulos, til en modelos de gran escala. Diagramas de procesos. Muestra la localizacin de los procesos en los distintos procesadores de un ambiente distribuido.

El xito de un proyecto cubre todos los ciclos de descubrimiento, la invencin y la aplicacin que constituyen el eje central para el anlisis y diseos de las diferentes fases de los macro y micro procesos. El descubrimiento de un mtodo de anlisis y diseo

proporciona una comprensin del comportamiento del sistema. Esta invencin da lugar a la creacin de una arquitectura del sistema, durante la etapa de diseo, cuando las principales decisiones estratgicas y tcticas se realizan. El anlisis y diseo orientado a objetos es utilizado en conjuncin con un proceso iterativo e incremental con el objetivo de proporcionar un buen software de proceso de ingeniera para los analistas de sistemas, diseadores y programadores. Se inicia con un modelo de las necesidades de un punto de vista del usuario. El modelo se madura durante el diseo, y se cambia a un punto de vista del desarrollador.

Metodologa de Rumbaugh (OMT)

OMT es una de las metodologas de anlisis y diseo de desarrollo de software orientado a objetos ms eficiente que existe en la actualidad. Es uno de los precursores de UML. La gran virtud que aporta esta metodologa es su carcter de abierta (no propietaria), que le

permite ser de dominio pblico y, en consecuencia, sobrevivir con enorme vitalidad. Esto facilita su evolucin para acoplarse a todas las necesidades actuales y futuras de la ingeniera de software.

Esta metodologa se extiende del anlisis, al diseo, a la implementacin. Primero, se construye un modelo de anlisis para abstraer los aspectos esenciales de la aplicacin sin tomar en cuenta, por el momento, la implementacin. Est modelo contiene objetos presentes en la aplicacin, incluyendo una descripcin de las propiedades del objeto y su comportamiento. Luego son tomadas las decisiones del diseo de la aplicacin y se agregan detalles al modelo para optimizar la implementacin. Finalmente el modelo de diseo es implementado en un lenguaje de programacin, base de datos o hardware. Este acercamiento es llamado Tcnica de Modelacin de Objetos (OMT).

OMT se basa en las siguientes etapas:

1. Anlisis: empezando desde la descripcin del problema, el analista construye un modelo de una situacin real mostrando sus propiedades ms importantes. El modelo de anlisis es una abstraccin concisa y precisa de qu debe hacer el sistema deseado, no cmo debe ser hecho. Los objetos en este modelo deben ser objetos de aplicacin, conceptos reales, no conceptos computacionales como estructuras de datos. Estos modelos deben ser analizados y comprendidos por los expertos en el tema que son programadores. El modelo de anlisis no debe contener detalles de implementacin.

2. Diseo del Sistema: el diseador del sistema toma decisiones de alto nivel de toda la arquitectura del sistema. Durante el diseo del sistema, el objetivo es organizar en subsistemas basndose en la estructura del anlisis y la arquitectura propuesta. En esta etapa se deben decidir las caractersticas del funcionamiento para optimizar el sistema, as como escoger una estrategia para atacar el problema.

3. Diseo de Objetos: el diseador de objetos construye un modelo de diseo basndose en el modelo de anlisis, pero incluyendo detalles de implementacin. Se agregan los detalles de implementacin al modelo de diseo basndose en la estrategia escogida durante el diseo del sistema. El objetivo del diseo de objetos son las estructuras de datos y algoritmos necesitados para implementar cada clase. Las clases de objetos definidas durante el anlisis son reforzadas con las estructuras de datos y algoritmos escogidos para optimizar el funcionamiento del sistema.

4. Implementacin: las clases de objetos y las relaciones entre ellas definidas durante el diseo de objetos son trasladadas a un lenguaje de programacin, a una base de datos o implementacin de hardware. La programacin se vuelve un proceso menor y mecnico del ciclo de desarrollo, ya que las decisiones fueron tomadas con anterioridad durante el proceso de anlisis y diseo.

Los conceptos de la orientacin a objetos son aplicados durante el ciclo de vida de desarrollo del sistema, de anlisis, a diseo, a implementacin. Las mismas clases son llevadas durante todo el proceso sin cambiar de notacin, solamente agregando detalles de implementacin. Todas las formas de visualizar una clase durante el proceso de anlisis y diseo son correctas, ya que se utilizan para diferentes propsitos; con lo que denotan diferentes niveles de abstraccin.

La metodologa OMT utiliza tres tipos de modelos para describir un sistema:

Modelo de Objetos: describe la estructura esttica de los objetos de un sistema y sus relaciones. El modelo de objetos contiene diagramas. Un diagrama de objeto es una grfica en la que los nodos son clases de objetos y los arcos entre nodos son las relaciones entre las clases.

Modelo Dinmico: describe los aspectos del sistema que cambian a travs del tiempo. El modelo dinmico es utilizado para especificar e implementar aspectos

del control del sistema. Utiliza diagramas de estado. Un diagrama de estado es una grfica en la que los nodos son estados y los arcos entre nodos son transiciones entre estados, causadas por eventos.

Modelo Funcional: describe las trasformaciones de los valores de los datos dentro de un sistema. El modelo funcional contiene diagramas de flujo de datos. Un diagrama de flujo de datos es una grfica en la que los nodos son procesos y los arcos entre procesos son flujo de datos.

Los modelos de objetos son fundamentales, ya que describen qu cambia en unsistema, antes de describir cundo y cmo cambia el sistema.

OMT es utilizado por medio de herramientas de diseo e ingeniera de software. Toda herramienta que implemente los modelos de objetos, dinmicos y funcionales puede ser utilizada para la realizacin de la metodologa OMT. Algunas de las herramientas que lo soportan son: SmartDraw, Software Design Center 10 Excelerator II Intersolv Inc. MetaEdit MetaCASE Consulting YO ObjectMarker, Mark V Software BOCS, Berard Software Eng. ObjectTeam, Candre Technologies, Inc.