EL PROCESO UNIFICADO DE DESARROLLO DE SOFTWARE

Parte 1:
El Proceso Unificado de Desarrollo de Software

Capítulo 1: El Proceso Unificado: dirigido por casos de uso, centrado en la arquitectura, iterativo e incremental.
1.1. El Proceso Unificado en pocas palabras
1.2. El Proceso Unificado está dirigido por casos de uso
1.3. El Proceso Unificado está centrado en la arquitectura
1.4. El Proceso Unificado es iterativo e incremental
1.5. La vida del Proceso Unificado
1.5.1. El producto
1.5.2. Fases dentro de un ciclo
1.6. Un Proceso integrado

Capítulo 2: Las cuatro "P" en el desarrollo de software: Personas, Proyecto, Producto y Proceso.
2.1. Las personas son decisivas
2.1.1. Los procesos de desarrollo afectan a las personas
2.1.2. Los papeles cambiarán
2.1.3. Convirtiendo "recursos" en "trabajadores"
2.2. Los proyectos construyen el producto
2.3. El producto es más que código
2.3.1. ¿Qué es un sistema software?
2.3.2. Artefactos

XV
CONTENIDO
2.3.3. Un sistema posee una colección de modelos
2.3.4. ¿Qué es un modelo?
3.5. Cada modelo es una vista autocontenida del sistema
2.3.6. Dentro de un modelo
2.3.7. Relaciones entre modelos
2.4. El proceso dirige los proyectos
2.4.1. El proceso: una plantilla
2.4.2. Las actividades relacionadas conforman flujos de trabajo
2.4.3. Procesos especializados
2.4.4. Méritos del proceso
2.5. La herramientas son esenciales en el proceso
2.5.1. Las herramientas influyen en el proceso
2.5.2. El proceso dirige las herramientas
2.5.3. El equilibrio entre el proceso y las herramientas
2.5.4. El modelado visual soporta UML
2.5.5. Las herramientas dan soporte al ciclo de vida completo
2.6. Referencias

Capítulo 3: Un proceso dirigido por casos de uso
3.1. Desarrollo dirigido por casos de uso en pocas palabras
3.2. ¿Por qué casos de uso?
3.2.1. Para capturar los requisitos que aportan valor añadido
3.2.2. Para dirigir el proceso
3.3.3. Para idear la arquitectura y más...
3.3. La captura de casos de uso
3.3.1. El modelo de casos de uso representa los requisitos funcionales.
3.3.2. Los actores son el entorno del sistema
3.3.3. Los casos de uso especifican el sistema
3.4. Análisis, diseño e implementación para realizar los casos de uso
3.4.1. Creación del modelo de análisis a partir de los casos de uso
3.4.2. Cada clase debe cumplir todos sus roles de colaboración
3.4.3. Creación del modelo de diseño a partir del modelo de análisis
3.4.4. Los subsistemas agrupan a las clases
3.4.5. Creación del modelo de implementación a partir del modelo de diseño
3.5. Prueba de los casos de uso
3.6. Resumen
3.7. Referencias

Capítulo 4: Un proceso centrado en la arquitectura
4.1. La Arquitectura en pocas palabras
4.2. Por qué es necesaria la arquitectura
4.2.1. Comprensión del sistema
4.2.2. Organización del desarrollo
4.2.3. Fomento de la reutilización
4.2.4. Evolución del sistema
4.3. Casos de uso y arquitectura
4.4. Los pasos hacia una arquitectura
4.4.1. La línea base de la arquitectura es un sistema "pequeño y flaco"
4.4.2. Utilización de patrones arquitectónicos
4.4.3. Descripción de la arquitectura
4.4.4. El arquitecto crea la arquitectura
4.5. Por fin, una descripción de la arquitectura
4.5.1. La vista de la arquitectura del modelo de casos de uso
4.5.2. La vista de la arquitectura del modelo de diseño
4.5.3. La vista de la arquitectura del modelo de despliegue
4.5.4. La vista de la arquitectura del modelo de implementación
4.6. Tres conceptos interesantes
4.6.1. ¿Qué es una arquitectura?
4.6.2. ¿Cómo se obtiene?
4.6.3. ¿Cómo se describe?
4.7. Referencias
Capítulo 5. Un proceso iterativo e incremental
81
5.1. Iterativo e incremental en breve
82
5.1.1. Desarrollo en pequeños pasos
83
5.1.2. Lo que no es una iteración
84
5.2. ¿Por qué un desarrollo iterativo e incremental?
85
5.2.1. Atenuación de riesgos
85
5.2.2. Obtención de una arquitectura robusta
87
5.2.3. Gestión de requisitos cambiantes
87
5.2.4. Permitir cambios tácticos
88
5.2.5. Conseguir una integración continua
88
5.2.6. Conseguir un aprendizaje temprano
90
5.3. La aproximación iterativa es dirigida por los riesgos
90
5.3.1. Las iteraciones alivian los riesgos técnicos
91
5.3.2. La dirección es responsable de los riesgos no técnicos
93
5.3.3. Tratamiento de los riesgos
93
5.4. La iteración genérica
94
5.4.1. Lo que es una iteración
94
5.4.2. Planificación de las iteraciones
96
5.4.3. Secuenciación de las iteraciones
96
5.5. El resultado de una iteración es un incremento
97
5.6. Las iteraciones sobre el ciclo de vida
98
5.7. Los modelos evolucionan con las iteraciones
100
5.8 Las iteraciones desafían a la organización
101
5.9 Referencias
102

■: Los flujos de trabajo fundamentales

Capítulo 6: Captura de requisitos: de la visión a los requisitos
105
6.1. Por qué la captura de requisitos es complicada
106
6.2. El objeto del flujo de trabajo de los requisitos
107
6.3. Visión general de la captura de requisitos
107
6.4. El papel de los requisitos en el ciclo de vida del software
111
VIII CONTENIDO

6.5. La comprensión del contexto del sistema mediante un modelo del dominio.. 112
6.5.1. ¿Qué es un modelo del dominio? 114
6.5.2. Desarrollo de un modelo del dominio 115
6.5.3. Uso del modelo del dominio 115
6.6. La comprensión del contexto del sistema mediante un modelo del negocio. 115
6.6.1. ¿Qué es un modelo del negocio?.. 118
6.6.2. Cómo desarrollar un modelo del negocio 120
6.6.3. Búsqueda de casos de uso a partir de un modelo del negocio 121
6.7. Requisitos adicionales 123
6.8. Resumen 123
6.9. Referencias

Capítulo 7: Captura de requisitos como casos de uso 125
7.1. Introducción 125
7.2. Artefactos 127
7.2.1. Artefacto: modelo de casos de uso 127
7.2.2. Artefacto: actor 128
7.2.3. Caso de uso 129
7.2.4. Artefacto: descripción de la arquitectura (vista del modelo de casos de uso) 132
7.2.5. Artefacto: glosario 133
7.2.6. Artefacto: prototipo de interfaz de usuario 133
7.3. Trabajadores 134
7.3.1. Trabajador: analista del sistema 135
7.3.2. Trabajador: especificador de casos de uso 135
7.3.3. Diseñador de interfaces de usuario 136
7.3.4. Trabajador: arquitecto 136
7.4. Flujo de trabajo 138
7.4.1. Actividad: encontrar actores y casos de uso 146
7.4.2. Actividad: priorizar casos de uso 147
7.4.3. Actividad: detallar un caso de uso 152
7.4.4. Actividad: prototipar la interfaz de usuario 158
7.4.5. Actividad: estructurar el modelo de casos de uso 162
7.5. Resumen del flujo de trabajo de los requisitos 163
7.6. Referencias

Capítulo 8: Análisis 165
8.1. Introducción 162
8.2. El análisis en pocas palabras 16
8.2.1. Por qué el análisis no es diseño ni implementación 16
8.2.2. El objeto del análisis: resumen 16
8.2.3. Ejemplos concretos de cuándo hacer análisis 17
8.3. El papel del análisis en el ciclo de vida del software 1
8.4. Artefactos 1
8.4.1. Artefacto: modelo de análisis 1
8.4.2. Artefacto: clase del análisis 1
8.4.3. Artefacto: realización de caso de uso-análisis 1

CONTENIDO IX
8.4.4. Artefacto: paquete del análisis 181
8.4.5. Artefacto: descripción de la arquitectura (vista del modelo de análisis) 183
8.5. Trabajadores 184
8.5.1. Trabajador: arquitecto 184
8.5.2. Trabajador: ingeniero de casos de uso 185
8.5.3. Trabajador: ingeniero de componentes 186
8.6. Flujo de trabajo 187
8.6.1. Actividad: análisis de la arquitectura 187
8.6.2. Actividad: analizar un caso de uso 194
8.6.3. Actividad: analizar una clase 197
8.6.4. Actividad: analizar un paquete 201
8.7. Resumen del análisis 203
8.8. Referencias 204

Capítulo 9: Diseño 205
9.1. Introducción 205
9.2. El papel del diseño en el ciclo de vida del software 207
9.3. Artefactos 208
9.3.1. Artefacto: modelo de diseño 208
9.3.2. Artefacto: clase del diseño 209
9.3.3. Artefacto: realización de caso de uso-diseño 210
9.3.4. Artefacto: subsistema del diseño 213
9.3.5. Artefacto: interfaz 215
9.3.6. Artefacto: descripción de la arquitectura (vista del modelo de diseño) 216
9.3.7. Artefacto: modelo de despliegue 217
9.3.8. Artefacto: descripción de la arquitectura (vista del modelo de despliegue) 218
9.4. Trabajadores 218
9.4.1. Trabajador: arquitecto 218
9.4.2. Trabajador: ingeniero de casos de uso 219
9.4.3. Trabajador: ingeniero de componentes 220
9.5. Flujo de trabajo 220
9.5.1. Actividad: diseño de la arquitectura 221
9.5.2. Actividad: diseñar un caso de uso 237
9.5.3. Actividad: diseñar una clase 243
9.5.4. Actividad: diseñar un subsistema 250
9.6. Resumen del diseño 251
9.7. Referencias 253

Capítulo 10: Implementación 255
10.1. Introducción 255
10.2. El papel de la implementación en el ciclo de vida del software 256
10.3. Artefactos 257
10.3.1. Artefacto: modelo de implementación 257
10.3.2. Artefacto: componente 257

Este libro, que es un punto de referencia obligada, proporciona una amplia revisión sobre el proceso unificado de desarrollo de software, poniendo especial énfasis en el modelado práctico con UML. El proceso unificado va más allá del mero análisis y diseño orientado a objetos para proporcionar una familia de técnicas que soportan el ciclo completo de desarrollo de software. El resultado es un proceso basado en componentes, dirigido por los casos de uso, centrado en la arquitectura, iterativo e incremental.

El proceso unificado utiliza todas las ventajas del estándar de la industria UML. Este libro demuestra que la notación y el proceso se complementan, utilizando modelos UML para ilustrar los nuevos procesos que intervienen. Los autores describen claramente la semántica y notación de las diferentes construcciones del más alto nivel utilizadas en los modelos. Construcciones como casos de uso, actores, subsistemas, clases, interfaces, clases activas, procesos, hilos, nodos y la mayoría de las relaciones, se describen siempre en el contexto de un modelo. Tanto los profesionales de la tecnología de objetos como los ingenieros de software familiarizados con otros trabajos de los autores, apreciarán El Proceso Unificado de Desarrollo de Software como un medio útil para aprender las mejores prácticas actuales en el desarrollo de software.

Ivar Jacobson, Grady Booch y James Rumbaugh son los diseñadores originales del Lenguaje Unificado de Modelado (UML). Son mundialmente reconocidos por sus significativas contribuciones al desarrollo de la tecnología de objetos, entre los que se encuentra el Proceso Objectory (OOSE), el Método Booch y la Técnica de Modelado de Objetos (OMT). Actualmente los tres trabajan en Rational Software Corporation.