Metodologia rup parte 1

Metodología RUP. (Rational Unific Process)
(Primera parte)
Marbella Castañeda Rivas
marbella.cas@gmail.com

 es un proceso de desarrollo de software desarrollado por la empresa Rational
Software, actualmente propiedad de IBM
 un conjunto de metodologías adaptables al contexto y necesidades de cada
organización
Historia
Según Wikipedia, “Los orígenes de RUP se remontan al modelo espiral original de Barry
Boehm. Ken Hartman, uno de los contribuidores claves de RUP colaboró con Boehm en la
investigación. En 1995 Rational Software compró una compañía sueca llamada Objectory AB,
fundada por Ivar Jacobson, famoso por haber incorporado los casos de uso a los métodos de
desarrollo orientados a objetos. El Rational Unified Process fue el resultado de una convergencia
de Rational Approach y Objectory (el proceso de la empresa Objectory AB). El primer resultado
de esta fusión fue el Rational Objectory Process, la primera versión de RUP, fue puesta en el
mercado en 1998, siendo el arquitecto en jefe Philippe Kruchten”

• Orígenes
– Modelo original Objectory definido por Ivan Jacobson (1987)
– Rational Software compra la empresa de Objectory (1995)
– Surge la primera versión de UML (1997)
– Se publica la primera versión del Proceso Unificado de Rational - RUP
(junio 1998)

Basado en seis principios claves de desarrollo
1. Proceso adaptable
2. Equilibra prioridades
3. Demuestra valor iterativamente
4. Colaboración entre equipos
5. Eleva el nivel de abstracción
6. Se enfoca en la calidad
Se caracteriza por :
1. Los casos de uso
2. Centrados en la arquitectura
3. Modelo de Ciclo de vida es iterativo e incremental
4. Estructura dinámica

 Dirigido por casos de uso
– Se centra en la funcionalidad que el sistema debe poseer para satisfacer las
necesidades de un usuario (persona, sistema externo, dispositivo) que
interactúa con él
– Casos de uso como el hilo conductor que orienta las actividades de desarrollo
Casos de Uso
Análisis
Recopilar,
Clarificar y
Validar los
requerimientos
Diseño
Realizar los
casos de uso
Pruebas
Verificar que se
satisfacen los
casos de uso
<<realiza>> <<verifica>>
<<defineNecesidades>>
Fuente: Ricardo Borillo. Introducción al Modelado. Metodologías, UML y patrones de diseño.

Metodología RUP. (Rational Unific
Process)
 Centrado en la arquitectura
 Concepto similar a la arquitectura de un edificio
 Varios planos con diferentes aspectos del edificio
 Tener una imagen completa del edificio antes que comience la construcción
 Arquitectura en software
 Diferentes vistas del sistema: estructural, funcional, dinámico, etc.
 Plataforma en la que va a operar
 Determina la forma del sistema
 Arquitectura: determina la forma del sistema
 Casos de uso: determinan la función del sistema

 Modelo de Ciclo de vida:
 Iterativo e incremental
 Descomposición de un proyecto grande en mini-proyectos
 Cada mini-proyecto es una iteración
 Las iteraciones deben estar controladas
 Cada iteración trata un conjunto de casos de uso
 Ventajas del enfoque iterativo
 Detección temprana de riesgos
 Administración adecuada del cambio
 Mayor grado de reutilización
 Mayor experiencia para el grupo de desarrollo

Dimensión Estructura
Dinámica
 Ciclo: cada ciclo una nueva versión del producto
 Fase: Etapas de un ciclo que finalizan en un HITO
 Iteración: Proceso de ingeniería sobre una funcionalidad limitada del
sistema
Estática - Flujos de trabajo
 Artefactos
 Actividades
 Roles

http://www.google.co.ve/imgres?imgurl=http://2.bp.blogspot.com/-
52UeNtFxRY4/UMc3uSSwn5I/AAAAAAAAADM/02yHmzdKYeM/s1600/rup.png&imgrefurl=http://metodologirup.blogspot.com/&h=57
9&w=758&sz=143&tbnid=sBpzetvS3G_F3M:&tbnh=91&tbnw=119&zoom=1&usg=__mTuqFqwmBT7Aa2dW5z4mlfqIDY4=&docid=Oi
YjRTUaXQBweM&sa=X&ei=Pr5_UdWcLYe09gSS8YGQCg&ved=0CDcQ9QEwAQ&dur=325

Ciclo de vida : es un desarrollo en espiral
Hito : punto en el tiempo en donde se evalúan objetivos logrados y se toman decisiones
críticas

Ciclo de
desarrollo 1
Ciclo de
desarrollo 2
Ciclo de
desarrollo n
Perfeccionar
el plan
Sincronizar
Artefactos
Análisis Diseño Construcción Pruebas
Construcción

Fase de Inicio o Concepción
En esta fase es donde se realiza el modelo del negocio. Se concreta la idea, la visión del producto, como se
enmarca en el negocio, el alcance del proyecto. El objetivo en esta etapa es determinar y proponer una visión
general de la arquitectura de software y producir el plan de las fases y el de las iteraciones consiguientes. Se
construyen los diagramas de caso de uso, requisitos.
Elaboración
Aquí en esta fase de desarrollo, es donde se construye el documento arquitectura de las diferentes vistas, para
posteriormente construir la base de datos.
Desarrollo o Construcción
En esta fase es donde pasamos a modelar el producto que vamos a mostrar al usuario con todo sus
requerimientos, además de que en esta etapa se realiza la implantación y las pruebas al mismo.
Transición
Durante esta fase de transición busca garantizar que se tiene un producto preparado para su entrega al
usuario. Pruebas finales de adaptación , puesta en producción.

• Objetivo:
Definir el alcance del
proyecto. Estudio de
oportunidad
Modelo de Negocio
Visión= Qué
+ PARA QUÉ +
CUÄNTO
• Actividades
o Especificación de los
criterios de éxito
del proyecto
o Especificación de los
requerimientos
o Estimación de los
recursos necesarios
• Artefactos
o Documento de
definición del
proyecto
• Objetivo: Establecer un plan
de proyecto y una arquitectura
correcta del sistema.
• Actividades:
o Análisis del dominio del
Problema
o Definición de la arquitectura
básica
o Análisis de riesgo
o Planificación del proyecto
• Artefactos:
o Vista Lógica
Diagrama de clases
Modelo E-R (Si el sistema así lo
requiere)
o Vista de Implementación
Diagrama de Secuencia
Diagrama de estados
Diagrama de Colaboración
o Vista Conceptual
Modelo de dominio
o Vista física
Mapa de comportamiento a
nivel de hardware.
• Objetivo: desarrollar
el sistema a lo largo de
una serie de iteraciones
• Especificación de
requisitos faltantes
• Diseño y desarrollo de
casos de uso y/o flujos
de acuerdo con la
planeación iterativa
• Pruebas de los casos de
uso desarrollados, y
pruebas de regresión
según sea el caso
• Pruebas finales de
aceptación
• Puesta en producción
• Estabilización

• El Modelado de Negocios se define como un proceso de representación de uno o mas
aspectos de la empresa tales como:
o Propósito
o Estructura
o Funcionalidad
o Dinámica
o Lógica de negocios
o Componentes:
 Fines
 Procesos de negocio
 Reglas de negocio
 Objetos de negocio
 Acciones
 Unidades organizativas

 Modelado del negocio
En esta fase el equipo se familiariza con el funcionamiento de la organización o
empresa, conoce los procesos de interés relacionados con el problema.
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.

 Según Booch (2002) “el modelado de negocio se define como “el flujo de trabajo
en el cual se pretende llegar a un mejor entendimiento de la organización donde se
va a implantar el producto”. Plantea como objetivos:
• Entender la estructura y la dinámica de la organización para el cual el sistema va
a ser desarrollado (organización objetivo)
• 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.
• Derivar los requisitos del sistema necesarios para apoyar a la organización
objetivo
Para lograr estos objetivos:
• Desarrollar la visión de la organización
• Definir los procesos, roles y responsabilidades de la organización por medio de
un modelo de Caso de Uso del Negocio
• Definir el Modelo de objetos del Negocio

 Requisitos
o 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.
o Establecer y mantener un acuerdo entre clientes y otros stakeholders
sobre lo que el sistema podría hacer.
o Proveer a los desarrolladores un mejor entendimiento de los requisitos
del sistema.
o Definir el ámbito del sistema.
o Proveer una base para estimar costos y tiempo de desarrollo del sistema.
o Definir una interfaz de usuarios para el sistema, enfocada a las necesidades
y metas del usuario.

 Según Booch (2002), los requisitos se dividen en dos
grupos:
 funcionales los cuales representan la funcionalidad del sistema y se modelan
mediante los diagramas de Casos de Uso.
 Los requisitos no funcionales representan aquellos atributos que debe exhibir el
sistema, pero que no son de funcionalidad específica, como por ejemplo facilidad
de uso, fiabilidad, eficiencia, portabilidad

La especificación de los requerimientos de Entradas, que consiste en el
prototipado de las interfaces o pantallas de actualización de datos. Se debe contemplar
aspectos propios de la implementación, como ser: ubicación de menú, ubicación de
botones de opciones, barra de acceso rápido, diseño de íconos, uso de colores
corporativos, tipo de letra, tamaño de letra, etc
La especificación de los requerimientos de Salidas, que consiste en el
prototipado de los reportes, pantallas de consulta, informes gráficos, estadísticas, salidas a
archivos, etc. Comprende un modelado lo más preciso posible a lo que se implementará.
Especificación de interfaces con otros sistemas o aplicaciones. Consiste en
determinar el nivel de procesos y de datos, los requerimientos de transferencia de
información con otros sistemas o aplicaciones existentes.

El enfoque de Rational-IBM
•‰ Énfasis en el
modelado de:
• „ Procesos de negocio
• „ Objetos de negocios
•‰ Los procesos de negocio se modelan con
casos de uso
•‰ Los objetos de negocio se modelan con
diagramas de clases

AC
Artefacto o
Producto
Workflows
de
Proceso
Conceptualizar
el sistema
Requerimientos
Modelo
Conceptual
Modelo de
Casos de Uso:
Actores, caso
de usos,
relaciones
Actividades
•Indagar, conocer el negocio
•Especificar los requerimientos
•Conceptualizar el sistema
•Confeccionar el modelo conceptual
Actividades
• Identificar los actores
• Estructurar el sistema a partir del modelo conceptual
• Describir cada caso de Uso
• Establecer las relaciones

Metodologia rup parte 1

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (20)

Destacado

Destacado (20)

Similar a Metodologia rup parte 1

Similar a Metodologia rup parte 1 (20)

Último

Último (20)

Metodologia rup parte 1