Please enable JavaScript.
Coggle requires JavaScript to display documents.
Rational Unified Process (RUP) - Coggle Diagram
Rational Unified Process (RUP)
Historia
1967 Metodología Ericsson (Ericsson Approach) elaborada por Ivar Jacobson. Introdujo el concepto de Caso de Uso.
Entre 1987 a 1995 Jacobson fundó la compañía Objectory AB y lanza el proceso de desarrollo Objectory (abreviación de Object Factory).
1995 Rational Software Corporation adquiere Objectory AB
Entre 1995 y 1997 se desarrolla Rational Objectory Process (ROP) a partir de Objectory 3.8 y del Enfoque Rational (Rational Approach) adoptando UML como lenguaje de modelado
1998 se lanza Rational Unified Process
Características esenciales
Proceso dirigido por Casos de Uso
Representan una interacción de un usuario
con el sistema
Son requisitos funcionales
Constituyen un elemento integrador y una
guía del trabajo
Proceso centrado en la arquitectura
Define los subsistemas y susinterfaces
Describe el sistema desde distintos puntos
de vista
Involucra los aspectos estáticos y dinámicos más significativos del sistema
Proceso iterativo e incremental
Se divide en
Construcción
Crear el producto
Transición
Refinar la versión final
Inicio
Desarrollar arquitectura del proyecto
Desarrollar plan general del proyecto
Desarrollar costos del proyecto
Desarrollar riesgos del proyecto
Desarrollar funciones del proyecto
Elaboración
Especificar casos de uso
Diseñar la
arquitectura base
Planificar actividades y recursos
Dividir el desarrollo del software en tareas mas pequeñas
Cada iteración resulta en un incremento y en una entrega funcional
Las iteraciones deben ser controladas para generar incremento y tratar los riesgos
Otras prácticas
Gestión de requisitos
Guía para encontrar, organizar, documentar, y seguir los cambios de los requisitos funcionales y restricciones
Desarrollo de software iterativo
Desarrollo del producto mediante iteraciones con hitos bien definidos
Desarrollo basado en componentes
El sistema se vaya creando a medida que se obtienen o se desarrollan sus componentes
Modelado visual (usando UML)
Mejorar la capacidad del equipo para gestionar la complejidad del software
Verificación continua de la calidad
La calidad de todos los artefactos se debe evaluar en varios puntos durante el proceso de desarrollo
Gestión de los cambios
El cambio es un factor de riesgo crítico en los proyectos de software
Estructura del proceso
Descrito en dos ejes
Eje horizontal
Organización a lo largo del tiempo
Eje vertical
Organización a lo largo del contenido
Estructura Dinámica del proceso
Inicio
objetivos
Establecer el ámbito del proyecto y sus límites
Encontrar los Casos de Uso críticos del sistema
Mostrar al menos una arquitectura candidata
Estimar el coste en recursos y tiempo
Estimar los riesgos
resultados
Un documento de visión
Modelo inicial de Casos de Uso (10-20%)
Un glosario inicial
El caso de negocio
Lista de riesgos y plan de contingencia
Plan del proyecto
Modelo de negocio
Prototipos exploratorios
criterios
Interesados en el proyecto coinciden en la definición del ámbito del sistema y las estimaciones de agenda
Entendimiento de los requisitos
Las estimaciones de tiempo, coste y riesgo son creíbles
Comprensión total de cualquier prototipo
Los gastos se asemejan a los planeados
Elaboración
objetivos
Definir, validar y cimentar la arquitectura
Completar la visión
Crear un plan fiable para la fase de construcción
Demostrar que la arquitectura propuesta soportará la visión con un coste razonable y en un tiempo razonable
resultados
Modelo de Casos de Uso (80%)
Requisitos adicionales que capturan los requisitos no funcionales y cualquier requisito no asociado con un Caso de Uso específico
Descripción de la arquitectura software
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
Un manual de usuario preliminar
criterios
La visión del producto es estable
La arquitectura es estable
Principales elementos de riesgo han sido abordados y resueltos
El plan para la fase de construcción es detallado y preciso
Todos los interesados coinciden en que la visión actual será alcanzada
Los gastos hasta ahora son aceptables
Construcción
objetivos
Minimizar los costes de desarrollo
Conseguir una calidad adecuada tan rápido como sea práctico
Conseguir versiones funcionales tan rápido como sea
práctico
resultados
Modelos Completos
Arquitectura íntegra
Riesgos Presentados Mitigados
Plan del Proyecto para la fase de Transición
Manual Inicial de Usuario
Prototipo Operacional
Caso del Negocio Actualizado
criterios
El producto es estable y maduro como para ser entregado
Todos los usuarios expertos están listos para la transición
Son aceptables los gastos actuales
Transición
observaciones
Validar el nuevo sistema frente a las expectativas de los usuarios
Funcionamiento paralelo con los sistemas legados
Conversión de las bases de datos operacionales
Entrenamiento de los usuarios y técnicos de mantenimiento
Traspaso del producto a los equipos de marketing, distribución y venta
objetivos
Conseguir que el usuario se valga por si mismo
Un producto final que cumpla los requisitos esperados, que funcione y satisfaga suficientemente al usuario
resultados
Prototipo Operacional
Documentos Legales
Caso del Negocio Completo
Línea de Base del Producto completa y corregida
Descripción de la Arquitectura completa y corregida
Iteraciones dirigidas a conseguir una nueva versión
criterios
El usuario se encuentra satisfecho
Son aceptables los gastos actuales
Estructura Estática del proceso
Roles
Analistas
Desarrolladores
Gestores
Apoyo
Especialista en pruebas
Otros
Actividades
Unidad de trabajo que una persona puede ser solicitado a que realice
Objetivo concreto
Artefactos
Trozo de información que es producido, modificado o usado durante el proceso de desarrollo de software
Puede ser
Un documento
Un modelo
Un elemento del modelo
Flujos de trabajo
Relación de actividades que nos producen unos resultados observables
tipo
Modelado del negocio
Llegar a un mejor entendimiento de la organización donde se va a implantar el producto
objetivos
Entender la estructura y la dinámica de la organización
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
Derivar los requisitos del sistema
Requisitos
objetivos
Establecer y mantener un acuerdo entre clientes y stakeholders sobre el propósito del sistema
Proveer a los desarrolladores un mejor entendimiento de los requisitos del sistema
Definir el ámbito del sistema
Proveer una base para la planeación de los contenidos técnicos de las iteraciones
Proveer una base para estimar costos y tiempo de desarrollo del sistema
Definir una interfaz de usuarios para el sistema
Establece qué tiene que hacer exactamente el sistema que construyamos
Análisis y Diseño
Traducir los requisitos a una especificación que describe cómo
implementar el sistema
objetivos
Transformar los requisitos al diseño del futuro sistema
Desarrollar una arquitectura para el sistema
Adaptar el diseño para que sea consistente con el entorno de implementación
Implementación
Implementan las clases y objetos en ficheros fuente, binarios, ejecutables y demás
objetivos
Formar el Plan de Integración
Cada implementador decide en que orden implementa los elementos del subsistema
Si encuentra errores de diseño, los notifica
Se prueban los subsistemas individualmente
Se integra el sistema siguiendo el plan
Pruebas
Encargado de evaluar la calidad del producto que estamos desarrollando
objetivos
Encontrar y documentar defectos en la calidad del software
Asesora sobre la calidad del software percibida
Provee la validación de los supuestos realizados en el diseño y especificación de requisitos
Verificar las funciones del producto de software
Verificar que los requisitos tengan su apropiada implementación
Despliegue
Producir con éxito distribuciones del producto y distribuirlo a los usuarios
objetivos
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
Gestión del proyecto
Lograr un balance al gestionar objetivos, riesgos y restricciones para desarrollar un producto acorde a los requisitos de los clientes y los usuarios
objetivos
Proveer un marco de trabajo para la gestión de proyectos
Proveer guías prácticas
Proveer un marco de trabajo para gestionar riesgos
Configuración y control de cambios
Mantener la integridad de todos los artefactos que se crean en el proceso
Entorno
Dar soporte al proyecto con las adecuadas herramientas, procesos y métodos
objetivos
Selección y adquisición de herramientas
Establecer y configurar las herramientas
Configuración del proceso
Servicios técnicos
Mejora del proceso
Una configuración RUP para proyecto pequeño
Entregables del proyecto
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
Modelo de Pruebas
Manual de Instalación
Material de Usuario
Esquema de trazabilidad
Se modelarán los procesos de negocio de la situación actual utilizando Diagramas de Actividad para representar Flujos de Trabajo Actuales
El modelo de procesos de la solución propuesta incluirá Flujos de Trabajo Propuestos junto con una lista de Características del Producto Software
Los requisitos serán establecidos mediante un Modelo de Casos de Uso que incluirá Diagramas de Casos de Uso, Prototipos de Interfaces de Usuario y Especificaciones de Casos de Uso
El Modelo de Pruebas incluirá las Pruebas de Aceptación establecidas para cada Caso de Uso
El Modelo de Análisis y Diseño establecerá el particionamiento interno del sistema
A partir del Diagrama de Clases, y considerando las clases que requieran persistencia, se derivará el Modelo Lógico Relacional, representado mediante Diagramas de Tablas
En el Modelo de Implementación se organizarán las operaciones de las clases en términos de componentes de dicha arquitectura
La implementación del Modelo Lógico Relacional y de los componentes de la aplicación constituirán el Producto, el cual se complementará con el Manual de Instalación y el Manual de Usuario