Proceso Unificado Racional

Los orgenes de RUP se remontan al modelo espiral original de Barry Boehm. Ken
Hartman, uno de los contribuidores claves de RUP colabor con Boehm en la
investigacin. En 1995 Rational Software compr una compaa sueca llamada
Objectory AB, fundada por Ivar Jacobson, famoso por haber incorporado los casos
de uso a los mtodos de desarrollo orientados a objetos. El Rational Unified
Process fue el resultado de una convergencia de Rational Approach y Objectory
(el proceso de la empresa Objectory AB). El primer resultado de esta fusin fue el
Rational Objectory Process, la primera versin de RUP, fue puesta en el mercado
en 1998, siendo el arquitecto en jefe Philippe Kruchten.
El primer libro para describir el proceso fue titulado The Unified Software
Development Process2.
En 2006, IBM cre un subconjunto de RUP ajustado para proyectos de desarrollo
gil - publicado como un mtodo libre, llamado OpenUP a travs del sitio de
Eclipse.

El proceso Unificado es un proceso de desarrollo de software; un proceso de

desarrollo de software es el conjunto de actividades necesarias para transformar
los requisitos de un usuario en un sistema de software. Sin embargo, el Proceso
Unificado es ms que un simple proceso; es un marco de trabajo genrico que
puede especializarse para una gran variedad de sistemas de software, para
diferentes reas de aplicacin, diferentes tipos de organizaciones, diferentes
niveles de aptitud y diferentes tamaos de proyectos.
El Proceso Unificado est basado en componentes, lo cual quiere decir que el
sistema software en construccin est formado por componentes software
interconectados a travs de interfaces bien definidas.
El Proceso Unificado utiliza el Lengua Unificado de Modelado (UML) para preparar
todos los esquemas de un sistema de software. UML es una parte esencial del
Proceso Unificado.
El ser dirigido por casos de usos, centrado en la arquitectura, e interactivo e
incremental; es lo que hace nico al Proceso Unificado.

Principios de desarrollo
La Filosofa del RUP est basado en 6 principios clave que son los siguientes:
1. Adaptar el proceso:
El proceso deber adaptarse a las necesidades del cliente ya que es muy
importante interactuar con l. Las caractersticas propias del proyecto. El tamao
del mismo, as como su tipo o las regulaciones que lo condicionen, influirn en su
diseo especfico. Tambin se deber tener en cuenta el alcance del proyecto.
2. Equilibrar prioridades:
Los requisitos de los diversos participantes pueden ser diferentes, contradictorios
o disputarse recursos limitados. Debe poder encontrarse un equilibrio que
satisfaga los deseos de todos. Gracias a este equilibrio se podrn corregir
desacuerdos que surjan en el futuro.
3. Demostrar valor iterativamente:
Los proyectos se entregan, aunque sea de un modo interno, en etapas iteradas.
En cada iteracin se analiza la opinin de los inversores, la estabilidad y calidad
del producto, y se refina la direccin del proyecto as como tambin los riesgos
involucrados.
4. Colaboracin entre equipos:
El desarrollo de software no lo hace una nica persona sino mltiples equipos.
Debe haber una comunicacin fluida para coordinar requisitos, desarrollo,
evaluaciones, planes, resultados, etc.
5. Enfocarse en la calidad:
El control de calidad no debe realizarse al final de cada iteracin, sino en todos los
aspectos de la produccin. El aseguramiento de la calidad forma parte del proceso
de desarrollo y no de un grupo independiente, tambin es una estrategia de
desarrollo de software.
6. Elevar el Nivel de Abstraccin:
Este principio dominante motiva el uso de conceptos reutilizables tales como
patrones de diseo del software, lenguajes 4GL o esquemas (frameworks) por
nombrar algunos. Estos se pueden acompaar por las representaciones visuales
de la arquitectura, por ejemplo con UML.