MARC details
| 000 -CABECERA |
|---|
| campo de control de longitud fija |
11330cam a22002174a 4500 |
| 008 - DATOS DE LONGITUD FIJA--INFORMACIÓN GENERAL |
|---|
| campo de control de longitud fija |
251218b mx ||||| |||| 00| 0 spa d |
| 020 ## - INTERNATIONAL STANDARD BOOK NUMBER |
|---|
| International Standard Book Number |
9788478290369 |
| 040 ## - FUENTE DE CATALOGACIÓN |
|---|
| Centro catalogador/agencia de origen |
ITTLALPAN |
| Lengua de catalogación |
spa |
| Centro/agencia transcriptor |
ITTLALPAN |
| Normas de descripción |
rda |
| 041 ## - CÓDIGO DE IDIOMA |
|---|
| Código de lengua del texto/banda sonora o título independiente |
Español |
| Código de lengua original |
Español |
| 050 00 - SIGNATURA TOPOGRÁFICA DE LA BIBLIOTECA DEL CONGRESO |
|---|
| Número de clasificación |
QA7676D47J33518 |
| Cutter |
J33518 |
| Año |
2008 |
| 100 ## - ENTRADA PRINCIPAL--NOMBRE DE PERSONA |
|---|
| Nombre de persona |
IVAR JACOBSON |
| 9 (RLIN) |
3876 |
| Término indicativo de función/relación |
AUTOR |
| 245 00 - MENCIÓN DEL TÍTULO |
|---|
| Título |
EL PROCESO UNIFICADO DE DESARROLLO DE SOFTWARE |
| 250 ## - MENCION DE EDICION |
|---|
| Mención de edición |
PRIMER EDICION |
| 260 3# - PUBLICACIÓN, DISTRIBUCIÓN, ETC. |
|---|
| Lugar de publicación, distribución, etc. |
ESPAÑA |
| Nombre del editor, distribuidor, etc. |
ANDRES OTERO |
| Fecha de publicación, distribución, etc. |
2008 |
| 300 ## - DESCRIPCIÓN FÍSICA |
|---|
| Extensión |
464 PAGINAS |
| Dimensiones |
195X250 |
| 505 ## - NOTA DE CONTENIDO CON FORMATO |
|---|
| Nota de contenido con formato |
Parte 1:<br/>El Proceso Unificado de Desarrollo de Software<br/><br/>Capítulo 1: El Proceso Unificado: dirigido por casos de uso, centrado en la arquitectura, iterativo e incremental.<br/>1.1. El Proceso Unificado en pocas palabras<br/>1.2. El Proceso Unificado está dirigido por casos de uso<br/>1.3. El Proceso Unificado está centrado en la arquitectura<br/>1.4. El Proceso Unificado es iterativo e incremental<br/>1.5. La vida del Proceso Unificado<br/>1.5.1. El producto<br/>1.5.2. Fases dentro de un ciclo<br/>1.6. Un Proceso integrado<br/><br/>Capítulo 2: Las cuatro "P" en el desarrollo de software: Personas, Proyecto, Producto y Proceso.<br/>2.1. Las personas son decisivas<br/>2.1.1. Los procesos de desarrollo afectan a las personas<br/>2.1.2. Los papeles cambiarán<br/>2.1.3. Convirtiendo "recursos" en "trabajadores"<br/>2.2. Los proyectos construyen el producto<br/>2.3. El producto es más que código<br/>2.3.1. ¿Qué es un sistema software?<br/>2.3.2. Artefactos<br/><br/>XV<br/>CONTENIDO<br/>2.3.3. Un sistema posee una colección de modelos<br/>2.3.4. ¿Qué es un modelo?<br/>3.5. Cada modelo es una vista autocontenida del sistema<br/>2.3.6. Dentro de un modelo<br/>2.3.7. Relaciones entre modelos<br/>2.4. El proceso dirige los proyectos<br/>2.4.1. El proceso: una plantilla<br/>2.4.2. Las actividades relacionadas conforman flujos de trabajo<br/>2.4.3. Procesos especializados<br/>2.4.4. Méritos del proceso<br/>2.5. La herramientas son esenciales en el proceso<br/>2.5.1. Las herramientas influyen en el proceso<br/>2.5.2. El proceso dirige las herramientas<br/>2.5.3. El equilibrio entre el proceso y las herramientas<br/>2.5.4. El modelado visual soporta UML<br/>2.5.5. Las herramientas dan soporte al ciclo de vida completo<br/>2.6. Referencias<br/><br/>Capítulo 3: Un proceso dirigido por casos de uso<br/>3.1. Desarrollo dirigido por casos de uso en pocas palabras<br/>3.2. ¿Por qué casos de uso?<br/>3.2.1. Para capturar los requisitos que aportan valor añadido<br/>3.2.2. Para dirigir el proceso<br/>3.3.3. Para idear la arquitectura y más...<br/>3.3. La captura de casos de uso<br/>3.3.1. El modelo de casos de uso representa los requisitos funcionales.<br/>3.3.2. Los actores son el entorno del sistema<br/>3.3.3. Los casos de uso especifican el sistema<br/>3.4. Análisis, diseño e implementación para realizar los casos de uso<br/>3.4.1. Creación del modelo de análisis a partir de los casos de uso<br/>3.4.2. Cada clase debe cumplir todos sus roles de colaboración<br/>3.4.3. Creación del modelo de diseño a partir del modelo de análisis<br/>3.4.4. Los subsistemas agrupan a las clases<br/>3.4.5. Creación del modelo de implementación a partir del modelo de diseño<br/>3.5. Prueba de los casos de uso<br/>3.6. Resumen<br/>3.7. Referencias<br/><br/>Capítulo 4: Un proceso centrado en la arquitectura<br/>4.1. La Arquitectura en pocas palabras<br/>4.2. Por qué es necesaria la arquitectura<br/>4.2.1. Comprensión del sistema<br/>4.2.2. Organización del desarrollo<br/>4.2.3. Fomento de la reutilización<br/>4.2.4. Evolución del sistema<br/>4.3. Casos de uso y arquitectura<br/>4.4. Los pasos hacia una arquitectura<br/>4.4.1. La línea base de la arquitectura es un sistema "pequeño y flaco"<br/>4.4.2. Utilización de patrones arquitectónicos<br/>4.4.3. Descripción de la arquitectura<br/>4.4.4. El arquitecto crea la arquitectura<br/>4.5. Por fin, una descripción de la arquitectura<br/>4.5.1. La vista de la arquitectura del modelo de casos de uso<br/>4.5.2. La vista de la arquitectura del modelo de diseño<br/>4.5.3. La vista de la arquitectura del modelo de despliegue<br/>4.5.4. La vista de la arquitectura del modelo de implementación<br/>4.6. Tres conceptos interesantes<br/>4.6.1. ¿Qué es una arquitectura?<br/>4.6.2. ¿Cómo se obtiene?<br/>4.6.3. ¿Cómo se describe?<br/>4.7. Referencias<br/>Capítulo 5. Un proceso iterativo e incremental<br/>81<br/>5.1. Iterativo e incremental en breve<br/>82<br/>5.1.1. Desarrollo en pequeños pasos<br/>83<br/>5.1.2. Lo que no es una iteración<br/>84<br/>5.2. ¿Por qué un desarrollo iterativo e incremental?<br/>85<br/>5.2.1. Atenuación de riesgos<br/>85<br/>5.2.2. Obtención de una arquitectura robusta<br/>87<br/>5.2.3. Gestión de requisitos cambiantes<br/>87<br/>5.2.4. Permitir cambios tácticos<br/>88<br/>5.2.5. Conseguir una integración continua<br/>88<br/>5.2.6. Conseguir un aprendizaje temprano<br/>90<br/>5.3. La aproximación iterativa es dirigida por los riesgos<br/>90<br/>5.3.1. Las iteraciones alivian los riesgos técnicos<br/>91<br/>5.3.2. La dirección es responsable de los riesgos no técnicos<br/>93<br/>5.3.3. Tratamiento de los riesgos<br/>93<br/>5.4. La iteración genérica<br/>94<br/>5.4.1. Lo que es una iteración<br/>94<br/>5.4.2. Planificación de las iteraciones<br/>96<br/>5.4.3. Secuenciación de las iteraciones<br/>96<br/>5.5. El resultado de una iteración es un incremento<br/>97<br/>5.6. Las iteraciones sobre el ciclo de vida<br/>98<br/>5.7. Los modelos evolucionan con las iteraciones<br/>100<br/>5.8 Las iteraciones desafían a la organización<br/>101<br/>5.9 Referencias<br/>102<br/><br/>■: Los flujos de trabajo fundamentales<br/><br/>Capítulo 6: Captura de requisitos: de la visión a los requisitos<br/>105<br/>6.1. Por qué la captura de requisitos es complicada<br/>106<br/>6.2. El objeto del flujo de trabajo de los requisitos<br/>107<br/>6.3. Visión general de la captura de requisitos<br/>107<br/>6.4. El papel de los requisitos en el ciclo de vida del software<br/>111<br/>VIII CONTENIDO<br/><br/>6.5. La comprensión del contexto del sistema mediante un modelo del dominio.. 112<br/>6.5.1. ¿Qué es un modelo del dominio? 114<br/>6.5.2. Desarrollo de un modelo del dominio 115<br/>6.5.3. Uso del modelo del dominio 115<br/>6.6. La comprensión del contexto del sistema mediante un modelo del negocio. 115<br/>6.6.1. ¿Qué es un modelo del negocio?.. 118<br/>6.6.2. Cómo desarrollar un modelo del negocio 120<br/>6.6.3. Búsqueda de casos de uso a partir de un modelo del negocio 121<br/>6.7. Requisitos adicionales 123<br/>6.8. Resumen 123<br/>6.9. Referencias<br/><br/>Capítulo 7: Captura de requisitos como casos de uso 125<br/>7.1. Introducción 125<br/>7.2. Artefactos 127<br/>7.2.1. Artefacto: modelo de casos de uso 127<br/>7.2.2. Artefacto: actor 128<br/>7.2.3. Caso de uso 129<br/>7.2.4. Artefacto: descripción de la arquitectura (vista del modelo de casos de uso) 132<br/>7.2.5. Artefacto: glosario 133<br/>7.2.6. Artefacto: prototipo de interfaz de usuario 133<br/>7.3. Trabajadores 134<br/>7.3.1. Trabajador: analista del sistema 135<br/>7.3.2. Trabajador: especificador de casos de uso 135<br/>7.3.3. Diseñador de interfaces de usuario 136<br/>7.3.4. Trabajador: arquitecto 136<br/>7.4. Flujo de trabajo 138<br/>7.4.1. Actividad: encontrar actores y casos de uso 146<br/>7.4.2. Actividad: priorizar casos de uso 147<br/>7.4.3. Actividad: detallar un caso de uso 152<br/>7.4.4. Actividad: prototipar la interfaz de usuario 158<br/>7.4.5. Actividad: estructurar el modelo de casos de uso 162<br/>7.5. Resumen del flujo de trabajo de los requisitos 163<br/>7.6. Referencias<br/><br/>Capítulo 8: Análisis 165<br/>8.1. Introducción 162<br/>8.2. El análisis en pocas palabras 16<br/>8.2.1. Por qué el análisis no es diseño ni implementación 16<br/>8.2.2. El objeto del análisis: resumen 16<br/>8.2.3. Ejemplos concretos de cuándo hacer análisis 17<br/>8.3. El papel del análisis en el ciclo de vida del software 1<br/>8.4. Artefactos 1<br/>8.4.1. Artefacto: modelo de análisis 1<br/>8.4.2. Artefacto: clase del análisis 1<br/>8.4.3. Artefacto: realización de caso de uso-análisis 1<br/><br/>CONTENIDO IX<br/>8.4.4. Artefacto: paquete del análisis 181<br/>8.4.5. Artefacto: descripción de la arquitectura (vista del modelo de análisis) 183<br/>8.5. Trabajadores 184<br/>8.5.1. Trabajador: arquitecto 184<br/>8.5.2. Trabajador: ingeniero de casos de uso 185<br/>8.5.3. Trabajador: ingeniero de componentes 186<br/>8.6. Flujo de trabajo 187<br/>8.6.1. Actividad: análisis de la arquitectura 187<br/>8.6.2. Actividad: analizar un caso de uso 194<br/>8.6.3. Actividad: analizar una clase 197<br/>8.6.4. Actividad: analizar un paquete 201<br/>8.7. Resumen del análisis 203<br/>8.8. Referencias 204<br/><br/>Capítulo 9: Diseño 205<br/>9.1. Introducción 205<br/>9.2. El papel del diseño en el ciclo de vida del software 207<br/>9.3. Artefactos 208<br/>9.3.1. Artefacto: modelo de diseño 208<br/>9.3.2. Artefacto: clase del diseño 209<br/>9.3.3. Artefacto: realización de caso de uso-diseño 210<br/>9.3.4. Artefacto: subsistema del diseño 213<br/>9.3.5. Artefacto: interfaz 215<br/>9.3.6. Artefacto: descripción de la arquitectura (vista del modelo de diseño) 216<br/>9.3.7. Artefacto: modelo de despliegue 217<br/>9.3.8. Artefacto: descripción de la arquitectura (vista del modelo de despliegue) 218<br/>9.4. Trabajadores 218<br/>9.4.1. Trabajador: arquitecto 218<br/>9.4.2. Trabajador: ingeniero de casos de uso 219<br/>9.4.3. Trabajador: ingeniero de componentes 220<br/>9.5. Flujo de trabajo 220<br/>9.5.1. Actividad: diseño de la arquitectura 221<br/>9.5.2. Actividad: diseñar un caso de uso 237<br/>9.5.3. Actividad: diseñar una clase 243<br/>9.5.4. Actividad: diseñar un subsistema 250<br/>9.6. Resumen del diseño 251<br/>9.7. Referencias 253<br/><br/>Capítulo 10: Implementación 255<br/>10.1. Introducción 255<br/>10.2. El papel de la implementación en el ciclo de vida del software 256<br/>10.3. Artefactos 257<br/>10.3.1. Artefacto: modelo de implementación 257<br/>10.3.2. Artefacto: componente 257<br/> |
| 520 ## - RESUMEN, ETC. |
|---|
| Resumen, etc. |
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.<br/><br/>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.<br/><br/>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. |
| 700 ## - ENTRADA AGREGADA--NOMBRE PERSONAL |
|---|
| Nombre de persona |
GRADY BOOCH, JAMES RUMBAUGH |
| 9 (RLIN) |
3877 |
| 942 ## - ELEMENTOS DE ENTRADA SECUNDARIOS (KOHA) |
|---|
| Fuente del sistema de clasificación o colocación |
Clasificación LC, Biblioteca del Congreso |
| Tipo de ítem Koha |
Libro |
| Suprimir en OPAC |
No |
| 945 ## - CATALOGADORES |
|---|
| Número del Creador del Registro |
1251 |
| Nombre del Creador del Registro |
Edgar Adrián Morales Avilés |
| Número de último modificador del registro |
1251 |
| Nombre del último modificador del registro |
Edgar Adrián Morales Avilés |
