Please enable JavaScript.
Coggle requires JavaScript to display documents.
Rational Unified Process (RUP), image - Coggle Diagram
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
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
Conseguir que el usuario se valga por si mismo
Un producto final que cumpla con los requisitos esperados, que funcione y satisfaga al usuario
RESULTADOS
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
CRITERIOS DE EVALUACION
El usuario se encuentra satisfecho
Son aceptables los gastos actuales versus los gastos planificados
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
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
