2. Fase de Elaboración
Propósito
Objetivos
› Definir, validar y cimentar la arquitectura.
› Crear un plan fiable para la fase de construcción.
› Demostrar que la arquitectura propuesta
soportará la visión con un coste razonable y en
un tiempo razonable.
3. Fase de Elaboración - HITOS
› Un modelo de Casos de
Uso
› Descripción de la
arquitectura software
› Un prototipo ejecutable
de la arquitectura
› Lista de riesgos
› Plan de desarrollo para
el proyecto.
› Requisitos adicionales que capturan
los requisitos no funcionales y
cualquier requisito no asociado con un
Caso de Uso específico.
› Los gastos hasta ahora son
aceptables, comparados con los
previstos. Si no se superan los
criterios de evaluación quizá sea
necesario abandonar el proyecto o re
planteárselo considerablemente.
Al final de la fase se elabora un plan para la fase
de construcción.
4. Fase de Elaboración - Actividades
Actividades críticas
› Especificar los Requerimientos.
› Validar los Requerimientos.
› Priorizar los Requerimientos.
› Definir el Alcance del Sistema.
› Definir Pautas para la Interfaz de
Usuario
› Diseñar el Sistema.
› Describir la Arquitectura del
Sistema.
› Comunicar el Diseño a
Implementadores
› Planificar la Integración de la
Iteración.
› Integrar el Sistema.
Actividades no críticas
› Planificar la Calidad
› Revisión Técnica Formal
› Revisar las entregas.
› Revisión de Ajuste al
Proceso
› Planificar la Configuración
› Documentación de
Usuario
› Planificar la Transición.
5. Flujo de Requisitos
Aquí se establecen las prioridades y se estructuran los casos de usos
› Encontrar casos de usos y sus actores
› Desarrollar prototipos de interfaces de usuario
› Determinar la prioridad de los casos de uso
› Detallar un caso de uso
› Estructurar el modelo de casos de uso
6. Flujo de Requisitos
Artefactos
› Modelo de Casos de Uso
› Actor
› Casos de Uso
› Prototipo de Interfaz de
Usuario
Trabajadores
› Analista de Sistemas
› Especificador de Casos de
Uso
› Diseñador de Interfaz de
Usuario
› Arquitecto
7. Flujo de Análisis
En la fase de elaboración, necesitamos trabajar con los casos de
uso que son significativos desde un punto de vista de la
arquitectura, y con aquellos casos de uso complejos que
necesitemos refinar para comprender mejor los detalles de la
apuesta económica.
› Análisis de la arquitectura
› Analizar un caso de uso.
› Analizar una clase.
› Analizar un paquete.
8. Flujo de Análisis
Artefactos
› Modelo de Análisis: se representa mediante un sistema de análisis
que denota el paquete de más alto nivel del modelo.
› Clases de Análisis: representa una abstracción de una a varias clases
y/o subsistemas del diseño del sistema.
› Clases de Interfaz: modelan la interacción entre el sistema y sus
actores.
› Descripción de la Arquitectura (vista del modelo de análisis):
contiene una vista de la arquitectura del modelo de análisis.
9. Flujo de Análisis
Trabajadores
› Arquitecto: es responsable de la integridad del modelo de análisis,
garantizando que este sea correcto, consistente y legible como un
todo.
› Ingeniero de Casos de Uso: es el responsable de la integridad de una
o más realizaciones de caso de uso, garantizando que cumplen los
requisitos que caen sobre ellos.
› Ingeniero de Componentes: define y mantiene las responsabilidades,
atributos, relaciones y requisitos especiales de una o varias clases del
análisis. También mantiene la integridad de uno o varios paquetes del
análisis.
10. Flujo de Diseño
En esta fase de elaboración se diseñará desde un punto de
vista arquitectónico.
› Diseñar un caso de uso
› Diseñar una clase
› Diseñar un subsistema
El diseño es el centro de atención al final de la fase de
elaboración y al comienzo de las iteraciones de la construcción.
11. Flujo de Diseño
Artefactos
› Modelo de Diseño
› Clase del Diseño
› Realización de Casos de Uso
› Diagramas de Clases
› Diagramas de Interacción
› Requisitos de la implementación
› Subsistema de Diseño
› Subsistemas de servicio
› Descripción de la Arquitectura (vista
del modelo de diseño)
› Modelo de Despliegue
› Descripción de la Arquitectura (vista
del modelo de despliegue)
Trabajadores
› Arquitecto
› Ingenieros de Casos de Uso
› Ingeniero de Componentes
12. Flujo de Implementación
Este flujo de trabajo implementa y prueba los componentes
arquitectónicamente significativos a partir de los elementos de
diseño significativos. El resultado es la base de la arquitectura,
implementada normalmente a partir de menos del 10 por ciento de
los casos de uso.
Su propósito es:
› Planificar las integraciones del sistema en cada iteración.
› Distribuir el sistema asignando componentes ejecutables a
nodos en el diagrama de despliegue.
› Implementar las clases y subsistemas encontrados durante
el diseño.
› Probar los componentes individualmente y luego integrarlos.
13. Flujo de Implementación
Artefactos
› Modelo de Implementación
› Componente
› Subsistema de Implementación
› Interfaz
› Descripción de la Arquitectura (vista
del modelo de implementación)
Trabajadores
› Arquitecto
› Ingeniero de Componentes
› Integrador de Sistema
14. Flujo de Prueba
Aquí el objetivo es asegurarse de que los subsistemas de todos
los niveles y de todas las capas funcionen.
Durante este flujo se:
› Busca los defectos a lo largo del ciclo de vida.
› Verifica el resultado de la implementación.
› Planifican las pruebas necesarias en cada iteración.
› Diseña e implementa los casos de prueba que especifican que
probar.
› Realizan diferentes pruebas y manejan los resultados de estas
sistemáticamente.
› Prueban los componentes individualmente para luego integrarlos.
15. Flujo de Prueba
Artefactos
› Modelo de Pruebas
› Caso de Prueba
› Procedimiento de Prueba
› Componente de Prueba
› Plan de Prueba
› Defecto
› Evaluación de Prueba
Trabajadores
› Diseñador de Pruebas
› Ingeniero de Componentes
› Ingeniero de Pruebas de
Integración
› Ingeniero de Pruebas de
Sistema
16. Fase de Elaboración - Importancia
› Establece una base de la arquitectura sólida para guiar el
trabajo durante las fases de construcción y transición, así
como en las posteriores generaciones del sistema.
› Recopila la mayor parte de los requisitos que aún queden
pendientes, formulando los requisitos funcionales como
casos de uso.
› Continua la observación y control de los riesgos críticos que
aún queden, e identifica los riesgos significativos hasta el
punto de que podamos estimar su impacto en el análisis de
negocio, y en particular en la apuesta económica.