Este documento describe los conceptos clave de la gestión de proyectos de TI utilizando RUP y UML. Explica que RUP es un proceso iterativo e incremental centrado en la arquitectura y guiado por casos de uso. Describe los principales artefactos de RUP como los modelos de casos de uso, requisitos, diseño e implementación. También explica los diagramas clave de UML 1.X y 2.0 y cómo se usan en las diferentes fases del desarrollo de software.

1. GESTION DE PROYECTOS
DE TI
RUP-UML

2. OBJETIVOS
El alumno será capaz de comprender los siguientes
temas:
RUP
Características
Fases
Disciplinas
Artefactos
Roles
UML
Diagramas usados en UML 1.X y UML 2.0

3. IBM(R) Rational Unified Process(R)

4. PRINCIPALES ARTEFACTOS RUP
Disciplina Artefacto Inicio Elaboración Construcción Transición
Administración de Plan de Desarrollo I R R R
Proyecto
Lista de Riesgos I R R R
Requisitos Modelo de Casos de Uso I R
Visión I R
SRS I R
Glosario I R
Análisis y Diseño Modelo de Diseño I R
Documento de Arquitectura I
de SW
Modelo de Datos I R
Implementación Modelo Implementación I R R
Pruebas Plan de Pruebas I R R
Despliegue Plan de Despliegue I
I = Inicio, R= Refinamiento

5. Características de RUP

6. CARACTERISTICAS DEL RUP
<<communicate>>
Consulta
Administrador
<<extend>>
Identificacion
Dirigido por los
Casos de Uso
Centrado en la Iterativo e
Arquitectura Incremental

7. DIRIGIDO POR CASOS DE USO
Un caso de uso es un fragmento de
funcionalidad del sistema que proporciona un
resultado de valor a un usuario. Los casos de
uso modelan los requerimientos funcionales del
sistema.
Los casos de uso también guían el proceso de
desarrollo (diseño, implementación y pruebas).
De este modo los casos de uso no solo inician el
proceso de desarrollo sino que le proporcionan
un hilo conductor, que avanza a través de una
serie de flujos de trabajo.

8. DEPENDENCIA ENTRE LOS CASOS DE USO Y LOS DEMÁS
MODELOS
<<communicate>>
Consulta
Administrador
<<extend>>
Identificacion
Especificado por Realizado por Distribuido por Implementado por
Modelo de análisis Modelo de diseño Verificado por
Modelo de despliegue Modelo de
implementación
X
OX
X
OX
X
OX
Modelo de prueba

9. ITERATIVO E INCREMENTAL
El esfuerzo de desarrollo de un proyecto de
software se divide en partes mas pequeñas o
mini proyectos.
Cada mini proyecto es una iteración que resulta
en un incremento.
Las iteraciones deben seleccionarse y ejecutarse
de forma planificada. Esta selección se basa en
dos cosas:
El conjunto de casos de uso que amplían
funcionalidad
En los riesgos mas importantes que deben
mitigarse

10. APLICANDO CASCADA ITERATIVAMENTE
Iteración 1 Iteración 2 Iteración 3
R R R
D D D
C C C
T T T
T I EMPO
Las primeras iteraciones reducen los principales riesgos
Cada iteración produce una versión ejecutable, un incremento
adicional al sistema
Cada iteración incluye integración y test

11. CENTRADO EN LA ARQUITECTURA
La arquitectura se describe mediante diferentes
vistas del sistema en construcción.
Incluye aspectos estáticos y dinámicos.
La arquitectura es una vista del diseño completo
con las características más importantes
resaltadas, dejando de los detalles de lado.
La arquitectura debe permitir el desarrollo de
todos los casos de uso requeridos actualmente y
a futuro, y los casos de uso deben encajar en la
arquitectura.

12. ¿QUE ES UN MODELO?
Un Modelo es
una Simplificación de la Realidad

13. ¿POR QUÉ DEBE MODELARSE UN SOFTWARE?
Diseñar un modelo para sistemas de software es
tan fundamental como tener un modelo para
una construcción grande. Los buenos modelos:
Identifican requerimientos y comunican
información
Se enfocan en como interactúan los
componentes sin necesidad de detalles
Permite visualizar las relaciones entre
componentes de diseño
Mejor la comunicación entre un equipo de
desarrollo a través del uso de un lenguaje
gráfico común

14. UNIFIED MODELING LANGUAGE (UML)
¿Qué es UML?
Es un estándar notacional empleado para
modelar y representar sistemas de software y
sus partes desde distintas perspectivas,
generando diagramas o artefactos.
Etapas donde se utiliza UML
Requerimientos
Análisis
Diseño
Implementación

15. DIAGRAMAS UML 1.X
State
State
Use Case Diagrams de
Diagramas
Use Case Diagrams State
Use Case Diagrams de
Diagramas Clases State
Use Case Diagrams Diagrams de
Diagramas
Diagrams de
Diagramas Casos de Uso Diagrams
Diagrams Objetos
Secuencia
Scenario State
Scenario State
Diagrams de
Diagramas Diagrams de
Diagramas
Diagrams Diagrams
Colaboración Modelos Componentes
Scenario Component
Scenario Component
Diagramas de
Diagrams
Diagrams de
Diagramas Diagrams
Diagrams Distribución
Estados Diagramas de
Actividad

16. DIAGRAMAS UML 2.0
Diagrama de Diagramas de
Maquina de Estados Casos de Uso
Diagrama de
Diagrama de Clases
Actividad Diagrama de
Objetos
Diagrama de
Secuencia
Diagrama de
Diagrama Visión Despliegue
de Interacción
Modelos
Diagrama de
Diagrama Componentes
de Tiempos
Diagrama Diagrama de Diagrama de Estructura
de Comunicación Estructura Paquete Compuesta

17. ARQUITECTURA DE SOFTWARE
Captura los aspectos estratégicos de la
estructura de alto nivel de un sistema
Abarca un conjunto de decisiones significativas
acerca de la organización de un sistema.
Involucra:
Selección de elementos que componen un
sistema y las interfaces entre ellos.
El comportamiento, especificado a través de
colaboraciones entre esos elementos.
Funcionalidad, desempeño, control de errores
y persistencia.

18. ORGANIZACIÓN DE MOLELOS
Vistas de UML: Arquitectura 4 + 1
5 Vistas
9 Diagramas

19. MODELO DE VISTAS 4+1
Creado por Philippe Kruchten(1995), vinculado
al Rational Unified Process (RUP), que define
cuatro vistas diferentes:
La vista estructural o lógica. Provee una
descripción estática de las clases primarias y
sus relaciones
La vista de implementación. Para mostrar
cómo el código se organiza en paquetes y
bibliotecas y el uso de software estándar
comercial

20. MODELO DE VISTAS 4+1
La vista de comportamiento. Para mostrar los
procesos y las tareas
La vista de ambiente o de despliegue, para
mostrar los procesadores, dispositivos y
enlaces en el medio operacional
Existe una quinta vista, la de usuario, que
consiste en una selección de casos de uso o de
escenarios que los arquitectos pueden elaborar a
partir de las cuatro vistas anteriores.

21. ORGANIZACIÓN DE MODELOS

22. FASES DEL RUP

23. FASE DE INICIO (INCEPTION)
Durante la fase de inicio se desarrolla la
descripción del producto final, 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 mas importantes?
¿Cuál es el plan del proyecto y cuanto costará
desarrollar el producto?
En esta fase se identifican y priorizan los riesgos
mas importantes.

24. WORKFLOW

25. FASE DE INICIO (INCEPTION)
Artefactos
• Un documento de visión • Caso de negocio:
general:
– Contexto
– Requerimientos generales
– Criterios de éxito
del proyecto
– Pronóstico financiero
– Características principales
• Identificación inicial de
– Restricciones
riesgos.
• Modelo inicial de casos de
• Plan de proyecto.
uso (10% a 20 % listos).
• Uno o más prototipos.
• Glosario.

26. FASE DE INICIO (INCEPTION)
Hito:
Objetivos del
Ciclo de Vida
Inicio Elaboración Construcción Transición
• Las partes interesadas deben acordar el
alcance y la estimación de tiempo y costo.
• Comprensión de los requerimientos plasmados
en casos de uso.

27. FASE DE INICIO (INCEPTION)

28. NUEVO PROYECTO
Paso previo para
identificar el problema a
solucionar

29. EL STAKEHOLDER
Es un rol que es responsable por representar a
un grupo de interés, cuyas necesidades deben
ser satisfechas por el proyecto.
El papel puede ser desempeñado por alguien
que es (o será potencialmente) afectado por el
resultado del proyecto

30. EL STAKEHOLDER
Muchos de los interesados son usuarios del sistema. Otros
son sólo usuarios indirectos del sistema o se ven afectados
sólo por los resultados del sistema. La comprensión de
quiénes son los interesados y sus necesidades son
elementos clave en el desarrollo de una solución eficaz.
Ejemplos de Stakeholders:
Clientes o representante del cliente, Usuarios
o usuario representante, Inversionistas,
Accionistas, Propietarios o miembro de la
Junta, Gerentes, Compradores,
Diseñadores, Tester, Documentadores, entre
otros.

31. DOCUMENTO VISION
Requerimiento Inicial del Mi problema es
o de los Stakeholder la lentitud en la
Desde el punto de vista atención …..
del Analista se analiza
los requerimientos
iniciales y se realiza la
visión inicial de lo que
será la Aplicación Final
Stakeholder
Analista

32. EJEMPLO: Requerimiento Stakeholder
La Gerente de los un restaurant, nos hace el siguiente
requerimiento:
Necesita que se generen automáticamente los requerimientos de
compra de productos de acuerdo a la venta de platos del día
Personalizar la venta de los platos y que su precio se calcule de
forma automática
Se requiere tener una gestión de mesas de forma grafica.
Control de stock por unidades, envases y medidas (Administrar
un conjunto de unidades de medida y sus respectivas
conversiones)
Gestionar clientes, proveedores y productos
Estadísticas de venta y de compra.
Ventas Delivery por WEB y teléfono. Gestión y recepción de
pedidos
Nota: Además el restaurante cuenta con un sistema de facturación
(Visual Basic 6.0 y SQL 2000), este sistema solo se tiene los
ejecutables, por lo que no se puede modificar. Esto solo corre en
la máquina de caja

33. PROYECTO
Versión 1.0
Versió
Una vez realizada la
Visión el Jefe de
Proyecto evalúa los
riesgos, los costos, realiza
el plan de desarrollo de
software y el plan de
iteración del proyecto para
la fase de inception.
Lista de Riesgos
Caso de Negocio
Plan de Desarrollo de Software
Plan de Iteración para inception

34. CASO DE NEGOCIO
El Caso de negocio ofrece la información
necesaria desde un punto de vista empresarial
para determinar si procede o no este proyecto o
si vale la pena o no invertir en él.
Para que un producto de software sea valido, los
negocios debe incluir una serie de supuestos
sobre el proyecto y el orden de magnitud de
retorno de la inversión (ROI).
Por ejemplo, el retorno de la inversión será de
una magnitud de cinco si ésta ha sido
completada en un año, dos si ésta ha sido
completada en dos años, y un número negativo
después de eso.

35. ESTRUCTURA DE UN DOCUMENTO CASO DE NEGOCIO
1. INTRODUCCIÓN
1.1 Propósito
1.2 Alcance
1.3 Definiciones, Acrónimos y Abreviaturas
1.4 Referencias
1.5 Descripción
2. DESCRIPCIÓN DEL PRODUCTO
3. CONTEXTO DEL NEGOCIO
4. OBJETIVOS DEL PRODUCTO
5. PRONÓSTICO FINANCIERO
6. RESTRICCIONES

36. LISTA DE RIESGOS
En el desarrollo de Sw. un riesgo es una variable
que puede tomar un valor que pueda disminuir
la probabilidad de éxito en un proyecto o
eliminarla por completo.
EL RUP cuenta con un documento que clasifica e
identifica los riesgos para poder ser mitigados.

37. EJEMPLO

38. PLAN DE DESARROLLO DE SOFTWARE
El Plan de Desarrollo de Software es un proceso
global, compuesto por un artefacto que reúne
toda la información necesaria para administrar el
proyecto.
Incluye una serie de artefactos desarrollados
durante la fase inicial y se mantiene a lo largo
del proyecto.

39. PLAN DE PROYECTO ITERATIVO
Preguntas
¿Cuántas iteraciones se necesitan?
¿Cuan larga debe ser una iteración?
¿Cómo se determina el contenido y objetivos
para una iteración?
¿Cómo realizar un seguimiento a una
iteración?
Asignación de tareas y responsabilidades del
equipo

40. PLAN DE PROYECTO ITERATIVO
Las primeras iteraciones (en las fases de Inicio y
Elaboración) se enfocan hacia:
La compresión del problema y la
tecnología
La delimitación del ámbito del proyecto
La eliminación de los riesgos críticos
Al establecimiento de una baseline de
la arquitectura.

41. PLAN DE PROYECTO ITERATIVO
Elaboración de 2 dimensiones de planes
Plan de Fases
Plan de Iteración
Consideraciones especiales
Ambos planes deben tener en cuenta el factor
riesgo (evitarlo, transferirlo o aceptarlo), lo
cual implica elaborar actividades para
disminuir el riesgo o definir un plan de
contingencia
Tener presente métricas para medir
cumplimiento de objetivos

42. EL PLAN DE FASES
Contenido
Fechas de los principales puntos de control
Fecha Fin de la Etapa ‘Inception’ con el proyecto bien definido
Fecha Fin de la Etapa ‘Elaboration’ con las Arquitectura
terminadas
Fecha Fin de la Etapa ‘Construction’ con la versión beta
Fecha Fin de la Etapa ‘Transition’ con la versión final del
Producto
Definición de perfiles del Staff
Fechas de menores puntos de control
Fecha Fin de cada iteración y sus principales objetivo
Se debe tener presente lo siguiente para la definición de fechas
Existen arquitecturas ya desarrolladas
Cantidad de riesgos que necesitan
Experiencia del equipo
Desarrollo complejo

43. EL PLAN DE ITERACIÓN
Contenido
Siempre existen dos planes de iteración activas
El plan de la iteración actual, se utiliza
para realizar un seguimiento
El plan de la siguiente iteración, se afina
en base a la presente iteración
Una iteración es como un mini-proyecto con
tiempos, asignación de tareas y cuyo producto es
una versión del SW a revisar
Fechas de menores puntos de control
Fecha Fin de cada iteración y sus
principales objetivos

44. EL PLAN DE ITERACIÓN
Contenido
Definición de la duración de una iteración
Cultura organizacional
Nivel de automatización del equipo de
SW
Distribución de la información
Experiencia en pruebas
Número de iteraciones
Análisis por Fases o Etapa

45. EL PLAN DE ITERACIÓN
Pasos para elaborar el plan de iteración
Definir los objetivos de éxito de cada iteración
Permite realizar un control de la iteración
Permite costear
Identificar los artefactos que se necesitarán elaborar o
actualizar y las actividades para realizar las operaciones
mencionadas
Ordenar y priorizar las actividades acorde con los
recursos
Utilizar estimaciones para asignar tiempos para cada
actividad

46. ENTORNO DEL PROYECTO

47. EJEMPLO: Herramientas de soporte al proyecto
Word
Formato de los entregables,
Tabla de contenido
Encabezados y pie de pagina
Estructura de documentos
Project
Diagrama de Gantt
Diagrama de Recursos
Microsoft Visio for Enterprise Architect
Modelos (Diagramas UML)

48. FASE DE ELABORACION
Se especifican en detalle la mayoría de los casos de uso y
se diseña la arquitectura.
Las iteraciones en la fase de elaboración:
Establecen una firme comprensión del
problema a solucionar.
Establece un plan detallado para las siguientes
iteraciones.
Elimina los mayores riesgos.
El resultado de esta fase es la línea base de la
arquitectura.

49. WORKFLOW

50. FASE DE ELABORACION
Los objetivos son:
Recopilar la mayor parte de los requisitos
definiéndolos como casos de uso
Establecer una línea base de la arquitectura
guiar el trabajo en las fases posteriores
Continuar la observación y control de los
riesgos críticos
• Para ello
• Se toman decisiones considerando:
requisitos funcionales y no funcionales

51. FASE DE ELABORACION
Artefactos:
• Modelo de casos de uso • Un prototipo ejecutable
(80% completo) con de la arquitectura.
descripciones detalladas.
• Lista revisada de riesgos
• Otros requerimientos no y del caso de negocio.
funcionales o no asociados
• Plan de desarrollo para el
a casos de uso.
resto del proyecto.
• Descripción de la
• Un manual de usuario
Arquitectura del Software.
preliminar.

52. FASE DE ELABORACION
Hito: Arquitectura de
Ciclo de Vida
Concepción Elaboración Construcción Transición
• Condiciones de éxito de la elaboración:
– ¿Es estable la visión del producto?
– ¿Es estable la arquitectura?
– ¿Las pruebas de ejecución demuestran que los riesgos
han sido abordados y resueltos?
– ¿Están de acuerdo con el plan todas las personas
involucradas?

53. FASE DE CONSTRUCCIÓN
En esta fase todas los componentes restantes se
desarrollan e incorporan al producto.
Todo es probado a profundidad.
El énfasis está en la producción eficiente y no ya
en la creación intelectual.
Puede hacerse construcción en paralelo, pero
esto exige una planificación detallada y una
arquitectura muy estable.

54. FASE DE CONSTRUCCIÓN
Los objetivos son:
Línea base de la arquitectura crece hasta
convertirse en el sistema completo
Riesgos reducidos o rutinarios
Implementación de los casos de uso
Prototipo
• Para ello
• A través de sucesivas iteraciones e
incrementos se desarrolla un producto
software, listo para operar, éste es
frecuentemente llamado versión beta

55. FASE DE CONSTRUCCIÓN
ARTEFACTOS:
El producto de software integrado y
corriendo en la plataforma adecuada.
Manuales de usuario.
Una descripción del “release” actual.

56. FASE DE CONSTRUCCION
Hito: Capacidad
Operacional
Concepción Elaboración Construcción Transición
• Se obtiene un producto Beta que debe decidirse si
puede ponerse en ejecución sin mayores riesgos.
• Condiciones de éxito:
– ¿El producto está maduro y estable para instalarlo en
el ambiente del cliente?

57. FASE DE TRANSICIÓN
Los objetivos son:
Cumplir los requisitos de fases anteriores
Gestionar todos los aspectos de implantación
Pruebas de aceptación
• Para ello
• Las iteraciones en esta fase continúan
agregando características al sw.
• El equipo se encuentra ocupado en corregir
y extender la funcionalidad del sistema
desarrollado en la fase anterior.

58. FASE DE TRANSICIÓN
El objetivo es traspasar el software desarrollado
a los usuarios.
Incluye:
Pruebas Beta para validar el producto con las
expectativas del cliente
Ejecución paralela con sistemas antiguos
Conversión de datos
Entrenamiento de usuarios
Distribuir el producto

59. FASE DE TRANSICIÓN
Hito:
Producto
Concepción Elaboración Construcción Transición
• Condiciones de éxito:
– ¿Se han alcanzado los objetivos fijados en
la fase de Inicio ?
– ¿El usuario está satisfecho ?

60. Disciplinas y Flujos de
Trabajo

61. DISCIPLINAS Y FLUJOS DE TRABAJO
Disciplinas de
Proceso
Disciplinas
de Soporte

62. DISCIPLINAS
Una disciplina es una colección de actividades
relacionadas vinculadas con un área específica
del proyecto.
Facilitar la comprensión del proyecto desde la
perspectiva tradicional del modelo en cascada.

63. FLUJO DE TRABAJO
Describe la secuencia en que se realizan las
actividades en una disciplina, quienes la realizan
(trabajadores) y que artefactos producen..

64. DISCIPLINAS DE SOPORTE
1. Gestión de configuraciones: controla los cambios y
mantiene la integridad de los artefactos de un proyecto.
2. Gestión del Proyecto: describe varias estrategias de
trabajo en un proceso iterativo.
3. Entorno: cubre la infraestructura necesaria para
desarrollar un sistema.

65. ADMINISTRACIÓN Y CONFIGURACIÓN DE CAMBIOS
Forma de controlar los artefactos producidos por
las personas que trabajan en el proyecto.
Algunos problemas habituales:
Actualizaciones simultáneas
Múltiples versiones
RUP da guías para:
Desarrollos en paralelo
Automatizar la construcción
Administrar defectos

66. ADMINISTRACIÓN DEL PROYECTO
• Es el arte de balancear objetivos contrarios, manejar
riesgos y producir software que satisface a clientes y
usuarios.
• Existen pocos proyectos realmente exitosos.
• RUP incluye:
– Un framework para manejo de proyectos de
software
– Guías para planificación, provisión de personal,
ejecución y monitoreo de planes
– Un framework para manejar riesgos

67. DISCIPLINAS DE PROCESO
1. Modelado del negocio: describe la estructura y la
dinámica de la organización.
2. Requisitos: describe el método basado en casos de uso
para extraer los requisitos.
3. Análisis y diseño: describe las diferentes vistas
arquitectónicas.

68. DISCIPLINAS DE PROCESO
4. Implementación: tiene en cuenta el desarrollo de
software, la prueba de unidades y la integración.
5. Pruebas: describe los casos de pruebas, los
procedimientos y las métricas para evaluación de defectos.
6. Despliegue: cubre la configuración del sistema
entregable.

69. Modelado de Negocio
Disciplina RUP

70. MODELADO DE NEGOCIO
El objetivo es entender la estructura y la dinámica del
negocio.
Se elabora un Modelo de Casos de Uso del Negocio
describe los proceso de negocio de una empresa en
términos de
Casos de uso del negocio y
Actores del negocio
que se corresponden con los procesos del
negocio y los clientes respectivamente .

71. ACTIVIDADES DEL MODELO DE NEGOCIO

72. ARTEFACTOS

73. Requerimientos

74. REQUERIMIENTOS EN LAS PRIMERAS FASES
Inicio Elaboración
Usa el lenguaje del Usa el lenguaje de
Cliente los desarrolladores
Descripción de los Se refinan los
CU en lenguaje requisitos.
natural,
Se estructuran los
Se usan Diagramas requisitos en base a
de actividad. clases y paquetes.
Vista externa del Vista interna del
sistema. sistema.

75. RUP - WORKFLOW DE REQUERIMIENTOS
Encontrar Actores
Analista de Sistemas y Casos de Uso
Estructurar el Modelo
de Casos de Uso
Arquitecto Priorizar
los Casos de Uso
Detallar
Especificador CU los Casos de Uso
Diseñador de Interfaz Prototipar
de usuario la Interfaz de Usuario

76. ACTIVIDADES - REQUERIMIENTOS

77. ARTEFACTOS - REQUERIMIENTOS

78. Análisis y Diseño

79. Refinamiento de los Casos de Uso
Modelamiento del
negocio
(Casos de Uso)
Requerimientos
(Detalle Caso Uso)
Análisis y Diseño
(Clases y diagrama
de secuencias)

80. ACTIVIDADES DE ANALISIS Y DISEÑO

81. ARTEFACTOS DE ANALISIS Y DISEÑO

82. Componentes de una Arquitectura Física

83. Implementación

84. IMPLEMENTACIÓN - ACTIVIDADES

85. IMPLEMENTACIÓN - ARTEFACTOS

86. IMPLEMENTACION
Trabajador Responsable de (artefacto)
Arquitecto Modelo de implementación
Modelo de despliegue
Descripción de la arquitectura
Integrador de sistema Plan de integración de
construcción
Ingeniero de Componentes Componente
Implementación de subsistema
Interfaz

87. DIAGRAMA DE COMPONENTES

88. Pruebas

89. PRUEBAS
Los objetivos de la prueba son:
Planificar las pruebas necesarias en cada
iteración, incluyendo las pruebas de
integración y las pruebas de sistema.
Diseñar e implementar pruebas creando:
Casos de prueba (especifican qué probar),
Procedimientos de prueba (especifican cómo realizar
las pruebas),
Componentes de prueba para automatizar las
pruebas.
Realizar las pruebas.

90. ACTIVIDADES

91. ARTEFACTOS

92. Despliegue

93. DESPLIEGUE
Producir un producto y hacerlo llegar a sus
usuarios finales.
Incluye varias actividades:
Producir un “release”
Empaquetar el software
Distribuir el software
Realizar pruebas beta
Instalar el software
Apoyar a los usuarios
Migración de datos

94. ACTIVIDADES

95. ARTEFACTOS

96. Conclusiones

97. CONCLUSIONES
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.

98. CONCLUSIONES
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.
Combinación de varios modelos de proceso.
Arquitecturas Dirigidas por Modelos (Model
Driven Architectures).

99. BIBLIOGRAFIA
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.