DESARROLLADORES DE SOFTWARE RUP

David Rivera Cruz

El Proceso Unificado de Rational (Rational Unified Process conocido como RUP) un producto rational (IBM), 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 sistema orientado a objeto. El RUP no es un sistema con paso firme estableciendo, sino un conjunto de metodologa adaptable al contexto y necesidades de la organizacin. Se caracteriza por ser interactivo e incremental, est centrado en la arquitectura y guiados los casos de uso. Incluyendo artefactos y roles. Este proceso suministra un enfoque para asignar tareas y responsabilidades dentro de una organizacin de desarrollo. Su objetivo es asegurar la produccin de software de alta calidad, que satisfaga las necesidades del usuario final dentro del tiempo y presupuesto establecido. Es una metodologa de desarrollo iterativo enfocada hacia Los caso de uso, manejo de riesgo y el manejo de arquitectura Ciclo de vida El ciclo de vida RUP es una implementacin del desarrollo espiral. El RUP maneja el proceso en cuatro fases dentro de los cuales se realizan varias iteraciones. 1. DIMENSIONES DEL RUP El RUP tiene 2 dimensiones:

eje horizontal representa tiempo y demuestra los aspectos del ciclo de vida del proceso. El eje vertical representa las disciplinas, que agrupan actividades definidas por la naturaleza. La primera dimensin presenta el aspecto dinmico del proceso y se expresa en trminos de faces, de interacciones. La segunda dimensin representa el aspecto esttico del proceso: como se describe en trminos de componentes de proceso, disciplinas, actividades, flujos de trabajo, artefactos y los roles. Por eje. En iteraciones tempranas pasamos, ms tiempo en requerimientos.
Figura 1. Disciplinas, fases, iteraciones del RUP

El

Se tiene 3 caterateristicas esenciales que define al RUP: Proceso dirigido por casos de uso: la utilizacin de los casos de uso, para el desarrollo de las disciplinas con los artefactos, roles y actividades necesarias. Los casos de uso son la base para la implementacin de las fases y disciplinas del RUP. Un caso de uso se relaciona directamente con el

requerimiento y es la secuencia de pasos que conlleva la realizacin e implementacin de un requerimiento planteado por el cliente. Proceso Iterativo Incremental: Es el modelo utilizado por RUP para el desarrollo de un proyecto de software el cual plantea realizar iteraciones, definiendo objetivo a cumplir en cada interaccin y tiene ventajas que se puede tener pequeos avances del proyectos que son entregables al cliente que puede probar mientras se desarrolla otra interaccin del proyecto hacia va creciendo el proyecto hasta completar en su totalidad. Proceso Centrado en Arquitectura: Define la arquitectura de un sistema, y una arquitectura ejecutable construida como un prototipo evolutivo. Una arquitectura es una implementacin parcial del sistema, construida para demostrar funciones y propiedades. RUP establece refinamiento sucesivo a una arquitectura ejecutable, construida, como un prototipo evolutivo. 2. FACES
Figuran 2 Fases del RUP

2.1. Planeado las Fases El ciclo de vida consiste ciclos, cada uno de los una nueva versin del ciclo est compuesto iteraciones: en una serie de cuales produce producto, cada por fases e

2.1.1 Concepcin, Inicio

Define el mbito y objetivos del proyecto Se define la funcionalidad y capacidades del producto 2.1.2 Elaboracin Tanto la funcionalidad como el dominio del problema se estudian en profundidad Se define una arquitectura bsica Se planifica el proyecto considerando recursos disponibles 2.1.3 Construccin El producto se desarrolla a travs de iteraciones donde cada iteracin involucra tareas de anlisis, diseo e implementacin Las fases de estudio y anlisis slo dieron una arquitectura bsica que es aqu refinada de manera incremental conforme se construye (se permiten cambios en la estructura) Gran parte del trabajo es programacin y pruebas Se documenta tanto el sistema construido como el manejo del mismo 2.1.4 Transicin Se libera el producto y se entrega al usuario para un uso real Se incluyen tareas de marketing, empaquetado atractivo, instalacin, configuracin, entrenamiento, soporte, mantenimiento, etc.

El ciclo de vida del software del RUP se descompone en cuatro fases secuenciales (figura 2). En cada extremo de una fase se realiza una evaluacin (actividad: Revisin del ciclo de vida de la finalizacin de fase) para determinar si los objetivos de la fase se han cumplido y que se mueva a la prxima fase

Los manuales de usuario se completan y refinan con la informacin anterior. Todas las fases no son idnticas en trminos de tiempo y esfuerzo. Aunque esto vara considerablemente dependiendo del proyecto.

Lo cual se representa en la figura 3:

2.2. Esfuerzo respecto al flujo de trabajo En la figura 5 se muestran ciertos porcentajes, de forma vertical se muestra el esfuerzo que se tiene que realizar por cada una de las disciplinas o flujos de trabajo, y los dos porcentajes que se muestran de forma horizontal son para todo el proyecto. Explicando mas puntualmente la figura 5 se puede observar que para la obtencin de requerimientos o requisitos en la fase de concepcin se empiezan a obtener, en la fase de elaboracin tiene su auge y va declinando en la fase de construccin, pero puede variar de un proyecto a otro.
Figura 5. Esfuerzo respecto de los flujos de trabajo

3. DISCIPLINAS Las disciplinas conllevan los flujos de trabajo, los cuales son una secuencia de pasos para la culminacin de cada disciplina, estas disciplinas se dividen en dos grupos: las primarias y las de apoyo. Las primarias son las necesarias para la realizacin de un proyecto de software, Las de apoyo son las que como su nombre lo indica sirven de apoyo a las primarias y especifican otras caractersticas en la realizacin de un proyecto de software. A continuacin se describe rpidamente cada una de estas disciplinas.
3.1 Primarias

Modelado del negocio Esta disciplina tiene como objetivos comprender la estructura y la dinmica de la organizacin, comprender problemas actuales e identificar posibles mejoras. Utiliza el Modelo de CU del Negocio para describir los procesos del negocio y los clientes, el Modelo de Objetos del Negocio para describir cada CU del Negocio con los Trabajadores, adems utilizan los Diagramas de Actividad y de Clases. Requerimientos Esta disciplina tiene como objetivos establecer lo que el sistema debe hacer (Especificar Requisitos), definir los lmites del sistema, y una interfaz de

usuario, realizar una estimacin del costo y tiempo de desarrollo. Utiliza el Modelo de CU para modelar el Sistema que comprenden los CU, Actores y Relaciones, adems utiliza los diagramas de Estados de cada CU y las especificaciones suplementarias. Anlisis y diseo Esta disciplina define la arquitectura del sistema y tiene como objetivos trasladar requisitos en especificaciones de implementacin, al decir anlisis se refiere a transformar CU en clases, y al decir diseo se refiere a refinar el anlisis para poder implementar los diagramas de clases de anlisis de cada CU, los diagramas de colaboracin de de cada CU, el de clases de diseo de cada CU, el de secuencia de diseo de CU, el de estados de las clases, el modelo de despliegue de la arquitectura. Implementacin Esta disciplina tiene como objetivos implementar las clases de diseo como componentes (ej. fichero fuente), asignar los componentes a los nodos, probar los componentes individualmente, integrar los componentes en un sistema ejecutable (enfoque incremental). Utiliza el Modelo de Implementacin, conjuntamente los Diagramas de Componentes para comprender cmo se organizan los Componentes y dependen unos de otros. Pruebas Esta disciplina tiene como objetivos verificar la integracin de los componentes (prueba de integracin), y todos los requisitos han sido implementados (pruebas del sistema), asegurar que los defectos detectados han sido resueltos antes de la distribucin Despliegue Esta disciplina tiene como objetivos asegurar que el producto est preparado

para el cliente, proceder a su entrega y recepcin por el cliente. Se realizan pruebas en su entorno final (Prueba Beta), e instalarlo, as como la tarea de ensear al usuario. 3.2 De apoyo Gestin y configuracin de cambios Es esencial para controlar el nmero de artefactos producidos por la cantidad de personal que trabajan en un proyecto conjuntamente. Los controles sobre los cambios ya que evitan confusiones costosas como la compostura de algo que ya se haba arreglado etc., siguientes tipos de problemas: Actualizacin simultnea: Notificacin limitada: Versiones mltiples: Gestin del proyecto Su objetivo es equilibrar los objetivos competitivos, administrar el riesgo, y superar restricciones para entregar un producto que satisface las necesidades de ambos clientes con xito. Con la En resumen su propsito consiste en proveer pautas para: Administrar proyectos de software intensivos. Planear, dirigir personal, ejecutar acciones y supervisar proyectos. Administrar el riesgo. Esta disciplina no cubre los aspectos como: Administracin de personal: contratando, entrenando, enseando. Administracin del presupuesto: definiendo, asignando. Administracin de los contratos con proveedores y clientes. 4 BIBLIOGRAFIA
4.1 Aplicacin de la metodologa rup para el Desarrollo rpido de aplicaciones basado en el Estndar j2ee de Julio Cesar Rueda Chacn

4.2 Introduccin al UML http://www.yoprogramo.com/articulo4.php 4.3 Metodologa de desarrollo de sistemas basados en el ciclo de vida http://comip.mendoza.gov.ar/metodologia%20para %20el%20desarrollo%20 de%20sistemas.pdf 4.5 Modelos para el desarrollo de software http://docentes.usaca.edu.co/wildiaz/INGSOF_MO DELOS.html 4.6 Para quines est desarrollado XDE? http://www.rational.com.ar/herramientas/desarrollo desoftware.html#XDE 4.7 www.Proceso Unificado de Rational Wikipedia, la enciclopedia libre