Proceso de Software Unificado

Siguiendo con algunas metodologías de la desarrollo de software yeeeeey,  hoy toca hablar de una cuyo nombre fue totalmente inspirado en la compañía que lo creó: Rational Software, estoy hablando del Proceso Unificado de Rational o como los conocemos los amigos RUP así que como siempre, vamos a hablar de una manera que nos quede claro de una vez por todas sobre de qué va esta metodología.


RationalSoftware.png
De Desconocido - Transferred from en.wikipedia, Dominio público, Enlace


Esta metodología tiene características bien diferenciadas de las demás pues se basa en casos de uso para obtener los requerimientos de los usuarios en cada una de sus iteraciones. ¿Iteraciones? Venga, no pierdas el hilo, ya llegaremos a ese punto. Algo que debemos de tener muy presente es que se enfoca en la arquitectura de una manera muy notoria ya que si usamos esta metodología tenemos que creer que esta es la parte central.

RUP, RUP, RUPIAS?!




¿De qué demonios va RUP? No te preocupes, aquí te hice un resumen sobre lo más importante que tienes que saber.
  • Utiliza casos de usos en cada iteración: ¿Por qué tener solamente una oportunidad para definir los casos de uso cuando podríamos refinarlos mientras avanzamos en el proyecto? Si ya te habías puesto a pensar en ello tengo que decirte que no fuiste el primero. Este tipo de razonamiento deja entrever en RUP tiene como meta un cliente satisfecho al asegurar que las expectativas del cliente se cumplan al pie de la letra. 
  • Es iterativo: ¿De qué va esto? Bueno, RUP toma prestada una característica del modelo de espiral y tiene etapas que se repiten una y otra vez, existen 4 de ellas las cuales son: Inicio, elaboración, construcción y transición. 
  • Se enfoca en la arquitectura: No solamente se enfoca en ella, esta metodología cree fervientemente que la arquitectura es la parte central y lo deja claro cuando delega a esta la planeación de cómo de debe de hacer el desarrollo.
De fases va esto



Como ya se dijo, RUP es una metodología iterativa que se repiten cuantas veces nuestro proyecto lo crea conveniente y estas se desglosarán a continuación.
  1. Proceso: Aquí es dónde se define el alcance de nuestro proyecto y se identifican los riesgos.
  2. Elaboración: Una vez ya hechos los casos de uso se seleccionan aquellos que permitan sentar la base de nuestro software a desarrollar, una vez hecha esta parte se procede a diseñar la solución preliminar.
  3. Construcción: ¿Ya podemos comenzar a programar? Sí, ya podemos. Esta fase en especial es muy interesante porque no solamente se trata de llevar a cabo cierts funcionalidades de nuestro sistema sino que también permite mejorar nuestro proyecto al pasar de iteración en iteración.
  4. Transición: Al ser una fase de culminación aquí nos aseguramos que nuestro cliente esté contento con nuestro software. En caso de que esto no suceda esta fase funciona para tomar nota de los defectos que se encontraron, se capacita a los usuarios en caso de requerirlo y se brinda soporte técnico a los usuarios finales del mismo.
Estas fases se repiten tantas veces como nuestro proyecto lo crea conveniente. Sí, lo diré muchas veces a lo largo de este post.

Pasa qué cosas, cosas que pasan


Maysix_failure success path
Flickr Angeline Veeneman

RUP es una metodología muy completa pues tiene muchos puntos fuertes, por ejemplo, es muy amigable con los proyectos cuyos requerimientos cambian fácilmente con el tiempo y además, gracias a su fe ciega en la arquitectura el software que se desarrolla bajo este modo de trabajo tiene componentes reusables que hace que el desarrollo consuma mucho menos tiempo. RUP es una de las pocas metodologías que se pueden considerar completas ya que al documentan muchas partes del proceso, algo que siempre se agradece.

Por otro lado, hay ciertas cosas que debes de saber antes de usar RUP como desquiciado en todos tus proyectos y una de ellas quizá es algo que no te guste: RUP no es para newbies. Al ser iterativo y constar de fases bien definidas RUP no es muy amigable con personas inexpertas en estos campos, por ejemplo, si a un miembro de tu equipo se le va la olla y termina documentando cosas de más tu proyecto costará muchísimo dinero a causa de esto y no será rentable. Otro problema que tiene esta metodología es que si no hay un número sensato de iteraciones, inevitablemente los problemas vendrán en forma de errores al momento de integrar para hacer algunos test.

RUP es una metolodología muy bella pero dista mucho de ser la solución perfecta.

Yapa

Mientras buscaba información para escribir esta entrada me pude dar cuenta que la mayoría de imágenes que ilustraban esta metodología no hacían otra cosa más que confundirme, pero una vez terminé de escribir, me encontré esta imagen que quizá te sea de mucha ayuda.

¿Qué son las montañitas azules que están entre la gráfica? Indican el esfuerzo. No hubiera estado de más un indicador que nos dijera esto. 



RUP.png
By Daniel20av - Own work, CC BY-SA 3.0, Link



Comentarios

Entradas populares de este blog

Hagamos un breve repaso

El QQQ que no es malo

Casos de la vida real (en el diseño orientado a objetos)