Ingeniería de software clásica y orientada a objetos / (Registro nro. 12823)

Detalles MARC
000 -Cabecera
Campo de control de longitud fija 18178nam a2200313 a 4500
003 - Identificador del Número de control
Identificador del número de control AR-sfUTN
008 - Códigos de información de longitud fija-Información general
Códigos de información de longitud fija 170717b ||||| |||| 00| 0 d
020 ## - ISBN
ISBN 9701056361
040 ## - Fuente de la catalogación
Centro transcriptor AR-sfUTN
041 ## - Código de lengua
Código de lengua del texto spa
080 ## - CDU
Clasificación Decimal Universal 004.41 SCH11
Edición de la CDU 2000
100 1# - Punto de acceso principal-Nombre de persona
Nombre personal Schach, Stephen R.
245 10 - Mención de título
Título Ingeniería de software clásica y orientada a objetos /
Mención de responsabilidad Stephen R. Schach.
250 ## - Mención de edición
Mención de edición 6ta. [i.e. en inglés, 1ra. en español]
260 ## - Publicación, distribución, etc. (pie de imprenta)
Lugar de publicación, distribución, etc. México:
Nombre del editor, distribuidor, etc. McGraw-Hill,
Fecha de publicación, distribución, etc. 2006
300 ## - Descripción física
Extensión 581 p.
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
505 80 - Nota de contenido con formato
Nota de contenido con formato CONTENIDO<br/>PARTE UNO. INTRODUCCION A LA INGENIERIA DE SOFTWARE 1<br/>Capítulo 1. El campo de aplicación de la ingeniería de software 3<br/>1.1. Aspectos históricos 4<br/>1.2. Aspectos económicos 6<br/>1.3. Aspectos del mantenimiento 7<br/>1.3.1. Conceptos tradicional y moderno del mantenimiento 9<br/>1.3.2. La importancia del mantenimiento posentrega 11<br/>1.4. Requisitos, análisis y aspectos de diseño 13<br/>1.5. Aspectos de la formación de equipos 15<br/>1.6. Por qué no hay fase de planeación 16<br/>1.7. Por qué no hay plan fase de pruebas 17<br/>1.8. Por qué no hay fase de documentación 17<br/>1.9. Paradigma orientado a objetos 18<br/>1.10. Paradigma orientado a objetos en perspectiva 23<br/>1.11. Terminología 23<br/>1.12. Temas de ética 26<br/>Capítulo 2. Modelos del ciclo de vida del software 34<br/>2.1. Desarrollo del software en teoría 34<br/>2.2. Minicaso de estudio Winburg 35<br/>2.3. Lecciones del minicaso de estudio Winburg 39<br/>2.4. Minicaso de estudio de Teal Tractors 39<br/>2.5. Iteración e incrementación 40<br/>2.6. Revisión del minicaso de estudio Winburg 44<br/>2.7. Riesgos y otros aspectos de la Iteración e incrementación 45<br/>2.8. Manejo de Iteración e incrementación 47<br/>2.9. Otros modelos del ciclo de vida 39<br/>2.9.1. Modelo del ciclo de vida de codificación y ajuste 48<br/>2.9.2. Modelo del ciclo de vida de cascada 49<br/>2.9.3. Modelo del ciclo de vida de elaboración rápida de un prototipo 51<br/>2.9.4. Programación extrema y proceso ágil 52<br/>2.9.5. Modelo del ciclo de vida de sincronización y estabilización 54<br/>2.9.6. Modelo del ciclo de vida en espiral 54<br/>2.10. Comparación de los modelos del ciclo de vida 58<br/>Capítulo 3. El proceso del software 64<br/>3.1. El Proceso Unificado 66<br/>3.2. Iteración e incrementación en el paradigma orientado a objetos 67<br/>3.3. El flujo de trabajo de los requerimientos 68<br/>3.4. El flujo de trabajo del análisis 70<br/>3.5. El flujo de trabajo del diseño 72<br/>3.6. El flujo de trabajo de la implementación 73<br/>3.7. El flujo de trabajo de las pruebas 74<br/>3.7.1. Artefactos de los requerimientos 74<br/>3.7.2. Artefactos del análisis 74<br/>3.7.3. Artefactos del diseño 75<br/>3.7.4. Artefactos de la implementación 75<br/>3.8. Mantenimiento posentrega 77<br/>3.9. Retiro 78<br/>3.10. Las fases del Proceso Unificado 78<br/>3.10.1. La fase de comienzo 79<br/>3.10.2. La fase de elaboración 81<br/>3.10.3. La fase de construcción 82<br/>3.10.4. La fase de transición 82<br/>3.11. Modelos del ciclo de vida uni contra bidimensionales 83<br/>3.12. Mejoramiento del proceso del software 84<br/>3.13. Modelos de madurez de la capacidad 85<br/>3.14. Otras iniciativas para el mejoramiento de los procesos de software 88<br/>3.15. Costos y beneficios del mejoramiento del proceso del software 89<br/>Capítulo 4. Equipos 96<br/>4.1. Organización de equipos 96<br/>4.2. Enfoque del equipo democrático 98<br/>4.2.1. Análisis del enfoque de los equipos democráticos 99<br/>4.3. Enfoque clásico del equipo con un programador jefe 99<br/>4.3.1. El proyecto de New York Times 101<br/>4.3.2. Lo que no es práctico del enfoque clásico del equipo con un programador jefe 102<br/>4.4. Más allá de los equipos de Programación con jefe y de los equipos democráticos 102<br/>4.5. Equipos de sincronización y estabilización 106<br/>4.6. Equipos de Programación extrema 106<br/>4.7. El modelo de madurez de la capacidad de las personas 107<br/>4.8. Elección de una Organización de equipos adecuada 108<br/>Capítulo 5. Las herramientas del oficio 112<br/>5.1. Depuración paso a paso 112<br/>5.1.1. Minicaso de estudio de la depuración paso a paso 113<br/>5.2. Análisis costo-beneficio 118<br/>5.3. Métrica del software 119<br/>5.4. CASE 121<br/>5.5. Taxonomía de CASE 122<br/>5.6. El alcance de CASE 123<br/>5.7. Versiones del software 127<br/>5.7.1. Revisiones 127<br/>5.7.2. Variaciones 128<br/>5.8. Control de la configuración 129<br/>5.8.1. Control de la configuración durante el mantenimiento posentrega 131<br/>5.8.2. Líneas base 131<br/>5.8.3. Control de la configuración durante el desarrollo 132<br/>5.9. Herramientas de construcción 132<br/>5.10. Ganancias de productividad con la tecnología CASE 133<br/>Capítulo 6. Pruebas 139<br/>6.1. Aspectos de calidad 140<br/>6.1.1. Aseguramiento de calidad de software 141<br/>6.1.2. Independencia gerencial 141<br/>6.2. Pruebas basadas en la no ejecución 142<br/>6.2.1. Recorridos 143<br/>6.2.2. La gestión de los recorridos 143<br/>6.2.3. Inspecciones 144<br/>6.2.4. Comparación de las inspecciones y los recorridos 146<br/>6.2.5. Fortalezas y debilidades de las revisiones 147<br/>6.2.6. Métricas para la inspección 147<br/>6.3. Pruebas basadas en la ejecución 147<br/>6.4. ¿Qué debe ser probado? 148<br/>6.4.1. Utilidad 149<br/>6.4.2. Confiabilidad 149<br/>6.4.3. Robustez 150<br/>6.4.4. Desempeño 150<br/>6.4.5. Corrección 151<br/>6.5. Evaluación comparada con pruebas de corrección 152<br/>6.5.1. Ejemplo de una prueba de corrección 152<br/>6.5.2. Minicaso de estudio de la prueba de corrección 156<br/>6.5.3. Pruebas de corrección e ingeniería de software 157<br/>6.6. ¿Quién debe llevar a cabo la prueba basada en la ejecución? 159<br/>6.7. Cuándo terminan las pruebas 161<br/>Capítulo 7. De módulos a objetos 166<br/>7.1. ¿Qué es un módulo? 166<br/>7.2. Cohesión 170<br/>7.2.1. Cohesión coincidente 170<br/>7.2.2. Cohesión lógica 171<br/>7.2.3. Cohesión temporal 172<br/>7.2.4. Cohesión procedimental 172<br/>7.2.5. Cohesión comunicacional 173<br/>7.2.6. Cohesión funcional 173<br/>7.2.7. Cohesión informacional 174<br/>7.2.8. Ejemplo de Cohesión 174<br/>7.3. Acoplamiento 175<br/>7.3.1. Acoplamiento por el contenido 176<br/>7.3.2. Acoplamiento común 176<br/>7.3.3. Acoplamiento por control 178<br/>7.3.4. Acoplamiento por molde 178<br/>7.3.5. Acoplamiento de datos 180<br/>7.3.6. Ejemplo de acoplamiento 180<br/>7.3.7. La importancia del acoplamiento 181<br/>7.4. Encapsulación de datos 182<br/>7.4.1. Encapsulación de datos y desarrollo 184<br/>7.4.2. Encapsulación de datos y mantenimiento 185<br/>7.5. Tipos de datos abstractos 191<br/>7.6. Ocultamiento de la información 192<br/>7.7. Objetos 194<br/>7.8. Herencia, polimorfismo y enlace dinámico 198<br/>7.9. El paradigma orientado a objetos 200<br/>Capítulo 8. Reutilización y portabilidad 208<br/>8.1. Conceptos de reutilización 209<br/>8.2. Obstáculos para la reutilización 211<br/>8.3. Estudios de caso de reutilización 212<br/>8.3.1. División de sistemas de Misiles Raytheon 212<br/>8.3.2. Agencia Europea del Espacio 214<br/>8.4. Objetos y reutilización 215<br/>8.5. Reutilización durante el diseño y la implementación 215<br/>8.5.1. Reutilización del diseño 215<br/>8.5.2. Esquemas de aplicación 217<br/>8.5.3. Patrones de diseño 217<br/>8.5.4. Arquitectura de software 220<br/>8.5.5. Ingeniería de programación basada en componentes 222<br/>8.6. Reutilización y mantenimiento posentrega 222<br/>8.7. Portabilidad 223<br/>8.7.1. Incompatibilidades del hardware 224<br/>8.7.2. Incompatibilidades del sistema operativo 225<br/>8.7.3. Incompatibilidades del software numérico 225<br/>8.7.4. Incompatibilidades entre los compiladores 226<br/>8.8. ¿Por qué portabilidad? 229<br/>8.9. Técnicas para obtener portabilidad 230<br/>8.9.1. Software de sistema portable 230<br/>8.9.2. Software de aplicación portable 231<br/>8.9.3. Datos portables 232<br/>Capítulo 9. Planeación y estimación 240<br/>9.1. Planeación y proceso de software 241<br/>9.2. Estimación de duración y costo 242<br/>9.2.1. Métricas para el tamaño de un producto 243<br/>9.2.2. Técnicas de estimación de costos 247<br/>9.2.3. COCOMO intermedio 249<br/>9.2.4. COCOMO II 252<br/>9.2.5. Rastreo de los estimados de duración y costo 253<br/>9.3. Componentes de un plan de administración de proyecto de software 254<br/>9.4. Marco de trabajo del plan de administración del proyecto de software 255<br/>9.5. Plan de administración de proyectos de software IEEE 257<br/>9.6. Planeación de pruebas 260<br/>9.7. Planeación de proyectos orientados a objetos 261<br/>9.8. Requerimientos de capacitación 261<br/>9.9. Estándares de documentación 262<br/>9.10. Herramientas CASE para planeación y estimación 263<br/>9.11. Prueba del plan de administración de proyectos de software 263<br/>PARTE DOS. LOS FLUJOS DE TRABAJO DEL CICLO DE VIDA DEL SOFTWARE 269<br/>Capítulo 10. Requerimientos 271<br/>10.1. Cómo determinar lo que el cliente necesita 271<br/>10.2. Repaso del flujo de trabajo de los requerimientos 272<br/>10.3. Comprender el dominio 273<br/>10.4. El modelo de negocio 274<br/>10.4.1. Como entrevistar 274<br/>10.4.2. Otras técnicas 275<br/>10.4.3. Casos de uso 276<br/>10.5. Requerimientos iniciales 277<br/>10.6. Comprensión inicial del dominio: el caso de estudio Osbert Oglesby 278<br/>10.7. Modelo de negocio inicial: el caso de estudio Osbert Oglesby 279<br/>10.8. Requerimientos iniciales: el caso de estudio Osbert Oglesby 282<br/>10.9. Continuación del flujo de trabajo de los requerimientos: el caso de estudio Osbert Oglesby 284<br/>10.10. El flujo de trabajo de las pruebas: el caso de estudio Osbert Oglesby 291<br/>10.11. La fase de requerimientos clásica 292<br/>10.12. Elaboración rápida de un prototipo 293<br/>10.13. Factores humanos 294<br/>10.14. Reutilización del prototipo rápido 295<br/>10.15. Herramientas CASE para el flujo de trabajo de los requerimientos 196<br/>10.16. Métricas para el flujo de trabajo de los requerimientos 297<br/>10.17. Retos del flujo de trabajo de los requerimientos 298<br/>Capítulo 11. Análisis clásico 303<br/>11.1. El documento de especificaciones 303<br/>11.2. Especificaciones informales 305<br/>11.2.1. Prueba de rectificación minicaso de estudio Redux 306<br/>11.3. Análisis de sistemas estructurados 307<br/>11.3.1. Minicaso de estudio de la tienda de Software de Sally 307<br/>11.4. Análisis de sistemas estructurados: el caso de estudio Osbert Oglesby 315<br/>11.5. Otras técnicas semiformales 316<br/>11.6. Modelo entidad-relación 317<br/>11.7. Máquinas de estado finito 319<br/>11.7.1. Máquinas de estado finito: el caso de estudio del problema del elevador 321<br/>11.8. Redes de Petri 325<br/>11.8.1. Redes de Petri: el caso de estudio del problema del elevador 328<br/>11.9. Z 330<br/>11.9.1. Z: el caso de estudio del problema del elevador 330<br/>11.9.2. Análisis de Z 333<br/>11.10. Otras técnicas formales 334<br/>11.11. Comparación de las técnicas de análisis clásico 335<br/>11.12. Probando durante el análisis clásico 335<br/>11.13. Herramientas CASE para el análisis clásico 336<br/>11.14. Métricas para el análisis clásico 337<br/>11.15. Plan de administración del proyecto de software: el caso de estudio Osbert Oglesby 338<br/>11.16. Retos del análisis clásico 338<br/>Capítulo 12. Análisis orientado a objetos 346<br/>12.1. El flujo de trabajo del análisis 347<br/>12.2. Extracción de las clases de entidad 348<br/>12.3. Análisis orientado a objetos: el caso de estudio del problema del elevador 349<br/>12.4. Modelado funcional: el caso de estudio del problema del elevador 349<br/>12.5. Modelado de clases de entidad: el caso de estudio del problema del elevador 351<br/>12.5.1. Extracción de sustantivos 352<br/>12.5.2. Tarjetas CRC 354<br/>12.6. Modelado dinámico: el caso de estudio del problema del elevador 355<br/>12.7. El flujo de trabajo de las pruebas: análisis orientado a objetos 358<br/>12.8. Extracción de las clases de control y de frontera 362<br/>12.9. El modelo funcional inicial: el caso de estudio de Osbert Oglesby 363<br/>12.10. El diagrama de clases inicial: el caso de estudio de Osbert Oglesby 365<br/>12.11. El modelo dinámico inicial: el caso de estudio de Osbert Oglesby 371<br/>12.12. Extracción de las clases de frontera: el caso de estudio de Osbert Oglesby 373<br/>12.13. Extracción de las clases de control: el caso de estudio de Osbert Oglesby 374<br/>12.14. Refinación de los casos de uso: el caso de estudio de Osbert Oglesby 374<br/>12.15. Realización del caso de uso: el caso de estudio de Osbert Oglesby 377<br/>12.15.1. El caso de uso comprar una Obra maestra 377<br/>12.15.2. Caso de Uso comprar un Trabajo maestro 382<br/>12.15.3. Caso de Uso Comprar Otra Pintura 383<br/>12.15.4. Los cinco casos de uso restantes 384<br/>12.16. Incrementos en el diagrama de clases: el caso de estudio Osbert Oglesby 386<br/>12.17. El flujo de trabajo de las pruebas: el caso de estudio Osbert Oglesby 388<br/>12.18. El documento de especificaciones en el Proceso Unificado 388<br/>12.19. Más sobre actores y casos de uso 389<br/>12.20. Herramientas CASE para el flujo de trabajo del análisis orientado a objetos 391<br/>12.21. Retos del flujo de trabajo del análisis orientado a objetos 391<br/>Capítulo 13. Diseño 397<br/>13.1. Diseño y abstracción 398<br/>13.2. Diseño orientado a operaciones 398<br/>13.3. Análisis del flujo de datos 399<br/>13.3.1. Contador de palabras 400<br/>13.3.2. Extensiones del análisis del flujo de datos 405<br/>13.4. Análisis de transacciones 405<br/>13.5. Diseño orientado a datos 407<br/>13.6. Diseño orientado a objetos 408<br/>13.7. Diseño orientado a objetos: el caso de estudio del problema del elevador 409<br/>13.8. Diseño orientado a objetos: el caso de estudio Osbert Oglesby 412<br/>13.9. El flujo de trabajo del diseño 416<br/>13.10. El flujo de trabajo de las pruebas: diseño 418<br/>13.11. El flujo de trabajo de las pruebas: el caso de estudio Osbert Oglesby 419<br/>13.12. Técnicas formales para el diseño detallado 419<br/>13.13. Técnicas de diseño de tiempo-real 419<br/>13.14. Herramientas CASE para el diseño 421<br/>13.15. Métricas para el diseño 421<br/>13.16. Retos del flujo de trabajo del diseño 422<br/>Capítulo 14. Implementación 428<br/>14.1. Elección del lenguaje de programación 428<br/>14.2. Lenguajes de cuarta generación 431<br/>14.3. Buenas prácticas de programación 433<br/>14.3.1. Uso consistente y significativo de nombres de variables 434<br/>14.3.2. El punto de auto-documentar el código 435<br/>14.3.3. Uso de parámetros 436<br/>14.3.4. Disposición del código para hacer más fácil la lectura 437<br/>14.3.5. Sentencias if anidadas 437<br/>14.4. Estándares de codificación 439<br/>14.5. Reutilización del código 439<br/>14.6. Integración 440<br/>14.6.1. Integración descendente (Top-down) 440<br/>14.6.2. Integración ascendente (bottom up) 442<br/>14.6.3. Integración sándwich 443<br/>14.6.4. Integración de productos orientados a objetos 443<br/>14.6.5. Administración de la integración 445<br/>14.7. El flujo de trabajo de la implementación 445<br/>14.8. El flujo de trabajo de la implementación: el caso de estudio Osbert Oglesby 445<br/>14.9. El flujo de trabajo de las pruebas: implementación 446<br/>14.10. Selección de casos de prueba 446<br/>14.10.1. Prueba de especificaciones contra prueba de código 446<br/>14.10.2. Viabilidad de las pruebas de especificaciones 446<br/>14.10.3. Viabilidad de la prueba de código 447<br/>14.11. Técnicas de pruebas unitarias de caja negra 450<br/>14.11.1. Pruebas de equivalencia y análisis del valor frontera 450<br/>14.11.2. Pruebas funcionales 451<br/>14.12. Casos de prueba de caja-negra: el caso de estudio de Osbert Oglesby 452<br/>14.13. Técnicas de pruebas unitarias de caja de cristal 455<br/>14.13.1. Pruebas estructurales: sentencias, ramas y cobertura de ruta 455<br/>14.13.2. Métricas de complejidad 457<br/>14.14. Recorridos e inspecciones al código 458<br/>14.15. Comparación de las técnicas de pruebas unitarias 458<br/>14.16. Cleanroom 459<br/>14.17. Problemas potenciales cuando se prueban objetos 460<br/>14.18. Aspectos administrativos de las pruebas unitarias 462<br/>14.19. Cuándo reescribir en lugar de depurar un artefacto de código 463<br/>14.20. Pruebas de integración 464<br/>14.21. Pruebas de producto 465<br/>14.22. Pruebas de aceptación 466<br/>14.23. El flujo de trabajo de las pruebas: el estudio de caso Osbert Oglesby 467<br/>14.24. Herramientas CASE para la implementación 467<br/>14.24.1. Herramientas CASE para el proceso completo de software 467<br/>14.24.2. Entornos de desarrollo integrados 468<br/>14.24.3. Entornos para aplicaciones de negocio 469<br/>14.24.4. Infraestructuras de herramientas públicas 469<br/>14.24.5. Problemas potenciales con los entornos 470<br/>14.25. Métricas para el flujo de trabajo de la implementación 470<br/>14.26. Retos del flujo de trabajo de la implementación 470<br/>Capítulo 15. Mantenimiento posentrega 479<br/>15.1. Por qué es necesario el mantenimiento posentrega 480<br/>15.2. ¿Qué se les exige a los programadores durante el mantenimiento posentrega? 480<br/>15.3. Mini caso de estudio mantenimiento posentrega 482<br/>15.4. Administración del mantenimiento posentrega 484<br/>15.4.1. Informes de defectos 484<br/>15.4.2. La autorización de cambios al producto 485<br/>15.4.3. Aseguramiento de la capacidad de mantenimiento 486<br/>15.4.4. El problema del mantenimiento repetido 486<br/>15.5. Mantenimiento del software orientado a objetos 487<br/>15.6. Diferencia entre habilidades de mantenimiento posentrega y habilidades de desarrollo 489<br/>15.7. Ingeniería en reversa 490<br/>15.8. Pruebas hechas durante el mantenimiento posentrega 491<br/>15.9. Herramientas CASE para el mantenimiento posentrega 492<br/>15.10. Métricas para el mantenimiento posentrega 492<br/>15.11. Mantenimiento posentrega: el caso de estudio Osbert Oglesby 493<br/>15.12. Retos del mantenimiento posentrega 493<br/>Capítulo 16. Más sobre UML 497<br/>16.1. UML no es una metodología 497<br/>16.2. Diagramas de clases 498<br/>16.2.1. Agregación 499<br/>16.2.2. Multiplicidad 500<br/>16.2.3. Composición 501<br/>16.2.4. Generalización 502<br/>16.2.5. Asociación 502<br/>16.3. Notas 503<br/>16.4. Diagramas de casos de uso 503<br/>16.5. Estereotipos 503<br/>16.6. Diagramas de interacción 504<br/>16.7. Diagramas de estados 506<br/>16.8. Diagramas de actividades 509<br/>16.9. Paquetes 511<br/>16.10. Diagramas de componentes 511<br/>16.11. Diagramas de implementación 511<br/>16.12. Repaso de los diagramas UML 511<br/>16.13. UML y la iteración 512
650 ## - Punto de acceso adicional de materia - Término de materia
Término de materia INGENIERIA DE SOFTWARE
650 ## - Punto de acceso adicional de materia - Término de materia
Término de materia PROCESO DEL SOFTWARE
650 ## - Punto de acceso adicional de materia - Término de materia
Término de materia INGENIERIA DE REQUERIMIENTOS
650 ## - Punto de acceso adicional de materia - Término de materia
Término de materia ANALISIS ORIENTADO A OBJETOS
650 ## - Punto de acceso adicional de materia - Término de materia
Término de materia UML
650 ## - Punto de acceso adicional de materia - Término de materia
Término de materia CASE
942 ## - ADDED ENTRY ELEMENTS (KOHA)
Tipo de ítem Koha Libro
Esquema de clasificación Clasificación Decinal Universal
Existencias
Estado Estado perdido Estado de conservación Tipo de préstamo Biblioteca Biblioteca 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 Date last checked out Precio efectivo a partir de Tipo de ítem Koha
      Sólo Consulta Facultad Regional Santa Fe - Biblioteca "Rector Comodoro Ing. Jorge Omar Conca" Facultad Regional Santa Fe - Biblioteca "Rector Comodoro Ing. Jorge Omar Conca" 02/02/2018 Compra Contratación directa, Expediente N°21/2009 10060 1 004.41 SCH11 10060 22/05/2019 22/05/2019 02/02/2018 Libro