Please enable JavaScript.

Coggle requires JavaScript to display documents.

Rational Unified Process (RUP) - Coggle Diagram

- - - - En junio del 1998 se lanza Rational Unified Process.
- - - - La arquitectura de un sistema es la organización o estructura de sus partes más relevantes, lo que permite tener una visión común entre todos los involucrados (desarrolladores y usuarios) y una perspectiva clara del sistema completo, necesaria para controlar el desarrollo
        
        En el caso de RUP además de utilizar los Casos de Uso para guiar el proceso se presta especial atención al establecimiento temprano de una buena arquitectura que no se vea fuertemente impactada ante cambios posteriores durante la construcción y el mantenimiento.
        
        la evolución de la arquitectura durante las fases de RUP. Se tiene una arquitectura más robusta en las fases finales del proyecto. En las fases iniciales lo que se hace es ir consolidando la arquitectura por medio de baselines y se va modificando dependiendo de las necesidades del proyecto.
        
        Es conveniente ver el sistema desde diferentes perspectivas para comprender mejor el diseño por lo que la arquitectura se representa mediante varias vistas que se centran en aspectos concretos del sistema,abstrayéndose de los demás. Para RUP, todas las vistas juntas forman el llamado modelo 4+1 de la arquitectura
    - - Para esto,la estrategia que se propone en RUP es tener un proceso iterativo e incremental en donde el trabajo se divide en partes más pequeñas o mini proyectos. Permitiendo que el equilibrio entre Casos de Uso y arquitectura se vaya logrando durante cada mini proyecto, así durante todo el proceso de desarrollo.
        
        Una iteración puede realizarse por medio de una cascada.
        Se pasa por los
        flujos fundamentales (Requisitos, Análisis, Diseño, Implementación y Pruebas),
        
        El proceso iterativo e incremental consta de una secuencia de iteraciones. Cada iteración aborda una partede la funcionalidad total, pasando por todos los flujos de trabajo relevantes y refinando la arquitectura. Cadaiteración se analiza cuando termina.
        
        RUP divide el proceso en cuatro fases, dentro de las cuales se realizan varias iteraciones en número
        variable según el proyecto y en las que se hace un mayor o menor hincapié en los distintas actividades.
    - - Los Casos de Uso son una técnica de captura de requisitos que fuerza a pensar en términos de importancia para el usuario y no sólo en términos de funciones que seria bueno contemplar. Se define un Caso de Uso como un fragmento de funcionalidad del sistema que proporciona al usuario un valor añadido.Los Casos de Uso representan los requisitos funcionales del sistema.
        
        Los Casos de Uso no sólo inician el proceso de desarrollo sino que proporcionan un hilo conductor,permitiendo establecer trazabilidad entre los artefactos que son generados en las diferentes actividades del proceso de desarrollo.
- - - - La creación de sistemas intensivos en software requiere dividir el sistema en componentes con interfaces
        bien definidas, que posteriormente serán ensamblados para generar el sistema.
    - - UML es un lenguaje para visualizar, especificar, construir y documentar los artefactos de un sistema
        software.
      - Utilizar herramientas de modelado visual facilita
        la gestión de dichos modelos, permitiendo ocultar o exponer detalles cuando sea necesario.
    - - 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.
    - - Es importante que la calidad de todos los artefactos se evalúe en varios puntos durante el proceso de
        desarrollo, especialmente al final de cada iteración.
    - - 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 losrequisitos.
    - - El cambio es un factor de riesgo crítico en los proyectos de software. Los artefactos software cambian no sólo debido a acciones de mantenimiento posteriores a la entrega del producto, sino que durante el proceso de desarrollo, especialmente importantes por su posible impacto son los cambios en los requisitos.
- - - - Representa el tiempo y es considerado el eje de los aspectos dinámicos del proceso. Indica
        las características del ciclo de vida del proceso expresado en términos de fases, iteraciones e hitos.
    - - 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.
  - - - Cada fase se concluye con un hito bien definido, un punto en el tiempo en el cual se deben tomar ciertas decisiones críticas y alcanzar las metas clave antes de pasar a la siguiente fase, ese hito principal de cada fase se compone de hitos menores que podrían ser los criterios aplicables a cada iteración.
        
        La duración y esfuerzo dedicado en cada fase es variable dependiendo de las características del proyecto.
    - - Elaboración
        
        El propósito de la fase de elaboración es analizar el dominio del problema, establecer los cimientos de la
        arquitectura, desarrollar el plan del proyecto y eliminar los mayores riesgos.
      - Construcción
        
        La finalidad principal de esta fase es alcanzar la capacidad operacional del producto de forma incremental a través de las sucesivas iteraciones. Durante esta fase todos los componentes, características y requisitos deben ser implementados, integrados y probados en su totalidad, obteniendo una versión aceptable del producto.
      - Inicio
        
        Durante la fase de inicio se define el modelo del negocio y el alcance del proyecto. Se identifican todos los actores y Casos de Uso, y se diseñan los Casos de Uso más esenciales (aproximadamente el 20% del modelo completo). Se desarrolla, un plan de negocio para determinar que recursos deben ser asignados al proyecto.
      - Transición
        
        La finalidad de la fase de transición es poner el producto en manos de los usuarios finales, para lo que se requiere desarrollar nuevas versiones actualizadas del producto, completar la documentación, entrenar al usuario en el manejo del producto, y en general tareas relacionadas con el ajuste, configuración, instalación y facilidad de uso del producto.
- - - - Una actividad en concreto es una unidad de trabajo que una persona que desempeñe un rol puede ser solicitado a que realice. Las actividades tienen un objetivo concreto, normalmente expresado en términos de crear o actualizar algún producto.
    - - Un producto o artefacto es un trozo de información que es producido, modificado o usado durante el proceso de desarrollo de software. Los productos son los resultados tangibles del proyecto, las cosas que va creando y usando hasta obtener el producto final.
      - Un artefacto puede ser cualquiera de los siguientes:
        
        Un modelo, como el modelo de Casos de Uso o el modelo de diseño
        
        Un elemento del modelo, un elemento que pertenece a un modelo como una clase, un Caso de Uso o
        un subsistema.
        
        Un documento, como el documento de la arquitectura del software
    - - Un rol define el comportamiento y responsabilidades de un individuo, o de un grupo de individuos trabajando juntos como un equipo. Una persona puede desempeñar diversos roles, así como un mismo rol puede ser representado por varias personas.
      - RUP define grupos de roles, agrupados por participación en actividades relacionadas. Estos grupos son:
        
        Gestores
        
        Apoyo
        
        Desarrolladores
        
        Especialista en pruebas
        
        Analistas
        
        Otros roles
    - - Un flujo
        de trabajo es una relación de actividades que nos producen unos resultados observables. Se consta de los siguientes flujos de trabajo:
        
        Análisis y Diseño
        
        El objetivo de este flujo de trabajo es traducir los requisitos a una especificación que describe cómo
        implementar el sistema.
        
        Implementación
        
        En este flujo de trabajo se implementan las clases y objetos en ficheros fuente, binarios, ejecutables y demás. Además se deben hacer las pruebas de unidad: cada implementador es responsable de probar las unidades que produzca. El resultado final de este flujo de trabajo es un sistema ejecutable.
        
        Requisitos
        
        Este es uno de los flujos de trabajo más importantes, porque en él se establece qué tiene que hacer exactamente el sistema que construyamos. 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.
        
        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.
        
        Modelado del negocio
        
        Con este flujo de trabajo pretendemos llegar a un mejor entendimiento de la organización donde se va a
        implantar el producto.
        
        Despliegue
        
        El objetivo de este flujo de trabajo es producir con éxito distribuciones del producto y distribuirlo a los
        usuarios. Las actividades implicadas incluyen:
        
        Gestión del proyecto
        
        La Gestión del proyecto es el arte de lograr un balance al gestionar objetivos, riesgos y restricciones para
        desarrollar un producto que sea acorde a los requisitos de los clientes y los usuarios.
        
        Configuración y control de cambios
        
        La finalidad de este flujo de trabajo es mantener la integridad de todos los artefactos que se crean en el
        proceso, así como de mantener información del proceso evolutivo que han seguido.
        
        Entorno
        
        La finalidad de este flujo de trabajo es dar soporte al proyecto con las adecuadas herramientas, procesos ymétodos. Brinda una especificación de las herramientas que se van a necesitar en cada momento, así comodefinir la instancia concreta del proceso que se va a seguir.
- - - - Especificaciones de Casos de Uso
        
        Para los casos de uso que lo requieran (cuya funcionalidad no sea evidente o que no baste con una simple descripción narrativa) se realiza una descripción detallada utilizando una plantilla de documento,donde se incluyen:
        
        Precondiciones
        
        Postcondiciones
        
        Flujo de eventos
        
        Requisitos no-funcionales
        asociados
      - Modelo de Análisis y Diseño
        
        Este modelo establece la realización de los casos de uso en clases y pasando desde una representación en términos de análisis (sin incluir aspectos de implementación) hacia una de diseño(incluyendo una orientación hacia el entorno de implementación).
        
        Está constituido esencialmente por un
        Diagrama de Clases y algunos Diagramas de Estados para las clases que lo requieran.
      - Modelo de Casos de Uso
        
        El modelo de Casos de Uso presenta la funcionalidad del sistema y los actores que hacen uso de ella.
        Se representa mediante Diagramas de Casos de Uso.
      - Modelo Lógico Relacional
        
        Previendo que la persistencia de la información del sistema será soportada por una base de datos relacional, este modelo describe la representación lógica de los datos persistentes, de acuerdo con el
        enfoque para modelado relacional de datos.
        
        Para expresar este modelo se utiliza un Diagrama de
        Tablas donde se muestran las tablas, claves, etc.
      - Glosario
        
        Es un documento que define los principales términos usados en el proyecto. Permite establecer una
        terminología consensuada.
      - Modelo de Implementación
        
        Este modelo es una colección de componentes y los subsistemas que los contienen. Estos
        componentes incluyen:
        
        Ficheros ejecutables
        
        Ficheros de código fuente
        
        Otros tipos de ficheros.
      - Características del Producto Software
        
        Es una lista de las características principales del producto, deseables desde una perspectiva de las
        necesidades del cliente.
      - Modelo de Pruebas
        
        Para cada Caso de Uso se establecen pruebas de Aceptación que validarán la correcta implementación
        del Caso de Uso.
        
        Cada prueba es especificada mediante un documento que establece las condiciones
        de ejecución, las entradas de la prueba, y los resultados esperados.
      - Flujos de Trabajo
        
        Se utilizarán Diagramas de Actividad para modelar los Flujos de Trabajo (workflows) del área problema,tanto los actuales (previos a la implantación de nuevo sistema) como los propuestos, que serán soportados por el sistema desarrollado
      - Manual de Instalación
        
        Este documento incluye las instrucciones para realizar la instalación del producto.
      - Material de Usuario
        
        Corresponde a un conjunto de documentos y facilidades de uso del sistema.
      - Producto
        
        Todos los ficheros fuente y ejecutable del producto