Todos los Flujos de Trabajo del Unified Software Development Process definen artefactos y roles estáticos unidos por un workflow dinámico. Los principales son:
- Captura de Requisitos.
- Análisis.
- Diseño.
- Implementación.
- Prueba.
Cada rol es responsable de ciertos artefactos, los cuales son las entradas o salidas de ciertas actividades de cada flujo de trabajo.
A estos flujos de trabajo el Rational Unified Process los denomina disciplinas.
Captura de Requisitos
En este flujo de trabajo se encuentran los casos de uso definidos desde el punto de vista del cliente. Se tiene en cuenta:
- Lista de características: las cosas generales que el sistema debería hacer.
- Modelado del Dominio: para entender los conceptos del negocio.
- Modelado del Negocio: para entender los procesos del negocio.
Roles y sus artefactos:
- Analista de sistema: responsable del modelo de casos de uso, de los actores, y del glosario.
- Especificador de casos de uso: responsable de los casos de uso.
- Diseñador de UI: responsable del prototipo de la UI.
- Arquitecto: responsable de la descripción de la arquitectura, que considera a los CU críticos.
La descripción de la arquitectura es un extracto adecuado de los modelos que evoluciona a medida que se avanza por el proceso. Tiene cinco secciones, una para cada modelo:
- Vista de casos de uso: presenta los actores y casos de uso más importantes.
- Vista de análisis: no siempre se mantiene.
- Vista de diseño: subsistemas, interfaces, y clases más importantes.
- Vista de despliegue: nodos (hardware) asignados a objetos activos (hilos de ejecución).
- Vista de implementación: componentes que implementan los modelos de diseño y de despliegue.
Flujo de Análisis
Estructuramos los requisitos en un modelo de análisis con lenguaje técnico. Se considera que este flujo de trabajo es opcional, por lo que no es necesario mantenerlo a lo largo del tiempo.
Roles:
- Arquitecto: responsable del modelo de análisis.
- Ingeniero de casos de uso: responsable de la realización de CU-análisis.
- Ingeniero de componentes: responsable de las clases y de los paquetes del análisis.
Flujo de Diseño
En este flujo se le da forma al sistema. Se trasladan los requisitos a un modelo para ser implementado. Se piensa en requisitos no funcionales, en tecnologías, en interfaces. El modelo de diseño es físico y específico a una implementación, por lo que debe mantenerse a lo largo del proceso.
Roles:
- Arquitecto: responsable del modelo de diseño, del modelo de desarrollo, y de la descripción de la arquitectura (que considera subsistemas, interfaces, dependencias, y clases críticas).
- Ingeniero de casos de uso: responsable de la realización de CU-diseño.
- Ingeniero de componentes: responsable de las interfaces y las clases y subsistemas de diseño.
Una realización de caso de uso-diseño es una colaboración en el modelo de diseño que describe cómo se realiza y ejecuta un caso de uso específico, en términos de clases de diseño y sus objetos.
Flujo de Implementación
El modelo se implementa en términos de componentes, los cuales son scripts, ejecutables, etc.
Roles:
- Arquitecto: responsable del modelo de implementación, la descripción de la arquitectura, y el modelo de despliegue.
- Integrador del sistema: responsable de la integración del sistema (Integración Continua).
- Ingeniero de componentes: responsable de las interfaces, los componentes (que resuelven el empaquetamiento físico del modelo), y las implementaciones de subsistemas.
Flujo de Prueba
Se verifican las construcciones logradas.
Roles:
- Ingeniero de pruebas: responsable del modelo de pruebas, los casos de pruebas (que tienen trazabilidad hacia los casos de uso que prueban), el procedimiento de pruebas, la evaluación de pruebas, y el plan de pruebas.
- Ingeniero de pruebas de integración: responsable de los defectos (anomalías a resolver).
- Ingeniero de pruebas del sistema: responsable de los defectos (anomalías a resolver).
- Ingeniero de componentes: responsable de los componentes de prueba, que automatizan los procedimientos de prueba (Automatización de Pruebas).