El Proceso Unificado Rational (Rational Unified Process) es un proceso moderno de desarrollo software que recoge elementos de todos los fundamentos de proceso comentados dentro del apartado de metodología, además de una serie de buenas prácticas que han de observarse para la obtención de un producto de calidad.

En Aesis empleamos este proceso como base en cada proyecto si bien, dependiendo de las características del mismo, se adapta, relajando aquellas partes que lo pueden hacer excesivamente rígido o burocrático.

En RUP se puede ver la evolución del software en cuatro fases, al final de las cuales, y tras una serie de iteraciones, establece objetivos a alcanzar bien definidos:

• Concepción. El objetivo de esta fase es establecer los requisitos de negocio que cubrirá el sistema identificando todas las entidades que interactúan con el sistema (personas, sistemas, etc.) y hacer una valoración de la viabilidad del proyecto.
• Elaboración. El objetivo de esta fase es entender muy bien el problema desde el punto de vista del equipo de desarrollo. Lleva consigo la elaboración de la arquitectura marco del sistema y el diseño de la solución técnica, así como determinar el plan del proyecto e identificar los riesgos fundamentales del mismo.
  
  Al final de la fase se tiene definida la arquitectura, el modelo de requisitos del sistema empleando los diagramas de casos de uso especificados en lenguaje UML (Unified Modeling Language), el plan de desarrollo y los estándares de calidad que se han de seguir en el proyecto o las herramientas que se han de emplear durante el transcurso del mismo.
• Construcción. En esta fase se profundiza en el diseño de los componentes y de manera iterativa se van añadiendo las funcionalidades al software a medida que se construyen y prueban, permitiendo a la vez que se puedan ir incorporando cambios.
  
  Se podrán planificar entregas al final de cada iteración, momento en el que se recoge feedback del usuario final y en el que se proponen cambios. Tras el análisis del impacto que suponen los mismos se decide si el mejor momento en que incorporar dichos cambios al sistema. Al final de la fase se tiene un sistema completamente operativo y la documentación para entregar a los usuarios.
• Transición. La fase final del RUP se ocupa del traslado del software desde los entornos de desarrollo a los entornos de producción, en los que el usuario final hará uso del sistema. Dependiendo del tipo de proyecto podrá requerir de entornos intermedios (preproducción o de aceptación por usuarios, etc.) para su correcta validación, antes de su pase a producción.

Cada fase se completa con la realización de varias iteraciones en las que se desarrollan una serie de actividades, que el modelo RUP clasifica en 9 disciplinas que tienen más o menos importancia en función de lo cerca que se esté o no de la finalización del proyecto.

• Modelado del negocio. En este conjunto de actividades se persigue el entendimiento de las necesidades de negocio. Documentos de requisitos generales y de alto nivel, reglas del negocio, glosarios, etc. ayudan a definir lo que el producto software deba hacer.
• Requisitos. Traduce las necesidades del modelo de negocio a requisitos de sistemas automatizables y que con carácter más técnico (se emplean los casos de uso UML), persiguen obtener un entendimiento más profundo del modelo de negocio por parte de los integrantes del equipo de desarrollo.
• Análisis y diseño. Estas actividades determinan, a partir de los requisitos la arquitectura del sistema más adecuada y el diseño detallado necesario previo a las actividades de implementación.
• Implementación. Actividades de codificación del software que de acuerdo al diseño, cumplen con los requisitos del sistema.
• Pruebas. Comprobaciones hechas a todos los elementos que se producen (documentos, diseños o código) para ver que cumplen con los requisitos y con los estándares de calidad definidos para el proyecto.
• Despliegue. Actividades que permiten tener el sistema instalado en los entornos en que finalmente va a ser explotado.
• Gestión de configuración. Gestión de los cambios y todos los elementos que intervienen en el proceso de construcción
• Gestión del proyecto. Actividades encaminadas a la gestión del desarrollo en cuanto a planes, recursos, seguimiento y control y gestión de riesgos.
• Entorno. Actividades que van encaminadas a dotar al proyecto de recursos hardware y software para facilitar la puesta en marcha y mantenimiento de los distintos entornos de desarrollo y pruebas o la propia puesta en producción del sistema.

RUP establece lo que denomina buenas prácticas como forma de trabajo adecuada para la consecución de objetivos que se pueden ir perfeccionando. Son las siguientes:

• Desarrollo iterativo que permita planificar desarrollos incrementales y entregas priorizando requisitos de modo que se entreguen antes las necesidades del usuario con mayor prioridad.
• Gestión de los requisitos: Documentar los requisitos y los cambios de los requisitos y analizar el impacto de cambios antes de aceptarlos.
• Emplear arquitecturas basadas en componentes para maximizar el aprovechamiento de desarrollos previos o componentes preconstruidos y abaratar los costes.
• Modelar visualmente el software empleando el estándar UML.
• Verificar la calidad de los productos del software asegurando que cumple los estándares de la compañía.
• Controlar los cambios del software.

Finalmente, cabe indicar que el modelo establece que el propio proceso es adaptable a cada caso de desarrollo. Por ejemplo, no todos los proyectos requieren del mismo nivel de documentación. El tamaño, la complejidad y el número de participantes entre otros aconsejan definir para el proyecto cómo adaptar el proceso. En la adaptación se definen qué artefactos hay que producir y en qué detalle, qué roles intervienen y las funciones que desempeñan dentro del proyecto, etc.