separata uml y rup

Prof.: Godofredo Ayquipa Cordova Curso: Análisis de Sistemas

UML (Lenguaje de Modelamiento Unificado)

Historia de UML

El lenguaje UML comenzó a gestarse en octubre de 1994, cuando James Rumbaugh se unió a la compañía Rational Software fundada por Grady Booch (dos reputados investigadores en el área de metodología del software). El objetivo de ambos era unificar dos métodos que habían desarrollado: el método Booch y el OMT (Object Modelling Tool). El primer borrador apareció en octubre de 1995. En esa misma época otro reputado investigador, Ivar Jacobson, se unió a Rational Software y se incluyeron ideas suyas. Estas tres personas son conocidas como los “tres amigos”. Además, este lenguaje se abrió a la colaboración de otras empresas para que aportaran sus ideas. Todas estas colaboraciones condujeron a la definición de la primera versión de UML.

¿Qué es UML? El UML (Lenguaje Unificado de Modelado) es una de las herramientas más emocionantes en el mundo actual del desarrollo de sistemas. Esto se debe a que permite a los creadores de sistemas generar diseños que capturen sus ideas en una forma convencional y fácil de comprender para comunicarlas a otras personas.

UML se ha convertido en ese estándar tan ansiado para representar y modelar la información con la que se trabaja en las fases de análisis y, especialmente, de diseño.

UML tiene una notación gráfica muy expresiva que permite representar en mayor o menor medida todas las fases de un proyecto informático: desde el análisis con los casos de uso, el diseño con los diagramas de clases, objetos, etc., hasta la implementación y configuración con los diagramas de despliegue.

Lenguaje

• El lenguaje gráfico de UML facilita la comunicación entre los distintos miembros de un proyecto. • Permite elevar el nivel de abstracción para obtener una visión más general de una parte de un

proyecto • UML es más que un montón de símbolos gráficos; detrás de cada símbolo hay una semántica bien

definida. Por lo tanto, una herramienta puede interpretar un modelo sin ambigüedad

Modelado

• Un modelo es una simplificación de la realidad [Booch99]. • ¿Por qué es necesario modelar?

� Los modelos nos ayudan a visualizar cómo es o queremos que sea un sistema (abstracción). � Los modelos nos permiten especificar la estructura y comportamiento de un sistema. � Los modelos nos proporcionan plantillas que nos guían en la construcción de un sistema. � Los modelos documentan las decisiones que hemos adoptado.

Unificado

UML resuelve de forma bastante satisfactoria un viejo problema del desarrollo de software como es su modelado gráfico. Además, se ha llegado a una solución unificada basada en lo mejor que había hasta el momento, lo cual lo hace todavía más excepcional.

UML define una notación: material gráfico para representar cada una de las vistas del modelo; es la sintaxis del lenguaje UML.

Prof.: Godofredo Ayquipa Cordova

Evolución de UML Los anteproyectos del UML empezaron a circular en la industria del software y las reacciones resultantes trajeron consigo considerables modificaciones. Conforme diversos corporativos vieron que el UML era útil a sus propósitos, se conformó un consorcio del UML. Entre los miembros se encuentran DEC, Hewlett-Intellicorp, Microsoft, Oracle, Texas Instruments y Rational. En 1997 el consorcio produjo la versión 1 .O del UML y lo puso aconsideración del OMG (Gmpo de administración de objetos) como respuesta a su propuesta para un lenguaje de modelado estándar. En noviembre de 1997 UML es aprobado por la OMG como un estándar con la versión UML 1.1


Objetivos de UML

UML es ante todo un lenguaje. Un lenguaje proporciona un vocabulario y unas reglas para permitir una comunicación. En este caso, este lenguaje se centra en la representación gráfica de un sistema.

Este lenguaje nos indica cómo crear ylas metodologías de desarrollo.

Los objetivos de UML son muchos, pero se pueden sintetizar sus funciones:

• Visualizar: UML permite expresar de una forma gráfica un sistema de f

• Especificar: UML permite especificar cuáles son las características de un siconstrucción. Significa construir modelos:

� Precisos (correctos, coherentes)� No ambiguos (formales)� Completos (enlace

UML cubre la especificación de todas las decisiones de� Análisis (conceptual y especificación)� Diseño � Implementación

que deben realizarse en un sistema con gran cantidad de software.

Cliente


Los anteproyectos del UML empezaron a circular en la industria del software y las

resultantes trajeron consigo considerables modificaciones. Conforme

vieron que el UML era útil a sus propósitos, se conformó un

UML. Entre los miembros se -Packard,

Oracle, Texas En 1997 el consorcio

UML y lo puso a consideración del OMG (Gmpo de

respuesta a su propuesta para un lenguaje de modelado

En noviembre de 1997 UML es aprobado por la OMG como un estándar con



Este lenguaje nos indica cómo crear y leer los modelos, pero no dice cómo crearlos. Esto último es el objetivo de

s objetivos de UML son muchos, pero se pueden sintetizar sus funciones:

UML permite expresar de una forma gráfica un sistema de forma que otro lo puede entender.

UML permite especificar cuáles son las características de un siconstrucción. Significa construir modelos:

Precisos (correctos, coherentes) No ambiguos (formales) Completos (enlace entre distintas vistas)

UML cubre la especificación de todas las decisiones de (conceptual y especificación)

ue deben realizarse en un sistema con gran cantidad de software.

Cotizacion

Curso: Análisis de Sistemas


leer los modelos, pero no dice cómo crearlos. Esto último es el objetivo de

orma que otro lo puede entender.

UML permite especificar cuáles son las características de un sistema antes de su


• Construir: A partir de los modelos especifica-dos se pueden construir los sistemas diseñados.

� UML NO es un lenguaje de programación visual, pero sus modelos pueden traducirse a gran variedad de lenguajes de programación (Java, C++ o VB)

� Rational Rose y Sparx EA poseen facilidades para la ingeniería directa e inversa a determinados lenguajes y sistemas de componentes

� El mayor nivel de abstracción para modelar facilita la construcción de la arquitectura global del sistema, así como el diseño detallado de las partes de un proyecto y su futura implementación

• Documentar: Los propios elementos gráficos sirven como documentación del sistema desarrollado que pueden servir para su futura revisión.

� Un producto software no es únicamente el código ejecutable final � El modelo de la aplicación documenta ésta para:

- Mejorar la comprensión del código - Futuras ampliaciones - Modificaciones y corrección de errores - Realización de pruebas de funcionamiento - Migración a otras plataformas o selección de un nuevo lenguaje de programación


¿Qué no es UML?

1- UML NO es un método: “proceso disciplinado para generar un conjunto de modelos que describen varios aspectos de un sistema software en desarrollo, utilizando una notación bien definida” [Booch99]

2- UML NO es una metodología: “colección de métodos a lo largo del ciclo de vida del desarrollo de software unificados por alguna aproximación general” [Booch99].

3- El LENGUAJE UML NO es un proceso de desarrollo software: “conjunto de actividades necesarias para transformar los requisitos de un usuario en un sistema software” [Jacobson99].

4- UML no es una técnica de desarrollo de SW. 5- UML no es una herramienta CASE. 6- UML no es un lenguaje de programación.

¿Qué Conforma un Modelo de UML?

Aunque UML está pensado para modelar sistemas complejos con gran cantidad de software, el lenguaje es los suficientemente expresivo como para modelar sistemas que no son informáticos, como flujos de trabajo (workflow) en una empresa, diseño de la estructura de una organización y por supuesto, en el diseño de hardware.

Un modelo UML está compuesto por tres clases de bloques de construcción:

• Elementos: Los elementos son abstracciones de cosas reales o ficticias (objetos, acciones, etc.)

• Relaciones: relacionan los elementos entre sí.

• Diagramas: Son colecciones de elementos con sus relaciones. Un diagrama es la representación gráfica de un conjunto de elementos con sus relaciones. En concreto, un diagrama ofrece una vista del sistema a modelar. Para poder representar correctamente un sistema, UML ofrece una amplia variedad de diagramas para visualizar el sistema desde varias perspectivas.

Caso de Uso: Consulta de usuarios.

Actor: usuario

Pre condición: El adm ha consultado el registro de los usuarios.

Pos Condición: Consultar la lista de usuarios.

FLUJO DE TRABAJO

ACTOR

1. En este caso

comienza cuando

ingresa los datos a

consultar por login.

2. Salir de la consulta.

SISTEMA

1. Abre el formulario de

consultar usuarios.

2. Salir de la consulta de

usuarios.


Gestionar Horarios

(from Casos de Uso de Negocio)Sistema Horarios

(from Actores del Negocio)

Gestionar Registro de Docentes

(from Casos de Uso de Negocio)

Gestionar Dictado Prof esor


Profesor


Gestion Estadistica de horario


Gestionar Cursos


Jefe Carreras


Pre-Matricular


Gestionar Matricula


Gestionar Retiro/cambio


Alumno.


Elementos

Relaciones

Diagrama


Diagramas en UML Un diagrama es la representación gráfica de un conjunto de elementos, visualizando la mayoría de las veces como un grafo conexo de nodos (elementos) y arcos (relaciones). Los diagramas se dibujan para visualizar el sistema desde diferentes perspectivas, de forma que un diagrama es una proyección de un sistema. En teoría un diagrama puede contener cualquier combinación de elementos y relaciones, sin embargo en la práctica solo surge un peque no número de combinaciones:

• Diagrama de clases. • Diagrama de objetos. • Diagrama de casos de uso. • Diagrama de secuencia. • Diagrama de colaboración. • Diagrama de estados. • Diagrama de actividades. • Diagrama de componentes. • Diagrama de despliegue.

En OMG UML 2.0 se definen una serie de diagramas adicionales a los establecidos en OMG UML 1.x. El conjunto de diagramas se encuentra organizado en torno a dos categorías: diagramas estructurales (representados en verdes) y diagramas dinámicos o de comportamiento (representados en celeste). Los diferentes diagramas son indicados en la figura siguiente:

Como se puede notar al comparar las dos figuras anteriores, el diagrama de colaboración de OMG UML 1.x se ha transformado en el Diagrama de Comunicación en OMG UML 2.0. Adicionalmente se incorporan los diagramas siguientes:

• Diagrama de Estructura Compuesta. • Diagrama General de Interacción. • Diagramas de Tiempos. • Diagrama de Comunicación.

Herramientas

• Rational Rose 2003 • ArgoUML • Poseidon • Visual Paradigm • MonoUML • Altova UML


Metodología RUP (Proceso Unificado Rational)

Historia de RUP

El Proceso Unificado es el resultado de tres décadas de desarrollo y uso práctico. Su desarrollo como producto representa la unión de distintas metodologías, parte del Proceso Objectory (1987) pasando por el Proceso Objectory de Rational (1997) hasta el Proceso Unificado de Rational (1998).

Como primer paso para el alumbramiento del Proceso Unificado nos remontaremos a 1967 con los logros conseguidos por Ericsson, quién planteó modelar el sistema entero como un conjunto de bloques interconectados para ensamblarlos después en subsistemas de más alto nivel, haciendo que el sistema sea más manejable. Los bloques eran identificados estudiando los denominados “casos de negocio” hoy conocidos como casos de uso.

En esencia, el método de Ericsson es similar al que actualmente conocemos como desarrollo basado en componentes propuesto por Ivar Jacobson.

En 1987 Ivar Jacobson, dejó la empresa Ericsson y fundó Objectory AB, desarrollando el Proceso Objectory (Object Factory – fábrica de objetos). Este proceso fue desarrollado hasta la versión 3.8 en 1995. Su principal característica es que el propio proceso era un producto de ingeniería. La arquitectura que conduce a los desarrolladores e informa a los usuarios comienza a destacar. Los flujos de trabajo sucesivos se representaron en una serie de modelos: requisitos-casos de uso, análisis, diseño, implementación y prueba. La trazabilidad se convirtió en un prerrequisito del desarrollo dirigido por casos de uso.

Aparece el concepto de “caso de uso” presentado en la conferencia OOPLSA de 1987.

En 1995 Rational Software Corporation compra Objectory AB. Rational ya desde 1981 se había centrado en el diseño de procesos de desarrollo de software haciendo énfasis en la arquitectura y el desarrollo iterativo (definiéndose las fases del proceso: comienzo, elaboración, construcción y transición). La arquitectura se representaba con cuatro vistas: vista lógica, vista de procesos, vista física, vista de desarrollo y una vista adicional que ilustraba las vistas anteriores mediante casos de uso o escenarios.

El planteamiento de tener un conjunto de vistas se diferencia de la idea de meter todo en un único tipo de diagrama, facilitando así los objetivos de usuarios y desarrolladores.

El Proceso Objectory de Rational 4.1 (1995-1997) toma el relevo del Proceso Objectory 3.8. En este nuevo proceso se desarrolla una definición precisa de la arquitectura y se amplía, incorporándose las fases, el desarrollo iterativo, pasando de ser un concepto general a ser un método dirigido por los riesgos que consideraba la arquitectura en primer lugar.

En junio de 1998 Rational lanza una nueva versión de su producto con el nombre de Proceso Unificado de Rational 5.0.

En aquellos momentos, UML estaba en fase de desarrollo y se incorporó como el lenguaje de modelado del Proceso Objectory de Rational y del nuevo Proceso Unificado.


Características Principales

1- Guiado/Manejado/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. • Todos los casos de uso juntos constituyen el modelo de casos de uso. • Los casos de uso también guían el proceso de desarrollo (diseño, implementación, y prueba). Basándose en los casos de uso los desarrolladores crean una serie de modelos de diseño e implementación que llevan a cabo los casos de uso. De este modo los casos de uso no solo inician el proceso de desarrollo sino que le proporcionan un hilo conductor, avanza a través de una serie de flujos de trabajo que parten de los casos de uso. a- El Modelo de Casos de Uso representa los requisi tos

funcionales: El objetivo de esta fase es determinar los requerimientos del sistema. Los requerimientos funcionales son plasmados a través de casos de uso en un Modelo de Casos de Uso.

El modelo de casos de uso ayuda al cliente, a los usuarios, y a los desarrolladores a llegar a un acuerdo sobre cómo utilizar el sistema.

b- Creación del Modelo de Análisis a partir de los Casos de Uso: En él, se describen un conjunto de Clases del Análisis que se utilizan para realizar una descripción abstracta de la realización de los casos de uso del modelo de casos de uso. Las clases del análisis luego evolucionan hacia otras clases más detalladas en el Modelo del Diseño.

c- Creación del Modelo de Diseño: El modelo de diseño se crea tomando el modelo de análisis como entrada principal (cuando este fue creado), y se lo adapta a un entorno de implementación particular.

d- Creación del Modelo de Implementación a partir del Modelo de Diseño: El modelo de implementación está formado por componentes, que incluyen todos los ejecutables (Ej. ActiveX, JavaBeans, .exe), y otro tipo de componentes como ser componentes de fichero (código fuente, shell scripts, etc.), componentes de tabla (elementos de base de datos), etc.

e- Prueba de Casos de Uso: Durante la prueba, verificamos que el sistema implementa correctamente su especificación. El modelo de prueba está compuesto por: casos de prueba y procedimientos de prueba.


2- Centrado en Arquitectura: La arquitectura de un sistema software se describe mediante diferentes vistas del sistema en construcción. El concepto de arquitectura software incluye los aspectos estáticos y dinámicos más significativos del sistema. La arquitectura es una vista del diseño completo con las características más importantes resaltadas, dejando los detalles de lado. Arquitectura : Conjunto de decisiones significativas acerca de la organización de un sistema software, la selección de los elementos estructurales a partir de los cuales se compone el sistema, las interfaces entre ellos, su comportamiento, sus colaboraciones, y su composición. Los casos de uso y la arquitectura están profundamente relacionados. Los casos de uso deben encajar en la arquitectura, y a su vez la arquitectura debe permitir el desarrollo de todos los casos de uso requeridos, actualmente y a futuro. El arquitecto desarrolla la forma o arquitectura a partir de la comprensión de un conjunto reducido de casos de uso fundamentales o críticos (usualmente no más del 10 % del total). En forma resumida, podemos decir que el arquitecto: a- Crea un esquema en borrador de la arquitectura comenzando por la parte no específica de los casos de

uso (por ejemplo la plataforma) pero con una comprensión general de los casos de uso fundamentales. b- A continuación, trabaja con un conjunto de casos de uso clave o fundamental. Cada caso de uso es

especificado en detalle y realizado en términos de subsistemas, clases, y componentes. c- A medida que los casos de uso se especifican y maduran, se descubre más de la arquitectura, y esto a

su vez lleva a la maduración de más casos de uso. Importancia y necesidad de una arquitectura Se necesita una arquitectura para: a- Comprender el sistema b- Organizar el desarrollo c- Fomentar la reutilización d- Hacer evolucionar el sistema

3- Un Proceso Iteractivo e Incremental: Es práctico dividir el

esfuerzo de desarrollo de un proyecto de software en partes más pequeñas o mini proyectos. Cada mini proyecto es una iteración que resulta en un incremento. Las iteraciones hace referencia a pasos en el flujo de trabajo, y los incrementos acrecimientos en el producto. Las iteraciones deben estar controladas. Esto significa que deben seleccionarse y ejecutarse de una forma planificada. Los desarrolladores basan la selección de lo que implementarán en cada iteración en dos cosas: el conjunto de casos de uso que amplían la funcionalidad, y en los riesgos más importantes que deben mitigarse. En cada iteración los desarrolladores identifican y especifican los casos de uso relevantes, crean un diseño utilizando la arquitectura seleccionada como guía, para implementar dichos casos de uso. Si la iteración cumple sus objetivos, se continúa con la próxima. Si no deben revisarse las decisiones previas y probar un nuevo enfoque. Beneficios del enfoque iterativo - La iteración controlada reduce el riesgo a los costes de un solo incremento. - Reduce el riesgo de retrasos en el calendario atacando los riesgos más importantes primero. - Acelera el desarrollo. Los trabajadores trabajan de manera más eficiente al obtener resultados a corto plazo. - Tiene un enfoque más realista al reconocer que los requisitos no pueden definirse completamente al principio.

4- Desarrollo Basado en Componentes: La creación de sistemas intensivos en software requiere dividir el sistema en componentes con interfaces bien definidas, que posteriormente serán ensamblados para generar el sistema


5- Utilización de un único Lenguaje de Modelamiento : UML es adoptado como único lenguaje de modelamiento para el desarrollo de todos los modelos.

6- Proceso Integrado: Se establece una arquitectura que abarque los ciclos, fases, flujos de trabajo, mitigación de riesgos, control de calidad, gestión del proyecto y control de configuración; el proceso unificado establece una estructura que integra todas estas facetas.

Ciclo de vida del Proceso Unificado

El Proceso Unificado se repite a lo largo de una serie de ciclos que constituyen la vida de un sistema. Cada ciclo constituye una versión del sistema. Fases: Cada ciclo constas de cuatro fases: inicio, elaboración, construcción, y transición.

Cada fase se subdivide en iteraciones. En cada iteración se desarrolla en secuencia un conjunto de disciplinas o flujos de trabajos.

Disciplinas: Cada disciplina es un conjunto de actividades relacionadas (flujos de trabajo) vinculadas a un área específica dentro del proyecto total. Las más importantes son: Requerimientos, Análisis, Diseño, Codificación, y Prueba. El agrupamiento de actividades en disciplinas es principalmente una ayuda para comprender el proyecto desde la visión tradicional en cascada. Cada disciplina está asociada con un conjunto de modelos que se desarrollan. Estos modelos están compuestos por artefactos. Los artefactos más importantes son los modelos que cada disciplina realiza: modelo de casos de uso, modelo de diseño, modelo de implementación, y modelo de prueba.

El Proceso Unificado consiste en una serie de disciplinas o flujos de trabajo que van desde los requisitos hasta las pruebas. Los flujos de trabajo desarrollan modelos desde el modelo de casos de uso hasta el modelo de pruebas.


Modelos del Proceso Unificado Actividades del RUP

a- Modelo de Negocio b- Modelo de Caso de Uso (Modelo de Requisitos) Modelado de Negocio c- Modelo de Análisis Análisis de Requisitos d- Modelo de Diseño Análisis y Diseño e- Modelo de Despliegue Implementación f- Modelo de Implementación Test g- Modelo de Prueba Distribución

Gestión de Configuración y Cambios Gestión del Proyecto Gestión del Entorno

Fases de la Metodología RUP

Fase de Inicio: Durante la fase de inicio se desarrolla una 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 más importantes? • ¿Cómo podría ser la mejor arquitectura del sistema? • ¿Cuál es el plan del proyecto y cuanto costará desarrollar el producto?

En esta fase se identifican y priorizan los riesgos más importantes. El objetivo de esta fase es ayudar al equipo de proyecto a decidir cuáles son los verdaderos objetivos del proyecto. Las iteraciones exploran diferentes soluciones posibles, y diferentes arquitecturas posibles. Puede que todo el trabajo físico realizado en esta fase sea descartado. Lo único que normalmente sobrevive a la fase de inicio es el incremento del conocimiento en el equipo. Los artefactos que típicamente sobreviven a esta fase son: - Un enunciado de los mayores requerimientos planteados generalmente como casos de uso. - Un boceto inicial de la arquitectura. - Una descripción de los objetivos del proyecto. - Una versión muy preliminar del plan del proyecto. - Un modelo del negocio. Este hito es alcanzado cuando el equipo de proyectos y los stakeholders llegan a un acuerdo sobre: - Cuál es el conjunto de necesidades del negocio, y que conjunto de funciones satisfacen estas necesidades. - Una planificación preliminar de iteraciones. - Una arquitectura preliminar. Debe poder responderse las siguientes cuestiones: - ¿Se ha determinado con claridad el ámbito del sistema? ¿Se ha determinado lo que va a estar dentro del sistema y fuera del sistema? - ¿Se ha llegado a un acuerdo con todas las personas involucradas (stakeholders) sobre los requisitos funcionales del sistema? - ¿Se vislumbra una arquitectura que pueda soportar estas características? - ¿Se identifican los riesgos críticos? ¿Se prevé forma de mitigarlos? - ¿El uso del producto justifica la relación costo-beneficio? - ¿Es factible para su organización llevar adelante el proyecto? - ¿Están los inversores de acuerdo con los objetivos?


Fase de Elaboración: Durante la fase de elaboración se especifican en detalle la mayoría de los casos de uso del producto y se diseña la arquitectura. Las iteraciones en la fase de elaboración: - Establecen una firme comprensión del problema a solucionar. - Establece la fundación arquitectural para el software. - 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. En esta fase se construyen típicamente los siguientes artefactos: - El cuerpo básico del sw en la forma de un prototipo arquitectural. - Casos de prueba - La mayoría de los casos de uso (80%) que describen la funcionalidad del sistema. - Un plan detallado para las siguientes iteraciones. Este hito se alcanza cuando el equipo de desarrollo y los stakeholders llegan a un acuerdo sobre: - Los casos de uso que describen la funcionalidad del sistema. - La línea base de la arquitectura - Los mayores riesgos han sido mitigados - El plan del proyecto Al alcanzar este hito debe poder responderse a preguntas como: - ¿Se ha creado una línea base de la arquitectura? ¿Es adaptable y robusta? ¿Puede evolucionar? - ¿Se han identificado y mitigado los riesgos más graves? - ¿Se ha desarrollado un plan del proyecto hasta el nivel necesario para respaldar una agenda, costes, y calidad realistas? - ¿Proporciona el proyecto, una adecuada recuperación de la inversión? - ¿Se ha obtenido la aprobación de los inversores? Fase de Construcción: Durante la fase de construcción se crea el producto. La línea base de la arquitectura crece hasta convertirse en el sistema completo. Al final de esta fase, el producto contiene todos los casos de uso implementados, sin embargo puede que no esté libre de defectos. Los artefactos producidos durante esta fase son: - El sistema software - Los casos de prueba - Los manuales de usuario Este hito se alcanza cuando el equipo de desarrollo y los stakeholders llegan a un acuerdo sobre: - El producto es estable para ser usado - El producto provee alguna funcionalidad de valor - Todas las partes están listas para comenzar la transición Fase de Transición: La fase de transición cubre el período durante el cual el producto se convierte en la versión beta. Las iteraciones en esta fase continúan agregando características al sw. Sin embargo las características se agregan a un sistema que el usuario se encuentra utilizando activamente. Los artefactos construidos en esta fase son los mismos que en la fase de construcción. El equipo se encuentra ocupado fundamentalmente en corregir y extender la funcionalidad del sistema desarrollado en la fase anterior. La fase de transición finaliza con el hito de Lanzamiento del Producto. Este hito se alcanza cuando el equipo de desarrollo y los stakeholders llegan a un acuerdo sobre: - Se han alcanzado los objetivos fijados en la fase de Inicio. - El usuario está satisfecho.

separata uml y rup

Documents