h@nz …el Geek

El Proceso Unificado de Rational (RUP, el original inglés Rational Unified Process) es un proceso de desarrollo de software y junto con el Lenguaje Unificado de Modelado UML, constituye la metodología estándar más utilizada para el análisis, implementación y documentación de sistemas orientados a objetos. RUP es en realidad un refinamiento realizado por Rational Software del más genérico Proceso Unificado.

El RUP no es un sistema con pasos firmemente establecidos, sino un conjunto de metodologías adaptables al contexto y necesidades de cada organización.

Esta es una definición tomada de Wikipedia que explica muy bien el sentido de RUP, esta metodología es bastante mencionada pero muy poco utilizada por el desconocimiento acerca del tema. Como se lee, RUP es adpatable al contexto y necesidades de cada organización, y eso es lo bueno ya que seguirla fielmente resultaría en un trabajo bastante engorroso.

Lo que pretendo es hacer una descripción de RUP basándome en la plantilla de la propia Rational, empezaré definiendo los roles para entender un poco más esta metodología.

¿Que es un Rol? Un rol es una definición abstracta de un conjunto de actividades realizadas y de artefactos obtenidos. Los roles son realizados típicamente por un individuo, o un conjunto de individuos, trabajando juntos en equipo. Un miembro del equipo de proyecto cumple normalmente muchos roles. Los roles no son individuos; en lugar de ello, describen cómo los individuos se comportan en el negocio y qué responsabilidades tienen estos individuos.

Hace un tiempo pregunte a una persona: ¿que metodología usas para tu desarrollo?, me respondió sin dudar: RUP, cuando le pregunté: ¿Con qué rol de RUP te identificas? me dijo: como Analista… y cual de los roles del analista pregunte inocentemente yo, como analista, me dijo. Si bien es cierto los roles conocidos son Analysts, Developers, Testers y Managers hay que considerar que dentro de estos roles genéricos existen otros roles que son más específicos.

A continuación les mostraré los roles específicos dentro del rol Analista haciendo una descripción de cada uno de ellos:

1. System Analyst Conduce y coordina los requerimientos y los Casos de Uso modelando y delimitando la funcionalidad del sistema y delimitando el sistema; por ejemplo, estableciendo que actores y casos de uso existen y como interactúan.

   

2. Business Designer El diseñador del negocio detalla la especificación de una parte de la organización describiendo el flujo de trabajo (Workflow) de uno o varios casos de uso del negocio. Este rol especifica los trabajadores del negocio y las entidades de negocio necesarios para realizar un caso de uso del negocio y distribuye el comportamiento del caso de uso del negocio a éstos. El diseñador del negocio define las responsabilidades, las operaciones, las cualidades, y las relaciones de uno o varios trabajadores del negocio y entidades de negocio.

   

3. Business-Model Reviewer El revisor del modelo de negocio participa en las revisiones formales del modelo del caso de uso del negocio y del modelo del objeto del negocio.

   

4. Business-Process Analyst El analista del proceso de negocio conduce y coordina el caso de uso del negocio que modela contorneando y delimitando la organización que es modelada; por ejemplo, el establecer que actores del negocio y casos de uso del negocio existen y como trabajan entre ellos. El analista del proceso de negocio es responsable de la arquitectura del negocio.

   

5. Requirements Reviewer El revisor de los requisitos planea y conduce la revisión formal del modelo del caso de uso.

   

6. Requirements Specifier El especificador de requerimientos detalla la especificación de una parte de la funcionalidad del sistema describiendo el aspecto de los requisitos de uno o varios casos de uso y otros requisitos de soporte del software. El especificador de requerimientos puede también ser responsable de un paquete casos de uso, y mantiene la integridad de ese paquete. Se recomienda que el especificador de los requisitos responsable de un paquete de casos de uso sea también responsable de sus casos de uso y actores contenidos.

   

7. Test Analyst El rol analista de pruebas es responsable inicialmente de identificar y posteriormente de definir las pruebas requeridas, de supervisar la cobertura de la prueba y de evaluar la calidad total experimentada al probar los elementos de prueba. Este papel también implica el especificar los datos de prueba requeridos y el evaluar el resultado de la prueba conducida en cada ciclo de la prueba. Este papel también se refiere a veces como el diseñador de prueba o considerado parte del rol Tester. Este rol es responsable de:
   • Identificar los elementos de prueba que se evaluarán por el esfuerzo de la prueba.
   • Definir las pruebas apropiadas requeridas y cualquier dato de prueba asociado.
   • Recopilar y manejar los datos de prueba.
   • Evaluar el resultado de cada ciclo de prueba.

   

8. User-Interface Designer El diseñador de la interfaz de usuario conduce y coordina los prototipos y el diseño de la interfaz de usuario, por ejemplo:
   • Capturando requerimientos de la interfaz de usuario, incluyendo requerimientos de usabilidad.
   • Construyendo prototipos de Interfaces de usuario.
   • Implicando a otros stakeholders acerca de la IU, tales como usuarios finales, en revisiones de la utilidad y sesiones de prueba de uso.
   • Repasando y proporcionando el feedback apropiado en la implementación final de la IU, según lo creado por otros desarrolladores; es decir, diseñadores e implementadores.

   

Espero que esta primera entrega les ayude a entender mejor estos roles, sería muy complicado dar la descripción completa de RUP, de manera que lo haré de a pocos en una próxima oportunidad daré la descripción del rol Developers luego de Testers y así sucesivamente.

Saludos.

Blogalaxia Tags: RUP Metodologías Software Analistas