Metodologia RUP

¿QUÉ ES RUP? 

El Proceso Unificado de Rational (Rational Unified Process en inglés, habitualmente resumido como RUP) es un proceso de desarrollo de software desarrollado por la empresa Rational Software, actualmente propiedad de IBM. Junto con el Lenguaje Unificado de Modelado UML, constituye la metodología estándar más utilizada para el análisis, diseño, 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.

También se conoce por este nombre al software, también desarrollado por Rational, que incluye información entrelazada de diversos artefactos y descripciones de las diversas actividades. Está incluido en el Rational Method Composer (RMC), que permite la personalización de acuerdo con las necesidades.

Originalmente se diseñó un proceso genérico y de dominio público, el Proceso Unificado, y una especificación más detallada, el Rational Unified Process, que se vendiera como producto independiente.

PRINCIPIOS DE DESARROLLO

El RUP está basado en 6 principios clave que son los siguientes:

Adaptar el proceso

El proceso deberá adaptarse a las necesidades del cliente ya que es muy importante interactuar con él. Las características propias del proyecto. El tamaño del mismo, así como su tipo o las regulaciones que lo condicionen, influirán en su diseño específico. También se deberá tener en cuenta el alcance del proyecto en un área subnormal.

Equilibrar prioridades

Los requisitos de los diversos participantes pueden ser diferentes, contradictorios o disputarse recursos limitados. Debe encontrarse un equilibrio que satisfaga los deseos de todos. Gracias a este equilibrio se podrán corregir desacuerdos que surjan en el futuro.

Demostrar valor iterativamente

Los proyectos se entregan, aunque sea de un 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.

Colaboración entre equipos

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

Elevar el nivel de abstracción

Este principio dominante motiva el uso de conceptos reutilizables tales como patrón del software, lenguajes 4GL o marcos de referencia (frameworks) por nombrar algunos. Esto evita que los ingenieros de software vayan directamente de los requisitos a la codificación de software a la medida del cliente, sin saber con certeza qué codificar para satisfacer de la mejor manera los requisitos y sin comenzar desde un principio pensando en la reutilización del código. Un alto nivel de abstracción también permite discusiones sobre diversos niveles y soluciones arquitectónicas. Éstas se pueden acompañar por las representaciones visuales de la arquitectura, por ejemplo con el lenguaje 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. El aseguramiento de la calidad forma parte del proceso de desarrollo y no de un grupo independiente.

CICLO DE VIDA

El ciclo de vida RUP es una implementación del Desarrollo en espiral. Fue creado ensamblando los elementos en secuencias semi-ordenadas. El ciclo de vida organiza las tareas en fases e 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. En la Figura muestra cómo varía el esfuerzo asociado a las disciplinas según la fase en la que se encuentre el proyecto RUP.

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.

Durante la fase de inicio las iteraciones hacen mayor énfasis en actividades de modelado del negocio y de requisitos.

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.

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 seleccionan algunos Casos de Uso, se refinan 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 iteraciones hasta que se termine la implementación de la nueva versión del producto.

En la fase de transición se pretende garantizar que se tiene un producto preparado para su entrega a la comunidad de usuarios.

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

PRINCIPALES CARACTERÍSTICAS

üForma disciplinada de asignar tareas y responsabilidades (quién hace qué, cuándo y cómo)

ü Pretende implementar las mejores prácticas en Ingeniería de Software

ü  Desarrollo iterativo

ü  Administración de requisitos

ü  Uso de arquitectura basada en componentes

ü  Control de cambios

ü  Modelado visual del software

ü  Verificación de la calidad del software

El RUP es un producto de Rational (IBM). Se caracteriza por ser iterativo e incremental, estar centrado en la arquitectura y guiado por los casos de uso. Incluye artefactos (que son los productos tangibles del proceso como por ejemplo, el modelo de casos de uso, el código fuente, etc.) y roles (papel que desempeña una persona en un determinado momento, una persona puede desempeñar distintos roles a lo largo del proceso).

FASES

ü  Establece oportunidad y alcance

ü  Identifica las entidades externas o actores con las que se trata

ü  Identifica los casos de uso

RUP comprende 2 aspectos importantes por los cuales se establecen las disciplinas:

Proceso: Las etapas de esta sección son: (Revise nuevamente la gráfica)

ü  Modelado de negocio

ü  Requisitos

ü  Análisis y Diseño

ü  Implementación

ü  Pruebas

ü  Despliegue

Soporte: En esta parte nos encontramos con las siguientes etapas:

ü  Gestión del cambio y configuraciones

ü  Gestión del proyecto

ü  Entorno

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:

ü  Inicio (también llamado Incepción o Concepción).

ü  Elaboración.

üDesarrollo (también llamado Implementación, Construcción).

ü  Cierre (también llamado Transición).

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.

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.

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.

Fase de Transición: 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.

DOCUMENTACIÓN

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:

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

ü  Los relacionados con el desarrollo de producto de software.

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

ARTEFACTOS

RUP en cada una de sus fases (pertenecientes a la estructura dinámica) realiza una serie de artefactos que sirven para comprender mejor tanto el análisis como el diseño del sistema (entre otros). Estos artefactos (entre otros) son los siguientes:

Inicio:

ü  Documento Visión

ü  Diagramas de caso de uso

ü  Especificación de Requisitos

ü  Diagrama de Requisitos

Elaboración:

ü  Documento Arquitectura que 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.

ü  Diseño y desarrollo de casos de uso, o flujos de casos de uso arquitectónicos.

ü  Pruebas de los casos de uso desarrollados, que demuestran que la arquitectura documentada responde adecuadamente a requerimientos funcionales y no funcionales.

Construcción:

ü  Especificación de requisitos faltantes

ü  Diseño y desarrollo de casos de uso y/o flujos de acuerdo con la planeación iterativa

ü  Pruebas de los casos de uso desarrollados, y pruebas de regresión según sea el caso

Transición:

ü  Pruebas finales de aceptación

ü  Puesta en producción

ü  Estabilización

FUNDAMENTOS DEL ENFOQUE ORIENTADO A OBJETOS

El Enfoque Orientado a Objeto se basa en cuatro principios que constituyen la base de todo desarrollo orientado a objetos. Estos principios son: la Abstracción, el Encapsulamiento, la Modularidad y la Herencia.

Fundamento 1: Abstracción

Es el principio de ignorar aquellos aspectos de un fenómeno observado que no son relevantes, con el objetivo de concentrarse en aquellos que si lo son. Una abstracción denota las características esenciales de un objeto (datos y operaciones), que lo distingue de otras clases de objetos. Decidir el conjunto correcto de abstracciones de un determinado dominio, es el problema central del diseño orientado a objetos.

ü  Los mecanismos de abstracción son usados en el EOO para extraer y definir del medio a modelar, sus características y su comportamiento. Dentro del EOO son muy usados mecanismos de abstracción: la Generalización, la Agregación y la clasificación.

ü   La generalización es el mecanismo de abstracción mediante el cual un conjunto de clases de objetos son agrupados en una clase de nivel superior (Superclase), donde las semejanzas de las clases constituyentes (Subclases) son enfatizadas, y las diferencias entre ellas son ignoradas. En consecuencia, a través de la generalización, la superclase almacena datos generales de las subclases, y las subclases almacenan sólo datos particulares.La especialización es lo contrario de la generalización. Por ejemplo; La clase Médico es una especialización de la clase Persona, y a su vez, la clase Pediatra es una especialización de la superclase Médico.

ü   La agregación es el mecanismo de abstracción por el cual una clase de objeto es definida a partir de sus partes (otras clases de objetos). Mediante agregación se puede definir por ejemplo un computador, por descomponerse en: la CPU, la ULA, la memoria y los dispositivos periféricos. El contrario de agregación es la descomposición.

ü  La clasificación consiste en la definición de una clase a partir de un conjunto de objetos que tienen un comportamiento similar. La ejemplificación es lo contrario a la clasificación, y corresponde a la instanciación de una clase, usando el ejemplo de un objeto en particular.

Fundamento 2: Encapsulamiento

Es la propiedad del EOO que permite ocultar al mundo exterior la representación interna del objeto. Esto quiere decir que el objeto puede ser utilizado, pero los datos esenciales del mismo no son conocidos fuera de él. La idea central del encapsulamiento es esconder los detalles y mostrar lo relevante. Permite el ocultamiento de la información separando el aspecto correspondiente a la especificación de la implementación; de esta forma, distingue el "qué hacer" del "cómo hacer". La especificación es visible al usuario, mientras que la implementación se le oculta.

Fundamento 3: Modularidad

Es la propiedad que permite tener independencia entre las diferentes partes de un sistema. La modularidad consiste en dividir un programa en módulos o partes, que pueden ser compilados separadamente, pero que tienen conexiones con otros módulos. En un mismo módulo se suele colocar clases y objetos que guarden una estrecha relación. El sentido de modularidad está muy relacionado con el ocultamiento de información.

Fundamento 4: Herencia

Es el proceso mediante el cual un objeto de una clase adquiere propiedades definidas en otra clase que lo preceda en una jerarquía de clasificaciones. Permite la definición de un nuevo objeto a partir de otros, agregando las diferencias entre ellos (Programación Diferencial), evitando repetición de código y permitiendo la reusabilidad.
Las clases heredan los datos y métodos de la superclase. Un método heredado puede ser sustituido por uno propio si ambos tienen el mismo nombre. La herencia puede ser simple (cada clase tiene sólo una superclase) o múltiple (cada clase puede tener asociada varias super clases). La clase Docente y la clase Estudiante heredan las propiedades de la clase Persona (superclase, herencia simple). La clase Preparador (subclase) hereda propiedades de la clase Docente y de la clase Estudiante (herencia múltiple).

Fundamento 5: Polimorfismo

Es una propiedad del EOO que permite que un método tenga múltiples implementaciones, que se seleccionan en base al tipo objeto indicado al solicitar la ejecución del método. El polimorfismo operacional o Sobrecarga operacional permite aplicar operaciones con igual nombre a diferentes clases o están relacionados en términos de inclusión. En este tipo de polimorfismo, los métodos son interpretados en el contexto del objeto particular, ya que los métodos con nombres comunes son implementados de diferente manera dependiendo de cada clase.