República bolivariana de Venezuela

Ministerio del poder popular para la educación universitaria

Universidad politécnica territorial del estado Aragua
Federico Brito Figueroa
La victoria edo Aragua

Metodología RUP Y DUM

Elaborado por:
Nicolás Ramos. CI: 26.613.034
Luis López CI: 25.904.338
Arturo Yaya CI: 27.521.620
 Introducción
Este trabajo se hace con la finalidad de dar a conocer más saber las mete todo
logias dup y rum, sobre sus características enfocadas directamente hacia su
directrices , su calidad ,requisitos, elaboración etc. Los enfoque hacia los
cuales están dirigidas cada una de estas
 METODOLOGIA RUP

La metodología RUP (Rational Unified Process o Proceso Unificado Racional): es un

proceso propietario de la ingeniería de software creado por Rational Software, adquirida
por IBM, ganando un nuevo nombre IRUP que ahora es una abreviatura de Rational
Unified Process y lo que es una marca en el área de software, proporcionando técnicas que
deben seguir los miembros del equipo de desarrollo de software con el fin de aumentar su
productividad en el proceso de desarrollo.
La metodología RUP utiliza el enfoque de la orientación a objetos en su diseño y está
diseñado y documentado el uso de la notación UML (Unified Modeling Language) para
ilustrar los procesos en acción, utilizando técnicas y prácticas probadas comercialmente.
 CARACTERISTICAS DE LA METODOLOGIA RUP

DIRECTRICES DE LA METODOLOGÍA RUP: Define las siguientes líneas maestras y

los esqueletos (plantillas) para los miembros del personal de un ciclo de producción, parte
del cliente y una evaluación de los avances del proyecto por su gestión. Ayuda a los
desarrolladores para mantener la concentración en el proyecto.
REQUISITOS DE GESTIÓN: La documentación apropiada es esencial para cualquier
proyecto de gran envergadura, en cuenta que RUP describe cómo documentar la
funcionalidad, las limitaciones del sistema, restricciones de diseño y requisitos de negocio.
EL USO DE UNA ARQUITECTURA BASADA EN COMPONENTES: La
arquitectura basada en componentes crea un sistema que puede ser fácilmente extensible,
promoviendo la reutilización y el software una comprensión intuitiva. Un componente se
refiere normalmente a un objeto en la programación orientada a objetos.
EL USO DE MODELOS VISUALES DE SOFTWARE EN LA METODOLOGÍA
RUP: Al abstraer la programación de su código y representarla utilizando bloques de
construcción gráficas, RUP puede de manera eficaz conseguir una visión general de una
solución.
El uso de modelos visuales también puede permitir que los individuos con menos perfil
técnico (como clientes) tienen una mejor comprensión de un problema dado, y así estar más
involucrados en el proyecto en su conjunto.
COMPROBAR LA CALIDAD DEL SOFTWARE: No asegura la calidad del software
es el fallo más común en todos los proyectos de sistemas informáticos. Por lo general, uno
piensa en la calidad del software después de la finalización de los proyectos, o la calidad es
la responsabilidad de un equipo de desarrollo de equipo diferente y tiene como objetivo
ayudar en el control de la planificación de la calidad, comprobando que en la construcción
de todo el proceso y la participación de todos los miembros del equipo de desarrollo.
SOFTWARE DE GESTIÓN Y DE CAMBIO DE CONTROL: En todos los proyectos
de software de la existencia del cambio es inevitable. RUP define métodos para controlar y
vigilar los cambios, como un pequeño cambio puede afectar a las aplicaciones de maneras
totalmente impredecibles, el control de cambio es esencial para el éxito de un proyecto.
RUP también 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 METODOLOGÍA RUP: Hasta ahora estas líneas guía son generales, para
ser adherido a pasar por la vida de un ciclo de proyecto. Las fases indican el énfasis que se
da en el proyecto en un instante dado. Para capturar la dimensión temporal de un proyecto,
RUP divide el proyecto en cuatro fases diferentes:
 Iniciación o Diseño: énfasis en el alcance del sistema.
 Preparación: énfasis en la arquitectura.
 Construcción: énfasis en el desarrollo.
 Transición: énfasis en la aplicación.
FASE DE DISEÑO: La fase de diseño o de iniciación contiene los flujos de trabajo
necesarios para el acuerdo de las partes interesadas – interesados – con los objetivos, la
arquitectura y la planificación del proyecto. Si estos actores tienen un buen conocimiento,
no será necesario analizar, de lo contrario, se requiere un análisis más 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 sólo las que sean necesarias para dar forma a
la opinión.
FASE DE ELABORACIÓN: La preparación será para el diseño del sistema, como
complemento de la encuesta y / o documentación de casos de uso, frente a la arquitectura
del sistema, revisar el modelo de negocio para el proyecto e iniciar la versión del manual
del usuario. Uno debe aceptar: Descripción del producto (aumento + integración) es
¿estable? El plan del proyecto es ¿fiable?; Los costos son ¿elegibles?.
FASE DE CONSTRUCCIÓN: En la fase de construcción, el desarrollo físico del
software se inicia, códigos de producción, pruebas alfa, pruebas beta se llevaron a cabo al
inicio de la fase de transición. Se debe aceptar las pruebas, procesos estables y de prueba, y
el código del sistema son «línea de base».
FASE DE TRANSICIÓN: 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 satisfacción del
cliente. Esta etapa también se lleva a cabo la formación de los usuarios.
LA DISCIPLINA MODELADO DE NEGOCIO: Las organizaciones dependen cada vez
más de los sistemas de TI, por lo que es imperativo que los ingenieros de sistemas de
información saben cómo se integran las aplicaciones en el desarrollo de la organización.
Las empresas invierten en TI, que entienden la ventaja competitiva del valor añadido por la
tecnología. El objetivo de modelado de negocio es establecer primero una mejor
comprensión y comunicación entre ingeniería de negocios y la ingeniería de software.
Comprender el negocio significa que los ingenieros de software deben entender la
estructura y la dinámica de la empresa objetivo (el cliente), los problemas actuales de la
organización y las posibles mejoras. También deben asegurar una comprensión común de la
organización de destino entre los clientes, usuarios finales y desarrolladores.
REQUISITOS DEL CURSO: Este curso explica cómo al llegar peticiones de las partes
interesadas («partes interesadas») los convierten en un conjunto de requisitos que los
productos funcionan dentro del sistema que se construirán y proporcionaran los requisitos
detallados para lo que es necesario del sistema.
ANÁLISIS Y DISEÑO DE LA DISCIPLINA («DISEÑO»): El propósito del análisis y
diseño es mostrar cómo se llevará a cabo el sistema. El objetivo es construir un sistema
que:
 Ejecutar en un entorno de ejecución específica, las tareas y las funciones
especificadas en las descripciones de casos de uso
 Satisfacer todas sus necesidades
 Es fácil de mantener cuando no son cambios en los requisitos funcionales, los
resultados del proyecto en un modelo de análisis y diseño tiene opcionalmente un
modelo de análisis. El modelo de diseño sirve como una abstracción del código
fuente, es decir, el proyecto sirve como modelo de «retroalimentación» de la forma
en que el código fuente está estructurado y escrito.
 El modelo de diseño consta de clases de diseño estructurados en paquetes y
subsistemas con interfaces bien definidas, en representación de lo que se convertirá
componentes de la aplicación. También contiene descripciones de cómo los objetos
de estas clases colaboran para llevar a cabo el diseño de casos de uso.
LA DISCIPLINA IMPLEMENTACIÓN: Los efectos de la aplicación son:
 Para configurar el código de la organización en términos de subsistemas de
aplicación organizados en capas.
 Para llevar a cabo las clases y objetos en términos de componentes (archivos de
código 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 través de los componentes de la aplicación. El proceso describe
cómo reutilizar componentes existentes o implementar nuevos componentes con
responsabilidades bien definidas, haciendo que el sistema sea más fácil de mantener y
aumentar las posibilidades de reutilización.
PRUEBA DE DISCIPLINA: Los fines de disciplina prueba son:
 Comprobar la interacción entre los objetos.
 Comprobar la correcta integración de todos los componentes de software.
 Compruebe que todos los requisitos han sido ejecutados correctamente.
 Identificar y asegurar que los defectos se tratan antes de la implementación de
software.
 Asegúrese de que todos los defectos son corregidos, revisados y cerrados.
LA DISCIPLINA IMPLEMENTACIÓN: El propósito del despliegue es producir
lanzamientos de productos exitosos y entregar el software a los usuarios finales. Abarca una
amplia gama de actividades, incluyendo la producción de versiones de software externos, el
envase de aplicaciones de software y de negocios, distribución de software, instalación de
software y proporcionar ayuda y asistencia a los usuarios.
TRES DISCIPLINAS SOPORTE / SERVICIO DE LA METODOLOGÍA 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 organización
de desarrollo de software y herramientas que apoyarán al equipo de desarrollo. Si los
usuarios no entienden que 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.
CONFIGURACIÓN DE LA DISCIPLINA Y DE LA GESTIÓN: La disciplina de la
gestión del cambio en el negocio con RUP abarca tres tratamientos específicos:
configuración, solicitudes de cambio, y el estado y de medida.
La gestión de configuración: gestión de la configuración es responsable de la
estructuración sistemática de productos. Los artefactos tales como documentos y modelos
necesitan estar bajo el control de versiones y estos cambios deben ser visibles. También
realiza un seguimiento de las dependencias entre los artefactos de manera que todos los
artículos relacionados se actualizan cuando se realizan cambios
La gestión 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 medición de la gestión: las solicitudes de cambio tienen los estados: nuevo,
conectado, aprobado, asignado y completa. La solicitud de cambio también tiene atributos
como la causa raíz, o la naturaleza (como el incumplimiento y recuperación), prioridad, etc.
Estos estados y atributos se almacenan en la base de datos para producir informes útiles
sobre el progreso del proyecto.
PROYECTO DE GESTIÓN DE LA DISCIPLINA: La planificación 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 número de alta granularidad o planes de iteración que describe los
pasos iterativos.

PRINCIPIOS BASICOS DE LA METODOLOGIA RUP

PRINCIPIOS Y LAS MEJORES PRÁCTICAS DE LA METODOLOGÍA RUP: La

metodología RUP se basa en un conjunto de principios de desarrollo de software y las
mejores prácticas, por ejemplo:
 Desarrollo de software iterativo.
 La gestión de requisitos.
 El uso de una arquitectura basada en componentes.
 Software de modelado visual.
 La verificación de la calidad del software.
 Control de cambios en el software.
DESARROLLO ITERATIVO: Teniendo en cuenta el tiempo necesario para desarrollar
un software grande y sofisticado, no se puede definir el problema y construir software en un
solo paso. Los requisitos cambiarán a menudo en el curso del desarrollo del proyecto,
debido a las restricciones de la arquitectura, las necesidades del usuario o para una mayor
comprensión del problema original.
LA GESTIÓN DE REQUISITOS: La gestión de requisitos en RUP se centra en encontrar
el final – el usuario necesita para la identificación y especificación de lo que necesita y la
identificación de lo que debe ser cambiado. Esto trae los siguientes beneficios: La
corrección de los requisitos genera la corrección del producto, por lo que se satisfacen las
necesidades de los usuarios.
RUP sugiere que la administración de requerimientos tiene que seguir las actividades:
 Análisis de los problemas es que de acuerdo con el problema y crear medidas que
probarán su valor para la organización.
 La comprensión de las necesidades de sus grupos de interés es para compartir el
problema y los valores con los principales interesados y elevar lo que las
necesidades están involucrados en el desarrollo de la idea.
 La definición del problema es la definición de las características de las necesidades
y el diseño de los casos de uso, actividades que mostrarán fácilmente 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 especificación 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 gestión 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 fácilmente extensible, intuitiva
y fácil de entender y promueve la reutilización de software.
SOFTWARE DE MODELADO VISUAL: Haciendo abstracción de su programación de
su código y representarla por medio de bloques de construcción gráficas constituye una
forma eficaz de obtener una visión general de una solución. El uso de esta representación,
los recursos técnicos pueden determinar la mejor manera de poner en práctica un conjunto
dado de interdependencias lógicas.
SOFTWARE DE CONTROL DE CALIDAD: Aseguramiento de la calidad del software
es el punto de fallo más común en los proyectos de software, ya que esto es a menudo algo
que no se había pensado anteriormente y, a veces es tratado por diferentes equipos. RUP
ayuda en la planificación del control de calidad y se encarga de su construcción en todos los
procesos de participación de todos los miembros del equipo.
No es una tarea está dirigida específicamente 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 del 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 métodos para controlar, seguir y supervisar estos
cambios. RUP define también el trabajo seguro de espacios (espacios de trabajo seguros en
inglés), lo que garantiza que un sistema de ingeniería de software no se ve afectada por los
cambios en otros sistemas. Este concepto es pegar bien con arquitecturas de software
basados en consonantización

METODOLOGIA DUM

DUM (Diseño Unificado con Métrica): es una metodología evolutiva e incremental de

desarrollo del software que ha sido creada en el departamento de Lenguajes y Ciencias de
la Computación de Universidad de Málaga (Peláez et al. 2008). Basada en un enfoque
iterativo incremental, esta metodología realiza una especificación exhaustiva de todas las
actividades y tareas que se realizan en las diferentes fases, prestando especial atención por
alcanzar un nivel superior de madurez según el marco CMMI/CarnegieMellon.

CARACTERISTICAS DE LA METODOLOGIA DUM

El proceso de desarrollo DUM abarca las etapas de Descripción, Desarrollo y

Mantenimiento de la I.S., las cuales subdivide en 6 fases:

PRELIMINAR: En la Fase Preliminar se llevan a cabo una serie de pasos previos en los
que se sientan las bases que permiten comenzar el proyecto. En esta fase el cliente
proporciona los dos elementos básicos para comenzar un proyecto: una petición formal del
mismo; y una definición del problema al que debe dar respuesta el Sistema a desarrollar. En
base a estos dos elementos la organización de desarrollo definirá un primer equipo
encargado del inicio del proyecto.
INICIO: en esta fase se estudia si es posible llevar a cabo el proyecto. Todas las labores
que se realicen en esta fase se llevan a cabo con el fin de aclarar situaciones que pongan en
cuestión el éxito del proyecto, sin entrar en mayor detalle.
ELABORACION: En esta fase se realiza una especificación exhaustiva del sistema a
desarrollar y se desarrollan completamente los elementos más importantes del mismo. El
objetivo es certificar que el proyecto es viable atendiendo a las restricciones impuestas por
el cliente.
CONSTRUCCION: En esta fase se desarrollan el resto de los elementos no desarrollados
en la fase anterior. Al final de esta fase se cuenta con una versión del sistema plenamente
funcional, pero que no ha sido probada en un entorno de producción.
TRANSICION: Durante esta fase se prueba la versión del sistema obtenida en la fase
anterior en un entorno de producción, solventando las incidencias detectadas. También se
prepara la finalización del proyecto, incluyendo instalación del sistema, puesta en marcha o
planes de formación.

MANTENIMIENTO: En esta fase se atiende a las incidencias o solicitudes de mejora,

estudiando las propuestas y gestionando las modificaciones que se decidan realizar, bien
introduciéndolas o bien posponiéndolas para futuras versiones del sistema. Cuando las
modificaciones pospuestas son muy numerosas, puede determinarse el comienzo de un
nuevo ciclo de vida.
Cada una de estas fases tiene definida una iteración, que podrá ejecutarse una o más veces
hasta conseguir los objetivos de la fase. No se pasara a una fase posterior hasta no haber
logrado dichos objetivos.

Cada iteración está compuesta por actividades pertenecientes a alguna de las siguientes
líneas de trabajo:
 Planificación.
 Estudio de viabilidad.
 Identificación y especificación de requisitos.
 Análisis del Sistema.
 Diseño del Sistema.
 Construcción del Sistema.
 Prueba del Sistema.
 Mantenimiento del Sistema.
 Labores de Calidad.
 Labores de Seguridad.
 Labores de Gestión de la Configuración.
 Labores de Gestión de Proyectos.

Ventajas de la metodología DUM:

DELIMITACION DEL TRABAJO A REALIZAR: La unidad fundamental en un
proyecto DUM es el Caso de Uso, el cual define la funcionalidad del sistema a desarrollar
desde el punto de vista del cliente. Los Casos de uso son también la unidad fundamental en
función de la cual se determina el trabajo necesario, se asignan tareas y se realizan
estimaciones de costes, tanto económicos como temporales y de esfuerzo. Además
permiten conocer de forma exacta el estado real del proyecto en un momento determinado.
FLEXIBILIDAD: La segunda unidad fundamental en un proyecto DUM son las
iteraciones. Las iteraciones se caracterizan por utilizar poca cantidad de información, lo que
les confiere gran flexibilidad para asimilar modificaciones, al mismo tiempo que facilita la
incorporación de nuevos participantes al proyecto una vez que ha comenzado. Al final de
cada iteración se añade funcionalidad al sistema dotando al proceso de un carácter
incremental.
SOLIDEZ: Las iteraciones otorgan flexibilidad al tratamiento de los Casos de Uso, sin
embargo, la flexibilidad aun siendo una buena cualidad, debe ser controlada, o de lo
contrario puede derivar en procesos impredecibles.
Para ello, debemos situar nuestro proceso flexible sobre una base sólida, a la que llamamos
Arquitectura del Sistema, y que está formada por los elementos más importantes del
mismo. Esta arquitectura se desarrollara completamente durante la fase de elaboración,
permitiendo el desarrollo del resto de los Casos de Uso en la fase de construcción, de
manera flexible, pero siempre en base a dicha arquitectura.

Desventaja de la Metodología DUM:

El hecho de que el proceso posea como características tanto la flexibilidad como la solidez
permite que ambas cualidades se limiten entre si.
Algunas Herramientas que pueden utilizarse para trabajar con ella son:
 Visible Analyst (paga, con Free Commutnity Edition).
 Enterprise Architect (paga).
 Visual Paradigm (paga, con Free Commutnity Edition).
 Rational Rose (paga).
 Lucidchart (online, cloud based, colaborativo).
 Genmymodel (online, colaborativo).