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.



Conclusin
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 iteracin. 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.




Lenguaje unificado de modelado


Collage de diagramas UML.
Lenguaje Unificado de Modelado (UML, por sus siglas en ingls, Unified Modeling Language) es el
lenguaje de modelado de sistemas de software ms conocido y utilizado en la actualidad; est
respaldado por el OMG (Object Management Group).

Es un lenguaje grfico para visualizar, especificar, construir y documentar un sistema. UML ofrece
un estndar para describir un "plano" del sistema (modelo), incluyendo aspectos conceptuales
tales como procesos de negocio, funciones del sistema, y aspectos concretos como expresiones de
lenguajes de programacin, esquemas de bases de datos y compuestos reciclados.

Es importante remarcar que UML es un "lenguaje de modelado" para especificar o para describir
mtodos o procesos. Se utiliza para definir un sistema, para detallar los artefactos en el sistema y
para documentar y construir. En otras palabras, es el lenguaje en el que est descrito el modelo.

Se puede aplicar en el desarrollo de software gran variedad de formas para dar soporte a una
metodologa de desarrollo de software (tal como el Proceso Unificado Racional o RUP), pero no
especfica en s mismo qu metodologa o proceso usar.

UML no puede compararse con la programacin estructurada, pues UML significa Lenguaje
Unificado de Modelado, no es programacin, solo se diagrama la realidad de una utilizacin en un
requerimiento. Mientras que, programacin estructurada, es una forma de programar como lo es
la orientacin a objetos, la programacin orientada a objetos viene siendo un complemento
perfecto de UML, pero no por eso se toma UML slo para lenguajes orientados a objetos.

UML cuenta con varios tipos de diagramas, los cuales muestran diferentes aspectos de las
entidades representadas.

Estandarizacin de UML
Desde el ao 2005, UML es un estndar aprobado por la ISO como ISO/IEC 19501:2005
Information technology Open Distributed Processing Unified Modeling Language (UML)
Versin 1.4.2.

Tipos de Diagramas de UML
Estructura
Diagrama de clases
Diagrama de objetos
Diagrama de componentes
Diagrama de estructura compuesta
Diagrama de paquetes
Diagrama de despliegue
Comportamiento
Diagrama de casos de uso
Diagrama de actividades
Diagrama de estado
Interaccin
Diagrama de secuencia
Diagrama de colaboracin UML 1.X / Diagrama de comunicacin UML 2.0
Diagrama de tiempo
Diagrama de interaccin
Historia
Antes de UML 1.x
Despus de que la Rational Software Corporation contratara a James Rumbaugh de General
Electric en 1994, la compaa se convirti en la fuente de los dos esquemas de modelado
orientado a objetos ms populares de la poca: el OMT (Object-modeling technique) de
Rumbaugh, que era mejor para anlisis orientado a objetos, y el Mtodo Booch de Grady Booch,
que era mejor para el diseo orientado a objetos. Poco despus se les uni Ivar Jacobson, el
creador del mtodo de ingenier de software orientado a objetos. Jacobson se uni a Rational en
1995 despus de que su compaa, Objectory AB, fuera comprada por Rational. Los tres
metodologistas eran conocidos como los Tres Amigos, porque se saba de sus constantes
discusiones sobre las prcticas metodolgicas.

En 1996 Rational concluy que la abundancia de lenguajes de modelado estaba alentando la
adopcin de la tecnologa de objetos, y para orientarse hacia un mtodo unificado, encargaron a
los Tres Amigos que desarrollaran un Lenguaje Unificado de Modelado abierto. Se consult con
representantes de compaas competidoras en el rea de la tecnologa de objetos durante la
OOPSLA '96; eligieron cajas para representar clases en lugar de la notacin de Booch que utilizaba
smbolos de nubes.

Bajo la direccin tcnica de los Tres Amigos fue organizado un consorcio internacional llamado
UML Partners en 1996 para completar las especificaciones del Lenguaje Unificado de Modelado
(UML), y para proponerlo como una respuesta al OMG RFP. El borrador de la especificacin UML
1.0 de UML Partners fue propuesto a la OMG en enero de 1997. Durante el mismo mes la UML
Partners form una Fuerza de Tarea Semntica, encabezada por Cris Kobryn y administrada por Ed
Eykholt, para finalizar las semnticas de la especificacin y para integrarla con otros esfuerzos de
estandarizacin. El resultado de este trabajo, el UML 1.1, fue presentado ante la OMG en agosto
de 1997 y adoptado por la OMG en noviembre de 1997.

UML 1.x
Como notacin de modelado, la influencia de la OMT domina UML (por ejemplo el uso de
rectngulos para clases y objetos). Aunque se quit la notacin de "nubes" de Booch, si se adopt
la capacidad de Booch para especificar detalles de diseo en los niveles inferiores. La notacin de
Casos de Uso del Objectory y la notacin de componentes de Booch fueron integrados al resto de
la notacin, pero la integracin semntica era relativamente dbil en UML 1.1, y no se arregl
realmente hasta la revisin mayor de UML 2.0.

Conceptos de muchos otros mtodos OO fueron integrados superficialmente en UML con el
propsito de hacerlo compatible con todos los mtodos OO. Adems el grupo tom en cuenta
muchos otros mtodos de la poca, con el objetivo de asegurar amplia cobertura en el dominio de
los sistemas en tiempo real. Como resultado, UML es til en una variedad de problemas de
ingeniera, desde procesos sencillos y aplicaciones de un slo usuario a sistemas concurrentes y
distribuidos.

El Lenguaje de Modelado Unificado es un estndar internacional:

ISO / IEC 19501:2005 Tecnologa de la informacin - Procesamiento distribuido abierto - Lenguaje
de Modelado Unificado (UML) Version 1.4.2

UML 2.x
UML ha madurado considerablemente desde UML 1.1. Varias revisiones menores (UML 1.3, 1.4 y
1.5) han corregido defectos y errores de la primera versin de UML. A estas le ha seguido la
revisin mayor UML 2.0 que fue adoptada por el OMG en 2005.

Aunque UML 2.1 nunca fue lanzado como una especificacin formal, las versiones 2.1.1 y 2.1.2,
aparecieron en 2007, seguidas por UML 2.2 en febrero de 2009. UML 2.3 fue lanzado oficialmente
en mayo de 2010. UML 2.4.1 fue lanzado oficialmente en agosto de 2011. UML 2.5 fue lanzado en
octubre de 2012 como una versin "En proceso" y todava tiene que ser formalmente liberada.