Metodologa RUP

Metodologa RUP
La metodologa RUP , abreviatura de Rational Unified Process (o Proceso Unificado
Racional), es un proceso propietario de la ingeniera de software creado por Rational
Software , adquirida por IBM , ganando un nuevo nombre Irup que ahora es una
abreviatura Rational Unified Process y lo que es una marca en el rea de
software, proporcionando tcnicas que deben seguir los miembros del equipo de
desarrollo de software con el fin de aumentar su productividad en el proceso
de desarrollo.

La metodologa RUP utiliza el enfoque de la orientacin a objetos en su diseo y est

diseado y documentado el uso de la notacin UML ( Unified Modeling Language )
para ilustrar los procesos en accin. Utiliza tcnicas y prcticas probadas
comercialmente.
Es un proceso considerado pesado y preferentemente aplicable a grandes equipos de
desarrollo y grandes proyectos , pero el hecho de que es ampliamente personalizable
que permite adaptarse a proyectos de cualquier escala.

Para la gestin del proyecto , la metodologa RUP proporciona una solucin

disciplinada como las tareas y responsabilidades sealadas dentro de una organizacin
de desarrollo de software.
RUP es, en s, un producto de software. Es modular y automatizado, y toda su
metodologa se apoya en varias herramientas de desarrollo integradas y vendidos por
IBM a travs de sus Suites racional.
 Los mtodos de la competencia en el campo de la ingeniera de software incluyen
salas blancas (considerado pesado) y gil (luz) como Extreme Programming
(Programacin XP-Extreme), Scrum , FDD y otros.

Contenido
1 Directrices de la metodologa RUP
o 1.1 Requisitos de gestin
o 1.2 El uso de una arquitectura basada en componentes
o 1.3 El uso de modelos visuales de software en la metodologa RUP
o 1.4 Comprobar la calidad del software
o 1.5 Software de gestin y de cambio de control
2 Fases de la metodologa RUP
o 2.1 Fase de diseo
o 2.2 Fase de elaboracin
o 2.3 Fase de construccin
o 2.4 Fase de transicin
3 Disciplinas de la metodologa RUP
o 3.1 Seis Disciplinas de Ingeniera de Software
o 3.2 Tres Disciplinas Soporte / Servicio de la metodologa RUP
4 Principios y las mejores prcticas de la metodologa RUP
o 4.1 Desarrollo iterativo
o 4.2 La gestin de requisitos
o 4.3 El uso de una arquitectura basada en componentes
o 4.4 Software de modelado visual
o 4.5 Software de control de calidad
o 4.6 Control de cambios en el software

DIRECTRICES DE LA METODOLOGA RUP

RUP define las siguientes lneas maestras y los esqueletos ( plantillas ) para los
miembros del personal de un ciclo de produccin: parte del cliente, y una evaluacin de
los avances del proyecto por su gestin. Ayuda a los desarrolladores para mantener la
concentracin en el proyecto.

REQUISITOS DE GESTIN
La documentacin apropiada es esencial para cualquier proyecto de gran envergadura;
en cuenta que RUP describe cmo documentar la funcionalidad, las limitaciones del
sistema, restricciones de diseo y requisitos de negocio.

Los casos de uso (en Ingls Casos de uso ) y los escenarios son ejemplos de artefactos
de proceso dependiente, que se han considerado mucho ms eficaz en la captura de
requisitos funcionales.

EL USO DE UNA ARQUITECTURA BASADA EN

COMPONENTES
La arquitectura basada en componentes crea un sistema que puede ser fcilmente
extensible, promoviendo la reutilizacin y el software una comprensin intuitiva. Un
componente se refiere normalmente a un objeto en la programacin orientada a objetos.
RUP proporciona una manera sistemtica para construir este tipo de sistema,
centrndose en la produccin de una arquitectura ejecutable en las primeras etapas del
proyecto, es decir, antes de comprometer recursos a gran escala.

Estos componentes se incluyen normalmente en las infraestructuras existentes, tales

como CORBA y COM (Component Object Model).

EL USO DE MODELOS VISUALES DE SOFTWARE EN

LA METODOLOGA RUP
Al abstraer la programacin de su cdigo y representarla utilizando bloques de
construccin grficas, RUP puede una manera eficaz de conseguir una visin general de
una solucin.

El uso de modelos visuales tambin puede permitir que los individuos menos perfil
tcnico (como clientes) tienen una mejor comprensin de un problema dado, y as estar
ms involucrados en el proyecto en su conjunto.

El lenguaje de modelado UML se ha convertido en un estndar de la industria para

representar los proyectos, y es ampliamente utilizado por RUP!

COMPROBAR LA CALIDAD DEL SOFTWARE

No asegura la calidad del software es el fallo ms comn en todos los proyectos de
sistemas informticos. Por lo general, uno piensa en la calidad del software despus de
la finalizacin de los proyectos, o la calidad es la responsabilidad de un equipo de
desarrollo de equipo diferente.

RUP tiene como objetivo ayudar en el control de la planificacin de la calidad,

comprobando que en la construccin de todo el proceso y la participacin de todos los
miembros del equipo de desarrollo.

SOFTWARE DE GESTIN Y DE CAMBIO DE CONTROL

En todos los proyectos de software de la existencia del cambio es inevitable. RUP
define mtodos para controlar y vigilar los cambios. Como un pequeo cambio puede
afectar a las aplicaciones de maneras totalmente impredecibles, el control de cambio es
esencial para el xito de un proyecto.

RUP tambin define las reas de trabajo y seguridad , lo que garantiza un programador
que cambia en otro sistema no afectar a su sistema.

FASES DE LA METODOLOGA RUP

Hasta ahora estas lneas gua son generales, para ser adherido a pasar por la vida de un
ciclo de proyecto. Las fases (ver figura abajo) indican el nfasis se da en el proyecto en
un instante dado. Para capturar la dimensin temporal de un proyecto, RUP divide el
proyecto en cuatro fases diferentes:
 Iniciacin o Diseo : nfasis en el alcance del sistema;
Preparacin : nfasis en la arquitectura;
Construccin : nfasis en el desarrollo;
Transicin : nfasis en la aplicacin.
RUP se basa tambin en las 4 Ps:
Personas
Diseo
Producto
Proceso
Las capas se componen de iteraciones. Iteraciones son ventanas de tiempo; iteraciones
han definido trmino como las fases son objetivos.

Todas las fases generan artefactos. Estos sern utilizados en la siguiente fase y
documentar el proyecto y permite un mejor seguimiento.

FASE DE DISEO
La fase de diseo o de iniciacin contiene los flujos de trabajo necesarios para el
acuerdo de las partes interesadas interesados con los objetivos, la arquitectura y la
planificacin del proyecto. Si estos actores tienen un buen conocimiento, no ser
necesario analizar. De lo contrario, se requiere un anlisis ms elaborado.

En esta etapa, los requisitos esenciales del sistema se transforman en los casos de uso .
El objetivo no es para cerrarlas en absoluto, sino slo las que sean necesarias para dar
forma a la opinin.

El paso es generalmente corto y se utiliza para definir si es factible para continuar con el
proyecto y definir los riesgos y el coste de la ltima. Un prototipo se puede hacer para
que el cliente apruebe. Como cita el RUP, lo ideal es realizar iteraciones , las cuales
deben estar bien definida en cuanto a su importe y objetivos.

FASE DE ELABORACIN
La preparacin ser para el diseo del sistema, como complemento de la encuesta y / o
documentacin de casos de uso, frente a la arquitectura del sistema, revisar el modelo de
negocio para el proyecto e iniciar la versin del manual del usuario. Uno debe aceptar:
Descripcin del producto (aumento + integracin) es estable;? El plan del proyecto es
fiable?; Los costos son elegibles?

FASE DE CONSTRUCCIN
En la fase de construccin, el desarrollo fsico del software se inicia, cdigos de
produccin, pruebas alfa. pruebas beta se llevaron a cabo al inicio de la fase de
transicin.

Se debe aceptar las pruebas, procesos estables y de prueba, y el cdigo del sistema son
lnea de base.

FASE DE TRANSICIN
En esta fase es la entrega ( despliegue) de software, que se lleva a cabo el plan de
despliegue y entrega, el seguimiento y la calidad del software. Productos (lanzamientos,
las versiones) se van a entregar, y coloque la satisfaccin del cliente. Esta etapa tambin
se lleva a cabo la formacin de los usuarios.

DISCIPLINAS DE LA METODOLOGA RUP

SEIS DISCIPLINAS DE INGENIERA DE SOFTWARE
LA DISCIPLINA MODELADO DE NEGOCIO
Las organizaciones dependen cada vez ms de los sistemas de TI , por lo que es
imperativo que los ingenieros de sistemas de informacin saben cmo se integran las
aplicaciones en el desarrollo de la organizacin. Las empresas invierten en TI, que
entienden la ventaja competitiva del valor aadido por la tecnologa.

El objetivo de modelado de negocio es establecer primero una mejor comprensin y

comunicacin entre ingeniera de negocios y la ingeniera de software.

Comprender el negocio significa que los ingenieros de software deben entender la

estructura y la dinmica de la empresa objetivo (el cliente), los problemas actuales de la
organizacin y las posibles mejoras. Tambin deben asegurar una comprensin comn
de la organizacin de destino entre los clientes, usuarios finales y desarrolladores.

El modelado de negocios explica cmo describir la visin de una organizacin en la que

se implementar el sistema y cmo utilizar esta visin como base para describir los
procesos, funciones y responsabilidades.

REQUISITOS DEL CURSO

Este curso explica cmo al llegar peticiones de las partes interesadas ( partes
interesadas) y los convierten en un conjunto de requisitos que los productos funcionan
dentro del sistema que se construirn y proporcionar los requisitos detallados para lo
que es necesario que el sistema.

ANLISIS Y DISEO DE LA DISCIPLINA ( DISEO)

El propsito del anlisis y diseo es mostrar cmo se llevar a cabo el sistema. El
objetivo es construir un sistema que:
Ejecutar en un entorno de ejecucin especfica, las tareas y las funciones especificadas
en las descripciones de casos de uso

Satisfacer todas sus necesidades

Es fcil de mantener cuando no son cambios en los requisitos funcionales, los resultados
del proyecto en un modelo de anlisis y diseo tiene opcionalmente un modelo de
anlisis. El modelo de diseo sirve como una abstraccin del cdigo fuente, es decir, el
proyecto sirve como modelo de retroalimentacin de la forma en que el cdigo fuente
est estructurado y escrito.

El modelo de diseo consta de clases de diseo estructurados en paquetes y subsistemas

con interfaces bien definidas, en representacin de lo que se convertir componentes de
la aplicacin. Tambin contiene descripciones de cmo los objetos de estas clases
colaboran para llevar a cabo el diseo de casos de uso.

LA DISCIPLINA IMPLEMENTACIN
Los efectos de la aplicacin son:

Para configurar el cdigo de la organizacin en trminos de subsistemas de

aplicacin organizados en capas
Para llevar a cabo las clases y objetos en trminos de componentes (archivos de
cdigo fuente, binarios, ejecutables, etc.)
Para probar los componentes desarrollados como unidades
Incorporar los resultados producidos por los ejecutores individuales (o equipos), en
un sistema ejecutable
Los sistemas se logran a travs de los componentes de la aplicacin. El proceso describe
cmo reutilizar componentes existentes o implementar nuevos componentes con
responsabilidades bien definidas, haciendo que el sistema sea ms fcil de mantener y
aumentar las posibilidades de reutilizacin.

PRUEBA DE DISCIPLINA
Los fines de disciplina prueba son:

Comprobar la interaccin entre los objetos

Comprobar la correcta integracin de todos los componentes de software
Compruebe que todos los requisitos han sido ejecutadas correctamente
Identificar y asegurar que los defectos se tratan antes de la implementacin de software
Asegrese de que todos los defectos son corregidos, revisados y cerrados

El Rational Unified Process propone un enfoque iterativo, lo que significa que debera
estar probando el proyecto en su totalidad. Esto le permite encontrar defectos tan pronto
como sea posible, lo que reduce drsticamente el costo de reparar el defecto.

Las pruebas se realizan a lo largo de cuatro dimensiones de la calidad: fiabilidad,

funcionalidad, rendimiento de las aplicaciones y el rendimiento del sistema . Para cada
una de estas dimensiones de la calidad, el proceso se describe cmo a pasar la prueba de
la planificacin, diseo, implementacin, ejecucin y evaluacin.
LA DISCIPLINA IMPLEMENTACIN
El propsito del despliegue es producir lanzamientos de productos exitosos y entregar el
software a los usuarios finales. Abarca una amplia gama de actividades, incluyendo la
produccin de versiones de software externos, el envase de aplicaciones de software y
de negocios, distribucin de software, instalacin de software y proporcionar ayuda y
asistencia a los usuarios.

Aunque las actividades de despliegue se centran principalmente en torno a la transicin,

muchas de las actividades se deben incluir en las etapas anteriores para preparar la
aplicacin, al final de la fase de construccin. Los procesos ( flujos de trabajo) de
Implementacin y Medio Ambiente RUP contienen menos detalles que otros flujos de
trabajo.

TRES DISCIPLINAS SOPORTE / SERVICIO DE

LA METODOLOGA RUP
DISCIPLINA PARA EL MEDIO AMBIENTE
El medio ambiente se centra en las actividades necesarias para configurar el proceso
para un proyecto. En l se describen las actividades necesarias para desarrollar
directrices para apoyar un proyecto.

La propuesta de las actividades ambientales es proporcionar a los procesos de

organizacin de desarrollo de software y herramientas que apoyarn al equipo de
desarrollo. Si los usuarios no entienden que RUP RUP es un marco de proceso, pueden
percibirlo como un proceso engorroso y costoso. Sin embargo, un concepto clave en las
RUP era la lata RUP y, a menudo debe ser refinado.

Esto se hizo inicialmente de forma manual, es decir, un documento caso del complejo
escrito que especifica el proceso de refinado para ser utilizado. Ms tarde, IBM
producto Compositor Mtodo Racional fue creado para ayudar a hacer este paso simple,
ingenieros de proceso y los directores de proyectos podra ms fcilmente personalizar
el RUP para sus necesidades del proyecto.

Muchas de las variaciones posteriores de las regiones ultraperifricas, incluidas

OpenUP / Basic, el cdigo abierto, versin ligera de RUP, se presentan ahora como
procesos separados en su propio derecho, y atender a los diferentes tipos y tamaos de
proyectos, tendencias y tecnologas de desarrollo de software.

Histricamente, como el RUP es a menudo la medida para cada proyecto por un experto
en procesos RUP, el xito global del proyecto puede ser algo dependiente de la
capacidad de esta persona.

CONFIGURACIN DE LA DISCIPLINA Y DE LA GESTIN

La disciplina de la gestin del cambio en el negocio con RUP abarca tres tratamientos
especficos: configuracin, solicitudes de cambio, y el estado y de medida.
La gestin de configuracin: gestin de la configuracin es responsable de la
estructuracin sistemtica de productos. Los artefactos tales como documentos y
modelos necesitan estar bajo el control de versiones y estos cambios deben ser visibles.
Tambin realiza un seguimiento de las dependencias entre los artefactos de manera que
todos los artculos relacionados se actualizan cuando se realizan cambios
La gestin del cambio de solicitud: Durante el proceso de desarrollo del sistema con
muchos artefactos que existen varias versiones. El CRM realiza un seguimiento de los
cambios propuestos
El estado y la medicin de la gestin: las solicitudes de cambio tienen los estados:
nuevo , conectado , aprobado , asignado y completa . La solicitud de cambio tambin
tiene atributos como la causa raz, o la naturaleza (como el incumplimiento y
recuperacin), prioridad, etc.
Estos estados y atributos se almacenan en la base de datos para producir informes
tiles sobre el progreso del proyecto. Racional tambin tiene un producto para mantener
las solicitudes de cambio llamados ClearQuest . Esta actividad tiene procedimientos a
seguir
PROYECTO DE GESTIN DE LA DISCIPLINA
La planificacin del proyecto en el RUP se produce en dos niveles. Hay un grano fino o
planes de fase que describe el proyecto en su totalidad, y un nmero de alta granularidad
o planes de iteracin que describe los pasos iterativos.

Este curso se centra principalmente en los aspectos importantes de un proceso de

desarrollo iterativo: La gestin de riesgos; La planificacin de un proyecto iterativo a
travs del ciclo de vida y para una iteracin en particular; Y el proceso de seguimiento
de un proyecto iterativo, la mtrica. Sin embargo, esta disciplina de RUP no pretende
cubrir todos los aspectos de la gestin de proyectos.

Por ejemplo, no cubre cuestiones tales como:

Gestin de personas: contratacin, formacin, etc.

Presupuesto general: definicin, asignacin, etc.
Gestin de contratos: con los proveedores, clientes, etc.
PRINCIPIOS Y LAS MEJORES PRCTICAS DE
LA METODOLOGA RUP
La metodologa RUP se basa en un conjunto de principios de desarrollo de software y
las mejores prcticas, por ejemplo:
1. Desarrollo de software iterativo
2. La gestin de requisitos
3. El uso de una arquitectura basada en componentes
4. Software de modelado visual
5. La verificacin de la calidad del software
6. Control de cambios en el software
DESARROLLO ITERATIVO
Teniendo en cuenta el tiempo necesario para desarrollar un software grande y
sofisticada, no se puede definir el problema y construir software en un solo paso. Los
requisitos cambiarn a menudo en el curso del desarrollo del proyecto , debido a las
restricciones de la arquitectura , las necesidades del usuario o para una mayor
comprensin del problema original.
Los cambios permiten que el proyecto para estar constantemente refinada, y la seal a
los elementos del proyecto de alto riesgo como las tareas de mayor prioridad.
Idealmente, al final de cada iteracin habr una versin ejecutable , lo que ayuda a
reducir el riesgo de configuracin de diseo, que permite una mayor respuesta de los
usuarios y ayudar al desarrollador a permanecer centrado.

RUP utiliza el desarrollo iterativo e incremental por las siguientes razones:

La integracin se hace paso a paso durante el proceso de desarrollo, cada paso se
limita a unos pocos elementos
La integracin es menos complejo, reduciendo el coste y aumentar la eficiencia
diseo de las piezas por separado y / o implementacin pueden ser fcilmente
identificados para su posterior reutilizacin
Requisitos cambios son registrados y pueden ser acomodados
Los riesgos se abordan en el comienzo del desarrollo y cada iteracin permite la
verificacin de riesgos ya percibidas y la identificacin de nuevos
Para la arquitectura de software se mejora a travs de un repetidor scrutinize
El uso de iteraciones, un proyecto tendr un plan general, as como varios planes de
iteracin. La participacin de las partes interesadas a menudo se alienta a cada entrega.
En esta forma, las entregas sirven como una manera de conseguir el compromiso de los
involucrados, mientras que tambin promueve una comparacin constante entre las
necesidades y el desarrollo de la organizacin a los conflictos que surjan.

LA GESTIN DE REQUISITOS
La gestin de requisitos en RUP se centra en encontrar el final el usuario necesita para
la identificacin y especificacin de lo que necesita y la identificacin de lo que debe
ser cambiado. Esto trae los siguientes beneficios:

La correccin de los requisitos genera la correccin del producto, por lo que se

satisfacen las necesidades de los usuarios.
se incluirn las caractersticas requeridas, lo que reduce el costo de los acontecimientos
posteriores.

RUP sugiere que la administracin de requerimientos tiene que seguir las actividades:

Anlisis de los problemas es que de acuerdo con el problema y crear medidas que
probarn su valor para la organizacin
La comprensin de las necesidades de sus grupos de inters es para compartir el
problema y los valores con los principales interesados y elevar lo que las
necesidades estn involucrados en el desarrollo de la idea
La definicin del problema es la definicin de las caractersticas de las
necesidades y el diseo de los casos de uso , actividades que mostrarn fcilmente
los requisitos de alto nivel y el esquema modelo de uso del sistema
Administrar el alcance del sistema es el alcance de los cambios que se comunica
con base en el progreso y los resultados seleccionados en el orden en que los
diagramas de flujo de los casos de uso son atacados
Refinar los ajustes del sistema de ofertas con los detalles de los diagramas de
flujo de casos de uso con las partes interesadas con el fin de crear una
especificacin de las aplicaciones de software que puede servir como un contrato
entre su grupo y el cliente y puede guiar las actividades de ensayo y proyecto
 Los requisitos de gestin del cambio es la forma de identificar las llegadas de los
cambios en las aplicaciones en un proyecto que ya ha comenzado
EL USO DE UNA ARQUITECTURA BASADA EN
COMPONENTES
La arquitectura basada en componentes crea un sistema que es fcilmente extensible,
intuitiva y fcil de entender y promueve la reutilizacin de software.

Un componente de frecuencia asociado con un conjunto de objetos en objetos

programacin orientada .
Arquitectura de software aumenta en importancia cuando un sistema se hace ms grande
y ms compleja. RUP se centra en la produccin de arquitectura bsica en los
primeros pocos iteraciones. Esta arquitectura se convierte en un prototipo en los ciclos
iniciales de desarrollo.
La arquitectura desarrollada en cada iteracin para convertirse en la arquitectura final
del sistema. RUP tambin propuso reglas de diseo y limitaciones para capturar
normas de arquitectura. Para el desarrollo iterativo es posible para identificar
gradualmente componentes que a continuacin se pueden desarrollar o comprado
reutilizada. Estos componentes se construyen a menudo en las infraestructuras
existentes, tales como CORBA y COM o Java EE , o PHP
SOFTWARE DE MODELADO VISUAL
Haciendo abstraccin de su programacin de su cdigo y representarla por medio de
bloques de construccin grficas constituye una forma eficaz de obtener una visin
general de una solucin. El uso de esta representacin, los recursos tcnicos pueden
determinar la mejor manera de poner en prctica un conjunto dado de interdependencias
lgicas .

Esto tambin crea una capa intermedia entre el proceso de negocio y el cdigo necesario
a travs de tecnologa de la informacin. Un modelo en este contexto es una pantalla y
al mismo tiempo una simplificacin de un diseo complejo. RUP especifica qu
modelos son necesarios y por qu.

El Lenguaje de Modelado Unificado (UML) se puede utilizar para el modelado de

casos de uso , diagramas de clases y otros objetos. RUP tambin analiza otras formas de
construir estos modelos.
SOFTWARE DE CONTROL DE CALIDAD
Aseguramiento de la calidad del software es el punto de fallo ms comn en los
proyectos de software , ya que esto es a menudo algo que no se haba pensado
anteriormente y, a veces es tratado por diferentes equipos. RUP ayuda en la
planificacin del control de calidad y se encarga de su construccin en todos los
procesos de participacin de todos los miembros del equipo.
No es una tarea est dirigida especficamente a la calidad ; RUP supone que cada
miembro del equipo es responsable de la calidad durante todo el proceso. El proceso se
centra en el descubrimiento de el nivel esperado de la calidad y proporciona pruebas en
los procesos para medir este nivel.
CONTROL DE CAMBIOS EN EL SOFTWARE
En todos los proyectos de software, los cambios son inevitables. RUP define mtodos
para controlar, seguir y supervisar estos cambios. RUP define tambin el trabajo seguro
de espacios (espacios de trabajo seguros en ingls), lo que garantiza que un sistema de
ingeniera de software no se ve afectada por los cambios en otros sistemas. Este
concepto es pegar bien con arquitecturas de software basados en componentizacin.