En 1998, Rational Software Corporation lanza el Proceso Unificado de Rational (RUP) y un año después Grady Booch, Ivar Jacobson y James Rumbaugh publican el libro El Proceso Unificado de Desarrollo de Software [1] donde regalan al mundo el proceso que hasta entonces había sido propiedad exclusiva de la compañía.
El Proceso Unificado es un marco de trabajo genérico que puede especializarse ─reducirse o ampliarse─ para una gran variedad de sistemas, dominios, organizaciones, niveles de aptitud y tamaños de proyecto. Dada su naturaleza, han ido apareciendo multitud de configuraciones del proceso, siendo RUP la más conocida y mejor documentada. Sin embargo, existen muchas otras, como aquellas orientadas a simplificarlo, entre las que se pueden citar el Proceso Unificado Abierto, el Proceso Unificado Ágil o el Proceso Unificado Esencial; y otras como el Proceso Unificado Empresarial que lo amplían. Unas 13 000 empresas de todo el mundo usan RUP1.
1 Datos según Enlyft recogidos hace seis años de aquellas empresas poseedoras del producto IBM Rational Unified Process. No se puede saber quien lo usa actualmente (podrían ser menos) y en absoluto se requiere comprar la herramienta de IBM para aplicar RUP (podrían ser más). https://enlyft.com/tech/products/ibm-rational-unified-process
El Proceso Unificado se caracteriza por ser un proceso dirigido por casos de uso, centrado en la arquitectura e iterativo e incremental.
Dirigido por casos de uso
Un caso de uso en una secuencia de acciones (interacción) entre el usuario y el sistema en desarrollo que proporciona al primero un resultado importante. El término usuario engloba no solo a las personas sino también a los sistemas externos, lo cual es un matiz importante ya que el Proceso Unificado persigue que el sistema resultante esté formado por componentes conectados mediante interfaces bien definidas.
Los casos de uso, ciertamente, representan los requisitos funcionales del sistema. Dado que están basados en la interacción con el usuario, fuerzan a pensar en lo importante para él y no a divagar en aquello que sería bueno que tuviera el sistema.
Sin embargo, los casos de uso son mucho más que una herramienta para especificar los requisitos, ya que guían el proceso. El hilo conductor del Proceso Unificado se basa en analizar, diseñar, programar y probar cada caso de uso mediante la definición de actividades que explican cómo hacerlo, pero que carecen de carácter normativo. Como marco de trabajo genérico que es, se podrá elegir entre hacerlas todas o un pequeño subconjunto. Esto es incluso aplicable a casos de uso pertenecientes a un mismo proyecto.
Aunque los casos de uso guían el proceso, no se desarrollan de manera aislada sino a la vez que la arquitectura del sistema, la cual influye en la selección de los casos de uso a realizar. Esto implica que los primeros casos que se completen no van a estar seleccionados únicamente en función de los deseos del cliente, sino ─principalmente─ en función del riesgo que impliquen para el desarrollo y su importancia para definir la arquitectura. En mi experiencia, confieso que casi siempre coinciden unos y otros pues para la primera entrega el cliente suele solicitar aquella funcionalidad básica, nuclear, esencial del sistema que, casualmente, coincide con aquellos casos de uso que ayudan a definir su arquitectura.
Centrado en la arquitectura
La arquitectura en una vista del diseño completo que destaca sus características más importantes obviando los detalles. La arquitectura se ve influida por muchos factores como el sistema operativo, el sistema gestor de base de datos, los protocolos de comunicaciones, los componentes de terceros, el uso de sistemas heredados y los requisitos no funcionales. El Proceso Unificado ayuda a que la arquitectura se centre en objetivos como la sencillez, la adaptación al cambio y la reutilización.
Los casos de uso deben encajar en la arquitectura y la arquitectura debe permitir el desarrollo de todos los casos de uso conocidos y venideros. Este circulo vicioso no parece fácil de romper. Sin embargo, las funciones claves de un sistema normalmente supondrán únicamente entre el 5 y el 10 % de los caso de uso totales. Por ejemplo, casos del tipo petición-respuesta a una base de datos puede haber muchos pero, parece claro, que cualquiera de ellos puede seleccionarse como caso de uso clave para guiar la arquitectura. Cuantos más casos de uso se especifican, más se sabe de la arquitectura que, a su vez, conduce a la maduración de más casos de uso. Por ejemplo, habiendo detallado uno de los casos de uso tipo petición-respuesta, será muy fácil encajar en la arquitectura todos aquellos pertenecientes a la misma familia.
En resumen, los casos de uso y la arquitectura evolucionan en paralelo hasta llegar a un punto donde la arquitectura es estable.
Iterativo e incremental
El Proceso Unificado está dividido en iteraciones ─pequeñísimos proyectos─ que resultan en un incremento ─crecimiento─ del producto. Cada iteración trata un grupo de casos de uso que amplían la utilidad del producto basándose en los artefactos ─diagramas de análisis y diseño, código de producción y pruebas, etc.─ tal y como quedaron al final de la última iteración.
No todas las iteraciones añaden el mismo grado de funcionalidad al sistema en desarrollo. Las primeras hacen más hincapié en los requisitos, el análisis y el diseño dando lugar a una realización completa de muy pocos casos de uso, ya que se busca la arquitectura. Las siguientes sí son típicamente aditivas buscando la realización de casos de uso completos.
Esta distinción entre iteraciones hace que el proceso se divida en cuatro fases, cada una de las cuales termina con un hito determinado por la creación de un conjunto de artefactos:
- Inicio. Se busca respuesta a las funciones principales del sistema, cómo podría ser la arquitectura ─un mero esbozo con los subsistemas más importantes─, cuál es el plan del proyecto y cuánto podría costar desarrollar el producto.
- Elaboración. Se especifican en detalle parte de los casos de uso y se diseña la arquitectura del sistema culminando la fase con una línea base de la misma. Llegados a este punto, la organización deberá estimar el personal y recursos necesarios para terminar el proyecto, además de responderse si los casos de uso, la arquitectura y el plan son lo suficientemente estables y los riesgos están controlados como para ser capaces de comprometerse al desarrollo mediante un contrato.
- Construcción. Cada iteración amplía la funcionalidad del sistema mediante la realización de los casos de uso que ampliarán la línea base de la arquitectura hasta el sistema completo. Al final de esta fase, el producto contiene todos los casos de uso pactados entre el cliente y la organización y el sistema completo está listo para la entrega.
- Transición. Se pasa de la versión alfa a la versión beta. El equipo corrige los defectos que pudieran encontrarse e incorpora las mejoras sugeridas por los usuarios. También aquí se elaboran los manuales, cursos de formación, se proporciona formación al cliente in situ, etc.
Uno de los mayores errores que se cometen a la hora de aplicar el Proceso Unificado es hacer corresponder sus cuatro fases con una gran cascada. Pensar que la fase de inicio se ocupa de los requisitos, elaboración del diseño, construcción de la programación y transición de las pruebas en una monstruosidad que anula las virtudes de este proceso.
Si el Proceso Unificado consta de cuatro fases es porque cada una de ellas termina con un gran hito y se centra en unas actividades más que en otras. Esto no implica que, por ejemplo, en la fase de elaboración no se programe ni se pruebe pese a que el análisis de requisitos y el análisis y diseño orientado a objetos sean la actividades de más peso (véase la figura). La consecución de una línea base de la arquitectura, por fuerza, implica escribir código que debe probarse, lo cual se hace completando unos pocos casos de uso que permite el despliegue del sistema, pues éste ya es operativo aunque tenga una funcionalidad mínima.
Referencias
[1] Ivar Jacobson, Grady Booch y James Rumbaugh. El Proceso Unificado de Desarrollo de Software. Addison Wesley, 2000.
Fotografía de la entrada por Elnaz Asadi en Unsplash
