Este 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
- 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.
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.
En RUP se tienen principios fundamentales de desarrollo que son:
Adaptar el proceso
Lo que se refiere a que los procesos deben de adaptarse al tamaño de los proyectos o de la organización.
Balancear prioridades
Se debe de encontrar un balance que satisfaga los deseos de todos
Colaboracion entre equipos
Los proyectos de desarrollo de Sw no son llevados a cabo por una sola persona, sino varias o varios equipos de desarrollo, los cuales deben de contar con una buena comunicación para que esto les permita coordinar esfuerzos.
Demostrar valor iterativamente
Los proyectos aunque sea de manera interna deben de entregarse de manera iterada en cada iteracion se analiza el avance, estabilidad, calidad del producto.
Elevar el nivel de abstracción
Esto previene a los ingenieros de Sw ir directamente de los requerimientos del cliente a la codificacion, un nivel alto de abstraccion permite discusiones sobre diversos niveles de arquitectura, los cuales se pueden acompañar por representaciones visuales de la arquitectura como por ejemplo utilizando UML.
Enfocarse a la calidad
El control de calidad deberá de ser llevado a cabo no solo al final de cada iteracion sino a todo lo largo de toda la producción.
EL CICLO DE VIDA
Concepcion: aquí empieza el proyecto con el desarrollo de los casos de uso y la identificación de riesgos.
Elaboración: Elaboracion de planes, se completan los casos de uso y se eliminan los riesgos.
Construcción: desarrollo del proyecto y elaboracion del manual de usuario, el cual estará dividido en varias iteraciones.
Imlementacion: Instalacion, entrenamiento de usuarios.
PRINCIPALES CARACTERISTICAS DE RUP
- Forma disciplinada de asignar tareas y responsabilidades
- Pretende implementar mejores practicas
- Desarrollo iterativo
- Uso de la arquitectura basada en componentes
- Control de cambios
- Modelado visual
- Verificacion de la calidad de Sw
La metodologia RUP es mas apropiada para empresas grandes y proyectos del mismo tamaño ya que se tienen que manejar procesos complejos y un desarrollo iterativo, en proyectos pequeños es posible que no sea posible cubrir los costos de dedicacion del equipo de profecionales, ya que tendrían que invertir una gran cantidad de horas y esfuerzo para hacer las cosas segun lo que dicen los procesos.
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á.
