Please enable JavaScript.
Coggle requires JavaScript to display documents.
Rational Unified Process (RUP) - Coggle Diagram
Rational Unified Process (RUP)
Producto comercial desarrollado y comercializado por Rational Software
Historia
En 1967 Ivar Jacobson elabora la Metodología Ericsson.
Entre 1987 - 1995 Jacobson funda la compañia Objectory AB
Entre 1995 - 1997 Se desarrolla Rational Objectory Process (ROP).
En 1998 se lanza Rational Unified Process (RUP).
A partir de Objectory 3.8 y del Rational Apprach adoptado UML como lenguaje de modelado
Rational Software desarrolló e incorporó diversos elementos para expandir ROP
Se lanza el proceso de desarrollo Objectory
En 1995 Rational Software Corporation adquiere Objectory AB.
Una aproximación de desarrollo basada en componentes, que introdujo el concepto de Caso de Uso.
Características Esenciales
El Proceso de RUP tiene tres características esenciales.
Proceso dirigido por Casos de Uso
Los casos de uso son una técnica de captura de requisitos, que fuerza a pensar en términos de importancia para el usuario.
En RUP los Casos de Usuario no son sólo una herramienta para especificar los requisitos del sistema, también guían su diseño, implementación y prueba.
Los Casos de Uso constituyen un elemento integrador y una guía del trabajo.
No sólo inician el proceso de desarrollo, sino que proporcionan un hilo conductor, permitiendo establecer trazabilidad entre los artefactos.
basándose en los Casos de Uso se crean los modelos de análisis y diseño, luego la implementación que los lleva a cabo
Se verifica que efectivamente el producto implemente adecuadamente cada Caso de Uso.
Artefactos que son generados en las diferentes actividades del proceso de desarrollo.
Proceso centrado en la Arquitectura
La arquitectura de un sistema es la organización de sus partes más relevantes, que permite tener una visión común entre todos los involucrados y una perspectiva clara del sistema.
En el caso de RUP se presta atención al establecimiento de una arquitectura que no se vea tan impactada ante cambios durante la construcción y el mantenimiento.
Los Casos de Uso deben encajar en la arquitectura cuando se llevan a cabo y la arquitectura debe permitir el desarrollo de todos los Casos de Uso requeridos.
Por esto ambos deben evolucionar en paralelo durante todo el proceso de desarrollo.
Es conveniente ver el sistema desde diferentes perspectivas para comprender mejor el diseño por lo que la arquitectura se representa mediante vistas que se centran en aspectos del sistema.
Proceso Iterativo e incremental
El equilibrio correcto entre los Casos de Uso y la arquitectura es algo muy parecido al equilibrio de la forma y la función en el desarrollo del producto.
Por esto en RUP proponen tener un proceso iterativo e incremental.
El trabajo se divide en mini proyectos, permitiendo que el equilibrio entre Casos de Uso y arquitectura se vaya logrando durante cada mini proyecto.
Cada mini proyecto se puede ver como una iteracion del cual se obtiene un crecimiento en el producto.
RUP divide el proceso en 4 fases donde se realizan varias iteraciones según el proyecto.
La fase de Inicio y de Implementación, se enfocan hacia la comprensión del problema y tecnologia.
En la fase de Construcción se construye el producto por medio de iteraciones.
En fase de Transición se pretende garantizar que el producto este preparado para su entrega.
Otras Prácticas
Gestión de Requisitos.
Desarrollo de Software Iterativo.
Desarrollo Basado en Componentes.
Modelado Visual
Verificación Continua de Calidad
Gestión de los Cambios.
Los artefactos del software suele cambiar durante el proceso de desarrollo, por lo que se necesita de cierta disciplina para evitar el caos.
Aqui las pruebas juegan un papel importante, para evaluar la calidad de los artefactos durante el proceso de desarrollo.
Ayuda a mejorar la capacidad del equipo para gestionar la complejidad del software, usando UML.
Se divide el sistema en componentes con interfaces, para ser ensamblados y generar el sistema.
Desarrollo del producto mediante iteraciones, repitiendo actividades pero con distintos énfasis.
RUP ayuda a encontrar, organizar y documentar cambios de los requisitos.
Estructura del Proceso
El proceso puede ser descrito en dos ejes.
Eje Vertical. Representa los aspectos estáticos del proceso.
Eje Horizontal. Representa el tiempo y los aspectos dinámicos del proceso.
Estructura Dinámica del Proceso.
RUP se repite a lo largo de una serie de ciclos que constituyen la vida de un producto.
Cada ciclo consta de Inicio, Elaboración, Construcción y Transición.
En Inicio se define el modelo de negocio y el alcance del proyecto, se identifican actores y casos de uso.
En Elaboración se analiza el dominio del problema, construye un prototipo de la arquitectura y desarrolla el plan del proyecto.
En Construcción todos los componentes, características y requisitos deben ser implementados en su totalidad.
En Transición se pone el sistema en manos de los usuarios finales.
2 more items...
Minimizar los costes de desarrollo mediante optimización de recursos. Conseguir una calidad adecuada y versiones funcionales.
Se deben obtener modelos completos, arquitectura íntegra, prototipo operacional y plan para la fase de Transición.
Definir, validar y cimentar la arquitectura. Crear un plan fiable para la siguiente fase.
Se debe obtener un modelo de casos de uso completo, identificando todos los casos y actores. Un prototipo de arquitectura.
Establece el ámbito del proyecto. Estimar cosot en recursos, tiempo y riesgos.
Se debe comprobar que todos los integrantes coinciden en la definición del sistema y que las estimaciones sean realistas.
Cada fase se subdivide en iteraciones.
Cada fase concluye con un hito definido, un punto donde se toman ciertas decisiones y alcanzar las metas clave.
Estructura Estática del Proceso
RUP define los roles (¿Quién?), las actividades (¿Cómo?), los productos (¿Qué?), y los flujos de trabajo de las disciplinas (¿Cuándo?).
Un rol define el comportamiento y responsabilidades de un individuo o grupo trabajando en equipo.
Una persona puede desempeñar varios roles, así como un rol puede ser representado por varias personas.
Una actividad es una unidad de trabajo que desempeña una persona.
Tienen un objetivo concreto, expresado generalmente en crear o actualizar algo.
Un Producto es un trozo de información que es producido, modificado o usado durante el proceso de desarrollo.
Son los resultados tangibles del proyecto, las cosas que va creando y usando para obtener el producto final.
Un Flujo de Trabajo es una relación de actividades que nos producen resultados observables.
Modelado del negocio - Requisitos - Analisis y Diseño.
Implementación - Pruebas - Despliegue.
Gestión del Proyecto - Configuración y control de Cambios - Entorno.
Configuración RUP para Proyecto Pequeño
Flujos de Trabajo
Características del Producto Software.
Glosario
Modelo de Casos de Uso.
Especificaciones de Casos de Uso.
Modelo de Análisis y Diseño.
Modelo Lógico Relacional.
Modelo de Implementación.
2 more items...
Describe la representación lógica de los datos persistentes, de acuerdo con el enfoque para modelado relacional de datos.
Establece la realización de los casos de uso en clases y pasando desde una representación en términos de análisis hacia una de diseño.
Se realiza una descripción detallada utilizando una plantilla de documento.
Presenta la funcionalidad del sistema y los actores que hacen uso de ella.
Documento que define los principales términos usados en el proyecto.
Es una lista de las características principales del producto.
Se utilizarán Diagramas de Actividad para modelar los Flujos de Trabajo del área problema.
Metodología, características principales y estructura del proceso.