INFORME METODOLOGIA RUP EQUIPO 7

Introducción

El desarrollo de software no es una tarea fácil. Las metodologías ágiles nos ayudan a establecer un control en el proceso de desarrollo de software. Su filosofía, que el cliente sea más colaborativo y propone el desarrollo de software en iteraciones. Estas metodologías están revolucionando la manera de hacer software en menos tiempo pero manteniendo la alta calidad del mismo.

Esta vez hablaremos de RUP (Rational Unified Process) una metodología ágil, iterativa e incremental. Creada para adaptarse a la organización, basada en UML. 

Índice

I. ¿Qué es RUP?          

            1.1. Principios                                                                               

            1.2. Características          

II. Ciclo de vida        

            2.1. Iteraciones                                                                               

            2.2. Disciplinas          

III. RUP vs. XP       

IV. Prácticas fundamentales de RUP             

V. Ventajas y desventajas                                                               

            Conclusiones        

Bibliografía                                                                                   

  

¿Qué es RUP?

Proceso de desarrollo de software creado por la empresa Rational. Con ayuda del Lenguaje Unificado de Modelado (UML), constituye la metodología estándar más utilizada para el análisis, diseño, implementación y documentación de sistemas orientados a objetos.

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

RUP (Rational Unified Process) se inició aproximadamente en el año 1998 siendo predecesora de Rational Objectory Process, que fue creada por:

●     Iván Jacobson

●     Grady Booch

●     James Rumbaugh

●     Philippe Kruchten

El  Proceso Unificado de Rational o RUP son marcas registradas por IBM (desde su compra de Rational Software Corporation en 2003).

Principios

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.

•Equilibrar prioridades: Los requisitos de los diversos participantes pueden ser diferentes, contradictorios o disputarse recursos limitados.

•Demostrar valor iterativamente: Los proyectos se entregan, aunque sea de un modo interno, en etapas iteradas.

•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.

•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.

Características esenciales de RUP

La mayoría de los autores destacan que el proceso de software propuesto por RUP tiene 3 principales características las cuales son:

●     Está dirigido por los Casos de Uso.

Los casos de uso los podríamos definir como un fragmento de funcionalidad del sistema.

Los casos de uso son una técnica de captura de requerimientos que te hacen pensar en términos de importancia para el usuario y no sólo en términos de funciones que serían bueno contemplar.

Los casos de uso no solo empiezan el proceso de desarrollo sino que proporcionan una guía conductora, permitiendo establecer conexiones o trazos entre los artefactos que son generados en las diferentes actividades del proceso de desarrollo.

Bueno basándonos en esto los que hacen los casos de uso se crean los modelos de análisis y diseño como primera instancia, seguida de los que es la fase de implementación que los lleva a cabo, y por último se verifica que todo el producto esté implementado adecuadamente con cada caso de uso.

●     Está centrado en la arquitectura (Análisis).

La arquitectura de un sistema es la organización o estructura de sus partes más relevantes, lo que permite tener una visión común entre todos los involucrados (desarrolladores y usuarios) y una perspectiva clara del sistema completo, necesaria para controlar el desarrollo. La arquitectura involucra todos los aspectos estáticos y dinámicos más significativos del sistema.

RUP además de utilizar los casos de uso para guiar el proceso presenta especial atención al establecimiento temprano de una buena arquitectura.

Cada producto tiene tanto una función como una forma. La función corresponde a la funcionalidad reflejada en los casos de uso y la forma proporciona la arquitectura. Los casos de uso deben encajar en la arquitectura cuando se lleven a cabo y la arquitectura debe permitir el desarrollo de todos los casos de uso requeridos actualmente y en el futuro.

●     Es iterativo e incremental.

Consta de una secuencia de iteraciones, cada iteración aborda una parte de la funcionalidad total, pasando por cada uno de los flujos de trabajo relevantes y refinando la arquitectura de los mismos.

Se pasa por los flujos fundamentales (Requisitos, Análisis, Diseño, Implementación y Pruebas), también existe una planificación de la iteración, un análisis de la iteración y algunas actividades específicas de la iteración. Al finalizar se realiza una integración de los resultados con lo obtenido de las iteraciones anteriores

Debe tener un equilibro entre los casos de uso y la arquitectura, la estrategia de RUP es dividir el trabajo en partes pequeñas o mini proyectos, permitiendo que el equilibrio entre casos de uso y arquitectura se logre durante cada pequeña parte o mini proyecto así hasta que termine todo el proceso de desarrollo.

Fases de RUP (Ciclo de vida)

Inicio: En esta fase se definen los alcances del proyecto, se identifican los riesgos y se propone una visión muy general de la arquitectura de software.

Además, se pueden establecer casos de negocio para un nuevo sistema o para alguna actualización importante de un sistema existente.

Los objetivos de esta fase son:

●     Establecer el ámbito del proyecto y sus límites.

●     Encontrar los Casos de Uso críticos del sistema, los escenarios básicos que definen la funcionalidad.

●     Mostrar al menos una arquitectura candidata para los escenarios principales.

●     Estimar el coste en recursos y tiempo de todo el proyecto.

●     Estimar los riesgos, las fuentes de incertidumbre.

Al terminar:

●     Todos los interesados en el proyecto coinciden en la definición del ámbito del sistema y las estimaciones de agenda.

●     Entendimiento de los requisitos, como evidencia de la fidelidad de los Casos de Uso principales.

●     Las estimaciones de tiempo, coste y riesgo son creíbles.

●     Comprensión total de cualquier prototipo de la arquitectura desarrollado.

●     Los gastos hasta el momento se asemejan a los planeados.

Elaboración: Se analiza el dominio del problema, se seleccionan los casos de uso que permiten definir la arquitectura base del sistema, se diseña la solución preliminar.

Los objetivos de esta fase son:

●     Definir, validar y cimentar la arquitectura.

●     Completar la visión.

●     Crear un plan fiable para la fase de construcción.

●     Este plan puede evolucionar en sucesivas iteraciones. Debe incluir los costes si procede.

●     Demostrar que la arquitectura propuesta soportará la visión con un coste razonable y en un tiempo razonable.

Al terminar:

●     Un prototipo ejecutable de la arquitectura.

●     Lista de riesgos y caso de negocio revisados.

●     Plan de desarrollo para el proyecto.

●     Un caso de desarrollo actualizado que especifica el proceso a seguir.

●     Un manual de usuario preliminar (opcional).

Construcción: Se lleva a cabo la construcción del producto, se redefine su análisis y diseño y se procede a su implantación y pruebas.

Los objetivos concretos incluyen:

●     Minimizar los costes de desarrollo mediante la optimización de recursos y evitando el tener que rehacer un trabajo o incluso desecharlo.

●     Conseguir una calidad adecuada tan rápido como sea práctico.

●     Conseguir versiones funcionales (alfa, beta, y otras versiones de prueba) tan rápido como sea práctico.

Los resultados deben ser:

●     Modelos Completos (Casos de Uso, Análisis, Diseño, Despliegue e Implementación)

●     Arquitectura íntegra (mantenida y mínimamente actualizada)

●     Riesgos Presentados Mitigados

●     Plan del Proyecto para la fase de Transición.

●     Manual Inicial de Usuario (con suficiente detalle)

●     Prototipo Operacional – beta

●     Caso del Negocio Actualizado

Transición: El propósito de esta fase es asegurar que el software esté disponible para la entrega al usuario.

Entrega del Producto

¿Está el usuario satisfecho?

Gastos reales de los recursos vs. Gastos previstos aceptables.

Los principales objetivos de esta fase son:

●     Conseguir que el usuario se valga por sí mismo.

●     Un producto final que cumpla los requisitos esperados, que funcione y satisfaga suficientemente al usuario.

Los resultados de la fase de transición son:

●     Prototipo Operacional

●     Documentos Legales

●     Caso del Negocio Completo

●     Línea de Base del Producto completa y corregida que incluye todos los modelos del sistema

●     Descripción de la Arquitectura completa y corregida

●     Las iteraciones de esta fase irán dirigidas normalmente a conseguir una nueva versión.

La duración y esfuerzo que debe ser dedicado en cada fase es una variable dependiendo de las características que contenga el proyecto en desarrollo.

	INICIO	ELABORACIÓN	CONSTRUCCIÓN	TRANSICIÓN
ESFUERZO	5%	20%	65%	10%
TIEMPO	10%	30%	50%	10%

Iteraciones

Cada fase en RUP puede descomponerse en iteraciones. Una iteración es un ciclo de desarrollo completo dando como resultado una entrega de producto ejecutable (interna o externa).

Una iteración puede realizarse por medio de una cascada. Se pasa por los flujos fundamentales (Requisitos, Análisis, Diseño, Implementación y Pruebas), también existe una planificación de la iteración, un análisis de la iteración y algunas actividades específicas de la iteración. Al finalizar se realiza una integración de los resultados con lo obtenido de las iteraciones anteriores.

El proceso iterativo e incremental consta de una secuencia de iteraciones. Cada iteración aborda una parte de la funcionalidad total, pasando por todos los flujos de trabajo relevantes y refinando la arquitectura. Cada iteración se analiza cuando termina. Se puede determinar si han aparecido nuevos requisitos o han cambiado los existentes, afectando a las iteraciones siguientes. Durante la planificación de los detalles de la siguiente iteración, el equipo también examina cómo afectarán los riesgos que aún quedan al trabajo en curso. Toda la retroalimentación de la iteración pasada permite reajustar los objetivos para las siguientes iteraciones. Se continúa con esta dinámica hasta que se haya finalizado por completo con la versión actual del producto.

Disciplinas

Las disciplinas conllevan los flujos de trabajo, los cuales son una secuencia de pasos para la culminación de cada disciplina, estas disciplinas se dividen en dos grupos: las primarias y las de apoyo.

Las primarias son las necesarias para la realización de un proyecto de software. (Flujos del trabajo de proceso)

Las de apoyo sirven de apoyo a las primarias y especifican otras características en la realización de un proyecto de software. ( Flujos de trabajo de soporte).

    

1. Flujos del Trabajo de Proceso

Modelado del negocio: Tiene como objetivos comprender la estructura y la dinámica de la organización, comprender problemas actuales e identificar posibles mejoras, comprender los procesos de negocio.

Requerimientos: Tiene como objetivos establecer lo que el sistema debe hacer (Especificar Requisitos), definir los límites del sistema, y una interfaz de usuario, realizar una estimación del costo y tiempo de desarrollo.

Análisis y Diseño: Define la arquitectura del sistema y tiene como objetivos trasladar requisitos en especificaciones de implementación.

Implementación: Tiene como objetivo implementar las clases de diseño como componentes

Pruebas: Tiene como objetivo verificar la integración de los componentes, verificar que todos los requisitos han sido implementados.

Despliegue: Asegura que es producto esté preparado para el cliente.

2. Flujo de Trabajo de Soporte

Gestión y configuración de cambios: Los controles sobre los cambios son de mucha ayuda ya que evitan confusiones costosas como la compostura de algo que ya se había arreglado etc.

Gestión del proyecto: su objetivo es equilibrar los objetivos competitivos, administrar el riesgo, y superar restricciones para entregar un producto que satisface las necesidades de los clientes con.

Entorno: se enfoca sobre las actividades necesarias para configurar el proceso que engloba el desarrollo de un proyecto y describe las actividades requeridas para el desarrollo de las pautas que apoyan un proyecto.

RUP Vs XP

RUP

XP

●     Forma disciplinada de asignar tareas y responsabilidades en una empresa de desarrollo ●     Un cambio en las etapas de vida del sistema incrementa el costo ●     Requiere un grupo grande de programadores para trabajar esta metodología ●     Describe una clase de los procesos que son iterativos e incrementales ●     Es un proceso de desarrollo más general de los existentes actualmente ●     Los procesos de RUP estiman tareas y horario del plan midiendo la velocidad de iteraciones concerniente a sus estimaciones originales. ●     Las iteraciones tempranas de proyectos conducidos RUP se enfocan fuertemente sobre arquitectura del software; la puesta en práctica rápida de características se retrasa hasta que se ha identificado y se ha probado una arquitectura firme.

●     Busca simplificar el desarrollo del software y que se logrará la reducción en el costo del proyecto ●     Reduce el costo del cambio en las etapas de vida del sistema ●     Se requiere de un grupo pequeño de programadores, se irán aumentando conforme sea necesario ●     Sus programadores pueden ser ordinarios ●     El desarrollo de software es riesgoso y difícil de controlar ●     Se harán pruebas todo el tiempo, no sólo de cada nueva clase (pruebas unitarias) sino que también los clientes comprobarán que el proyecto va satisfaciendo los requisitos (pruebas funcionales). ●     intenta reducir la complejidad del software por medio de un trabajo orientado directamente al objetivo, basado en las relaciones interpersonales y la velocidad de reacción ●     Es un sistema de prácticas mínimas - le suponen utilizarlas todas en el principio de un proyecto y adaptarlas y agregar los adicionales como cuando se experimenta la necesidad.

Cuadro 1 ‘RUP Vs XP’ (ESCUELA DE INGENIERÍA DE SISTEMAS, http://www.usmp.edu.pe/publicaciones/boletin/fia/info49/articulos/RUP%20vs.%20XP.pdf)

Prácticas fundamentales de RUP

La perspectiva práctica en el RUP describe buenas prácticas dentro de la ingeniería del software que son aconsejables en el desarrollo de sistemas. Se recomienda seis buenas prácticas fundamentales.

1.               Desarrolle el software de forma iterativa. Planifica los incrementos del sistema basado en las prioridades del usuario y desarrollo y entrega de las características del sistema de más alta prioridad al inicio del proceso de desarrollo

2.               Gestión de requerimientos. Documenta explícitamente los requerimientos del cliente y se mantiene al tanto de los cambios.

3.               Utilización de arquitecturas en componentes. Se estructura la arquitectura del sistema

4.               Modelo del software visualmente. Utilización de modelos gráficos UML

5.               Verificación de la calidad del software. Se asegura que se cumplan los estándares de calidad organizacionales

6.               Control de cambios del software. Gestiona los cambios del software usando un sistema de gestión de cambios

Ventajas y Desventajas

VENTAJAS

●     RUP ha madurado con el tiempo

●     Requiere conocimientos del proceso y de UML

●     UML hace que el software se apegue a estándares de la industria

●     Adaptable a la organización

●     Progreso visible en las etapas tempranas

●     El uso de las iteraciones (actividades) permite evaluar tempranamente los riesgos en lugar de descubrir problemas en la integración final del sistema

●     Facilita la reutilización del código teniendo en cuenta que se realizan revisiones en las primeras interacciones lo cual además permite que se aprecien oportunidades de mejoras en el diseño

DESVENTAJAS

●     Por el grado de complejidad puede no resultar muy adecuado

●     RUP es generalmente mal aplicado en el estilo de cascada

●     Sistemas híbridos: en empresas que hay organismos híbridos y nos adaptables a cualquier empresa UML no es efectivo

●     Costosa la compra de herramientas y capacitación del equipo, requiere de tiempo y consultoría

●     Limitaciones en ciclo de vida pues no lo contempla por completo.

●     Posee características avanzadas en la sintaxis de modelación, requiere notaciones que  no poseen los desarrolladores promedio

Conclusiones

RUP es una metodología ágil para el análisis, diseño, desarrollo, implementación y documentación de sistemas orientados a objetos. No es un modelo con pasos definidos, sino un modelo adaptable a las necesidades de la organización. Sus principios son: adaptar el proceso según el contexto de la organización. Establecer prioridades, establecer las iteraciones, colaboración de equipos, código reutilizable y enfocarse en la calidad.

Esta metodología promueve la interacción con el cliente y la comunicación entre equipos. Así mismo, que el control de calidad no se realice sólo en la parte final de la iteración, sino en durante todo el proceso.

Se basa en UML, es decir, está dirigido por casos de uso. Esto hace que se sea más costoso y con mayor grado de complejidad por lo que puede resultar no muy adecuado.

 BIBLIOGRAFÍA

★    Cuatro enfoques metodológicos para el desarrollo de Software RUP – MSF – XP - SCRUM, Recibido el 1 de abril de 20111. Aprobado el 10 de junio de 2011, Oliver Andrés Pérez A.

★    Inventum No. 10 Facultad de Ingeniería UNIMINUTO - Junio de 2011 - ISSN 1909 - 2520

★    Ingeniería del Software- Ian Sommerville- Séptima Edición - PEARSON EDUCACIÓN, S.A. , Madrid 2005

★    Cocolito. (s.f.). cocolito. Recuperado el 2013 de Septiembre de 09, de http://cocolito.comoj.com/rup.html