810

Ingeniería del Software - Pressman

Embed Size (px)

Citation preview

  • 00Pressman(i-xxx)prelim.indd ii00Pressman(i-xxx)prelim.indd ii 2/2/10 11:40:142/2/10 11:40:14

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

    00Pressman(i-xxx)prelim.indd i00Pressman(i-xxx)prelim.indd i 2/2/10 11:40:122/2/10 11:40:12

  • 00Pressman(i-xxx)prelim.indd ii00Pressman(i-xxx)prelim.indd ii 2/2/10 11:40:142/2/10 11:40:14

  • Ingeniera del softwareU N E N F O Q U E P R C T I C O

    SPTIMA EDICIN

    Roger S. Pressman, Ph.D.University of Connecticut

    MXICO BOGOT BUENOS AIRES CARACAS GUATEMALA MADRIDNUEVA YORK SAN JUAN SANTIAGO SO PAULO AUCKLAND LONDRES MILN

    MONTREAL NUEVA DELHI SAN FRANCISCO SINGAPUR ST. LOUIS SIDNEY TORONTO

    00Pressman(i-xxx)prelim.indd iii00Pressman(i-xxx)prelim.indd iii 2/2/10 11:40:142/2/10 11:40:14

  • 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 Garca

    Traductores: Vctor Campos OlgunJavier Enrquez Brito

    Revisin tcnica: Carlos Villegas QuezadaBrbaro Jorge Ferro Castro

    INGENIERA DEL SOFTWARE. UN ENFOQUE PRCTICOSptima edicin

    Prohibida la reproduccin total o parcial de esta obra, por cualquier medio, sin la autorizacin escrita del editor.

    Educacin

    DERECHOS 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 A Piso 17, Colonia Desarrollo Santa Fe, Delegacin lvaro Obregn C.P. 01376, Mxico, D. F. Miembro de la Cmara Nacional de la Industria Editorial Mexicana, Reg. Nm. 736

    ISBN: 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 the Americas, New York, NY 10020. Copyright 2010 by The McGraw-Hill Companies, Inc. All rights reserved.978-0-07-337597-7

    1234567890 109876543210

    Impreso en Mxico Printed in Mexico

    00Pressman(i-xxx)prelim.indd iv00Pressman(i-xxx)prelim.indd iv 2/2/10 11:40:142/2/10 11:40:14

  • 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.

    00Pressman(i-xxx)prelim.indd v00Pressman(i-xxx)prelim.indd v 2/2/10 11:40:142/2/10 11:40:14

  • 00Pressman(i-xxx)prelim.indd vi00Pressman(i-xxx)prelim.indd vi 2/2/10 11:40:142/2/10 11:40:14

  • ACERCA DEL AUTOR

    Roger S. Pressman es una autoridad internacionalmente reconocida en el mejoramiento del proceso del software y en las tecnologas de la ingeniera del mismo. Durante casi cuatro dcadas ha trabajado como ingeniero de software, gestor, profesor, escritor y consultor, especializado en temas de ingeniera del software.

    Como profesional y gestor industrial, el doctor Pressman trabaj en el desarrollo de sistemas CAD/CAM para aplicaciones de ingeniera y fabricacin avanzadas. Tambin ha tenido posicio-nes de 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 Bullard en ingeniera de cmputo de la Universidad de Bridgeport, y en director del Centro de Diseo y Fabricacin Asistidos por Computadora de dicha universidad.

    En la actualidad, el doctor Pressman es presidente de R. S. Pressman & Associates, Inc., una empresa de consultora especializada en mtodos y capacitacin en ingeniera del software. Trabaja como consultor principal y dise y desarroll Ingeniera del software esencial, un video curricular completo acerca de ingeniera del software, y Consultor de procesos, un sistema auto-dirigido para el mejoramiento del proceso de software. Ambos productos los utilizan miles de compaas en todo el mundo. Ms recientemente, trabaj en colaboracin con EdistaLearning, en India, para desarrollar capacitacin abarcadora basada en internet acerca de ingeniera del software.

    El doctor Pressman ha escrito muchos artculos tcnicos, es colaborador regular en revistas peridicas industriales y autor de siete libros tcnicos. Adems de Ingeniera del software: un enfoque prctico, es coautor de Web Engineering (McGraw-Hill), uno de los primeros libros en aplicar un conjunto personalizado de principios y prcticas de la ingeniera del software al de-sarrollo de sistemas y aplicaciones basados en web. Tambin escribi el premiado A Managers Guide to Software Engineering (McGraw-Hill); Making Software Engineering Happen (Prentice hall), el primer libro en abordar los problemas administrativos cruciales asociados con el mejo-ramiento del proceso de software; y Software Shock (Dorset House), un tratamiento que se en-foca en el software y su impacto en los negocios y la sociedad. Pressman ha formado parte de los consejos editoriales de varias publicaciones industriales y durante muchos aos fue editor de la columna Manager en IEEE Software.

    Adems, es un orador bien conocido, y ha sido el orador principal en muchas conferencias industriales importantes. Es miembro de IEEE, y de Tau Beta Pi, Phi Kappa Phi, Eta Kappa Nu y Pi Tau Sigma.

    En el lado personal, Pressman vive en el sur de Florida con su esposa, Brbara. Atleta de toda la vida, sigue siendo un serio jugador de tenis (4.5 en el programa estadounidense de calificacin de tenis, NTRP) y un golfista con un handicap de un solo dgito. En su tiempo libre escribi dos novelas, Aymara Bridge y The Puppeteer, y tiene planes para escribir una ms.

    vii

    00Pressman(i-xxx)prelim.indd vii00Pressman(i-xxx)prelim.indd vii 2/2/10 11:40:142/2/10 11:40:14

  • 00Pressman(i-xxx)prelim.indd viii00Pressman(i-xxx)prelim.indd viii 2/2/10 11:40:152/2/10 11:40:15

  • CONTENIDO BREVE

    CAPTULO 1 El software y la ingeniera de software 1

    PARTE UNO EL PROCESO DEL SOFTWARE 25

    CAPTULO 2 Modelos del proceso 26

    CAPTULO 3 Desarrollo gil 55

    PARTE DOS MODELADO 81

    CAPTULO 4 Principios que guan la prctica 82

    CAPTULO 5 Comprensin de los requerimientos 101

    CAPTULO 6 Modelado de los requerimientos: escenarios, informacin y clases de anlisis 126

    CAPTULO 7 Modelado de los requerimientos: flujo, comportamiento, patrones y webapps 158

    CAPTULO 8 Conceptos de diseo 183

    CAPTULO 9 Diseo de la arquitectura 206

    CAPTULO 10 Diseo en el nivel de componentes 234

    CAPTULO 11 Diseo de la interfaz de usuario 265

    CAPTULO 12 Diseo basado en patrones 295

    CAPTULO 13 Diseo de webapps 317

    PARTE TRES ADMINISTRACIN DE LA CALIDAD 337

    CAPTULO 14 Conceptos de calidad 338

    CAPTULO 15 Tcnicas de revisin 354

    CAPTULO 16 Aseguramiento de la calidad del software 368

    CAPTULO 17 Estrategias de prueba de software 383

    CAPTULO 18 Prueba de aplicaciones convencionales 411

    CAPTULO 19 Prueba de aplicaciones orientadas a objetos 437

    CAPTULO 20 Prueba de aplicaciones web 453

    CAPTULO 21 Modelado y verificacin formal 478

    CAPTULO 22 Administracin de la configuracin del software 501

    CAPTULO 23 Mtricas de producto 526

    PARTE CUATRO ADMINISTRACIN DE PROYECTOS DE SOFTWARE 553

    CAPTULO 24 Conceptos de administracin de proyecto 554

    CAPTULO 25 Mtricas de proceso y de proyecto 571

    CAPTULO 26 Estimacin para proyectos de software 593

    CAPTULO 27 Calendarizacin del proyecto 620

    CAPTULO 28 Administracin del riesgo 640

    CAPTULO 29 Mantenimiento y reingeniera 655

    ix

    00Pressman(i-xxx)prelim.indd ix00Pressman(i-xxx)prelim.indd ix 2/2/10 11:40:152/2/10 11:40:15

  • PARTE CINCO TEMAS AVANZADOS 675

    CAPTULO 30 Mejoramiento del proceso de software 676

    CAPTULO 31 Tendencias emergentes en ingeniera del software 695

    CAPTULO 32 Comentarios finales 717

    APNDICE 1 Introduccin a UML 725

    APNDICE 2 Conceptos orientados a objeto 743

    REFERENCIAS 751

    NDICE ANALTICO 767

    x CONTENIDO BREVE

    00Pressman(i-xxx)prelim.indd x00Pressman(i-xxx)prelim.indd x 2/2/10 11:40:152/2/10 11:40:15

  • CONTENIDO

    Prefacio xxv

    CAPTULO 1 EL SOFTWARE Y LA INGENIERA DE SOFTWARE 1

    1.1 La naturaleza del software 21.1.1 Definicin de software 31.1.2 Dominios de aplicacin del software 61.1.3 Software heredado 8

    1.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 15

    1.5.1 La esencia de la prctica 151.5.2 Principios generales 16

    1.6 Mitos del software 181.7 Cmo comienza todo 201.8 Resumen 21PROBLEMAS Y PUNTOS POR EVALUAR 21LECTURAS ADICIONALES Y FUENTES DE INFORMACIN 22

    PARTE UNO EL PROCESO DEL SOFTWARE 25

    CAPTULO 2 MODELOS DEL PROCESO 26

    2.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 29

    2.2 Evaluacin y mejora del proceso 312.3 Modelos de proceso prescriptivo 33

    2.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 42

    2.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 44

    2.5 El proceso unificado 452.5.1 Breve historia 462.5.2 Fases del proceso unificado 46

    2.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) 49

    2.7 Tecnologa del proceso 502.8 Producto y proceso 512.9 Resumen 52PROBLEMAS Y PUNTOS POR EVALUAR 53LECTURAS ADICIONALES Y FUENTES DE INFORMACIN 54

    xi

    00Pressman(i-xxx)prelim.indd xi00Pressman(i-xxx)prelim.indd xi 2/2/10 11:40:152/2/10 11:40:15

  • xii CONTENIDO

    CAPTULO 3 DESARROLLO GIL 55

    3.1 Qu es la agilidad? 563.2 La agilidad y el costo del cambio 573.3 Qu es un proceso gil? 58

    3.3.1 Principios de agilidad 583.3.2 La poltica del desarrollo gil 593.3.3 Factores humanos 60

    3.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 66

    3.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) 75

    3.6 Conjunto de herramientas para el proceso gil 763.7 Resumen 77PROBLEMAS Y PUNTOS POR EVALUAR 78LECTURAS ADICIONALES Y FUENTES DE INFORMACIN 79

    PARTE DOS MODELADO 81

    CAPTULO 4 PRINCIPIOS QUE GUAN LA PRCTICA 82

    4.1 Conocimiento de la ingeniera de software 834.2 Principios fundamentales 83

    4.2.1 Principios que guan el proceso 844.2.2 Principios que guan la prctica 84

    4.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 96

    4.4 Resumen 97PROBLEMAS Y PUNTOS POR EVALUAR 98LECTURAS Y FUENTES DE INFORMACIN ADICIONALES 99

    CAPTULO 5 COMPRENSIN DE LOS REQUERIMIENTOS 101

    5.1 Ingeniera de requerimientos 1025.2 Establecer las bases 106

    5.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 108

    5.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

    00Pressman(i-xxx)prelim.indd xii00Pressman(i-xxx)prelim.indd xii 2/2/10 11:40:152/2/10 11:40:15

  • CONTENIDO xiii

    5.4 Desarrollo de casos de uso 1135.5 Elaboracin del modelo de los requerimientos 117

    5.5.1 Elementos del modelo de requerimientos 1185.5.2 Patrones de anlisis 120

    5.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 124

    CAPTULO 6 MODELADO DE LOS REQUERIMIENTOS: ESCENARIOS,INFORMACIN Y CLASES DE ANLISIS 126

    6.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 130

    6.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 135

    6.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) 138

    6.4 Conceptos de modelado de datos 1396.4.1 Objetos de datos 1396.4.2 Atributos de los datos 1406.4.3 Relaciones 141

    6.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 154

    6.6 Resumen 155PROBLEMAS Y PUNTOS POR EVALUAR 156LECTURAS ADICIONALES Y FUENTES DE INFORMACIN 157

    CAPTULO 7 MODELADO DE LOS REQUERIMIENTOS: FLUJO,COMPORTAMIENTO, PATRONES Y WEBAPPS 158

    7.1 Requerimientos que modelan las estrategias 1587.2 Modelado orientado al flujo 159

    7.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 163

    7.3 Creacin de un modelo de comportamiento 1657.3.1 Identificar los eventos con el caso de uso 1667.3.2 Representaciones de estado 166

    7.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 170

    7.5 Modelado de requerimientos para webapps 1747.5.1 Cunto anlisis es suficiente? 1747.5.2 Entrada del modelado de los requerimientos 174

    00Pressman(i-xxx)prelim.indd xiii00Pressman(i-xxx)prelim.indd xiii 2/2/10 11:40:152/2/10 11:40:15

  • xiv CONTENIDO

    7.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 180

    7.6 Resumen 180PROBLEMAS Y PUNTOS POR EVALUAR 181LECTURAS ADICIONALES Y FUENTES DE INFORMACIN 182

    CAPTULO 8 CONCEPTOS DE DISEO 183

    8.1 Diseo en el contexto de la ingeniera de software 1848.2 El proceso de diseo 186

    8.2.1 Lineamientos y atributos de la calidad del software 1868.2.2 La evolucin del diseo del software 188

    8.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 196

    8.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 202

    8.5 Resumen 203PROBLEMAS Y PUNTOS POR EVALUAR 203LECTURAS ADICIONALES Y FUENTES DE INFORMACIN 204

    CAPTULO 9 DISEO DE LA ARQUITECTURA 206

    9.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 209

    9.2 Gneros arquitectnicos 2099.3 Estilos arquitectnicos 211

    9.3.1 Breve taxonoma de estilos de arquitectura 2139.3.2 Patrones arquitectnicos 2159.3.3 Organizacin y refinamiento 216

    9.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

    00Pressman(i-xxx)prelim.indd xiv00Pressman(i-xxx)prelim.indd xiv 2/2/10 11:40:162/2/10 11:40:16

  • CONTENIDO xv

    9.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 224

    9.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 231

    9.7 Resumen 232PROBLEMAS Y PUNTOS POR EVALUAR 232LECTURAS ADICIONALES Y FUENTES DE INFORMACIN 233

    CAPTULO 10 DISEO EN EL NIVEL DE COMPONENTES 234

    10.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 239

    10.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 244

    10.3 Realizacin del diseo en el nivel de componentes 24610.4 Diseo en el nivel de componentes para webapps 251

    10.4.1 Diseo del contenido en el nivel de componente 25110.4.2 Diseo de las funciones en el nivel de componentes 252

    10.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 255

    10.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 260

    10.7 Resumen 262PROBLEMAS Y PUNTOS POR EVALUAR 263LECTURAS ADICIONALES Y FUENTES DE INFORMACIN 263

    CAPTULO 11 DISEO DE LA INTERFAZ DE USUARIO 265

    11.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 268

    11.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 271

    11.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 278

    11.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

    00Pressman(i-xxx)prelim.indd xv00Pressman(i-xxx)prelim.indd xv 2/2/10 11:40:162/2/10 11:40:16

  • xvi CONTENIDO

    11.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 289

    11.6 Evaluacin del diseo 29011.7 Resumen 292PROBLEMAS Y PUNTOS POR EVALUAR 293LECTURAS ADICIONALES Y FUENTES DE INFORMACIN 293

    CAPTULO 12 DISEO BASADO EN PATRONES 295

    12.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 300

    12.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 305

    12.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 313

    12.6.1 Centrarse en el diseo 31312.6.2 Granularidad del diseo 314

    12.7 Resumen 315PROBLEMAS Y PUNTOS POR EVALUAR 315LECTURAS ADICIONALES Y FUENTES DE INFORMACIN 316

    CAPTULO 13 DISEO DE WEBAPPS 317

    13.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 323

    13.5.1 Aspectos de la distribucin 32313.5.2 Aspectos del diseo grfico 324

    13.6 Diseo del contenido 32413.6.1 Objetos de contenido 32413.6.2 Aspectos de diseo del contenido 325

    13.7 Diseo arquitectnico 32613.7.1 Arquitectura del contenido 32613.7.2 Arquitectura de las webapps 328

    13.8 Diseo de la navegacin 32913.8.1 Semntica de la navegacin 32913.8.2 Sintaxis de navegacin 330

    13.9 Diseo en el nivel de componentes 33113.10 Mtodo de diseo de hipermedios orientado a objetos (MDHOO) 332

    13.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 333

    13.11 Resumen 334PROBLEMAS Y PUNTOS POR EVALUAR 335LECTURAS ADICIONALES Y FUENTES DE INFORMACIN 335

    00Pressman(i-xxx)prelim.indd xvi00Pressman(i-xxx)prelim.indd xvi 2/2/10 11:40:162/2/10 11:40:16

  • CONTENIDO xvii

    PARTE TRES ADMINISTRACIN DE LA CALIDAD 337

    CAPTULO 14 CONCEPTOS DE CALIDAD 338

    14.1 Qu es calidad? 33914.2 Calidad del software 340

    14.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 344

    14.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 349

    14.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 351

    14.5 Resumen 351PROBLEMAS Y PUNTOS POR EVALUAR 352LECTURAS Y FUENTES DE INFORMACIN ADICIONALES 352

    CAPTULO 15 TCNICAS DE REVISIN 354

    15.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 357

    15.3.1 Anlisis de las mtricas 35815.3.2 Eficacia del costo de las revisiones 358

    15.4 Revisiones: espectro de formalidad 35915.5 Revisiones informales 36115.6 Revisiones tcnicas formales 362

    15.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 365

    15.7 Resumen 366PROBLEMAS Y PUNTOS POR EVALUAR 367LECTURAS Y FUENTES DE INFORMACIN ADICIONALES 367

    CAPTULO 16 ASEGURAMIENTO DE LA CALIDAD DEL SOFTWARE 368

    16.1 Antecedentes 36916.2 Elementos de aseguramiento de la calidad del software 37016.3 Tareas, metas y mtricas del ACS 371

    16.3.1 Tareas del ACS 37116.3.2 Metas, atributos y mtricas 372

    16.4 Enfoques formales al ACS 37316.5 Aseguramiento estadstico de la calidad del software 374

    16.5.1 Ejemplo general 37416.5.2 Seis Sigma para la ingeniera de software 375

    16.6 Confiabilidad del software 37616.6.1 Mediciones de la confiabilidad y disponibilidad 37716.6.2 Seguridad del software 378

    00Pressman(i-xxx)prelim.indd xvii00Pressman(i-xxx)prelim.indd xvii 2/2/10 11:40:162/2/10 11:40:16

  • xviii CONTENIDO

    16.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 381

    CAPTULO 17 ESTRATEGIAS DE PRUEBA DE SOFTWARE 383

    17.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 388

    17.2 Aspectos estratgicos 38817.3 Estrategias de prueba para software convencional 389

    17.3.1 Prueba de unidad 38917.3.2 Pruebas de integracin 391

    17.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 398

    17.5 Estrategias de prueba para webapps 39817.6 Pruebas de validacin 399

    17.6.1 Criterios de pruebas de validacin 39917.6.2 Revisin de la configuracin 40017.6.3 Pruebas alfa y beta 400

    17.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 403

    17.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 408

    17.9 Resumen 408PROBLEMAS Y PUNTOS POR EVALUAR 409LECTURAS Y FUENTES DE INFORMACIN ADICIONALES 409

    CAPTULO 18 PRUEBA DE APLICACIONES CONVENCIONALES 411

    18.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 414

    18.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 420

    18.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 421

    18.6 Pruebas de caja negra 42318.6.1 Mtodos de prueba basados en grficos 42318.6.2 Particin de equivalencia 425

    00Pressman(i-xxx)prelim.indd xviii00Pressman(i-xxx)prelim.indd xviii 2/2/10 11:40:162/2/10 11:40:16

  • CONTENIDO xix

    18.6.3 Anlisis de valor de frontera 42518.6.4 Prueba de arreglo ortogonal 426

    18.7 Prueba basada en modelo 42918.8 Prueba para entornos, arquitecturas y aplicaciones especializados 429

    18.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 432

    18.9 Patrones para pruebas de software 43318.10 Resumen 434PROBLEMAS Y PUNTOS POR EVALUAR 435LECTURAS ADICIONALES Y FUENTES DE INFORMACIN 436

    CAPTULO 19 PRUEBA DE APLICACIONES ORIENTADAS A OBJETOS 437

    19.1 Ampliacin de la definicin de las pruebas 43819.2 Modelos de prueba AOO y DOO 439

    19.2.1 Exactitud de los modelos AOO y DOO 43919.2.2 Consistencia de los modelos orientados a objetos 439

    19.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 442

    19.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 446

    19.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 448

    19.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 450

    19.7 Resumen 451PROBLEMAS Y PUNTOS POR EVALUAR 451LECTURAS ADICIONALES Y FUENTES DE INFORMACIN 452

    CAPTULO 20 PRUEBA DE APLICACIONES WEB 453

    20.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 456

    20.2 Un panorama del proceso de prueba 45620.3 Prueba de contenido 457

    20.3.1 Objetivos de la prueba de contenido 45720.3.2 Prueba de base de datos 458

    20.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 465

    20.5 Prueba en el nivel de componente 466

    00Pressman(i-xxx)prelim.indd xix00Pressman(i-xxx)prelim.indd xix 2/2/10 11:40:162/2/10 11:40:16

  • xx CONTENIDO

    20.6 Prueba de navegacin 46720.6.1 Prueba de sintaxis de navegacin 46720.6.2 Prueba de la semntica de navegacin 468

    20.7 Prueba de configuracin 46920.7.1 Conflictos en el lado servidor 46920.7.2 Conflictos en el lado cliente 470

    20.8 Prueba de seguridad 47020.9 Prueba de rendimiento 471

    20.9.1 Objetivos de la prueba de rendimiento 47220.9.2 Prueba de carga 47220.9.3 Prueba de esfuerzo 473

    20.10 Resumen 475PROBLEMAS Y PUNTOS POR EVALUAR 475LECTURAS ADICIONALES Y FUENTES DE INFORMACIN 476

    CAPTULO 21 MODELADO Y VERIFICACIN FORMAL 478

    21.1 Estrategia de cuarto limpio 47921.2 Especificacin funcional 480

    21.2.1 Especificacin de caja negra 48221.2.2 Especificacin de caja de estado 48221.2.3 Especificacin de caja clara 483

    21.3 Diseo de cuarto limpio 48321.3.1 Refinamiento de diseo 48321.3.2 Verificacin de diseo 484

    21.4 Pruebas de cuarto limpio 48521.4.1 Pruebas de uso estadstico 48621.4.2 Certificacin 487

    21.5 Conceptos de mtodos formales 48721.6 Aplicacin de notacin matemtica para especificacin formal 49021.7 Lenguajes de especificacin formal 492

    21.7.1 Lenguaje de restriccin de objeto (OCL) 49221.7.2 El lenguaje de especificacin Z 495

    21.8 Resumen 498PROBLEMAS Y PUNTOS POR EVALUAR 499LECTURAS ADICIONALES Y FUENTES DE INFORMACIN 500

    CAPTULO 22 ADMINISTRACIN DE LA CONFIGURACIN DEL SOFTWARE 501

    22.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 505

    22.2 El repositorio ACS 50622.2.1 El papel del repositorio 50622.2.2 Caractersticas y contenido generales 50722.2.3 Caractersticas ACS 507

    22.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 515

    22.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

    00Pressman(i-xxx)prelim.indd xx00Pressman(i-xxx)prelim.indd xx 2/2/10 11:40:172/2/10 11:40:17

  • CONTENIDO xxi

    22.4.4 Administracin del cambio 52022.4.5 Control de versin 52222.4.6 Auditora y reporte 522

    22.5 Resumen 523PROBLEMAS Y PUNTOS POR EVALUAR 524LECTURAS ADICIONALES Y FUENTES DE INFORMACIN 525

    CAPTULO 23 MTRICAS DE PRODUCTO 526

    23.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 530

    23.2 Mtricas para el modelo de requerimientos 53123.2.1 Mtrica basada en funciones 53123.2.2 Mtricas para calidad de la especificacin 534

    23.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 545

    23.4 Mtricas de diseo para webapps 54523.5 Mtricas para cdigo fuente 54723.6 Mtricas para pruebas 548

    23.6.1 Mtricas de Halstead aplicadas para probar 54923.6.2 Mtricas para pruebas orientadas a objetos 549

    23.7 Mtricas para mantenimiento 55023.8 Resumen 551PROBLEMAS Y PUNTOS POR EVALUAR 551LECTURAS Y FUENTES DE INFORMACIN ADICIONALES 552

    PARTE CUATRO ADMINISTRACIN DE PROYECTOS DE SOFTWARE 553

    CAPTULO 24 CONCEPTOS DE ADMINISTRACIN DE PROYECTO 554

    24.1 El espectro administrativo 55524.1.1 El personal 55524.1.2 El producto 55524.1.3 El proceso 55624.1.4 El proyecto 556

    24.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 561

    24.3 El producto 56224.3.1 mbito del software 56224.3.2 Descomposicin del problema 563

    24.4 El proceso 56324.4.1 Fusin de producto y proceso 56424.4.2 Descomposicin del proceso 564

    00Pressman(i-xxx)prelim.indd xxi00Pressman(i-xxx)prelim.indd xxi 2/2/10 11:40:172/2/10 11:40:17

  • xxii CONTENIDO

    24.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 569

    CAPTULO 25 MTRICAS DE PROCESO Y DE PROYECTO 571

    25.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 574

    25.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 580

    25.3 Mtricas para calidad de software 58225.3.1 Medicin de la calidad 58325.3.2 Eficiencia en la remocin del defecto 584

    25.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 586

    25.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 591

    CAPTULO 26 ESTIMACIN PARA PROYECTOS DE SOFTWARE 593

    26.1 Observaciones acerca de las estimaciones 59426.2 El proceso de planificacin del proyecto 59526.3 mbito y factibilidad del software 59526.4 Recursos 596

    26.4.1 Recursos humanos 59626.4.2 Recursos de software reutilizables 59726.4.3 Recursos ambientales 598

    26.5 Estimacin de proyectos de software 59826.6 Tcnicas de descomposicin 599

    26.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 607

    26.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

    00Pressman(i-xxx)prelim.indd xxii00Pressman(i-xxx)prelim.indd xxii 2/2/10 11:40:172/2/10 11:40:17

  • CONTENIDO xxiii

    26.8 Estimacin para proyectos orientados a objetos 61126.9 Tcnicas de estimacin especializadas 612

    26.9.1 Estimacin para desarrollo gil 61226.9.2 Estimacin para webapp 613

    26.10 La decisin hacer/comprar 61426.10.1 Creacin de un rbol de decisin 61526.10.2 Outsourcing 616

    26.11 Resumen 617PROBLEMAS Y PUNTOS POR EVALUAR 617LECTURAS Y FUENTES DE INFORMACIN ADICIONALES 618

    CAPTULO 27 CALENDARIZACIN DEL PROYECTO 620

    27.1 Conceptos bsicos 62127.2 Calendarizacin del proyecto 622

    27.2.1 Principios bsicos 62327.2.2 Relacin entre personal y esfuerzo 62427.2.3 Distribucin de esfuerzo 625

    27.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 627

    27.4 Definicin de una red de tareas 62827.5 Calendarizacin 629

    27.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 633

    27.6 Anlisis de valor ganado 63527.7 Resumen 637PROBLEMAS Y PUNTOS POR EVALUAR 637LECTURAS Y FUENTES DE INFORMACIN ADICIONALES 638

    CAPTULO 28 ADMINISTRACIN DEL RIESGO 640

    28.1 Estrategias reactivas de riesgo frente a estrategias proactivas de riesgo 64128.2 Riesgos de software 64128.3 Identificacin de riesgos 642

    28.3.1 Valoracin del riesgo de proyecto global 64328.3.2 Componentes y promotores de riesgo 644

    28.4 Proyeccin del riesgo 64428.4.1 Elaboracin de una lista de riesgos 64528.4.2 Valoracin de impacto de riesgo 647

    28.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 653

    CAPTULO 29 MANTENIMIENTO Y REINGENIERA 655

    29.1 Mantenimiento de software 65629.2 Soportabilidad del software 65729.3 Reingenera 65829.4 Reingeniera de procesos de empresa 658

    29.4.1 Procesos empresariales 65929.4.2 Un modelo RPE 659

    00Pressman(i-xxx)prelim.indd xxiii00Pressman(i-xxx)prelim.indd xxiii 2/2/10 11:40:172/2/10 11:40:17

  • xxiv CONTENIDO

    29.5 Reingeniera de software 66129.5.1 Un modelo de proceso de reingeniera de software 66129.5.2 Actividades de reingeniera de software 662

    29.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 667

    29.7 Reestructuracin 66829.7.1 Reestructuracin de cdigo 66829.7.2 Reestructuracin de datos 668

    29.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 671

    29.9 Economa de la reingeniera 67129.10 Resumen 672PROBLEMAS Y PUNTOS POR EVALUAR 673LECTURAS Y FUENTES DE INFORMACIN ADICIONALES 674

    PARTE CINCO TEMAS AVANZADOS 675

    CAPTULO 30 MEJORAMIENTO DEL PROCESO DE SOFTWARE 676

    30.1 Qu es mps? 67730.1.1 Enfoques del MPS 67730.1.2 Modelos de madurez 67930.1.3 El MPS es para todos? 680

    30.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 685

    30.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 694

    CAPTULO 31 TENDENCIAS EMERGENTES EN INGENIERA DEL SOFTWARE 695

    31.1 Evolucin tecnolgica 69631.2 Observacin de las tendencias en ingeniera del software 69731.3 Identificacin de tendencias blandas 699

    31.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 703

    31.4 Direcciones de la tecnologa 70431.4.1 Tendencias de proceso 70531.4.2 El gran desafo 706

    00Pressman(i-xxx)prelim.indd xxiv00Pressman(i-xxx)prelim.indd xxiv 2/2/10 11:40:172/2/10 11:40:17

  • CONTENIDO xxv

    31.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 710

    31.5 Tendencias relacionadas con herramientas 71131.5.1 Herramientas que responden a tendencias blandas 71231.5.2 Herramientas que abordan tendencias tecnolgicas 714

    31.6 Resumen 714PROBLEMAS Y PUNTOS POR EVALUAR 715LECTURAS Y FUENTES DE INFORMACIN ADICIONALES 715

    CAPTULO 32 COMENTARIOS FINALES 717

    32.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 722

    APNDICE 1 Introduccin a UML 725APNDICE 2 Conceptos orientados a objeto 743REFERENCIAS 751NDICE ANALTICO 767

    00Pressman(i-xxx)prelim.indd xxv00Pressman(i-xxx)prelim.indd xxv 2/2/10 11:40:172/2/10 11:40:17

  • 00Pressman(i-xxx)prelim.indd xxvi00Pressman(i-xxx)prelim.indd xxvi 2/2/10 11:40:182/2/10 11:40:18

  • Cuando el software de computadora triunfa (al satisfacer las necesidades de las personas que lo usan, trabajar sin fallos durante largos periodos, ser fcil de modificar e incluso ms fcil de usar) puede y debe cambiar las cosas a fin de mejorar. Pero cuando el soft-ware fracasa (cuando sus usuarios no estn satisfechos, es proclive al error, es difcil de cambiar e incluso ms difcil de usar) pueden ocurrir, y ocurren, cosas malas. Todo mundo quiere cons-truir software que haga mejor las cosas y que evite las malas que acechan en la sombra de los esfuerzos fallidos. Para triunfar, se necesita disciplina al momento de disear y construir el software. Es necesario un enfoque de ingeniera.

    Han pasado casi tres dcadas desde que se escribi la primera edicin de este libro. Durante ese tiempo, la ingeniera del software evolucion desde una oscura idea practicada por un n-mero relativamente pequeo de fanticos hasta una legtima disciplina de la ingeniera. En la actualidad, se le reconoce como una materia merecedora de investigacin seria, estudio con-cienzudo y debate turbulento. A lo largo de toda la industria, el ingeniero de software sustituy al programador como el ttulo laboral de preferencia. Los modelos de proceso de software, los mtodos de ingeniera de software y las herramientas del software se adoptaron exitosamente a travs de un amplio espectro de segmentos industriales.

    Aunque los gestores y profesionales reconocen por igual la necesidad de un enfoque del software ms disciplinado, continan debatiendo la forma en la que la disciplina debe aplicarse. Muchos individuos y compaas todava desarrollan el software de manera fortuita, incluso cuando construyen sistemas para atender las tecnologas ms avanzadas de la actualidad. Mu-chos profesionales 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-na el debate y la controversia en torno de la verdadera naturaleza del enfoque de la ingeniera del software. El estatus de la ingeniera del software es un estudio en contrastes. Las actitudes han cambiado, se ha progresado, pero todava falta mucho por hacer antes de que la disciplina alcance madurez plena.

    La sptima edicin de Ingeniera del software: un enfoque prctico tiene la intencin de funcio-nar como gua hacia una disciplina de ingeniera que madura. Como las seis ediciones que la precedieron, la sptima se dirige a estudiantes y profesionales, y conserva su atractivo como gua para el profesional industrial y como introduccin abarcadora para el estudiante en los niveles superiores de pregrado o en el primer ao de graduado.

    La sptima edicin es considerablemente ms que una simple actualizacin. El libro se revis y reestructur para mejorar el flujo pedaggico y enfatizar nuevos e importantes procesos y prcticas 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-sentante de 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 dividir mejor los temas y ayudar a los profesores que tal vez no tengan tiempo para completar todo el libro en un semestre.

    La parte 1, El proceso, presenta varias visiones diferentes del proceso de software, considera todos los modelos de proceso importantes y aborda el debate entre las filosofas de proceso

    PREFACIO

    xxvii

    00Pressman(i-xxx)prelim.indd xxvii00Pressman(i-xxx)prelim.indd xxvii 2/2/10 11:40:182/2/10 11:40:18

  • prescriptivo y gil. La parte 2, Modelado, presenta los mtodos de anlisis y diseo con nfasis en las tcnicas orientadas a objeto y al modelado UML. Tambin se considera el diseo basa-do en patrn y el diseo para aplicaciones web. La parte 3, Gestin de la calidad, presenta los conceptos, procedimientos, tcnicas y mtodos que permiten a un equipo de software valorar la calidad del software, revisar los productos de trabajo de la ingeniera del software, realizar procedimientos SQA y aplicar una estrategia y tcticas de prueba efectivas. Adems, tambin se considera el modelado formal y los mtodos de verificacin. La parte 4, Gestin de proyectos de software, presenta temas que son relevantes a quienes planean, gestionan y controlan un pro-yecto de desarrollo de software. La parte 5, Temas avanzados, considera el mejoramiento del proceso de software y las tendencias en la ingeniera del software. Al continuar con la tradicin de las ediciones pasadas, a lo largo del libro se usa una serie de recuadros para presentar las experiencias y tribulaciones de un equipo de software (ficticio) y para proporcionar materiales complementarios acerca de los mtodos y herramientas que son relevantes para los temas del captulo. Dos nuevos apndices proporcionan breves tutoriales acerca del UML y del pensa-miento orientado 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-mas con base en el tiempo disponible y las necesidades del estudiante. Un curso de todo un semestre podra construirse en torno de uno o ms de las cinco partes. Uno de evaluacin de ingeniera del software seleccionara captulos de las cinco. Uno de ingeniera del software que enfatice el anlisis y el diseo elegira temas de las partes 1 y 2. Un curso de ingeniera del soft-ware orientado a pruebas seleccionara temas de las partes 1 y 3, con una breve incursin en la parte 2. Un curso administrativo subrayara las partes 1 y 4.

    Reconocimientos. Mi trabajo en las siete ediciones de Ingeniera del software: un enfoque prc-tico ha sido el proyecto tcnico continuo ms largo de mi vida. Aun cuando la escritura ces, la informacin extrada de la literatura tcnica contina asimilndose y organizndose, y las crti-cas y 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 en medios electrnicos) que me han proporcionado comprensin, ideas y comentarios adicionales durante casi 30 aos.

    Agradezco especialmente a Tim Lethbridge, de la Universidad de Ottawa, quien me auxili en el desarrollo de los ejemplos UML y OCL, y quien desarroll el estudio de caso que acompaa a 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 para Bruce Maxim, de la Universidad de Michigan-Dearborn, quien me auxili en el desarrollo de gran 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 crticas bien pensadas han sido invaluables.

    Osman Balci,Virginia Tech University

    Max Fomitchev,Penn State University

    Jerry (Zeyu) Gao,San Jose State University

    Guillermo Garcia,Universidad Alfonso X Madrid

    Pablo Gervas,Universidad Complutense de Madrid

    SK Jain,National Institute of Technology Hamirpur

    Saeed Monemi,Cal Poly Pomona

    Ahmed Salem,California State University

    Vasudeva Varma,IIIT Hyderabad

    El contenido de la sptima edicin de Ingeniera del software: un enfoque prctico fue confor-mado por profesionales de la industria, profesores universitarios y estudiantes, quienes usaron ediciones anteriores del libro y tomaron tiempo para comunicar sus sugerencias, crticas e ideas.

    xxviii PREFACIO

    00Pressman(i-xxx)prelim.indd xxviii00Pressman(i-xxx)prelim.indd xxviii 2/2/10 11:40:182/2/10 11:40:18

  • Mi agradecimiento a cada uno de ustedes. Adems, mi reconocimiento personal a nuestros muchos clientes industriales en todo el mundo, quienes, ciertamente, me ensearon tanto o ms de lo que yo podra haberles enseado en algn momento.

    Conforme las ediciones de este libro evolucionaban, mis hijos, Mathew y Michael, crecieron de nios a hombres. Su madurez, carcter y xito en el mundo real han sido una inspiracin para m. Nada me ha llenado ms de orgullo. Y finalmente, a Brbara, mi amor y agradecimiento por tolerar las muchsimas horas en la oficina y por alentar todava otra edicin de el libro.

    Roger S. Pressman

    PREFACIO xxix

    00Pressman(i-xxx)prelim.indd xxix00Pressman(i-xxx)prelim.indd xxix 2/2/10 11:40:182/2/10 11:40:18

  • 00Pressman(i-xxx)prelim.indd xxx00Pressman(i-xxx)prelim.indd xxx 2/2/10 11:40:182/2/10 11:40:18

  • 1C A P T U L O

    1EL SOFTWARE Y LA INGENIERADE SOFTWARECO N C E P T O S C L A V E actividades estructurales . . . . 12

    actividades sombrilla. . . . . . . 12

    caractersticas del software . . . 3

    dominios de aplicacin . . . . . . . 6

    ingeniera de software . . . . . 10

    mitos del software . . . . . . . . 18

    prctica . . . . . . . . . . . . . . . . 15

    principios . . . . . . . . . . . . . . . 16

    proceso del software. . . . . . . 12

    software heredado . . . . . . . . . 8

    webapps . . . . . . . . . . . . . . . . 9

    Qu es? El software de computadora es el producto que construyen los programadores profesionales y al que despus le dan manteni-miento durante un largo tiempo. Incluye pro-

    gramas que se ejecutan en una computadora de cual-quier tamao y arquitectura, contenido que se presenta a medida de que se ejecutan los programas de cmputo e informacin descriptiva tanto en una copia dura como en formatos virtuales que engloban virtualmente a cualesquie-ra medios electrnicos. La ingeniera de software est for-mada por un proceso, un conjunto de mtodos (prcticas) y un arreglo de herramientas que permite a los profesiona-les elaborar software de cmputo de alta calidad.

    Quin lo hace? Los ingenieros de software elaboran y dan mantenimiento al software, y virtualmente cada perso-na lo emplea en el mundo industrializado, ya sea en forma directa o indirecta.

    Por qu es importante? El software es importante por-que afecta a casi todos los aspectos de nuestras vidas y ha invadido nuestro comercio, cultura y actividades cotidia-

    nas. La ingeniera de software es importante porque nos permite construir sistemas complejos en un tiempo razona-ble y con alta calidad.

    Cules son los pasos? El software de computadora se construye del mismo modo que cualquier producto exitoso, con la aplicacin de un proceso gil y adaptable para obtener un resultado de mucha calidad, que satisfaga las necesidades de las personas que usarn el producto. En estos pasos se aplica el enfoque de la ingeniera de soft-ware.

    Cul es el producto final? Desde el punto de vista de un ingeniero de software, el producto final es el conjunto de programas, contenido (datos) y otros productos termi-nados que constituyen el software de computadora. Pero desde la perspectiva del usuario, el producto final es la informacin resultante que de algn modo hace mejor al mundo en el que vive.

    Cmo me aseguro de que lo hice bien? Lea el resto de este libro, seleccione aquellas ideas que sean aplicables al software que usted hace y aplquelas a su trabajo.

    U N A M I R A D A R P I D A

    Tena la apariencia clsica de un alto ejecutivo de una compaa importante de software a la mitad de los 40, con las sienes comenzando a encanecer, esbelto y atltico, con ojos 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 tu empresa 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 lo

    compras, lo posees y tu trabajo consiste en administrarlo est llegando a su fin. Hoy da, con Web 2.0 y la computacin ubicua cada vez ms fuerte, vamos a ver una generacin de software por completo diferente. Se distribuir por internet y se ver exactamente como si estuviera ins-talado en 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 no tendrn que preocuparse por las cinco diferentes versiones de la misma App que utilizan dece-nas de miles de usuarios.

    Sonri. Absolutamente. Slo la versin ms reciente estar en nuestros servidores. Cuando hagamos un cambio o correccin, actualizaremos funcionalidad y contenido a cada usuario. Todos lo tendrn en forma instantnea

    Hice 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 hacer

    una ingeniera de software an mejor. El problema es que tenemos que hacerlo rpido porque el mercado se ha acelerado en cada rea de aplicacin.

    01Pressman(001-024).indd 101Pressman(001-024).indd 1 14/1/10 13:30:5314/1/10 13:30:53

  • 2 CAPTULO 1 EL SOFTWARE Y LA INGENIERA DE SOFTWARE

    Est 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 indispensable para los negocios, ciencias e ingeniera, ni que permitira la creacin de tecnologas nuevas (por ejemplo, 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 el software evolucionara poco a poco de un producto a un servicio cuando compaas de software sobre pedido proporcionaran funcionalidad justo a tiempo a travs de un navegador web, que una compaa de software sera ms grande y tendra ms influencia que casi todas las empre-sas de la era industrial, que una vasta red llamada internet sera operada con software y evolu-cionara y cambiara todo, desde la investigacin en bibliotecas y la compra de productos para el consumidor hasta el discurso poltico y los hbitos de encuentro de los adultos jvenes (y no tan jvenes).

    Nadie pudo prever que habra software incrustado en sistemas de toda clase: de transporte, mdicos, de telecomunicaciones, militares, industriales, de entretenimiento, en mquinas de oficina la lista es casi infinita. Y si usted cree en la ley de las consecuencias inesperadas, hay muchos 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 ejecutar estas actividades de mantenimiento absorbera ms personas y recursos que todo el trabajo aplicado a la creacin de software nuevo.

    Conforme ha aumentado la importancia del software, la comunidad de programadores ha tratado continuamente de desarrollar tecnologas que hagan ms fcil, rpida y barata la elabo-racin de programas de cmputo de alta calidad. Algunas de estas tecnologas se dirigen a un dominio especfico de aplicaciones (por ejemplo, diseo e implantacin de un sitio web), otras se centran en un dominio tecnolgico (sistemas orientados a objetos o programacin orientada a 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-babilidades de 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. Ms vale que est bien hecho.

    Este libro presenta una estructura que puede ser utilizada por aquellos que hacen software de cmputo personas que deben hacerlo bien. La estructura incluye un proceso, un conjunto de 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-hculo para entregar un producto. En su forma de producto, brinda el potencial de cmputo in-corporado en el hardware de cmputo o, con ms amplitud, en una red de computadoras a las

    Me recargu en la espalda y coloqu mis manos en mi nuca. Ya sabes lo que se dice pue-des tenerlo rpido o bien hecho o barato. Escoge dos de estas caractersticas

    Elijo 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 otra

    generacin ms de tcnicos de que as es

    Cita:

    Las ideas y los descubrimientos tecnolgicos son los motores que impulsan el crecimiento econ-mico.

    Wall Street Journal

    01Pressman(001-024).indd 201Pressman(001-024).indd 2 14/1/10 13:30:5514/1/10 13:30:55

  • CAPTULO 1 EL SOFTWARE Y LA INGENIERA DE SOFTWARE 3

    que se accede por medio de un hardware local. Ya sea que resida en un telfono mvil u opere en el interior de una computadora central, el software es un transformador de informacinproduce, administra, adquiere, modifica, despliega o transmite informacin que puede ser tan simple como un solo bit o tan compleja como una presentacin con multimedios generada a partir de datos obtenidos de decenas de fuentes independientes. Como vehculo utilizado para distribuir el producto, el software acta como la base para el control de la computadora (siste-mas operativos), para la comunicacin de informacin (redes) y para la creacin y control de otros programas (herramientas y ambientes de software).

    El software distribuye el producto ms importante de nuestro tiempo: informacin. Trans-forma los datos personales (por ejemplo, las transacciones financieras de un individuo) de modo que puedan ser ms tiles en un contexto local, administra la informacin de negocios para mejorar 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-tecturas de computadora, el gran incremento en la memoria y capacidad de almacenamiento, y una amplia variedad de opciones de entradas y salidas exticas han propiciado la existencia de sistemas basados en computadora ms sofisticados y complejos. Cuando un sistema tiene xito, la sofisticacin y complejidad producen resultados deslumbrantes, pero tambin plantean pro-blemas enormes para aquellos que deben construir sistemas complejos.

    En la actualidad, la enorme industria del software se ha convertido en un factor dominante en las economas del mundo industrializado. Equipos de especialistas de software, cada uno centrado 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-tas que se haca aquel programador son las mismas que surgen cuando se construyen sistemas modernos 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 nuestros clientes?

    Por qu dedicamos tanto tiempo y esfuerzo a mantener los programas existentes?

    Por qu seguimos con dificultades para medir el avance mientras se desarrolla y mantiene el software?

    stas y muchas otras preguntas, denotan la preocupacin sobre el software y la manera en que se desarrolla, preocupacin que ha llevado a la adopcin de la prctica de la ingeniera del software.

    1.1.1 Definicin de software

    En la actualidad, la mayora de profesionales y muchos usuarios tienen la fuerte sensacin de que 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 las

    caractersticas, funcin y desempeo buscados; 2) estructuras de datos que permiten que los progra-

    PUNTOCLAVE

    El software es tanto un producto como un vehculo para entregar un producto.

    Cita:

    El software es un lugar donde se siembran sueos y se cose-chan pesadillas, una cinega abstracta y mstica en la que terribles demonios luchan contra panaceas mgicas, un mundo de hombres lobo y balas de plata.

    Brad J. Cox

    1 En un excelente libro de ensayos sobre el negocio del software, Tom DeMarco [DeM95] defiende el punto de vista

    contrario. 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 nos

    ayudar a continuar el extraordinario nivel de logro que siempre ha distinguido a la industria del software.

    Cmo se define software??

    01Pressman(001-024).indd 301Pressman(001-024).indd 3 14/1/10 13:30:5514/1/10 13:30:55

  • 4 CAPTULO 1 EL SOFTWARE Y LA INGENIERA DE SOFTWARE

    mas manipulen en forma adecuada la informacin, y 3) informacin descriptiva tanto en papel como

    en 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 nuestra

    comprensin. Para asimilar lo anterior, es importante examinar las caractersticas del software que lo hacen diferente de otros objetos que construyen los seres humanos. El software es ele-mento de un sistema lgico y no de uno fsico. Por tanto, tiene caractersticas que difieren con-siderablemente de 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 se logra a travs de un buen diseo, pero la fase de manufactura del hardware introduce problemas 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-dos y el trabajo logrado es diferente por completo (vase el captulo 24). Las dos activi-dades requieren la construccin de un producto, pero los enfoques son distintos. Los costos del software se concentran en la ingeniera. Esto significa que los proyectos de software 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-llas relativamente elevada en una etapa temprana de su vida (fallas que con frecuencia son atribuibles a defectos de diseo o manufactura); los defectos se corrigen y la tasa de fallas se abate a un nivel estable (muy bajo, por fortuna) durante cierto tiempo. No obstante, conforme pasa el tiempo, la tasa de fallas aumenta de nuevo a medida que los componentes del hardware resienten los efectos acumulativos de suciedad, vibracin, abuso, temperaturas extremas y muchos otros inconvenientes ambientales. En pocas palabras, el hardware comienza a desgastarse.

    El software no es susceptible a los problemas ambientales que hacen que el hard-ware se desgaste. Por tanto, en teora, la curva de la tasa de fallas adopta la forma de la curva idealizada que se aprecia en la figura 1.2. Los defectos ocultos ocasionarn ta-

    PUNTOCLAVE

    El software se modifica con intelecto, no se manufactura.

    DesgasteMortalidadinfantil

    Tiempo

    Tasa

    de

    falla

    FIGURA 1.1

    Curva de fallas del hardware

    PUNTOCLAVE

    El software no se desgasta, pero s se deteriora.

    01Pressman(001-024).indd 401Pressman(001-024).indd 4 14/1/10 13:30:5514/1/10 13:30:55

  • CAPTULO 1 EL SOFTWARE Y LA INGENIERA DE SOFTWARE 5

    sas elevadas de fallas al comienzo de la vida de un programa. Sin embargo, stas se co-rrigen y la curva se aplana, como se indica. La curva idealizada es una gran simplifica-cin de 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-gura 1.2. Durante su vida,2 el software sufrir cambios. Es probable que cuando stos se realicen, se introduzcan errores que ocasionen que la curva de tasa de fallas tenga au-mentos sbitos, como se ilustra en la curva real (vase la figura 1.2). Antes de que la curva vuelva a su tasa de fallas original de estado estable, surge la solicitud de otro cambio que hace que la curva se dispare otra vez. Poco a poco, el nivel mnimo de la tasa de fallas comienza a aumentar: el software se est deteriorando como consecuen-cia del 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. En cambio, no hay refacciones para el software. Cada falla de ste indica un error en el di-seo o 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-nes de cambios, involucran una complejidad considerablemente mayor que el mantenimiento del hardware.

    3. Aunque la industria se mueve hacia la construccin basada en componentes, la mayor parte del software se construye para un uso individualizado.

    A medida que evoluciona una disciplina de ingeniera, se crea un conjunto de compo-nentes estandarizados para el diseo. Los tornillos estndar y los circuitos integrados preconstruidos son slo dos de los miles de componentes estndar que utilizan los in-genieros mecnicos y elctricos conforme disean nuevos sistemas. Los componentes reutilizables han sido creados para que el ingeniero pueda concentrarse en los elemen-tos verdaderamente innovadores de un diseo; es decir, en las partes de ste que repre-sentan algo nuevo. En el mundo del hardware, volver a usar componentes es una parte

    Si quiere reducir el deterioro del software, tendr que mejorar su diseo (captulos 8 a 13).

    CONSEJO

    Tasa de fallasincrementada debidoa efectos colaterales

    Tiempo

    Tasa

    de

    falla

    s

    Cambio

    Curva real

    Curva idealizada

    FIGURA 1.2

    Curvas de falla del software

    2 En realidad, los distintos participantes solicitan cambios desde el momento en que comienza el desarrollo y

    mucho antes de que se disponga de la primera versin.

    PUNTOCLAVE

    Los mtodos de la ingeniera de software llevan a reducir la magnitud de los picos y de la pendiente de la curva real en la figura 1.2.

    Cita:

    Las ideas son los ladrillos con los que se construyen las ideas.

    Jason Zebehazy

    01Pressman(001-024).indd 501Pressman(001-024).indd 5 14/1/10 13:30:5614/1/10 13:30:56

  • 6 CAPTULO 1 EL SOFTWARE Y LA INGENIERA DE SOFTWARE

    natural del proceso de ingeniera. En el del software, es algo que apenas ha empezado a hacerse a gran escala.

    Un componente de software debe disearse e implementarse de modo que pueda volverse a usar en muchos programas diferentes. Los modernos componentes reutiliza-bles incorporan tanto los datos como el procesamiento que se les aplica, lo que permite que el ingeniero de software cree nuevas aplicaciones a partir de partes susceptibles de volverse a usar.3 Por ejemplo, las actuales interfaces interactivas de usuario se constru-yen con componentes reutilizables que permiten la creacin de ventanas grficas, me-ns desplegables y una amplia variedad de mecanismos de interaccin. Las estructuras de datos y el detalle de procesamiento que se requieren para construir la interfaz estn contenidos en una librera de componentes reusables para tal fin.

    1.1.2 Dominios de aplicacin del software

    Actualmente, hay siete grandes categoras de software de computadora que plantean retos continuos 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-tas para 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 todo datos indeterminados. En cualquier caso, el rea de software de sistemas se caracteriza por: gran interaccin con el hardware de la computadora, uso intensivo por parte de usua-rios mltiples, operacin concurrente que requiere la secuenciacin, recursos compartidos y administracin de un proceso sofisticado, estructuras complejas de datos e interfaces ex-ternas mltiples.

    Software de aplicacin: programas aislados que resuelven una necesidad especfica de negocios. Las aplicaciones en esta rea procesan datos comerciales o tcnicos en una forma que facilita las operaciones de negocios o la toma de decisiones administrativas o tcnicas. Adems de las aplicaciones convencionales de procesamiento de datos, el soft-ware de 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-tura en tiempo real).

    Software de ingeniera y ciencias: se ha caracterizado por algoritmos devoradores de nmeros. Las aplicaciones van de la astronoma a la vulcanologa, del anlisis de tensio-nes en automviles a la dinmica orbital del transbordador espacial, y de la biologa mo-lecular a la manufactura automatizada. Sin embargo, las aplicaciones modernas dentro del rea 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-nes interactivas, han comenzado a hacerse en tiempo real e incluso han tomado caracters-ticas del software de sistemas.

    Software incrustado: reside dentro de un producto o sistema y se usa para implementar y controlar caractersticas y funciones para el usuario final y para el sistema en s. El software incrustado ejecuta funciones limitadas y particulares (por ejemplo, control del tablero de un horno de microondas) o provee una capacidad significativa de funcionamiento y control

    3 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 las

    salidas. 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 libreras ms completas de software compartido y libre.

    01Pressman(001-024).indd 601Pressman(001-024).indd 6 14/1/10 13:30:5614/1/10 13:30:56

  • CAPTULO 1 EL SOFTWARE Y LA INGENIERA DE SOFTWARE 7

    (funciones digitales en un automvil, como el control del combustible, del tablero de con-trol y de los sistemas de frenado).

    Software de lnea de productos: es diseado para proporcionar una capacidad espec-fica para uso de muchos consumidores diferentes. El software de lnea de productos se centra 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, hojas de clculo, grficas por computadora, multimedios, entretenimiento, administracin de base de datos y aplicaciones para finanzas personales o de negocios).

    Aplicaciones web: llamadas webapps, esta categora de software centrado en redes agrupa una amplia gama de aplicaciones. En su forma ms sencilla, las webapps son poco ms que un conjunto de archivos de hipertexto vinculados que presentan informacin con uso de texto y grficas limitadas. Sin embargo, desde que surgi Web 2.0, las webapps es-tn evolucionando hacia ambientes de cmputo sofisticados que no slo proveen caracte-rsticas aisladas, funciones de cmputo y contenido para el usuario final, sino que tambin estn integradas con bases de datos corporativas y aplicaciones de negocios.

    Software de inteligencia artificial: hace uso de algoritmos no numricos para resolver problemas complejos que no son fciles de tratar computacionalmente o con el anlisis di-recto. Las aplicaciones en esta rea incluyen robtica, sistemas expertos, reconocimiento de 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 de software en una o ms de estas categoras. En ciertos casos se elaboran sistemas nuevos, pero en muchos otros se corrigen, adaptan y mejoran aplicaciones ya existentes. No es raro que una joven ingeniera de software trabaje en un programa de mayor edad que la de ella Las genera-ciones pasadas de los trabajadores del software dejaron un legado en cada una de las categoras mencionadas. Por fortuna, la herencia que dejar la actual generacin aligerar la carga de los futuros 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 inalmbricas quiz lleve pronto a la computacin verdaderamente ubicua y distribuida. El reto para los ingenieros de software ser desarrollar software de sistemas y aplicacin que permita a dispositivos mviles, computadoras personales y sistemas empresariales comunicarse a travs de redes enormes.

    Construccin de redes: la red mundial (World Wide Web) se est convirtiendo con rapi-dez tanto en un motor de computacin como en un proveedor de contenido. El desafo para los ingenieros de software es hacer arquitecturas sencillas (por ejemplo, planeacin fi-nanciera personal y aplicaciones sofisticadas que proporcionen un beneficio a mercados objetivo de usuarios finales en todo el mundo).

    Fuente abierta: tendencia creciente que da como resultado la distribucin de cdigo fuente para aplicaciones de sistemas (por ejemplo, sistemas operativos, bases de datos y ambientes de desarrollo) de modo que mucha gente pueda contribuir a su desarrollo. El de-safo para los ingenieros de software es elaborar cdigo fuente que sea autodescriptivo, y tambin, lo que es ms importante, desarrollar tcnicas que permitirn tanto a los consu-midores como a los desarrolladores saber cules son los cambios hechos y cmo se mani-fiestan dentro del software.

    Es indudable que cada uno de estos nuevos retos obedecer a la ley de las consecuencias im-previstas y 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 que tenga sentido comn.

    Marvin Minsky

    Cita:

    No siempre puedes predecir, pero siempre puedes prepararte.

    Annimo

    01Pressman(001-024).indd 701Pressman(001-024).indd 7 14/1/10 13:30:5714/1/10 13:30:57

  • 8 CAPTULO 1 EL SOFTWARE Y LA INGENIERA DE SOFTWARE

    sarrollando un proceso que sea gil y suficientemente adaptable para que acepte los cambios profundos en la tecnologa y las reglas de los negocios que seguramente surgirn en la dcada siguiente.

    1.1.3 Software heredado

    Cientos de miles de programas de cmputo caen en uno de los siete dominios amplios de apli-cacin que 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 centro de 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-

    cados de manera continua para que satisfagan los cambios en los requerimientos de los negocios y

    plataformas de computacin. La proliferacin de tales sistemas es causa de dolores de cabeza para

    las 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-dos continan siendo un apoyo para las funciones bsicas del negocio y son indispensables para ste. Adems, el software heredado se caracteriza por su longevidad e importancia crti-ca para 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-bles de extenderse, cdigo confuso, documentacin mala o inexistente, casos y resultados de pruebas que nunca se archivaron, una historia de los cambios mal administrada la lista es muy larga. A pesar de esto, dichos sistemas dan apoyo a las funciones bsicas del negocio y son indispensables para ste. Qu hacer?

    La nica respuesta razonable es: hacer nada, al menos hasta que el sistema heredado tenga un cambio significativo. Si el software heredado satisface las necesidades de sus usuarios y corre de manera confiable, entonces no falla ni necesita repararse. Sin embargo, conforme pase el tiempo ser frecuente que los sistemas de software evolucionen por una o varias de las si-guientes razones:

    El software debe adaptarse para que cumpla las necesidades de los nuevos ambientes del 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 datos modernos.

    La arquitectura del software debe redisearse para hacerla viable dentro de un ambiente de 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 es desarrollar metodologas que se basen en el concepto de evolucin; es decir, el concepto de que los sistemas de software cambian continuamente, que los nuevos sistemas de software se

    5 En este caso, la calidad se juzga con base en el pensamiento moderno de la ingeniera de software, criterio algo

    injusto, ya que algunos conceptos y principios de la ingeniera de software moderna tal vez no hayan sido bien

    entendidos en la poca en que se desarroll el software heredado.

    Qu hago si encuentro un sistema heredado de mala calidad?

    ?

    Qu tipos de cambios se hacen a los sistemas heredados?

    ?

    Todo ingeniero de software debe reconocer que el cambio es natural. No trate de evitarlo.

    CONSEJO

    01Pressman(001-024).indd 801Pressman(001-024).indd 8 14/1/10 13:30:5714/1/10 13:30:57

  • CAPTULO 1 EL SOFTWARE Y LA INGENIERA DE SOFTWARE 9

    desarrollan a partir de los antiguos y [] que todo debe operar entre s y cooperar con cada uno de 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 ms que un conjunto de archivos de hipertexto vinculados que presentaban la informacin con el empleo de texto y grficas limitadas. Al pasar el tiempo, el aumento de HTML por medio de herramientas de desarrollo (XML, Java) permiti a los ingenieros de la web brindar capacidad de cmputo junto con contenido de informacin. Haban nacido los sistemas y aplicaciones ba-sados en la web6 (denomin a stas en forma colectiva como webapps). En la actualidad, las webapps se han convertido en herramientas sofisticadas de cmputo que no slo proporcionan funciones aisladas al usuario final, sino que tambin se han integrado con bases de datos cor-porativas y 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] sugiere que los sistemas y aplicaciones basados en web involucran una mezcla entre las publicaciones impresas y el desarrollo de software, entre la mercadotecnia y la computacin, entre las comu-nicaciones internas y las relaciones exteriores, y entre el arte y la tecnologa. La gran mayora de webapps presenta los siguientes atributos:

    Uso intensivo de redes. Una webapp reside en una red y debe atender las necesidades de una comunidad diversa de clientes. La red permite acceso y comunicacin mundiales (por ejemplo, internet) o tiene acceso y comunicacin limitados (por ejemplo, una intranet corporativa).

    Concurrencia. A la webapp puede acceder un gran nmero de usuarios a la vez. En mu-chos casos, los patrones de uso entre los usuarios finales varan mucho.

    Carga impredecible. El nmero de usuarios de la webapp cambia en varios rdenes de magnitud de un da a otro. El lunes tal vez la utilicen cien personas, el jueves quiz 10 000 usen el sistema.

    Rendimiento. Si un usuario de la webapp debe esperar demasiado (para entrar, para el procesamiento por parte del servidor, para el formado y despliegue del lado del cliente), l o ella quiz decidan irse a otra parte.

    Disponibilidad. Aunque no es razonable esperar una disponibilidad de 100%, es fre-cuente que los usuarios de webapps populares demanden acceso las 24 horas de los 365 das del ao. Los usuarios en Australia o Asia quiz demanden acceso en horas en las que las aplicaciones internas de software tradicionales en Norteamrica no estn en lnea por razones de mantenimiento.

    Orientadas a los datos. La funcin principal de muchas webapp es el uso de hiperme-dios para 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 en bases de datos que no son parte integral del ambiente basado en web (por ejemplo, comer-cio electrnico o aplicaciones financieras).

    Cita:

    Cuando veamos cualquier tipo de estabilizacin, la web se habr convertido en algo com-pletamente diferente.

    Louis Monier

    6 En el contexto de este libro, el trmino aplicacin web (webapp) agrupa todo, desde una simple pgina web que

    ayude al consumidor a calcular el pago del arrendamiento de un automvil hasta un sitio web integral que pro-

    porcione servicios completos de viaje para gente de negocios y vacacionistas. En esta categora se incluyen sitios

    web completos, funcionalidad especializada dentro de sitios web y aplicaciones de procesamiento de informa-

    cin que residen en internet o en una intranet o extranet.

    Qu caracterstica diferencia las webapps de otro software?

    ?

    01Pressman(001-024).indd 901Pressman(001-024).indd 9 14/1/10 13:30:5814/1/10 13:30:58

  • 10 CAPTULO 1 EL SOFTWARE Y LA INGENIERA DE SOFTWARE

    Contenido sensible. La calidad y naturaleza esttica del contenido constituye un rasgo importante de la calidad de una webapp.

    Evolucin continua. A diferencia del software de aplicacin convencional que evolu-ciona a lo largo de una serie de etapas planeadas y separadas cronolgicamente, las aplica-ciones web evolucionan en forma continua. No es raro que ciertas webapp (especfica-mente su contenido) se actualicen minuto a minuto o que su contenido se calcule en cada solicitud.

    Inmediatez. Aunque la inmediatez necesidad apremiante de que el software llegue con rapidez al mercado es una caracterstica en muchos dominios de aplicacin, es frecuente que las webapps tengan plazos de algunos das o semanas para llegar al mercado.7

    Seguridad. 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-sin de los datos, deben implementarse medidas estrictas de seguridad a travs de la infra-estructura de 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, la esttica tiene tanto que ver con el xito como el diseo tcnico.

    Podra argumentarse que otras categoras de aplicaciones estudiadas en la seccin 1.1.2 muestran algunos de los atributos mencionados. Sin embargo, las webapps casi siempre poseen todos ellos.

    1.3 INGENIERA DE SOFTWARECon objeto de elaborar software listo para enfrentar los retos del siglo XXI, el lector debe aceptar algunas realidades sencillas:

    El software se ha incrustado profundamente en casi todos los aspectos de nuestras vidas y, como consecuencia, el nmero de personas que tienen inters en las caractersticas y funciones que brinda una aplicacin especfica8 ha crecido en forma notable. Cuando ha de construirse una aplicacin nueva o sistema incrustado, deben escucharse muchas opiniones. Y en ocasiones parece que cada una de ellas tiene una idea un poco distinta de cules caractersticas y funciones debiera tener el software. Se concluye que debe hacerse un esfuerzo concertado para entender el problema antes de desarrollar una aplica-cin de 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 elaborados por un solo individuo. El software sofisticado, que alguna vez se implement en un ambiente de cmputo predecible y autocontenido, hoy en da se halla incrustado en el interior de todo, desde la electrnica de consumo hasta dispositivos mdicos o sistemas de armamento. La complejidad de estos nuevos sistemas y productos basados en computadora demanda atencin cuidadosa a las interacciones de todos los elementos del 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.

    PUNTOCLAVE

    Entender el problema antes de dar una solucin.

    PUNTOCLAVE

    El diseo es una actividad crucial de la ingeniera de software.

    01Pressman(001-024).indd 1001Pressman(001-024).indd 10