El proceso unificado de desarrollo de software /
Jacobson, Ivar
El proceso unificado de desarrollo de software / Ivar Jacobson, Grady Booch, James Rumbaugh - Madrid : Pearson Educación, 2000 - xxvi, 438 p. : fig. ; 25 cm - The Addison-Wesley object technology series . - The Addison-Wesley object technology series .
Incluye glosario Incluye índice alfabético
PARTE I: 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
2.3.3. Un sistema posee una colección de modelos
2.3.4 ¿Qué es un modelo?
2.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. Las 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
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?
Capítulo 5. UN PROCESO ITERATIVO E INCREMENTAL
5.1. Iterativo e incremental en breve
5.1.1. Desarrollo en pequeños pasos
5.1.2. Lo que no es una iteración
5.2. ¿Por qué un desarrollo iterativo e incremental?
5.2.1. Atenuación de riesgos
5.2.2. Obtención de una arquitectura robusta
5.2.3. Gestión de requisitos cambiantes
5.2.4. Permitir cambios tácticos
5.2.5. Conseguir una integración continua
5.2.6. Conseguir un aprendizaje temprano
5.3. La aproximación iterativa es dirigida por los riesgos
5.3.1. Las iteraciones alivian los riesgos técnicos
5.3.2. La dirección es responsable de los riesgos no técnicos
5.3.3. Tratamiento de los riesgos
5.4. La iteración genérica
5.4.1. Lo que es una iteración
5.4.2. Planificación de las iteraciones
5.4.3. Secuenciación de las iteraciones
5.5. El resultado de una iteración es un incremento
5.6. Las iteraciones sobre el ciclo de vida
5.7. Los modelos evolucionan con las iteraciones
5.8. Las iteraciones desafían a la organización
PARTE II: LOS FLUJOS DE TRABAJO FUNDAMENTALES
Capítulo 6: CAPTURA DE REQUISITOS: DE LA VISIÓN A LOS REQUISITOS
6.1. Por qué la captura de requisitos es complicada
6.2. El objeto del flujo de trabajo de los requisitos
6.3. Visión general de la captura de requisitos
6.4. El papel de los requisitos en el ciclo de vida del software
6.5. La comprensión del contexto del sistema mediante un modelo del dominio
6.5.1. ¿Qué es un modelo del dominio?
6.5.2. Desarrollo de un modelo del dominio
6.5.3. Uso del modelo del dominio
6.6. La comprensión del contexto del sistema mediante un modelo del negocio
6.6.1. ¿Qué es un modelo del negocio?
6.6.2. Cómo desarrollar un modelo del negocio
6.6.3. Búsqueda de casos de uso a partir de un modelo del negocio
6.7. Requisitos adicionales
Capítulo 7: CAPTURA DE REQUISITOS COMO CASOS DE USO
7.1. Introducción
7.2. Artefactos
7.2.1. Artefacto: modelo de casos de uso
7.2.2. Artefacto: actor
7.2.3. Caso de uso
7.2.4. Artefacto: descripción de la arquitectura (vista del modelo de casos de uso)
7.2.5. Artefacto: glosario
7.2.6. Artefacto: prototipo de interfaz de usuario
7.3. Trabajadores
7.3.1. Trabajador: analista del sistema
7.3.2. Trabajador: especificador de casos de uso
7.3.3. Diseñador de interfaces de usuario
7.3.4. Trabajador: arquitecto
7.4. Flujo de trabajo
7.4.1. Actividad: encontrar actores y casos de uso
7.4.2. Actividad: priorizar casos de uso
7.4.3. Actividad: detallar un caso de uso
7.4.4. Actividad: prototipar la interfaz de usuario
7.4.5. Actividad: estructurar el modelo de casos de uso
7.5. Resumen del flujo de trabajo de los requisitos
Capítulo 8: ANÁLISIS
8.1. Introducción
8.2. El análisis en pocas palabras
8.2.1. Por qué el análisis no es diseño ni implementación
8.2.2. El objeto del análisis: resumen
8.2.3. Ejemplos concretos de cuándo hacer análisis
8.3. El papel del análisis en el ciclo de vida del software
8.4. Artefactos
8.4.1. Artefacto: modelo de análisis
8.4.2. Artefacto: clase del análisis
8.4.3. Artefacto: realización de caso de uso-análisis
8.4.4. Artefacto: paquete del análisis
8.4.5. Artefacto: descripción de la arquitectura (vista del modelo de análisis)
8.5. Trabajadores
8.5.1. Trabajador: arquitecto
8.5.2. Trabajador: ingeniero de casos de uso
8.5.3. Trabajador: ingeniero de componentes
8.6. Flujo de trabajo
8.6.1. Actividad: análisis de la arquitectura
8.6.2. Actividad: analizar un caso de uso
8.6.3. Actividad: analizar una clase
8.6.4. Actividad: analizar un paquete
8.7. Resumen del análisis
Capítulo 9: DISEÑO
9.1. Introducción
9.2. El papel del diseño en el ciclo de vida del software
9.3. Artefactos
9.3.1. Artefacto: modelo de diseño
9.3.2. Artefacto: clase del diseño
9.3.3. Artefacto: realización de caso de uso-diseño
9.3.4. Artefacto: subsistema del diseño
9.3.5. Artefacto: interfaz
9.3.6. Artefacto: descripción de la arquitectura (vista del modelo de diseño)
9.3.7. Artefacto: modelo de despliegue
9.3.8. Artefacto: descripción de la arquitectura (vista del modelo de despliegue)
9.4. Trabajadores
9.4.1. Trabajador: arquitecto
9.4.2. Trabajador: ingeniero de casos de uso
9.4.3. Trabajador: ingeniero de componentes
9.5. Flujo de trabajo
9.5.1. Actividad: diseño de la arquitectura
9.5.2. Actividad: diseñar un caso de uso
9.5.3. Actividad: diseñar una clase
9.5.4. Actividad: diseñar un subsistema
9.6. Resumen del diseño
Capítulo 10: IMPLEMENTACIÓN
10.1. Introducción
10.2. El papel de la implementación en el ciclo de vida del software
10.3. Artefactos
10.3.1. Artefacto: modelo de implementación
10.3.2. Artefacto: componente
10.3.3. Artefacto: subsistema de la implementación
10.3.4. Artefacto: interfaz
10.3.5. Artefacto: descripción de la arquitectura (vista del modelo de implementación)
10.3.6. Artefacto: plan de integración de construcciones
10.4. Trabajadores
10.4.1. Trabajador: arquitecto
10.4.2. Trabajador: ingeniero de componentes
10.4.3. Trabajador: integrador de sistemas
10.5. Flujo de trabajo
10.5.1. Actividad: implementación de la arquitectura
10.5.2. Actividad: integrar el sistema
10.5.3. Actividad: implementar un subsistema
10.5.4. Actividad: implementar una clase
10.5.5. Actividad: realizar prueba unidad
10.6. Resumen de la implementación
Capítulo 11: PRUEBA
11.1. Introducción
11.2. El papel de la prueba en el ciclo de vida del software
11.3. Artefactos
11.3.1. Artefacto: modelo de pruebas
11.3.2. Artefacto: caso de prueba
11.3.3. Artefacto: procedimiento de prueba
11.3.4. Artefacto: componente de prueba
11.3.5. Artefacto: plan de prueba
11.3.6. Artefacto: defecto
11.3.7. Artefacto: evaluación de prueba
11.4. Trabajadores
11.4.1. Trabajador: diseñador de pruebas
11.4.2. Trabajador: ingeniero de componentes
11.4.3. Trabajador: ingeniero de pruebas de integración
11.4.4. Trabajador: ingeniero de pruebas del sistema
11.5. Flujo de trabajo
11.5.1. Actividad: planificar prueba
11.5.2. Actividad: diseñar prueba
11.5.3. Actividad: implementar prueba
11.5.4. Actividad: realizar pruebas de integración
11.5.5. Actividad: realizar prueba de sistema
11.5.6. Actividad: evaluar prueba
11.6. Resumen de la prueba
PARTE III: EL DESARROLLO ITERATIVO E INCREMENTAL
Capítulo 12: EL FLUJO DE TRABAJO DE ITERACIÓN GENÉRICO
12.1. La necesidad de equilibrio
12.2. Las fases son la primera división del trabajo
12.2.1. La fase de inicio establece la viabilidad
12.2.2. La fase de elaboración se centra en la factibilidad
12.2.3. La fase de construcción construye el sistema
12.2.4. La fase de transición se mete dentro del entorno del usuario
12.3. La iteración genérica
12.3.1. Los flujos de trabajo fundamentales se repiten en cada iteración
12.3.2. Los trabajadores participan en los flujos de trabajo
12.4. El planificar precede al hacer
12.4.1. Planear las cuatro fases
12.4.2. Plan de iteraciones
12.4.3. Pensar a largo plazo
12.4.4. Planear los criterios de evaluación
12.5. Los riesgos influyen en la planificación del proyecto
12.5.1. Administrar la lista de riesgos
12.5.2. Los riesgos influyen en el plan de iteración
12.5.3. Planificar la acción sobre los riesgos
12.6. Asignación de prioridades a los casos de uso
12.6.1. Riesgos específicos de un producto particular
12.6.2. Riesgo de no conseguir la arquitectura correcta
12.6.3. Riesgo de no conseguir los requisitos correctos
12.7. Recursos necesitados
12.7.1. Los proyectos difieren enormemente
12.7.2. Un proyecto típico tiene este aspecto
12.7.3. Los proyectos más grandes tienen mayores necesidades
12.7.4. Una nueva línea de productos requiere experiencia
12.7.5. El pago del coste de los recursos utilizados
12.8. Evaluar las iteraciones y las fases
12.8.1. Criterios no alcanzados
12.8.2. Los criterios mismos
12.8.3. La siguiente iteración
12.8.4. Evolución del conjunto de modelos
Capítulo 13: LA FASE DE INICIO PONE EN MARCHA EL PROYECTO
13.1. La fase de inicio en pocas palabras
13.2. Al comienzo de la fase de inicio
13.2.1. Antes de comenzar la fase de inicio
13.2.2. Planificación de la fase de inicio
13.2.3. Ampliación de la descripción del sistema
13.2.4. Establecimiento de los criterios de evaluación
13.3. Flujo de trabajo arquetípico de una iteración en la fase de inicio
13.3.1. Introducción a los cinco flujos de trabajo fundamentales
13.3.2. Ajuste del proyecto al entorno de desarrollo
13.3.3. Identificación de los riesgos críticos
13.4. Ejecución de los flujos de trabajo fundamentales, de requisitos a pruebas
13.4.1. Recopilación de requisitos
13.4.2. Análisis
13.4.3. Diseño
13.4.4. Implementación
13.4.5. Pruebas
13.5. Realización del análisis inicial de negocio
13.5.1. Esbozar la apuesta económica
13.5.2. Estimar la recuperación de la inversión
13.6. Evaluación de la iteración o iteraciones de la fase de inicio
13.7. Planificación de la fase de elaboración
13.8. Productos de la fase de inicio
Capítulo 14: LA FASE DE ELABORACIÓN CONSTRUYE LA LÍNEA BASE DE LA ARQUITECTURA
14.1. La fase de elaboración en pocas palabras
14.2. Al comienzo de la fase de elaboración
14.2.1. Planificación de la fase de elaboración
14.2.2. Formación del equipo
14.2.3. Modificación del entorno de desarrollo
14.2.4. Establecimiento de criterios de evaluación
14.3. Flujo de trabajo arquetípico de una iteración en la fase de elaboración
14.3.1. Recopilación y refinamiento de la mayor parte de los requisitos
14.3.2. Desarrollo de la línea base de la arquitectura
14.3.3. Iterando mientras el equipo es pequeño
14.4. Ejecución de los flujos de trabajo fundamentales, de requisitos a pruebas
14.4.1. Recopilar los requisitos
14.4.2. Análisis
14.4.3. Diseño
14.4.4. Implementación
14.4.5. Pruebas
14.5. Desarrollo del análisis del negocio
14.5.1. Preparar la apuesta económica
14.5.2. Actualizar la recuperación de la inversión
14.6. Evaluación de las iteraciones de la fase de elaboración
14.7. Planificación de la fase de construcción
14.8. Productos clave
Capítulo 15: LA CONSTRUCCIÓN LLEVA A LA CAPACIDAD OPERACIÓN INICIAL
15.1. La fase de construcción en pocas palabras
15.2. Al comienzo de la fase de construcción
15.2.1. Asignación de personal para la fase
15.2.2. Establecimiento de los criterios de evaluación
15.3. Flujo de trabajo arquetípico de una iteración en la fase de construcción
15.4. Ejecución de los flujos de trabajo fundamentales, de requisitos a pruebas
15.4.1. Requisitos
15.4.2. Análisis
15.4.3. Diseño
15.4.4. Implementación
15.4.5. Pruebas
15.5. Control del análisis de negocio
15.6. Evaluación de las iteraciones y de la fase de construcción
15.7. Planificación de la fase de transición
15.8. Productos clave
Capítulo 16: LA TRANSICIÓN COMPLETA LA VERSIÓN DEL PRODUCTO
16.1. La fase de transición en pocas palabras
16.2. Al comienzo de la fase de transición
16.2.1. Planificación de la fase de transición
16.2.2. Asignación de personal para la fase
16.2.3. Establecimiento de los criterios de evaluación
16.3. Los flujos de trabajo fundamentales desempeñan un papel pequeño en esta fase
16.4. Lo que se hace en la fase de transición
16.4.1. Preparación de la versión beta
16.4.2. Instalación de la versión beta
16.4.3. Reacción a los resultados de las pruebas
16.4.4. Adaptación del producto a entornos de usuario variados
16.4.5. Finalización de los artefactos
16.4.6. ¿Cuándo acaba el proyecto?
16.5. Finalización del análisis del negocio
16.5.1. Control del progreso
16.5.2. Revisión del plan del negocio
16.6. Evaluación de la fase de transición
16.6.1. Evaluación de las iteraciones y de la fase
16.6.2. Autopsia del proyecto
16.7. Planificación de la próxima versión o generación
16.8. Productos clave
Capítulo 17: CÓMO HACER QUE EL PROCESO UNIFICADO FUNCIONE
17.1. El Proceso Unificado ayuda a manejar la complejidad
17.1.1. Los objetivos del ciclo de vida
17.1.2. La arquitectura del ciclo de vida
17.1.3. Capacidad operativa inicial
17.1.4. Lanzamiento del producto
17.2. Los temas importantes
17.3. La dirección lidera la conversión al Proceso Unificado
17.3.1. La necesidad de actuar
17.3.2. La directriz de reingeniería
17.3.3. Implementación de la transición
17.4. Especialización del Proceso Unificado
17.4.1. Adaptación del proceso
17.4.2. Completando el marco de trabajo del proceso
17.5. Relación con comunidades más amplias
17.6. Obtenga los beneficios del Proceso Unificado
APÉNDICE A: Visión general del UML
A.1. Introducción
A.1.1. Vocabulario
A.1.2. Mecanismos de extensibilidad
A.2. Notación gráfica
A.2.1. Cosas estructurales
A.2.2. Elementos de comportamiento
A.2.3. Elementos de agrupación
A.2.A. Elementos de anotación
A.2.5. Relaciones de dependencia
A.2.6. Relaciones de asociación
A.2.7. Relaciones de generalización
A.2.8. Mecanismos de extensibilidad
A.3. Glosario de términos
APÉNDICE B: Extensiones del UML específicas del Proceso Unificado
B.1. Introducción
B.2. Estereotipos
B.3. Valores etiquetados
B.A. Notación gráfica
B.5. Referencias
Apéndice C: Glosario general
C.1. Introducción
C.2. Términos
8478290362
SOPORTE LOGICO DE COMPUTADORES
LENGUAJES DE PROGRAMACION
681.3.06
El proceso unificado de desarrollo de software / Ivar Jacobson, Grady Booch, James Rumbaugh - Madrid : Pearson Educación, 2000 - xxvi, 438 p. : fig. ; 25 cm - The Addison-Wesley object technology series . - The Addison-Wesley object technology series .
Incluye glosario Incluye índice alfabético
PARTE I: 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
2.3.3. Un sistema posee una colección de modelos
2.3.4 ¿Qué es un modelo?
2.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. Las 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
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?
Capítulo 5. UN PROCESO ITERATIVO E INCREMENTAL
5.1. Iterativo e incremental en breve
5.1.1. Desarrollo en pequeños pasos
5.1.2. Lo que no es una iteración
5.2. ¿Por qué un desarrollo iterativo e incremental?
5.2.1. Atenuación de riesgos
5.2.2. Obtención de una arquitectura robusta
5.2.3. Gestión de requisitos cambiantes
5.2.4. Permitir cambios tácticos
5.2.5. Conseguir una integración continua
5.2.6. Conseguir un aprendizaje temprano
5.3. La aproximación iterativa es dirigida por los riesgos
5.3.1. Las iteraciones alivian los riesgos técnicos
5.3.2. La dirección es responsable de los riesgos no técnicos
5.3.3. Tratamiento de los riesgos
5.4. La iteración genérica
5.4.1. Lo que es una iteración
5.4.2. Planificación de las iteraciones
5.4.3. Secuenciación de las iteraciones
5.5. El resultado de una iteración es un incremento
5.6. Las iteraciones sobre el ciclo de vida
5.7. Los modelos evolucionan con las iteraciones
5.8. Las iteraciones desafían a la organización
PARTE II: LOS FLUJOS DE TRABAJO FUNDAMENTALES
Capítulo 6: CAPTURA DE REQUISITOS: DE LA VISIÓN A LOS REQUISITOS
6.1. Por qué la captura de requisitos es complicada
6.2. El objeto del flujo de trabajo de los requisitos
6.3. Visión general de la captura de requisitos
6.4. El papel de los requisitos en el ciclo de vida del software
6.5. La comprensión del contexto del sistema mediante un modelo del dominio
6.5.1. ¿Qué es un modelo del dominio?
6.5.2. Desarrollo de un modelo del dominio
6.5.3. Uso del modelo del dominio
6.6. La comprensión del contexto del sistema mediante un modelo del negocio
6.6.1. ¿Qué es un modelo del negocio?
6.6.2. Cómo desarrollar un modelo del negocio
6.6.3. Búsqueda de casos de uso a partir de un modelo del negocio
6.7. Requisitos adicionales
Capítulo 7: CAPTURA DE REQUISITOS COMO CASOS DE USO
7.1. Introducción
7.2. Artefactos
7.2.1. Artefacto: modelo de casos de uso
7.2.2. Artefacto: actor
7.2.3. Caso de uso
7.2.4. Artefacto: descripción de la arquitectura (vista del modelo de casos de uso)
7.2.5. Artefacto: glosario
7.2.6. Artefacto: prototipo de interfaz de usuario
7.3. Trabajadores
7.3.1. Trabajador: analista del sistema
7.3.2. Trabajador: especificador de casos de uso
7.3.3. Diseñador de interfaces de usuario
7.3.4. Trabajador: arquitecto
7.4. Flujo de trabajo
7.4.1. Actividad: encontrar actores y casos de uso
7.4.2. Actividad: priorizar casos de uso
7.4.3. Actividad: detallar un caso de uso
7.4.4. Actividad: prototipar la interfaz de usuario
7.4.5. Actividad: estructurar el modelo de casos de uso
7.5. Resumen del flujo de trabajo de los requisitos
Capítulo 8: ANÁLISIS
8.1. Introducción
8.2. El análisis en pocas palabras
8.2.1. Por qué el análisis no es diseño ni implementación
8.2.2. El objeto del análisis: resumen
8.2.3. Ejemplos concretos de cuándo hacer análisis
8.3. El papel del análisis en el ciclo de vida del software
8.4. Artefactos
8.4.1. Artefacto: modelo de análisis
8.4.2. Artefacto: clase del análisis
8.4.3. Artefacto: realización de caso de uso-análisis
8.4.4. Artefacto: paquete del análisis
8.4.5. Artefacto: descripción de la arquitectura (vista del modelo de análisis)
8.5. Trabajadores
8.5.1. Trabajador: arquitecto
8.5.2. Trabajador: ingeniero de casos de uso
8.5.3. Trabajador: ingeniero de componentes
8.6. Flujo de trabajo
8.6.1. Actividad: análisis de la arquitectura
8.6.2. Actividad: analizar un caso de uso
8.6.3. Actividad: analizar una clase
8.6.4. Actividad: analizar un paquete
8.7. Resumen del análisis
Capítulo 9: DISEÑO
9.1. Introducción
9.2. El papel del diseño en el ciclo de vida del software
9.3. Artefactos
9.3.1. Artefacto: modelo de diseño
9.3.2. Artefacto: clase del diseño
9.3.3. Artefacto: realización de caso de uso-diseño
9.3.4. Artefacto: subsistema del diseño
9.3.5. Artefacto: interfaz
9.3.6. Artefacto: descripción de la arquitectura (vista del modelo de diseño)
9.3.7. Artefacto: modelo de despliegue
9.3.8. Artefacto: descripción de la arquitectura (vista del modelo de despliegue)
9.4. Trabajadores
9.4.1. Trabajador: arquitecto
9.4.2. Trabajador: ingeniero de casos de uso
9.4.3. Trabajador: ingeniero de componentes
9.5. Flujo de trabajo
9.5.1. Actividad: diseño de la arquitectura
9.5.2. Actividad: diseñar un caso de uso
9.5.3. Actividad: diseñar una clase
9.5.4. Actividad: diseñar un subsistema
9.6. Resumen del diseño
Capítulo 10: IMPLEMENTACIÓN
10.1. Introducción
10.2. El papel de la implementación en el ciclo de vida del software
10.3. Artefactos
10.3.1. Artefacto: modelo de implementación
10.3.2. Artefacto: componente
10.3.3. Artefacto: subsistema de la implementación
10.3.4. Artefacto: interfaz
10.3.5. Artefacto: descripción de la arquitectura (vista del modelo de implementación)
10.3.6. Artefacto: plan de integración de construcciones
10.4. Trabajadores
10.4.1. Trabajador: arquitecto
10.4.2. Trabajador: ingeniero de componentes
10.4.3. Trabajador: integrador de sistemas
10.5. Flujo de trabajo
10.5.1. Actividad: implementación de la arquitectura
10.5.2. Actividad: integrar el sistema
10.5.3. Actividad: implementar un subsistema
10.5.4. Actividad: implementar una clase
10.5.5. Actividad: realizar prueba unidad
10.6. Resumen de la implementación
Capítulo 11: PRUEBA
11.1. Introducción
11.2. El papel de la prueba en el ciclo de vida del software
11.3. Artefactos
11.3.1. Artefacto: modelo de pruebas
11.3.2. Artefacto: caso de prueba
11.3.3. Artefacto: procedimiento de prueba
11.3.4. Artefacto: componente de prueba
11.3.5. Artefacto: plan de prueba
11.3.6. Artefacto: defecto
11.3.7. Artefacto: evaluación de prueba
11.4. Trabajadores
11.4.1. Trabajador: diseñador de pruebas
11.4.2. Trabajador: ingeniero de componentes
11.4.3. Trabajador: ingeniero de pruebas de integración
11.4.4. Trabajador: ingeniero de pruebas del sistema
11.5. Flujo de trabajo
11.5.1. Actividad: planificar prueba
11.5.2. Actividad: diseñar prueba
11.5.3. Actividad: implementar prueba
11.5.4. Actividad: realizar pruebas de integración
11.5.5. Actividad: realizar prueba de sistema
11.5.6. Actividad: evaluar prueba
11.6. Resumen de la prueba
PARTE III: EL DESARROLLO ITERATIVO E INCREMENTAL
Capítulo 12: EL FLUJO DE TRABAJO DE ITERACIÓN GENÉRICO
12.1. La necesidad de equilibrio
12.2. Las fases son la primera división del trabajo
12.2.1. La fase de inicio establece la viabilidad
12.2.2. La fase de elaboración se centra en la factibilidad
12.2.3. La fase de construcción construye el sistema
12.2.4. La fase de transición se mete dentro del entorno del usuario
12.3. La iteración genérica
12.3.1. Los flujos de trabajo fundamentales se repiten en cada iteración
12.3.2. Los trabajadores participan en los flujos de trabajo
12.4. El planificar precede al hacer
12.4.1. Planear las cuatro fases
12.4.2. Plan de iteraciones
12.4.3. Pensar a largo plazo
12.4.4. Planear los criterios de evaluación
12.5. Los riesgos influyen en la planificación del proyecto
12.5.1. Administrar la lista de riesgos
12.5.2. Los riesgos influyen en el plan de iteración
12.5.3. Planificar la acción sobre los riesgos
12.6. Asignación de prioridades a los casos de uso
12.6.1. Riesgos específicos de un producto particular
12.6.2. Riesgo de no conseguir la arquitectura correcta
12.6.3. Riesgo de no conseguir los requisitos correctos
12.7. Recursos necesitados
12.7.1. Los proyectos difieren enormemente
12.7.2. Un proyecto típico tiene este aspecto
12.7.3. Los proyectos más grandes tienen mayores necesidades
12.7.4. Una nueva línea de productos requiere experiencia
12.7.5. El pago del coste de los recursos utilizados
12.8. Evaluar las iteraciones y las fases
12.8.1. Criterios no alcanzados
12.8.2. Los criterios mismos
12.8.3. La siguiente iteración
12.8.4. Evolución del conjunto de modelos
Capítulo 13: LA FASE DE INICIO PONE EN MARCHA EL PROYECTO
13.1. La fase de inicio en pocas palabras
13.2. Al comienzo de la fase de inicio
13.2.1. Antes de comenzar la fase de inicio
13.2.2. Planificación de la fase de inicio
13.2.3. Ampliación de la descripción del sistema
13.2.4. Establecimiento de los criterios de evaluación
13.3. Flujo de trabajo arquetípico de una iteración en la fase de inicio
13.3.1. Introducción a los cinco flujos de trabajo fundamentales
13.3.2. Ajuste del proyecto al entorno de desarrollo
13.3.3. Identificación de los riesgos críticos
13.4. Ejecución de los flujos de trabajo fundamentales, de requisitos a pruebas
13.4.1. Recopilación de requisitos
13.4.2. Análisis
13.4.3. Diseño
13.4.4. Implementación
13.4.5. Pruebas
13.5. Realización del análisis inicial de negocio
13.5.1. Esbozar la apuesta económica
13.5.2. Estimar la recuperación de la inversión
13.6. Evaluación de la iteración o iteraciones de la fase de inicio
13.7. Planificación de la fase de elaboración
13.8. Productos de la fase de inicio
Capítulo 14: LA FASE DE ELABORACIÓN CONSTRUYE LA LÍNEA BASE DE LA ARQUITECTURA
14.1. La fase de elaboración en pocas palabras
14.2. Al comienzo de la fase de elaboración
14.2.1. Planificación de la fase de elaboración
14.2.2. Formación del equipo
14.2.3. Modificación del entorno de desarrollo
14.2.4. Establecimiento de criterios de evaluación
14.3. Flujo de trabajo arquetípico de una iteración en la fase de elaboración
14.3.1. Recopilación y refinamiento de la mayor parte de los requisitos
14.3.2. Desarrollo de la línea base de la arquitectura
14.3.3. Iterando mientras el equipo es pequeño
14.4. Ejecución de los flujos de trabajo fundamentales, de requisitos a pruebas
14.4.1. Recopilar los requisitos
14.4.2. Análisis
14.4.3. Diseño
14.4.4. Implementación
14.4.5. Pruebas
14.5. Desarrollo del análisis del negocio
14.5.1. Preparar la apuesta económica
14.5.2. Actualizar la recuperación de la inversión
14.6. Evaluación de las iteraciones de la fase de elaboración
14.7. Planificación de la fase de construcción
14.8. Productos clave
Capítulo 15: LA CONSTRUCCIÓN LLEVA A LA CAPACIDAD OPERACIÓN INICIAL
15.1. La fase de construcción en pocas palabras
15.2. Al comienzo de la fase de construcción
15.2.1. Asignación de personal para la fase
15.2.2. Establecimiento de los criterios de evaluación
15.3. Flujo de trabajo arquetípico de una iteración en la fase de construcción
15.4. Ejecución de los flujos de trabajo fundamentales, de requisitos a pruebas
15.4.1. Requisitos
15.4.2. Análisis
15.4.3. Diseño
15.4.4. Implementación
15.4.5. Pruebas
15.5. Control del análisis de negocio
15.6. Evaluación de las iteraciones y de la fase de construcción
15.7. Planificación de la fase de transición
15.8. Productos clave
Capítulo 16: LA TRANSICIÓN COMPLETA LA VERSIÓN DEL PRODUCTO
16.1. La fase de transición en pocas palabras
16.2. Al comienzo de la fase de transición
16.2.1. Planificación de la fase de transición
16.2.2. Asignación de personal para la fase
16.2.3. Establecimiento de los criterios de evaluación
16.3. Los flujos de trabajo fundamentales desempeñan un papel pequeño en esta fase
16.4. Lo que se hace en la fase de transición
16.4.1. Preparación de la versión beta
16.4.2. Instalación de la versión beta
16.4.3. Reacción a los resultados de las pruebas
16.4.4. Adaptación del producto a entornos de usuario variados
16.4.5. Finalización de los artefactos
16.4.6. ¿Cuándo acaba el proyecto?
16.5. Finalización del análisis del negocio
16.5.1. Control del progreso
16.5.2. Revisión del plan del negocio
16.6. Evaluación de la fase de transición
16.6.1. Evaluación de las iteraciones y de la fase
16.6.2. Autopsia del proyecto
16.7. Planificación de la próxima versión o generación
16.8. Productos clave
Capítulo 17: CÓMO HACER QUE EL PROCESO UNIFICADO FUNCIONE
17.1. El Proceso Unificado ayuda a manejar la complejidad
17.1.1. Los objetivos del ciclo de vida
17.1.2. La arquitectura del ciclo de vida
17.1.3. Capacidad operativa inicial
17.1.4. Lanzamiento del producto
17.2. Los temas importantes
17.3. La dirección lidera la conversión al Proceso Unificado
17.3.1. La necesidad de actuar
17.3.2. La directriz de reingeniería
17.3.3. Implementación de la transición
17.4. Especialización del Proceso Unificado
17.4.1. Adaptación del proceso
17.4.2. Completando el marco de trabajo del proceso
17.5. Relación con comunidades más amplias
17.6. Obtenga los beneficios del Proceso Unificado
APÉNDICE A: Visión general del UML
A.1. Introducción
A.1.1. Vocabulario
A.1.2. Mecanismos de extensibilidad
A.2. Notación gráfica
A.2.1. Cosas estructurales
A.2.2. Elementos de comportamiento
A.2.3. Elementos de agrupación
A.2.A. Elementos de anotación
A.2.5. Relaciones de dependencia
A.2.6. Relaciones de asociación
A.2.7. Relaciones de generalización
A.2.8. Mecanismos de extensibilidad
A.3. Glosario de términos
APÉNDICE B: Extensiones del UML específicas del Proceso Unificado
B.1. Introducción
B.2. Estereotipos
B.3. Valores etiquetados
B.A. Notación gráfica
B.5. Referencias
Apéndice C: Glosario general
C.1. Introducción
C.2. Términos
8478290362
SOPORTE LOGICO DE COMPUTADORES
LENGUAJES DE PROGRAMACION
681.3.06