Rational Unified Process (RUP)

Características esenciales

Dirigidos por los casos de uso

Técnica de captura de requisitos y se enfoca en la importancia de los requisitos para el usuario

Los casos de uso representan requisitos funcionales del sistema

Los casos de uso en RUP son un elemento importante que puede servir como guía de trabajo

Los casos de uso pueden proporcionar un hilo conductor que permiten ver como evolucionan los artefactos generados en las diferentes actividades del proceso

Basándose en los casos de uso se crean los modelos de análisis y diseño, luego la implementación y se verifica que efectivamente el producto implemente cada caso de uso

Proceso centrado en la arquitectura

La arquitectura se refiere a la organización de las partes mas relevantes del sistema. Esto permite que los involucrados en el proyecto tengan una visión común necesaria para controlar el desarrollo

El proceso esta involucrado en la toma de decisiones que indican en que orden y como debe ser construido el sistema

Toma en cuenta los elementos de calidad del sistema(Rendimiento, reutilización y capacidad de evolución)

La arquitectura se ve influenciada por la plataforma de software(Gestor de base de datos, protocolos, sistema operativo, etc.)

Se presta especial atención al establecimiento temprano de una buena arquitectura que no se vea fuertemente impactada frente a cambios futuros

Los casos de uso deben encajar en la arquitectura, y esta debe permitir el desarrollo de todos los casos de uso requeridos, actualmente y en el futuro. Esto provoca que la arquitectura y los casos de uso evolucionen en paralelo durante el desarrollo del software

Proceso iterativo e incremental

El trabajo se divide en partes mas pequeñas, permitiendo que el equilibrio entre casos de uso y arquitectura se vaya logrando durante cada pequeña parte durante todo el proceso de desarrollo

Cada división del proyecto se puede ver como una iteración que produce un crecimiento en el producto

Una iteración puede realizarse por medio de una cascada que pasa por los flujos fundamentales(Requisitos, análisis, diseño, implementación y pruebas). Al final se realiza una integración de los resultados con lo obtenido de las iteraciones anteriores

Este proceso es una secuencia de iteraciones que abordan una parte de la funcionalidad total, pasando por todos los flujos de trabajo relevantes y refinando la arquitectura

La retroalimentación de la iteración pasada permite reajustar los objetivos para las siguientes iteraciones

RUP divide el proceso en cuatro fases: -INICIO: se enfocan hacia la comprensión del problema, delimitando el ámbito del proyecto. -ELABORACION: Las iteraciones se orientan al desarrollo de la baseline de la arquitectura, modelo de negocios, análisis, diseño y una parte de la implementación orientado al punto de partida de la arquitectura

-CONSTRUCCION: Se lleva a cabo la construcción por medio de una serie de iteraciones. Se realiza una pequeña cascada para cada ciclo. -TRANCISION: Se pretende tener el producto listo para ser lanzado

Otras buenas practicas

GESTION DE REQUISITOS: RUP brinda una guía para encontrar, organizar, documentar y seguir los cambios de los requisitos funcionales y restricciones. Utiliza una notación de Caso de Uso y escenarios para representar los
requisitos.

DESARROLLO DE SOFTWARE ITERATIVO: Desarrollo del producto mediante iteraciones con hitos bien definidos, en las cuales se repiten las actividades pero con distinto énfasis según la fase del proyecto

DESARROLLO BASADO EN COMPONENTES: El sistema se divide en componentes con interfaces bien definidas que posteriormente serán ensambladas para generar el sistema

MODELADO VISUAL(USANDO UML): UML es un lenguaje visual que facilita la gestión de modelos, permitiendo exponer u ocultar detalles cuando sea necesario. Ayuda a mejorar la capacidad del equipo para gestionar la complejidad del software

VERIFICACION CONTINUA DE CALIDAD: Es importante que la calidad de todos los artefactos se evalúe especialmente al final de cada iteración

GESTION DE CAMBIOS: Los artefactos de software cambian a lo largo de todo el proceso de construcción. La gestión de cambio y la configuración de disciplina del RUP ayudan en este aspecto

Estructuras del proceso

EJE HORIZONTAL: Representa el tiempo. Indica las características del ciclo de vida del proceso expresado en términos de fases, iteraciones e hitos

EJE VERTICAL: Representa los aspectos estáticos del proceso. Describe el proceso en términos de componentes de proceso, disciplinas, flujos de trabajo, actividades, artefactos y roles

Estructura dinámica del proceso. Fases e iteraciones

RUP se repite a lo largo de una serie de ciclos. Cada uno consta de cuatro fases: Inicio, elaboración, construcción y transición. Cada fase se subdivide a la vez en iteraciones.

Cada fase se concluye con un hito bien definido, un punto en el tiempo en el cual se deben tomar ciertas decisiones criticas y alcanzar metas clave antes de pasar a la siguiente fase

La duración y el esfuerzo dedicado en cada fase es variable dependiendo de las características del proyecto

imagen_2021-04-25_123028

image

1)INICIO

OBJETIVOS:

Establecer el ámbito del proyecto y sus limites

Encontrar casos de uso críticos del sistema

Mostrar almenos una arquitectura preliminar para los escenarios principales

Estimar el coste en recursos de todo el proyecto

Estimar los riesgo, las fuentes de incertidumbre

RESULTADOS

Un documento con una visión general de los requerimientos del proyecto, características clave y restricciones principales

Modelo inicial de casos de uso

Modelo de negocio

Lista de riesgos y plan de contingencia

Plan de proyecto, mostrando fases e iteraciones

Prototipos exploratorios para probar conceptos o la arquitectura candidata

COMPROBACION DE CRITERIOS DE EVALUACION

Se define el ámbito del sistema y las estimaciones de agenda

Entendimiento de los requisitos como evidencia de la fidelidad de los casos de uso principales

Estimaciones de tiempo, coste y riesgo son creibles

Comprensión total de cualquier prototipo de la arquitectura desarrollado

Los gastos hasta el momento se asemejan a los planeados

2)ELABORACION

OBJETIVOS

Definir, validar y cementar la arquitectura

Crear un plan fiable para la fase de construcción. Este plan puede evolucionar en futuras iteraciones

Demostrar que la arquitectura propuesta soportara la visión con un coste razonable y en un tiempo razonable

RESULTADOS

Un modelo de casos de uso: Todos los casos y actores identificados, la mayoría de los casos desarrollados

Requisitos adicionales que capturan los requisitos no funcionales y cualquier requisito no asociado con un caso de uso

Descripción de la arquitectura de software

Prototipo ejecutable de la arquitectura

Lista de riesgos y casos de negociación revisados

Plan de desarrollo para el proyecto

Manual preliminar de usuario

CRITERIOS DE EVALUACION

La visión y arquitectura del producto son estables

Se ha demostrado que los principales elementos de riesgo han sido elaborados y resueltos

El plan para la fase de construcción es detallado y preciso

Los gastos hasta ahora son aceptables, comparados con los previstos

4)TRANSICION

OBJETIVOS

RESULTADOS

CRITERIOS DE EVALUACION

3)CONSTRUCCION

OBJETIVOS

Minimizar los costes de desarrollo mediante la optimización de recursos

Conseguir una calidad adecuada tan rápido como sea practico

Conseguir versiones funcionales tan rápido como sea practico

RESULTADOS

Modelos completos(Casos de uso, análisis, diseño, despliegue e implementación)

Arquitectura integrada

Riesgos presentados mitigados

Manual inicial del usuario

Prototipo operacional(beta)

Cado del negocio actualizado

CRITERIOS DE EVALUACION

El producto es estable y maduro como para ser entregado

Todos los usuarios expertos están listos para la transición en la comunidad de usuarios

Son aceptables los gastos actuales versus los gastos planeados

Conseguir que el usuario se valga por si mismo

Un producto final que cumpla con los requisitos esperados, que funcione y satisfaga al usuario

Prototipo orepacional

Caso del negocio completo

Documentos legales

Descripción de la arquitectura completa y corregida

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

El usuario se encuentra satisfecho

Son aceptables los gastos actuales versus los gastos planificados

Estructura estatica del proceso

RUP define cuatro elementos: Roles, actividades, artefactos y flujos de disciplina que responden a las preguntas; quien? , como?, que?, cuando?, respetivamente.

ROLES: Un rol define las responsabilidades de un individuo o un grupo de individuos dentro de un equipo. una persona puede desempeñar varios roles

ANALISTAS

Analista de procesos de negocio

Diseñador del negocio

Analista de sistema

Especificador de requisitos

DESARROLLADORES

Arquitecto de software

Diseñador

Diseñador de interfaz de usuario

Diseñador de capsulas

Diseñador de base de datos

Implementador

Integrador

GESTORES

Jefe de proyecto

Jefe control de cambios

Jefe de pruebas

Jefe de despliegue

Ingeniero de procesos

Revisión de gestión del proyecto

Gestor de pruebas

APOYO

Documentador técnico

Administrador de sistemas

Especialista de herramientas

Desarrollador de cursos

Artista grafico

ESPECIALISTAS EN PRUEBAS

Tester

Analista de pruebas

Diseñador de pruebas

OTROS ROLES

Stakeholders

Revisor

Coordinación de revisiones

Revisor tecnico

ACTIVIDADES: Las actividades tienen como objetivo crear o actualizar algún producto

ARTEFACTOS: Un artefacto es un trozo de información que es producido modificado o usado durante el proceso de desarrollo de software

Ejemplos: Documento de arquitectura de software, modelo de casos de uso, modelo de diseño, modelo de un subsistema,etc

FLUJOS DE TRABAJO: Son relaciones de actividades que nos producen resultados observables

Modelado de negocio

Pretende llegar a un mejor entendimiento de la organización donde se va a implementar el producto

Entender problemas en la organización objetivo e identificar potenciales mejoras

Otro objetivo es derivar los requisitos del sistema necesarios para apoyar la organización objetivo

Busca también asegurar que clientes, usuarios y desarrolladores tengan un entendimiento común de la organización objetivo

Para lograr sus objetivos, el modelo de negocio describe como desarrollar una visión de la nueva organización

Requisitos

Establece que tiene que hacer exactamente el sistema que construyamos

Los requisitos pueden entenderse como el contrato que se debe cumplir, de modo que los usuarios finales tienen que comprender y aceptar los requisitos que especifiquemos

Los objetivos del flujo de requisitos son

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

Promover a los desarrolladores un mejor entendimiento de los requisitos del sistema

Definir el ámbito del sistema y una interfaz de usuario para el sistema, enfocada a las necesidades de uso

Proveer una base para la planeación de contenidos técnicos de las iteraciones

Análisis y diseño

En análisis consiste en obtener una visión del sistema que se preocupa solo por lo requisitos funcionales

El diseño es un refinamiento del análisis que tiene en cuenta los requisitos no funcionales

al principio de la fase de elaboración hay que definir una arquitectura candidata. Durante la elaboración se va refinando esta arquitectura hasta llegar a su forma definitiva

El resultado final mas importante de este flujo de trabajo será el modelo de diseño

Es importante la documentación de la arquitectura de software, que captura varias vistas arquitectónicas del sistema

Implementacion

Se implementan las clases y objetos. Además se deben hacer pruebas de unidad: cada implementador es responsable de probar las unidades que produzca

En cada iteración si se encuentra errores de diseño, se debe notificar

La integración del sistema debe ser siguiendo el plan. Los subsistemas se prueban individualmente

La integración debe ser incremental. De este modo es mas fácil localizar fallos

Pruebas

Se encarga de evaluar la calidad del producto que estamos desarrollando. Debe integrarse a lo largo del ciclo de vida del proyecto

Tiene como objetivo encontrar y documentar defectos en la calidad del software así como también validar los supuestos realizados en el diseño y especificación de requisitos

Otro objetivo es verificar que los requisitos tengan su apropiada implementacion

Estas actividades comienzan con el plan de prueba o con alguna evaluación durante la fase de inicio y se extiende durante todo el proyecto

Despliegue

Su objetivo es producir con éxito distribuciones del producto y distribuirlo a los usuarios

Las algunas de las actividades implicadas son: Probar el producto en su entorno de ejecución final, distribuir el software, instalar el software, proveer asistencia a los usuarios, entre otros

El flujo de trabajo se desarrolla con mayor intensidad en la fase de transición, ya que el propósito del flujo es asegurar aceptación y adaptación por parte de los usuarios

Gestion del proyecto

Es el arte de lograr un balance al gestionar objetivos, riesgos y restricciones para desarrollar un producto acorde a los requisitos de clientes y usuarios

Sus objetivos son proveer un marco de trabajo para la gestión de proyectos de software, proveer guías practicas para realizar planeación y proveer un marco de trabajo para gestionar riesgos

Entorno

Su finalidad es dar soporte al proyecto con las adecuadas herramientas, procesos y metodos

Las responsabilidades de este flujo de trabajo incluyen: Selección y adquisición de herramientas, configuración del proceso, mejora del proceso, servicios técnicos

Configuración estática RUP para proyecto pequeño

Mantiene artefactos, roles y actividades mas importantes debido a que esta enfocado en proyectos pequeños

ENTREGABLES DEL PROYECTO

1.-Flujos de trabajo: Se utilizan diagramas de actividad para modelar los flujos de trabajo

2.-Características del producto: Lista de características principales del producto, deseables por parte del cliente

3.-Glosario: Define los principales términos usados en el proyecto

4.-Modelo de casos de uso: Presenta mediante diagramas de casos de uso, la funcionalidad del sistema y actores que hacen uso de ella

5.-Especificaciones de casos de uso: Se realiza una descripción detallada donde se incluyen: precondiciones, postcondiciones, flujo de eventos, requisitos no-funcionales asociados

6.-Modelo de análisis y diseño: Establece la relacion de los casos de uso en clases y pasando de la representación en términos de análisis hacia una de diseño

8.-Modelo de implementación: Es una colección de componentes y subsistemas que los contienen. Incluyen todo tipo de ficheros necesarios para la implantación y despliegue del sistema

10.-Manual de instalación: Incluye las instrucciones para realizar la instalación del producto

9.-Modelo de pruebas: Para cada caso de uso se establecen pruebas de aceptación que validaran la correcta implementación del caso de uso

11.-Material de usuario: Corresponde a un conjunto de documentos y facilidades de uso del sistema

12.-Producto: Todos los ficheros fuente y ejecutable del producto

7.-Modelo lógico racional: Describe la representación lógica de los datos persistentes, de acuerdo con el enfoque para modelado racional de datos