Prof.

: Godofredo Ayquipa Cordova

Curso: Anlisis 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 compaa Rational Software fundada por Grady Booch (dos reputados investigadores en el rea de metodologa del software). El objetivo de ambos era unificar dos mtodos que haban desarrollado: el mtodo 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. Adems, este lenguaje se abri a la colaboracin de otras empresas para que aportaran sus ideas. Todas estas colaboraciones condujeron a la definicin de la primera versin de UML. Qu es UML? El UML (Lenguaje Unificado de Modelado) es una de las herramientas ms emocionantes en el mundo actual del desarrollo de sistemas. Esto se debe a que permite a los creadores de sistemas generar diseos que capturen sus ideas en una forma convencional y fcil de comprender para comunicarlas a otras personas. UML se ha convertido en ese estndar tan ansiado para representar y modelar la informacin con la que se trabaja en las fases de anlisis y, especialmente, de diseo. UML tiene una notacin grfica muy expresiva que permite representar en mayor o menor medida todas las fases de un proyecto informtico: desde el anlisis con los casos de uso, el diseo con los diagramas de clases, objetos, etc., hasta la implementacin y configuracin con los diagramas de despliegue.

Lenguaje
El lenguaje grfico de UML facilita la comunicacin entre los distintos miembros de un proyecto. Permite elevar el nivel de abstraccin para obtener una visin ms general de una parte de un proyecto UML es ms que un montn de smbolos grficos; detrs de cada smbolo hay una semntica bien definida. Por lo tanto, una herramienta puede interpretar un modelo sin ambigedad

Modelado Un modelo es una simplificacin de la realidad [Booch99]. Por qu es necesario modelar? Los modelos nos ayudan a visualizar cmo es o queremos que sea un sistema (abstraccin). Los modelos nos permiten especificar la estructura y comportamiento de un sistema. Los modelos nos proporcionan plantillas que nos guan en la construccin 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 grfico. Adems, se ha llegado a una solucin unificada basada en lo mejor que haba hasta el momento, lo cual lo hace todava ms excepcional. UML define una notacin: material grfico para representar cada una de las vistas del modelo; es la sintaxis del lenguaje UML.

Prof.: Godofredo Ayquipa Cordova

Curso: Anlisis de Sistemas

Evolucin 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 propsitos, se conform un consorcio del UML. Entre los miembros se encuentran DEC, Hewlett-Packard, Intellicorp, Microsoft, Oracle, Texas Instruments y Rational. En 1997 el consorcio produjo la versin 1 .O del UML y lo puso a consideracin del OMG (Gmpo de administracin de objetos) como respuesta a su propuesta para un lenguaje de modelado estndar. En noviembre de 1997 UML es aprobado por la OMG como un estndar con la versin UML 1.1 UML se ha convertido en ese estndar tan ansiado para representar y modelar la informacin con la que se trabaja en las fases de anlisis y, especialmente, de diseo.

Objetivos de UML UML es ante todo un lenguaje. Un lenguaje proporciona un vocabulario y unas reglas para permitir una comunicacin. En este caso, este lenguaje se centra en la representacin grfica de un sistema. Este lenguaje nos indica cmo crear y leer los modelos, pero no dice cmo crearlos. Esto ltimo es el objetivo de las metodologas de desarrollo. Los objetivos de UML son muchos, pero se pueden sintetizar sus funciones: s Visualizar: UML permite expresar de una forma grfica un sistema de forma que otro lo puede entender. forma

C otizacion

Cliente

Especificar: UML permite especificar cules son las caractersticas de un sistema antes de su si construccin. Significa construir modelos: Precisos (correctos, coherentes) No ambiguos (formales) Completos (enlace entre distintas vistas) UML cubre la especificacin de todas las decisiones de Anlisis (conceptual y especificacin) Diseo Implementacin que deben realizarse en un sistema con gran cantidad de software. ue

Prof.: Godofredo Ayquipa Cordova

Curso: Anlisis de Sistemas

Construir: A partir de los modelos especifica-dos se pueden construir los sistemas diseados. UML NO es un lenguaje de programacin visual, pero sus modelos pueden traducirse a gran variedad de lenguajes de programacin (Java, C++ o VB) Rational Rose y Sparx EA poseen facilidades para la ingeniera directa e inversa a determinados lenguajes y sistemas de componentes El mayor nivel de abstraccin para modelar facilita la construccin de la arquitectura global del sistema, as como el diseo detallado de las partes de un proyecto y su futura implementacin

Documentar: Los propios elementos grficos sirven como documentacin del sistema desarrollado que pueden servir para su futura revisin. Un producto software no es nicamente el cdigo ejecutable final El modelo de la aplicacin documenta sta para: Mejorar la comprensin del cdigo Futuras ampliaciones Modificaciones y correccin de errores Realizacin de pruebas de funcionamiento Migracin a otras plataformas o seleccin de un nuevo lenguaje de programacin

Prof.: Godofredo Ayquipa Cordova

Curso: Anlisis de Sistemas

Caso de Uso: Consulta de usuarios. Actor: usuario Pre condicin: El adm ha consultado el registro de los usuarios. Pos Condicin: 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. Qu no es UML? 1- UML NO es un mtodo: proceso disciplinado para generar un conjunto de modelos que describen varios aspectos de un sistema software en desarrollo, utilizando una notacin bien definida [Booch99] 2- UML NO es una metodologa: coleccin de mtodos a lo largo del ciclo de vida del desarrollo de software unificados por alguna aproximacin 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 tcnica de desarrollo de SW. 5- UML no es una herramienta CASE. 6- UML no es un lenguaje de programacin.

SISTEMA
1. Abre el formulario de consultar usuarios. 2. Salir de la consulta de usuarios.

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 informticos, como flujos de trabajo (workflow) en una empresa, diseo de la estructura de una organizacin y por supuesto, en el diseo de hardware. Un modelo UML est compuesto por tres clases de bloques de construccin: 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 representacin grfica 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.

Prof.: Godofredo Ayquipa Cordova

Curso: Anlisis de Sistemas

Relaciones

Pre-Matricular Alumno.
(from Actores del Negocio) (fromCasos d Uso deNegocio) e

Gestion Estadistica de horario

(from Casos de Uso de Negocio)

Diagrama
Jef e Carreras
(from Actores del Negocio)

Gestionar Matricula
(fr omCasos d Uso deNegoci o) e

Gestionar Cursos
(from Casos de Uso de Negocio)

Gestionar Retiro/cambio
(from Casos de Uso de Negocio)

Gestionar Horarios
(from Casos de Uso de Negocio)

Sistema Horarios
(from Actores del Negocio)

Gestionar Registro de Docentes

(from Casos de Uso de Negocio)

Prof esor
(from Actores del Negocio)

Gestionar Dictado Prof esor

(from Casos de Uso de Negocio)

Elementos

Prof.: Godofredo Ayquipa Cordova

Curso: Anlisis de Sistemas

Diagramas en UML Un diagrama es la representacin grfica de un conjunto de elementos, visualizando la mayora 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 proyeccin de un sistema. En teora un diagrama puede contener cualquier combinacin de elementos y relaciones, sin embargo en la prctica solo surge un peque no nmero de combinaciones: Diagrama de clases. Diagrama de objetos. Diagrama de casos de uso. Diagrama de secuencia. Diagrama de colaboracin. 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 categoras: diagramas estructurales (representados en verdes) y diagramas dinmicos 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 colaboracin de OMG UML 1.x se ha transformado en el Diagrama de Comunicacin en OMG UML 2.0. Adicionalmente se incorporan los diagramas siguientes: Diagrama de Estructura Compuesta. Diagrama General de Interaccin. Diagramas de Tiempos. Diagrama de Comunicacin.

Herramientas Rational Rose 2003 ArgoUML Poseidon Visual Paradigm MonoUML Altova UML

Prof.: Godofredo Ayquipa Cordova

Curso: Anlisis de Sistemas

Metodologa RUP (Proceso Unificado Rational) Historia de RUP El Proceso Unificado es el resultado de tres dcadas de desarrollo y uso prctico. Su desarrollo como producto representa la unin de distintas metodologas, 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, quin plante modelar el sistema entero como un conjunto de bloques interconectados para ensamblarlos despus en subsistemas de ms alto nivel, haciendo que el sistema sea ms manejable. Los bloques eran identificados estudiando los denominados casos de negocio hoy conocidos como casos de uso. En esencia, el mtodo 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 fbrica de objetos). Este proceso fue desarrollado hasta la versin 3.8 en 1995. Su principal caracterstica es que el propio proceso era un producto de ingeniera. 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, anlisis, diseo, implementacin 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 haba centrado en el diseo de procesos de desarrollo de software haciendo nfasis en la arquitectura y el desarrollo iterativo (definindose las fases del proceso: comienzo, elaboracin, construccin y transicin). La arquitectura se representaba con cuatro vistas: vista lgica, vista de procesos, vista fsica, 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 definicin precisa de la arquitectura y se ampla, incorporndose las fases, el desarrollo iterativo, pasando de ser un concepto general a ser un mtodo dirigido por los riesgos que consideraba la arquitectura en primer lugar. En junio de 1998 Rational lanza una nueva versin 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.

Prof.: Godofredo Ayquipa Cordova

Curso: Anlisis de Sistemas

Caractersticas 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 tambin guan el proceso de desarrollo (diseo, implementacin, y prueba). Basndose en los casos de uso los desarrolladores crean una serie de modelos de diseo e implementacin 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 travs de una serie de flujos de trabajo que parten de los casos de uso.
a- El Modelo de Casos de Uso representa los requisitos funcionales: El objetivo de esta fase es determinar los requerimientos del sistema. Los requerimientos funcionales son plasmados a travs 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 cmo utilizar el sistema. b- Creacin del Modelo de Anlisis a partir de los Casos de Uso: En l, se describen un conjunto de Clases del Anlisis que se utilizan para realizar una descripcin abstracta de la realizacin de los casos de uso del modelo de casos de uso. Las clases del anlisis luego evolucionan hacia otras clases ms detalladas en el Modelo del Diseo. c- Creacin del Modelo de Diseo: El modelo de diseo se crea tomando el modelo de anlisis como entrada principal (cuando este fue creado), y se lo adapta a un entorno de implementacin particular. d- Creacin del Modelo de Implementacin a partir del Modelo de Diseo: El modelo de implementacin est formado por componentes, que incluyen todos los ejecutables (Ej. ActiveX, JavaBeans, .exe), y otro tipo de componentes como ser componentes de fichero (cdigo 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 especificacin. El modelo de prueba est compuesto por: casos de prueba y procedimientos de prueba.

Prof.: Godofredo Ayquipa Cordova

Curso: Anlisis de Sistemas

2- Centrado en Arquitectura: La arquitectura de un sistema software se describe mediante diferentes vistas del sistema en construccin. El concepto de arquitectura software incluye los aspectos estticos y dinmicos ms significativos del sistema. La arquitectura es una vista del diseo completo con las caractersticas ms importantes resaltadas, dejando los detalles de lado. Arquitectura: Conjunto de decisiones significativas acerca de la organizacin de un sistema software, la seleccin de los elementos estructurales a partir de los cuales se compone el sistema, las interfaces entre ellos, su comportamiento, sus colaboraciones, y su composicin. Los casos de uso y la arquitectura estn 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 comprensin de un conjunto reducido de casos de uso fundamentales o crticos (usualmente no ms 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 especfica de los casos de uso (por ejemplo la plataforma) pero con una comprensin general de los casos de uso fundamentales. b- A continuacin, trabaja con un conjunto de casos de uso clave o fundamental. Cada caso de uso es especificado en detalle y realizado en trminos de subsistemas, clases, y componentes. c- A medida que los casos de uso se especifican y maduran, se descubre ms de la arquitectura, y esto a su vez lleva a la maduracin de ms 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 reutilizacin d- Hacer evolucionar el sistema 3- Un Proceso Iteractivo e Incremental: Es prctico dividir el esfuerzo de desarrollo de un proyecto de software en partes ms pequeas o mini proyectos. Cada mini proyecto es una iteracin 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 seleccin de lo que implementarn en cada iteracin en dos cosas: el conjunto de casos de uso que amplan la funcionalidad, y en los riesgos ms importantes que deben mitigarse. En cada iteracin los desarrolladores identifican y especifican los casos de uso relevantes, crean un diseo utilizando la arquitectura seleccionada como gua, para implementar dichos casos de uso. Si la iteracin cumple sus objetivos, se contina con la prxima. Si no deben revisarse las decisiones previas y probar un nuevo enfoque. Beneficios del enfoque iterativo - La iteracin controlada reduce el riesgo a los costes de un solo incremento. - Reduce el riesgo de retrasos en el calendario atacando los riesgos ms importantes primero. - Acelera el desarrollo. Los trabajadores trabajan de manera ms eficiente al obtener resultados a corto plazo. - Tiene un enfoque ms realista al reconocer que los requisitos no pueden definirse completamente al principio. 4- Desarrollo Basado en Componentes: La creacin de sistemas intensivos en software requiere dividir el sistema en componentes con interfaces bien definidas, que posteriormente sern ensamblados para generar el sistema

Prof.: Godofredo Ayquipa Cordova

Curso: Anlisis de Sistemas

5- Utilizacin 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, mitigacin de riesgos, control de calidad, gestin del proyecto y control de configuracin; 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 versin del sistema. Fases: Cada ciclo constas de cuatro fases: inicio, elaboracin, construccin, y transicin. Cada fase se subdivide en iteraciones. En cada iteracin 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 especfica dentro del proyecto total. Las ms importantes son: Requerimientos, Anlisis, Diseo, Codificacin, y Prueba. El agrupamiento de actividades en disciplinas es principalmente una ayuda para comprender el proyecto desde la visin tradicional en cascada. Cada disciplina est asociada con un conjunto de modelos que se desarrollan. Estos modelos estn compuestos por artefactos. Los artefactos ms importantes son los modelos que cada disciplina realiza: modelo de casos de uso, modelo de diseo, modelo de implementacin, 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.

Prof.: Godofredo Ayquipa Cordova

Curso: Anlisis de Sistemas

Modelos del Proceso Unificado abcdefgModelo de Negocio Modelo de Caso de Uso (Modelo de Requisitos) Modelo de Anlisis Modelo de Diseo Modelo de Despliegue Modelo de Implementacin Modelo de Prueba

Actividades del RUP Modelado de Negocio Anlisis de Requisitos Anlisis y Diseo Implementacin Test Distribucin Gestin de Configuracin y Cambios Gestin del Proyecto Gestin del Entorno

Fases de la Metodologa RUP Fase de Inicio: Durante la fase de inicio se desarrolla una descripcin del producto final, y se presenta el anlisis del negocio. Esta fase responde las siguientes preguntas: Cules son las principales funciones del sistema para los usuarios ms importantes? Cmo podra ser la mejor arquitectura del sistema? Cul es el plan del proyecto y cuanto costar desarrollar el producto? En esta fase se identifican y priorizan los riesgos ms importantes. El objetivo de esta fase es ayudar al equipo de proyecto a decidir cules son los verdaderos objetivos del proyecto. Las iteraciones exploran diferentes soluciones posibles, y diferentes arquitecturas posibles. Puede que todo el trabajo fsico 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 tpicamente sobreviven a esta fase son: - Un enunciado de los mayores requerimientos planteados generalmente como casos de uso. - Un boceto inicial de la arquitectura. - Una descripcin de los objetivos del proyecto. - Una versin 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: - Cul es el conjunto de necesidades del negocio, y que conjunto de funciones satisfacen estas necesidades. - Una planificacin 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 caractersticas? - Se identifican los riesgos crticos? Se prev forma de mitigarlos? - El uso del producto justifica la relacin costo-beneficio? - Es factible para su organizacin llevar adelante el proyecto? - Estn los inversores de acuerdo con los objetivos?

Prof.: Godofredo Ayquipa Cordova

Curso: Anlisis de Sistemas

Fase de Elaboracin: Durante la fase de elaboracin se especifican en detalle la mayora de los casos de uso del producto y se disea la arquitectura. Las iteraciones en la fase de elaboracin: - Establecen una firme comprensin del problema a solucionar. - Establece la fundacin arquitectural para el software. - Establece un plan detallado para las siguientes iteraciones. - Elimina los mayores riesgos. El resultado de esta fase es la lnea base de la arquitectura. En esta fase se construyen tpicamente los siguientes artefactos: - El cuerpo bsico del sw en la forma de un prototipo arquitectural. - Casos de prueba - La mayora 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 lnea 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 lnea base de la arquitectura? Es adaptable y robusta? Puede evolucionar? - Se han identificado y mitigado los riesgos ms 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 recuperacin de la inversin? - Se ha obtenido la aprobacin de los inversores? Fase de Construccin: Durante la fase de construccin se crea el producto. La lnea 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 estn listas para comenzar la transicin Fase de Transicin: La fase de transicin cubre el perodo durante el cual el producto se convierte en la versin beta. Las iteraciones en esta fase continan agregando caractersticas al sw. Sin embargo las caractersticas 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 construccin. El equipo se encuentra ocupado fundamentalmente en corregir y extender la funcionalidad del sistema desarrollado en la fase anterior. La fase de transicin 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.