1.
IT 7-1 Valeria Espinoza Rodríguez Ana Patricia Valencia Montaño<br />

2.
Índice<br />Antecedentes <br />Historia de RUP<br />Metodología de desarrollo aplicada<br />Disciplinas y fases<br />Ventajas<br />Desventajas<br />Características de la fase de transición<br />Planeando las fases<br />Dimensiones del RUP<br />National Rose<br />

3.
RUP<br />

4.
Antecedentes<br />El antecedente más importante se ubica en 1 967 con la Metodología Ericsson (Ericsson Approach) elaborada por Ivar Jacobson , una aproximación de desarrollo lo basada en componentes, que introdujo el concepto de Caso de Uso. Entre los años de 1987 a 1955 Jacobson fundó la compañía Objectory AB y lanza el proceso de desarrollo Objectory (abreviación de ObjectFactory).<br />

5.
Historia de RUP<br /> Posteriormente en 1995 Rational Software Corporation adquiere Objectory AB y entre 1995 y 1997 se desarrolla Rational Objectory Procesos (ROP) a partir de Objectory 3.8 y del Enfoque Rational (RationalApproach) adoptando UML como lengua je de modelado.<br /> Desde ese entonces y a la cabeza de Grady Booch , Ivar Jacobson y James Rumbaugh , Rational Software desarrolló e incorporó diversos elementos para expandir ROP, destacándose especialmente el flujo de trabajo conocido como modelado del negocio. En junio del 1998 se lanza RationalUnifiedProcess. <br />

6.
Metodología de desarrollo aplicada<br /> Las siglas RUP en ingles significa RationalUnifiedProcess (ProcesoUnificado de Rational) es un producto del proceso de ingeniería de software que proporciona un enfoque disciplinado para asignar tareas y responsabilidades dentro de una organización del desarrollo.<br /> Su meta es asegurar la producción del software de alta calidad que resuelve las necesidades de los usuarios dentro de un presupuesto y tiempo establecidos.<br />

7.
RUP<br />Es el Marco de referencia de ingeniería de software para definir, implementar y distribuir aplicaciones de software sus características principales<br /><ul><li>Utiliza UML.

8.
Gramática bien definida.

9.
Terminología usada para las definiciones de los procesos.</li></li></ul><li>Disciplinas y fases<br />1.- Modelado de negocio.<br />2.- Requerimientos.<br />3.- Análisis y diseño.<br />4.- Implementación.<br />5.- Pruebas.<br />6.- Distribución.<br />7.- Administración de proyectos.<br />8.- Administración de cambios y configuración.<br />9.- Ambiente.<br />

10.
Ejemplo<br />Pedir una pizza a domicilio para enfatizar la implementación de RUP<br />

11.
Fase de iniciación<br />En esta fase se especifican los requerimientos, se definen los casos de negocio y se empieza a describir el alcance actores primarios que interactuaran con el software y factores críticos de la entrega del proyecto.<br />Al pedir una pizza el cliente llama al operador y realiza una orden esto sería el requerimiento( quiere una pizza de peperoni).<br />

12.
Fase de elaboración<br />En esta fase se analiza el dominio del diseño de la aplicación y establecer las fases de la arquitectura del software es la más importante en la entrega de un proyecto y una de la de más alto riesgo por lo critico de la toma de decisiones de la arquitectura del diseño.<br />Una vez recibida la orden el chef piensa los ingredientes que utilizara y como la va a cocinar en el horno y a cuentos grados de temperatura.<br />

13.
Fase de construcción<br />Se compone de cada desarrollo de la aplicación.<br />El Chef sigue los pasos previamente establecidos une todos los ingredientes y cocina la pizza.<br />

14.
Fase de transición<br />Se centran la actividades requeridas para colocar el software en las manos de los usuarios finales incluye varias interacciones de archivos beta y corrección de errores y mejoras.<br />El producto es empaquetado y llevado a su destino para ser entregado al cliente.<br />

15.
Fase de evolución<br /> Son actividades asociadas con implementación de nuevas versiones de un producto mas maduro.<br /> Cada ciclo de evolución lleva las fases <br /><ul><li>Iniciación

16.
Elaboración

17.
Construcción

18.
Transición</li></li></ul><li>La pizzería para estar siempre actualizada evalúa sus estadísticas y se da cuenta de que la piza de queso es la más pedidas y decide incluir una pizza doble queso, introduce un nuevo requerimiento y se vuelven a seguir todos los pasos para obtener el nuevo producto.<br />

19.
Ventajas<br /> Al basarte en este marco de referencia las VENTAJAS que obtenemos son:<br /> RUP ha madurado con el tiempo: el uso <br />UML hace que el software se apegue a estándares de la industria<br />Adaptable a la organización<br />Herramientas de buena implementación <br />Define actividades, roles y responsabilidades <br /> desde jefe de proyecto hasta los analistas y <br /> desde desarrolladores y equipos de prueba<br />

20.
Desventajas<br />Sistemas híbridos: en empresas que hay organismos híbridos y no son adáptales a cualquier empresa UML no es efectivo.<br />Características avanzadas la sintaxis de modelación requiere de notaciones que no poseen los desarrolladores promedio.<br />Costosa comprar las herramientas y capacitar al equipo requiere de tiempo y consultoría. <br />Limitaciones en ciclo de vida no lo contempla completo.<br />

21.
Cada paso con las cuatro fases produce una generación del software. <br /> A menos que el producto "muera", se desarrollará nuevamente repitiendo la misma secuencia las fases de iniciación, elaboración, construcción y transición, pero con diversos énfasis cada fase.<br />

22.
Características de la fase de transición<br />Se incluyen tareas de marketing, empaquetado atractivo, instalación, configuración, entrenamiento, soporte, mantenimiento, etc.<br /> Los manuales de usuario se completan y refinan con la información anterior estas tareas se realizan también en iteraciones.<br /> Todas las fases no son idénticas en términos de tiempo y esfuerzo.<br /> Aunque esto varía considerablemente dependiendo del proyecto, un ciclo de desarrollo inicial típico para un proyecto de tamaño mediano debe anticipar la distribución siguiente el esfuerzo y horario.<br />

23.
Fases<br />

24.
Planeando las fases<br />El ciclo de vida consiste en una serie de ciclos, cada uno de los cuales.<br />Produce una nueva versión del producto, cada ciclo está compuesto por fases y.<br />Cada una de estas fases está compuesta por un número de iteraciones.<br />

25.
Elaboración<br />Tanto la funcionalidad como el dominio del problema se estudian en profundidad.<br /> Se define una arquitectura básica, se planifica el proyecto considerando recursos disponibles.<br />

26.
Construcción<br />El producto se desarrolla a través de iteraciones donde cada iteración e involucra tareas de análisis, diseño e implementación.<br /> Las fases de estudio y análisis sólo dieron una arquitectura básica que es aquí refinada de manera incremental conforme se construye (se permiten cambios en la estructura).<br /> Gran parte del trabajo es programación y pruebas<br /> Se documenta tanto el sistema construido como el manejo del mismo Esta fase proporciona un producto construido junto con la documentación.<br />

27.
Requerimientos<br />Esta disciplina tiene como objetivos establecer lo que el sistema debe.<br />Hacer (especificar requisitos), definir los límites del sistema, y una interfaz de.<br />Usuario, realizar una estimación del costo y tiempo de desarrollo. <br />

28.
En un ciclo evolutivo, las fases de concepción y elaboración serían considerablemente más pequeñas. <br />Algunas herramientas que pueden automatizar una cierta porción del esfuerzo de la fase de Construcción pueden atenuar esto, haciendo que la fase de construcción sea mucho más pequeña<br />que las fases de concepción y elaboración juntas. Este es precisamente el objetivo del trabajo.<br />

29.
Los ciclos evolutivos pueden ser iniciados por las mejoras sugeridas por el usuario, cambios en el contexto del usuario, cambios en la tecnología subyacente, reacción a la competición, etcétera. <br />Los ciclos evolutivos tienen típicamente fases de concepción y elaboración mucho más cortas, puesto que la definición y la arquitectura básicas del producto son determinadas por los ciclos de desarrollo anteriores. <br />Las excepciones a esta regla son los ciclos evolutivos en los cuales ocurre o surge un producto significativo o una redefinición arquitectónica.<br />

30.

31.
El RUP tiene dos dimensiones<br />El eje horizontal representa tiempo y demuestra los aspectos del ciclo de vida del proceso.<br /> El eje vertical representa las disciplinas, que agrupan actividades<br /> Definidas lógicamente por la naturaleza.<br /> La primera dimensión representa el aspecto dinámico del proceso y se<br /> Expresa en términos de fases, de iteraciones, y la finalización de las fases.<br /> La segunda dimensión representa el aspecto estático del proceso: cómo se describe en términos de componentes de proceso, las disciplinas, las actividades, los flujos de trabajo, los artefactos, y los roles.<br />

32.
National Rose<br />Herramienta Facilitadora de implementación<br />

33.
National Rose<br />Herramienta Facilitadora de implementación<br />

34.
Es una herramienta de modelado visual para el análisis y diseño de sistemas basados en objetos.<br />Es utilizada para modelar un sistema antes de proceder a construirlo.<br />Cubre todo el ciclo de vida de un proyecto:<br />

35.
Interfaz de Rational Rose<br />

36.
Bibliografía<br />http://www.youtube.com/watch?v=bV8MgbfOO5g&feature=related<br />Adobe Acrobat Document/aplicaciónRup.pdf<br />Copyright.2003,Rational Software Corporation<br />http://www.slideshare.net/vivi_jocadi/rational-rose<br />

37.
Nuestro Libro<br />Libro<br />

38.
Nuestro Blog<br />http://rupit71.wordpress.com<br />