El Proceso Unificado de Desarrollo de Software (RUP)

Introduccin
El Proceso Unificado es un proceso de software genrico que puede ser utilizado para una gran cantidad de tipos de sistemas de software, para diferentes reas de aplicacin, diferentes tipos de organizaciones, diferentes niveles de competencia y diferentes tamaos de proyectos. Provee un enfoque disciplinado en la asignacin de tareas y resposa ilidades dentro de una organizacin de desarrollo. !u meta es asegurar la produccin de software de muy alta calidad que satisfaga las necesidades de los usuarios finales, dentro de un calendario y presupuesto predeci le. El Proceso Unificado tiene dos dimensiones "#igura $%& Un e'e (orizontal que representa el tiempo y muestra los aspectos del ciclo de vida del proceso a lo largo de su desenvolvimiento Un e'e vertical que representa las disciplinas, las cuales agrupan actividades de una manera lgica de acuerdo a su naturaleza.

)a primera dimensin representa el aspecto dinmico del proceso conforme se va desarrollando, se e*presa en trminos de fases, iteraciones e (itos "milestones%. )a segunda dimensin representa el aspecto esttico del proceso& cmo es descrito en trminos de componentes del proceso, disciplinas, actividades, flu'os de tra a'o, artefactos y roles.

#igura $ El Proceso Unificado se asa en componentes "component+ ased%, lo que significa que el sistema en construccin est (ec(o de componentes de software interconectados por medio de interfaces ien definidas "well+defined interfaces%. El Proceso Unificado usa el )engua'e de ,odelado Unificado "U,)% en la preparacin de todos los planos del sistema. -e (ec(o, U,) es una parte integral del Proceso Unificado, fueron desarrollados a la par. )os aspectos distintivos del Proceso Unificado estn capturados en tres conceptos clave& dirigido por casos de uso "use+case driven%, centrado en la arquitectura "arc(itecture+ centric%, iterativo e incremental. Esto es lo que (ace .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 e*itoso se de e conocer qu es lo que quieren y necesitan los usuarios prospectos. El trmino usuario se refiere no solamente a los usuarios (umanos, sino a otros sistemas. En este conte*to, el trmino 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. )os casos de uso capturan los requerimientos funcionales. /odos los

casos de uso 'untos constituyen el modelo de casos de uso el cual descri e la funcionalidad completa del sistema. Este modelo reemplaza la tradicional especificacin funcional del sistema. Una especificacin funcional tradicional se concentra en responder la pregunta& 01u se supone que el sistema de e (acer2 )a estrategia de casos de uso puede ser definida agregando tres pala ras al final de la pregunta& 0por cada usuario2 Estas tres pala ras tienen una implicacin importante, nos fuerzan a pensar en trminos del valor a los usuarios y no solamente en trminos de las funciones que ser3a ueno que tuviera. !in em argo, los casos de uso no son solamente una (erramienta para especificar los requerimientos del sistema, tam in dirigen su diseo, implementacin y prue as, esto es, dirigen el proceso de desarrollo. 4.n y cuando los casos de uso dirigen el proceso, no son elegidos de manera aislada. !on 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 eleccin 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 desempea en la construccin de edificios. El edificio se mira desde diferentes puntos de vista& estructura, servicios, plomer3a, electricidad, etc. Esto le permite al constructor ver una radiograf3a completa antes de empezar a construir. !imilarmente, 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 estticos y dinmicos ms significativos del sistema. )a arquitectura surge de las necesidades de la empresa, tal y como las interpretan los usuarios y otros sta5e(olders, y tal y como estn refle'adas en los casos de uso. !in em argo, tam in est influenciada por muc(os otros factores, tales como la plataforma de software en la que se e'ecutar, la disponi lidad de componentes reutiliza les, consideraciones de instalacin, sistemas legados, requerimientos no funcionales "e'. desempeo, confia ilidad%. )a arquitectura es la vista del diseo completo con las caracter3sticas ms importantes (ec(as ms visi les y de'ando los detalles de lado. 6a que lo importante depende en parte del criterio, el cual a su vez viene con la e*periencia, el valor de la arquitectura depende del personal asignado a esta tarea. !in em argo, el proceso ayuda al arquitecto a enfocarse en las metas correctas, tales como claridad "understanda ility%, fle*i ilidad en los cam ios futuros "resilience% y reuso. 07mo se relacionan los casos de uso con la arquitectura2 7ada producto tiene funcin y forma. Uno slo de los dos no es suficiente. Estas dos fuerzas de en estar alanceadas para o tener un producto e*itoso. En este caso funcin corresponde a los casos de uso y forma a la arquitectura. E*iste la necesidad de intercalar entre casos de uso y arquitectura. Es un pro lema del 8(uevo y la gallina9. Por una parte, los casos de uso de en, cuando son realizados, acomodarse en la arquitectura. Por otra parte, la arquitectura

de e proveer espacio para la realizacin de todos los casos de uso, (oy y en el futuro. En la realidad, am os arquitectura y casos de uso de en evolucionar en paralelo.

El Proceso Unificado es Iterativo e Incremental

-esarrollar un producto de software comercial es una tarea enorme que puede continuar por varios meses o aos. Es prctico dividir el tra a'o en pequeos pedazos o mini+proyectos. 7ada mini+proyecto es una iteracin que finaliza en un incremento. )as iteraciones se refieren a pasos en el flu'o de tra a'o, los incrementos se refieren a crecimiento en el producto. Para ser ms efectivo, las iteraciones de en estar controladas, esto es, de en ser seleccionadas y llevadas a ca o de una manera planeada. )os desarrolladores asan su seleccin de qu van a implementar en una iteracin en dos factores. Primero, la iteracin trata con un grupo de casos de uso que en con'unto e*tienden la usa ilidad del producto. !egundo, la iteracin trata con los riesgos ms importantes. )as iteraciones sucesivas construyen los artefactos del desarrollo a partir del estado en el que fueron de'ados en la iteracin anterior. En cada iteracin, los desarrolladores identifican y especifican los casos de uso relevantes, crean el diseo usando la arquitectura como gu3a, implementan el diseo en componentes y verifican que los componentes satisfacen los casos de uso. !i una iteracin cumple sus metas : y usualmente lo (ace : el desarrollo contin.a con la siguiente iteracin. 7uando la iteracin no cumple con sus metas, los desarrolladores de en revisar sus decisiones previas y pro ar un nuevo enfoque.