Metodología RUP

Ciclo de vida RUP
El Proceso Unificado Racional

(Rational Unified Process en inglés,
habitualmente resumido como RUP) 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.
El RUP no es un sistema con
pasos firmemente
establecidos, sino un conjunto
de metodologías adaptables al
contexto y necesidades de
cada organización.
• Inicio: Se hace un plan de fases, se identifican los principales casos de uso y se
identifican los riesgos. Se define el alcance del proyecto
• Elaboración: se hace un plan de proyecto, se completan los casos de uso y se

eliminan los riesgos
• Construcción: se concentra en la elaboración de un producto totalmente

operativo y eficiente y el manual de usuario
• Transición: se Instala el producto en el cliente y se entrena a los usuarios.

Como consecuencia de esto suelen surgir nuevos requisitos a ser analizados.
FASE DE INICIO
Durante la fase de inicio las iteraciones hacen ponen mayor

énfasis en actividades modelado del negocio y de requisitos.
Modelado del negocio
En esta fase el equipo se familiarizará más al funcionamiento

de la empresa, sobre conocer sus procesos.
• Entender la estructura y la dinámica de la organización para
la cual el sistema va ser desarrollado .
• Entender el problema actual en la organización objetivo e
identificar potenciales mejoras.
• Asegurar que clientes, usuarios finales y desarrolladores
tengan un entendimiento común de la organización objetivo.
Requisitos
En esta línea los requisitos son el contrato que se debe cumplir,

de modo que los usuarios finales tienen que comprender y
aceptar los requisitos que especifiquemos.
• Establecer y mantener un acuerdo entre clientes y otros

stakeholders sobre lo que el sistema podría hacer.
• Proveer a los desarrolladores un mejor entendimiento de los

requisitos del sistema.
• Definir el ámbito del sistema.
• Proveer una base para estimar costos y tiempo de desarrollo del

sistema.
• Definir una interfaz de usuarios para el sistema, enfocada a las

necesidades y metas del usuario.
Artefactos para Inicio
 Documento Visión
 Especificación de Requerimientos
FASE DE ELABORACIÓN
En la fase de elaboración, las iteraciones se orientan al
desarrollo de la baseline de la arquitectura, abarcan más
los flujos de trabajo de requerimientos, modelo de
negocios (refinamiento), análisis, diseño y una parte de
implementación orientado a la baseline de la arquitectura.
Análisis y Diseño
En esta actividad se especifican los requerimientos y se

describen sobre como se van a implementar en el
sistemas
• Transformar los requisitos al diseño del sistema.
• Desarrollar una arquitectura para el sistema.
• Adaptar el diseño para que sea consistente con el

entorno de implementación
Artefactos para Elaboración
 Diagramas de casos de uso
FASE DE CONSTRUCCIÓN
Implementación
Se implementan las clases y objetos en ficheros fuente, binarios,
ejecutables y demás. El resultado final es un sistema ejecutable.
• Planificar qué subsistemas deben ser implementados y en que orden

deben ser integrados, formando el Plan de Integración.
• Cada implementador decide en que orden implementa los elementos

del subsistema.
• Si encuentra errores de diseño, los notifica.
• Se integra el sistema siguiendo el plan.

Pruebas
Este flujo de trabajo es el encargado de evaluar la calidad del

producto que estamos desarrollando, pero no para aceptar o
rechazar el producto al final del proceso de desarrollo, sino que
debe ir integrado en todo el ciclo de vida.
• Encontrar y documentar defectos en la calidad del software.
• Generalmente asesora sobre la calidad del software percibida.
• Provee la validación de los supuestos realizados en el diseño y

especificación de requisitos por medio de demostraciones
concretas.
• Verificar las funciones del producto de software según lo

diseñado.
• Verificar que los requisitos tengan su apropiada implementación.

Artefactos para Construcción
 Documento Arquitectura que trabaja con las siguientes
vistas:
 Vista Lógica
 Diagrama de clases
 Modelo E-R (si el sistema así lo requieres)
 Vista de Implementación
 Diagrama de secuencia
 Diagrama de estados
 Diagrama de colaboración
 Vista Conceptual
 Modelo de dominio
 Vista Física
 Mapa de comportamiento a nivel de hardware
FASE DE TRANSICION
Despliegue
Esta actividad tiene como objetivo producir con éxito

distribuciones del producto y distribuirlo a los usuarios. Las
actividades implicadas incluyen:
• Probar el producto en su entorno de ejecución final.
• Empaquetar el software para su distribución.
• Distribuir el software. • Instalar el software.
• Proveer asistencia y ayuda a los usuarios.
• Formar a los usuarios y al cuerpo de ventas.
• Migrar el software existente o convertir bases de datos.

DURANTE TODO EL PROYECTO
Gestión del proyecto
Se vigila el cumplimiento de los objetivos, gestión de riesgos y

restricciones para desarrollar un producto que sea acorde a los
requisitos de los clientes y los usuarios.
• Proveer un marco de trabajo para la gestión de proyectos de
software intensivos.
• Proveer guías prácticas realizar planeación, contratar personal,

ejecutar y monitorear el proyecto.
• Proveer un marco de trabajo para gestionar riesgos.

Configuración y control de cambios
El control de cambios permite mantener la integridad de todos los artefactos

que se crean en el proceso, así como de mantener información del proceso
evolutivo que han seguido.
Entorno
La finalidad de esta actividad es dar soporte al proyecto con las adecuadas
herramientas, procesos y métodos. Brinda una especificación de las herramientas
que se van a necesitar en cada momento, así como definir la instancia concreta del
proceso que se va a seguir.
En concreto las responsabilidades de este flujo de trabajo incluyen:
• Selección y adquisición de herramientas
• Establecer y configurar las herramientas para que se ajusten a la organización.
• Configuración del proceso.
• Mejora del proceso.
• Servicios técnicos.
La ventaja principal de RUP es que se basa todo
en las mejores prácticas que se han intentado y
se han probado en el campo. (en comparación
con XP que se basa en las prácticas inestables
que utilizaron juntas se evita que se derribe).
Mitigación temprana de posibles riesgos
altos
progreso visible en las primeras etapas
Temprana retroalimentación que se ajuste
a las necesidades reales
Gestión de la complejidad
Conocimiento adquirido en una iteración
puede aplicarse de iteración a iteración
Por el grado de complejidad
puede no resultar muy adecuado.
El RUP es generalmente mal
aplicado en el estilo cascada.
Requiere conocimientos del
proceso y de UML.
CONCLUSIONES
La metodología RUP es más adaptable para proyectos de
largo plazo.
Podemos incluir además lo más importante antes de

elegir la metodología que vamos a usar para la
implementación del Software.
BIBLIOGRAFIA
https://procesosdesoftware.wikispaces.com/METODOLOGIA+RUP
http://www.oocities.org/es/monsalvelaura/fase2/analisis.html
http://users.dsic.upv.es/asignaturas/facultad/lsi/ejemplorup/index.html
http://www.scribd.com/doc/297224/RUP
http://1251_bestpractices_TP026B
http://www.usmp.edu.pe/publicaciones/boletin/fia/info49/articulos/RUP%20vs.%20XP.pdf

Metodología RUP

Cargado por

Copyright:

Formatos disponibles

Metodología RUP

Cargado por

Información del documento

Descripción original:

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Metodología RUP

Cargado por

Copyright:

Formatos disponibles

Ciclo de vida RUP

El Proceso Unificado Racional

• Elaboración: se hace un plan de proyecto, se completan los casos de uso y se

• Construcción: se concentra en la elaboración de un producto totalmente

• Transición: se Instala el producto en el cliente y se entrena a los usuarios.

Durante la fase de inicio las iteraciones hacen ponen mayor

Modelado del negocio

En esta fase el equipo se familiarizará más al funcionamiento

En esta línea los requisitos son el contrato que se debe cumplir,

• Establecer y mantener un acuerdo entre clientes y otros

• Proveer a los desarrolladores un mejor entendimiento de los

• Definir el ámbito del sistema.

• Proveer una base para estimar costos y tiempo de desarrollo del

• Definir una interfaz de usuarios para el sistema, enfocada a las

En esta actividad se especifican los requerimientos y se

• Desarrollar una arquitectura para el sistema.

• Adaptar el diseño para que sea consistente con el

• Planificar qué subsistemas deben ser implementados y en que orden

• Cada implementador decide en que orden implementa los elementos

• Si encuentra errores de diseño, los notifica.

• Se integra el sistema siguiendo el plan.

Este flujo de trabajo es el encargado de evaluar la calidad del

• Encontrar y documentar defectos en la calidad del software.

• Generalmente asesora sobre la calidad del software percibida.

• Provee la validación de los supuestos realizados en el diseño y

• Verificar las funciones del producto de software según lo

• Verificar que los requisitos tengan su apropiada implementación.

Esta actividad tiene como objetivo producir con éxito

• Empaquetar el software para su distribución.

• Distribuir el software. • Instalar el software.

• Proveer asistencia y ayuda a los usuarios.

• Formar a los usuarios y al cuerpo de ventas.

• Migrar el software existente o convertir bases de datos.

Gestión del proyecto

Se vigila el cumplimiento de los objetivos, gestión de riesgos y

• Proveer guías prácticas realizar planeación, contratar personal,

• Proveer un marco de trabajo para gestionar riesgos.

El control de cambios permite mantener la integridad de todos los artefactos

• Selección y adquisición de herramientas

• Establecer y configurar las herramientas para que se ajusten a la organización.

• Configuración del proceso.

• Mejora del proceso.

Podemos incluir además lo más importante antes de

También podría gustarte