Rup

RUP RATIONAL UNIFIED PROCESS

EQUIPO 4 CERVNATES RODRIGUEZ JOSE DE JESUS GARCIA VAZQUES RAMIRO ALBERTO MORENO ESPINOZA EDUARDO DAVID ZACARIAS PADILLA LUIS JORGE

MODULO 2. - Rational Unified Process (RUP) 2.1 Ciclo de vida RUP 2.1.1 Fases e Iteraciones del RUP 2.1.2 Fase Inicio del RUP 2.1.3 Fase Elaboración del RUP 2.1.4 Fase Construcción y Transición Del RUP 2.2 Disciplinas y Artefactos del RUP 2.2.1 Modelado del negocio 2.2.2 Gestión del proyecto 2.2.3 Modelos y Vistas INGENIRIA DEL SOFTWARE 2

MODULO 2

RUP

INDICE Rational Unified Process (RUP) ................................................................................................. 3 2.1 Ciclo de vida RUP ............................................................................................................ 3 2.1.1 Fases e Iteraciones del RUP.......................................................................................... 3 2.1.2 Fase Inicio del RUP ................................................................................................... 4 2.1.3 Fase Elaboración del RUP ......................................................................................... 4 2.1.4 Fase Construcción del RUP ....................................................................................... 5 2.1.5 Fase de Transición del RUP....................................................................................... 5 2.2 Disciplinas y Artefactos del RUP ...................................................................................... 6 2.2.1 Modelado del negocio ............................................................................................. 8 2.2.2 Gestión del proyecto................................................................................................ 9 2.2.3 Modelos y Vistas .................................................................................................... 10 2.3 CONCLUSIONES ............................................................................................................ 11 2.4 REFERENCIAS ................................................................................................................ 12

INGENIERIA DEL SOFTWARE 2

2

MODULO 2

RUP

Rational Unified Process (RUP)

El Proceso Unificado de Rational (RationalUnifiedProcess en inglés, habitualmente resumido como RUP) es un proceso de desarrollo de software y junto con el Lenguaje Unificado de Modelado UML, constituye la metodología estándar más utilizada para el análisis, implementación y documentación de sistemas orientados a objetos. El RUP no es un sistema con pasos firmemente establecidos, sino un conjunto de metodologías adaptables al contexto y necesidades de cada organización.

2.1

Ciclo de vida RUP

El ciclo de vida RUP es una implementación del Desarrollo en espiral. Fue creado ensamblando los elementos en secuencias semi-ordenadas. El RUP divide el proceso de desarrollo en ciclos, teniendo un producto final al final de cada ciclo, cada ciclo se divide en fases que finalizan con un producto donde se debe tomar una decisión importante. El ciclo de vida organiza las tareas en fases e iteraciones.

2.1.1 Fases

e Iteraciones del RUP

El proceso iterativo e incremental consta de una secuencia de iteraciones. Cada iteración aborda una parte de la funcionalidad total, pasando por todos los flujos de trabajo relevantes y refinando la arquitectura. Cada iteración se analiza cuando termina. Se puede determinar si han aparecido nuevos requisitos o han cambiado los existentes, afectando a las iteraciones siguientes. Durante la planificación de los detalles de la siguiente iteración, se examina cómo afectarán los riesgos que aún quedan al trabajo en curso. Toda la retroalimentación de la iteración pasada permite reajustar los objetivos para las siguientes iteraciones. RUP divide el proceso en cuatro fases, dentro de las cuales se realizan varias iteraciones en número variable según el proyecto y en las que se hace un mayor o menor hincapié en las distintas actividades. 

Fase de Inicio  Fase de Elaboración  Fase de Construcción  Fase de Transición

Las primeras iteraciones (en las fases de Inicio y Elaboración) se enfocan hacia la comprensión del problema y la tecnología, la delimitación del ámbito del proyecto, la eliminación de los riesgos críticos, y al establecimiento de una baseline (Línea Base) de la arquitectura.


3

MODULO 2 2.1.2 Fase

RUP Inicio del RUP

Durante la fase de inicio las iteraciones hacen mayor énfasis en actividades de modelado del negocio y de requisitos. Se hace un plan de fases, se identifican los principales casos de uso y se identifican los riesgos. Los objetivos de esta fase son: Establecer el ámbito del proyecto y sus límites.  Encontrar los Casos de Uso críticos del sistema, los escenarios básicos que definen la funcionalidad. escenarios principales.  Mostrar al menos una arquitectura candidata para los  Estimar el coste en recursos y tiempo de todo el proyecto.  Estimar los riesgos, las fuentes de incertidumbre. 

Fase de Inicio: Esta fase tiene como propósito definir y acordar el alcance del proyecto con los patrocinadores, identificar los riesgos asociados al proyecto, proponer una visión muy general de la arquitectura de software y producir el plan de las fases y el de iteraciones posteriores. 2.1.3 Fase

Elaboración del RUP

En la fase de elaboración, las iteraciones se orientan al desarrollo de la baseline de la arquitectura, abarcan más los flujos de trabajo de requisitos, modelo de negocios (refinamiento), análisis, diseño y una parte de implementación orientado a la baseline de la arquitectura. Se hace un plan de proyecto, se completan los casos de uso y se eliminan los riesgos Los objetivos de esta fase son: Definir, validar y cimentar la arquitectura.  Completar la visión.  Crear un plan fiable para la fase de construcción. Este plan puede evolucionar en sucesivas iteraciones. Debe incluir los costes si procede.  Demostrar que la arquitectura propuesta soportará la visión con un coste razonable y en un tiempo razonable. 

Fase de elaboración: En la fase de elaboración se seleccionan los casos de uso que permiten definir la arquitectura base del sistema y se desarrollaran en esta fase, se realiza la especificación de los casos de uso seleccionados y el primer análisis del dominio del problema, se diseña la solución preliminar.


4

MODULO 2 2.1.4 Fase

RUP Construcción del RUP

En la fase de construcción, se lleva a cabo la construcción del producto por medio de una serie de iteraciones. Para cada iteración se selecciona algunos Casos de Uso, se refina su análisis y diseño y se procede a su implementación y pruebas. Se realiza una pequeña cascada para cada ciclo. Se realizan tantas iteraciones hasta que se termine la implementación de la nueva versión del producto. Los objetivos concretos incluyen: Minimizar los costes de desarrollo mediante la optimización de recursos y evitando el tener que rehacer un trabajo o incluso desecharlo.  Conseguir una calidad adecuada tan rápido como sea práctico.  Conseguir versiones funcionales (alfa, beta, y otras versiones de prueba) tan rápido como sea práctico. 

Fase de Desarrollo: El propósito de esta fase es completar la funcionalidad del sistema, para ello se deben clarificar los requisitos pendientes, administrar los cambios de acuerdo a las evaluaciones realizados por los usuarios y se realizan las mejoras para el proyecto. 2.1.5 Fase

de Transición del RUP

En la fase de transición se pretende garantizar que se tiene un producto preparado para su entrega a la comunidad de usuarios. Se implementa el producto en el cliente y se entrena a los usuarios. Como c onsecuencia de esto suelen surgir nuevos requisitos a ser anali zados. Los principales objetivos de esta fase son:  

Conseguir que el usuario se valga por si mismo. Un producto final que cumpla los requisitos esperados, que funcione y satisfaga suficientemente al usuario.

Como se puede observar en cada f ase participan todas las disciplinas, pero que dependiendo de la fase el esfuerzo dedicado a una disciplina varía.

Fase de Cierre: El propósito de esta fase es asegurar que el software esté disponible para los usuarios finales, ajustar los errores y defectos encontrados en las pruebas de aceptación, capacitar a los usuarios y proveer el soporte técnico necesario. Se debe verificar que el producto cumpla con las especificaciones entregadas por las personas involucradas en el proyecto.


5

MODULO 2 2.2

RUP

Disciplinas y Artefactos del RUP

Un proceso de desarrollo de software define quién hace qué, cómo y cuándo. RUP define cuatro elementos los roles, que responden a la pregunta ¿Quién?, las actividades que responden a la pregunta ¿Cómo?, los productos, que responden a la pregunta ¿Qué? y los flujos de trabajo de las disciplinas que responde a la pregunta ¿Cuándo? [RSC98]. RUP comprende 2 aspectos importantes por los cuales se establecen las disciplinas: 'Proceso' : Las etapas de esta sección son: Modelado de negocio  Requisitos  Análisis y Diseño  Implementación  Pruebas  Despliegue

Roles

Artefactos Actividades

En esta parte nos encontramos con las siguientes etapas: Gestión del cambio y configuraciones  Gestión del proyecto  Entorno

Soporte:



La estructura dinámica de RUP es la que permite que éste sea un proceso de desarrollo fundamentalmente iterativo, y en esta parte se ven inmersas las 4 fases descritas anteriormente: Un proceso de desarrollo de software define quién hace qué, cómo y cuándo. RUP define cuatro elementos:  Los roles, que responden a la pregunta ¿Quién?,  Las actividades que responden a la pregunta ¿Cómo?,  Los productos, que responden a la pregunta ¿Qué? Y  Los flujos de trabajo de las disciplinas que responde a la pregunta ¿Cuándo? Roles

Un rol define el comportamiento y responsabilidades de un individuo, o de un grupo de individuos trabajando juntos como un equipo. Una persona puede desempeñar diversos roles, así como un mismo rol puede ser representado por varias personas. Actividades

Una actividad en concreto es una unidad de trabajo que una persona que desempeñe un rol puede Ser solicitado a que realice. Las actividades tienen un objetivo concreto, normalmente expresado en términos de crear o actualizar algún producto. Artefactos

Un producto o artefacto es un trozo de información que es producido, modificado o usado durante el proceso de desarrollo de software. Los productos son los resultados tangibles del proyecto, las cosas que va creando y usando hasta obtener el producto final. INGENIERIA DEL SOFTWARE 2

6

MODULO 2

RUP

Flujos de traba jo

Un flujo de trabajo es una relación de actividades que nos producen unos resultados observables. Por ejemplo: Modelado del negocio  Requisitos  Análisis y Diseño  Implementación  Pruebas  Despliegue  Gestión del proyecto  Configuración y control de cambios  Entorno 

Con la enumeración de roles, actividades y artefactos no se define un proceso, necesitamos contar con una secuencia de actividades realizadas por los diferentes roles, así como la relación entre los mismos. Requisitos

Este es uno de los flujos de trabajo más importantes, porque en él se establece qué tiene que hacer exactamente el sistema que construyamos. En esta línea los requisitos son el contrato que se debe cumplir, de modo que los usuarios finales tienen que comprender y aceptar los requisitos que especifiquemos. Los objetivos del flujo de datos Requisitos es [RSC02]: Establecer y mantener un acuerdo entre clientes y otros stakeholders sobre lo que el sistema podría hacer.  Proveer a los desarrolladores un mejor entendimiento de los requisitos del sistema.  Definir el ámbito del sistema.  Proveer una base para la planeación de los contenidos técnicos de las iteraciones.  Proveer una base para estimar costos y tiempo de desarrollo del sistema.  Definir una interfaz de usuarios para el sistema, enfocada a las necesidades y metas del usuario. 


7

MODULO 2 2.2.1

RUP

Modelado del negocio

Con este flujo de trabajo pretendemos llegar a un mejor entendimiento de la organización donde se va a implantar el producto. Los objetivos del modelado de negocio son [RSC02]: Entender la estructura y la dinámica de la organización para la cual el sistema va ser desarrollado (organización objetivo).  Entender el problema actual en la organización objetivo e identificar potenciales mejoras.  Asegurar que clientes, usuarios finales y desarrolladores tengan un entendimiento común de la organización objetivo.  Derivar los requisitos del sistema necesarios para apoyar a la organización objetivo. 

Para lograr estos objetivos, el modelo de negocio describe como desarrollar una visión de la nueva organización, basado en esta visión se definen procesos, roles y responsabilidades de la organización por medio de un modelo de Casos de Uso del negocio y un Modelo de Objetos del Negocio. Complementario a estos modelos, se desarrollan otras especificaciones tales como un Glosario.


8

MODULO 2 2.2.2

RUP

Gestión del proyecto

RUP define pautas para ayudar a la administración de proyectos, este está exento en la definición de las siguientes áreas: gestión de recurso humano (procesos relacionados con capacitación y manejo del recurso), gestión de presupuesto y contratación. El RUP utiliza estas áreas de proceso directamente del PMBOK. La metodología RUP, utiliza las mejores prácticas para definir los artefactos del proyecto basados en los que se encuentran definidos en el PMBOK. Esto no quiere decir que ambos sean iguales. A continuación se hace un listado de los artefactos que posee el RUP en la gestión de proyectos: Desarrollo del Plan de Proyecto  Plan de calidad  Plan de manejo de riesgos  Plan de aceptación del producto  Plan para la resolución de problemas  Generación del Caso de Negocio  Plan de Iteraciones (todas las iteraciones del proyecto)  Documentación de Iteraciones  Documentación del estado del proyecto  Listado de Riesgos  Plan de trabajo  Listado de hitos  Métricas e indicadores del proyecto. 

Si se mapean el artefacto de Plan de proyectos a la definición del PMBOK, se ejemplificaría de la siguiente forma: Plan de Proyecto

:

Este plan es desarrollado en la etapa inicial del ciclo RUP y es actualizado en todas las iteraciones. Este plan contendría: Una Descripción General del Proyecto  Propósito, alcance y objetivos  Limitaciones y cosas que se asumen  Entregables del proyecto  Organización del Proyecto  Estructura organizacional y del proyecto  Ambiente organizacional y factores del entorno  Definición de roles y responsabilidades  Gestión del Proyecto  Estimados del proyecto  Plan de desarrollo de software  Plan de iteraciones  Monitoreo y control  Otros planes 


9

MODULO 2 2.2.3

RUP

Modelos y Vistas

RUP trabaja con las siguientes vistas: Vista Lógica:  Diagrama de clases  Modelo E-R (Si el sistema así lo requiere) Vista de Implementación:  Diagrama de Secuencia  Diagrama de estados  Diagrama de Colaboración Vista Conceptual:  Modelo de dominio Vista física:  Mapa de comportamiento a nivel de hardware. p

p

p

p

Modelado vis ual (usando UML)

UML es un lenguaje para visualizar, especificar, construir y documentar los artefactos de un sistema software. Es un estándar de la OMG .Utilizar herramientas de modelado visual facilita la gestión de dichos modelos, permitiendo ocultar o exponer detalles cuando sea necesario. El modelado visual también ayuda a mantener la consistencia entre los artefactos del sistema: requisitos, diseños e implementaciones. En resumen, el modelado visual ayuda a mejorar la capacidad del equipo para gestionar la complejidad del software.


10

MODULO 2 2.3

RUP

CONCLUSIONES

Cervantes Rodrí guez José de Jesús

RUP es modelo útil cuando el cliente conoce los objetivos generales para el software, es iterativo e incremental. También ofrece un mejor enfoque cuando el responsable del desarrollo del software está inseguro de la eficacia de un algoritmo, de la adaptabilidad de un sistema operativo o de la forma que debería tomar la interacción humano-máquina. En si es un forma disciplinada de asignar tareas y responsabilidades en una empresa de desarrollo (quién hace qué, cuándo y cómo). Ya que contiene una serie de procesos muy ordenados para el desarrollo del software en conjunto de UML, para el análisis, implementación y documentación de sistemas orientados a objetos Garcí a Vázquez Ramiro Alberto

Pienso que la herramienta RUP es un gran avance en cuanto a la ingeniería del software, debido a que ya establece unas mejores y mas distinguidas fases para que el usuario las pueda identificar asi como para tener en un mejor orden y una buena documentación del software a crear, es por eso que es uno de los mejores métodos en el cual se podría confiar. Moreno Espinoza Eduardo David

RUP, es una buena opción para el desarrollo de software, ya que permite una mejor organización, y facilita la generación de la documentación. Zacarí as Padilla Luis Jorge

Se puede concluir que, RUP, es una herramienta que nos ayuda con en el desarrollo de software, aumenta nuestra visión de desarrollo de software, RUP es una herramienta que permite prever los cambios que un software pueda tener de acuerdo a los requerimientos y avance que se tenga, brindando objetivos más amplios y visión de requerimientos global.


11

MODULO 2 2.4

RUP

REFERENCIAS http://yaqui.mxl.uabc.mx/~molguin/as/RUP.htm

www.rational.com.ar/herramientas/ rup.html www.willydev.net/descargas/prev/IntroArq.pdf http://es.scribd.com/doc/36325889/RUP-y-UML http://www.juanzamora.net/2007/12/rup-en-proyectos.html


12

Rup

Recommend Documents