2.3 RESUMEN DE METODOLOGÍAS

2.3    RESUMEN DE METODOLOGÍA

2.3.1    Metodología rup 

    El Proceso Unificado Racional (Rational Unified Process en inglés, habitualmente resumido como RUP) 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.

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.

Como filosofía RUP maneja 6 principios clave:

1.    Adaptación del proceso: El proceso deberá adaptarse a las características propias de la organización. El tamaño del mismo, así como las regulaciones que lo condicionen, influirán en su diseño específico. También se deberá tener en cuenta el alcance del proyecto.

2.    Balancear prioridades: Los requerimientos de los diversos inversores pueden ser diferentes, contradictorios o disputarse recursos limitados. Debe encontrarse un balance que satisfaga los deseos de todos.

3.    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 requerimientos, desarrollo, evaluaciones, planes, resultados, etc.

4.    Demostrar valor iterativamente: 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.

5.    Elevar el nivel de abstracción: Este principio dominante motiva el uso de conceptos reutilizables tales como patrón del software, lenguajes 4GL o esquemas (frameworks) por nombrar algunos. Éstos se pueden acompañar por las representaciones visuales de la arquitectura, por ejemplo con UML.

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

Características de la metodología RUP:

ü  Forma disciplinada de asignar tareas y responsabilidades (quién hace qué, cuándo y cómo)

ü   Pretende implementar las mejores prácticas en Ingeniería de Software

ü  Desarrollo iterativo

ü  Administración de requisitos

ü  Uso de arquitectura basada en componentes

ü  Control de cambios

ü  Modelado visual del software

ü  Verificación de la calidad del software      

El RUP es un producto de Rational (IBM). Se caracteriza por ser iterativo e incremental, estar centrado en la arquitectura y guiado por los casos de uso. Incluye artefactos (que son los productos tangibles del proceso como por ejemplo, el modelo de casos de uso, el código fuente, etc.) y roles (papel que desempeña una persona en un determinado momento, puede desempeñar distintos roles a lo largo del proceso).

El ciclo de vida de RUP

RUP divide el proceso en 4 fases, dentro de las cuales se realizan varias iteraciones en números variables según el proyecto y en las que se hace un mayor o menor hincapié de las distintas actividades.

Ø  Inicio: Se hace un plan de fases, se identifican los principales casos de uso y se identifican los riesgos. Se define el alcance del proyecto.

Ø  Elaboración: Se hace un plan de proyecto, se completan los casos de uso y se eliminan los riesgos.

Ø  Construcción: Se concentra en la elaboración de un producto totalmente operativo, eficiente y el manual de usuario.

Ø  Transición: Se Instala el producto en el cliente y se entrena a los usuarios. Como consecuencia de esto suelen surgir nuevos requisitos a ser analizados.

DESCRIPCIÓN DE LAS FASES DE RUP

Fase de Inicio: Durante la fase de inicio las iteraciones ponen mayor énfasis en las actividades de modelado del negocio y de requisitos.

ü  Modelado del negocio: En esta fase el equipo se familiarizará más al funcionamiento de la empresa, sobre conocer sus procesos.

·         Entender la estructura y la dinámica de la organización para la cual el sistema será desarrollado.

·         Entender el problema actual en la organización objetivo e identificar potenciales mejoras.

·         Asegurar que clientes, usuarios finales y desarrolladores tengan un entendimiento común de la organización objetivo.

ü  Requisitos: En esta línea los requisitos son el contrato que se debe cumplir, de modo que los usuarios finales tienen que comprender y aceptar los requisitos que especifiquemos.

·         Establecer y mantener un acuerdo entre clientes sobre lo que el sistema podría hacer.

·         Proveer a los desarrolladores un mejor entendimiento de los requisitos del sistema.

·         Definir el ámbito del sistema.

·         Proveer una base para estimar costos y tiempo de desarrollo del sistema.

·         Definir una interfaz de usuarios para el sistema, enfocado a las necesidades y metas del usuario.

Fase de Elaboración: En la fase de elaboración, las iteraciones se orientan al desarrollo de la base de la arquitectura, abarcan más los flujos de trabajo de requerimientos, modelo de negocios (refinamiento), análisis, diseño y una parte de implementación orientado a la base de la arquitectura.

ü  Análisis y Diseño: En esta actividad se especifican los requerimientos y se describen sobre cómo se van a implementar en el sistemas:

·         Transformar los requisitos al diseño del sistema.

·         Desarrollar una arquitectura para el sistema.

·         Adaptar el diseño para que sea consistente con el entorno de implementación

Fase de  Construcción

ü  Implementación: Se implementan las clases y objetos en ficheros fuente, binarios, ejecutables y demás. El resultado final es un sistema ejecutable.

·         Planificar qué subsistemas deben ser implementados y en qué orden deben ser integrados, formando el Plan de Integración.

·         Cada implementador decide en qué orden implementa los elementos del subsistema.

·         Si encuentra errores de diseño, los notifica.

·         Se integra el sistema siguiendo el plan.

ü  Pruebas: Este flujo de trabajo es el encargado de evaluar la calidad del producto que estamos desarrollando, pero no para aceptar o rechazar el producto al final del proceso de desarrollo, sino que debe ir integrado en todo el ciclo de vida.

·         Encontrar y documentar defectos en la calidad del software.

·         Generalmente asesora sobre la calidad del software percibida.

·         Provee la validación de los supuestos realizados en el diseño y especificación de requisitos por medio de demostraciones concretas.

·         Verificar las funciones del producto de software según lo diseñado.

·         Verificar que los requisitos tengan su apropiada implementación.

ü  Despliegue: Esta actividad tiene como objetivo producir con éxito, distribuciones del producto y distribuirlo a los usuarios. Las actividades implicadas incluyen:

·         Probar el producto en su entorno de ejecución final.

·         Empaquetar el software para su distribución.

·         Distribuir el software.

·         Instalar el software.

·         Proveer asistencia y ayuda a los usuarios.

·         Formar a los usuarios y al cuerpo de ventas.

·         Migrar el software existente o convertir bases de datos.