Requisitos del proceso unificado

Mapa conceptual (resumen) 3 al 7 de noviembre

Get Started. It's Free
or sign up with your email address
Requisitos del proceso unificado by Mind Map: Requisitos del proceso unificado

1. Centrado a la arquitectura

1.1. Un sistema de software se describe mediante diferentes vistas del sistema en construcción

1.2. Incluye los aspectos estáticos y dinámicos más significativos del sistema.

1.3. Es una vista del diseño completo con las características más importantes resaltadas

2. Iterativo e incremental

2.1. Cada mini proyecto es una iteración que resulta en un incremento

2.1.1. Las iteraciones hace referencia a pasos en el flujo de trabajo.

2.1.1.1. Deben estar controladas

2.1.1.2. Deben seleccionarse y ejecutarse de una forma planificada

2.1.2. Los incrementos hacen referencia a crecimientos en el producto

2.2. Beneficios

2.2.1. La iteración controlada reduce el riesgo a los costes de un solo incremento

2.2.2. Reduce el riesgo de retrasos en el calendario atacando los riesgos mas importantes primero.

2.2.3. Acelera el desarrollo. Los trabajadores trabajan de manera más eficiente al obtener resultados a corto plazo

2.2.4. Tiene un enfoque más realista al reconocer que los requisitos no pueden definirse completamente al principio.

3. Dirigido por casos de uso

3.1. Es un fragmento de funcionalidad del sistema que proporciona un resultado de valor a un usuario.

3.2. Modelan los requerimientos funcionales del sistema

3.2.1. Todos los casos de uso juntos constituyen el modelo de casos de uso

3.3. Guían el proceso de desarrollo (diseño, implementación, y prueba).

4. Ciclo de vida del proceso unificado

4.1. Inicio

4.1.1. Define el alcance del proyecto

4.1.1.1. Alcances y objetivos

4.1.1.1.1. Se identifican y priorizan los riesgos mas importantes

4.2. Elaboración

4.2.1. Planificar el proyecto, elegir una arquitectura base

4.2.1.1. Arquitectura

4.2.1.1.1. Se especifican en detalle la mayoría de los casos de uso del producto y se diseña la arquitectura

4.3. Construcción

4.3.1. Construir el sistema

4.3.1.1. Iteraciones

4.3.1.1.1. Entregas internas

4.4. Transición

4.4.1. Transición a los usuarios

4.4.1.1. Versión final

4.4.1.1.1. Cubre el período durante el cual el producto se convierte en la versión beta

4.5. Cada fase se divide en iteraciones y cada iteración en conjunto de disciplinas o flujos de trabajo

4.5.1. Modelado del negocio

4.5.2. Requerimientos

4.5.2.1. Modelos de casos de uso

4.5.3. Análisis

4.5.3.1. Modelo de análisis

4.5.4. Codificación

4.5.4.1. Modelo de implementación

4.5.5. Prueba

4.5.5.1. Modelo de pruebas

4.5.6. Instalación

4.5.7. Diseño

4.5.7.1. Modelo de despliegue

4.6. Las disciplinas producen modelos