2. INTRODUCCIÓN
En este tema se describe a groso modo el proceso unificado, indicando sus características generales. Por
otra pare, en el de este tema, y, en general, en el contexto del proceso de desarrollo de un sistema
informático, se entiende por proceso “el conjunto de pasos ordenados que se realizan para alcanzar un
objetivo”.
El Proceso Unificado (PU) puede verse como una metodología adaptable. Esto quiere decir que se puede
modificar para adaptarlo al sistema concreto que se va a desarrollar en cada momento. Por otra parte se
puede decir que el PU es una técnica para elaborar modelos1 que se adapta especialmente a UML. Su
objetivo es producir un software de calidad. Por definición, PU utiliza buenas prácticas de desarrollo, siendo
adaptable a un amplio rango de aplicaciones y sistemas. Este proceso no sólo considera aspectos de
desarrollo de un sistema, sino también los de gestión del mismo.

3. PROCESO UNIFICADO
El Proceso Unificado es un proceso de desarrollo de software.
Un proceso de desarrollo de software es un conjunto de actividades necesarias para transformar los
requerimientos del usuario en un sistema de software.
El Proceso Unificado de Desarrollo Software o simplemente Proceso Unificado es un marco de
desarrollo de software que se caracteriza por estar dirigido por casos de uso, centrado en la arquitectura y
por ser iterativo e incremental. El refinamiento más conocido y documentado del Proceso Unificado es el
Proceso Unificado de Rational o simplemente RUP.
El Proceso Unificado no es simplemente un proceso, sino un marco de trabajo extensible que puede ser
adaptado a organizaciones o proyectos específicos. De la misma forma, el Proceso Unificado de Rational,
también es un marco de trabajo extensible, por lo que muchas veces resulta imposible decir si un
refinamiento particular del proceso ha sido derivado del Proceso Unificado o del RUP. Por dicho motivo, los
dos nombres suelen utilizarse para referirse a un mismo concepto.
Características generales del Proceso Unificado
- Soporta técnicas orientadas a objeto, por lo que se basa en los conceptos de clase y objeto y las
relaciones entre ellos, usando UML como notación común.
- Es una metodología que sigue un proceso iterativo e incremental. Propone una descomposición
incremental del problema a través de refinamientos sucesivos y una producción incremental de la solución,
a través de la realización de varios ciclos. Esta filosofía es lógica cuando se aplica a sistemas grandes ya
que “no se puede abarcar todo a la vez”.
- El PU (figura 1) tiene 4 fases o incrementos y en cada uno se consideran distintos flujos de trabajo
(workflow) o modelos que suponen mayor o menor número de horas de trabajo dependiendo de la fase
incremental en la que se encuentre el desarrollo. Cada incremento consta de todos los pasos de un ciclo de
vida completo, que se repiten (iteración) hasta obtener el desarrollo exacto del sistema.
Para ello se hacen diagramas cada vez más precisos: el proceso es repetitivo – iterativo- y cada vez se
amplía y detalla más –incremental. En el apartado 2 se hace un estudio más detallado del ciclo de vida
iterativo e incremental.
- El PU está dirigido por el riesgo. Esta es una de las características fundamentales del este modelo, y
propone identificar, afrontar y resolver los elementos de riesgo lo más pronto posible. En etapas iniciales se
desarrollan las funcionalidades con mayor riesgo y las de mayor complejidad. De este modo se mejoran las
posibilidades de éxito del proyecto.
- Se utilizan modelos gráficos de representación más que documentación, en particular se usan diagramas
UML que son representaciones expresivas y pueden aplicarse durante todo el desarrollo.
- El PU está centrado en la arquitectura software. La arquitectura del software para el sistema en
desarrollo se define al principio y guía su desarrollo. Propone la definición de una arquitectura robusta, lo
que facilita el desarrollo del sistema en paralelo, aumentando las posibilidades de reutilización de
componentes y el mantenimiento del sistema. El diseño arquitectónico aporta una base sólida sobre
la que planificar y gestionar el desarrollo software basado en componentes. Al basarse en la definición de
una arquitectura clara y sencilla, el PU sirve de marco común para toda una familia de procesos y que
puede acomodarse a distintas situaciones. Para ello, el PU da las guías para configurar el proceso de modo
que se adapte a cada situación.
- EL PU está dirigido por los casos de uso. Esto es así porque el PU pone gran énfasis en la construcción
de sistemas basados en la comprensión de cómo se va a utilizar ese sistema. Así, los casos de uso y los
escenarios se usan para guiar el flujo de procesos, desde la definición de los requisitos hasta las pruebas.
- El PU es un proceso adaptable a los distintos tipos de desarrollo y se puede configurar dependiendo de
las necesidades de cada proyecto (desde los más sencillos a los más complejos).
- Control continuo de la calidad. El PU propone llevar un adecuado control de calidad y una adecuada
gestión de riesgos. Ambos conceptos están incluidos en el propio proceso, formando parte de sus
actividades.
- La filosofía del Proceso Unificado es empezar a trabajar en el desarrollo con un conocimiento relativo del
problema, a partir de él se hacen los primeros diagramas. A medida que se va conociendo más el problema,
los diagramas se hacen más precisos (en cada iteración) para ampliarlos después (incremento). El proceso
se repite hasta asegurarse que los diagramas realizados son una expresión exacta del sistema de
información a desarrollar.

4. FASES DEL PROCESO UNIFICADO
FASE 1. INICIO.
El objetivo de esta fase es determinar si merece la pena desarrollar el sistema en estudio (estudiar su
viabilidad). Por tanto, durante esta fase se establecen los objetivos del proyecto, se realiza su la
planificación y se determina su alcance. Al hacer la planificación hay que considerar: los criterios de éxito
del proyecto; hacer una adecuada estimación de recursos; hacer una evaluación del riesgo; y definir un plan
de trabajo, identificando los diversos hitos del proyecto.
Flujos de trabajo en esta fase:
El desarrollo de esta fase supone empezar por el flujo de trabajo (workflow) de requisitos, en cuyo inicio se
debe comprender el dominio del problema y luego, construir el modelo de negocio (cómo la empresa realiza
los negocios en ese dominio).
En esta fase se realiza también el diagrama de casos de usos inicial, dentro del flujo de trabajo de requisitos
y del modelo de negocio. Si el sistema es grande también se les da una prioridad en función del riesgo que
suponga su desarrollo, de modo que los que sean críticos se consideren antes.
Al final de la fase de inicio se examinan los objetivos del proyecto y se determina si se continúa o no. Para
ello, es necesario que durante el desarrollo de fase se haya considerado lo siguiente: Estudio de viabilidad
del sistema que se va a desarrollar, una estimación de la duración del desarrollo y una estimación de
riesgos. Esto se hace también durante el flujo de trabajo de requisitos.
Además, una pequeña parte del flujo de trabajo de análisis se realiza también en esta fase. En este
apartado, se hace el análisis de los casos de uso críticos, para que pueda empezarse el diseño de la
arquitectura.
Durante la fase de inicio, igualmente empieza a desarrollarse el flujo de trabajo de implementación, aunque
no se suele realizar ninguna codificación. Sin embargo, a veces, se construye un prototipo para probar la
viabilidad de parte del sistema propuesto. No es un prototipo rápido construido para asegurar que los
requisitos se han determinado con precisión, sino que es más una maqueta de ingeniería, es decir, un
modelo a escala para probar la factibilidad de la construcción.
El flujo de trabajo de pruebas comienza casi al principio de esta fase. Su objetivo es asegurar que los
requisitos se hayan determinado con precisión.
Documentación obtenida al final de esta fase:
La versión inicial del modelo de dominio.
La versión inicial del modelo de negocio.
La versión inicial del modelo de los artefactos de los requisitos (diagrama de casos de usos).
Una versión preliminar de los artefactos del análisis.
Una versión preliminar de la arquitectura.
La lista inicial de los riesgos.
El plan de trabajo para la fase siguiente.
La versión inicial de caso de negocios.
FASE 2. ELABORACION.
Objetivos de esta fase y flujos de trabajo asociados:
El propósito de esta fase es establecer una base arquitectónica sólida para el sistema sobre la que se
asentará la fase de construcción. Las decisiones sobre la arquitectura del sistema se deben tomar
considerando el proyecto de un modo global. Esto supone describir los requisitos fundamentales del sistema
y de mayor peso identificados en fases anteriores. También se tendrá que hacer una evaluación de los
riesgos. Para verificar la arquitectura se implementa un sistema (prototipo de la arquitectura) que demuestre
las posibilidades de la arquitectura y ejecute los casos de uso más significativos. Los objetivos se pueden
enumerar como sigue:
1. Analizar el dominio del problema: esto supone refinar los requisitos iniciales (expresados en el diagrama
de casos de uso). Se realiza dentro del flujo de trabajo de requisitos.
2. Eliminar (o resolver) los elementos de más alto riesgo del proyecto: es decir, refinar sus prioridades. Se
realiza dentro del flujo de trabajo de análisis.
3. Desarrollar el plan de trabajo para el proyecto.
Al final de la fase se examinan el alcance y objetivos del sistema, la arquitectura elegida, y la solución de los
riesgos mayores. Igualmente se decide si se pasa a la fase siguiente.
Documentación obtenida al final de esta fase:
Modelo de dominio terminado.
Modelo de negocio terminado.
Los artefactos de los requisitos terminados.

5. Los artefactos de análisis terminados.
Una versión revisada de la arquitectura.
La lista revisada y refinada de los riesgos.
El plan de administración del proyecto para el resto de fases.
El caso de negocios terminado.
FASE 3. CONSTRUCCION.
En esta fase se desarrolla iterativamente y de modo incremental un producto completo preparado para la
siguiente fase. Esto supone describir los restantes objetivos, los criterios de aceptación, y refinado del
diseño. Se completan la implementación y las pruebas. Para ello, se describen los requisitos no
desarrollados antes y se completa el desarrollo del sistema basándose en la arquitectura definida.
Flujos de trabajo en esta fase:
El peso de esta fase lo lleva el desarrollo del flujo de trabajo de implementación y de pruebas. Dentro del
flujo de trabajo de implementación se codifican los distintos módulos obtenidos en el diseño detallado. A
estos módulos se les aplican las pruebas unitarias (flujo de trabajo de pruebas). Luego los módulos se
compilan y se integran para formar subsistemas a los que se les aplican las pruebas de integración. Por otra
parte los diversos subsistemas que formen el sistema en desarrollo se combinan para formar el sistema
completo, al que se le aplican las pruebas de aceptación. Al final de la fase se obtiene la primera versión
operativa y con la calidad suficiente para el sistema desarrollado (a veces se llama versión beta).
La carga de trabajo de esta fase la soportan, en su mayoría, los programadores y el equipo de control de
calidad, aunque los diseñadores llevan a cabo el rediseño del sistema. Si se detectara algún fallo que
requiera modificaciones en los elementos previos de los flujos de trabajo, los analistas también tendrían que
intervenir para revisar esos elementos o cambiar los requisitos que han provocado el error.
Al final de la fase se decide si todo está preparado para la instalación del sistema (el software acabado,
localización del sistema y usuarios preparados).
Documentación obtenida al final de esta fase:
Manual de usuario inicial y otros manuales necesarios.
Todos los artefactos (versión beta).
La arquitectura terminada
La lista de riesgos actualizada.
El plan de administración del proyecto para el resto de fases.
El caso de negocios revisado, en caso necesario.
FASE 4. TRANSICIÓN.
El objetivo de esta fase es asegurar que los requisitos se han cumplido y que el software está disponible
para los usuarios finales. Por eso esta fase está dirigida por la retroalimentación de los usuarios, a partir de
la información que se deduzca de la versión beta del sistema en funcionamiento. Para ello:
Se corrigen los fallos que hubiera para lo cual se realizan las pruebas.
Se determinan los elementos que deban ajustarse (problemas no detectados, refinamiento y mejora
de algunas características) con un desarrollo adicional.
Se actualiza la documentación correspondiente.
Se deben descubrir riesgos no detectados anteriormente.
Los ajustes que se hagan serán específicos y de corto alcance. Ajustes estructurales mayores debieron
haberse resuelto anteriormente en el ciclo de vida y deberán documentarse para futuras ampliaciones.
Estando en marcha la versión beta del sistema, se reemplaza por el sistema definitivo que se despliega
entre los usuarios.
La carga de trabajo de esta fase la soportan los programadores (que hacen los cambios necesarios) y el
equipo de control de calidad (que prueba los cambios). Si los fallos que se detecten requieren cambios en
los flujos de trabajo de requisitos, del análisis o del diseño, los analistas también tendrían que intervenir.
Al final de la fase, se decide si se han cumplido los objetivos previstos y se puede determinar si es
necesario empezar otro ciclo de desarrollo. Por otra parte, se anotan las lecciones aprendidas, para
aplicarlas en próximos desarrollos.
Documentación obtenida al final de esta fase:
Todos los artefactos (versión final).
Los manuales completos.

6. ANEXOS
Figura 1 construcción de un sistema de información con 4 incrementos o fases.
BIBLIOGRAFÍA
Stephen R. Schach. D. Mc Graw Hill. ISBN 970-10-4982-9. 2005.