Historia

Su origen está en una empresa sueca, Objectory AB, que desarrolló un software del mismo nombre como herramienta de diseño orientado a objetos. En 1995 Rational Software adquirió la empresa y popularizó su herramienta (más evolucionada) bajo el nombre de Rational Rose.

En 1999 Ivar Jacobson, Grady Booch, y James Rumbaugh publican "The Unified Software Development Process" en el que se describe el marco teórico de la metodología.

Hoy hay muchas variaciones del Proceso Unificado. La más popular es RUP (Rational Unified Process) basada en las herramientas de la empresa Rational hoy adquirida por IBM. Pero también existen el Agile Unified Process, Basic Unified Process, Enterprise Unified Process, Open Unified Process... e incluso Oracle Unified Method. Y es que el Proceso Unificado es una metodología flexible, que requiere ser adaptada a cada organización.

Características

Sus características principales son: que es iterativa, se basa en la técnica de Casos de Uso y es muy flexible.

Es Iterativa

Divide el proyecto en iteraciones. En cada una se desarrollan prácticamente todas las actividades del proyecto y se produce un sistema utilizable. Con cada iteración el sistema evoluciona, incluyendo nueva funcionalidad o mejorando la existente.

Es necesario que el resultado de cada iteración sea utilizable porque el Proceso Unificado requiere que tras cada iteración los usuarios, el cliente y el equipo valoren el sistema. Esta valoración se utiliza para redefinir los objetivos del proyecto. De esta forma, con iteraciones frecuentes, se garantiza la adaptación del sistema a los cambios durante el desarrollo.

Se Basa en Casos de Uso

Los Casos de Uso constituyen la guía para el desarrollo del sistema en el Proceso Unificado. Cada iteración se planifica para añadir un conjunto limitado de Casos de Uso al sistema haciéndolo crecer iteración tras iteración.

Como es un proceso iterativo, tras cada iteración se revisan los Casos de Uso y se eligen los que se desarrollarán en la siguiente iteración.

Centrada en la Arquitectura

En el Proceso Unificado, la arquitectura del sistema es fundamental.

La arquitectura del sistema se implementa en las primeras iteraciones y, sobre ella, se va añadiendo progresivamente la funcionalidad de los casos de uso.

Es Flexible

El Proceso Unificado establece las fases del proyecto, las formas generales de trabajo y recomienda técnicas para cada actividad. Pero deja abiertas muchas opciones y posibilidades para adaptar la metodología a las necesidades y características de cada organización, incluso de cada proyecto.

Planificación

El Proceso Unificado divide el proyecto en cuatro fases, cada una de ellas formada por una o más iteraciones. La duración de cada iteración oscila entre 2 y 6 semanas, pero es la misma para todas las iteraciones del proyecto.

Los Casos de Uso que se desarrollarán en cada iteración se eligen en base a dos criterios:

1. Los de mayor "riesgo".
2. Los de mayor valor para el cliente.

Se entiende por "arriesgados" aquellos casos que puedan condicionar la arquitectura del sistema. Por lo tanto, suelen incluirse en las primeras iteraciones (o mejor en la primera) casos que impliquen a todos los componentes del sistema. Con esto se consigue consolidar la arquitectura del sistema en las primeras iteraciones.

El criterio de valor para el cliente garantiza que el sistema adquirirá valor rápidamente con cada iteración.

Las cuatro fases son:

1.- Lanzamiento (Inception)

El objetivo de esta fase es tomar una decisión fundada sobre la viabilidad técnica y económica del proyecto

En esta fase se suelen especificar el ámbito del proyecto y los principales Casos de Uso, se identifican los riesgos y las posibles arquitecturas y se concluye con un Plan de Ejecución y un Presupuesto preliminares.

Es importante señalar que en esta fase NO se catalogan los requerimientos del proyectos. Eso es contrario al espíritu del Proceso Unificado. Los requerimientos se irán capturando progresivamente en Casos de Uso. Por lo tanto, el presupuesto y el Plan de Ejecución resultantes deben ser considerados "preliminares".

Normalmente, esta fase dura una o dos semanas. En proyectos muy conocidos (de escaso riesgo) puede reducirse a unos pocos días.

2.- Elaboración

Los objetivos de esta fase son:

Desarrollar la arquitectura básica del sistema.

Capturar la mayoría de los requerimientos del sistema.

Para lograrlo, se eligen los Casos de Uso necesarios para cubrir la arquitectura básica del sistema, y se desarrollan. En el Proceso Unificado, la arquitectura del sistema es la pieza fundamental sobre la que se añade el resto del desarrollo. Por eso se aborda en las primeras iteraciones.

Respecto a los requerimientos del sistema, no es necesario registrarlos todos con detalle. Bastará con identificarlos y detallar los más representativos (10-20%).

En esta fase se utilizan técnicas como Diagramas de Paquetes (para describir la arquitectura), Diagramas de Casos de Uso y Diagramas Conceptuales de Clases.

La fase de Elaboración concluye con la elaboración de un Plan de Ejecución y un Presupuesto para la fase de Construcción. Sabiendo ya cual será la arquitectura del sistema y los requerimientos del sistema, el Plan de Ejecución y el Presupuesto ya serán mucho más fiables que los elaborados en la fase de Lanzamiento.

La duración de esta fase depende de la complejidad de la arquitectura, la extensión del sistema y la propia duración de cada iteración. Pero en ningún caso puede exceder los dos meses.

3.- Construcción

Esta es la fase principal del proyecto, y su objetivo es desarrollar el resto del sistema.

En cada iteración, se añade nueva funcionalidad al sistema sobre la base de la arquitectura desarrollada en la fase de elaboración. Para ello, se van detallando completamente los Casos de Uso que se incluyen en cada iteración.

Las técnicas más utilizadas en esta fase son las propias de Implementación: Programación en Parejas, Test-First, etc. Pero también son necesarias las técnicas finales de Diseño, como los Diagramas de Secuencia y de Interacción.

4.- Transición

Esta es la fase final del proyecto y su objetivo es entregar el sistema a los usuarios finales.

Tras cada iteración de la fase de Transición, se pone a disposición de los usuarios finales una nueva versión de la aplicación, utilizándose la información recibida de estos para mejorar el sistema en la siguiente entrega.

La fase de Transición incluye la migración y carga de datos, formación a usuarios, soporte técnico, etc.

Técnicas Empleadas

En cada una de las actividades, el Proceso Unificado propone varias técnicas. La elección depende del Jefe de Proyecto.

Modelado del Negocio

La técnica más utilizada es el Modelo de Objetos de Negocio. Aunque algunos autores lo consideran "demasiado pesado". También son útiles los Diagramas de Actividad para explicar más detalladamente áreas concretas de la organización y procesos de negocio.

En ocasiones, también se registran las Reglas del Negocio que son aplicables a varios proyectos.

Pero en muchos proyectos puede bastar con un simple Organigrama.

Gestión de Requerimientos

En la Gestión de Requerimientos se utilizan dos técnicas fundamentales: los Casos de Uso y el Modelo de Dominio.

Los Casos de Uso son fundamentales en el Proceso Unificado. Constituyen la base de la planificación de las iteraciones del proyecto. Y, sin lugar a dudas, esta no es una técnica optativa.

Los Casos de Uso se complementan con otras técnicas auxiliares. Por ejemplo, varios casos de uso pueden mostrarse gráficamente en un Diagrama de Casos de Uso. Y, los casos de uso más complicados, pueden detallarse utilizando Diagramas de Secuencia del Sistema o incluso Contratos de Operación.

Además de los Casos de Uso, es habitual utilizar otras técnicas para registrar requerimientos. Por ejemplo, la Visión resume las principales ideas del proyecto y el Vocabulario registra los términos relevantes o confusos del proyecto.

Pero también es imprescindible registrar los Requerimientos No Funcionales que permitirán posteriormente medir y gestionar la calidad del proyecto.

El Modelo de Dominio es la otra técnica fundamental en la captura de requerimientos, que permite representar gráficamente los objetos reales que debe abordar el proyecto.

Diseño

En la actividad de Diseño se utilizan técnicas de modelado estático (para describir las clases software) como los Diagramas de Clase y técnicas de modelado dinámico (para describir las interacciones entre las clases), como los Diagramas de Interacción (de secuencia y de comunicación).

Además, es habitual estructurar las clases en capas, para lo que se utilizan los Diagramas de Paquetes.

Implementación

En la actividad de Implementación, el Proceso Unificado utiliza técnicas como la Refactorización, el Desarrollo Dirigido por Tests (TDD) o los Tests Unitarios.

Tests

Para realizar esta actividad, en el Proceso Unificado se utilizan técnicas de Tests de Aceptación, Tests de Rendimiento, Tests de Integración, etc.

Despliegue

Para esta actividad apenas hay técnicas definidas. Podemos citar el Diagrama de Despliegue.

Gestión de Cambios

Esta actividad tampoco tiene técnicas específicas definidas. Podemos citar el Control de Versiones.

Gestión del Proyecto

Esta actividad tampoco tiene técnicas específicas definidas.

Referencias

Wikipedia: Unified Process

IBM: An Introduction to Model-Driven Architecture

Enterprise Unified Process: History of the Unified Process

Applying UML and Patterns - Craig Larman, Ed. Prentice Hall