1. iIngeniera del softwareU N E N F O Q U E P R C T I C O

2. Ingeniera del softwareU N E N F O Q U E P R C T I C OSPTIMA EDICINRoger S. Pressman, Ph.D.University of ConnecticutMXICO BOGOT BUENOS AIRES CARACAS GUATEMALA MADRIDNUEVA YORK SAN JUAN SANTIAGO SO PAULO AUCKLAND LONDRES MILNMONTREAL NUEVA DELHI SAN FRANCISCO SINGAPUR ST. LOUIS SIDNEY TORONTO 3. Director Higher Education: Miguel ngel Toledo CastellanosEditor sponsor: Pablo Roig VzquezCoordinadora editorial: Marcela I. Rocha MartnezEditora de desarrollo: Mara Teresa Zapata TerrazasSupervisor de produccin: Zeferino Garca GarcaTraductores: Vctor Campos OlgunJavier Enrquez BritoRevisin tcnica: Carlos Villegas QuezadaBrbaro Jorge Ferro CastroINGENIERA DEL SOFTWARE. UN ENFOQUE PRCTICOSptima edicinProhibida la reproduccin total o parcial de esta obra,por cualquier medio, sin la autorizacin escrita del editor.EducacinDERECHOS RESERVADOS 2010, 2005, 2002 respecto a la tercera edicin en espaol porMcGRAW-HILL INTERAMERICANA EDITORES, S.A. DE C.V.A Subsidiary of The McGraw-Hill Companies, Inc.Prolongacin Paseo de la Reforma 1015, Torre APiso 17, Colonia Desarrollo Santa Fe,Delegacin lvaro ObregnC.P. 01376, Mxico, D. F.Miembro de la Cmara Nacional de la Industria Editorial Mexicana, Reg. Nm. 736ISBN: 978-607-15-0314-5(ISBN edicin anterior: 970-10-5473-3)Traducido de la sptima edicin de SOFTWARE ENGINEERING. A PRACTITIONERS APPROACH.Published by McGraw-Hill, a business unit of The McGraw-Hill Companies, Inc., 1221 Avenue of theAmericas, New York, NY 10020. Copyright 2010 by The McGraw-Hill Companies, Inc. All rightsreserved.978-0-07-337597-71234567890 109876543210Impreso en Mxico Printed in Mexico 4. En recuerdo de mi querido padre,quien vivi 94 aos y me ense,sobre todo, que la honestidady la integridad eran las mejoresguas para mi viaje por la vida. 5. ACERCA DEL AUTORRoger S. Pressman es una autoridad internacionalmente reconocida en el mejoramientodel proceso del software y en las tecnologas de la ingeniera del mismo. Durante casicuatro dcadas ha trabajado como ingeniero de software, gestor, profesor, escritor yconsultor, especializado en temas de ingeniera del software.Como profesional y gestor industrial, el doctor Pressman trabaj en el desarrollo de sistemasCAD/CAM para aplicaciones de ingeniera y fabricacin avanzadas. Tambin ha tenido posicio-nesde responsabilidad en la programacin cientfica y de sistemas.Despus de recibir su doctorado en ingeniera por parte de la Universidad de Connecticut,Pressman se dedic a la academia, donde se convirti en profesor asociado de la ctedra Bullarden ingeniera de cmputo de la Universidad de Bridgeport, y en director del Centro de Diseo yFabricacin Asistidos por Computadora de dicha universidad.En la actualidad, el doctor Pressman es presidente de R. S. Pressman & Associates, Inc., unaempresa de consultora especializada en mtodos y capacitacin en ingeniera del software.Trabaja como consultor principal y dise y desarroll Ingeniera del software esencial, un videocurricular completo acerca de ingeniera del software, y Consultor de procesos, un sistema auto-dirigidopara el mejoramiento del proceso de software. Ambos productos los utilizan miles decompaas en todo el mundo. Ms recientemente, trabaj en colaboracin con EdistaLearning,en India, para desarrollar capacitacin abarcadora basada en internet acerca de ingeniera delsoftware.El doctor Pressman ha escrito muchos artculos tcnicos, es colaborador regular en revistasperidicas industriales y autor de siete libros tcnicos. Adems de Ingeniera del software: unenfoque prctico, es coautor de Web Engineering (McGraw-Hill), uno de los primeros libros enaplicar un conjunto personalizado de principios y prcticas de la ingeniera del software al de-sarrollode sistemas y aplicaciones basados en web. Tambin escribi el premiado A ManagersGuide to Software Engineering (McGraw-Hill); Making Software Engineering Happen (Prenticehall), el primer libro en abordar los problemas administrativos cruciales asociados con el mejo-ramientodel proceso de software; y Software Shock (Dorset House), un tratamiento que se en-focaen el software y su impacto en los negocios y la sociedad. Pressman ha formado parte delos consejos editoriales de varias publicaciones industriales y durante muchos aos fue editorde la columna Manager en IEEE Software.Adems, es un orador bien conocido, y ha sido el orador principal en muchas conferenciasindustriales importantes. Es miembro de IEEE, y de Tau Beta Pi, Phi Kappa Phi, Eta Kappa Nu yPi Tau Sigma.En el lado personal, Pressman vive en el sur de Florida con su esposa, Brbara. Atleta de todala vida, sigue siendo un serio jugador de tenis (4.5 en el programa estadounidense de calificacinde tenis, NTRP) y un golfista con un handicap de un solo dgito. En su tiempo libre escribi dosnovelas, Aymara Bridge y The Puppeteer, y tiene planes para escribir una ms.vii 6. CONTENIDO BREVECAPTULO 1 El software y la ingeniera de software 1PARTE UNO EL PROCESO DEL SOFTWARE 25CAPTULO 2 Modelos del proceso 26CAPTULO 3 Desarrollo gil 55PARTE DOS MODELADO 81CAPTULO 4 Principios que guan la prctica 82CAPTULO 5 Comprensin de los requerimientos 101CAPTULO 6 Modelado de los requerimientos: escenarios, informacin y clases de anlisis 126CAPTULO 7 Modelado de los requerimientos: flujo, comportamiento, patrones y webapps 158CAPTULO 8 Conceptos de diseo 183CAPTULO 9 Diseo de la arquitectura 206CAPTULO 10 Diseo en el nivel de componentes 234CAPTULO 11 Diseo de la interfaz de usuario 265CAPTULO 12 Diseo basado en patrones 295CAPTULO 13 Diseo de webapps 317PARTE TRES ADMINISTRACIN DE LA CALIDAD 337CAPTULO 14 Conceptos de calidad 338CAPTULO 15 Tcnicas de revisin 354CAPTULO 16 Aseguramiento de la calidad del software 368CAPTULO 17 Estrategias de prueba de software 383CAPTULO 18 Prueba de aplicaciones convencionales 411CAPTULO 19 Prueba de aplicaciones orientadas a objetos 437CAPTULO 20 Prueba de aplicaciones web 453CAPTULO 21 Modelado y verificacin formal 478CAPTULO 22 Administracin de la configuracin del software 501CAPTULO 23 Mtricas de producto 526PARTE CUATRO ADMINISTRACIN DE PROYECTOS DE SOFTWARE 553CAPTULO 24 Conceptos de administracin de proyecto 554CAPTULO 25 Mtricas de proceso y de proyecto 571CAPTULO 26 Estimacin para proyectos de software 593CAPTULO 27 Calendarizacin del proyecto 620CAPTULO 28 Administracin del riesgo 640CAPTULO 29 Mantenimiento y reingeniera 655ix 7. x CONTENIDO BREVEPARTE CINCO TEMAS AVANZADOS 675CAPTULO 30 Mejoramiento del proceso de software 676CAPTULO 31 Tendencias emergentes en ingeniera del software 695CAPTULO 32 Comentarios finales 717APNDICE 1 Introduccin a UML 725APNDICE 2 Conceptos orientados a objeto 743REFERENCIAS 751NDICE ANALTICO 767 8. CONTENIDOPrefacio xxvCAPTULO 1 EL SOFTWARE Y LA INGENIERA DE SOFTWARE 11.1 La naturaleza del software 21.1.1 Definicin de software 31.1.2 Dominios de aplicacin del software 61.1.3 Software heredado 81.2 La naturaleza nica de las webapps 91.3 Ingeniera de software 101.4 El proceso del software 121.5 La prctica de la ingeniera de software 151.5.1 La esencia de la prctica 151.5.2 Principios generales 161.6 Mitos del software 181.7 Cmo comienza todo 201.8 Resumen 21PROBLEMAS Y PUNTOS POR EVALUAR 21LECTURAS ADICIONALES Y FUENTES DE INFORMACIN 22PARTE UNO EL PROCESO DEL SOFTWARE 25CAPTULO 2 MODELOS DEL PROCESO 262.1 Un modelo general de proceso 272.1.1 Definicin de actividad estructural 292.1.2 Identificacin de un conjunto de tareas 292.1.3 Patrones del proceso 292.2 Evaluacin y mejora del proceso 312.3 Modelos de proceso prescriptivo 332.3.1 Modelo de la cascada 332.3.2 Modelos de proceso incremental 352.3.3 Modelos de proceso evolutivo 362.3.4 Modelos concurrentes 402.3.5 Una ltima palabra acerca de los procesos evolutivos 422.4 Modelos de proceso especializado 432.4.1 Desarrollo basado en componentes 432.4.2 El modelo de mtodos formales 442.4.3 Desarrollo de software orientado a aspectos 442.5 El proceso unificado 452.5.1 Breve historia 462.5.2 Fases del proceso unificado 462.6 Modelos del proceso personal y del equipo 482.6.1 Proceso personal del software (PPS) 482.6.2 Proceso del equipo de software (PES) 492.7 Tecnologa del proceso 502.8 Producto y proceso 512.9 Resumen 52PROBLEMAS Y PUNTOS POR EVALUAR 53LECTURAS ADICIONALES Y FUENTES DE INFORMACIN 54xi 9. xii CONTENIDOCAPTULO 3 DESARROLLO GIL 553.1 Qu es la agilidad? 563.2 La agilidad y el costo del cambio 573.3 Qu es un proceso gil? 583.3.1 Principios de agilidad 583.3.2 La poltica del desarrollo gil 593.3.3 Factores humanos 603.4 Programacin extrema (XP) 613.4.1 Valores XP 613.4.2 El proceso XP 623.4.3 XP industrial 653.4.4 El debate XP 663.5 Otros modelos giles de proceso 673.5.1 Desarrollo adaptativo de software (DAS) 683.5.2 Scrum 693.5.3 Mtodo de desarrollo de sistemas dinmicos (MDSD) 713.5.4 Cristal 723.5.5 Desarrollo impulsado por las caractersticas (DIC) 723.5.6 Desarrollo esbelto de software (DES) 733.5.7 Modelado gil (MA) 743.5.8 El proceso unificado gil (PUA) 753.6 Conjunto de herramientas para el proceso gil 763.7 Resumen 77PROBLEMAS Y PUNTOS POR EVALUAR 78LECTURAS ADICIONALES Y FUENTES DE INFORMACIN 79PARTE DOS MODELADO 81CAPTULO 4 PRINCIPIOS QUE GUAN LA PRCTICA 824.1 Conocimiento de la ingeniera de software 834.2 Principios fundamentales 834.2.1 Principios que guan el proceso 844.2.2 Principios que guan la prctica 844.3 Principios que guan toda actividad estructural 864.3.1 Principios de comunicacin 864.3.2 Principios de planeacin 884.3.3 Principios de modelado 904.3.4 Principios de construccin 944.3.5 Principios de despliegue 964.4 Resumen 97PROBLEMAS Y PUNTOS POR EVALUAR 98LECTURAS Y FUENTES DE INFORMACIN ADICIONALES 99CAPTULO 5 COMPRENSIN DE LOS REQUERIMIENTOS 1015.1 Ingeniera de requerimientos 1025.2 Establecer las bases 1065.2.1 Identificacin de los participantes 1065.2.2 Reconocer los mltiples puntos de vista 1075.2.3 Trabajar hacia la colaboracin 1075.2.4 Hacer las primeras preguntas 1085.3 Indagacin de los requerimientos 1085.3.1 Recabacin de los requerimientos en forma colaborativa 1095.3.2 Despliegue de la funcin de calidad 1115.3.3 Escenarios de uso 1125.3.4 Indagacin de los productos del trabajo 112 10. CONTENIDO xiii5.4 Desarrollo de casos de uso 1135.5 Elaboracin del modelo de los requerimientos 1175.5.1 Elementos del modelo de requerimientos 1185.5.2 Patrones de anlisis 1205.6 Requerimientos de las negociaciones 1215.7 Validacin de los requerimientos 1225.8 Resumen 123PROBLEMAS Y PUNTOS POR EVALUAR 123LECTURAS ADICIONALES Y FUENTES DE INFORMACIN 124CAPTULO 6 MODELADO DE LOS REQUERIMIENTOS: ESCENARIOS,INFORMACIN Y CLASES DE ANLISIS 1266.1 Anlisis de los requerimientos 1276.1.1 Objetivos y filosofa general 1286.1.2 Reglas prcticas del anlisis 1286.1.3 Anlisis del dominio 1296.1.4 Enfoques del modelado de requerimientos 1306.2 Modelado basado en escenarios 1316.2.1 Creacin de un caso preliminar de uso 1326.2.2 Mejora de un caso de uso preliminar 1346.2.3 Escritura de un caso de uso formal 1356.3 Modelos UML que proporcionan el caso de uso 1376.3.1 Desarrollo de un diagrama de actividades 1376.3.2 Diagramas de canal (swimlane) 1386.4 Conceptos de modelado de datos 1396.4.1 Objetos de datos 1396.4.2 Atributos de los datos 1406.4.3 Relaciones 1416.5 Modelado basado en clases 1426.5.1 Identificacin de las clases de anlisis 1436.5.2 Especificacin de atributos 1456.5.3 Definicin de las operaciones 1466.5.4 Modelado clase-responsabilidad-colaborador (CRC) 1486.5.5 Asociaciones y dependencias 1526.5.6 Paquetes de anlisis 1546.6 Resumen 155PROBLEMAS Y PUNTOS POR EVALUAR 156LECTURAS ADICIONALES Y FUENTES DE INFORMACIN 157CAPTULO 7 MODELADO DE LOS REQUERIMIENTOS: FLUJO,COMPORTAMIENTO, PATRONES Y WEBAPPS 1587.1 Requerimientos que modelan las estrategias 1587.2 Modelado orientado al flujo 1597.2.1 Creacin de un modelo de flujo de datos 1597.2.2 Creacin de un modelo de flujo de control 1627.2.3 La especificacin de control 1627.2.4 La especificacin del proceso 1637.3 Creacin de un modelo de comportamiento 1657.3.1 Identificar los eventos con el caso de uso 1667.3.2 Representaciones de estado 1667.4 Patrones para el modelado de requerimientos 1697.4.1 Descubrimiento de patrones de anlisis 1697.4.2 Ejemplo de patrn de requerimientos: Actuador-Sensor 1707.5 Modelado de requerimientos para webapps 1747.5.1 Cunto anlisis es suficiente? 1747.5.2 Entrada del modelado de los requerimientos 174 11. xiv CONTENIDO7.5.3 Salida del modelado de los requerimientos 1757.5.4 Modelo del contenido de las webapps 1767.5.5 Modelo de la interaccin para webapps 1777.5.6 Modelo funcional para las webapps 1787.5.7 Modelos de configuracin para las webapps 1797.5.8 Modelado de la navegacin 1807.6 Resumen 180PROBLEMAS Y PUNTOS POR EVALUAR 181LECTURAS ADICIONALES Y FUENTES DE INFORMACIN 182CAPTULO 8 CONCEPTOS DE DISEO 1838.1 Diseo en el contexto de la ingeniera de software 1848.2 El proceso de diseo 1868.2.1 Lineamientos y atributos de la calidad del software 1868.2.2 La evolucin del diseo del software 1888.3 Conceptos de diseo 1898.3.1 Abstraccin 1898.3.2 Arquitectura 1908.3.3 Patrones 1918.3.4 Divisin de problemas 1918.3.5 Modularidad 1918.3.6 Ocultamiento de informacin 1928.3.7 Independencia funcional 1938.3.8 Refinamiento 1948.3.9 Aspectos 1948.3.10 Rediseo 1958.3.11 Conceptos de diseo orientados a objeto 1958.3.12 Clases de diseo 1968.4 El modelo del diseo 1978.4.1 Elementos del diseo de datos 1998.4.2 Elementos del diseo arquitectnico 1998.4.3 Elementos de diseo de la interfaz 1998.4.4 Elementos del diseo en el nivel de los componentes 2018.4.5 Elementos del diseo del despliegue 2028.5 Resumen 203PROBLEMAS Y PUNTOS POR EVALUAR 203LECTURAS ADICIONALES Y FUENTES DE INFORMACIN 204CAPTULO 9 DISEO DE LA ARQUITECTURA 2069.1 Arquitectura del software 2079.1.1 Qu es la arquitectura? 2079.1.2 Por qu es importante la arquitectura? 2089.1.3 Descripciones arquitectnicas 2089.1.4 Decisiones arquitectnicas 2099.2 Gneros arquitectnicos 2099.3 Estilos arquitectnicos 2119.3.1 Breve taxonoma de estilos de arquitectura 2139.3.2 Patrones arquitectnicos 2159.3.3 Organizacin y refinamiento 2169.4 Diseo arquitectnico 2179.4.1 Representacin del sistema en contexto 2179.4.2 Definicin de arquetipos 2189.4.3 Refinamiento de la arquitectura hacia los componentes 2199.4.4 Descripcin de las instancias del sistema 220 12. CONTENIDO xv9.5 Evaluacin de los diseos alternativos para la arquitectura 2219.5.1 Mtodo de la negociacin para analizar la arquitectura 2229.5.2 Complejidad arquitectnica 2249.5.3 Lenguajes de descripcin arquitectnica 2249.6 Mapeo de la arquitectura con el uso del flujo de datos 2259.6.1 Mapeo de transformacin 2259.6.2 Refinamiento del diseo arquitectnico 2319.7 Resumen 232PROBLEMAS Y PUNTOS POR EVALUAR 232LECTURAS ADICIONALES Y FUENTES DE INFORMACIN 233CAPTULO 10 DISEO EN EL NIVEL DE COMPONENTES 23410.1 Qu es un componente? 23510.1.1 Una visin orientada a objetos 23510.1.2 La visin tradicional 23610.1.3 Visin relacionada con el proceso 23910.2 Diseo de componentes basados en clase 23910.2.1 Principios bsicos del diseo 23910.2.2 Lineamientos de diseo en el nivel de componentes 24210.2.3 Cohesin 24310.2.4 Acoplamiento 24410.3 Realizacin del diseo en el nivel de componentes 24610.4 Diseo en el nivel de componentes para webapps 25110.4.1 Diseo del contenido en el nivel de componente 25110.4.2 Diseo de las funciones en el nivel de componentes 25210.5 Diseo de componentes tradicionales 25210.5.1 Notacin grfica de diseo 25310.5.2 Notacin del diseo tabular 25410.5.3 Lenguaje de diseo del programa 25510.6 Desarrollo basado en componentes 25610.6.1 Ingeniera del dominio 25710.6.2 Calificacin, adaptacin y combinacin de los componentes 25710.6.3 Anlisis y diseo para la reutilizacin 25910.6.4 Clasificacin y recuperacin de componentes 26010.7 Resumen 262PROBLEMAS Y PUNTOS POR EVALUAR 263LECTURAS ADICIONALES Y FUENTES DE INFORMACIN 263CAPTULO 11 DISEO DE LA INTERFAZ DE USUARIO 26511.1 Las reglas doradas 26611.1.1 Dejar el control al usuario 26611.1.2 Reducir la necesidad de que el usuario memorice 26711.1.3 Hacer consistente la interfaz 26811.2 Anlisis y diseo de la interfaz de usuario 26911.2.1 Anlisis y modelos del diseo de la interfaz 26911.2.2 El proceso 27111.3 Anlisis de la interfaz 27211.3.1 Anlisis del usuario 27211.3.2 Anlisis y modelado de la tarea 27311.3.3 Anlisis del contenido de la pantalla 27711.3.4 Anlisis del ambiente de trabajo 27811.4 Etapas del diseo de la interfaz 27811.4.1 Aplicacin de las etapas de diseo de la interfaz 27911.4.2 Patrones de diseo de la interfaz de usuario 28011.4.3 Aspectos del diseo 281 13. xvi CONTENIDO11.5 Diseo de una interfaz para webapps 28411.5.1 Principios y lineamientos del diseo de la interfaz 28511.5.2 Flujo de trabajos para el diseo de la interfaz de webapp 28911.6 Evaluacin del diseo 29011.7 Resumen 292PROBLEMAS Y PUNTOS POR EVALUAR 293LECTURAS ADICIONALES Y FUENTES DE INFORMACIN 293CAPTULO 12 DISEO BASADO EN PATRONES 29512.1 Patrones de diseo 29612.1.1 Clases de patrones 29712.1.2 Estructuras 29912.1.3 Descripcin de un patrn 29912.1.4 Lenguajes y repositorios de patrones 30012.2 Diseo de software basado en patrones 30112.2.1 El diseo basado en patrones, en contexto 30112.2.2 Pensar en patrones 30212.2.3 Tareas de diseo 30312.2.4 Construccin de una tabla para organizar el patrn 30512.2.5 Errores comunes en el diseo 30512.3 Patrones arquitectnicos 30612.4 Patrones de diseo en el nivel de componentes 30812.5 Patrones de diseo de la interfaz de usuario 31012.6 Patrones de diseo de webapp 31312.6.1 Centrarse en el diseo 31312.6.2 Granularidad del diseo 31412.7 Resumen 315PROBLEMAS Y PUNTOS POR EVALUAR 315LECTURAS ADICIONALES Y FUENTES DE INFORMACIN 316CAPTULO 13 DISEO DE WEBAPPS 31713.1 Calidad del diseo de webapps 31813.2 Metas del diseo 32013.3 Pirmide del diseo de webapps 32113.4 Diseo de la interfaz de la webapp 32113.5 Diseo de la esttica 32313.5.1 Aspectos de la distribucin 32313.5.2 Aspectos del diseo grfico 32413.6 Diseo del contenido 32413.6.1 Objetos de contenido 32413.6.2 Aspectos de diseo del contenido 32513.7 Diseo arquitectnico 32613.7.1 Arquitectura del contenido 32613.7.2 Arquitectura de las webapps 32813.8 Diseo de la navegacin 32913.8.1 Semntica de la navegacin 32913.8.2 Sintaxis de navegacin 33013.9 Diseo en el nivel de componentes 33113.10 Mtodo de diseo de hipermedios orientado a objetos (MDHOO) 33213.10.1 Diseo conceptual del MDHOO 33213.10.2 Diseo de la navegacin para el MDHOO 33313.10.3 Diseo abstracto de la interfaz y su implementacin 33313.11 Resumen 334PROBLEMAS Y PUNTOS POR EVALUAR 335LECTURAS ADICIONALES Y FUENTES DE INFORMACIN 335 14. CONTENIDO xviiPARTE TRES ADMINISTRACIN DE LA CALIDAD 337CAPTULO 14 CONCEPTOS DE CALIDAD 33814.1 Qu es calidad? 33914.2 Calidad del software 34014.2.1 Dimensiones de la calidad de Garvin 34114.2.2 Factores de la calidad de McCall 34214.2.3 Factores de la calidad ISO 9126 34314.2.4 Factores de calidad que se persiguen 34314.2.5 Transicin a un punto de vista cuantitativo 34414.3 El dilema de la calidad del software 34514.3.1 Software suficientemente bueno 34514.3.2 El costo de la calidad 34614.3.3 Riesgos 34814.3.4 Negligencia y responsabilidad 34814.3.5 Calidad y seguridad 34914.3.6 El efecto de las acciones de la administracin 34914.4 Lograr la calidad del software 35014.4.1 Mtodos de la ingeniera de software 35014.4.2 Tcnicas de administracin de proyectos 35014.4.3 Control de calidad 35114.4.4 Aseguramiento de la calidad 35114.5 Resumen 351PROBLEMAS Y PUNTOS POR EVALUAR 352LECTURAS Y FUENTES DE INFORMACIN ADICIONALES 352CAPTULO 15 TCNICAS DE REVISIN 35415.1 Efecto de los defectos del software en el costo 35515.2 Amplificacin y eliminacin del defecto 35615.3 Mtricas de revisin y su empleo 35715.3.1 Anlisis de las mtricas 35815.3.2 Eficacia del costo de las revisiones 35815.4 Revisiones: espectro de formalidad 35915.5 Revisiones informales 36115.6 Revisiones tcnicas formales 36215.6.1 La reunin de revisin 36315.6.2 Reporte y registro de la revisin 36315.6.3 Lineamientos para la revisin 36415.6.4 Revisiones orientadas al muestreo 36515.7 Resumen 366PROBLEMAS Y PUNTOS POR EVALUAR 367LECTURAS Y FUENTES DE INFORMACIN ADICIONALES 367CAPTULO 16 ASEGURAMIENTO DE LA CALIDAD DEL SOFTWARE 36816.1 Antecedentes 36916.2 Elementos de aseguramiento de la calidad del software 37016.3 Tareas, metas y mtricas del ACS 37116.3.1 Tareas del ACS 37116.3.2 Metas, atributos y mtricas 37216.4 Enfoques formales al ACS 37316.5 Aseguramiento estadstico de la calidad del software 37416.5.1 Ejemplo general 37416.5.2 Seis Sigma para la ingeniera de software 37516.6 Confiabilidad del software 37616.6.1 Mediciones de la confiabilidad y disponibilidad 37716.6.2 Seguridad del software 378 15. xviii CONTENIDO16.7 Las normas de calidad ISO 9000 37816.8 El plan de ACS 37916.9 Resumen 380PROBLEMAS Y PUNTOS POR EVALUAR 381LECTURAS Y FUENTES DE INFORMACIN ADICIONALES 381CAPTULO 17 ESTRATEGIAS DE PRUEBA DE SOFTWARE 38317.1 Un enfoque estratgico para la prueba de software 38417.1.1 Verificacin y validacin 38417.1.2 Organizacin de las pruebas del software 38517.1.3 Estrategia de prueba del software. Visin general 38617.1.4 Criterios para completar las pruebas 38817.2 Aspectos estratgicos 38817.3 Estrategias de prueba para software convencional 38917.3.1 Prueba de unidad 38917.3.2 Pruebas de integracin 39117.4 Estrategias de prueba para software orientado a objeto 39717.4.1 Prueba de unidad en el contexto OO 39717.4.2 Prueba de integracin en el contexto OO 39817.5 Estrategias de prueba para webapps 39817.6 Pruebas de validacin 39917.6.1 Criterios de pruebas de validacin 39917.6.2 Revisin de la configuracin 40017.6.3 Pruebas alfa y beta 40017.7 Pruebas del sistema 40117.7.1 Pruebas de recuperacin 40117.7.2 Pruebas de seguridad 40217.7.3 Pruebas de esfuerzo 40217.7.4 Pruebas de rendimiento 40317.7.5 Pruebas de despliegue 40317.8 El arte de la depuracin 40417.8.1 El proceso de depuracin 40417.8.2 Consideraciones psicolgicas 40517.8.3 Estrategias de depuracin 40617.8.4 Correccin del error 40817.9 Resumen 408PROBLEMAS Y PUNTOS POR EVALUAR 409LECTURAS Y FUENTES DE INFORMACIN ADICIONALES 409CAPTULO 18 PRUEBA DE APLICACIONES CONVENCIONALES 41118.1 Fundamentos de las pruebas del software 41218.2 Visiones interna y externa de las pruebas 41318.3 Prueba de caja blanca 41418.4 Prueba de ruta bsica 41418.4.1 Notacin de grfico o grafo de flujo 41518.4.2 Rutas de programa independientes 41618.4.3 Derivacin de casos de prueba 41818.4.4 Matrices de grafo 42018.5 Prueba de la estructura de control 42018.5.1 Prueba de condicin 42118.5.2 Prueba de flujo de datos 42118.5.3 Prueba de bucle 42118.6 Pruebas de caja negra 42318.6.1 Mtodos de prueba basados en grficos 42318.6.2 Particin de equivalencia 425 16. CONTENIDO xix18.6.3 Anlisis de valor de frontera 42518.6.4 Prueba de arreglo ortogonal 42618.7 Prueba basada en modelo 42918.8 Prueba para entornos, arquitecturas y aplicaciones especializados 42918.8.1 Pruebas de interfaces grficas de usuario 43018.8.2 Prueba de arquitecturas cliente-servidor 43018.8.3 Documentacin de prueba y centros de ayuda 43118.8.4 Prueba para sistemas de tiempo real 43218.9 Patrones para pruebas de software 43318.10 Resumen 434PROBLEMAS Y PUNTOS POR EVALUAR 435LECTURAS ADICIONALES Y FUENTES DE INFORMACIN 436CAPTULO 19 PRUEBA DE APLICACIONES ORIENTADAS A OBJETOS 43719.1 Ampliacin de la definicin de las pruebas 43819.2 Modelos de prueba AOO y DOO 43919.2.1 Exactitud de los modelos AOO y DOO 43919.2.2 Consistencia de los modelos orientados a objetos 43919.3 Estrategias de pruebas orientadas a objetos 44119.3.1 Prueba de unidad en el contexto OO 44119.3.2 Prueba de integracin en el contexto OO 44219.3.3 Prueba de validacin en un contexto OO 44219.4 Mtodos de prueba orientada a objetos 44219.4.1 Implicaciones del diseo de casos de prueba de los conceptos OO 44319.4.2 Aplicabilidad de los mtodos convencionales de diseo de casos de prueba 44319.4.3 Prueba basada en fallo 44419.4.4 Casos de prueba y jerarqua de clase 44419.4.5 Diseo de pruebas basadas en escenario 44519.4.6 Pruebas de las estructuras superficial y profunda 44619.5 Mtodos de prueba aplicables en el nivel clase 44719.5.1 Prueba aleatoria para clases OO 44719.5.2 Prueba de particin en el nivel de clase 44819.6 Diseo de casos de prueba interclase 44819.6.1 Prueba de clase mltiple 44919.6.2 Pruebas derivadas a partir de modelos de comportamiento 45019.7 Resumen 451PROBLEMAS Y PUNTOS POR EVALUAR 451LECTURAS ADICIONALES Y FUENTES DE INFORMACIN 452CAPTULO 20 PRUEBA DE APLICACIONES WEB 45320.1 Conceptos de pruebas para aplicaciones web 45320.1.1 Dimensiones de calidad 45420.1.2 Errores dentro de un entorno de webapp 45520.1.3 Estrategia de las pruebas 45520.1.4 Planificacin de pruebas 45620.2 Un panorama del proceso de prueba 45620.3 Prueba de contenido 45720.3.1 Objetivos de la prueba de contenido 45720.3.2 Prueba de base de datos 45820.4 Prueba de interfaz de usuario 46020.4.1 Estrategia de prueba de interfaz 46020.4.2 Prueba de mecanismos de interfaz 46120.4.3 Prueba de la semntica de la interfaz 46320.4.4 Pruebas de usabilidad 46320.4.5 Pruebas de compatibilidad 46520.5 Prueba en el nivel de componente 466 17. xx CONTENIDO20.6 Prueba de navegacin 46720.6.1 Prueba de sintaxis de navegacin 46720.6.2 Prueba de la semntica de navegacin 46820.7 Prueba de configuracin 46920.7.1 Conflictos en el lado servidor 46920.7.2 Conflictos en el lado cliente 47020.8 Prueba de seguridad 47020.9 Prueba de rendimiento 47120.9.1 Objetivos de la prueba de rendimiento 47220.9.2 Prueba de carga 47220.9.3 Prueba de esfuerzo 47320.10 Resumen 475PROBLEMAS Y PUNTOS POR EVALUAR 475LECTURAS ADICIONALES Y FUENTES DE INFORMACIN 476CAPTULO 21 MODELADO Y VERIFICACIN FORMAL 47821.1 Estrategia de cuarto limpio 47921.2 Especificacin funcional 48021.2.1 Especificacin de caja negra 48221.2.2 Especificacin de caja de estado 48221.2.3 Especificacin de caja clara 48321.3 Diseo de cuarto limpio 48321.3.1 Refinamiento de diseo 48321.3.2 Verificacin de diseo 48421.4 Pruebas de cuarto limpio 48521.4.1 Pruebas de uso estadstico 48621.4.2 Certificacin 48721.5 Conceptos de mtodos formales 48721.6 Aplicacin de notacin matemtica para especificacin formal 49021.7 Lenguajes de especificacin formal 49221.7.1 Lenguaje de restriccin de objeto (OCL) 49221.7.2 El lenguaje de especificacin Z 49521.8 Resumen 498PROBLEMAS Y PUNTOS POR EVALUAR 499LECTURAS ADICIONALES Y FUENTES DE INFORMACIN 500CAPTULO 22 ADMINISTRACIN DE LA CONFIGURACIN DEL SOFTWARE 50122.1 Administracin de la configuracin del software 50222.1.1 Un escenario ACS 50222.1.2 Elementos de un sistema de administracin de la configuracin 50322.1.3 Lneas de referencia 50422.1.4 tems de configuracin del software 50522.2 El repositorio ACS 50622.2.1 El papel del repositorio 50622.2.2 Caractersticas y contenido generales 50722.2.3 Caractersticas ACS 50722.3 El proceso ACS 50822.3.1 Identificacin de objetos en la configuracin del software 50922.3.2 Control de versin 51022.3.3 Control de cambio 51122.3.4 Auditora de configuracin 51422.3.5 Reporte de estado 51522.4 Administracin de la configuracin para webapps 51522.4.1 Conflictos dominantes 51622.4.2 Objetos de configuracin de webapps 51722.4.3 Administracin de contenido 517 18. CONTENIDO xxi22.4.4 Administracin del cambio 52022.4.5 Control de versin 52222.4.6 Auditora y reporte 52222.5 Resumen 523PROBLEMAS Y PUNTOS POR EVALUAR 524LECTURAS ADICIONALES Y FUENTES DE INFORMACIN 525CAPTULO 23 MTRICAS DE PRODUCTO 52623.1 Marco conceptual para las mtricas de producto 52723.1.1 Medidas, mtricas e indicadores 52723.1.2 El reto de la mtrica de producto 52723.1.3 Principios de medicin 52823.1.4 Medicin de software orientado a meta 52923.1.5 Atributos de las mtricas de software efectivas 53023.2 Mtricas para el modelo de requerimientos 53123.2.1 Mtrica basada en funciones 53123.2.2 Mtricas para calidad de la especificacin 53423.3 Mtricas para el modelo de diseo 53523.3.1 Mtricas del diseo arquitectnico 53523.3.2 Mtricas para diseo orientado a objetos 53723.3.3 Mtricas orientadas a clase: la suite de mtricas CK 53923.3.4 Mtricas orientadas a clase: La suite de mtricas MOOD 54123.3.5 Mtricas OO propuestas por Lorenz y Kidd 54223.3.6 Mtricas de diseo en el nivel de componente 54223.3.7 Mtricas orientadas a operacin 54423.3.8 Mtricas de diseo de interfaz de usuario 54523.4 Mtricas de diseo para webapps 54523.5 Mtricas para cdigo fuente 54723.6 Mtricas para pruebas 54823.6.1 Mtricas de Halstead aplicadas para probar 54923.6.2 Mtricas para pruebas orientadas a objetos 54923.7 Mtricas para mantenimiento 55023.8 Resumen 551PROBLEMAS Y PUNTOS POR EVALUAR 551LECTURAS Y FUENTES DE INFORMACIN ADICIONALES 552PARTE CUATRO ADMINISTRACIN DE PROYECTOS DE SOFTWARE 553CAPTULO 24 CONCEPTOS DE ADMINISTRACIN DE PROYECTO 55424.1 El espectro administrativo 55524.1.1 El personal 55524.1.2 El producto 55524.1.3 El proceso 55624.1.4 El proyecto 55624.2 El personal 55624.2.1 Los participantes 55724.2.2 Lderes de equipo 55724.2.3 El equipo de software 55824.2.4 Equipos giles 56124.2.5 Conflictos de coordinacin y comunicacin 56124.3 El producto 56224.3.1 mbito del software 56224.3.2 Descomposicin del problema 56324.4 El proceso 56324.4.1 Fusin de producto y proceso 56424.4.2 Descomposicin del proceso 564 19. xxii CONTENIDO24.5 El proyecto 56624.6 El principio W5HH 56724.7 Prcticas cruciales 56724.8 Resumen 568PROBLEMAS Y PUNTOS POR EVALUAR 569LECTURAS Y FUENTES DE INFORMACIN ADICIONALES 569CAPTULO 25 MTRICAS DE PROCESO Y DE PROYECTO 57125.1 Mtricas en los dominios de proceso y proyecto 57225.1.1 Las mtricas del proceso y la mejora del proceso de software 57225.1.2 Mtricas de proyecto 57425.2 Medicin del software 57525.2.1 Mtricas orientadas a tamao 57625.2.2 Mtricas orientadas a funcin 57725.2.3 Reconciliacin de mtricas LOC y PF 57725.2.4 Mtricas orientadas a objeto 57925.2.5 Mtricas orientadas a caso de uso 58025.2.6 Mtricas de proyecto webapp 58025.3 Mtricas para calidad de software 58225.3.1 Medicin de la calidad 58325.3.2 Eficiencia en la remocin del defecto 58425.4 Integracin de mtricas dentro del proceso de software 58525.4.1 Argumentos para mtricas de software 58525.4.2 Establecimiento de una lnea de referencia 58625.4.3 Recoleccin, clculo y evaluacin de mtricas 58625.5 Mtricas para organizaciones pequeas 58725.6 Establecimiento de un programa de mtricas del software 58825.7 Resumen 590PROBLEMAS Y PUNTOS POR EVALUAR 590LECTURAS Y FUENTES DE INFORMACIN ADICIONALES 591CAPTULO 26 ESTIMACIN PARA PROYECTOS DE SOFTWARE 59326.1 Observaciones acerca de las estimaciones 59426.2 El proceso de planificacin del proyecto 59526.3 mbito y factibilidad del software 59526.4 Recursos 59626.4.1 Recursos humanos 59626.4.2 Recursos de software reutilizables 59726.4.3 Recursos ambientales 59826.5 Estimacin de proyectos de software 59826.6 Tcnicas de descomposicin 59926.6.1 Dimensionamiento del software 59926.6.2 Estimacin basada en problema 60026.6.3 Un ejemplo de estimacin basada en LOC 60126.6.4 Un ejemplo de estimacin basada en PF 60226.6.5 Estimacin basada en proceso 60426.6.6 Un ejemplo de estimacin basada en proceso 60526.6.7 Estimacin con casos de uso 60526.6.8 Un ejemplo de estimacin basada en caso de uso 60626.6.9 Reconciliacin de estimaciones 60726.7 Modelos de estimacin empricos 60826.7.1 La estructura de los modelos de estimacin 60826.7.2 El modelo COCOMO II 60926.7.3 La ecuacin del software 610 20. CONTENIDO xxiii26.8 Estimacin para proyectos orientados a objetos 61126.9 Tcnicas de estimacin especializadas 61226.9.1 Estimacin para desarrollo gil 61226.9.2 Estimacin para webapp 61326.10 La decisin hacer/comprar 61426.10.1 Creacin de un rbol de decisin 61526.10.2 Outsourcing 61626.11 Resumen 617PROBLEMAS Y PUNTOS POR EVALUAR 617LECTURAS Y FUENTES DE INFORMACIN ADICIONALES 618CAPTULO 27 CALENDARIZACIN DEL PROYECTO 62027.1 Conceptos bsicos 62127.2 Calendarizacin del proyecto 62227.2.1 Principios bsicos 62327.2.2 Relacin entre personal y esfuerzo 62427.2.3 Distribucin de esfuerzo 62527.3 Definicin de un conjunto de tareas para el proyecto de software 62627.3.1 Un ejemplo de conjunto de tareas 62727.3.2 Refinamiento de acciones de ingeniera del software 62727.4 Definicin de una red de tareas 62827.5 Calendarizacin 62927.5.1 Cronogramas 62927.5.2 Seguimiento del calendario 63127.5.3 Seguimiento del progreso para un proyecto OO 63227.5.4 Calendarizacin para proyectos webapp 63327.6 Anlisis de valor ganado 63527.7 Resumen 637PROBLEMAS Y PUNTOS POR EVALUAR 637LECTURAS Y FUENTES DE INFORMACIN ADICIONALES 638CAPTULO 28 ADMINISTRACIN DEL RIESGO 64028.1 Estrategias reactivas de riesgo frente a estrategias proactivas de riesgo 64128.2 Riesgos de software 64128.3 Identificacin de riesgos 64228.3.1 Valoracin del riesgo de proyecto global 64328.3.2 Componentes y promotores de riesgo 64428.4 Proyeccin del riesgo 64428.4.1 Elaboracin de una lista de riesgos 64528.4.2 Valoracin de impacto de riesgo 64728.5 Refinamiento del riesgo 64928.6 Mitigacin, monitoreo y manejo de riesgo 64928.7 El plan MMMR 65128.8 Resumen 652PROBLEMAS Y PUNTOS POR EVALUAR 653LECTURAS Y FUENTES DE INFORMACIN ADICIONALES 653CAPTULO 29 MANTENIMIENTO Y REINGENIERA 65529.1 Mantenimiento de software 65629.2 Soportabilidad del software 65729.3 Reingenera 65829.4 Reingeniera de procesos de empresa 65829.4.1 Procesos empresariales 65929.4.2 Un modelo RPE 659 21. xxiv CONTENIDO29.5 Reingeniera de software 66129.5.1 Un modelo de proceso de reingeniera de software 66129.5.2 Actividades de reingeniera de software 66229.6 Ingeniera inversa 66429.6.1 Ingeniera inversa para comprender datos 66529.6.2 Ingeniera inversa para entender el procesamiento 66629.6.3 Ingeniera inversa de interfaces de usuario 66729.7 Reestructuracin 66829.7.1 Reestructuracin de cdigo 66829.7.2 Reestructuracin de datos 66829.8 Ingeniera hacia adelante 66929.8.1 Ingeniera hacia adelante para arquitecturas cliente-servidor 67029.8.2 Ingeniera hacia adelante para arquitecturas orientadas a objetos 67129.9 Economa de la reingeniera 67129.10 Resumen 672PROBLEMAS Y PUNTOS POR EVALUAR 673LECTURAS Y FUENTES DE INFORMACIN ADICIONALES 674PARTE CINCO TEMAS AVANZADOS 675CAPTULO 30 MEJORAMIENTO DEL PROCESO DE SOFTWARE 67630.1 Qu es mps? 67730.1.1 Enfoques del MPS 67730.1.2 Modelos de madurez 67930.1.3 El MPS es para todos? 68030.2 El proceso MPS 68030.2.1 Valoracin y anlisis de la desviacin 68130.2.2 Educacin y capacitacin 68230.2.3 Seleccin y justificacin 68230.2.4 Instalacin/migracin 68330.2.5 Evaluacin 68330.2.6 Gestin del riesgo para MPS 68430.2.7 Factores de xito cruciales 68530.3 El CMMI 68530.4 El CMM de personal 68830.5 Otros marcos conceptuales MPS 68930.6 Rendimiento sobre inversin de MPS 69130.7 Tendencias MPS 69230.8 Resumen 693PROBLEMAS Y PUNTOS POR EVALUAR 693LECTURAS Y FUENTES DE INFORMACIN ADICIONALES 694CAPTULO 31 TENDENCIAS EMERGENTES EN INGENIERA DEL SOFTWARE 69531.1 Evolucin tecnolgica 69631.2 Observacin de las tendencias en ingeniera del software 69731.3 Identificacin de tendencias blandas 69931.3.1 Administracin de la complejidad 70031.3.2 Software de mundo abierto 70131.3.3 Requerimientos emergentes 70131.3.4 La mezcla de talento 70231.3.5 Bloques constructores de software 70331.3.6 Cambio de percepciones de valor 70331.3.7 Fuente abierta 70331.4 Direcciones de la tecnologa 70431.4.1 Tendencias de proceso 70531.4.2 El gran desafo 706 22. CONTENIDO xxv31.4.3 Desarrollo colaborativo 70731.4.4 Ingeniera de requerimientos 70831.4.5 Desarrollo de software impulsado por modelo 70931.4.6 Diseo posmoderno 71031.4.7 Desarrollo impulsado por pruebas 71031.5 Tendencias relacionadas con herramientas 71131.5.1 Herramientas que responden a tendencias blandas 71231.5.2 Herramientas que abordan tendencias tecnolgicas 71431.6 Resumen 714PROBLEMAS Y PUNTOS POR EVALUAR 715LECTURAS Y FUENTES DE INFORMACIN ADICIONALES 715CAPTULO 32 COMENTARIOS FINALES 71732.1 La importancia del software-revisin 71832.2 Las personas y la forma en la que construyen sistemas 71832.3 Nuevos modos para representar la informacin 71932.4 La vista larga 72032.5 La responsabilidad del ingeniero de software 72132.6 Un comentario final 722APNDICE 1 Introduccin a UML 725APNDICE 2 Conceptos orientados a objeto 743REFERENCIAS 751NDICE ANALTICO 767 23. PREFACIOCuando el software de computadora triunfa (al satisfacer las necesidades de las personasque lo usan, trabajar sin fallos durante largos periodos, ser fcil de modificar e inclusoms fcil de usar) puede y debe cambiar las cosas a fin de mejorar. Pero cuando el soft-warefracasa (cuando sus usuarios no estn satisfechos, es proclive al error, es difcil de cambiare incluso ms difcil de usar) pueden ocurrir, y ocurren, cosas malas. Todo mundo quiere cons-truirsoftware que haga mejor las cosas y que evite las malas que acechan en la sombra de losesfuerzos fallidos. Para triunfar, se necesita disciplina al momento de disear y construir elsoftware. Es necesario un enfoque de ingeniera.Han pasado casi tres dcadas desde que se escribi la primera edicin de este libro. Duranteese tiempo, la ingeniera del software evolucion desde una oscura idea practicada por un n-merorelativamente pequeo de fanticos hasta una legtima disciplina de la ingeniera. En laactualidad, se le reconoce como una materia merecedora de investigacin seria, estudio con-cienzudoy debate turbulento. A lo largo de toda la industria, el ingeniero de software sustituyal programador como el ttulo laboral de preferencia. Los modelos de proceso de software, losmtodos de ingeniera de software y las herramientas del software se adoptaron exitosamentea travs de un amplio espectro de segmentos industriales.Aunque los gestores y profesionales reconocen por igual la necesidad de un enfoque delsoftware ms disciplinado, continan debatiendo la forma en la que la disciplina debe aplicarse.Muchos individuos y compaas todava desarrollan el software de manera fortuita, inclusocuando construyen sistemas para atender las tecnologas ms avanzadas de la actualidad. Mu-chosprofesionales y estudiantes no estn conscientes de los mtodos modernos. Como resul-tado,la calidad del software que producen es deficiente y ocurren cosas malas. Adems, conti-nael debate y la controversia en torno de la verdadera naturaleza del enfoque de la ingenieradel software. El estatus de la ingeniera del software es un estudio en contrastes. Las actitudeshan cambiado, se ha progresado, pero todava falta mucho por hacer antes de que la disciplinaalcance madurez plena.La sptima edicin de Ingeniera del software: un enfoque prctico tiene la intencin de funcio-narcomo gua hacia una disciplina de ingeniera que madura. Como las seis ediciones que laprecedieron, la sptima se dirige a estudiantes y profesionales, y conserva su atractivo comogua para el profesional industrial y como introduccin abarcadora para el estudiante en losniveles superiores de pregrado o en el primer ao de graduado.La sptima edicin es considerablemente ms que una simple actualizacin. El libro se revisy reestructur para mejorar el flujo pedaggico y enfatizar nuevos e importantes procesos yprcticas de la ingeniera del software. Adems, este texto cuenta con un paquete de comple-mentos,los cuales estn disponibles para los profesores que lo adopten. Consulte con el repre-sentantede McGraw-Hill local.La sptima edicin. Los 32 captulos de la sptima edicin se reorganizaron en cinco partes.Esta organizacin, que difiere considerablemente de la sexta edicin, se realiz para dividirmejor los temas y ayudar a los profesores que tal vez no tengan tiempo para completar todo ellibro en un semestre.La parte 1, El proceso, presenta varias visiones diferentes del proceso de software, consideratodos los modelos de proceso importantes y aborda el debate entre las filosofas de procesoxxvii 24. xxviii PREFACIOprescriptivo y gil. La parte 2, Modelado, presenta los mtodos de anlisis y diseo con nfasisen las tcnicas orientadas a objeto y al modelado UML. Tambin se considera el diseo basa-doen patrn y el diseo para aplicaciones web. La parte 3, Gestin de la calidad, presenta losconceptos, procedimientos, tcnicas y mtodos que permiten a un equipo de software valorarla calidad del software, revisar los productos de trabajo de la ingeniera del software, realizarprocedimientos SQA y aplicar una estrategia y tcticas de prueba efectivas. Adems, tambin seconsidera el modelado formal y los mtodos de verificacin. La parte 4, Gestin de proyectos desoftware, presenta temas que son relevantes a quienes planean, gestionan y controlan un pro-yectode desarrollo de software. La parte 5, Temas avanzados, considera el mejoramiento delproceso de software y las tendencias en la ingeniera del software. Al continuar con la tradicinde las ediciones pasadas, a lo largo del libro se usa una serie de recuadros para presentar lasexperiencias y tribulaciones de un equipo de software (ficticio) y para proporcionar materialescomplementarios acerca de los mtodos y herramientas que son relevantes para los temas delcaptulo. Dos nuevos apndices proporcionan breves tutoriales acerca del UML y del pensa-mientoorientado a objeto para quienes no estn familiarizados con estos importantes temas.La organizacin en cinco partes de la sptima edicin permite al profesor englobar los te-mascon base en el tiempo disponible y las necesidades del estudiante. Un curso de todo unsemestre podra construirse en torno de uno o ms de las cinco partes. Uno de evaluacin deingeniera del software seleccionara captulos de las cinco. Uno de ingeniera del software queenfatice el anlisis y el diseo elegira temas de las partes 1 y 2. Un curso de ingeniera del soft-wareorientado a pruebas seleccionara temas de las partes 1 y 3, con una breve incursin en laparte 2. Un curso administrativo subrayara las partes 1 y 4.Reconocimientos. Mi trabajo en las siete ediciones de Ingeniera del software: un enfoque prc-ticoha sido el proyecto tcnico continuo ms largo de mi vida. Aun cuando la escritura ces, lainformacin extrada de la literatura tcnica contina asimilndose y organizndose, y las crti-casy sugerencias de los lectores en todo el mundo se evalan y catalogan. Por esta razn,agradezco a los muchos autores de libros, ponencias y artculos (tanto en copia dura como enmedios electrnicos) que me han proporcionado comprensin, ideas y comentarios adicionalesdurante casi 30 aos.Agradezco especialmente a Tim Lethbridge, de la Universidad de Ottawa, quien me auxilien el desarrollo de los ejemplos UML y OCL, y quien desarroll el estudio de caso que acompaaa este libro, y a Dale Skrien, de Colby College, quien desarroll el tutorial UML en el apndice 1.Su asistencia y sus comentarios fueron invaluables. Un agradecimiento especial tambin paraBruce Maxim, de la Universidad de Michigan-Dearborn, quien me auxili en el desarrollo degran parte del contenido pedaggico en el sitio web que acompaa a este libro. Finalmente,quiero agradecer a los revisores de la sptima edicin: sus comentarios a profundidad y crticasbien pensadas han sido invaluables.Osman Balci,Virginia Tech UniversityMax Fomitchev,Penn State UniversityJerry (Zeyu) Gao,San Jose State UniversityGuillermo Garcia,Universidad Alfonso X MadridPablo Gervas,Universidad Complutense de MadridSK Jain,National Institute of Technology HamirpurSaeed Monemi,Cal Poly PomonaAhmed Salem,California State UniversityVasudeva Varma,IIIT HyderabadEl contenido de la sptima edicin de Ingeniera del software: un enfoque prctico fue confor-madopor profesionales de la industria, profesores universitarios y estudiantes, quienes usaronediciones anteriores del libro y tomaron tiempo para comunicar sus sugerencias, crticas e ideas. 25. PREFACIO xxixMi agradecimiento a cada uno de ustedes. Adems, mi reconocimiento personal a nuestrosmuchos clientes industriales en todo el mundo, quienes, ciertamente, me ensearon tanto o msde lo que yo podra haberles enseado en algn momento.Conforme las ediciones de este libro evolucionaban, mis hijos, Mathew y Michael, crecieronde nios a hombres. Su madurez, carcter y xito en el mundo real han sido una inspiracinpara m. Nada me ha llenado ms de orgullo. Y finalmente, a Brbara, mi amor y agradecimientopor tolerar las muchsimas horas en la oficina y por alentar todava otra edicin de el libro.Roger S. Pressman 26. CAPTULO1EL SOFTWARE Y LA INGENIERA 1DE SOFTWARECONCEPTOS CLAVEactividades estructurales . . . . 12actividades sombrilla. . . . . . . 12caractersticas del software . . . 3dominios de aplicacin . . . . . . . 6ingeniera de software . . . . . 10mitos del software . . . . . . . . 18prctica . . . . . . . . . . . . . . . . 15principios . . . . . . . . . . . . . . . 16proceso del software. . . . . . . 12software heredado . . . . . . . . . 8webapps . . . . . . . . . . . . . . . . 9Qu es? El software de computadora es elproducto que construyen los programadoresprofesionales y al que despus le dan manteni-mientodurante un largo tiempo. Incluye pro-gramasque se ejecutan en una computadora de cual-quiertamao y arquitectura, contenido que se presenta amedida de que se ejecutan los programas de cmputo einformacin descriptiva tanto en una copia dura como enformatos virtuales que engloban virtualmente a cualesquie-ramedios electrnicos. La ingeniera de software est for-madapor un proceso, un conjunto de mtodos (prcticas)y un arreglo de herramientas que permite a los profesiona-leselaborar software de cmputo de alta calidad.Quin lo hace? Los ingenieros de software elaboran ydan mantenimiento al software, y virtualmente cada perso-nalo emplea en el mundo industrializado, ya sea en formadirecta o indirecta.Por qu es importante? El software es importante por-queafecta a casi todos los aspectos de nuestras vidas y hainvadido nuestro comercio, cultura y actividades cotidia-nas.La ingeniera de software es importante porque nospermite construir sistemas complejos en un tiempo razona-bley con alta calidad.Cules son los pasos? El software de computadora seconstruye del mismo modo que cualquier producto exitoso,con la aplicacin de un proceso gil y adaptable paraobtener un resultado de mucha calidad, que satisfaga lasnecesidades de las personas que usarn el producto. Enestos pasos se aplica el enfoque de la ingeniera de soft-ware.Cul es el producto final? Desde el punto de vista deun ingeniero de software, el producto final es el conjuntode programas, contenido (datos) y otros productos termi-nadosque constituyen el software de computadora. Perodesde la perspectiva del usuario, el producto final es lainformacin resultante que de algn modo hace mejor almundo en el que vive.Cmo me aseguro de que lo hice bien? Lea el restode este libro, seleccione aquellas ideas que sean aplicablesal software que usted hace y aplquelas a su trabajo.UNAMIRADARPIDATena la apariencia clsica de un alto ejecutivo de una compaa importante de softwarea la mitad de los 40, con las sienes comenzando a encanecer, esbelto y atltico, conojos que penetraban al observador mientras hablaba. Pero lo que dijo me dej anona-dado.El software ha muerto.Pestae con sorpresa y sonre. Bromeas, verdad? El mundo es dirigido con software y tuempresa se ha beneficiado mucho de ello. No ha muerto! Est vivo y en desarrollo.Movi su cabeza de manera enftica. No, est muerto al menos como lo conocimos.Me apoy en el escritorio. Contina.Habl al tiempo que golpeaba en la mesa con nfasis. El concepto antiguo del software locompras, lo posees y tu trabajo consiste en administrarlo est llegando a su fin. Hoy da, conWeb 2.0 y la computacin ubicua cada vez ms fuerte, vamos a ver una generacin de softwarepor completo diferente. Se distribuir por internet y se ver exactamente como si estuviera ins-taladoen el equipo de cmputo de cada usuario pero se encontrar en un servidor remoto.Tuve que estar de acuerdo. Entonces, tu vida ser mucho ms sencilla. Tus muchachos notendrn que preocuparse por las cinco diferentes versiones de la misma App que utilizan dece-nasde miles de usuarios.Sonri. Absolutamente. Slo la versin ms reciente estar en nuestros servidores. Cuandohagamos un cambio o correccin, actualizaremos funcionalidad y contenido a cada usuario.Todos lo tendrn en forma instantneaHice una mueca. Pero si cometes un error, todos lo tendrn tambin instantneamente.l se ri entre dientes. Es verdad, por eso estamos redoblando nuestros esfuerzos para haceruna ingeniera de software an mejor. El problema es que tenemos que hacerlo rpido porqueel mercado se ha acelerado en cada rea de aplicacin. 27. 2 CAPTULO 1 EL SOFTWARE Y LA INGENIERA DE SOFTWAREMe recargu en la espalda y coloqu mis manos en mi nuca. Ya sabes lo que se dice pue-destenerlo rpido o bien hecho o barato. Escoge dos de estas caractersticasElijo rpido y bien hecho, dijo mientras comenzaba a levantarse.Tambin me incorpor. Entonces realmente necesitas ingeniera de software.Ya lo s, dijo mientras sala. El problema es que tenemos que llegar a convencer a otrageneracin ms de tcnicos de que as esEst muerto realmente el software? Si lo estuviera, usted no estara leyendo este libroEl software de computadora sigue siendo la tecnologa ms importante en la escena mundial.Y tambin es un ejemplo magnfico de la ley de las consecuencias inesperadas. Hace 50 aos,nadie hubiera podido predecir que el software se convertira en una tecnologa indispensablepara los negocios, ciencias e ingeniera, ni que permitira la creacin de tecnologas nuevas (porejemplo, ingeniera gentica y nanotecnologa), la ampliacin de tecnologas ya existentes (te-lecomunicaciones)y el cambio radical de tecnologas antiguas (la industria de la impresin);tampoco que el software sera la fuerza que impulsara la revolucin de las computadoras per-sonales,que productos de software empacados se compraran en los supermercados, que elsoftware evolucionara poco a poco de un producto a un servicio cuando compaas de softwaresobre pedido proporcionaran funcionalidad justo a tiempo a travs de un navegador web, queuna compaa de software sera ms grande y tendra ms influencia que casi todas las empre-sasde la era industrial, que una vasta red llamada internet sera operada con software y evolu-cionaray cambiara todo, desde la investigacin en bibliotecas y la compra de productos parael consumidor hasta el discurso poltico y los hbitos de encuentro de los adultos jvenes (y notan jvenes).Nadie pudo prever que habra software incrustado en sistemas de toda clase: de transporte,mdicos, de telecomunicaciones, militares, industriales, de entretenimiento, en mquinas deoficina la lista es casi infinita. Y si usted cree en la ley de las consecuencias inesperadas, haymuchos efectos que an no podemos predecir.Nadie poda anticipar que millones de programas de computadora tendran que ser corregi-dos,adaptados y mejorados a medida que transcurriera el tiempo. Ni que la carga de ejecutarestas actividades de mantenimiento absorbera ms personas y recursos que todo el trabajoaplicado a la creacin de software nuevo.Conforme ha aumentado la importancia del software, la comunidad de programadores hatratado continuamente de desarrollar tecnologas que hagan ms fcil, rpida y barata la elabo-racinde programas de cmputo de alta calidad. Algunas de estas tecnologas se dirigen a undominio especfico de aplicaciones (por ejemplo, diseo e implantacin de un sitio web), otrasse centran en un dominio tecnolgico (sistemas orientados a objetos o programacin orientadaa aspectos), otros ms tienen una base amplia (sistemas operativos, como Linux). Sin embargo,todava falta por desarrollarse una tecnologa de software que haga todo esto, y hay pocas pro-babilidadesde que surja una en el futuro. A pesar de ello, las personas basan sus trabajos,confort, seguridad, diversiones, decisiones y sus propias vidas en software de computadora. Msvale que est bien hecho.Este libro presenta una estructura que puede ser utilizada por aquellos que hacen softwarede cmputo personas que deben hacerlo bien. La estructura incluye un proceso, un conjuntode mtodos y unas herramientas que llamamos ingeniera de software.1.1 LA NATURALEZA DEL SOFTWAREEn la actualidad, el software tiene un papel dual. Es un producto y al mismo tiempo es el ve-hculopara entregar un producto. En su forma de producto, brinda el potencial de cmputo in-corporadoen el hardware de cmputo o, con ms amplitud, en una red de computadoras a lasCita:Las ideas y los descubrimientostecnolgicos son los motores queimpulsan el crecimiento econ-mico.Wall Street Journal 28. CAPTULO 1 EL SOFTWARE Y LA INGENIERA DE SOFTWARE 3que se accede por medio de un hardware local. Ya sea que resida en un telfono mvil u opereen el interior de una computadora central, el software es un transformador de informacinproduce, administra, adquiere, modifica, despliega o transmite informacin que puede ser tansimple como un solo bit o tan compleja como una presentacin con multimedios generada apartir de datos obtenidos de decenas de fuentes independientes. Como vehculo utilizado paradistribuir el producto, el software acta como la base para el control de la computadora (siste-masoperativos), para la comunicacin de informacin (redes) y para la creacin y control deotros programas (herramientas y ambientes de software).El software distribuye el producto ms importante de nuestro tiempo: informacin. Trans-formalos datos personales (por ejemplo, las transacciones financieras de un individuo) de modoque puedan ser ms tiles en un contexto local, administra la informacin de negocios paramejorar la competitividad, provee una va para las redes mundiales de informacin (la internet)y brinda los medios para obtener informacin en todas sus formas.En el ltimo medio siglo, el papel del software de cmputo ha sufrido un cambio significativo.Las notables mejoras en el funcionamiento del hardware, los profundos cambios en las arqui-tecturasde computadora, el gran incremento en la memoria y capacidad de almacenamiento, yuna amplia variedad de opciones de entradas y salidas exticas han propiciado la existencia desistemas basados en computadora ms sofisticados y complejos. Cuando un sistema tiene xito,la sofisticacin y complejidad producen resultados deslumbrantes, pero tambin plantean pro-blemasenormes para aquellos que deben construir sistemas complejos.En la actualidad, la enorme industria del software se ha convertido en un factor dominanteen las economas del mundo industrializado. Equipos de especialistas de software, cada unocentrado en una parte de la tecnologa que se requiere para llegar a una aplicacin compleja,han reemplazado al programador solitario de los primeros tiempos. A pesar de ello, las pregun-tasque se haca aquel programador son las mismas que surgen cuando se construyen sistemasmodernos basados en computadora:1 Por qu se requiere tanto tiempo para terminar el software? Por qu son tan altos los costos de desarrollo? Por qu no podemos detectar todos los errores antes de entregar el software a nuestrosclientes? Por qu dedicamos tanto tiempo y esfuerzo a mantener los programas existentes? Por qu seguimos con dificultades para medir el avance mientras se desarrolla ymantiene el software?stas y muchas otras preguntas, denotan la preocupacin sobre el software y la manera enque se desarrolla, preocupacin que ha llevado a la adopcin de la prctica de la ingeniera delsoftware.1.1.1 Definicin de softwareEn la actualidad, la mayora de profesionales y muchos usuarios tienen la fuerte sensacin deque entienden el software. Pero, es as?La descripcin que dara un libro de texto sobre software sera ms o menos as:El software es: 1) instrucciones (programas de cmputo) que cuando se ejecutan proporcionan lascaractersticas, funcin y desempeo buscados; 2) estructuras de datos que permiten que los progra-PUNTOCLAVEEl software es tanto un productocomo un vehculo para entregar unproducto.Cita:El software es un lugar dondese siembran sueos y se cose-chanpesadillas, una cinegaabstracta y mstica en la queterribles demonios luchan contrapanaceas mgicas, un mundo dehombres lobo y balas de plata.Brad J. Cox1 En un excelente libro de ensayos sobre el negocio del software, Tom DeMarco [DeM95] defiende el punto de vistacontrario. Dice: En lugar de preguntar por qu el software cuesta tanto, necesitamos comenzar a preguntar:Qu hemos hecho para hacer posible que el software actual cueste tan poco? La respuesta a esa pregunta nosayudar a continuar el extraordinario nivel de logro que siempre ha distinguido a la industria del software.Cmo se definesoftware? ? 29. 4 CAPTULO 1 EL SOFTWARE Y LA INGENIERA DE SOFTWAREmas manipulen en forma adecuada la informacin, y 3) informacin descriptiva tanto en papel comoen formas virtuales que describen la operacin y uso de los programas.No hay duda de que podran darse definiciones ms completas.Pero es probable que una definicin ms formal no mejore de manera apreciable nuestracomprensin. Para asimilar lo anterior, es importante examinar las caractersticas del softwareque lo hacen diferente de otros objetos que construyen los seres humanos. El software es ele-mentode un sistema lgico y no de uno fsico. Por tanto, tiene caractersticas que difieren con-siderablementede las del hardware:1. El software se desarrolla o modifica con intelecto; no se manufactura en el sentido clsico.Aunque hay algunas similitudes entre el desarrollo de software y la fabricacin de hard-ware,las dos actividades son diferentes en lo fundamental. En ambas, la alta calidad selogra a travs de un buen diseo, pero la fase de manufactura del hardware introduceproblemas de calidad que no existen (o que se corrigen con facilidad) en el software.Ambas actividades dependen de personas, pero la relacin entre los individuos dedica-dosy el trabajo logrado es diferente por completo (vase el captulo 24). Las dos activi-dadesrequieren la construccin de un producto, pero los enfoques son distintos. Loscostos del software se concentran en la ingeniera. Esto significa que los proyectos desoftware no pueden administrarse como si fueran proyectos de manufactura.2. El software no se desgasta.La figura 1.1 ilustra la tasa de falla del hardware como funcin del tiempo. La relacin,que es frecuente llamar curva de tina, indica que el hardware presenta una tasa de fa-llasrelativamente elevada en una etapa temprana de su vida (fallas que con frecuenciason atribuibles a defectos de diseo o manufactura); los defectos se corrigen y la tasade fallas se abate a un nivel estable (muy bajo, por fortuna) durante cierto tiempo. Noobstante, conforme pasa el tiempo, la tasa de fallas aumenta de nuevo a medida que loscomponentes del hardware resienten los efectos acumulativos de suciedad, vibracin,abuso, temperaturas extremas y muchos otros inconvenientes ambientales. En pocaspalabras, el hardware comienza a desgastarse.El software no es susceptible a los problemas ambientales que hacen que el hard-warese desgaste. Por tanto, en teora, la curva de la tasa de fallas adopta la forma de lacurva idealizada que se aprecia en la figura 1.2. Los defectos ocultos ocasionarn ta-PUNTOCLAVEEl software se modifica con intelecto,no se manufactura.Mortalidad DesgasteinfantilTiempoTasa de fallaPUNTOCLAVEEl software no se desgasta, pero sse deteriora.FIGURA 1.1Curva de fallasdel hardware 30. CAPTULO 1 EL SOFTWARE Y LA INGENIERA DE SOFTWARE 5sas elevadas de fallas al comienzo de la vida de un programa. Sin embargo, stas se co-rrigeny la curva se aplana, como se indica. La curva idealizada es una gran simplifica-cinde los modelos reales de las fallas del software. Aun as, la implicacin est clara:el software no se desgasta, pero s se deteriora!Esta contradiccin aparente se entiende mejor si se considera la curva real en la fi-gura1.2. Durante su vida,2 el software sufrir cambios. Es probable que cuando stos serealicen, se introduzcan errores que ocasionen que la curva de tasa de fallas tenga au-mentossbitos, como se ilustra en la curva real (vase la figura 1.2). Antes de que lacurva vuelva a su tasa de fallas original de estado estable, surge la solicitud de otrocambio que hace que la curva se dispare otra vez. Poco a poco, el nivel mnimo de latasa de fallas comienza a aumentar: el software se est deteriorando como consecuen-ciadel cambio.Otro aspecto del desgaste ilustra la diferencia entre el hardware y el software.Cuando un componente del hardware se desgasta es sustituido por una refaccin. Encambio, no hay refacciones para el software. Cada falla de ste indica un error en el di-seoo en el proceso que tradujo el diseo a cdigo ejecutable por la mquina. Enton-ces,las tareas de mantenimiento del software, que incluyen la satisfaccin de peticio-nesde cambios, involucran una complejidad considerablemente mayor que elmantenimiento del hardware.3. Aunque la industria se mueve hacia la construccin basada en componentes, la mayor partedel software se construye para un uso individualizado.A medida que evoluciona una disciplina de ingeniera, se crea un conjunto de compo-nentesestandarizados para el diseo. Los tornillos estndar y los circuitos integradospreconstruidos son slo dos de los miles de componentes estndar que utilizan los in-genierosmecnicos y elctricos conforme disean nuevos sistemas. Los componentesreutilizables han sido creados para que el ingeniero pueda concentrarse en los elemen-tosverdaderamente innovadores de un diseo; es decir, en las partes de ste que repre-sentanalgo nuevo. En el mundo del hardware, volver a usar componentes es una parteCONSEJOSi quiere reducir el deterioro delsoftware, tendr que mejorar sudiseo (captulos 8 a 13).Tasa de fallasincrementada debidoa efectos colateralesTiempoTasa de fallasCambioCurva realCurva idealizadaFIGURA 1.2Curvas de falladel software2 En realidad, los distintos participantes solicitan cambios desde el momento en que comienza el desarrollo ymucho antes de que se disponga de la primera versin.PUNTOCLAVELos mtodos de la ingeniera desoftware llevan a reducir la magnitudde los picos y de la pendiente de lacurva real en la figura 1.2.Cita:Las ideas son los ladrillos conlos que se construyen las ideas.Jason Zebehazy 31. 6 CAPTULO 1 EL SOFTWARE Y LA INGENIERA DE SOFTWAREnatural del proceso de ingeniera. En el del software, es algo que apenas ha empezado ahacerse a gran escala.Un componente de software debe disearse e implementarse de modo que puedavolverse a usar en muchos programas diferentes. Los modernos componentes reutiliza-blesincorporan tanto los datos como el procesamiento que se les aplica, lo que permiteque el ingeniero de software cree nuevas aplicaciones a partir de partes susceptibles devolverse a usar.3 Por ejemplo, las actuales interfaces interactivas de usuario se constru-yencon componentes reutilizables que permiten la creacin de ventanas grficas, me-nsdesplegables y una amplia variedad de mecanismos de interaccin. Las estructurasde datos y el detalle de procesamiento que se requieren para construir la interfaz estncontenidos en una librera de componentes reusables para tal fin.1.1.2 Dominios de aplicacin del softwareActualmente, hay siete grandes categoras de software de computadora que plantean retoscontinuos a los ingenieros de software:Software de sistemas: conjunto de programas escritos para dar servicio a otros progra-mas.Determinado software de sistemas (por ejemplo, compiladores, editores y herramien-taspara administrar archivos) procesa estructuras de informacin complejas pero determi-nistas.4 Otras aplicaciones de sistemas (por ejemplo, componentes de sistemas operativos,manejadores, software de redes, procesadores de telecomunicaciones) procesan sobre tododatos indeterminados. En cualquier caso, el rea de software de sistemas se caracterizapor: gran interaccin con el hardware de la computadora, uso intensivo por parte de usua-riosmltiples, operacin concurrente que requiere la secuenciacin, recursos compartidosy administracin de un proceso sofisticado, estructuras complejas de datos e interfaces ex-ternasmltiples.Software de aplicacin: programas aislados que resuelven una necesidad especfica denegocios. Las aplicaciones en esta rea procesan datos comerciales o tcnicos en unaforma que facilita las operaciones de negocios o la toma de decisiones administrativas otcnicas. Adems de las aplicaciones convencionales de procesamiento de datos, el soft-warede aplicacin se usa para controlar funciones de negocios en tiempo real (por ejem-plo,procesamiento de transacciones en punto de venta, control de procesos de manufac-turaen tiempo real).Software de ingeniera y ciencias: se ha caracterizado por algoritmos devoradores denmeros. Las aplicaciones van de la astronoma a la vulcanologa, del anlisis de tensio-nesen automviles a la dinmica orbital del transbordador espacial, y de la biologa mo-leculara la manufactura automatizada. Sin embargo, las aplicaciones modernas dentro delrea de la ingeniera y las ciencias estn abandonando los algoritmos numricos conven-cionales.El diseo asistido por computadora, la simulacin de sistemas y otras aplicacio-nesinteractivas, han comenzado a hacerse en tiempo real e incluso han tomado caracters-ticasdel software de sistemas.Software incrustado: reside dentro de un producto o sistema y se usa para implementar ycontrolar caractersticas y funciones para el usuario final y para el sistema en s. El softwareincrustado ejecuta funciones limitadas y particulares (por ejemplo, control del tablero de unhorno de microondas) o provee una capacidad significativa de funcionamiento y control3 El desarrollo basado en componentes se estudia en el captulo 10.4 El software es determinista si es posible predecir el orden y momento de las entradas, el procesamiento y lassalidas. El software es no determinista si no pueden predecirse el orden y momento en que ocurren stos.WebRefEn la direccin shareware.cnet.com se encuentra una de las librerasms completas de software compartidoy libre. 32. CAPTULO 1 EL SOFTWARE Y LA INGENIERA DE SOFTWARE 7(funciones digitales en un automvil, como el control del combustible, del tablero de con-troly de los sistemas de frenado).Software de lnea de productos: es diseado para proporcionar una capacidad espec-ficapara uso de muchos consumidores diferentes. El software de lnea de productos secentra en algn mercado limitado y particular (por ejemplo, control del inventario de pro-ductos)o se dirige a mercados masivos de consumidores (procesamiento de textos, hojasde clculo, grficas por computadora, multimedios, entretenimiento, administracin debase de datos y aplicaciones para finanzas personales o de negocios).Aplicaciones web: llamadas webapps, esta categora de software centrado en redesagrupa una amplia gama de aplicaciones. En su forma ms sencilla, las webapps son pocoms que un conjunto de archivos de hipertexto vinculados que presentan informacin conuso de texto y grficas limitadas. Sin embargo, desde que surgi Web 2.0, las webapps es-tnevolucionando hacia ambientes de cmputo sofisticados que no slo proveen caracte-rsticasaisladas, funciones de cmputo y contenido para el usuario final, sino que tambinestn integradas con bases de datos corporativas y aplicaciones de negocios.Software de inteligencia artificial: hace uso de algoritmos no numricos para resolverproblemas complejos que no son fciles de tratar computacionalmente o con el anlisis di-recto.Las aplicaciones en esta rea incluyen robtica, sistemas expertos, reconocimientode patrones (imagen y voz), redes neurales artificiales, demostracin de teoremas y juegos.Son millones de ingenieros de software en todo el mundo los que trabajan duro en proyectos desoftware en una o ms de estas categoras. En ciertos casos se elaboran sistemas nuevos, peroen muchos otros se corrigen, adaptan y mejoran aplicaciones ya existentes. No es raro que unajoven ingeniera de software trabaje en un programa de mayor edad que la de ella Las genera-cionespasadas de los trabajadores del software dejaron un legado en cada una de las categorasmencionadas. Por fortuna, la herencia que dejar la actual generacin aligerar la carga de losfuturos ingenieros de software. Aun as, nuevos desafos (captulo 31) han aparecido en el hori-zonte.Computacin en un mundo abierto: el rpido crecimiento de las redes inalmbricasquiz lleve pronto a la computacin verdaderamente ubicua y distribuida. El reto para losingenieros de software ser desarrollar software de sistemas y aplicacin que permita adispositivos mviles, computadoras personales y sistemas empresariales comunicarse atravs de redes enormes.Construccin de redes: la red mundial (World Wide Web) se est convirtiendo con rapi-deztanto en un motor de computacin como en un proveedor de contenido. El desafopara los ingenieros de software es hacer arquitecturas sencillas (por ejemplo, planeacin fi-nancierapersonal y aplicaciones sofisticadas que proporcionen un beneficio a mercadosobjetivo de usuarios finales en todo el mundo).Fuente abierta: tendencia creciente que da como resultado la distribucin de cdigofuente para aplicaciones de sistemas (por ejemplo, sistemas operativos, bases de datos yambientes de desarrollo) de modo que mucha gente pueda contribuir a su desarrollo. El de-safopara los ingenieros de software es elaborar cdigo fuente que sea autodescriptivo, ytambin, lo que es ms importante, desarrollar tcnicas que permitirn tanto a los consu-midorescomo a los desarrolladores saber cules son los cambios hechos y cmo se mani-fiestandentro del software.Es indudable que cada uno de estos nuevos retos obedecer a la ley de las consecuencias im-previstasy tendr efectos (para hombres de negocios, ingenieros de software y usuarios finales)que hoy no pueden predecirse. Sin embargo, los ingenieros de software pueden prepararse de-Cita:No hay computadora quetenga sentido comn.Marvin MinskyCita:No siempre puedes predecir,pero siempre puedesprepararte.Annimo 33. 8 CAPTULO 1 EL SOFTWARE Y LA INGENIERA DE SOFTWAREsarrollando un proceso que sea gil y suficientemente adaptable para que acepte los cambiosprofundos en la tecnologa y las reglas de los negocios que seguramente surgirn en la dcadasiguiente.1.1.3 Software heredadoCientos de miles de programas de cmputo caen en uno de los siete dominios amplios de apli-cacinque se estudiaron en la subseccin anterior. Algunos de ellos son software muy nuevo,disponible para ciertos individuos, industria y gobierno. Pero otros programas son ms viejos,en ciertos casos muy viejos.Estos programas antiguos que es frecuente denominar software heredado han sido centrode atencin y preocupacin continuas desde la dcada de 1960. Dayani-Fard y sus colegas[Day99] describen el software heredado de la manera siguiente:Los sistemas de software heredado [] fueron desarrollados hace varias dcadas y han sido modifi-cadosde manera continua para que satisfagan los cambios en los requerimientos de los negocios yplataformas de computacin. La proliferacin de tales sistemas es causa de dolores de cabeza paralas organizaciones grandes, a las que resulta costoso mantenerlos y riesgoso hacerlos evolucionar.Liu y sus colegas [Liu98] amplan esta descripcin al hacer notar que muchos sistemas hereda-doscontinan siendo un apoyo para las funciones bsicas del negocio y son indispensablespara ste. Adems, el software heredado se caracteriza por su longevidad e importancia crti-capara el negocio.Desafortunadamente, en ocasiones hay otra caracterstica presente en el software heredado:mala calidad.5 Hay veces en las que los sistemas heredados tienen diseos que no son suscepti-blesde extenderse, cdigo confuso, documentacin mala o inexistente, casos y resultados depruebas que nunca se archivaron, una historia de los cambios mal administrada la lista es muylarga. A pesar de esto, dichos sistemas dan apoyo a las funciones bsicas del negocio y sonindispensables para ste. Qu hacer?La nica respuesta razonable es: hacer nada, al menos hasta que el sistema heredado tengaun cambio significativo. Si el software heredado satisface las necesidades de sus usuarios ycorre de manera confiable, entonces no falla ni necesita repararse. Sin embargo, conforme paseel tiempo ser frecuente que los sistemas de software evolucionen por una o varias de las si-guientesrazones: El software debe adaptarse para que cumpla las necesidades de los nuevos ambientesdel cmputo y de la tecnologa. El software debe ser mejorado para implementar nuevos requerimientos del negocio. El software debe ampliarse para que sea operable con otros sistemas o bases de datosmodernos. La arquitectura del software debe redisearse para hacerla viable dentro de un ambientede redes.Cuando ocurren estos modos de evolucin, debe hacerse la reingeniera del sistema heredado(captulo 29) para que sea viable en el futuro. La meta de la ingeniera de software moderna esdesarrollar metodologas que se basen en el concepto de evolucin; es decir, el concepto deque los sistemas de software cambian continuamente, que los nuevos sistemas de software se5 En este caso, la calidad se juzga con base en el pensamiento moderno de la ingeniera de software, criterio algoinjusto, ya que algunos conceptos y principios de la ingeniera de software moderna tal vez no hayan sido bienentendidos en la poca en que se desarroll el software heredado.Qu hago si encuentroun sistema heredado demala calidad??Qu tipos de cambiosse hacen a los sistemasheredados??CONSEJOTodo ingeniero de software debereconocer que el cambio es natural.No trate de evitarlo. 34. CAPTULO 1 EL SOFTWARE Y LA INGENIERA DE SOFTWARE 9desarrollan a partir de los antiguos y [] que todo debe operar entre s y cooperar con cada unode los dems [Day99].1.2 LA NATURALEZA NICA DE LAS WEBAPPSEn los primeros das de la Red Mundial (entre 1990 y 1995), los sitios web consistan en poco msque un conjunto de archivos de hipertexto vinculados que presentaban la informacin con elempleo de texto y grficas limitadas. Al pasar el tiempo, el aumento de HTML por medio deherramientas de desarrollo (XML, Java) permiti a los ingenieros de la web brindar capacidadde cmputo junto con contenido de informacin. Haban nacido los sistemas y aplicaciones ba-sadosen la web6 (denomin a stas en forma colectiva como webapps). En la actualidad, laswebapps se han convertido en herramientas sofisticadas de cmputo que no slo proporcionanfunciones aisladas al usuario final, sino que tambin se han integrado con bases de datos cor-porativasy aplicaciones de negocios.Como se dijo en la seccin 1.1.2, las webapps son una de varias categoras distintas de soft-ware.No obstante, podra argumentarse que las webapps son diferentes. Powell [Pow98] sugiereque los sistemas y aplicaciones basados en web involucran una mezcla entre las publicacionesimpresas y el desarrollo de software, entre la mercadotecnia y la computacin, entre las comu-nicacionesinternas y las relaciones exteriores, y entre el arte y la tecnologa. La gran mayorade webapps presenta los siguientes atributos:Uso intensivo de redes. Una webapp reside en una red y debe atender las necesidadesde una comunidad diversa de clientes. La red permite acceso y comunicacin mundiales(por ejemplo, internet) o tiene acceso y comunicacin limitados (por ejemplo, una intranetcorporativa).Concurrencia. A la webapp puede acceder un gran nmero de usuarios a la vez. En mu-choscasos, los patrones de uso entre los usuarios finales varan mucho.Carga impredecible. El nmero de usuarios de la webapp cambia en varios rdenes demagnitud de un da a otro. El lunes tal vez la utilicen cien personas, el jueves quiz 10 000usen el sistema.Rendimiento. Si un usuario de la webapp debe esperar demasiado (para entrar, para elprocesamiento por parte del servidor, para el formado y despliegue del lado del cliente), lo ella quiz decidan irse a otra parte.Disponibilidad. Aunque no es razonable esperar una disponibilidad de 100%, es fre-cuenteque los usuarios de webapps populares demanden acceso las 24 horas de los 365das del ao. Los usuarios en Australia o Asia quiz demanden acceso en horas en las quelas aplicaciones internas de software tradicionales en Norteamrica no estn en lnea porrazones de mantenimiento.Orientadas a los datos. La funcin principal de muchas webapp es el uso de hiperme-diospara presentar al usuario final contenido en forma de texto, grficas, audio y video.Adems, las webapps se utilizan en forma comn para acceder a informacin que existe enbases de datos que no son parte integral del ambiente basado en web (por ejemplo, comer-cioelectrnico o aplicaciones financieras).Cita:Cuando veamos cualquier tipode estabilizacin, la web sehabr convertido en algo com-pletamentediferente.Louis Monier6 En el contexto de este libro, el trmino aplicacin web (webapp) agrupa todo, desde una simple pgina web queayude al consumidor a calcular el pago del arrendamiento de un automvil hasta un sitio web integral que pro-porcioneservicios completos de viaje para gente de negocios y vacacionistas. En esta categora se incluyen sitiosweb completos, funcionalidad especializada dentro de sitios web y aplicaciones de procesamiento de informa-cinque residen en internet o en una intranet o extranet.Qu caractersticadiferencia las webappsde otro software?? 35. 10 CAPTULO 1 EL SOFTWARE Y LA INGENIERA DE SOFTWAREContenido sensible. La calidad y naturaleza esttica del contenido constituye un rasgoimportante de la calidad de una webapp.Evolucin continua. A diferencia del software de aplicacin convencional que evolu-cionaa lo largo de una serie de etapas planeadas y separadas cronolgicamente, las aplica-cionesweb evolucionan en forma continua. No es raro que ciertas webapp (especfica-mentesu contenido) se actualicen minuto a minuto o que su contenido se calcule en cadasolicitud.Inmediatez. Aunque la inmediatez necesidad apremiante de que el software llegue conrapidez al mercado es una caracterstica en muchos dominios de aplicacin, es frecuenteque las webapps tengan plazos de algunos das o semanas para llegar al mercado.7Seguridad. Debido a que las webapps se encuentran disponibles con el acceso a una red,es difcil o imposible limitar la poblacin de usuarios finales que pueden acceder a la apli-cacin.Con el fin de proteger el contenido sensible y brindar modos seguros de transmi-sinde los datos, deben implementarse medidas estrictas de seguridad a travs de la infra-estructurade apoyo de una webapp y dentro de la aplicacin misma.Esttica. Parte innegable del atractivo de una webapp es su apariencia y percepcin.Cuando se ha diseado una aplicacin para comercializar o vender productos o ideas, laesttica tiene tanto que ver con el xito como el diseo tcnico.Podra argumentarse que otras categoras de aplicaciones estudiadas en la seccin 1.1.2muestran algunos de los atributos mencionados. Sin embargo, las webapps casi siempre poseentodos ellos.1.3 INGENIERA DE SOFTWARECon objeto de elaborar software listo para enfrentar los retos del siglo XXI, el lector debe aceptaralgunas realidades sencillas: El software se ha incrustado profundamente en casi todos los aspectos de nuestras vidasy, como consecuencia, el nmero de personas que tienen inters en las caractersticas yfunciones que brinda una aplicacin especfica8 ha crecido en forma notable. Cuando hade construirse una aplicacin nueva o sistema incrustado, deben escucharse muchasopiniones. Y en ocasiones parece que cada una de ellas tiene una idea un poco distintade cules caractersticas y funciones debiera tener el software. Se concluye que debehacerse un esfuerzo concertado para entender el problema antes de desarrollar una aplica-cinde software. Los requerimientos de la tecnologa de la informacin que demandan los individuos,negocios y gobiernos se hacen ms complejos con cada ao que pasa. En la actualidad,grandes equipos de personas crean programas de cmputo que antes eran elaboradospor un solo individuo. El software sofisticado, que alguna vez se implement en unambiente de cmputo predecible y autocontenido, hoy en da se halla incrustado en elinterior de todo, desde la electrnica de consumo hasta dispositivos mdicos o sistemasde armamento. La complejidad de estos nuevos sistemas y productos basados encomputadora demanda atencin cuidadosa a las interacciones de todos los elementosdel sistema. Se concluye que el diseo se ha vuelto una actividad crucial.7 Con las herramientas modernas es posible producir pginas web sofisticadas en unas cuantas horas.8 En una parte posterior de este libro, llamar a estas personas participantes.PUNTOCLAVEEntender el problema antes de daruna solucin.PUNTOCLAVEEl diseo es una actividad crucial dela ingeniera de software. 36. CAPTULO 1 EL SOFTWARE Y LA INGENIERA DE SOFTWARE 11 Los individuos, negocios y gobiernos dependen cada vez ms del software para tomardecisiones estratgicas y tcticas, as como para sus operaciones y control cotidianos. Siel software falla, las personas y empresas grandes pueden experimentar desde un incon-venientemenor hasta fallas catastrficas. Se concluye que el software debe tener altacalidad. A medida que aumenta el valor percibido de una aplicacin especfica se incrementa laprobabilidad de que su base de usuarios y longevidad tambin crezcan. Conforme seextienda su base de usuarios y el tiempo de uso, las demandas para adaptarla ymejorarla tambin crecern. Se concluye que el software debe tener facilidad para recibirmantenimiento.Estas realidades simples llevan a una conclusin: debe hacerse ingeniera con el software en todassus formas y a travs de todos sus dominios de aplicacin. Y esto conduce al tema de este libro: laingeniera de software.Aunque cientos de autores han desarrollado definiciones personales de la ingeniera de soft-ware,la propuesta por Fritz Bauer [Nau69] en la conferencia fundamental sobre el tema todavasirve como base para el anlisis:[La ingeniera de software es] el establecimiento y uso de principios fundamentales de la ingenieracon objeto de desarrollar en forma econmica software que sea confiable y que trabaje con eficienciaen mquinas reales.El lector se sentir tentado de ampliar esta definicin.9 Dice poco sobre los aspectos tcnicosde la calidad del software; no habla directamente de la necesidad de satisfacer a los consumi-doresni de entregar el producto a tiempo; omite mencionar la importancia de la medicin y lametrologa; no establece la importancia de un proceso eficaz. No obstante, la definicin deBauer proporciona una base. Cules son los principios fundamentales de la ingeniera quepueden aplicarse al desarrollo del software de computadora? Cmo se desarrolla software enforma econmica y que sea confiable? Qu se requiere para crear programas de cmputoque trabajen con eficiencia, no en una sino en muchas mquinas reales diferentes? stas sonlas preguntas que siguen siendo un reto para los ingenieros de software.El IEEE [IEEE93a] ha desarrollado una definicin ms completa, como sigue:La ingeniera de software es: 1) La aplicacin de un enfoque sistemtico, disciplinado y cuantificableal desarrollo, operacin y mantenimiento de software; es decir, la aplicacin de la ingeniera al soft-ware.2) El estudio de enfoques segn el punto 1.Aun as, el enfoque sistemtico, disciplinado y cuantificable aplicado por un equipo desoftware podra ser algo burdo para otro. Se necesita disciplina, pero tambin adaptabilidad yagilidad.La ingeniera de software es una tecnologa con varias capas. Como se aprecia en la figura1.3, cualquier enfoque de ingeniera (incluso la de software) debe basarse en un compromisoorganizacional con la calidad. La administracin total de la calidad, Six Sigma y otras filosofassimilares10 alimentan la cultura de mejora continua, y es esta cultura la que lleva en ltima ins-tanciaal desarrollo de enfoques cada vez ms eficaces de la ingeniera de software. El funda-mentoen el que se apoya la ingeniera de software es el compromiso con la calidad.El fundamento para la ingeniera de software es la capa proceso. El proceso de ingeniera desoftware es el aglutinante que une las capas de la tecnologa y permite el desarrollo racional yPUNTOCLAVETanto la calidad como la facilidad derecibir mantenimiento son resultadode un buen diseo.Cita:Ms que una disciplina o cuer-pode conocimientos, ingenieraes un verbo, una palabra deaccin, una forma de abordarun problema.Scott WhitmirCmo se define laingeniera de software? ?PUNTOCLAVELa ingeniera de software incluye unproceso, mtodos y herramientaspara administrar y hacer ingenieracon el software.9 Consulte muchas otras definiciones en www.answers.com/topic/software-engineering#wp-_note-13.10 En el captulo 14 y toda la parte 3 del libro se estudia la administracin de la calidad y los enfoques relacionadoscon sta. 37. 12 CAPTULO 1 EL SOFTWARE Y LA INGENIERA DE SOFTWAREHerramientasMtodosProcesoCompromiso con la calidadoportuno del software de cmputo. El proceso define una estructura que debe establecerse parala obtencin eficaz de tecnologa de ingeniera de software. El proceso de software forma la basepara el control de la administracin de proyectos de software, y establece el contexto en el quese aplican mtodos tcnicos, se generan productos del trabajo (modelos, documentos, datos,reportes, formatos, etc.), se establecen puntos de referencia, se asegura la calidad y se adminis-trael cambio de manera apropiada.Los mtodos de la ingeniera de software proporcionan la experiencia tcnica para elaborarsoftware. Incluyen un conjunto amplio de tareas, como comunicacin, anlisis de los requeri-mientos,modelacin del diseo, construccin del programa, pruebas y apoyo. Los mtodos dela ingeniera de software se basan en un conjunto de principios fundamentales que gobiernancada rea de la tecnologa e incluyen actividades de modelacin y otras tcnicas descriptivas.Las herramientas de la ingeniera de software proporcionan un apoyo automatizado o se-miautomatizadopara el proceso y los mtodos. Cuando se integran las herramientas de modoque la informacin creada por una pueda ser utilizada por otra, queda establecido un sistemallamado ingeniera de software asistido por computadora que apoya el desarrollo de software.1.4 EL PROCESO DEL SOFTWAREUn proceso es un conjunto de actividades, acciones y tareas que se ejecutan cuando va a crearsealgn producto del trabajo. Una actividad busca lograr un objetivo amplio (por ejemplo, comu-nicacincon los participantes) y se desarrolla sin importar el dominio de la aplicacin, tamaodel proyecto, complejidad del esfuerzo o grado de rigor con el que se usar la ingeniera desoftware. Una accin (diseo de la arquitectura) es un conjunto de tareas que producen un pro-ductoimportante del trabajo (por ejemplo, un modelo del diseo de la arquitectura). Una tarease centra en un objetivo pequeo pero bien definido (por ejemplo, realizar una prueba unitaria)que produce un resultado tangible.En el contexto de la ingeniera de software, un proceso no es una prescripcin rgida de cmoelaborar software de cmputo. Por el contrario, es un enfoque adaptable que permite que laspersonas que hacen el trabajo (el equipo de software) busquen y elijan el conjunto apropiado deacciones y tareas para el trabajo. Se busca siempre entregar el software en forma oportuna ycon calidad suficiente para satisfacer a quienes patrocinaron su creacin y a aquellos que lousarn.La estructura del proceso establece el fundamento para el proceso completo de la ingenierade software por medio de la identificacin de un nmero pequeo de actividades estructuralesque sean aplicables a todos los proyectos de software, sin importar su tamao o complejidad.Adems, la estructura del proceso incluye un conjunto de actividades sombrilla que son aplica-blesa travs de todo el proceso del software. Una estructura de proceso general para la inge-nierade software consta de cinco actividades:FIGURA 1.3Capas de laingeniera desoftwareWebRefCrossTalk es un peridico que dainformacin prctica sobre procesos,mtodos y herramientas. Se encuentraen www.stsc.hill.af.milCules son loselementos de unproceso de software?Cita:?Un proceso define quin hacequ, cundo y cmo, paraalcanzar cierto objetivo.Ivar Jacobson, Grady Boochy James Rumbaugh 38. CAPTULO 1 EL SOFTWARE Y LA INGENIERA DE SOFTWARE 13Comunicacin. Antes de que comience cualquier trabajo tcnico, tiene importancia cr-ticacomunicarse y colaborar con el cliente (y con otros participantes).11 Se busca entenderlos objetivos de los participantes respecto del proyecto, y reunir los requerimientos queayuden a definir las caractersticas y funciones del software.Planeacin. Cualquier viaje complicado se simplifica si existe un mapa. Un proyecto desoftware es un viaje difcil, y la actividad de planeacin crea un mapa que gua al equipomientras viaja. El mapa llamado plan del proyecto de software define el trabajo de inge-nierade software al describir las tareas tcnicas por realizar, los riesgos probables, los re-cursosque se requieren, los productos del trabajo que se obtendrn y una programacin delas actividades.Modelado. Ya sea usted diseador de paisaje, constructor de puentes, ingeniero aeronu-tico,carpintero o arquitecto, a diario trabaja con modelos. Crea un bosquejo del objeto porhacer a fin de entender el panorama general cmo se ver arquitectnicamente, cmoajustan entre s las partes constituyentes y muchas caractersticas ms. Si se requiere, re-finael bosquejo con ms y ms detalles en un esfuerzo por comprender mejor el problema ycmo resolverlo. Un ingeniero de software hace lo mismo al crear modelos a fin de entendermejor los requerimientos del software y el diseo que los satisfar.Construccin. Esta actividad combina la generacin de cdigo (ya sea manual o auto-matizada)y las pruebas que se requieren para descubrir errores en ste.Despliegue. El software (como entidad completa o como un incremento parcialmenteterminado) se entrega al consumidor que lo evala y que le da retroalimentacin, mismaque se basa en dicha evaluacin.Estas cinco actividades estructurales genricas se usan durante el desarrollo de programas pe-queosy sencillos, en la creacin de aplicaciones web grandes y en la ingeniera de sistemasenormes y complejos basados en computadoras. Los detalles del proceso de software serndistintos en cada caso, pero las actividades estructurales son las mismas.Para muchos proyectos de software, las actividades estructurales se aplican en forma itera-tivaa medida que avanza el proyecto. Es decir, la comunicacin, la planeacin, el mode-lado,la construccin y el despliegue se ejecutan a travs de