Please enable JavaScript.

Coggle requires JavaScript to display documents.

Rational Unified Process - Coggle Diagram

- - - - Permite trazabilidad entre artefactos
      - Permite crear modelos de análisis y diseño
  - - - Permite tener una visión común entre todos los involucrados (desarrolladores y usuarios)
      - Permite tener perspectiva clara del
        sistema completo, necesaria para controlar el desarrollo
    - - Aspectos estáticos
      - Aspectos dinámicos
      - Toma de decisiones
        
        Ayuda a determinar el orden
        
        Atención a crear buena estructura que resista cambios posteriores durante la construcción y mantenimiento
    - - Plataforma software
      - Sistema operativo
      - Gestor de base de datos
      - Protocolos
      - Sistemas heredados
      - Muchas de estas restricciones constituyen requisitos no funcionales del sistema
  - - - Cada parte pequeña o mini proyecto se puede ver como una iteración
    - - Pasa por los flujos fundamentales
        
        Requisitos
        
        Análisis
        
        Diseño
        
        Implementación
        
        Prueba e integración
      - Cada iteración aborda una funcionalidad total
      - Cada iteración se analiza cuando termina
      - Los resultados de los análisis ayudan a reajustar las siguientes iteraciones
    - - Inicio
        
        Énfasis en actividades de modelado del negocio y requsitos
      - Elaboración
        
        Desarrollo del baseline de la arquitectura
      - Construcción
        
        Serie de iteraciones
      - Transición
        
        Garantizar que se tiene un producto preparado
- - - - Objetivos
        
        Establecer el ámbito del proyecto y sus límites.
        
        Encontrar los Casos de Uso críticos del sistema, los escenarios básicos que definen la
        funcionalidad.
        
        Mostrar al menos una arquitectura candidata para los escenarios principales.
        
        Estimar el coste en recursos y tiempo de todo el proyecto.
        
        Estimar los riesgos, las fuentes de incertidumbre.
      - Resultados
        
        Un documento de visión
        
        Modelo inicial de Casos de Uso (10-20% completado).
        
        Un glosario inicial: Terminología clave del dominio.
        
        El caso de negocio.
        
        Lista de riesgos y plan de contingencia.
        
        Plan del proyecto, mostrando fases e iteraciones.
        
        Modelo de negocio, si es necesario
        
        Prototipos exploratorios para probar conceptos o la arquitectura candidata.
      - Comprobación
        
        Todos los interesados en el proyecto coinciden en la definición del ámbito del sistema y las
        estimaciones de agenda.
        
        Entendimiento de los requisitos, como evidencia de la fidelidad de los Casos de Uso principales.
        
        Las estimaciones de tiempo, coste y riesgo son creíbles.
        
        Comprensión total de cualquier prototipo de la arquitectura desarrollado.
        
        Los gastos hasta el momento se asemejan a los planeados.
        
        Si el proyecto no pasa estos criterios hay que plantearse abandonarlo o repensarlo profundamente.
      - Identificación de todos los actores y casos de uso
    - - Analizar el dominio del problema, establecer los cimientos de la arquitectura, desarrollar el plan del proyecto y eliminar los mayores riesgos.
      - Objetivos
        
        Definir, validar y cimentar la arquitectura.
        
        Completar la visión.
        
        Crear un plan fiable para la fase de construcción. Este plan puede evolucionar en sucesivas iteraciones. Debe incluir los costes si procede.
        
        Demostrar que la arquitectura propuesta soportará la visión con un coste razonable y en un tiempo
        razonable.
      - Resultados
        
        Un modelo de Casos de Uso completa al menos hasta el 80%: 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 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 que especifica el proceso a seguir.
        
        Un manual de usuario preliminar (opcional).
      - Comprobación
        
        La visión del producto es estable.
        
        La arquitectura es estable.
        
        Se ha demostrado mediante la ejecución del prototipo que los principales elementos de riesgo han sido abordados y resueltos.
        
        El plan para la fase de construcción es detallado y preciso. Las estimaciones son creíbles.
        
        Todos los interesados coinciden en que la visión actual será alcanzada si se siguen los planes actuales en el contexto de la arquitectura actual.
        
        Los gastos hasta ahora son aceptables, comparados con los previstos.
    - - Alcanzar la capacidad operacional del producto de forma incremental a través de las sucesivas iteraciones.
      - Objetivos
        
        Minimizar los costes de desarrollo mediante la optimización de recursos y evitando el tener que rehacer un trabajo o incluso desecharlo.
        
        Conseguir una calidad adecuada tan rápido como sea práctico.
        
        Conseguir versiones funcionales (alfa, beta, y otras versiones de prueba) tan rápido como sea práctico.
      - Resultados
        
        Modelos Completos (Casos de Uso, Análisis, Diseño, Despliegue e Implementación)
        
        Arquitectura íntegra (mantenida y mínimamente actualizada)
        
        Riesgos Presentados Mitigados
        
        Plan del Proyecto para la fase de Transición.
        
        Manual Inicial de Usuario (con suficiente detalle)
        
        Prototipo Operacional – beta
        
        Caso del Negocio Actualizado
      - Comprobación
        
        El producto es estable y maduro como para ser entregado a la comunidad de usuario para ser probado.
        
        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.
    - - Poner el producto en manos de los usuarios finales
      - Se puede incluir
        
        Prueba de la versión Beta para validar el nuevo sistema frente a las expectativas de los usuarios
        
        Funcionamiento paralelo con los sistemas legados que están siendo sustituidos por nuestro proyecto.
        
        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 que incluye todos los modelos del sistema
        
        Descripción de la Arquitectura completa y corregida
        
        Las iteraciones de esta fase irán dirigidas normalmente a conseguir una nueva versión.
      - Comprobación
        
        El usuario se encuentra satisfecho.
        
        Son aceptables los gastos actuales versus los gastos planificados.
  - - - Comportamiento y responsabilidades de un individuo, o de un grupo de individuos trabajando
        juntos como un equipo.
      - Grupos
        
        Analistas
        
        Desarrolladores
        
        Gestores
        
        Apoyo
        
        Especialista en pruebas
        
        Otros
        
        Stakeholder, revisor, coordinador de revisiones.
    - - Unidad de trabajo que una persona que desempeñe un rol puede realizar.
    - - Un documento, como el documento de la arquitectura del software.
      - 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.
    - - Secuencia de actividades
      - Modelado del negocio
        
        Entender la estructura y la dinámica de la organización para la cual el sistema va ser desarrollado
        (organización objetivo).
        
        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
        
        Establecer y mantener un acuerdo entre clientes y otros stakeholders sobre lo que el sistema podría
        hacer.
        
        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.
      - Análisis y diseño
        
        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.
      - Implementación
        
        Planificar qué subsistemas deben ser implementados y en que orden deben ser integrados, formando 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
        
        Encontrar y documentar defectos en la calidad del software.
        
        Generalmente asesora sobre la calidad del software percibida.
        
        Verificar las funciones del producto de software según lo diseñado.
        
        Provee la validación de los supuestos realizados en el diseño y especificación de requisitos por medio
        de demostraciones concretas.
        
        Verificar que los requisitos tengan su apropiada implementación.
      - Despliegue
        
        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
        
        Proveer un marco de trabajo para la gestión de proyectos de software intensivos.
        
        Proveer guías prácticas realizar planeación, contratar personal, ejecutar y monitorear el proyecto.
        
        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
        
        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.
- - - - Modelos de casos de uso
        
        Diagrama de casos de uso
        
        Prototipo de interfaces
        
        Especificaciones de casos de uso
    - - Pruebas de aceptación
    - - Diagrama de clases
        
        Modelo lógico relacional
        
        Diagrama de tablas
      - Diagramas de estado
    - - Diagrama de componentes