El proceso unificado de desarrollo de software / (Registro nro. 1362)

Detalles MARC
000 -CABECERA
Campo de control de longitud fija 17958nam a2200349 i 4500
001 - NÚMERO DE CONTROL
Número de control 1362
003 - IDENTIFICADOR DEL NÚMERO DE CONTROL
Identificador del número de control AR-RqUTN
008 - DATOS DE LONGITUD FIJA--INFORMACIÓN GENERAL
Códigos de información de longitud fija 241028s2000 d||||r|||| 001 0 spa d
020 ## - NÚMERO INTERNACIONAL ESTÁNDAR DEL LIBRO
ISBN 8478290362
040 ## - FUENTE DE LA CATALOGACIÓN
Centro catalogador de origen AR-RqUTN
Lengua de catalogación spa
Centro transcriptor AR-RqUTN
041 #7 - CÓDIGO DE LENGUA
Código de lengua del texto es
Fuente del código ISO 639-1
080 0# - NÚMERO DE LA CLASIFICACIÓN DECIMAL UNIVERSAL
Clasificación Decimal Universal 681.3.06
Edición de la CDU 1991
100 1# - ENTRADA PRINCIPAL--NOMBRE DE PERSONA
Nombre personal Jacobson, Ivar
245 13 - MENCIÓN DE TÍTULO
Título El proceso unificado de desarrollo de software /
Mención de responsabilidad Ivar Jacobson, Grady Booch, James Rumbaugh
260 ## - PUBLICACIÓN, DISTRIBUCIÓN, ETC.
Lugar de publicación, distribución, etc. Madrid :
Nombre del editor, distribuidor, etc. Pearson Educación,
Fecha de publicación, distribución, etc. 2000
300 ## - DESCRIPCIÓN FÍSICA
Extensión xxvi, 438 p. :
Otras características físicas fig. ;
Dimensiones 25 cm
336 ## - TIPO DE CONTENIDO
Fuente rdacontent
Término de tipo de contenido texto
Código de tipo de contenido txt
337 ## - TIPO DE MEDIO
Fuente rdamedia
Nombre del tipo de medio sin mediación
Código del tipo de medio n
338 ## - TIPO DE SOPORTE
Fuente rdacarrier
Nombre del tipo de soporte volumen
Código del tipo de soporte nc
490 1# - MENCIÓN DE SERIE
Mención de serie The Addison-Wesley object technology series
500 ## - NOTA GENERAL
Nota general Incluye glosario
500 ## - NOTA GENERAL
Nota general Incluye índice alfabético
505 00 - NOTA DE CONTENIDO CON FORMATO
Nota de contenido con formato PARTE I: EL PROCESO UNIFICADO DE DESARROLLO DE SOFTWARE<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/>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/>2.3.3. Un sistema posee una colección de modelos<br/>2.3.4 ¿Qué es un modelo?<br/>2.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. Las 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/>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/>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/>Capítulo 5. UN PROCESO ITERATIVO E INCREMENTAL<br/>5.1. Iterativo e incremental en breve<br/>5.1.1. Desarrollo en pequeños pasos<br/>5.1.2. Lo que no es una iteración<br/>5.2. ¿Por qué un desarrollo iterativo e incremental?<br/>5.2.1. Atenuación de riesgos<br/>5.2.2. Obtención de una arquitectura robusta<br/>5.2.3. Gestión de requisitos cambiantes<br/>5.2.4. Permitir cambios tácticos<br/>5.2.5. Conseguir una integración continua<br/>5.2.6. Conseguir un aprendizaje temprano<br/>5.3. La aproximación iterativa es dirigida por los riesgos<br/>5.3.1. Las iteraciones alivian los riesgos técnicos<br/>5.3.2. La dirección es responsable de los riesgos no técnicos<br/>5.3.3. Tratamiento de los riesgos<br/>5.4. La iteración genérica<br/>5.4.1. Lo que es una iteración<br/>5.4.2. Planificación de las iteraciones<br/>5.4.3. Secuenciación de las iteraciones<br/>5.5. El resultado de una iteración es un incremento<br/>5.6. Las iteraciones sobre el ciclo de vida<br/>5.7. Los modelos evolucionan con las iteraciones<br/>5.8. Las iteraciones desafían a la organización<br/>PARTE II: LOS FLUJOS DE TRABAJO FUNDAMENTALES<br/>Capítulo 6: CAPTURA DE REQUISITOS: DE LA VISIÓN A LOS REQUISITOS<br/>6.1. Por qué la captura de requisitos es complicada<br/>6.2. El objeto del flujo de trabajo de los requisitos<br/>6.3. Visión general de la captura de requisitos<br/>6.4. El papel de los requisitos en el ciclo de vida del software<br/>6.5. La comprensión del contexto del sistema mediante un modelo del dominio<br/>6.5.1. ¿Qué es un modelo del dominio?<br/>6.5.2. Desarrollo de un modelo del dominio<br/>6.5.3. Uso del modelo del dominio<br/>6.6. La comprensión del contexto del sistema mediante un modelo del negocio<br/>6.6.1. ¿Qué es un modelo del negocio?<br/>6.6.2. Cómo desarrollar un modelo del negocio<br/>6.6.3. Búsqueda de casos de uso a partir de un modelo del negocio<br/>6.7. Requisitos adicionales<br/>Capítulo 7: CAPTURA DE REQUISITOS COMO CASOS DE USO<br/>7.1. Introducción<br/>7.2. Artefactos<br/>7.2.1. Artefacto: modelo de casos de uso<br/>7.2.2. Artefacto: actor<br/>7.2.3. Caso de uso<br/>7.2.4. Artefacto: descripción de la arquitectura (vista del modelo de casos de uso)<br/>7.2.5. Artefacto: glosario<br/>7.2.6. Artefacto: prototipo de interfaz de usuario<br/>7.3. Trabajadores<br/>7.3.1. Trabajador: analista del sistema<br/>7.3.2. Trabajador: especificador de casos de uso<br/>7.3.3. Diseñador de interfaces de usuario<br/>7.3.4. Trabajador: arquitecto<br/>7.4. Flujo de trabajo<br/>7.4.1. Actividad: encontrar actores y casos de uso<br/>7.4.2. Actividad: priorizar casos de uso<br/>7.4.3. Actividad: detallar un caso de uso<br/>7.4.4. Actividad: prototipar la interfaz de usuario<br/>7.4.5. Actividad: estructurar el modelo de casos de uso<br/>7.5. Resumen del flujo de trabajo de los requisitos<br/>Capítulo 8: ANÁLISIS<br/>8.1. Introducción<br/>8.2. El análisis en pocas palabras<br/>8.2.1. Por qué el análisis no es diseño ni implementación<br/>8.2.2. El objeto del análisis: resumen<br/>8.2.3. Ejemplos concretos de cuándo hacer análisis<br/>8.3. El papel del análisis en el ciclo de vida del software<br/>8.4. Artefactos<br/>8.4.1. Artefacto: modelo de análisis<br/>8.4.2. Artefacto: clase del análisis<br/>8.4.3. Artefacto: realización de caso de uso-análisis<br/>8.4.4. Artefacto: paquete del análisis<br/>8.4.5. Artefacto: descripción de la arquitectura (vista del modelo de análisis)<br/>8.5. Trabajadores<br/>8.5.1. Trabajador: arquitecto<br/>8.5.2. Trabajador: ingeniero de casos de uso<br/>8.5.3. Trabajador: ingeniero de componentes<br/>8.6. Flujo de trabajo<br/>8.6.1. Actividad: análisis de la arquitectura<br/>8.6.2. Actividad: analizar un caso de uso<br/>8.6.3. Actividad: analizar una clase<br/>8.6.4. Actividad: analizar un paquete<br/>8.7. Resumen del análisis<br/>Capítulo 9: DISEÑO<br/>9.1. Introducción<br/>9.2. El papel del diseño en el ciclo de vida del software<br/>9.3. Artefactos<br/>9.3.1. Artefacto: modelo de diseño<br/>9.3.2. Artefacto: clase del diseño<br/>9.3.3. Artefacto: realización de caso de uso-diseño<br/>9.3.4. Artefacto: subsistema del diseño<br/>9.3.5. Artefacto: interfaz<br/>9.3.6. Artefacto: descripción de la arquitectura (vista del modelo de diseño)<br/>9.3.7. Artefacto: modelo de despliegue<br/>9.3.8. Artefacto: descripción de la arquitectura (vista del modelo de despliegue)<br/>9.4. Trabajadores<br/>9.4.1. Trabajador: arquitecto<br/>9.4.2. Trabajador: ingeniero de casos de uso<br/>9.4.3. Trabajador: ingeniero de componentes<br/>9.5. Flujo de trabajo<br/>9.5.1. Actividad: diseño de la arquitectura<br/>9.5.2. Actividad: diseñar un caso de uso<br/>9.5.3. Actividad: diseñar una clase<br/>9.5.4. Actividad: diseñar un subsistema<br/>9.6. Resumen del diseño<br/>Capítulo 10: IMPLEMENTACIÓN<br/>10.1. Introducción<br/>10.2. El papel de la implementación en el ciclo de vida del software<br/>10.3. Artefactos<br/>10.3.1. Artefacto: modelo de implementación<br/>10.3.2. Artefacto: componente<br/>10.3.3. Artefacto: subsistema de la implementación<br/>10.3.4. Artefacto: interfaz<br/>10.3.5. Artefacto: descripción de la arquitectura (vista del modelo de implementación)<br/>10.3.6. Artefacto: plan de integración de construcciones<br/>10.4. Trabajadores<br/>10.4.1. Trabajador: arquitecto<br/>10.4.2. Trabajador: ingeniero de componentes<br/>10.4.3. Trabajador: integrador de sistemas<br/>10.5. Flujo de trabajo<br/>10.5.1. Actividad: implementación de la arquitectura<br/>10.5.2. Actividad: integrar el sistema<br/>10.5.3. Actividad: implementar un subsistema<br/>10.5.4. Actividad: implementar una clase<br/>10.5.5. Actividad: realizar prueba unidad<br/>10.6. Resumen de la implementación<br/>Capítulo 11: PRUEBA<br/>11.1. Introducción<br/>11.2. El papel de la prueba en el ciclo de vida del software<br/>11.3. Artefactos<br/>11.3.1. Artefacto: modelo de pruebas<br/>11.3.2. Artefacto: caso de prueba<br/>11.3.3. Artefacto: procedimiento de prueba<br/>11.3.4. Artefacto: componente de prueba<br/>11.3.5. Artefacto: plan de prueba<br/>11.3.6. Artefacto: defecto<br/>11.3.7. Artefacto: evaluación de prueba<br/>11.4. Trabajadores<br/>11.4.1. Trabajador: diseñador de pruebas<br/>11.4.2. Trabajador: ingeniero de componentes<br/>11.4.3. Trabajador: ingeniero de pruebas de integración<br/>11.4.4. Trabajador: ingeniero de pruebas del sistema<br/>11.5. Flujo de trabajo<br/>11.5.1. Actividad: planificar prueba<br/>11.5.2. Actividad: diseñar prueba<br/>11.5.3. Actividad: implementar prueba<br/>11.5.4. Actividad: realizar pruebas de integración<br/>11.5.5. Actividad: realizar prueba de sistema<br/>11.5.6. Actividad: evaluar prueba<br/>11.6. Resumen de la prueba<br/>PARTE III: EL DESARROLLO ITERATIVO E INCREMENTAL<br/>Capítulo 12: EL FLUJO DE TRABAJO DE ITERACIÓN GENÉRICO<br/>12.1. La necesidad de equilibrio<br/>12.2. Las fases son la primera división del trabajo<br/>12.2.1. La fase de inicio establece la viabilidad<br/>12.2.2. La fase de elaboración se centra en la factibilidad<br/>12.2.3. La fase de construcción construye el sistema<br/>12.2.4. La fase de transición se mete dentro del entorno del usuario<br/>12.3. La iteración genérica<br/>12.3.1. Los flujos de trabajo fundamentales se repiten en cada iteración<br/>12.3.2. Los trabajadores participan en los flujos de trabajo<br/>12.4. El planificar precede al hacer<br/>12.4.1. Planear las cuatro fases<br/>12.4.2. Plan de iteraciones<br/>12.4.3. Pensar a largo plazo<br/>12.4.4. Planear los criterios de evaluación<br/>12.5. Los riesgos influyen en la planificación del proyecto<br/>12.5.1. Administrar la lista de riesgos<br/>12.5.2. Los riesgos influyen en el plan de iteración<br/>12.5.3. Planificar la acción sobre los riesgos<br/>12.6. Asignación de prioridades a los casos de uso<br/>12.6.1. Riesgos específicos de un producto particular<br/>12.6.2. Riesgo de no conseguir la arquitectura correcta<br/>12.6.3. Riesgo de no conseguir los requisitos correctos<br/>12.7. Recursos necesitados<br/>12.7.1. Los proyectos difieren enormemente<br/>12.7.2. Un proyecto típico tiene este aspecto<br/>12.7.3. Los proyectos más grandes tienen mayores necesidades<br/>12.7.4. Una nueva línea de productos requiere experiencia<br/>12.7.5. El pago del coste de los recursos utilizados<br/>12.8. Evaluar las iteraciones y las fases<br/>12.8.1. Criterios no alcanzados<br/>12.8.2. Los criterios mismos<br/>12.8.3. La siguiente iteración<br/>12.8.4. Evolución del conjunto de modelos<br/>Capítulo 13: LA FASE DE INICIO PONE EN MARCHA EL PROYECTO<br/>13.1. La fase de inicio en pocas palabras<br/>13.2. Al comienzo de la fase de inicio<br/>13.2.1. Antes de comenzar la fase de inicio<br/>13.2.2. Planificación de la fase de inicio<br/>13.2.3. Ampliación de la descripción del sistema<br/>13.2.4. Establecimiento de los criterios de evaluación<br/>13.3. Flujo de trabajo arquetípico de una iteración en la fase de inicio<br/>13.3.1. Introducción a los cinco flujos de trabajo fundamentales<br/>13.3.2. Ajuste del proyecto al entorno de desarrollo<br/>13.3.3. Identificación de los riesgos críticos<br/>13.4. Ejecución de los flujos de trabajo fundamentales, de requisitos a pruebas<br/>13.4.1. Recopilación de requisitos<br/>13.4.2. Análisis<br/>13.4.3. Diseño<br/>13.4.4. Implementación<br/>13.4.5. Pruebas<br/>13.5. Realización del análisis inicial de negocio<br/>13.5.1. Esbozar la apuesta económica<br/>13.5.2. Estimar la recuperación de la inversión<br/>13.6. Evaluación de la iteración o iteraciones de la fase de inicio<br/>13.7. Planificación de la fase de elaboración<br/>13.8. Productos de la fase de inicio<br/>Capítulo 14: LA FASE DE ELABORACIÓN CONSTRUYE LA LÍNEA BASE DE LA ARQUITECTURA<br/>14.1. La fase de elaboración en pocas palabras<br/>14.2. Al comienzo de la fase de elaboración<br/>14.2.1. Planificación de la fase de elaboración<br/>14.2.2. Formación del equipo<br/>14.2.3. Modificación del entorno de desarrollo<br/>14.2.4. Establecimiento de criterios de evaluación<br/>14.3. Flujo de trabajo arquetípico de una iteración en la fase de elaboración<br/>14.3.1. Recopilación y refinamiento de la mayor parte de los requisitos<br/>14.3.2. Desarrollo de la línea base de la arquitectura<br/>14.3.3. Iterando mientras el equipo es pequeño<br/>14.4. Ejecución de los flujos de trabajo fundamentales, de requisitos a pruebas<br/>14.4.1. Recopilar los requisitos<br/>14.4.2. Análisis<br/>14.4.3. Diseño<br/>14.4.4. Implementación<br/>14.4.5. Pruebas<br/>14.5. Desarrollo del análisis del negocio<br/>14.5.1. Preparar la apuesta económica<br/>14.5.2. Actualizar la recuperación de la inversión<br/>14.6. Evaluación de las iteraciones de la fase de elaboración<br/>14.7. Planificación de la fase de construcción<br/>14.8. Productos clave<br/>Capítulo 15: LA CONSTRUCCIÓN LLEVA A LA CAPACIDAD OPERACIÓN INICIAL<br/>15.1. La fase de construcción en pocas palabras<br/>15.2. Al comienzo de la fase de construcción<br/>15.2.1. Asignación de personal para la fase<br/>15.2.2. Establecimiento de los criterios de evaluación<br/>15.3. Flujo de trabajo arquetípico de una iteración en la fase de construcción<br/>15.4. Ejecución de los flujos de trabajo fundamentales, de requisitos a pruebas<br/>15.4.1. Requisitos<br/>15.4.2. Análisis<br/>15.4.3. Diseño<br/>15.4.4. Implementación<br/>15.4.5. Pruebas<br/>15.5. Control del análisis de negocio<br/>15.6. Evaluación de las iteraciones y de la fase de construcción<br/>15.7. Planificación de la fase de transición<br/>15.8. Productos clave<br/>Capítulo 16: LA TRANSICIÓN COMPLETA LA VERSIÓN DEL PRODUCTO<br/>16.1. La fase de transición en pocas palabras<br/>16.2. Al comienzo de la fase de transición<br/>16.2.1. Planificación de la fase de transición<br/>16.2.2. Asignación de personal para la fase<br/>16.2.3. Establecimiento de los criterios de evaluación<br/>16.3. Los flujos de trabajo fundamentales desempeñan un papel pequeño en esta fase<br/>16.4. Lo que se hace en la fase de transición<br/>16.4.1. Preparación de la versión beta<br/>16.4.2. Instalación de la versión beta<br/>16.4.3. Reacción a los resultados de las pruebas<br/>16.4.4. Adaptación del producto a entornos de usuario variados<br/>16.4.5. Finalización de los artefactos<br/>16.4.6. ¿Cuándo acaba el proyecto?<br/>16.5. Finalización del análisis del negocio<br/>16.5.1. Control del progreso<br/>16.5.2. Revisión del plan del negocio<br/>16.6. Evaluación de la fase de transición<br/>16.6.1. Evaluación de las iteraciones y de la fase<br/>16.6.2. Autopsia del proyecto<br/>16.7. Planificación de la próxima versión o generación<br/>16.8. Productos clave<br/>Capítulo 17: CÓMO HACER QUE EL PROCESO UNIFICADO FUNCIONE<br/>17.1. El Proceso Unificado ayuda a manejar la complejidad<br/>17.1.1. Los objetivos del ciclo de vida<br/>17.1.2. La arquitectura del ciclo de vida<br/>17.1.3. Capacidad operativa inicial<br/>17.1.4. Lanzamiento del producto<br/>17.2. Los temas importantes<br/>17.3. La dirección lidera la conversión al Proceso Unificado<br/>17.3.1. La necesidad de actuar<br/>17.3.2. La directriz de reingeniería<br/>17.3.3. Implementación de la transición<br/>17.4. Especialización del Proceso Unificado<br/>17.4.1. Adaptación del proceso<br/>17.4.2. Completando el marco de trabajo del proceso<br/>17.5. Relación con comunidades más amplias<br/>17.6. Obtenga los beneficios del Proceso Unificado<br/>APÉNDICE A: Visión general del UML<br/>A.1. Introducción<br/>A.1.1. Vocabulario<br/>A.1.2. Mecanismos de extensibilidad<br/>A.2. Notación gráfica<br/>A.2.1. Cosas estructurales<br/>A.2.2. Elementos de comportamiento<br/>A.2.3. Elementos de agrupación<br/>A.2.A. Elementos de anotación<br/>A.2.5. Relaciones de dependencia<br/>A.2.6. Relaciones de asociación<br/>A.2.7. Relaciones de generalización<br/>A.2.8. Mecanismos de extensibilidad<br/>A.3. Glosario de términos<br/>APÉNDICE B: Extensiones del UML específicas del Proceso Unificado<br/>B.1. Introducción<br/>B.2. Estereotipos<br/>B.3. Valores etiquetados<br/>B.A. Notación gráfica<br/>B.5. Referencias<br/>Apéndice C: Glosario general<br/>C.1. Introducción<br/>C.2. Términos
650 #7 - PUNTO DE ACCESO ADICIONAL DE MATERIA--TÉRMINO DE MATERIA
Término de materia SOPORTE LOGICO DE COMPUTADORES
Fuente del encabezamiento o término Spines
650 #7 - PUNTO DE ACCESO ADICIONAL DE MATERIA--TÉRMINO DE MATERIA
Término de materia LENGUAJES DE PROGRAMACION
Fuente del encabezamiento o término Spines
700 1# - PUNTO DE ACCESO ADICIONAL--NOMBRE DE PERSONA
Nombre personal Booch, Grady
700 1# - PUNTO DE ACCESO ADICIONAL--NOMBRE DE PERSONA
Nombre personal Rumbaugh, James
830 #0 - PUNTO DE ACCESO ADICIONAL DE SERIE-TÍTULO UNIFORME
Título uniforme The Addison-Wesley object technology series
942 ## - ELEMENTOS DE PUNTO DE ACCESO ADICIONAL (KOHA)
Tipo de ítem Koha Libros
Esquema de clasificación Universal Decimal Classification
999 ## - NÚMEROS DE CONTROL DE SISTEMA (KOHA)
-- 1362
-- 1362
Existencias
Estado Estado perdido Esquema de Clasificación Estado de conservación Tipo de préstamo Tipo de colección Localización permanente Ubicación/localización actual ST Fecha de adquisición Origen de la adquisición Número de inventario Total Checkouts ST completa de Koha Código de barras Date last seen Número de patrimonio Número de copias Tipo de ítem Koha
    Universal Decimal Classification       Biblioteca "Ing. Alcides R. Martínez" Biblioteca "Ing. Alcides R. Martínez"   02/06/2004 Compra 1686   681.3.06 J157 1686 28/10/2024 509.10 28/10/2024 Libros