Material de Soporte 1 - RUP

Unidad 2
Proceso Unificado
Requerimiento y Análisis
Contenido
1. ¿Qué es un proceso?
2. El Proceso Unificado.
3. Fases del ciclo.
4. Flujos de trabajo.
5. Tipos de resultados.
6. Modelado de Requisitos.
7. Modelado de Análisis.
¿Qué es un proceso?
Es una secuencia de acciones o pasos dispuestos de forma lógica que se llevan a cabo
para el logro de un determinado fin.
Permite mejorar la productividad al planificar las acciones, establecer un orden, reducir
riesgos y mitigar posibles problemas en el desarrollo de una solución.
¿Qué es el Proceso Unificado?
Define un proceso de desarrollo de software.
Es principalmente un marco de referencia (framework) que se puede
adaptar según la organización o tipo de proyecto.
Se caracteriza por:
◦ Estar dirigido por los casos de usos
◦ Centrado en la arquitectura y ser
◦ Interactivo e incremental
Está dirigido por los casos de uso
Los requisitos de los usuarios son lo que justifica el desarrollo
de software.
Los casos de uso son el medio sistemático de capturar
requisitos funcionales.
Permiten:
▪ Encontrar las clases e identificar sus características.
▪ Planificar u organizar el trabajo.
▪ Realizar la trazabilidad de los artefactos del proyecto.
▪ La trazabilidad permite identificar el valor que agrega cada
nuevo artefacto.
9.4. El Proceso Unificado

Está centrado en la arquitectura
La arquitectura puede pensarse como la forma en que todos

los involucrados ven finalmente desarrollado el sistema.
La arquitectura da una clara perspectiva del sistema completo
que permite controlar el desarrollo.
La arquitectura:
◦ Facilita el desarrollo, incrementando la reutilización.
◦ Permite identificar elementos del modelo: subsistemas,
dependencias, interfaces, colaboraciones, nodos y clases.

Es un proceso iterativo e incremental
“Una iteración es un conjunto de actividades llevadas a cabo

de acuerdo a un plan y unos criterios de evaluación, que lleva
a producir una versión.”
Un enfoque iterativo:
Propone resolver incrementalmente un problema por medio
de refinamientos sucesivos y un crecimiento incremental a
través de varias versiones.
Es flexible y se acomoda a nuevos requisitos o a cambios
tácticos en los objetivos del negocio.
Permite identificar y resolver riesgos lo más pronto.

Además …
Es un proceso configurable, se puede elegir el set de
actividades de acuerdo a la organización o problema.
Orientado a Objetos, Se basa en UML que representa clases,
objetos y relaciones.
Impulsa un control de calidad, a través de la trazabilidad y
mejora continua de los artefactos y
Fomenta la gestión y control del riesgo, por medio de las
iteraciones cortas.

El Proceso Unificado
Es una estructura matricial donde filas representan las
actividades del flujo de trabajo y columnas representa a
fases que están subdivididas en iteraciones.
Los tiempos están definidos por las fases.
Los esfuerzos están definidos por los flujos de trabajo.
La representación gráfica se denomina en la jerga el
Diagrama de Montañas.
El flujo de trabajo esta conformado por el ciclo de vida del
desarrollo y soporte.

Proceso Unificado: Iterativo e Incremental
Flujos de trabajo
del proceso Iniciación Elaboración Construcción Transición
Modelado del
negocio
Requisitos
Análisis y diseño
Implementación
Pruebas
Despliegue
Flujos de trabajo
de soporte
Gestión del cambio
y configuraciones
Gestión del proyecto
Entorno
Iteraciones Iter Iter Iter Iter Iter Iter Iter

preliminares #1 #2 #n #n+1 #n+2 #m #m+1
Fuente: Jacobson et al., 2000

Elementos del Proceso Unificado
En esta estructura matricial se puede deducir que:

1.Modelos: son el resultado de los flujos de trabajo.
2.Iteraciones: son la conjunción del tiempo (fases) y esfuerzos
(flujos de trabajo).
3.Versiones: son la conjunción de tiempo (fases) y resultados
(modelos).
4.Tipos de Modelos: es la conjunción de resultados (modelos) y
esfuerzos (flujos de trabajo)

Fases
Fase: Es el intervalo de tiempo entre dos hitos importantes del

proceso que subdivido en iteraciones busca el logra de
objetivos bien definidos.
Iteración: Representa un ciclo de vida de desarrollo completo,
que puede incluir: requisitos, análisis, diseño, implementación
y pruebas, estos microciclos busca producir como resultado un
artefactos o programa ejecutable.
10.1. Fases del ciclo

Fases
Iniciación.
◦ Se establece la planificación del proyecto y se delimita su alcance.
Elaboración.
◦ Se analiza el dominio del problema, se establece una base
arquitectónica sólida, se desarrolla el plan del proyecto y se eliminan
los elementos de más alto riesgo del proyecto.
Construcción.
◦ Se desarrolla de forma iterativa e incremental un producto completo
que está preparado para la transición hacia la comunidad de usuarios.
Transición.
◦ El software se despliega en la comunidad de usuarios.

Las iteraciones son distintas en el ciclo de vida
Flujos de trabajo
F1: Modelado del

negocio
F2: Requisitos
F3: Análisis y diseño

F4: Implementación
F5: Pruebas
F6: Despliegue
Flujos de trabajo
de soporte
F7: Gestión del cambio
y configuraciones
F8: Gestión del proyecto
F9: Entorno
preliminares#1 #2 #n #n+1 #n+2 #m #m+1
F2 F2 F3 F2
F1 F1 F4
F3 F3 F1
F9 F9 F9
F4 F4
F8
F8 F5 F8
F5 F5 F7
F6 F7 F6 F6 F7

Flujos de trabajo
Los esfuerzos aplicados en el ciclo de vida de

desarrollo son de dos tipos:
Del Proceso, Conjunto de actividades fundamentalmente
técnicas (Ciclo de vida de Desarrollo Clásico).
De soporte, Conjunto de actividades fundamentalmente
de gestión.
11.1. Flujos de trabajo

El ciclo de vida del desarrollo del software:
Flujos de trabajo
Flujos de trabajo
Modelado del
negocio
Requisitos
Análisis y diseño
Implementación
Pruebas
Despliegue
Flujos de trabajo
de soporte
Gestión del cambio
y configuraciones
Entorno


Flujos de trabajo de Proceso
▪ Modelado del negocio: describe la estructura y la dinámica de la

organización.
▪ Requisitos: describe el método basado en casos de uso para
extraer los requisitos.
▪ Análisis y diseño: describe las diferentes vistas arquitectónicas.
▪ Implementación: tiene en cuenta el desarrollo de software, la
prueba de unidades y la integración.
▪ Pruebas: describe los casos de pruebas, los procedimientos y las
métricas para evaluación de defectos.
▪ Despliegue: cubre la configuración del sistema entregable.

Flujos de trabajo de Soporte
▪ Gestión de configuraciones: controla los cambios y

mantiene la integridad de los artefactos de un proyecto.
▪ Gestión del Proyecto: describe varias estrategias de trabajo
en un proceso iterativo.
▪ Entorno: cubre la infraestructura necesaria para desarrollar
un sistema.

Tipos de resultados
Los modelos son el tipo de artefacto más importante

en el Proceso Unificado.
Hay nueve modelos que en conjunto cubren todas las
decisiones importantes implicadas en la visualización,
especificación, construcción y documentación de un
sistema con gran cantidad de software.
12.5. Tipos de resultados

Tipos de resultados
▪ Modelo del negocio: establece una abstracción de la organización.

▪ Modelo de casos de uso: establece los requisitos funcionales del sistema.
▪ Modelo del dominio: establece el contexto del sistema.
▪ Modelo de análisis (opcional): establece un diseño de las ideas.
▪ Modelo de diseño: establece el vocabulario del problema y su solución.
▪ Modelo del proceso (opcional): establece los mecanismos de concurrencia y
sincronización del sistema.
▪ Modelo de despliegue: establece la topología hardware sobre la cual se ejecutará el
sistema.
▪ Modelo de implementación: establece las partes que se utilizarán para ensamblar y hacer
disponible el sistema físico.
▪ Modelo de pruebas: establece las formas de validar y verificar el sistema.

Tipos de resultados
El Proceso Unificado recupera el concepto de vista de UML.

Para el Proceso Unificado una vista es una proyección de un
modelo.
Usualmente la forma de organizar las vistas se basa en el
modelo 4+1 vistas diseñado por Philippe Kruchten:
▪ La vista de diseño.
▪ La vista de procesos.
▪ La vista de despliegue.
▪ La vista de implementación.
▪ La vista de casos de uso.

Vistas de la arquitectura de un sistema
vocabulario, ensamblado del
funcionalidad sistema,
Vista de gestión de
Vista de diseño configuraciones
implementación
comportamiento Vista de
casos de uso
Vista de Vista de
procesos despliegue
Funcionamiento, topología del

capacidad de sistema,
crecimiento, distribución,
rendimiento entrega,
instalación

Relaciones lógicas entre los modelos :
Modelo de
Casos de Uso verificado por
especificado por realizado por

Modelo de
distribuido por Prueba
Modelo de
Análisis
Modelo de implementado por
Diseño
Modelo de
Despliegue
Modelo de
Implementación

Modelos y flujos de trabajo
del Proceso Unificado
Modelado del Implementa-

Requisitos Análisis Diseño Prueba Despliegue
Negocio ción
Modelo del
Negocio X
Modelo del
Dominio X X
Modelo de
Casos de Uso X
Modelo de
Análisis X
Modelo de
Diseño X
Modelo de
Procesos X
Modelo de
Despliegue X X
Modelo de
Implementación X X
Modelo de
Prueba X X

Modelos y flujos de trabajo
del Proceso Unificado

Tipos de resultados
Los artefactos conjunto del RUP son los siguientes:

1. Conjunto de requisitos.
2. Conjunto de diseño.
3. Conjunto de implementación.
4. Conjunto de despliegue.

Tipos de resultados - Requisitos
• Agrupa toda la información que describe lo que debe

hacer el sistema.
• Puede comprender un modelo de casos de uso, un
modelo de requisitos no funcionales, un modelo del
dominio, un modelo de análisis y otras formas de
expresión de las necesidades del usuario, incluyendo
pero no limitándose a maquetas, prototipos de la
interfaz, restricciones legales, etc.

Tipos de resultados - Diseño
• Agrupa información que describe cómo se va a

construir el sistema y captura las decisiones acerca de
cómo se va realizar, teniendo en cuenta las
restricciones de tiempo, presupuesto, aplicaciones
existentes, reutilización, objetivos de calidad y demás
consideraciones.
• Puede implicar un modelo de diseño, un modelo de
pruebas y otras formas de expresión de la naturaleza
del sistema, incluyendo, pero no limitándose, a
prototipos y arquitecturas ejecutables.

Tipos de resultados - Implementación
• Agrupa toda la información acerca de los elementos

software que comprende el sistema, incluyendo, pero
no limitándose, a código fuente en varios lenguajes de
programación, archivos de configuración, archivos de
datos, componentes software, etc., junto con la
información que describe cómo ensamblar el sistema.

Tipos de resultados - Despliegue
• Agrupa toda la información acerca de la forma en que

se empaqueta actualmente el software, se distribuye,
se instala y se ejecuta en el entorno destino.

Requerimiento,
Análisis y
Diseño

Modelado de Requisitos
Flujos de trabajo
Modelado del
negocio Requisitos
Requisitos
Análisis y diseño
Implementación
Pruebas
Despliegue
Flujos de trabajo
de soporte
Gestión del cambio
y configuraciones
Entorno

13.4. Captura y Modelado de Requisitos

El Análisis de Requisitos tiene por misión convertir el problema, expresado en

términos del dominio del negocio, a soluciones descritas en el lenguaje del
dominio de la Tecnología de Información.
El problema y su planteamiento pertenecen al Espacio del Problema:
◦ Descripción concreta del negocio.
◦ Dominio de los Objetos de Negocio (DON).
Las soluciones pertenecen al Espacio de la Solución:

◦ Descripción concreta del sistema de información.
◦ Dominio de los Objetos de Negocio.
◦ Dominio de los Objetos de Infraestructura (DOI):
◦ Subdominio de Objetos de Bases de Datos (SDOBD).
◦ Subdominio de Objetos de Interfaz (SDOIZ).

Metamodelo de requerimientos

Tipos de Requerimientos

Tipos de Requerimientos

FURPS

FURPS+

Se realiza por medio de los flujos de trabajo:

◦ Modelado del negocio.
◦ Requisitos.
Resultado:
◦ Modelo del Negocio y Dominio.
◦ Modelo de Casos de Uso.

Modelo de Negocios
▪ Asegurar un entendimiento del negocio de parte del
cliente usuarios y desarrolladores del sistema.
▪ Identifica los procesos de negocio.
▪ Establece la reglas y responsabilidades.
▪ Incluye procesos todos los procesos y permite
identificar los procesos que se pueden automatizar.
▪ Se obtiene con técnicas similares al modelo de
sistemas automatizados (casos de usos de negocio y
modelos de objetos de negocios)

Requisitos
1. Búsqueda de Actores y Casos de Usos

▪ Búsqueda de actores (usuarios y stakeholders)
▪ Requerimientos funcionales y no funcionales (modelo FURPS)
▪ Definición de casos de usos (Diagrama de casos de Uso)
2. Priorización de casos de usos
▪ Basado en utilidad para el usuario y riesgo de desarrollo
3. Detalles de casos de usos
4. Interface o Prototipo

Motivaciones del modelamiento de casos de uso
Los casos de uso son textos, no diagramas y el

modelamiento de casos de uso es principalmente escribir
textos y no diagramas
▪ Genera un medio que permite la participación y comunicación de forma simple entre

todos los involucrados del proyectos, desde expertos conocedores del dominio del
negocio hasta expertos ingenieros de software.
▪ Esta centrado en la experiencia y objetivos de los usuarios, permite a partir de esa
experiencia expresar los requerimiento por medio de una descripción de un escenario de
éxito completo de interacción entre los actores y el sistema.
▪ Debido al simple lenguaje que se utiliza permite centrarse en el QUE evitando entrar en
tecnicismos que podrían obscurecer los objetivos que busca el actor al utilizar el sistema.

Flujo de trabajo de los requerimientos

Definición de Actores
Se parte por identificar a los actores que son entidades o personas que tienen algún
tipo de interés del sistema, usualmente personas pero que también pueden ser
organizaciones o incluso otros sistemas.
Existen 3 tipos de actores
▪ Primarios: Son aquellos que tienen un fin u objetivos en el CU, de modo que el caso
de uso lograr satisfacerlo completamente.
▪ De Soporte: Le brinda un servicio al CU, proveyendo de información, puede ser una
persona como otro sistema.
▪ Fuera de escenario o indirectos: tiene intereses en el funcionamiento del caso de uso
pero no directamente, por ejemplo una entidad reguladora, de seguridad, etc.

Definición de Casos de usos
La definición de casos de usos parte por la identificación de escenarios, que es la

secuencia de acción e interacciones entre el actor y el sistema, refleja la historia de un
uso particular del sistema de forma exitosa o del uso fallido también. Se parte de la
identificación los escenarios que se definen los casos de usos y que incluyen una
colección de escenarios de éxito y fracaso.
Existen 3 tipos de descripciones
▪ Resumida: Un párrafo breve que describas de forma resumida el escenario principal
de éxito.
▪ Casual: Varios párrafos, descritos informalmente, que incluyen varios escenarios de
éxito y alternativos.
▪ Formal: Todos los pasos y variantes son descritas en detalle, subdividido en secciones.

Ejemplo de descripción resumida
Procesar venta : Un cliente arriba a un punto de pago con los productos que ha
comprado. El cajero usa un terminal de punto de venta (POS) y registra cada producto
comprado. El sistema presenta el total y el detalle de cada producto adquirido. El
cliente proporciona la información de pago y el sistema valida y lo registra. El sistema
actualiza el inventario. En cliente récipe su ticket de pago del sistema y libera los
productos para que puedan ser retirados.

Ejemplo de descripción informal
Procesar devolución
Escenario principal : Un cliente arriba a un punto de pago con los productos que desea
devolver. El cajero usa un terminal de punto de venta (POS) y registra cada producto
devuelto. El sistema presenta el total y el detalle de cada producto devuelto. El cliente
proporciona la información de devolución y el sistema valida y registra. El sistema
actualiza el inventario. En cliente récipe su ticket por la devolución del sistema y
registra los productos para hacerlos disponibles en almacén.
Escenarios alternativos: Si el cliente pago al crédito y la transacción de reembolso es
rechazada por el sistema, se le informa y paga al contado.
Si el producto no es encontrado en el sistema se registra manualmente utilizando el
código de identificación del producto….

Secciones de una descripción Formal

Ejemplo de descripción detallada
Caso de Uso CU1: Procesar Venta, Ámbito: Sistema XXX

Actor principal: Cajero
Interesados:
◦ Cajero, debe asegurarse de que las operaciones de pago sean sin errores por que podría ser
descontado de su sueldo.
◦ Vendedores, Recibirán una comisión por venta exitosa
◦ Cliente, Comprar un producto con el mínimo esfuerzo, de forma segura y fácil.
◦ Empresa, Asegurarse de un registro exitoso de las venta y satisfacción y fidelización del cliente.
◦ Administrador, Proceso éxitos y fáciles de ser auditados y controlados
◦ SUNAT, Asegurarse que los cobros de impuestos sigan las normativas gubernamentales
◦ Servicios Financieros, registro de operaciones de crédito o debito correcto en las cuentas bancarias
correctas

Caso de Uso CU1: Procesar Venta , Ámbito: Sistema XXX

Precondiciones: El cajero se ha identificado y autenticado
Postcondiciones o Garantía de éxito: Venta es almacenada correctamente en el
sistema, Calculo de impuesto es el correcto, Inventario actualizado correctamente,
comisión de vendedor registrada correctamente, recibo de venta es generado
correctamente, autorización de pago aprobado y registrado correctamente en el
sistema.
Escenario principal:
1. El cliente arriba a un punto de pago con los productos que ha comprado.
2. El cajero inicia la nueva compra


3. El cajero ingresa la identidad de un producto
4. El sistema registra cada producto y presenta su descripción, precio, y total. El precio
es calculado por las reglas de precio definidas en la empresa.
El cajero repite 3 y 4 hasta que finalice con todos los productos
5. El sistema presenta el total y el calculo del impuesto.
6. El cajero muestra al cliente el total y le solicita el pago.
7. El cliente realiza el pago y se registra en el sistema de pago.


8. El sistema registra la venta, actualiza el stock, informa a los servicios financieros y
contables correspondientes.
9. El sistema emite el recibo
10. El cliente obtiene el recibo y se retira con los productos comprados.
Flujos alternativos:
a) En algún momento, administrado rectifica alguna operación.
b) En algún momento, el sistema falla.
c) En algún momento, el cliente cancela toda la operación.


Flujos alternativos:
a) En algún momento, administrador rectifica alguna operación:
1. El administrador ingresa al sistema su código de autorización
2. El sistema ingresa a modo autorizado de administrador
3. El administrador realizar la operación autorizada y sale
4. El sistema retorna al modo regular de autorización.
b) En algún momento, el sistema falla.
1. Asegurarse de la hora de la ultima transacción y los detalles de los productos registrados.
2. El cajero reestablece el sistema, se autentica y solicita al sistema el proceso de recuperación del
estado anterior.
3. El sistema reconstruye la operación, detecta anomalías y registra los errores.
4. El cajero inicia una nueva venta.


Requisitos especiales (Requerimientos no funcionales):
1. Confiabilidad: El sistema no deberá permitir el registro parcial de alguna operación.
2. Confiabilidad: La comunicación y transmisión de pagos a los sistemas financieros
deberá ser 100% confiable, no se acepta fallas en el registro de los pagos.
3. Rendimiento: Sistema de Pago con respuesta de 30 segundos en aproximadamente
el 90% de los casos
4. Facilidad de uso: Monitores touch en paneles flat de resolución adecuada para ser
visualizables a 2 metros.
5. Facilidad de uso: En castellano e ingles y que incluya accesibilidad a personas
ciegas.

Reglas para identificar un CU correcto
Existen varia reglas que pueden ser útiles, aunque la pregunta más útil no
es preguntar si un CU es correcto o no si no ¿Cual es el nivel de detalle de
un CU para expresar un requerimiento adecuadamente?
▪ Prueba del Jefe: ¿Qué es lo que están haciendo?, si el muy escaso no
satisfará al Jefe.
▪ Prueba del Proceso de Negocio Elemental: Similar a la prueba del Jefe
pero no solo se asegura lo escaso sino se asegura que la tarea no
involucre ni demasiados recursos, ni que se ejecute en tiempos
diferentes.
▪ Prueba del Tamaño: Asegurarse de forma similar que los anteriores
pruebas que no sea tan simple que solo involucre un solo paso o muy
complejo que involucre demasiados pasos que se requiera muchos
paginas para describirlo.

Caso de Uso - Generalización
Fuente: Craig Larman, Applying UML and Patterns an introduction to object-oriented analysis and design and iterative development, 2016

Caso de Uso - Generalización

Caso de Uso - Inclusión

Caso de Uso - Inclusión

Caso de Uso - Extensión

Caso de Uso - Extensión

Modelado de Análisis
Una vez completado el modelo de casos de uso (CU) se ha llegado a

obtener diagramas de casos de uso en determinados niveles que ya no
se pueden explotar más.
Si se intentara explotar los CU, se pasaría a describir el comportamiento
interno de las funciones con artefactos inadecuados.
Los casos de uso contenidos en estos diagramas se denominan casos de
uso elementales.
Esta situación límite indica que se debe pasar a trabajar con otros
artefactos, que son los del modelo de análisis:
◦ Clases de análisis.
◦ Asociaciones.
◦ Diagramas de clases.
◦ Diagramas de colaboración asociados a los diagramas de clases.
14.1. Modelado de Análisis

Modelo de
Casos de Uso verificado por
especificado por realizado por

Modelo de
distribuido por Prueba
Modelo de
Análisis
Modelo de implementado por
Diseño
Modelo de
Despliegue
Transición del MCU hacia el MA
Modelo de
Implementación

El Análisis en el RUP se realiza por medio de los flujos de

trabajo:
◦ Análisis y diseño.
El resultado del Análisis es el siguiente:

◦ Modelo de Análisis.
El Modelo de Análisis contiene:

◦ La Vista de Diseño de UML.
◦ La Vista de Procesos de UML.

Flujos de trabajo
Modelado del
negocio
Requisitos
Análisis y diseño Análisis

Implementación
Pruebas
Despliegue
Flujos de trabajo
de soporte
Gestión del cambio
y configuraciones
Entorno


Modelo de casos de uso
con estructura de
desglose de diagramas
Realización de caso de uso
NIVEL 0
Casos de Uso → Análisis
Cada caso de uso se
desglosa en un diagrama
en el nivel inferior
MODELO DE CASOS DE USO MODELO DE ANÁLISIS
«trace»
NIVEL1
caso de uso (MCU) Realización (MA)
Cada caso de uso se

desglosa en un diagrama
Interfaz Gestor/Control Entidad
en el nivel inferior
NIVEL 2
Artefactos del modelo de análisis

Proceso de Conversión:
Casos de Uso → Análisis
F01.01 Consulta saldo
«trace»
caso de uso (MCU) Realización (MA) I_Cajero Cta_Cliente

Cliente C_Gestor_Interfaz

I_Autenticacion C_Verificador
Autenticacion
Diagrama de Clases de Análisis Atómico

Modelo de Casos de Uso Modelo de Análisis
MCU MA
Nivel 0 Nivel 0
MA
Top-Down MCU Nivel 1
Nivel 1 Bottom-Up
MCU MA
Nivel 2 Nivel 2
MCU MA
Nivel i Nivel j F01.01 Consulta saldo

Cliente I_Cajero C_Gestor_Interfaz Cta_Cliente
«trace»
caso de uso (MCU) Realización (MA)
I_Autenticacion C_Verificador_Autenticacio
n




Resumen
El Proceso Unificado es una metodología creada principalmente para el

desarrollo de software orientado a objetos.
Utiliza el soporte de modelado de UML, pero es independiente de UML.
El Proceso Unificado:
◦ Es un Proceso iterativo.
◦ Está centrado en la arquitectura.
◦ Está dirigido por los casos de uso.
◦ Es un proceso configurable.
◦ Soporta las técnicas orientadas a objetos.
◦ Impulsa un control de calidad y una gestión del riesgo objetivos y continuos.
17.1. Resumen
17. Resumen
La aplicación formal del Proceso Unificado supone:

◦ Desventajas:
◦ Grandes esfuerzos en la construcción de modelos.
◦ Necesidad del soporte de herramientas informáticas.
◦ Ventajas:
◦ Disminuye el riesgo del error de análisis / diseño acumulado.
◦ Aligera el esfuerzo en implementación.
◦ Proporciona la documentación del ciclo de vida en el mismo proceso.
17.2. Resumen
Resumen
El Proceso Unificado es flexible y se puede adaptar al grado de

complejidad del modelo de proceso de desarrollo (descarte de algunos
modelos o flujos).
El Proceso Unificado es abierto y permite la incorporación de enfoques y
artefactos complementarios:
◦ Patrones de diseño.
◦ Patrones de implementación.
◦ Marcos de diseño.
◦ Combinación de varios modelos de proceso.
◦ Arquitecturas Dirigidas por Modelos (Model Driven Architectures).
◦ Ejecutabilidad de modelos: UML 2, validación y verificación formales.
17.3. Resumen
Bibliografía
1. Booch G., Rumbaugh J., Jacobson I. El Lenguaje Unificado de Modelado, Addison-Wesley,
Madrid, 1999.
2. Bruegge B., Dutoit A.H. Ingeniería de Software Orientado a Objetos, Prentice Hall– Pearson
educación, México, 2002.
3. Jacobson I., Booch G., Rumbaugh J. El Proceso Unificado de Desarrollo de Software,
Addison-Wesley, Madrid, 2000.
4. Pressman R.S. Ingeniería del Software. Un enfoque práctico (5ª ed.) Mc Graw-Hill; New York
, 2001.
5. Rumbaugh J., Jacobson I., Booch G. El Lenguaje Unificado de Modelado. Manual de
Referencia, Addison-Wesley, Madrid, 2000.
6. Sommerville I. Ingeniería de software, 6ª edición, Prentice Hall – Pearson educación,
México, 2002.
7. Stevens P., Pooley R. Utilización de UML en Ingeniería del Software con Objetos y
Componentes, Addison-Wesley, Madrid, 2002.
8. http://www.omg.org
9. http://www.uml.org
18. Bibliografía Parte II

Material de Soporte 1 - RUP

Cargado por

Información del documento

Título 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

Material de Soporte 1 - RUP

Cargado por

Copyright:

Formatos disponibles

Unidad 2

9.4. El Proceso Unificado

La arquitectura puede pensarse como la forma en que todos

9.3. El Proceso Unificado

“Una iteración es un conjunto de actividades llevadas a cabo

9.2. El Proceso Unificado

9.5. El Proceso Unificado

9.8. El Proceso Unificado

Iteraciones Iter Iter Iter Iter Iter Iter Iter

Fuente: Jacobson et al., 2000

9.9. El Proceso Unificado

En esta estructura matricial se puede deducir que:

9.10. El Proceso Unificado

Fase: Es el intervalo de tiempo entre dos hitos importantes del

10.1. Fases del ciclo

10.2. Fases del ciclo

F1: Modelado del

F3: Análisis y diseño

10.3. Fases del ciclo

Los esfuerzos aplicados en el ciclo de vida de

11.1. Flujos de trabajo

Iteraciones Iter Iter Iter Iter Iter Iter Iter

11.4. Flujos de trabajo

▪ Modelado del negocio: describe la estructura y la dinámica de la

11.2. Flujos de trabajo

▪ Gestión de configuraciones: controla los cambios y

11.3. Flujos de trabajo

Los modelos son el tipo de artefacto más importante

12.5. Tipos de resultados

▪ Modelo del negocio: establece una abstracción de la organización.

12.6. Tipos de resultados

El Proceso Unificado recupera el concepto de vista de UML.

12.10. Tipos de resultados

Funcionamiento, topología del

12.11. Tipos de resultados

especificado por realizado por

12.7. Tipos de resultados

Modelado del Implementa-

12.8. Tipos de resultados

12.8. Tipos de resultados

Los artefactos conjunto del RUP son los siguientes:

12.15. Tipos de resultados

• Agrupa toda la información que describe lo que debe

12.16. Tipos de resultados

• Agrupa información que describe cómo se va a

12.17. Tipos de resultados

• Agrupa toda la información acerca de los elementos

12.18. Tipos de resultados

• Agrupa toda la información acerca de la forma en que

12.19. Tipos de resultados

12.19. Tipos de resultados

Iteraciones Iter Iter Iter Iter Iter Iter Iter

13.4. Captura y Modelado de Requisitos

El Análisis de Requisitos tiene por misión convertir el problema, expresado en

Las soluciones pertenecen al Espacio de la Solución:

13.1. Captura y Modelado de Requisitos

13.2. Captura y Modelado de Requisitos

13.2. Captura y Modelado de Requisitos

13.2. Captura y Modelado de Requisitos

13.2. Captura y Modelado de Requisitos

13.2. Captura y Modelado de Requisitos

Se realiza por medio de los flujos de trabajo:

13.3. Captura y Modelado de Requisitos