El Proceso
Unificado de Desarrollo de Software (RUP)
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á.
