Proceso Unificado de Rational PROCESO UNIFICADO DE RATIONAL (RUP)

El proceso de desarrollo de software tiene cuatro roles importantes: 1. Proporcionar una gua de actividades para el trabajo en equipo. (Gua detallada para el desarrollo exitoso de un producto de software. Explicando qu hacer, cmo, cuando y quin debe hacerlo) 2. Especificar que artefactos debern desarrollarse y cuando debern aplicarse. 3. Direccionar las tareas de los desarrolladores individuales y al equipo en general. 4. Ofrecer criterios de monitoreo y medidas de los productos del proyecto. CONCEPTOS DEL PROCESO UNIFICADO El Proceso Unificado de Rational, es un proceso iterativo e incremental. Su alcance es identificar riesgos en el desarrollo de un proyecto durante el ciclo de vida, cuando es posible atacar y solucionar estos riesgos a tiempo y de manera eficiente. El Proceso Unificado de Rational, es un proceso de ingeniera de software, que proporciona un alcance disciplinario para asignar tareas y responsabilidades mediante un desarrollo organizacional. Su meta es asegurar una produccin de software de alta calidad, conociendo las necesidades de los usuarios con un horario y presupuesto predecible.

MODELOS DEL PROCESO UNIFICADO MODELO DE CASOS DE USO

Un Modelo de Casos de Uso consiste de actores, casos de uso y relaciones entre ellos. Los actores representan todo aquello que intercambia informacin con el sistema. Cuando un actor usa el sistema, el sistema ejecuta un caso de uso. Un buen caso de uso es una transaccin secuencial que produce un resultado para un actor. La coleccin de casos de uso es la funcionalidad completa de un sistema. El Modelo del Caso de Uso es usado como entrada esencial para las actividades de anlisis, diseo y pruebas.

MODELO DE ANLISIS El Modelo de Anlisis tiene el propsito de refinar los casos de uso ms detalladamente, y realizar una asignacin inicial del comportamiento del sistema; a un conjunto de objetos que proporcionen el funcionamiento esperado. Es un Modelo de Objetos que describe la realizacin de casos de uso, y sirve como abstraccin para el Modelo del Diseo. El Modelo de Anlisis contiene el resultado del anlisis de casos de uso, y clases. El Modelo de Anlisis es un artefacto opcional.

L.S.C. Mara de los Angeles Fierro Lpez

Pg. 1

Proceso Unificado de Rational MODELO DE DISEO El Modelo de Diseo define la estructura esttica del sistema, tales como: subsistemas, clases e interfaces, y la realizacin de los casos de uso como colaboraciones entre los subsistemas, clases e interfaces. Es un Modelo de Objetos que describe la realizacin del caso de uso, y sirve como una abstraccin del Modelo de Implementacin y sus cdigos fuentes. El Modelo del Diseo es usado como entrada esencial para las actividades de implementacin y pruebas. MODELO DE IMPLEMENTACIN El Modelo de Implementacin es una coleccin de componentes y subsistemas que los contienen. Los componentes incluyen archivos ejecutables, cdigos fuentes y libreras. Realizan el mapeo de las clases a los componentes. Incluyen componentes (representando cdigos fuentes). MODELO DE DEPLOYMENT El Modelo de Deployment muestra la configuracin de los procesos (nodos) en el tiempo de ejecucin, la liga de comunicacin entre ellos y los componentes y objetos que residen en ellos. Realizan el mapeo de los componentes a los nodos. Definen los nodos fsicos de las computadoras. MODELO DE PRUEBAS El Modelo de Pruebas es una representacin de lo que ser probado y como ser probado. Es una vista de los modelos de diseo e implementacin, describiendo las pruebas de ellos mismos. Esto incluye la coleccin de casos de pruebas, procedimientos de prueba, escritos de prueba y los resultados de prueba esperados junto con una descripcin de sus relaciones. Describen los casos de pruebas que verificarn los casos de uso.

L.S.C. Mara de los Angeles Fierro Lpez

Pg. 2

Proceso Unificado de Rational ESTRUCTURA DEL PROCESO UNIFICADO Figura 4.

La figura 4, muestra la arquitectura total del proceso unificado. El proceso tiene dos estructuras o dimensiones: 1. El eje horizontal representa el tiempo y muestra los aspectos del ciclo de vida del proceso. Representa el aspecto dinmico y es visto en trminos de ciclos, fases, iteraciones y milestones. Desarrollo Iterativo. 2. El eje vertical representa la secuencia de actividades del proceso. Representa el aspecto esttico y es visto en trminos de procesos, actividades, workflows, artefactos y workers. Representacin del Proceso.

ESTRUCTURA ESTTICA (Representacin del Proceso) Un proceso describe quin, qu, cmo y cundo se va a realizar una actividad. El Proceso Unificado de Rational es representado usando los cuatro principales elementos de modelado, ver figura 5. 1. 2. 3. 4. Workers: el quin. Activities: el cmo. Artifacts: el qu. Workflows: el cundo.

L.S.C. Mara de los Angeles Fierro Lpez

Pg. 3

Proceso Unificado de Rational

Figura 5.

1.

Workers

Es importante definir que rol tendr el personal del equipo durante el transcurso del proyecto. Una persona puede tener diferentes roles, ver figura 6. En RUP, el termino workers se refiere a los roles que definirn lo que el individuo deber realizar en su trabajo. Un worker ejecuta uno o ms roles y es el encargado de seleccionar los artefactos. Figura 6.

El Administrador del Proyecto ser el responsable de la planeacin del proyecto, de la seleccin del nmero de workers que se necesitarn para formar el equipo de trabajo, y tambin definir los roles que tendr cada uno de ellos.

Diferentes tipos de workers: Administrador del Proyecto. Analista de Sistemas. Arquitecto. Especificador de los Casos de Uso. Diseador de la Interface con el Usuario.

L.S.C. Mara de los Angeles Fierro Lpez

Pg. 4

Proceso Unificado de Rational 2. Activities Unidad de trabajo que desempea un worker. El propsito de las actividades, es la creacin y actualizacin de los artefactos, tales como: modelos, clases, etc. Cada actividad es asignada a un worker especfico. Las actividades pueden ser repetidas en diferentes tiempos, en el mismo artefacto, especialmente desde una iteracin a otra cuando el sistema es refinado y extendido. Diferentes tipos de actividades: Planeando una iteracin: realizada por el Administrador del Proyecto. Encontrando actores y casos de uso: realizada por el Analista de Sistemas. Priorizando casos de uso: realizada por el Arquitecto. Detallando un caso de uso: realizada por el Especificador de los Casos de Uso. Prototipo de interface con el usuario: realizada por el Diseador de la Interface con el Usuario. 3. Artifacts Los artefactos contienen descripciones de los elementos de informacin que son entradas o salidas del proceso. Esta informacin puede ser empaquetada en documentos y reportes. Un artefacto es una pieza de informacin que es producida, utilizada, y modificada por un proceso. Son productos tangibles del proyecto. Los artefactos son usados por los workers para ejecutar una actividad y son el resultado de esas actividades. Diferentes tipos de artefactos: El Analista de Sistemas es responsable del Modelo de Casos de Uso, Actor, Glosario. El Especificador de los Casos de Uso es responsable de los Casos de uso. El Arquitecto es responsable de la Descripcin Arquitectural. El Diseador de la Interface con el Usuario es responsable de modelar el Prototipo de la Interface con el Usuario. Modelo del diseo almacenado en Rational Rose. Plan del proyecto almacenado en Microsoft Project. 4. Workflows

Los desarrolladores de software, necesitan conocer el camino que los ayude a describir adecuadamente la secuencia de actividades que producirn resultados valorables y mostrarn las interacciones entre los workers. La figura 7, representa el workflow de iteraciones en cada fase.

L.S.C. Mara de los Angeles Fierro Lpez

Pg. 5

Proceso Unificado de Rational

Figura 7.

Un workflow, es una secuencia de actividades que producen el resultado de un valor esperado, y se enfoca principalmente a los siguientes aspectos especficos de un proceso de desarrollo iterativo: 1. Mitigacin de riesgos. 2. Planeacin de un proyecto iterativo a travs de un ciclo de vida y de una iteracin en particular. 3. Monitoreo del progreso de un proyecto iterativo y metrics. Existen muchos caminos para organizar nuestras actividades. El proceso unificado utiliza los siguientes workflows:

L.S.C. Mara de los Angeles Fierro Lpez

Pg. 6

Proceso Unificado de Rational

Workflows de proceso

Representan una divisin de todos los workes y actividades dentro de grupos lgicos y es dividido en seis workflows de ingeniera y tres de soporte. Las fases de un proceso iterativo son diferentes y estos workflows son revisados una y otra vez a travs del ciclo de vida del sistema.

Workflows de Ingeniera

Workflows de soporte

Modelo de Negocios. Requerimientos. Anlisis y Diseo. Implementacin. Pruebas. Deployment. Configuracin y Administrador Cambios. 2. Administrador de Proyectos. 3. Ambiente.

1. 2. 3. 4. 5. 6. 1.

de

ESTRUCTURA DINMICA (Desarrollo Iterativo) La estructura dinmica del proceso unificado, muestra el desarrollo iterativo utilizando las fases de inicio, elaboracin, construccin y transicin, milestones e iteraciones, con la finalidad de mitigar los riesgos y evolucionar incrementalmente, ver figura 8. FIGURA 8.

L.S.C. Mara de los Angeles Fierro Lpez

Pg. 7

Proceso Unificado de Rational

El desarrollo de productos de software puede durar varios meses, o quizs un ao o ms. Hay que dividir el trabajo en pequeos miniproyectos, donde cada miniproyecto ser una iteracin que resulta en un incremento. Para ser ms efectivos, las iteraciones sern controladas, seleccionadas y llevadas en la planeacin del proyecto. En cada iteracin los desarrolladores identifican y especifican los casos de uso relevantes, crean diseos utilizando arquitecturas bases, implementando el diseo en componentes y verificando que stos satisfagan los casos de uso. Si una iteracin encuentra su meta, se procede con una siguiente iteracin. Cuando la iteracin no encuentra una meta, los desarrolladores debern revisar decisiones previas y tratar un nuevo alcance. El proceso iterativo es organizado en cuatro fases: Fase Inicio Elaboracin Descripcin Se entienden los requerimientos y se define el alcance del sistema. Se analiza el dominio del problema, se desarrolla el plan del proyecto, y recursos requeridos. Especfica las caractersticas y se disea la arquitectura. Se construye el producto. Se realiza la entrega del sistema a los usuarios, manuales, entrenamiento, soporte y mantenimiento hasta que los usuarios estn satisfechos.

Construccin Transicin

Las cuatro fases constituyen un desarrollo cclico y producen una generacin de software y muestran la duracin y esfuerzo por cada fase, ver figura 9. Figura 9..

La figura 10, muestra el perfil en una visin tabular

L.S.C. Mara de los Angeles Fierro Lpez

Pg. 8

Proceso Unificado de Rational

Figura 10 Fase Inicio Elaboracin Consruccion Transicin

Porcentaje Esperado 10 30 50 10

Porcentaje Obtenido 5 20 65 10

Cantidad de Iteraciones 0-1 1-3 1-3 1-2

A continuacin se presenta la secuencia de actividades que se debe desarrollar en cada fase del proceso unificado: FASE DE INICIO Se define el alcance del sistema y el esquema de la arquitectura candidata.

FASE DE ELABORACIN Se capturan y refinan los requerimientos y se desarrolla la arquitectura baseline.

L.S.C. Mara de los Angeles Fierro Lpez

Pg. 9

Proceso Unificado de Rational

FASE DE CONSTRUCCIN En esta fase se construye el sistema.

L.S.C. Mara de los Angeles Fierro Lpez

Pg. 10

Proceso Unificado de Rational

FASE DE TRANSICIN Las actividades de implementacin y de pruebas, tienen un mayor enfoque en esta fase. Actividades que se deben de realizar en la fase de transicin: 1. Preparando la liberacin beta. El equipo del proyecto, prepara la documentacin previa, para los usuarios que probarn el sistema. Ellos suplementan este documento con especficas instrucciones, seleccionan los usuarios y distribuyen la liberacin beta con material anexo. Instalando la liberacin beta. Se deben de especificar las instrucciones que indiquen como instalar el software de pruebas, como opera, los problemas que podrn presentarse a los usuarios, y como comunicar los errores u otros problemas encontrados. Si la liberacin es una actualizacin o un reemplazo de un software existente, el personal de transicin proporciona instrucciones, de cmo los usuarios migrarn la informacin o convertirn las bases de datos a la nueva liberacin. Las instrucciones pueden presentarse en paralelo con la liberacin beta y el software anterior por un perodo de tiempo. Respondiendo a los resultados de las pruebas. El proyecto analiza los resultados de las pruebas, y se concentran en dos clases: en los errores de cdigos menores y en problemas ms importantes, extendiendo la posibilidad de un cambio en la arquitectura.

2.

3.

Error: un error resulta en primera instancia en un defecto de un componente, pero este defecto ocasiona regresar a las actividades de anlisis, diseo, o modelos previos. Si es difcil encontrar el error en el modelo del sistema, se buscar asistencia del Ingeniero de Componentes u otra persona para que realice el trabajo original en la rea encontrada. Problemas mayores: es importante mantener la integridad de la Arquitectura del Sistema, mientras se corrigen los problemas y defectos. El Arquitecto sigue el progreso del trabajo de la transicin. Si las actividades en est fase afectan la arquitectura, el Arquitecto actualiza su descripcin. Por supuesto que pocas son las organizaciones que liberan productos sin defectos. El Administrador del Proyecto debe de medir el costo y tiempo presentados en un caso de negocio.
4. Adaptando el producto a los usuarios.

L.S.C. Mara de los Angeles Fierro Lpez

Pg. 11