METODOLOGÍA RUP

Aquí hablaremos de la metodología RUP, comenzando con una corta introducción de que es una Metodología Tradicional, después, daremos el concepto de metodología RUP, ventajas y desventajas, funcionalidad, y fases de la metodología, pero primero daremos una diferencias entre una Metodología Ágil y una Metodología Tradicional. 

DIFERENCIAS ENTRE UNA METODOLOGÍA ÁGIL Y TRADICIONAL 

Metodologías Tradicionales	Metodologías Ágiles
Basadas en normas provenientes de estándares seguidos por el entorno de desarrollo	Basadas en heurísticas provenientes de prácticas de producción de código
Cierta resistencia a los cambios	Especialmente preparados para cambios durante el proyecto
Impuestas externamente	Impuestas internamente (por el equipo)
Proceso mucho más controlado, con numerosas políticas/normas	Proceso menos controlado, con pocos principios.
El cliente interactúa con el equipo de desarrollo mediante reuniones	El cliente es parte del equipo de desarrollo
Más artefactos	Pocos artefactos
Más roles	Pocos roles
Grupos grandes y posiblemente distribuidos	Grupos pequeños (<10 integrantes) y trabajando en el mismo sitio
La arquitectura del software es esencial y se expresa mediante modelos	Menos énfasis en la arquitectura del software
Existe un contrato prefijado	No existe contrato tradicional o al menos es bastante flexible

     

Aquí, unos ejemplos de los dos tipos de metodologías

¿QUÉ ES UNA METODOLOGÍA TRADICIONAL?

Estas metodologías tradicionales imponen una disciplina de trabajo sobre el proceso de desarrollo, con el fin de conseguir un software. Para ello, se hace énfasis en la planificación total de todo el trabajo a y una vez que está todo detallado, comienza el ciclo de desarrollo de software. Se centran especialmente en el control de proceso, mediante una rigurosa definición de roles, documentación detallada. Además, las metodologías no se adaptan adecuadamente a los cambios, si se necesita hacer una cambio en las últimas fases, sería muy complicado ya que tendrían que devolverse al principio y eso tendría muchos costos y se perdería tiempo valioso, por lo cuales no son métodos adecuados cuando se trabajan en un entorno,  donde los requisitos no pueden predecirse o bien pueden variar. 

¿ QUE ES LA METODOLOGÍA RUP?

La metodología RUP , abreviatura de Rational Unified Process (o Proceso Unificado Racional), es un proceso propietario de la ingeniería de software creado por Rational Software , adquirida por IBM , ganando un nuevo nombre Irup que ahora es una abreviatura Rational Unified Process y lo que es una marca en el área de software, proporcionando técnicas que deben seguir los miembros del equipo de desarrollo de software con el fin de aumentar su productividad en el proceso de desarrollo.

Es una metodología cuyo fin es entregar un producto de software. Se estructura todos los procesos y se mide la eficiencia de la organización.

Es un proceso de desarrollo de software el cual utiliza 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

VENTAJAS Y DESVENTAJAS 

VENTAJAS

• Está basada totalmente en mejoras prácticas de la metodología:
• Reduce riesgos del proyecto.
• Incorpora fielmente el objetivo de calidad.
• Integra desarrollo con mantenimiento.

DESVENTAJAS

• Pretende prever y tener todo el control de antemano
• Modelo genera trabajo adicional.
• Genera muchos costos. 
• No recomendable para proyectos pequeños

PRINCIPIOS O FUNCIONALIDAD DE DESARROLLO DE LA METODOLOGÍA RUP

      El RUP está basado en 6 principios clave que son                 

Adaptar el proceso

El proceso deberá adaptarse a las necesidades del cliente ya que es muy importante interactuar con él. Las características propias del proyecto u organización. El tamaño del mismo, así como su tipo o las regulaciones que lo condicionen, influirán en su diseño específico. También se deberá tener en cuenta el alcance del proyecto en un área subformal.

Equilibrar prioridades

Los requisitos de los diversos participantes pueden ser diferentes, contradictorios o disputarse recursos limitados. Debe encontrarse un equilibrio que satisfaga los deseos de todos. Gracias a este equilibrio se podrán corregir desacuerdos que surjan en el futuro.

Demostrar valor iteractivamente

Los proyectos se entregan, aunque sea de un modo interno, en etapas iteradas. En cada iteración se analiza la opinión de los inversores, la estabilidad y calidad del producto, y se refina la dirección del proyecto así como también los riesgos involucrados

Colaboración entre equipos

El desarrollo de software no lo hace una única persona sino múltiples equipos. Debe haber una comunicación fluida para coordinar requisitos, desarrollo, evaluaciones, planes, resultados, etc.

Elevar el nivel de abstracción

Este principio dominante motiva el uso de conceptos reutilizables tales como patrón del software, lenguajes 4GL o marcos de referencia (frameworks) por nombrar algunos. Esto evita que los ingenieros de software vayan directamente de los requisitos a la codificación de software a la medida del cliente, sin saber con certeza qué codificar para satisfacer de la mejor manera los requisitos y sin comenzar desde un principio pensando en la reutilización del código. Un alto nivel de abstracción también permite discusiones sobre diversos niveles y soluciones arquitectónicas. Éstas se pueden acompañar por las representaciones visuales de la arquitectura, por ejemplo con el lenguaje UML.

Enfocarse en la calidad

El control de calidad no debe realizarse al final de cada iteración, sino en todos los aspectos de la producción. El aseguramiento de la calidad forma parte del proceso de desarrollo y no de un grupo independiente.

FASES DE LA METODOLOGÍA RUP

Fases

• Establece oportunidad y alcance
• Identifica las entidades externas o actores con las que se trata
• Identifica los casos de uso

RUP comprende 2 aspectos importantes por los cuales se establecen las disciplinas:

Proceso:

Las etapas de esta sección son: (revisar nuevamente la gráfica)

• Modelado de negocio
• Requisitos
• Análisis y Diseño
• Implementación
• Pruebas
• Despliegue

Soporte

En esta parte nos encontramos con las siguientes etapas:

• Gestión del cambio y configuraciones
• Gestión del proyecto
• Entorno

La estructura dinámica de RUP es la que permite que éste sea un proceso de desarrollo fundamentalmente iterativo, y en esta parte se ven inmersas las cuatro fases descritas anteriormente:

1. Inicio (también llamado Incepción o Concepción).
2. Elaboración.
3. Desarrollo (también llamado Implementación, Construcción).
4. Cierre (también llamado Transición).

Fase de Inicio

Esta fase tiene como propósito definir y acordar el alcance del proyecto con los patrocinadores o alumnos de un proyecto en el cual tenemos que, identificar los riesgos asociados al proyecto, proponer una visión muy general de la arquitectura de software y producir el plan de las fases y el de iteraciones posteriores.

Fase de Elaboración

En la fase de elaboración se seleccionan los casos de uso que permiten definir la arquitectura base del sistema y se desarrollaran en esta fase, se realiza la especificación de los casos de uso seleccionados y el primer análisis del dominio del problema, se diseña la solución preliminar.

Fase de Desarrollo

El propósito de esta fase es completar la funcionalidad del sistema, para ello se deben clarificar los requisitos pendientes, administrar los cambios de acuerdo a las evaluaciones realizados por los usuarios y se realizan las mejoras para el proyecto.

Fase de Transición

El propósito de esta fase es asegurar que el software esté disponible para los usuarios finales, ajustar los errores y defectos encontrados en las pruebas de aceptación, capacitar a los usuarios y proveer el soporte técnico necesario. Se debe verificar que el producto cumpla con las especificaciones entregadas por las personas involucradas en el proyecto.

Artefactos

RUP en cada una de sus fases (pertenecientes a la estructura dinámica) realiza una serie de artefactos que sirven para comprender mejor tanto el análisis como el diseño del sistema (entre otros). Estos artefactos (entre otros) son los siguientes:

Inicio

• Documento Visión
• Diagramas de caso de uso
• Especificación de Requisitos
• Diagrama de Requisitos

Elaboración

• Documento Arquitectura que trabaja con las siguientes vistas:

Vista Lógica

• Diagrama de clases

                                     

• Modelo E-R (Si el sistema así lo requiere)

             

Vista de Implementación

• Diagrama de Secuencia

               

• Diagrama de estados

           

• Diagrama de Colaboración

              

Vista Conceptual

• Modelo de dominio

Vista física

• Mapa de comportamiento a nivel de hardware.
• Diseño y desarrollo de casos de uso, o flujos de casos de uso arquitectónicos
• Pruebas de los casos de uso desarrollados, que demuestran que la arquitectura documentada responde adecuadamente a requerimientos funcionales y no funcionales.

Construcción

• Especificación de requisitos faltantes
• Diseño y desarrollo de casos de uso y/o flujos de acuerdo con la planeación iterativa
• Pruebas de los casos de uso desarrollados, y pruebas de regresión según sea el caso

Transición

• 
  
• Pruebas finales de aceptación
• Puesta en producción
• Estabilización