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 ms 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 especficos. De la misma forma, el Proceso
Unificado de Rational, tambin 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.
El nombre Proceso Unificado se usa para describir el proceso genrico que incluye aquellos
elementos que son comunes a la mayora de los refinamientos existentes. Tambin permite evitar
problemas legales ya que Proceso Unificado de Rational o RUP son marcas registradas por IBM
(desde su compra de Rational Software Corporation en 2003). El primer libro sobre el tema se
denomin, en su versin espaola, El Proceso Unificado de Desarrollo de Software (ISBN 84-7829-
036-2) y fue publicado en 1999 por Ivar Jacobson, Grady Booch y James Rumbaugh, conocidos
tambin por ser los desarrolladores del UML, el Lenguaje Unificado de Modelado. Desde entonces
los autores que publican libros sobre el tema y que no estn afiliados a Rational utilizan el trmino
Proceso Unificado, mientras que los autores que pertenecen a Rational favorecen el nombre de
Proceso Unificado de Rational.
ndice
1 Caractersticas
1.1 Iterativo e Incremental
1.2 Dirigido por los casos de uso
1.3 Centrado en la arquitectura
1.4 Enfocado en los riesgos
2 Lenguaje unificado de modelado
2.1 Por qu analizar y disear?
3 Vase tambin
4 Bibliografa
Caractersticas

Iterativo e Incremental
El Proceso Unificado es un marco de desarrollo iterativo e incremental compuesto de cuatro fases
denominadas Inicio, Elaboracin, Construccin y Transicin. Cada una de estas fases es a su vez
dividida en una serie de iteraciones (la de inicio puede incluir varias iteraciones en proyectos
grandes). Estas iteraciones ofrecen como resultado un incremento del producto desarrollado que
aade o mejora las funcionalidades del sistema en desarrollo.
Cada una de estas iteraciones se divide a su vez en una serie de disciplinas que recuerdan a las
definidas en el ciclo de vida clsico o en cascada: Anlisis de requisitos, Diseo, Implementacin y
Prueba. Aunque todas las iteraciones suelen incluir trabajo en casi todas las disciplinas, el grado de
esfuerzo dentro de cada una de ellas vara a lo largo del proyecto.


Diagrama ilustrando como el nfasis relativo en las distintas disciplinas cambia a lo largo del
proyecto.
Dirigido por los casos de uso
En el Proceso Unificado los casos de uso se utilizan para capturar los requisitos funcionales y para
definir los contenidos de las iteraciones. La idea es que cada iteracin tome un conjunto de casos
de uso o escenarios y desarrolle todo el camino a travs de las distintas disciplinas: diseo,
implementacin, prueba, etc. El proceso dirigido por casos de uso es el rup. Nota: en UP se est
Dirigido por requisitos y riesgos de acuerdo con el Libro UML 2 de ARLOW, Jim que menciona el
tema.
Centrado en la arquitectura
El Proceso Unificado asume que no existe un modelo nico que cubra todos los aspectos del
sistema. Por dicho motivo existen mltiples modelos y vistas que definen la arquitectura de
software de un sistema. La analoga con la construccin es clara, cuando construyes un edificio
existen diversos planos que incluyen los distintos servicios del mismo: electricidad, fontanera, etc.
Enfocado en los riesgos
El Proceso Unificado requiere que el equipo del proyecto se centre en identificar los riesgos
crticos en una etapa temprana del ciclo de vida. Los resultados de cada iteracin, en especial los
de la fase de Elaboracin deben ser seleccionados en un orden que asegure que los riesgos
principales son considerados primero.
Lenguaje unificado de modelado

El Lenguaje unificado de modelado no es el sucesor de la oleada de metodos de analisis y diseno
orientados a objetos que surgio a finales de la decada de los 1980 y principios de la siguiente. El
UML unifica, sobre todo, los metodos de Booch, Rumbaugh, Brhl (OMT) y Jacobson, pero su
alcance ha llegado a formar parte fundamental de la Ingeniera de Software tras su
estandarizacin en 1997 con el OMG (Object Management Group o Grupo de administracion de
objetos).
Por qu analizar y disear?
En resumidas cuentas, la cuestion fundamental del desarrollo del software es la escritura del
cdigo. Despus de todo, los diagramas son solo imagenes bonitas. Ningn usuario va a agradecer
la belleza de los dibujos; lo que el usuario quiere es software que funcione (UML Gota a Gota,
Addison Wesley, pg. 7). Por lo tanto, cuando considere usar el UML es importante preguntarse
por qu lo har y cmo le ayudar a usted cuando llegue el momento de escribir el cdigo. No
existe una evidencia emprica adecuada que demuestre si estas tcnicas son buenas o malas; pero
lo que s es cierto es que es de considerable ayuda para las etapas de mantenimiento en proyectos
de mediana/avanzada envergadura.















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
resposabilidades dentro de una organizacin de desarrollo. Su 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 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 lgica de acuerdo a su naturaleza.
La primera dimensin representa el aspecto dinmico del proceso
conforme se va desarrollando, se expresa en trminos de fases, iteraciones e hitos
(milestones).
La segunda dimensin representa el aspecto esttico del proceso: cmo es
descrito en trminos de componentes del proceso, disciplinas, actividades, flujos
de trabajo, artefactos y roles.


Figura 1
El Proceso Unificado se basa en componentes (component-based), lo que
significa que el sistema en construccin 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 preparacin 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 estn 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 trmino usuario se refiere no solamente a los usuarios humanos, sino a
otros sistemas. En este contexto, el trmino usuario representa algo o alguien que
interacta 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 especificacin funcional del sistema. Una especificacin
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 implicacin importante, nos fuerzan a pensar en trminos del
valor a los usuarios y no solamente en trminos de las funciones que sera bueno
que tuviera. Sin embargo, los casos de uso no son solamente una herramienta
para especificar los requerimientos del sistema, tambin dirigen su diseo,
implementacin y pruebas, esto es, dirigen el proceso de desarrollo.
An 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 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, plomera, electricidad, etc. Esto
le permite al constructor ver una radiografa 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 estticos y
dinmicos ms 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 estn reflejadas en los casos de uso. Sin embargo,
tambin est influenciada por muchos otros factores, tales como la plataforma de
software en la que se ejecutar, la disponiblidad de componentes reutilizables,
consideraciones de instalacin, sistemas legados, requerimientos no funcionales
(ej. desempeo, confiabilidad). La arquitectura es la vista del diseo completo
con las caractersticas ms importantes hechas ms 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.
Cmo se relacionan los casos de uso con la arquitectura? Cada producto
tiene funcin y forma. Uno slo de los dos no es suficiente. Estas dos fuerzas
deben estar balanceadas para obtener un producto exitoso. En este caso funcin
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 realizacin 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 aos. Es prctico dividir el trabajo en
pequeos pedazos o mini-proyectos. Cada mini-proyecto es una iteracin 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 ms
efectivo, las iteraciones deben estar controladas, esto es, deben ser seleccionadas
y llevadas a cabo de una manera planeada.
Los desarrolladores basan 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 conjunto extienden la usabilidad del producto. Segundo, la iteracin trata
con los riesgos ms importantes. Las iteraciones sucesivas construyen los
artefactos del desarrollo a partir del estado en el que fueron dejados en la
iteracin anterior.
En cada iteracin, los desarrolladores identifican y especifican los casos de
uso relevantes, crean el diseo usando la arquitectura como gua, implementan el
diseo en componentes y verifican que los componentes satisfacen los casos de
uso. Si una iteracin cumple sus metas y usualmente lo hace el desarrollo
contina con la siguiente iteracin. Cuando la iteracin no cumple con sus metas,
los desarrolladores deben revisar sus decisiones previas y probar un nuevo
enfoque.









1. Proceso de Desarrollo de Software: Proceso de negocio, o caso de uso de
negocio, de un negocio de desarrollo de software. Conjunto total de actividades
necesarias para transformar los requisitos de un cliente en un conjunto consistente de
artefactos que representan un producto software y en punto posterior en el tiempo para
transformar cambiso en dichos requisitos en nuevas versiones del producto.
2. Lenguaje Unificado de Modelado (UML): Lenguaje estandar para el modelado
de software lenguaje para visualizar, especificar, construir y documentar los artefactos
de un sistema con gran cantidad de software. Lenguaje usado por el Proceso Unificado.
Lenguaje que permite a los desarrolladores visualizar el producto de su trabajo
(Artefactos) en esquemas o diagramas estandarizados.
3. Proceso Unificado de Desarrollo de Software (PUDS): Proceso de desarrollo
de software basado en el Lenguaje Unificado de Modelado y que es iterativo, centrado en
la arquitectura y dirigido por los casos de uso y los riesgos. Proceso que se organiza en
cuatro fases: inicio, elaboracion, construccion y transicion, y que se estructura en torno
a cinco flujos de trabajo fundamentales: recopilacion de requisitos, analisis, diseo,
implementacion y pruebas. Proceso que se describe en terminos de un modelo de
negocio, el cual esta a su vez estructurado en funcion de tres bloques de construccion
primordiales trabajadores, actividades y artefactos.
4. Requisitos: Flujo de trabajo fundamental cuyo proposito esencial es orientado al
desarrollado hacia el sistema correcto. Esto se lleva a cabo mediante la descripcion de
los requisitos del sistema de forma tal que se pueda llegar a un acuerdo entre el
cliente(incluyendo los usuarios) y los desarrolladores del sistema, acerca de lo que el
sistema debe hacer y lo que no.
5. Analisisis: Flujos de trabajo fundamental cuyo proposito principal es analizar los
requisitos descritos en la captura de requisitos, mediante su refinamiento y
estructuracion. El objetivo de esto es (1) lograr una comprension mas precisa de los
requisitos, y (2) obtener una descripcion de los requisitos que sea facil de mantener y
que nos ayude a dar estructura al sistema en su conjunto incluyendo su arquitectura.
6. Diseo: Flujo de trabajo fundamental cuyo proposito principal es la de formular
modelos que se centran en los requisitos no funcionales y el dominio de la solucion y que
prepara para la implementacion y pruebas del sistema.
7. Implementacion: Flujo de trabajo fundamental cuyo proposito esencial es
implementar el sistema en terminos de componentes, es decir codigo fuente guiones,
ficheros binarios, ejecutables, et.
8. Prueba: Flujo de trabajo fundamental cuyo proposito esencial es comprobar el
resultado de la implementacion mediante las pruebas de cada construccion, incluyendo
tanto construcciones internas como intermedias, asi como las versiones finales del
sistema que van a ser entregadas a terceras personas.
9. Fase de Inicio: Primera fase del ciclo de vida del software, en la que la idea inicial
para el desarrollo es refinada hasta el punto de quedar lo suficientemente bien
establecida como para garantizar la entrada en la base de elaboracion.
10. Fase de Elaboracion: Segunda fase del ciclo de vida, en la que se define la
arquitectura.
11. Fase de Construccion: Tercera fase del ciclo de vida del software, en la que el
software es desarrollado a partir de una linea base de la arquitectura ejecutable, hasta el
punto en el que se esta listo para ser transmitido a las comunidades de usuarios.
12. Fase de Transicion: Cuarta fase del ciclo de vida del software es puesto en manos
de la comunidad de usuarios.
13. Arquitectura: Conjunto de desiciones significativas, acerca de la organizacion de un
sistema software, la seleccion de los elementos estructurales apartir de los cuales se
compone el sistema y las interfaces entre ellos, junto con su comportamiento, tal y como
se especifica en las colaboraciones entre estos elementos, la composicion de estos
elementos estructurales y de comportamiento de subsistemas progresivamente
mayores, y el estilo arquitectonico que guia esta organizacion, estos elementos y sus
interfaces, sus colaboraciones y su composicion. La arquitectura de software se interesa
no solo por la estructura y el comportamiento, sino tambien por las restricciones y
compromisos de uso, funcionamiento, flexibilidad al cambio, reutilizacion, comprension,
economia y tecnologia, asi como aspectos esteticos.
14. Vista Arquitectonica del Modelo de Casos de Uso: Vista de la arquitectura de
un sistema abarcando los casos de uso significativos desde un punto de vista
arquitectonico.
15. Vista Arquitectonica del Modelo de Analisis: Vista arquitectonica de un
sistema, abarcando las clases, paquetes y realizaciones de casos de uso del analisis,
vista que fundamentalmente aborda el refinamiento y estructuracion de los requisitos del
sistema. La estrucutra de esta vista se preserva en la medida de lo posible cuando se
disea e implementa la arquitectura del sistema.
16. Vista Arquitectonica del Modelo de Diseo: Vista de la arquitectura de un
sistema, abarcando las clases , subsistemas, interfaces y realizaciones de casos de uso
del diseo que forman el vocabulario del dominio de la solucion del sistema, vista que
abarca tambien los hilos y procesos qeu establecen la concurrencia y mecanismos de
sincronizacion del sistema, vista que aborda los requisitos no funcionales, incluyendo los
requisitos de rendimiento y capacidad de crecimiento de un sistema.
17. Vista Arquitectonica del Modelo de Despliege: Vista de la arquitectura de un
sistema abarcando los nodos que forman la topologia hardware sobre la que se ejecuta
el sistema, vista que aborda la distribucion, entrega e instalacion de las partes que
constituyen el sistema fisico.
18. Vista Arquitectonica del Modelo de Implementacion: Vista arquitectonica de
un sistema, abarcando los componentes usados para el ensamblado y lanzamiento del
sistema fisico, vista que aborda la gestion de la configuracion de las versiones del
sistema, constituida por componentes independientes que pueden ser ensambladas de
varias formas para producir un sistema ejecutable