PRACTICA

RATIONAL UNIFIED PROCESS (RUP- Proceso Racional Unificado)

Es un proceso de desarrollo de software y junto con el Lenguaje Unificado de Modelado UML, constituye la metodología estándar más utilizada para el análisis, implementación y documentación de sistemas orientados a objetos

Ventajas:

• Un proceso de software hecho a la medida para ser publicado y hacerlo accesible para todo el equipo del proyecto.

• Un proceso de software configurable, para satisfacer necesidades específicas de un proyecto.

RUP se basa en la evolución de prototipos ejecutables o versiones del producto final que se muestran a los usuarios e inversionistas del proyecto. Cada paso por el ciclo de vida produce una versión del producto que incrementalmente se va refinando en las iteraciones de las diferentes fases. Si llegado el final del ciclo de vida de RUP., el producto no cumple con los objetivos planteados, se puede realizar un ciclo más para refinar, corregir y agregar funcionalidades.

Elementos Básicos De RUPCon RUP, un proceso de desarrollo es representado usando un conjunto de elementos de modelado, tales como: roles, actividades, artefactos y flujos de trabajo (workflows), entre otros. Un rol expresa quién (individuo o grupo) hace un trabajo, una actividad describe cómo es hecho el trabajo y un artefacto captura el trabajo realizado. En RUP se encuentran 4 elementos básicos: los roles (el quién), las actividades (el cómo), los artefactos (el qué) y los flujos de trabajo (el cuándo).La estructura estática de RUP maneja cómo los elementos del proceso (actividades, disciplinas, artefactos y roles) están lógicamente agrupados dentro del corazón de las disciplinas del proceso.

Pagina: 1

RUP (Proceso Unificado de Racional)

R U P e s u n p r o c e s o p a r a e l d e s a r r o l l o d e u n p r o y e c t o d e s o f t w a r e q u e d e f i n e l a s s i g u i e n t e s f a s e s :

FASE DE INICIO

Durante la fase de inicio se define el modelo del negocio y el alcance del proyecto.

Se identifican todos los actores y Casos de Uso.

FASE DE ELABORACION p r o p ó s i t o d e l a f a s e d e e l a b o r a c i ó n e s a n a l i z a r e l d o m i n i o d e l

p r o b l e m a .

Es tab lece r l os c im ien to s de l a a rqu i t e c tu ra .

Desa r ro l l a r e l p lan de l p ro ye c t o y eliminar los mayores riesgos.

PRACTICA

Pagina: 2

FASE DE CONSTRUCCION

L a f i n a l i d a d p r i n c i p a l d e e s t a f a s e e s a l c a n z a r l a c a p a c i d a d o p e r a c i o n a l d e l producto de forma incremental a través de las sucesivas iteraciones.

FASE DE TRANSICION

La finalidad de la fase de transición es poner el producto en manos de los usuarios f i na les , pa ra l o qu e se re qu ie re des a r ro l l a r nuevas ve rs io ne s ac tua l i za da s de l p rodu c to .

NOTACIÓN DE LA METODOLOGÍA Y DISCIPLINAS.

Las disciplinas conllevan los flujos de trabajo, los cuales son una secuencia de pasos para la culminación de cada disciplina.

Modelado del negocio. Esta disciplina tiene como objetivos comprender la estructura y

la dinámica de la organización.

Requerimientos.

Esta disciplina tiene como objetivos establecer lo que el sistema debe hacer (Especificar Requisitos), definir los límites del sistema, y una interfaz de usuario, realizar una estimación del costo y tiempo de desarrollo.

Análisis y diseño.

Esta disciplina define la arquitectura del sistema y tiene como objetivos trasladar requisitos en especificaciones de implementación, al decir análisis se refiere a transformar CU en clases, y al decir diseño se refiere a refinar el análisis para poder implementar los diagramas de clases

Implementación.

Esta disciplina tiene como objetivos implementar las clases de diseño como componentes (ej. fichero fuente), asignar los componentes a los nodos, probar los componentes individualmente.

Pruebas.

Esta disciplina tiene como objetivos verificar la integración de los componentes (prueba de integración), verificar que todos los requisitos han sido implementados (pruebas del sistema), asegurar que los defectos detectados han sido resueltos antes de la distribución

Despliegue.

Esta disciplina tiene como objetivos asegurar que el producto está preparado para el cliente, proceder a su entrega y recepción por el cliente.

Gestión y configuración de cambios.

Es esencial para controlar el número de artefactos producidos por la cantidad de personal que trabajan en un proyecto conjuntamente.

PRACTICA

¿Cuándo Usar RUP?

RUP puede ser utilizado desde el principio de un proyecto de software y puede continuar usándose en los subsecuentes ciclos de desarrollo del software después que

la fase inicial ha finalizado. Sin embargo, la manera en la cual se use RUP, necesita ser trasformada para ajustarse a las necesidades. Existen algunas consideraciones que modifican el cuándo y cómo se utilizarán las diferentes partes de RUP, éstas son:

• El ciclo de vida del proyecto (número de iteración, longitud de cada fase, el largo del

proyecto).

• Los objetivos de negocio del proyecto, visión, alcance y riesgos.

• El tamaño del esfuerzo para el desarrollo del software.

Aproximadamente 10.000 compañías están usando RUP. Estas compañías usan RUP en varios dominios de aplicación, de una manera equilibrada en proyectos grandes o pequeños. Esto muestra lo versátil de RUP y su amplia aplicabilidad. Algunos ejemplos de las industrias que usan RUP son empresa de: telecomunicación, transporte, servicios financieros, manufacturas, integradores de sistemas, entre otros.

Pagina: 3