EL PROCESO UNIFICADO DEL DESARROLLO DE SOFTWARE (Registro nro. 5425)

000 -CABECERA
campo de control de longitud fija 10895nam a2200265Ia 4500
001 - NÚMERO DE CONTROL
campo de control 1104
008 - DATOS DE LONGITUD FIJA--INFORMACIÓN GENERAL
campo de control de longitud fija 522237 2000 sp x 8052223000spa00
020 ## - NÚMERO INTERNACIONAL ESTÁNDAR DEL LIBRO
Número Internacional Estándar del Libro 84-7829-036-2
040 ## - FUENTE DE LA CATALOGACIÓN
Centro/agencia transcriptor EAM
041 ## - CÓDIGO DE LENGUA
Código de lengua del texto/banda sonora o título independiente ESPAÑOL
082 ## - NÚMERO DE LA CLASIFICACIÓN DECIMAL DEWEY
Número de clasificación 005.1 J.115
090 ## - LOCALMENTE ASIGNADO TIPO-LC NÚMERO DE CLASIFICACIÓN (OCLC); NÚMERO DE CLASIFICACIÓN LOCAL (RLIN)
Número de clasificación (OCLC) (R) ; Numero de clasificación, CALL (RLIN) (NR) 5425
100 ## - ENTRADA PRINCIPAL--NOMBRE DE PERSONA
Nombre de persona JACOBSON, IVAR
245 ## - MENCIÓN DE TÍTULO
Título EL PROCESO UNIFICADO DEL DESARROLLO DE SOFTWARE
245 ## - MENCIÓN DE TÍTULO
Mención de responsabilidad, etc. IVAR JACOBSON
260 ## - PUBLICACIÓN, DISTRIBUCIÓN, ETC. (PIE DE IMPRENTA)
Lugar de publicación, distribución, etc. España
260 ## - PUBLICACIÓN, DISTRIBUCIÓN, ETC. (PIE DE IMPRENTA)
Nombre del editor, distribuidor, etc. Pearson Educacion
260 ## - PUBLICACIÓN, DISTRIBUCIÓN, ETC. (PIE DE IMPRENTA)
Fecha de publicación, distribución, etc. 2000
300 ## - DESCRIPCIÓN FÍSICA
Extensión 438p.
500 ## - NOTA GENERAL
Nota general Incluye indice analitico
520 ## - SUMARIO, ETC.
Sumario, etc. 1.El proceso unificado del desarrillo de software / 2.el proceso unificado : dirigido por casos de uso centrado en la arquitectura interativo e inbremental / 3.el proceso unificado en pocas palabras / 4.el proceso unificado esta dirigido por casos de uso / 5.el proceso unificado esta centrado en la arquitectura / 6.el proceso unificado es interativo e incremental / 7.la vida del proceso unificado / 8.el producto / 9.fases dentro de un ciclo / 10.un proceso integrado / 11.las cuatro p en el desarrollo del software : personas producto precio / 12.las personas son decisivas / 13.los procesos de desarrollo afectan a la personas / 14.los papelos cambiaran / 15.convirtiendo recursos en trabajadores / 16.los proyectos constituyen productos / 17.el producto es mas que codigo / 18.que es un sistema software / 19.artefactos / 20.un sistema posee una coleccion de modelos / 21.que es un modelo / 22.cada modelo es una vista aurocontenida del sistema / 23.dentro de un modelo / 24.relaciones entre modelos / 25.el proceso dirige los proyectos / 26.el proceso : una plantilla / 27.las acrividades relacionadas conforman flujos de trabajo / 28.procesos especializados / 29.meritos del proceso / 30.las herramientas son esenciales en el proceso / 31.el proceso dirige las herramientas / 32.el modelo visual soporta uml / 33.las herramientas dan soporte al ciclo de vida completo / 34.referencias / 35.un proceso dirigido por casos de uso / 36.desarrollo dirigido por casos de uso en pocas palabras / 37.porque casos de uso / 38.para capturar los requisitos que aportan valor añadido / 39.para idear la arquitectura y mas / 40.la captura de casos de uso / 41.el modelo de casos de uso representa los requisitos funcionales / 42.los actores son el entorno del sistema / 43.los casos de uso representan el sistema 44.analisis diseño e implementacion para realizar los casos de uso / 45.creacion del modelo de analisis a partir de los casos de uso / 46.cada clase debe cumplir todos sus roles de colaboracion / 47.creacion del modelo de diseño a partir del modelo de analisis / 48.los subsistemas qgrupan a las clases / 49.creacion del modelo de implementacion apartir del modelo de diseño / 50.prueba de los casos de uso / 51.referencias / 52.un proceso centrado en la arquitectura / 53.la arquitectura en pocas palabras / 54.por que es necesaria la arquitctura / 55.comprension del sistema / 56.organizacion del desarrollo / 57.fomento de la reutilizacion / 58.evolucion del sistema / 59.casos de uso y arquitectura / 60.la linea base de la arquitectura es un sistema pequeño y flaco / 61.utilizacion de patrones arquitectonicos / 62.descripcion de la arquitectura / 63.el arquitecto crea la arquitctura / 64.por fin una desctripcion de la arquitectura / 65.la vista de la arquitectura del modelo de casos de uso / 66.la vista de la arquitectura del modelo de diseño / 67.la vista de la arquitectura del modelo de despliegue / 68.la vista de la arquitectura del modelo de implementacion / 69.tres conceptos interesantes / 70.que es una arquitectura / 71.como se obtiene / 72.como se describe / 73.un proceso interativo e incremental / 74.interativo e incremental en breve / 75.desarrollo en pequeños pasos / 76.lo que no es una interacion / 77.por que un desarrollo interativo e incremental / 78.atenuacion de riesgos / 79.obtencion de una arquitectura robusta / 80.gestion de requisitos cambiantes / 81.permitir cambops tacticos / 82.conseguir una integracion continua / 83.conseguir un aprendizaje temprano / 84.la aproximacion interativa es dirigida por los riesgos / 85.las interaciones alivian los riesgos tecnicos / 86.la diteccion es responsable de los riesgos no tecnicos / 87.tratamiento de los riesgos / 88.la interaccion generica / 89.lo que es una interaccion / 90.planificacion de las interacciones / 91.las interacciones desafian a la organizacion / 92.referencias / 93.los flujos de trabajo fundamentales / 94.captura de requisitos : de la vision a los requisistos / 95.por que la captura de los requisistos es complicada / 96.el objeto del flujo de trabajo de los requisitos / 97.vision general de la captura de requisitos / 98.el paoel de los requisitos en el ciclo de vida del sofrware / 99.la comprension del contexto del sistema mediante un modelo de dominio / 100.que es un modelo del dominio / 101.desarrollo de un modelo del dominio / 102.la comprension del contexto del sistema mediante un modelo del negocio / 103.captura de requisitos como casos de uso / 104.artefactos / 105.artefacto : modelo de casos de uso / 106.artefacto : actor / 107.casos de uso / 108.artefacto : descripsionde la arquitectura vista del modelo de casos de uso / 109.artefacto : glosario / 110.artefacto : prototipo de interfaz del usuario / 111.trabajadores / 112.trabajador 8 analista del sistema / 113.trabajador : especificador de casos de uso / 114.diseñador de interfaz del usuario / 115.trabajador : arquitecto / 116.flujo de trabajador / 117.actividad : encontrar actores y casos de uso / 118.actividad : priorizar casos de uso / 119.actividad : detallar en caso de uso / 120.actividad : prototipar la interfaz del usuario / 121.actividad : estructurar el modelo de casos de uso / 122.resumen del flujo de trabajo de los requisitos / 123.analisis/ 124.el analisis en pocas palabras / 125.por que el analisis no es diseño ni implementacion / 126.el objeto del analisis : resumen / 127.ejemplos concretos de cuando hacer analisis / 128.el papel del analisis en el ciclo de vida del software / 129.artefactos / 130.artefacto : modelo de analisis / 131.artefacto : clases de analisis / 132.artefacto : realizacion de caso de uso analisis / 133.artefacto : paquete del analisis / 134.artefacto : descripcion de la arquitectura vista del modelo de analisis / 135.trabajadores / 136.trabajadores : arquitecto / 137.trabajador : ingeniero de casos de uso / 138.trabajador : ingeniero de componentes / 139.flujo de trabajador / 140.actividad : analisis de la arquitectura / 141.actividad : analizar un caso de uso / 142.actividad : analizar una clase / 143.actividad : analizar un paquete / 144.diseño / 145.el papel del diseño en el ciclo de vida del software / 146.artefactos / 147.artefacto : modelo de diseño / 148.artefacto : clase de diseño / 149.artefacto : realizacion de casos de uso diseño / 150.artefacto : subsistema del diseño / 151.artefacto : interfaz / 152.artefacto : descripcion de la arquitectura vista del modelo de despliegue / 153.artefacto :descripcion de la arquitectura vista del modelo de despliegue / 154.trabajadores / 155.trabajador : arquitecto / 156.trabajador : ingeniero de casos de uso / 157.trabajador : ingeniero de componente / 158.flujo de trabajador / 159.actividad / 160.actividad : diseño de la arquitectura / 161.actividad : diseñar un caso de uso /162.actividad : diseñar una clase / 163.actividad : diseñar un subsistema / 164.implementacion / 165.el papel de la implementacion en el ciclo de vida del software / 166.artefactos / 167.artefacto : modelo de implementacion / 168.artefacto : componente / 169.artefacto : subsistema de la implementacion / 170.artefacto : interfaz / 171.artefacto : descripcion de la arquitectura vista del modelo de implementacion / 172.artefacto : plan de integracionde construcciones / 173.trabajadores / 174.trabajador : arquitecto / 175.trabajador : ingeniero de componentes / 176.trabajador : integrador de sistemas / 177.flujo de trabajo / 178.actividad : implementacion de la arquitectura / 179.trabajador : integrar el sistema / 180.trabajador 8 implementar el subsistema / 181.trabajador : implementar una clase / 182.trabajador : realizar prueba unidad / 183.prueba / 184.el papel del a prueba en el ciclo de vida del sofware / 185.artefactos / 186.artefacto : modelo de prueba / 187.artefacto : caso de prueba / 188.artefacto : procedimiento de prueba / 189.artefacto : componente de prueba / 190.artefacto : plan de prueba / 191.artefacto : defecto / 192.artefacto : evaluacion de la prueba / 193.trabajadores / 194.trabajador : diseñador de pruebas/ 195.trabajador : ingeniero de componentes / 196.trabajador : ingeniero de pruebas de integracion / 197.trabajador : ingeniero de pruebas del sistema / 198.flujo de trabajo / 199.actividad : planificar prueba / 200.actividad : diseñar prueba / 201.actividad : implementar prueba / 202.actividad : realizar pruebas de integracion / 203.actividad : realizar pruebas de sistema / 204.actividad : evaluar prueba / 205.desarrollo interativo e incremental / 206.el flujo de trabajo de intercion generico / 207.la necesidad de equilibrio / 208.las fases son las primera division del trabajo / 209.la fase de inicio establece la viabilidad / 210.la fase de elaboracion se centra en la factibilidad / 211.la fase de construccion construye el sistema / 212.la fase de transicion se mete dentro del entorno del usuario / 213.la iteracion generica / 214.los flujos de trabajo fundamentales se repiten en cada iteracion / 215.los trabajadores participan en los flujos de trabajos / 216.el planificar precede al hacer / 217.planer las cuatro fases / 218.plan de iteraciones / 219.pensar a largo plazo / 220.planear los criterios de evaluacion / 221.los riesgos influyen en la planificacion del proyecto / 222.administrar la lista de riesgos / 223.los riesgos influyen en el plan de iteracion / 224.planificar la accion sobre los riesgos / 225.asignacion de prioridades a los casos de uso / 226.riesgos especificos de un producto particular / 227.riesgo de no conseguir la arquitectura correcta / 228.riesgo de no conseguir los requisitos correctos / 229.recursos necesitados / 230.los proyectos difieren enormemente / 231.un proyecto tipico tiene este aspecto / 232.los proyectos mas grandes tienen mayores necesidades / 233.una nueva linea de productos requiere experiencia / 234.el pago del coste de los recursos utilizados / 235.evaluar las iteraciones y las fases / 236.criterios no alcanzados / 237.l
520 ## - SUMARIO, ETC.
Ampliación de la nota de sumario os criterios mismos / 238.la siguiente iteracion / 239.evolucion del conjunto de modelos / 240.la fase de inicio pone en marcha el proyecto / 241.la fase de inicio en pocas palabras / 242.al comienzo de la fase de inicio / 243.antes de comenzar la fase de
650 ## - PUNTO DE ACCESO ADICIONAL DE MATERIA--TÉRMINO DE MATERIA
Término de materia o nombre geográfico como elemento inicial PROGRAMAS INTEGRADOS PARA COMPUTADOR
700 ## - PUNTO DE ACCESO ADICIONAL--NOMBRE DE PERSONA
Nombre de persona BOOCH, GRADY \ RUMBAUGH, JAMES
942 ## - ELEMENTOS DE PUNTO DE ACCESO ADICIONAL (KOHA)
Tipo de ítem Koha Libros
Existencias
Precio válido a partir de Fecha visto por última vez Localización permanente No para préstamo Fecha de adquisición Tipo de ítem Koha Estado de pérdida Enumeración/cronología de publicación seriada Estado de retiro Número de copia Especificación de materiales (volumen encuadernado u otra parte) Renovaciones totales Fecha del último préstamo Total de préstamos Código de colección Estado dañado Código de barras Ubicación/localización actual Signatura topográfica completa
2015-01-272015-01-27EAM 2006-07-04Libros   1    INGENIERIA DE SISTEMAS 01754EAM005.1 J.115
2015-01-272019-05-07EAM 2006-08-24Libros   2  2015-10-081ANALISIS Y PROGRAMACION 01755EAM005.1 J.115
2015-01-272015-01-27EAM 2006-08-24Libros   3    ANALISIS Y PROGRAMACION 07307EAM005.1 J.115
2015-01-272015-04-27EAM 2005-01-21Libros   4 12015-04-082GENERAL 07458EAM005.1 J.115
2015-01-272023-10-31EAM 2005-01-21Libros   5  2023-08-141GENERAL 07459EAM005.1 J.115

PBX: (6) 745 11 01
FAX: Ext. 159

Avenida Bolivar N. 3-11
Institución Universitaria EAM
Armenia - Quindío

Síganos y únase a nuestra

Familia EAM

Con tecnología Koha