Please enable JavaScript.

Coggle requires JavaScript to display documents.

RATIONAL UNIFIED PROCESS, 1 - Coggle Diagram

- - - - Todos los modelos deben estar sincronizados con el modelo de casos de uso
  - - - 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
    - - Para RUP, todas las vistas juntas forman el llamado modelo 4+1 de la arquitectura
  - - - Cada iteraciones aborda una parte de la funcionalidad total
    - - Inicio
      - Elaboración
      - Construcción
      - Transición
- - - - Analista de Proceso de Negocio
      - Diseñador del Negocio
      - Analista de Sistema
      - Especificador de Requisitos
    - - Integrador
      - Arquitecto de Software
      - Diseñador
      - Diseñador de Interfaz de Usuario
      - Diseñador de Cápsulas
      - Diseñador de Base de Datos
      - Implementador
    - - Ingeniero de Procesos
      - Jefe de Proyecto
      - Jefe de Control de Cambios
      - Jefe de Configuración
      - Jefe de Pruebas
      - Jefe de Despliegue
      - Gestor de Pruebas
      - Revisor de Gestión del Proyecto
    - - Artista Gráfico
      - Especialista en Herramientas
      - Documentador Técnico
      - Administrador de Sistema
      - Desarrollador de Cursos
    - - Especialista en Pruebas
        
        Tester
      - Analista de Pruebas
      - Diseñador de Pruebas
    - - Stakeholders
      - Revisor
      - Coordinación de Revisiones
      - Revisor Técnico
      - Cualquier Rol
  - - - Dar soporte al proyecto con las adecuadas herramientas, procesos y métodos
      - Responsabilidades de este flujo de trabajo incluyen
        
        Selección y Adquisición de Herramientas
        
        Establecer y Configurar las Herramientas para que se Ajusten a la Organización
        
        Configuración del Proceso
        
        Mejora del Proceso
        
        Servicios Técnicos
    - - Objetivos:
        
        Proveer un marco de trabajo para gestionar riesgos
        
        Proveer guías prácticas realizar planeación, contratar personal, ejecutar y monitorear el proyecto
      - La planeación de un proyecto posee dos niveles de abstracción
        
        Plan para las fases
        
        Plan para cada iteración
    - - 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 necesarios para apoyar a la organización objetivo
      - Se pretende llegar a un mejor entendimiento de la organización
    - - Se dividen en dos grupos
        
        Requisitos Funcionales
        
        Requisitos no Funcionales
      - Se establece qué tiene que hacer exactamente el sistema
      - Objetivos:
        
        Definir una interfaz de usuarios para el sistema
        
        Establecer y mantener un acuerdo entre clientes y otros
        
        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
    - - Objetivo:
        
        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
      - Análisis
        
        Consiste en obtener una visión del sistema que se preocupa de ver qué hace
      - Diseño:
        
        Consiste en colaboraciones de clases que pueden ser agregadas en paquetes y subsistemas
    - - Se implementan las clases y objetivos en ficheros fuente, binarios, ejecutables y demás
      - La estructura de todos los elementos implementados forma el modelo de implementación
    - - Este flujo de trabajo es el encargado de evaluar la calidad del producto que estamos desarrollando
      - Objetivos:
        
        Encontrar y documentar defectos en la calidad de software
        
        Verificar las funciones del producto de software según lo diseñado
    - - El objetivo de este flujo de trabajo es producir con éxito distribuciones del producto y distribuir a los usuarios
      - El flujo de trabajo se desarrolla con mayor intensidad en la fase de transición
    - - La finalidad de este flujo de trabajo es mantener la integridad de todos los artefactos que se crean en el proceso
- - - - Inicio - Lifercycle Objectives
      - Elaboración - Lifercycle Architecture
      - Construcción - Initial Operational Capability
      - Transición - Product Release
- - - - Todos los ficheros fuente y ejecutable del producto
    - - Se utilizarán diagramas de actividad para modelar los flujos de trabajo
    - - Es una lista de las características principales del producto
    - - Es un documento que define los principales términos usados en el proyecto
    - - Presenta la funcionalidad del sistema y los actores que hacen uso de el
    - - Se realiza una descripción detallada utilizando una plantilla de documento
    - - Establece la realización de los casos de uso en clases
    - - Describe la representación lógica de los datos persistentes
    - - Este modelo es una colección de componentes y los subsistemas que los contienen
    - - Cada prueba es especificada mediante un documento que establece las condiciones de ejecución
    - - Corresponde a un conjunto de documentos y facilidades de uso del sistema
    - - Este documento incluye las instrucciones para realizar la instalación del producto