El Proceso Unificado Rational (RUP)

El Proceso Unificado Rational (RUP)

Contenido

• Definición de Procesos y Procesos de Software.

• Procesos de Software Iterativos.

• Proceso Unificado Rational (RUP).

• Fases e Hitos de RUP.

• Características de RUP.

• Noción del Proceso (worker, artefactos, actividades y flujos de Trabajo

• Mejores Prácticas de RUP.

• Workflows de RUP.

¿Qué es un Proceso?

• Un proceso define Quién está haciendo Qué, Cuándo y Cómo para lograr un cierto objetivo. En la ingeniería de software el objetivo es construir un producto de software ó mejorar alguno existente.

Procesos de Software

• Es la forma en que producimos software. Este incorpora la metodología con su modelo de ciclo de vida del software subyacente y las técnicas, las herramientas y lo más importante de todo, las construcciones individuales de software.

Procesos de Desarrollo Iterativos

• Es un enfoque para construir software en el cual el ciclo de vida total está compuesto de algunas iteraciones en secuencia. Cada iteración es un mini proyecto auto contenido compuesto de actividades como análisis de requerimientos, diseño, programación y pruebas.

Ejemplos

• RUP: Rational Unified Process

• PUD: Proceso Unificado de Desarrollo (UP: Unified Process)

• OpenUP: Framework Abierto para UP.

• XP: eXtremme Programming (Programación Extrema)

Proceso Unificado Rational

• El RUP es un proceso de ingeniería de software. Provee un esquema disciplinado para asignar tareas y responsabilidades en una organización de desarrollo.

• Su objetivo es asegurar la producción de software de alta calidad que reúna las necesidades de sus usuarios dentro de los límites presupuestarios y de calendario.

• El Proceso Unificado Rational es un framework de proceso de desarrollo de software iterativo creado por la Corporación Rational Software, la cual es una división de IBM desde 2003.

• RUP no es un simple proceso prescriptivo concreto, más bien es un framework adaptable orientado a ajustarse por las organizaciones de desarrollo y equipos de proyectos de software, que seleccionarán los elementos del proceso que son apropiados para sus necesidades.

• El RUP como producto incluye una base de conocimientos base con artefactos ejemplo y descripción detallada para muchos tipos de actividades.

• El Proceso Unificado (UP) fue diseñado desde el principio para incluir a un proceso genérico de dominio público y uno más detallado llamado Rational Unified Process, el cual ha sido mercadeado como un producto comercial.

Objetivos de RUP

• Proporcionar una guía del orden de las actividades de los equipos.

• Especificar cuáles artefactos deben ser desarrollados y cuándo deben ser desarrollados.

• Dirigir las tareas de desarrolladores individuales y equipos como una sola.

• Ofrecer criterios para monitorear y medir los productos y actividades del proyecto

Fases e Hitos de RUP

Características Claves del Proceso Unificado Rational

• Dirigido por Casos de Uso

• Centrado en la Arquitectura

• Iterativo e Incremental

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 Usos modelan los requerimientos funcionales del sistema.

• El modelo de casos de Usos ayudan a los clientes, usuarios y desarrolladores a llegar a un acuerdo de lo que se quiere que haga el sistema y cómo lo hará.

• Cada tipo de usuario del sistema representa un actor que define un rol de utilización del sistema.

• Los actores modelan el entorno del sistema y los casos de usos especifican el sistema.

• El conjunto de diagramas de casos de usos constituyen el modelo de casos de uso del sistema.

• Los casos de usos guían el proceso de desarrollo (diseño, implementación y pruebas).

Centrado en la Arquitectura

• Los modelos expresan la arquitectura. La arquitectura abarca las decisiones significativas acerca de lo siguiente:

• La organización de un sistema software.

• Los elementos más significativos del sistema influenciado entre otros por plataformas software, sistemas operativos, manejadores de bases de datos, protocolos, consideraciones de desarrollo como sistemas heredados y requerimientos no funcionales.

• La arquitectura de un sistema de software se describe mediante diferentes vistas del sistema en construcción.

• Todas las vistas juntas forman el llamado modelo 4+1 de la arquitectura conformado por las vistas lógicas, de proceso, implementación, despliegue más la de casos de usos que da cohesión a todas.

• El concepto de arquitectura de software incluye los aspectos estáticos y dinámicos más significativos del sistema en construcción.

Iterativo e Incremental

• Es práctico dividir el esfuerzo de desarrollo de un proyecto de software en parte más pequeñas o mini proyectos.

• Cada mini proyecto es una iteración que resulta en un incremento.

• Las iteraciones hacen referencia a pasos en un flujo de trabajo y los incrementos al crecimiento del producto.

• Cada fase en RUP puede descomponerse en iteraciones. Una iteración es un ciclo de desarrollo completo dando como resultado una entrega de producto ejecutable (interna o externa)

Estructura del RUP

• El proceso puede describirse en dos dimensiones, o a lo largo de dos ejes:

– El eje horizontal representa tiempo y muestra el aspecto dinámico del proceso, expresado en términos de ciclos, fases, iteraciones, y metas.

– El eje vertical representa el aspecto estático del proceso; como está descrito en términos de actividades, artefactos, trabajadores y flujos de trabajo.

Perfil de un Proyecto Típico

Noción del Proceso

Flujos de Trabajo

• Una mera enumeración de todos los trabajadores, actividades y artefactos no constituyen un proceso. Se necesita una forma de describir secuencias significativas que produzcan algún resultado válido, y que muestre la interacción entre trabajadores.

• Un flujo de trabajo es una secuencia de actividades que producen un resultado de valor observable.

• En términos de UML pueden ser expresados como un diagrama de secuencia, un diagrama de colaboración, ó como un diagrama de actividad.

• Los grupos de trabajo agrupan actividades en forma lógica

Fases de Rup

Fase de Inicio:

Antes de iniciar un proyecto es conveniente plantearse algunas cuestiones: ¿Cuál es el objetivo? ¿Es factible? ¿Lo construimos o lo compramos? ¿Cuánto va a costar? La fase de inicio trata de responder a estas preguntas y a otras más. Sin embargo no pretendemos una estimación precisa o la captura de todos los requisitos. Más bien se trata de explorar el problema lo justo para decidir si vamos a continuar o a dejarlo.

Los objetivos de la fase de inicio 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.

• Mostrar al menos una arquitectura candidata para los escenarios principales.

• Estimar el coste en recursos y tiempo de todo el proyecto.

• Estimar los riesgos, las fuentes de incertidumbre.

Los productos de la fase de inicio deben ser:

• Visión del negocio: Describe los objetivos y restricciones a alto nivel.

• Modelo de casos de uso.

• Especificación adicional: requisitos no funcionales.

• Glosario: Terminología clave del dominio.

• Lista de riesgos y planes de contingencia.

• El caso de negocio (business case).

• Prototipos exploratorios para probar conceptos o la arquitectura candidata.

• Plan de iteración para la primera iteración de la fase de elaboración.

• Plan de fases.

Fase de Elaboración:

El propósito de la fase de elaboración es analizar el dominio del problema, establecer los cimientos de la arquitectura, desarrollar el plan del proyecto y eliminar los mayores riesgos

Los objetivos de la fase de elaboración 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.

Al terminar deben obtenerse los siguientes productos:

• Un modelo de casos de uso completa al menos hasta el 80%: todos los casos y actores identificados, la mayoría de los casos desarrollados.

• Requisitos adicionales.

• Descripción de la arquitectura software.

• Un prototipo ejecutable de la arquitectura.

• Lista de riesgos y caso de negocio revisados.

• Plan de desarrollo para el proyecto.

• Un caso de desarrollo actualizado que especifica el proceso a seguir.

• Posiblemente un manual de usuario preliminar

Fase de Construcción :

La

...