Please enable JavaScript.

Coggle requires JavaScript to display documents.

RUPRUP logo - Coggle Diagram

- - - - Según "Kru00", los Casos de Uso son una técnica de captura de requisitos que fuerza a pensar en términos
        de importancia para el usuario
      - Se define 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
      - En RUP no solo son para representar los requisitos funcionales del sistema, sino que 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
      - Proporcionan un hilo conductor, permitiendo establecer trazabilidad entre los artefactos que son generados en las diferentes actividades
      - Basándose en los Casos de Uso se crean los modelos de análisis y diseño
        
        Todos los modelos deben estar sincronizados con el
        modelo de Casos de Uso.
    - - La arquitectura de un sistema es la organización o estructura de sus partes más relevantes.
      - está relacionada con la toma de decisiones
      - Además de utilizar los Casos de Uso para guiar el proceso se presta especial atención al establecimiento temprano de una buena arquitectura.
      - Existe una interacción entre los Casos de Uso
        y la arquitectura
        
        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,
        
        Esto provoca que tanto arquitectura como Casos de Uso deban evolucionar en paralelo
      - la arquitectura se representa mediante varias vistas que se centran en aspectos concretos del sistema
        
        Para RUP, todas las vistas juntas forman el llamado modelo 4+1 de la arquitectura
      - Se incorporan pocos cambios a la
        arquitectura
      - Al final de la fase de elaboración se obtiene una baseline1 de la arquitectura donde fueron seleccionados una serie de Casos de Uso.
    - - un proceso iterativo e incremental es en donde el trabajo se
        divide en partes más pequeñas o mini proyectos de manera que el desarrollo fuese más sencillo.
      - El proceso iterativo e incremental consta de una secuencia de iteraciones.
        
        Cada iteración aborda una parte
        de la funcionalidad total
      - Toda la retroalimentación de la iteración pasada permite reajustar los objetivos para las siguientes iteraciones
      - RUP divide el proceso en cuatro fases
        
        Inicio
        
        ponen mayor énfasis en actividades modelado del negocio y
        de requisitos.
        
        Elaboración
        
        se orientan al desarrollo de la baseline de la arquitectura
        
        construcción
        
        se lleva a cabo la construcción del producto por medio de las iteraciones
        
        transición
        
        pretende garantizar que se tiene un producto preparado para su entrega
- - - - Representa el tiempo y es considerado el eje de los aspectos dinámicos del proceso
    - - : Representa los aspectos estáticos del proceso
  - - - Cada ciclo concluye
        con una generación del producto para los clientes
        
        Cada ciclo consta de cuatro fases
        
        Inicio, Elaboración, Construcción y Transición
        
        Cada fase se concluye con un hito bien definido, un punto en el tiempo en el cual se deben tomar ciertas decisiones críticas
        
        Los hitos para
        cada una de las fases son
        
        Inicio - Lifecycle Objectives
        
        3 more items...
        
        Elaboración - Lifecycle Architecture
        
        3 more items...
        
        Construcción -
        Initial Operational Capability
        
        3 more items...
        
        Transición - Product Release
        
        4 more items...
- - - - 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 cápsulas
        
        Diseñador de base de datos
        
        Implementador.
        
        Integrador
      - Gestores
        
        Jefe de proyecto
        
        Jefe de control de cambios
        
        Jefe de configuración
        
        Jefe de pruebas
        
        Jefe de despliegue
        
        Ingeniero de procesos
        
        Gestor de pruebas.
        
        Revisor de gestión del proyecto
      - Apoyo
        
        Documentador técnico
        
        Administrador de sistema
        
        Especialista en herramientas
        
        Desarrollador de cursos
        
        Artista gráfico
      - Especialista en pruebas
        
        Especialista en Pruebas (tester)
        
        Analista de pruebas
        
        Diseñador de pruebas
      - Otros roles
        
        Stakeholders
        
        Revisor
        
        Coordinación de revisiones
        
        Revisor técnico
        
        Cualquier rol
  - - - necesitamos contar con una
        secuencia de actividades realizadas por los diferentes roles
        
        Modelado del negocio
        
        Con este flujo de trabajo pretendemos llegar a un mejor entendimiento de la organización
        
        Los objetivos del modelado de negocio son
        
        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
        
        Requisitos
        
        Este es uno de los flujos de trabajo más importantes, porque en él se establece qué tiene que hacer exactamente el sistema
        
        Los objetivos del flujo de datos Requisitos es
        
        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
        
        Definir una interfaz de usuarios para el sistema, enfocada a las necesidades y metas del usuario
        
        Los requisitos se dividen en dos grupos
        
        Requisitos funcionales
        
        representan la funcionalidad del sistema
        
        Requisitos no funcionales
        
        representan aquellos
        atributos que debe exhibir el sistema, pero que no son una funcionalidad específica
        
        Análisis y Diseño
        
        Los objetivos del análisis y diseño son
        
        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, diseñando para el rendimiento
        
        El análisis consiste en obtener una visión del sistema que se preocupa de ver qué hace
        
        El diseño consiste en
        colaboraciones de clases, que pueden ser agregadas en paquetes y subsistemas
        
        Otro producto importante de este flujo es la documentación de la arquitectura de software
        
        Implementación
        
        En este flujo de trabajo se implementan las clases y objetos en ficheros fuente, binarios, ejecutables y
        demás
        
        En cada iteración habrá que hacer lo siguiente
        
        Planificar qué subsistemas deben ser implementados y en que orden deben ser integrados
        
        Cada implementador decide en que orden implementa los elementos del subsistema
        
        Cada implementador decide en que orden implementa los elementos del subsistema
        
        Se prueban los subsistemas individualmente
        
        Se integra el sistema siguiendo el plan
        
        La estructura de todos los elementos implementados forma el modelo de implementación
        
        Pruebas
        
        Este flujo de trabajo es el encargado de evaluar la calidad del producto que estamos desarrollando
        
        Esta disciplina brinda soporte a las otras disciplinas. Sus objetivos son
        
        Encontrar y documentar defectos en la calidad del software
        
        Encontrar y documentar defectos en la calidad del software
        
        Encontrar y documentar defectos en la calidad del software
        
        Verificar las funciones del producto de software según lo diseñado
        
        Verificar las funciones del producto de software según lo diseñado
        
        Las actividades de este flujo comienzan pronto en el proyecto con el plan de prueba
        
        Despliegue
        
        El objetivo de este flujo de trabajo es producir con éxito distribuciones del producto y distribuirlo a los
        usuarios
        
        Las actividades implicadas incluyen
        
        Las actividades implicadas incluyen
        
        Empaquetar el software para su distribución
        
        Distribuir el software
        
        Instalar el software
        
        Proveer asistencia y ayuda a los usuarios
        
        Proveer asistencia y ayuda a los usuarios
        
        Migrar el software existente o convertir bases de datos
        
        Este flujo de trabajo se desarrolla con mayor intensidad en la fase de transición
        
        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
        
        Los objetivos de este flujo de trabajo son
        
        Los objetivos de este flujo de trabajo son
        
        Proveer guías prácticas realizar planeación, contratar personal, ejecutar y monitorear el proyecto
        
        Proveer un marco de trabajo para gestionar riesgos
        
        La planeación de un proyecto posee dos niveles de abstracción
        
        un plan para las fases
        
        un plan para cada
        iteración
        
        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
        
        Entorno
        
        La finalidad de este flujo de trabajo es dar soporte al proyecto con las adecuadas herramientas, procesos y
        métodos
        
        En concreto las 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
        
        El principal artefacto que se usa en este flujo de trabajo es el caso de desarrollo que especifica para el
        proyecto actual en concreto
  - - - Un producto o artefacto es un trozo de información que es producido, modificado o usado durante el
        proceso de desarrollo de software
        
        Un artefacto puede ser cualquiera de los siguientes
        
        Un elemento del modelo
        
        Un modelo
        
        Un documento
- - - - 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
    - - o presenta la funcionalidad del sistema y los actores que hacen uso de ell
    - - se realiza una descripción detallada utilizando una plantilla de document
    - - 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
    - - Este documento incluye las instrucciones para realizar la instalación del producto.
    - - Corresponde a un conjunto de documentos y facilidades de uso del sistema.
    - - Todos los ficheros fuente y ejecutable del producto.
  - - - Se modelarán los procesos de negocio de la situación actual utilizando Diagramas de Actividad
      - 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
      - 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
      - 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