METODOLOGÍA RUP

El Proceso Unificado Racional, Rational Unified Process en inglés, y sus siglas 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 que trata de un conjunto de metodologías adaptables al contexto y necesidades de cada organización, donde el software es organizado como una colección de unidades atómicas llamados objetos, constituidos por datos y funciones, que interactúan entre sí.

RUP es un proceso para el desarrollo de un proyecto de un software que define claramente quien, cómo, cuándo y qué debe hacerse en el proyecto

RUP como proceso de desarrollo

• RUP es explícito en la definición de software y su trazabilidad, es decir, contempla en relación causal de los programas creados desde los requerimientos hasta la implementación y pruebas.

• RUP identifica claramente a los profesionales (actores) involucrados en el desarrollo del software y sus responsabilidades en cada una de las actividades.

Fases de desarrollo del software

· Inicio

· Elaboración

· Construcción

· Transición

Fase de inicio

Se hace un plan de fases, donde se identifican los principales casos de uso y se identifican los riesgos. Se concreta la idea, la visión del producto, como se enmarca en el negocio, el alcance del proyecto. El objetivo en esta etapa es determinar la visión del proyecto.

Modelado del negocio

En esta fase el equipo se familiarizará más al funcionamiento de la empresa, sobre conocer sus procesos.

· Entender la estructura y la dinámica de la organización para la cual el sistema va ser desarrollado.

· 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.

Requisitos

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.

· 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 estimar costos y tiempo de desarrollo del sistema.

· Definir una interfaz de usuarios para el sistema, enfocada a las necesidades y metas del usuario.

Fase de elaboración

Se realiza el plan de proyecto, donde se completan los casos de uso y se mitigan los riesgos. Planificar las actividades necesarias y los recursos requeridos, especificando las características y el diseño de la arquitectura. En esta etapa el objetivo es determinar la arquitectura Óptima.

Análisis y Diseño

En esta actividad se especifican los requerimientos y se describen sobre cómo se van a implementar en el sistema.

· Transformar los requisitos al diseño del sistema.

· Desarrollar una arquitectura para el sistema.

· Adaptar el diseño para que sea consistente con el entorno de implementación.

Fase de construcción

Se basa en la elaboración de un producto totalmente operativo y en la elaboración del manual de usuario. Construir el producto, la arquitectura y los planes, hasta que el producto está listo para ser enviado a la comunidad de usuarios. En esta etapa el objetivo es llevar a obtener la capacidad operacional inicial.

Implementación

Se implementan las clases y objetos en ficheros fuente, binarios, ejecutables y demás. El resultado final es un sistema ejecutable.

· Planificar qué subsistemas deben ser implementados y en qué orden deben ser integrados, formando el Plan de Integración.

· Cada implementador decide en qué orden implementa los elementos del subsistema.

· Si encuentra errores de diseño, los notifica.

· Se integra el sistema siguiendo el plan.

Pruebas

Este flujo de trabajo es el encargado de evaluar la calidad del producto que estamos desarrollando, pero no para aceptar o rechazar el producto al final del proceso de desarrollo, sino que debe ir integrado en todo el ciclo de vida.

· Encontrar y documentar defectos en la calidad del software.

· Generalmente asesora sobre la calidad del software percibida.

· Provee la validación de los supuestos realizados en el diseño y especificación de requisitos por medio de demostraciones concretas.

· Verificar las funciones del producto de software según lo diseñado.

· Verificar que los requisitos tengan su apropiada implementación.

Etapa de transición

El objetivo es llegar a obtener el release del proyecto. Se realiza la instalación del producto en el cliente y se procede al entrenamiento de los usuarios. Realizar la transición del producto a los usuarios, lo cual incluye: manufactura, envío, entrenamiento, soporte y mantenimiento del producto, hasta que el cliente quede satisfecho, por tanto en esta fase suelen ocurrir cambios.

Despliegue

Esta actividad tiene como objetivo producir con éxito distribuciones del producto y distribuirlo a los usuarios. Las actividades implicadas incluyen:

· Probar el producto en su entorno de ejecución final.

· Empaquetar el software para su distribución.

· Distribuir el software.

· Instalar el software.

· Proveer asistencia y ayuda a los usuarios.

· Formar a los usuarios y al cuerpo de ventas.

· Migrar el software existente o convertir bases de datos.

Cada una de estas etapas es desarrollada mediante el ciclo de iteraciones, la cual consiste en reproducir el ciclo de vida en cascada a menor escala. Los objetivos de una iteración se establecen en función de la evaluación de las iteraciones precedentes.

A medida que se avanza en el proyecto, es decir, cuando se va pasando de una fase a otra, la importancia relativa de cada uno de los Flujos de Trabajo va cambiando. Así, en las iteraciones de la Fase de Inicio el trabajo se centra principalmente en el Modelamiento del Negocio y en la captura y especificación de requisitos. Pero en la fase de Construcción el desarrollo está enfocado en la Implementación (codificación) y, en menor medida, en el Diseño

Como filosofía RUP maneja 6 principios clave

Adaptación del proceso

El proceso deberá adaptarse a las características propias de la organización. El tamaño del mismo, así como las regulaciones que lo condicionen, influirán en su diseño específico. También se deberá tener en cuenta el alcance del proyecto.

Balancear prioridades

Los requerimientos de los diversos inversores pueden ser diferentes, contradictorios o disputarse recursos limitados. Debe encontrarse un balance que satisfaga los deseos de todos.

Colaboración entre equipos

El desarrollo de software no hace una única persona sino múltiples equipos. Debe haber una comunicación fluida para coordinar requerimientos, desarrollo, evaluaciones, planes, resultados, etc.

Demostrar valor iterativamente

Los proyectos se entregan, aunque sea de modo interno, en etapas iteradas. En cada iteración se analiza la opinión de los inversores, la estabilidad y calidad del producto, y se refina la dirección del proyecto así como también los riesgos involucrados.

Elevar el nivel de abstracción

Este principio dominante motiva el uso de conceptos reutilizables tales como patrón del software, lenguajes 4GL o esquemas (Frameworks) por nombrar algunos. Estos se pueden acompañar por las representaciones visuales de la arquitectura, por ejemplo con UML.

Enfocarse en la calidad

El control de calidad no debe realizarse al final de cada iteración, sino en todos los aspectos de la producción.

Roles que se cumplen en el RUP

Analistas:

· Analista de procesos de negocio.

· Diseñador del negocio.

· Analista de sistema.

· Especificador de requisitos.

Desarrolladores:

· Arquitecto de software.

· Diseñador.

· Diseñador de interfaz de usuario

· Diseñador de cápsulas.

· Diseñador de base de datos.

· Implementador.

· Integrador.

Gestores:

· Jefe de proyecto

· Jefe de control de cambios.

· Jefe de configuración.

· Jefe de pruebas

· Jefe de despliegue

· Ingeniero de procesos

· Revisor de gestión del proyecto

· Gestor de pruebas.

Apoyo:

· Documentador técnico

· Administrador de sistema

· Especialista en herramientas

· Desarrollador de cursos

· Artista gráfico

Especialista en pruebas:

· Especialista en Pruebas

· Analista de pruebas

· Diseñador de pruebas

Otros roles:

· Stakeholders

· Revisor

· Coordinación de revisiones

· Revisor técnico

Gestión del proyecto

Se vigila el cumplimiento de los objetivos, gestión de riesgos y restricciones para desarrollar un producto que sea acorde a los requisitos de los clientes y los usuarios.

· Proveer un marco de trabajo para la gestión de proyectos de software intensivos.

· Proveer guías prácticas realizar planeación, contratar personal, ejecutar y monitorear el proyecto.

· Proveer un marco de trabajo para gestionar riesgos.

Configuración y control de cambios

El control de cambios permite mantener la integridad de todos los módulos que se crean en el proceso, así como de mantener información del proceso evolutivo que han seguido.

Entorno

La finalidad de esta actividad es dar soporte al proyecto con las adecuadas herramientas, procesos y métodos. Brinda una especificación de las herramientas que se van a necesitar en cada momento, así como definir la instancia concreta del proceso que se va a seguir.

En concreto las responsabilidades de este flujo de trabajo incluyen:

· Selección y adquisición de herramientas.

· Establecer y configurar las herramientas para que se ajusten a la organización.

· Configuración del proceso.

· Mejora del proceso.

· Servicios técnicos.

Niveles de documentación de la metodología RUP

Primer nivel de documentación

Especifica en términos generales qué actividades deberán integrar el Sistema de Aseguramiento de Calidad, que será implantado en la organización. Este nivel contiene los siguientes elementos:

• Declaración de Visión: Proyecciones de la administración sobre el lugar que ocupará la organización en el futuro.

• Declaración de Misión: Compromiso de la administración para alcanzar la Visión.

• Política de Calidad: Posición de la organización, en cuanto a la manera en que la calidad afectará la manera de cumplir con la Misión.

• Requerimientos de Calidad: Conjunto de actividades que la organización debe llevar a cabo, para asegurar la calidad tanto del proceso como el producto que desarrolla

La Visión, Misión y Políticas de Calidad fueron desarrolladas a partir de los lineamientos estratégicos del Departamento de Sistemas de Información.

El Requerimiento de Calidad se identifica en modelos de calidad como ISO 9000.

Segundo nivel de documentación

Este nivel incluye especificaciones detalladas, orientadas a la administración, para explicar cómo se llevarán a cabo las actividades que integran el Sistema de Aseguramiento de Calidad. Este nivel está compuesto básicamente por procedimientos Administrativos, que son declaraciones de direcciones sistemáticas, sobre cómo la organización debe llevar a cabo cada uno de los Requerimientos de Calidad, definidos en el Primer Nivel de Documentación.

Tercer nivel de documentación

Este nivel incluye especificaciones punto a punto, explícito y conciso para llevar a cabo cualquier tarea en la organización. Está compuesto básicamente por Procedimientos de Operativos que describen cada paso que se debe realizar para concretar una tarea o actividad; y Estándares que se utilizan con el fin de registrar datos o información de algo específico. Estos procedimientos y estándares han sido divididos en tres grupos:

1. Los relacionados con el desarrollo del curso Proyecto de Título.

2. Los relacionados con el desarrollo de producto de software.

3. Los que guían la implantación y mejoramiento del Sistema de Aseguramiento de Calidad.

Esta división facilita el uso y mantención del sistema. Por ejemplo, si hay cambios en las normas administrativas que afecten el desarrollo de los cursos en general, entonces sólo se verán afectados los procedimientos y estándares relacionados con el desarrollo del proyecto.

Ciclo de iteraciones de la metodología RUP

Vale mencionar que el ciclo de vida que se desarrolla por cada iteración, es llevada bajo dos disciplinas:

Disciplina de Desarrollo

· Ingeniería de Negocios: Entendiendo las necesidades del negocio.

· Requerimientos: Trasladando las necesidades del negocio a un sistema automatizado.

· Análisis y Diseño: Trasladando los requerimientos dentro de la arquitectura de software.

· Implementación: Creando software que se ajuste a la arquitectura y que tenga el comportamiento deseado.

· Pruebas: Asegurándose que el comportamiento requerido es el correcto y que todo lo solicitado está presente.

Disciplina de Soporte

· Configuración y administración del cambio: Guardando todas las versiones del proyecto.

· Administrando el proyecto: Administrando horarios y recursos.

· Ambiente: Administrando el ambiente de desarrollo.

Los elementos del RUP son:

· Actividades, Son los procesos que se llegan a determinar en cada iteración.

· Trabajadores, Vienen hacer las personas o entes involucrados en cada proceso.

· Artefactos, Un artefacto puede ser un documento, un modelo, o un elemento de modelo.

Una particularidad de esta metodología es que, en cada ciclo de iteración, se hace exigente el uso de artefactos, siendo por este motivo, una de las metodologías más importantes para alcanzar un grado de certificación en el desarrollo del software.

Método pesado

Costo del cambio

· Un cambio en las etapas de vida del sistema incrementaría notablemente el costo.

· Requiere un grupo grande de programadores para trabajar con esta metodología.

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).

El proceso define una serie de roles:

Los roles se distribuyen entre los miembros del proyecto y que definen las tareas de cada uno y el resultado (artefactos) que se espera de ellos.

Figura donde se muestra la definición de roles

Dimensiones del RUP

El RUP tiene dos dimensiones:

· El eje horizontal representa tiempo y demuestra los aspectos del ciclo de vida del proceso.

· El eje vertical representa las disciplinas, que agrupan actividades definidas lógicamente por la naturaleza.

La primera dimensión representa el aspecto dinámico del proceso y se expresa en términos de fases, de iteraciones, y la finalización de las fases. 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.

Características esenciales que definen al RUP

· Proceso Dirigido por los Casos de Uso:

Con esto se refiere a la utilización de los Casos de Uso para el desenvolvimiento y desarrollo de las disciplinas con los artefactos, roles y actividades necesarias. Los Casos de Uso son la base para la implementación de las fases y disciplinas del RUP. Un Caso de Uso es una secuencia de pasos a seguir para la realización de un fin o propósito, y se relaciona directamente con los requerimientos, ya que un Caso de Uso es la secuencia de pasos que conlleva la realización e implementación de un Requerimiento planteado por el Cliente.

· Proceso Iterativo e Incremental: Es el modelo utilizado por RUP para el desarrollo de un proyecto de software. Este modelo plantea la implementación del proyecto a realizar en Iteraciones, con lo cual se pueden definir objetivos por cumplir en cada iteración y así poder ir completando todo el proyecto iteración por iteración, con lo cual se tienen varias ventajas, entre ellas se puede mencionar la de tener pequeños avances del proyectos que son entregables al cliente el cual puede probar mientras se está desarrollando otra iteración del proyecto, con lo cual el proyecto va creciendo hasta completarlo en su totalidad.

· Proceso Centrado en la Arquitectura:

Define la Arquitectura de un sistema, y una arquitectura ejecutable construida como un prototipo evolutivo. Arquitectura de un sistema es la organización o estructura de sus partes más relevantes. Una arquitectura ejecutable es una implementación parcial del sistema, construida para demostrar algunas funciones y propiedades. RUP establece refinamientos sucesivos de una arquitectura ejecutable, construida como un prototipo evolutivo.

Alcance de la metodología RUP

La metodología RUP es más apropiada para proyectos grandes, también pequeños, dado que requiere un equipo de trabajo capaz de administrar un proceso complejo en varias etapas. En proyectos pequeños, es posible que no se puedan cubrir los costos de dedicación del equipo de profesionales necesarios.

Antecedentes del RUP

Los orígenes de RUP se remontan al modelo espiral original de Barry Boehm. Ken Hartman, uno de los contribuidores claves de RUP colaboró con Boehm en la investigación. En 1995 Rational Software compró una compañía sueca llamada Objectory AB, fundada por Ivar Jacobson, famoso por haber incorporado los casos de uso a los métodos de desarrollo orientados a objetos. El Rational Unified Process fue el resultado de una convergencia de Rational Approach y Objectory. El primer resultado de esta fusión fue el Rational Objectory Process, la primera versión de RUP, fue puesta en el mercado en 1998, siendo el arquitecto en jefe Philippe Kruchten. Desde allí hasta la actualidad es la metodología más empleada en el mundo.

Un FRAMEWORK de métodos y módulos reutilizables

Antes de que se puede aplicar a proyectos específicos dentro de una organización. Del mismo modo, necesita terminar el esqueleto RUP y sus bibliotecas para adaptarlos a la organización.

El marco RUP es definido por una familia de método plug-ins que se basan en las necesidades únicas del negocio, así como el contexto (complejidad técnica y de gestión), las organizaciones son capaces de crear sus propias configuraciones de método y a la medida de procesos. RUP proporciona un Fundación arquitectónica y gran cantidad de material que puede construirse en una definición de proceso, por lo tanto, lo que permite la organización adoptando configurar y ampliar esa fundación como desee.

Flujos de trabajo de fase RUP

Cada fase en RUP tiene un flujo de trabajo, en el que se describe la secuencia en que las actividades de todas las diversas disciplinas se pueden realizar para alcanzar los objetivos del hito fase respectivos.

Fases RUP frente a las fases de la cascada

Las Fases RUP difieren de las fases SDLC de cascada tradicional. Para ayudar a las organizaciones a adoptar el RUP. El hecho es que las fases en el RUP no equivalen a las fases en el ciclo de vida de cascada. Para lograr esto se realiza a través de múltiples disciplinas ocesos.