2.

3 El proceso de desarrollo unificado RUP

El Proceso Unificado de Rational (Rational Unified Process -RUP) es un proceso de desarrollo, un conjunto de mtodos y tcnicas, para desarrollar y mantener un software de calidad. Desarrollado por la empresa Rational Software, actualmente propiedad de IBM. Junto con el Lenguaje Unificado de Modelado UML, constituye la metodologa estndar ms utilizada para el anlisis, diseo, implementacin y documentacin de sistemas orientados a objetos. Tambin se conoce por este nombre al software, tambin desarrollado por Rational, que 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 con las necesidades.

Se caracteriza por estar orientado a objetos, basado en casos de uso, estar centrado en una arquitectura, por ser iterativo e incremental y enfocado a riesgos. Orientado a objetos. Implica que el modulo principal del que estar compuesta la solucin ser el objeto Basado en casos de uso. Implica que estos se utilizan para definir los requisitos de la aplicacin y por ende dan la orientacin general del proceso. Estos mismos casos de uso son pieza clave para manejar los riesgos que el desarrollo puede presentar. Centrado en una arquitectura. Un sistema tiene que ser concebido, modelado y resuelto en su totalidad de manera general, antes de poder implementar. Iterativo e incremental. Deriva del proceso en espiral. El proceso reconoce actividades que se tienen que desarrollar de manera recurrente, cclica, en cuyo trmino se obtiene una funcionalidad adicional del producto desarrollado. Enfocado a riegos. El proceso tiene como una de sus actividades el identificar, prevenir, corregir o minimizar los efectos de cualquier acontecimiento que afecte la correcta ejecucin del proceso en lo concerniente al tiempo y al presupuesto.

El proceso unificado contempla el desarrollo de seis disciplinas o actividades durante toda la vida del proyecto: 1. Modelado del Negocio o Anlisis del Dominio, es una disciplina que involucra el entendimiento del problema y el contexto en el que se desenvuelve. Es en esta etapa donde aprendemos el negocio del cliente, sus entidades, productos y procesos. Los diagramas UML desarrollados como parte de esta actividad son: orientados a la perspectiva del dominio. 2. Requerimientos, contempla la recopilacin, documentacin y clasificacin de los requerimientos funcionales y no funcionales que el cliente, negocio o entorno imponen a la solucin. Los requerimientos son por lo general condiciones o restricciones que de manera obligatoria la solucin debe implementas. Los diagramas generados en esta disciplina estn orientados a la perspectiva de Requerimientos y Especificacin.

3. Anlisis y Diseo, contempla el estudio y anlisis del cumulo de informacin capturada por las disciplinas anteriores y, con base en ella, el planteamiento de una solucin, plasmada como modelo. Se define la arquitectura central de la solucin y donde el arquitecto intenta equilibrar los pros y contras del diseo propuesto. Los diagramas generados en esta disciplina estn orientados a la perspectiva de Diseo e Implementacin. 4. Implementacin o construccin implica la codificacin en un lenguaje orientado a objetos en especfico, de la solucin diseada en la disciplina anterior. Esta actividad est protagonizada por los programadores. Construccin del sistema de software. 5. Pruebas 6. Puesta en Operacin. Montar la solucin a un ambiente real.

El RUP est basado en 6 principios clave que son los siguientes: 1. Adaptar el proceso. El proceso deber adaptarse a las necesidades del cliente ya que es muy importante interactuar con l. Las caractersticas propias del proyecto u organizacin, el tamao del mismo, as como su tipo o las regulaciones que lo condicionen, influirn en su diseo especfico. Tambin se deber tener en cuenta el alcance del proyecto en un rea subformal. 2. Equilibrar prioridades. Los requisitos de los diversos participantes pueden ser

diferentes, contradictorios o disputarse recursos limitados. Debe encontrarse un equilibrio que satisfaga los deseos de todos. Gracias a este equilibrio se podrn corregir desacuerdos que surjan en el futuro. 3. Demostrar valor iterativamente. Los proyectos se entregan, aunque sea de un 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. 4. Colaboracin entre equipos. El desarrollo de software no lo hace una nica persona sino mltiples equipos. Debe haber una comunicacin fluida para coordinar requisitos, desarrollo, evaluaciones, planes, resultados, etc. 5. Elevar el nivel de abstraccin. Este principio dominante motiva el uso de conceptos reutilizables tales como patrn del software, lenguajes 4GL o marcos de referencia (frameworks) por nombrar algunos. Esto evita que los ingenieros de software vayan directamente de los requisitos a la codificacin de software a la medida del cliente, sin saber con certeza qu codificar para satisfacer de la mejor manera los requisitos y sin comenzar desde un principio pensando en la reutilizacin del cdigo. Un alto nivel de abstraccin tambin permite discusiones sobre diversos niveles y soluciones arquitectnicas. stas se pueden acompaar por las representaciones visuales de la arquitectura, por ejemplo con el lenguaje UML.

6. Enfocarse en la calidad. El control de calidad no debe realizarse al final de cada

iteracin, sino en todos los aspectos de la produccin. El aseguramiento de la calidad forma parte del proceso de desarrollo y no de un grupo independiente.
2.5.1 Ciclo de vida El ciclo de vida RUP es una implementacin del Desarrollo en espiral. Fue creado ensamblando los elementos en secuencias semi-ordenadas. El ciclo de vida organiza las tareas en fases e iteraciones. RUP divide el proceso en cuatro fases, dentro de las cuales se realizan varias iteraciones en nmero variable segn el proyecto y en las que se hace un mayor o menor hincapi en las distintas actividades. En la Figura muestra cmo vara el esfuerzo asociado a las disciplinas segn la fase en la que se encuentre el proyecto RUP. El conjunto de disciplinas o actividades que se desarrollan en cada etapa, tendrn como nica finalidad, la obtencin del correspondiente milestone (conjunto entregable de artefactos).

Figura 9 Con RUP, realizas algunos requerimientos de planeacin, diseo, implementacin y pruebas de tu aplicacin en cada fase del ciclo de vida, permitiendo abordar con tiempo los riesgos y de forma continua.

2.5.2 Fases

Fase de Inicio

Esta fase tiene como propsito definir y acordar el alcance del proyecto con los patrocinadores, identificar los riesgos asociados al proyecto, proponer una visin muy general de la arquitectura de software y producir el plan de las fases y el de iteraciones posteriores. Tiene como objetivo o milestone, el documento de visin o propuesta (Lifecycle Objective) Este documento debe incluir la siguiente informacin: Enunciado del problema. Explicar en pocas palabras la situacin a la que nos estamos enfrentando y se pretende resolver. Se plantea el problema, ms no la solucin. Se pretende entender el porqu estamos en la situacin y no el cmo salir de ella. Enunciado de la visin. Es una frase que nos permita resumir las bondades y beneficios de la solucin que se propone y el cmo encajara est en la operacin del negocioJustificacin o businees case para el proyecto. Pequeo estudio o anlisis acerca de la viabilidad del proyecto, es decir, la relacin costo-beneficio. Entre los puntos que debe tocar se encuentra el nivel de aceptacin del producto por parte de los usuarios, las fuentes de ingresos que lo patrocinaran, la comparativa entre el precio estimado del proyecto contra productos semejantes en el mercado y el tiempo de recuperacin de inversin. Los casos de uso principales, que definirn la funcionalidad y alcance del proyecto Principales requerimientos Una o ms arquitecturas candidatas y los pros y contra de cada una de ellas Identificacin de los principales riesgos Calendario del proyecto o plan de desarrollo estimado Costo estimado

Fase de elaboracin. Las iteraciones se orientan al desarrollo de la lnea base de la arquitectura, abarcan ms los flujos de trabajo de requisitos, modelo de negocios (refinamiento), anlisis, diseo y una parte de implementacin orientado a la lnea base de la arquitectura. En la fase de elaboracin se seleccionan los casos de uso que permiten definir la arquitectura base del sistema y se desarrollaran en esta fase, se realiza la especificacin de los casos de uso seleccionados y el primer anlisis del dominio del problema, se disea la solucin preliminar. Se espera capturar la mayora de los requerimientos del sistema. Sin embargo, la principal meta de la fase es establecer y validar la arquitectura de la solucin propuesta, manejando o resolviendo los riegos principales conocidos. El milestone de esta etapa se conoce como Lifecycle Architecture, est comprendido por: La descripcin de la arquitectura de software. Es un conjunto de diagramas que describen la arquitectura general en diferentes vistas. Cada una de estas vistas describe la arquitectura en diferentes aspectos. Modelo de Vistas 4+1 o Vista de Casos de Uso. Contiene unos pocos escenarios principales, descritos a travs de diagramas de casos de uso.

Vista Lgica. Describe lo que el sistema hace y direcciona los requerimientos funcionales del sistema. Se construye a partir de diagrama de clases. o Vista de Implementacin. Describe la organizacin de mdulos de software estticos y direcciona los problemas de la facilidad de instalacin, administracin, reus y otros. Se implementa a partir de diagramas de paquetes. o Vista de Proceso. Describe los aspectos concurrentes del sistema en tiempo real y direcciona los problemas tales como tolerancia de fallos, bloqueos muertos, tiempo de respuesta y rendimiento. Se implementa a partir de diagramas de secuencia. o Vista de Puesta en Operacin. Describe como los varios ejecutables y otras libreras de tiempo de ejecucin son mapeadas a las plataformas husped y direcciona problemas como instalacin, desempeo y requerimientos del sistema. El prototipo arquitectural ejecutable. Es un primer release ejecutable de la solucin. Se considera prototipo, puesto que no est del todo terminado o detallado. o

Fase de construccin. Se lleva a cabo la construccin del producto por medio de una serie de iteraciones. Para cada iteracin se seleccionan algunos Casos de Uso, se refinan su anlisis y diseo y se procede a su implementacin y pruebas. Se realiza una pequea cascada para cada ciclo. Se realizan iteraciones hasta que se termine la implementacin de la nueva versin del producto. El propsito de esta fase es completar la funcionalidad del sistema, para ello se deben clarificar los requisitos pendientes, administrar los cambios de acuerdo a las evaluaciones realizados por los usuarios y se realizan las mejoras para el proyecto. Se busca lograr la optimizacin en los procesos de construccin a nivel de costos, tiempos y calidad. Al final de la etapa se debe decidir, si la solucin y los usuarios estn listos para operar, sin poner en riesgo el proyecto (versin beta del producto). Construccin: Documento Arquitectura que trabaja con las siguientes vistas: Vista Lgica. Diagrama de clases, Modelo E-R (Si el sistema as lo requiere) Vista de Implementacin. Diagrama de Secuencia, Diagrama de estados, Diagrama de Colaboracin Vista Conceptual. Modelo de dominio Vista fsica. Mapa de comportamiento a nivel de hardware. Fase de transicin. Se pretende garantizar que se tiene un producto preparado para su entrega a la comunidad de usuarios. El propsito de esta fase es asegurar que el software est disponible para los usuarios finales, ajustar los errores y defectos encontrados en las pruebas de aceptacin, capacitar a los usuarios y proveer el soporte tcnico necesario. Se debe verificar que el producto cumpla con las especificaciones entregadas por las personas involucradas en el proyecto.

2.4 El lenguaje de modelado unificado UML

Es un lenguaje visual de modelado y especificacin de sistemas, orientados a objetos, nopropietario, independiente del lenguaje de programacin, no especifico para soluciones de software. Soporta la presentacin de mdulos en diferentes vistas y perspectivas. Consta de 4 partes que evolucionan de forma independiente: 1. Superestructura. Define la notacin y semntica de los diagramas y elementos constituyentes. 2. Infraestructura. Define la meta-modelo central sobre el cual la Superestructura se basa. 3. Object Constraint Language (OCL). Para definir reglas de los elementos constituyentes del modelo. 4. Diagrama de intercambio UML. Define como los layout (acomodo) de UML son intercambiados. Se define a un diagrama UML como la representacin grafica parcial del modelo de un sistema. El modelo UML de un sistema es el conjunto de todos los diagramas que lo describen en sus diferentes vistas y perspectivas. El UML 2.2 define 14 diagramas divididos en 2 grandes categoras o vistas de un sistema: 1. Diagrama de Vista Esttica o estructural. Agrupa los diagramas que se enfocan en el aspecto estructural del modelo, en las relaciones inherentes e indisolubles entre los elementos constituyentes. Diagrama de perfil, de clase, de estructura compuesta, de componente, de despliegue, de objeto, de paquete. 2. Diagrama de Vista Dinmica o de comportamiento. Agrupa a los diagramas que se enfocan en el aspecto dinmico del sistema al mostrar colaboraciones entre los objetos y los cambios en el estado interno de estos. Diagrama de actividad, de interaccin (diagrama de secuencia, comunicacin, vista general interaccin, de tiempo), de caso de uso.