13 Metodología Híbrida RUP

Metodología Híbrida:
RUP
Autor: Mg. Mauricio Galvez Legua
(mgalvez@uni.edu.pe)
Autor: Mauricio Galvez Legua (mgalvez@uni.edu.pe) 1

Definición
• RUP (Rational Unified Process) o Proceso Unificado
Racional, es una metodología de proceso de
desarrollo de software desarrollado por IBM.
• Junto con UML (Unified Modeling Language),
constituyen en una metodología estándar muy
utilizado para el análisis, diseño, implementación y
documentación de sistemas orientados a objetos.

Definición
• RUP es un marco genérico que puede adaptarse a
una gran variedad de tipos de sistemas, áreas de
aplicación, tipos de organizaciones y diferentes
tamaños de proyectos.
• RUP no es un sistema con pasos específicamente
definidos.

Principios de desarrollo de RUP
• La filosofía RUP se desarrolló en base a 6 principios:
– Adaptar el proceso
– Equilibrar prioridades
– Demostrar valor iterativamente (ágil)
– Colaboración entre equipos (ágil)
– Enfocarse en la calidad (mejora continua,
enfocado en el “cliente”) (ágil)
– Elevar el nivel de abstracción (mejorar el
entendimiento del sistema por parte del usuario)

• Adaptar el proceso:
– El proceso debe adaptarse a las características propias del
proyecto u organización.
– Influyen en su diseño específico: el tamaño y tipo de
organización, así como las regulaciones existentes.
– Se debe tener en cuenta el alcance del proyecto.

• Equilibrar prioridades:
– Los requerimientos de los diversos usuarios pueden ser
diferentes, contradictorios o disputarse recursos limitados.
– Debe encontrarse un equilibrio que satisfaga los
requerimientos de todos. En base a este equilibrio se
podrán corregir desacuerdos que surjan en el futuro.

• Demostrar valor iterativamente:
– Los proyectos se entregan, aunque sea de un modo
interno, en etapas iteradas.
– En cada iteración se analiza la opinión del cliente, la
estabilidad y calidad del producto, y se ajusta la dirección
del proyecto así como también los riesgos involucrados.

• Colaboración entre equipos:
– El desarrollo de software no lo hace una única persona
sino un equipo.
– Debe haber una comunicación fluida para coordinar
requisitos, desarrollo, evaluaciones, planes, resultados,
etc.

• Enfocarse en la calidad:
– El control de calidad no debe realizarse al final de cada
iteración, sino en todos los aspectos de la producción del
software.
– El aseguramiento de la calidad forma parte del proceso de
desarrollo y no de un grupo independiente. Es una
estrategia de desarrollo de software.

• Elevar el nivel de abstracción:
– Este principio dominante motiva el uso de conceptos
reutilizables tales como patrones de diseño del software,
lenguajes 4GL o esquemas (frameworks), etc. Estos se
pueden acompañar por las representaciones visuales de la
arquitectura, por ejemplo con UML.

Características del Proceso RUP
• Presenta las siguientes características:
– Dirigido por casos de uso
– Centrado en la arquitectura
– Iterativo e Incremental
– Desarrollo basado en componentes
– Utilización de UML
– Proceso integrado

Características del Proceso RUP: Dirigido
por casos de uso
• Significa que los requerimientos están
enfocados a dar valor al cliente y que el
proceso debe garantizar que todo el
desarrollo, pruebas, planificación,
documentación, entre otros, está fuertemente
orientado a cubrir estas expectativas del
cliente y asegurar que los requerimientos de
valor se ponen en producción.

Casos de Uso
• Los casos de uso son una técnica de captura

de requisitos que fuerza a pensar en términos
de importancia para el usuario y no sólo en
términos de funciones.
• Un caso de uso es un fragmento de
funcionalidad del sistema que proporciona un
resultado de valor para el usuario.

Casos de Uso
• Los casos de uso
modelan los
requerimientos
funcionales del sistema.
• Un caso de uso es la
descripción de una
acción o actividad.
• Los casos de uso guían el
proceso de desarrollo
del software: diseño,
implementación y
pruebas.
Casos de Uso
• Un diagrama de caso de uso es una descripción de
las actividades que deberá realizar alguien o algo
para llevar a cabo algún proceso.
• Los personajes o entidades que participarán en un
diagrama de caso de uso se denominan actores. Se le
llama actor a toda entidad externa al sistema que
guarda una relación con este y que le demanda una
funcionalidad.

Casos de Uso
• Los diagramas de casos de uso sirven para especificar
la comunicación y el comportamiento de un sistema
mediante su interacción con los usuarios y/u otros
sistemas.
Capturar, definir y validar
los casos de uso
Implementar los casos de

uso
Verificar que se satisfacen

los casos de uso

Características del Proceso RUP: Centrado
en la arquitectura
• Significa que hay un énfasis a diseñar una
arquitectura de calidad, y es la arquitectura
también la que guía la forma cómo se debe
planear y hacer el desarrollo.

en la arquitectura
• La arquitectura de un software se define
como:
Conjunto de decisiones significativas acerca de
la organización de un sistema software, la
selección de los elementos estructurales a partir
de los cuales se compone el sistema, las
interfaces entre ellos, su comportamiento, sus
colaboraciones, y su composición.

en la arquitectura
• La arquitectura de un sistema software se
describe mediante diferentes vistas del
sistema en construcción.
– El concepto de arquitectura de software incluye
los aspectos estáticos y dinámicos más
significativos del sistema.
– La arquitectura del software es una vista del
diseño completo con las características más
importantes resaltadas, dejando los detalles de
lado.
Características del Proceso RUP: Iterativo
e incremental
• Significa que el proyecto se divide en varios ciclos
de vida, denominadas iteraciones, que deben dar
como resultado el sistema de software.
• Se establecen criterios de evaluación cada vez
que se planifica una iteración.

Características del Proceso RUP: Iterativo
e incremental
• Por cada una de las iteraciones se va agregando
nuevos requerimientos y sobre todo valor para el
cliente; por este motivo es incremental.

Características del Proceso RUP:
Desarrollo basado en componentes
• La creación de sistemas complejos en software
requiere dividir el sistema en componentes con
interfaces bien definidas, que posteriormente serán
ensamblados para obtener el sistema completo.
– El software está formado por componentes de software
interconectados a través de interfaces.
• Esta característica en el proceso de desarrollo,
permite que el sistema se vaya creando a medida
que se obtienen o se desarrollan sus componentes.

Características del Proceso RUP:
Utilización del UML
• UML es un lenguaje para visualizar, especificar,
construir y documentar software.
– Utilizar herramientas de modelado visual facilita la gestión
de dichos modelos, permitiendo ocultar o exponer detalles
cuando sea necesario.
– El modelado visual también ayuda a mantener la
consistencia.
• En resumen, el modelado visual ayuda a mejorar la
capacidad del equipo para gestionar la complejidad
del software.

Características del Proceso RUP: Proceso
integrado
• Proceso integrado

Ciclo de vida de RUP
• RUP repite a lo largo de una serie de ciclos que
constituyen la vida de un sistema. Cada ciclo
constituye una versión del sistema.
• El ciclo de vida RUP es una implementación del
desarrollo en espiral.

• El ciclo de vida de RUP se organiza en cuatro fases
secuenciales (modelo cascada):
– Inicio o concepción (Inception): Objetivos y alcance del
proyecto.
– Elaboración (Elaboration): elaborar la arquitectura del
sistema.
– Construcción (Construction): Desarrollar las
funcionalidades del sistema.
– Transición (Transition): Depurar y entregar al usuario.
Inception Elaboration Construction Transition

Ciclo de vida de RUP: Inicio o concepción
• Se define el alcance del proyecto. Se desarrolla una
descripción del producto final (requerimientos del
sistema) mediante casos de uso, y se presenta el
análisis del negocio. Esta fase responde las siguientes
preguntas:
– ¿Cuáles son las principales funciones del sistema para los
usuarios más importantes?
– ¿Cómo sería la arquitectura del sistema?
– ¿Cuál es el plan del proyecto y cuánto costará desarrollar
el producto?

Ciclo de vida de RUP: Inicio o concepción
• En esta fase se identifican y priorizan los riesgos más
importantes.
• Las iteraciones hacen mayor énfasis en actividades
de modelado del negocio y de requisitos.

Ciclo de vida de RUP: Elaboración
• Planificar el proyecto y elaborar la arquitectura base.
Se especifican en detalle la mayoría de los casos de
uso del software y se diseña la arquitectura.
• Las iteraciones en la fase de elaboración:
– Establecen una firme comprensión del problema a
solucionar.
– Establece la fundamentación arquitectural para el
software.
– Establece un plan detallado para las siguientes iteraciones.
– “Elimina” los mayores riesgos.

Ciclo de vida de RUP: Elaboración
• Las iteraciones se orientan al desarrollo de la línea
base de la arquitectura, abarcan los flujos de trabajo
de requisitos, modelo de negocios, análisis, diseño y
una parte de implementación orientado a la línea
base de la arquitectura.

Ciclo de vida de RUP: Construcción
• Construir el sistema. Durante la fase de construcción
se desarrolla el software. La línea base de la
arquitectura crece hasta convertirse en el sistema
completo.

Ciclo de vida de RUP: Construcción
• Para cada iteración se
seleccionan algunos casos de uso,
se refinan su análisis y diseño y se
procede a su implementación y
pruebas.
• Se realizan iteraciones hasta que
se termine la implementación de
la nueva versión del software.

Ciclo de vida de RUP: Transición
• Transición a los usuarios. Cubre el período durante el
cual el software se convierte en la versión beta. Las
iteraciones en esta fase continúan agregando
características al software. Sin embargo las
características se agregan a un sistema que el usuario
se encuentra utilizando activamente.
– Se pretende garantizar que se tiene un producto
preparado para su entrega a la comunidad de usuarios.

• La duración y esfuerzo dedicado en cada fase es
variable dependiendo de las características del
proyecto. En promedio se tiene:

Workflows o disciplinas
• Cada fase en RUP se completa con la realización
de varias iteraciones en las que se desarrollan
una serie de actividades, que el modelo RUP se
denominan workflows o disciplinas.

• Los workflows o disciplinas, las podemos dividir
en dos grandes grupos:
– Workflows primarios
– Workflows de apoyo

Workflows primarios
• Workflows primarios:
– Business Modeling (Modelado de negocio): Describe los
procesos de negocio, identificando quiénes participan y las
actividades que requieren automatización.
– Requirements (Requisitos): Define qué es lo que el
sistema debe hacer, para lo cual se identifican las
funcionalidades requeridas y las restricciones que se
imponen.
– Analysis & Design (Análisis y diseño): Describe cómo el
sistema será realizado a partir de la funcionalidad
prevista y las restricciones impuestas, por lo que
indica con precisión lo que se debe programar.

Workflows primarios
– Implementation (Implementación): Define cómo
se organizan las clases y objetos en componentes,
cuáles nodos se utilizarán y la ubicación en ellos
de los componentes y la estructura de capas de la
aplicación.
– Test (Pruebas): Asegurarse que el funcionamiento
del sistema sea el correcto y que todo lo solicitado
está presente.
– Deployment (Despliegue): Realiza actividades
(empaque, instalación, asistencia a usuarios, etc.)
para entregar el software a los usuarios finales.

Workflows primarios
Independientemente
de la fase

Comparativa
• Comparativa entre el modelo cascada y el modelo
iterativo e incremental y modelo RUP:

Workflows de apoyo
• Workflows de apoyo:
– Configuration & Change Management (Gestión de
configuración y cambios): Describe cómo controlar los
elementos producidos por todos los integrantes del equipo
de proyecto en cuanto a la utilización/actualización
concurrente de elementos, control de versiones, etc.
– Proyect Management (Gestión del proyecto): Involucra
actividades con las que se busca producir un producto que
satisfaga las necesidades de los clientes.
– Enviroment (Entorno): Contiene actividades que describen
los procesos y herramientas que soportarán el equipo de
trabajo del proyecto, así como el procedimiento para
implementar el proceso en una organización.


• El agrupamiento de disciplinas es principalmente una
ayuda para comprender el proyecto desde la visión
tradicional en cascada.

• Las disciplinas las podemos clasificar en dos partes:
– Desarrollo
– Soporte

• Disciplinas de Desarrollo:
– Requerimientos: Se trasladan las necesidades del negocio
a un sistema automatizado.
– Análisis y Diseño: Los requerimientos se trasladan a una
arquitectura software.
– Codificación: Se crea el software adaptándolo a las
necesidades.
– Pruebas: Se comprueba que el software actúa de forma
adecuada.

• Disciplinas de Soporte:
– Administración del Proyecto: Proveer un marco de trabajo
para administrar los proyectos de software.
• Proveer guías prácticas para la planeación, soporte,
ejecución y monitoreo de proyectos.
• Proveer un marco de trabajo para la administración del
riesgo.

• Disciplinas de Soporte:
– Gestión, Configuración y Cambio: Consiste en controlar los
cambios y mantener la integridad de los productos que
incluye el proyecto.
• Identificar los elementos configurables.
• Restringir los cambios en los elementos configurables.
• Auditar los cambios hechos a estos elementos.
• Definir y mantener las configuraciones de estos
elementos.

• Cada disciplina está asociada con un conjunto de
modelos que se desarrollan.
Disciplina Modelos
Requisitos Modelo de Casos de Uso
Análisis Modelo de Análisis
Diseño Modelo de Diseño – Modelo de Despliegue
Implementación Modelo de Implementación
Prueba Modelo de Prueba

Artefactos
• Los artefactos son unidades de información creadas,
producidas, cambiadas o utilizadas en el proceso de
desarrollo del software.
• Un artefacto puede ser:
– Un documento, como un caso de negocio o un documento
de la arquitectura del software.
– Un modelo, como un modelo de caso de uso. Los modelos
están plasmados en artefactos (documentos).

Artefactos
• Grado de finalización de los artefactos por cada fase:

Hitos
• Cada fase finaliza con un hito. Cada hito se
determina por la disponibilidad de un conjunto de
modelos, los cuales están compuestos de
documentos (artefactos) que han sido desarrollados
hasta alcanzar un estado definitivo.

Hitos
• Los hitos tienen muchos objetivos, es por ello que los
jefes de proyecto deben tomar ciertas decisiones
antes de que el trabajo continúe con la siguiente
fase.
• Los hitos permiten controlar la dirección y progreso
del trabajo.
• Al final se obtiene un conjunto de datos a partir del
seguimiento del tiempo y esfuerzo consumidos en
cada fase. Estos datos son útiles para las
estimaciones en futuros proyectos.

Roles
• Un rol define el comportamiento y responsabilidades
de un individuo, o de un grupo de individuos
trabajando juntos como un equipo.
• Los roles que se definen en RUP indican las tareas
que tiene que hacer cada uno de los miembros del
proyecto y el objetivo que debe de conseguir.

Roles
• Una persona puede desempeñar diversos roles, así
como un mismo rol puede ser representado por
varias personas.
• Las responsabilidades de un rol son tanto el llevar a
cabo un conjunto de actividades como el ser el
dueño de un conjunto de artefactos.

Roles por cada disciplina
Disciplina Roles generales Roles específicos
Modelado de Analista de procesos de Diseñador de negocio: Detallar un
negocio negocio: Descubrir todos los conjunto de los casos de uso de
casos de uso de negocio. negocio.
Requisitos Analista de sistemas: Descubrir Especificador de casos de uso:
todos los casos de uso. Detallar un conjunto de los casos de
uso.
Análisis y diseño Arquitectos de Software: Toma Diseñadores: Detallan el análisis y
decisiones tecnológicas de la diseño para un conjunto de casos de
solución a nivel global. uso.
Implementación Integrador: Es el propietario Desarrollador o programador:
del plan de construcción que Implementa un conjunto de clases o
muestra cómo se integrarán un conjunto de operaciones de una
cada una de las clases con las clase.
otras.

Pruebas Gestor de las pruebas (tester): Diseñador de pruebas:
Asegura que las pruebas han sido Implementa las pruebas
realizadas correctamente. automáticas de la iteración.
Analista de pruebas: Selecciona qué Probador: Ejecuta un test
se va a probar según lo estimado. específico.
Diseñador de pruebas: Decide qué
pruebas deberían ser automáticas o
manuales, y crea las automáticas.
Despliegue o Gestor de la implantación: Supervisa Asegurar la correcta
implantación la implantación de todas las unidades. implantación del sistema.

Gestión del proyecto Gestor del proyecto: Crea los Gestor de proyectos: Planifica,
casos de negocio y un plan monitoriza y gestiona los riesgos para
general, y toma decisiones una sola iteración.
críticas al respecto de que
cosas hacer y cuales no hacer.
Entorno Ingeniero de procesos: Es el Especialista en herramientas: Crea
responsable de los procesos manuales de uso de herramientas
del proyecto. específicas.
Configuración y Gestor de la configuración: Gestor de la configuración: Crea una
mantenimiento Establece las políticas y planes. unidad de despliegue o implantación,
Gestor de control de cambios: reportes del estado de la
Establece un proceso de configuración, auditorias, entre otros.
control de los cambios. Gestor de control de cambios: Revisa
y gestiona las peticiones de cambios.

Roles, actividades, artefactos y flujos de
trabajo
• Un proceso de desarrollo de software define quién
hace qué, cómo y cuándo:
– Los roles, responden a la pregunta ¿Quién?
– Los productos de trabajo, responde a la pregunta ¿Qué se
va a realizar?
– Las actividades, responden a la pregunta ¿Cómo?
– Los flujos de trabajo de las disciplinas, responde a la
pregunta ¿Cuándo?

trabajo

trabajo
• RUP se define por una serie de características
denominadas buenas prácticas y que vienen
definidas en “RUP, Best Software Practices
Development”:
– Gestión de los riesgos: Decidir qué riesgos tener en cuenta
en cada iteración. Actualizar la lista de riesgos y hacerla
visible. Utilizar herramientas de gestión de riesgos y
trazabilidad.
– Desarrollos iterativos: Entregas iterativas. Replanificación
basada en el feedback. Planificar las iteraciones en función
de los riesgos.

trabajo
– Usar componentes basados en la arquitectura: Aplicar
componentes y principio de diseño de servicios. Modelar
componentes, servicios e interfaces. Crear especificaciones
detalladas de los componentes y los servicios.
– Gestión de los requisitos: Identificar escenarios. Capturar
casos de uso, y relacionarlos con sus respectivos
escenarios. Trocear casos de uso en requisitos gestionados
independientemente. Utiliza UML para la realización de un
modelo visual del software.

trabajo
– Modelado del software visual: La calidad debe ser revisada
respecto a los requisitos basándose en la fiabilidad,
funcionalidad, rendimiento de la aplicación y del sistema.
Planificación, diseño, implementación, ejecución y
evaluación de las pruebas.
– Verificar la calidad del software: Controlar y hacer el
seguimiento de los cambios. Utilización de entornos de
trabajos independientes para aislar los diferentes cambios.
– Control de los cambios del software: La metodología RUP
quizás sea la más adecuada para proyectos grandes ya que
necesita disponer de un equipo de trabajo que sea capaz
de manejar procesos en varias etapas.

Fin !!!
Autor: Mg. Mauricio Galvez Legua

(mgalvez@uni.edu.pe)

13 Metodología Híbrida RUP

Cargado por

Información del documento

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

13 Metodología Híbrida RUP

Cargado por

Copyright:

Formatos disponibles

Metodología Híbrida:

Autor: Mauricio Galvez Legua (mgalvez@uni.edu.pe) 1

Autor: Mauricio Galvez Legua (mgalvez@uni.edu.pe) 2

Autor: Mauricio Galvez Legua (mgalvez@uni.edu.pe) 3

Autor: Mauricio Galvez Legua (mgalvez@uni.edu.pe) 4

Autor: Mauricio Galvez Legua (mgalvez@uni.edu.pe) 5

Autor: Mauricio Galvez Legua (mgalvez@uni.edu.pe) 6

Autor: Mauricio Galvez Legua (mgalvez@uni.edu.pe) 7

Autor: Mauricio Galvez Legua (mgalvez@uni.edu.pe) 8

Autor: Mauricio Galvez Legua (mgalvez@uni.edu.pe) 9

Autor: Mauricio Galvez Legua (mgalvez@uni.edu.pe) 10

Autor: Mauricio Galvez Legua (mgalvez@uni.edu.pe) 11

Autor: Mauricio Galvez Legua (mgalvez@uni.edu.pe) 12

• Los casos de uso son una técnica de captura

Autor: Mauricio Galvez Legua (mgalvez@uni.edu.pe) 13

Autor: Mauricio Galvez Legua (mgalvez@uni.edu.pe) 15

Implementar los casos de

Verificar que se satisfacen

Autor: Mauricio Galvez Legua (mgalvez@uni.edu.pe) 16

Autor: Mauricio Galvez Legua (mgalvez@uni.edu.pe) 17

Autor: Mauricio Galvez Legua (mgalvez@uni.edu.pe) 18

Autor: Mauricio Galvez Legua (mgalvez@uni.edu.pe) 20

Autor: Mauricio Galvez Legua (mgalvez@uni.edu.pe) 21

Autor: Mauricio Galvez Legua (mgalvez@uni.edu.pe) 22

Autor: Mauricio Galvez Legua (mgalvez@uni.edu.pe) 23

Autor: Mauricio Galvez Legua (mgalvez@uni.edu.pe) 24

Autor: Mauricio Galvez Legua (mgalvez@uni.edu.pe) 25

Inception Elaboration Construction Transition

Autor: Mauricio Galvez Legua (mgalvez@uni.edu.pe) 26

Autor: Mauricio Galvez Legua (mgalvez@uni.edu.pe) 27

Autor: Mauricio Galvez Legua (mgalvez@uni.edu.pe) 28

Autor: Mauricio Galvez Legua (mgalvez@uni.edu.pe) 29

Autor: Mauricio Galvez Legua (mgalvez@uni.edu.pe) 30

Autor: Mauricio Galvez Legua (mgalvez@uni.edu.pe) 31

Autor: Mauricio Galvez Legua (mgalvez@uni.edu.pe) 32

Autor: Mauricio Galvez Legua (mgalvez@uni.edu.pe) 33

Autor: Mauricio Galvez Legua (mgalvez@uni.edu.pe) 34

Autor: Mauricio Galvez Legua (mgalvez@uni.edu.pe) 35

Autor: Mauricio Galvez Legua (mgalvez@uni.edu.pe) 36

Autor: Mauricio Galvez Legua (mgalvez@uni.edu.pe) 37

Autor: Mauricio Galvez Legua (mgalvez@uni.edu.pe) 38

Autor: Mauricio Galvez Legua (mgalvez@uni.edu.pe) 39

Autor: Mauricio Galvez Legua (mgalvez@uni.edu.pe) 40

Autor: Mauricio Galvez Legua (mgalvez@uni.edu.pe) 41

Autor: Mauricio Galvez Legua (mgalvez@uni.edu.pe) 42

Autor: Mauricio Galvez Legua (mgalvez@uni.edu.pe) 43

Autor: Mauricio Galvez Legua (mgalvez@uni.edu.pe) 44

Autor: Mauricio Galvez Legua (mgalvez@uni.edu.pe) 45

Autor: Mauricio Galvez Legua (mgalvez@uni.edu.pe) 46

Autor: Mauricio Galvez Legua (mgalvez@uni.edu.pe) 47

Autor: Mauricio Galvez Legua (mgalvez@uni.edu.pe) 48

Autor: Mauricio Galvez Legua (mgalvez@uni.edu.pe) 49

Autor: Mauricio Galvez Legua (mgalvez@uni.edu.pe) 50

Autor: Mauricio Galvez Legua (mgalvez@uni.edu.pe) 51

Autor: Mauricio Galvez Legua (mgalvez@uni.edu.pe) 52

Autor: Mauricio Galvez Legua (mgalvez@uni.edu.pe) 53

Autor: Mauricio Galvez Legua (mgalvez@uni.edu.pe) 54

Autor: Mauricio Galvez Legua (mgalvez@uni.edu.pe) 55

Autor: Mauricio Galvez Legua (mgalvez@uni.edu.pe) 56

Autor: Mauricio Galvez Legua (mgalvez@uni.edu.pe) 57

Autor: Mauricio Galvez Legua (mgalvez@uni.edu.pe) 58

Autor: Mauricio Galvez Legua (mgalvez@uni.edu.pe) 59

Autor: Mauricio Galvez Legua (mgalvez@uni.edu.pe) 60

Autor: Mauricio Galvez Legua (mgalvez@uni.edu.pe) 61