02 rup

5,986 views
5,799 views

Published on

rup (rational unified process)

Published in: Education
0 Comments
2 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
5,986
On SlideShare
0
From Embeds
0
Number of Embeds
19
Actions
Shares
0
Downloads
367
Comments
0
Likes
2
Embeds 0
No embeds

No notes for slide

02 rup

  1. 1. GESTION DE PROYECTOS DE TI RUP-UML
  2. 2. OBJETIVOSEl 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. 3. IBM(R) Rational Unified Process(R)
  4. 4. PRINCIPALES ARTEFACTOS RUPDisciplina Artefacto Inicio Elaboración Construcción TransiciónAdministración de Plan de Desarrollo I R R RProyecto Lista de Riesgos I R R RRequisitos Modelo de Casos de Uso I R Visión I R SRS I R Glosario I RAnálisis y Diseño Modelo de Diseño I R Documento de Arquitectura I de SW Modelo de Datos I RImplementación Modelo Implementación I R RPruebas Plan de Pruebas I R RDespliegue Plan de Despliegue I I = Inicio, R= Refinamiento
  5. 5. Características de RUP
  6. 6. CARACTERISTICAS DEL RUP <<communicate>> Consulta Administrador <<extend>> Identificacion Dirigido por los Casos de Uso Centrado en la Iterativo e Arquitectura Incremental
  7. 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. 8. DEPENDENCIA ENTRE LOS CASOS DE USO Y LOS DEMÁSMODELOS <<communicate>> ConsultaAdministrador <<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. 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. 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. 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. 12. ¿QUE ES UN MODELO? Un Modelo es una Simplificación de la Realidad
  13. 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. 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. 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. 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. 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. 18. ORGANIZACIÓN DE MOLELOS Vistas de UML: Arquitectura 4 + 1 5 Vistas 9 Diagramas
  19. 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. 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. 21. ORGANIZACIÓN DE MODELOS
  22. 22. FASES DEL RUP
  23. 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. 24. WORKFLOW
  25. 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. 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. 27. FASE DE INICIO (INCEPTION)
  28. 28. NUEVO PROYECTO Paso previo para identificar el problema a solucionar
  29. 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. 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. 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. 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. 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. 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. 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. 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. 37. EJEMPLO
  38. 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. 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. 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. 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. 42. EL PLAN DE FASESContenido 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. 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. 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. 45. EL PLAN DE ITERACIÓNPasos 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. 46. ENTORNO DEL PROYECTO
  47. 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. 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. 49. WORKFLOW
  50. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 60. Disciplinas y Flujos de Trabajo
  61. 61. DISCIPLINAS Y FLUJOS DE TRABAJODisciplinas deProcesoDisciplinasde Soporte
  62. 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. 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. 64. DISCIPLINAS DE SOPORTE1. 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. 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. 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. 67. DISCIPLINAS DE PROCESO1. 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. 68. DISCIPLINAS DE PROCESO4. 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. 69. Modelado de Negocio Disciplina RUP
  70. 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. 71. ACTIVIDADES DEL MODELO DE NEGOCIO
  72. 72. ARTEFACTOS
  73. 73. Requerimientos
  74. 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. 75. RUP - WORKFLOW DE REQUERIMIENTOS Encontrar ActoresAnalista de Sistemas y Casos de Uso Estructurar el Modelo de Casos de Uso Arquitecto Priorizar los Casos de Uso DetallarEspecificador CU los Casos de UsoDiseñador de Interfaz Prototipar de usuario la Interfaz de Usuario
  76. 76. ACTIVIDADES - REQUERIMIENTOS
  77. 77. ARTEFACTOS - REQUERIMIENTOS
  78. 78. Análisis y Diseño
  79. 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. 80. ACTIVIDADES DE ANALISIS Y DISEÑO
  81. 81. ARTEFACTOS DE ANALISIS Y DISEÑO
  82. 82. Componentes de una Arquitectura Física
  83. 83. Implementación
  84. 84. IMPLEMENTACIÓN - ACTIVIDADES
  85. 85. IMPLEMENTACIÓN - ARTEFACTOS
  86. 86. IMPLEMENTACIONTrabajador Responsable de (artefacto)Arquitecto Modelo de implementación Modelo de despliegue Descripción de la arquitecturaIntegrador de sistema Plan de integración de construcciónIngeniero de Componentes Componente Implementación de subsistema Interfaz
  87. 87. DIAGRAMA DE COMPONENTES
  88. 88. Pruebas
  89. 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. 90. ACTIVIDADES
  91. 91. ARTEFACTOS
  92. 92. Despliegue
  93. 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. 94. ACTIVIDADES
  95. 95. ARTEFACTOS
  96. 96. Conclusiones
  97. 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. 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. 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.

×