Introducción
El Proceso Unificado es un
proceso de software genérico que puede ser utilizado para una gran cantidad de
tipos de sistemas de software, para diferentes áreas de aplicación, diferentes
tipos de organizaciones, diferentes niveles de competencia y diferentes tamaños
de proyectos.
Provee un enfoque disciplinado
en la asignación de tareas y resposabilidades dentro de una organización de
desarrollo. Su meta es asegurar la producción de software de muy alta calidad
que satisfaga las necesidades de los usuarios finales, dentro de un calendario
y presupuesto predecible.
El Proceso Unificado tiene dos dimensiones (Figura 1):
·
Un
eje horizontal que representa el tiempo y muestra los aspectos del ciclo de
vida del proceso a lo largo de su desenvolvimiento
·
Un
eje vertical que representa las disciplinas, las cuales agrupan actividades de
una manera lógica de acuerdo a su naturaleza.
La primera dimensión
representa el aspecto dinámico del proceso conforme se va desarrollando, se
expresa en términos de fases, iteraciones e hitos (milestones).
La segunda dimensión
representa el aspecto estático del proceso: cómo es descrito en términos de
componentes del proceso, disciplinas, actividades, flujos de trabajo,
artefactos y roles.
El Proceso Unificado se basa
en componentes (component-based), lo que significa que el sistema en
construcción está hecho de componentes de software interconectados por medio de
interfaces bien definidas (well-defined interfaces).
El Proceso Unificado usa el
Lenguaje de Modelado Unificado (UML) en la preparación de todos los planos del
sistema. De hecho, UML es una parte integral del Proceso Unificado, fueron
desarrollados a la par.
Los aspectos distintivos del
Proceso Unificado están capturados en tres conceptos clave: dirigido por casos
de uso (use-case driven), centrado en la arquitectura (architecture-centric),
iterativo e incremental. Esto es lo que hace único al Proceso Unificado.
El Proceso Unificado es dirigido
por casos de uso
Un sistema de software se crea
para servir a sus usuarios. Por lo tanto, para construir un sistema exitoso se
debe conocer qué es lo que quieren y necesitan los usuarios prospectos.
El término usuario se refiere
no solamente a los usuarios humanos, sino a otros sistemas. En este contexto,
el término usuario representa algo o alguien que interactúa con el sistema por
desarrollar.
Un caso de uso es una pieza en la funcionalidad del sistema que le da
al usuario un resultado de valor. Los casos de uso capturan los requerimientos
funcionales. Todos los casos de uso juntos constituyen el modelo de casos de uso el cual describe la funcionalidad completa
del sistema. Este modelo reemplaza la tradicional especificación funcional del
sistema. Una especificación funcional tradicional se concentra en responder la
pregunta: ¿Qué se supone que el sistema debe hacer? La estrategia de casos de
uso puede ser definida agregando tres palabras al final de la pregunta: ¿por
cada usuario? Estas tres palabras tienen una implicación importante, nos
fuerzan a pensar en términos del valor a los usuarios y no solamente en
términos de las funciones que sería bueno que tuviera. Sin embargo, los casos
de uso no son solamente una herramienta para especificar los requerimientos del
sistema, también dirigen su diseño, implementación y pruebas, esto es, dirigen
el proceso de desarrollo.
Aún y cuando los casos de uso
dirigen el proceso, no son elegidos de manera aislada. Son desarrollados a la
par con la arquitectura del sistema, esto es, los casos de uso dirigen la
arquitectura del sistema y la arquitectura del sistema influencia la elección
de los casos de uso. Por lo tanto, al arquitectura del sistema y los casos de
uso maduran conforme avanza el ciclo de vida.
El Proceso Unificado está
centrado en la arquitectura
El papel del arquitecto de
sistemas es similar en naturaleza al papel que el arquitecto desempeña en la
construcción de edificios. El edificio se mira desde diferentes puntos de
vista: estructura, servicios, plomería, electricidad, etc. Esto le permite al
constructor ver una radiografía completa antes de empezar a construir.
Similarmente, la arquitectura en un sistema de software es descrita como
diferentes vistas del sistema que está siendo construido.
El concepto de arquitectura de
software involucra los aspectos estáticos y dinámicos más significativos del
sistema. La arquitectura surge de las necesidades de la empresa, tal y como las
interpretan los usuarios y otros stakeholders, y tal y como están reflejadas en
los casos de uso. Sin embargo, también está influenciada por muchos otros
factores, tales como la plataforma de software en la que se ejecutará, la
disponiblidad de componentes reutilizables, consideraciones de instalación,
sistemas legados, requerimientos no funcionales (ej. desempeño, confiabilidad).
La arquitectura es la vista del diseño completo con las características más
importantes hechas más visibles y dejando los detalles de lado. Ya que lo
importante depende en parte del criterio, el cual a su vez viene con la
experiencia, el valor de la arquitectura depende del personal asignado a esta
tarea. Sin embargo, el proceso ayuda al arquitecto a enfocarse en las metas
correctas, tales como claridad (understandability), flexibilidad en los cambios
futuros (resilience) y reuso.
¿Cómo se relacionan los casos
de uso con la arquitectura? Cada producto tiene función y forma. Uno sólo de
los dos no es suficiente. Estas dos fuerzas deben estar balanceadas para
obtener un producto exitoso. En este caso función corresponde a los casos de
uso y forma a la arquitectura. Existe la necesidad de intercalar entre casos de
uso y arquitectura. Es un problema del “huevo y la gallina”. Por una parte, los
casos de uso deben, cuando son realizados, acomodarse en la arquitectura. Por
otra parte, la arquitectura debe proveer espacio para la realización de todos
los casos de uso, hoy y en el futuro. En la realidad, ambos arquitectura y
casos de uso deben evolucionar en paralelo.
El Proceso Unificado es
Iterativo e Incremental
Desarrollar un producto de software comercial
es una tarea enorme que puede continuar por varios meses o años. Es práctico
dividir el trabajo en pequeños pedazos o mini-proyectos. Cada mini-proyecto es
una iteración que finaliza en un incremento. Las iteraciones se refieren a
pasos en el flujo de trabajo, los incrementos se refieren a crecimiento en el
producto. Para ser más efectivo, las iteraciones deben estar controladas, esto
es, deben ser seleccionadas y llevadas a cabo de una manera planeada.
Los desarrolladores basan su
selección de qué van a implementar en una iteración en dos factores. Primero,
la iteración trata con un grupo de casos de uso que en conjunto extienden la
usabilidad del producto. Segundo, la iteración trata con los riesgos más
importantes. Las iteraciones sucesivas construyen los artefactos del desarrollo
a partir del estado en el que fueron dejados en la iteración anterior.
En cada iteración, los
desarrolladores identifican y especifican los casos de uso relevantes, crean el
diseño usando la arquitectura como guía, implementan el diseño en componentes y
verifican que los componentes satisfacen los casos de uso. Si una iteración
cumple sus metas – y usualmente lo hace – el desarrollo continúa con la siguiente
iteración. Cuando la iteración no cumple con sus metas, los desarrolladores
deben revisar sus decisiones previas y probar un nuevo enfoque.
Conclusión
Los conceptos anteriormente
tratados – dirigido por casos de uso, centrado en arquitectura, desarrollo
iterativo e incremental – son igualmente importantes. La arquitectura provee la
estructura sobre la cual guiar el trabajo en iteraciones, mientras que los
casos de uso definen las metas y dirigen el trabajo en cada iteración. Remover
cualquiera de estos conceptos reducirá severamente el valor del Proceso
Unificado. Es como una mesa de tres patas, sin alguna de ellas, la mesa se
caerá.
