1. Ingeniera del software

2. Ingeniera del software Sptima edicinIAN SOMMERVILLETraduccin Mara Isabel Alfonso Galipienso Antonio Bata Martnez Francisco Mora Lizn Jos Pascual Trigueros Jover Departamento Ciencia de la Computacin e lnteligencia Artificia! Universidad de Alicanre--PEARSON.ddi""()11 ('Sk~'Madrid> Mxico Santaf de Bogot- Buenos Aires> Caracas> Lima Montevideo San Juan > San Jos > Santiago. Sao Paulo Reading. Massachusetts Harlow, England 3. /Datos de catalogacin bibliogrficalNGENlEIA DEL SOFTWARE. SptiJII. edidn 1 SommeniUe ... PEARSON EDUCACIN. S.A .. Madrid. 2005 ISBN: 84-7829.Q74-5 MATERIA: Informtica 681.3 Formato: 195 x 250 mmPginas: 712Todos los derechos reservados. Queda prohibida, salvo excepcin prevista en la Ley, cualquier forma de reproduccin, distribucin, comunicacin pblica y transfonnacin de esta obra sin contar con autorizacin de los titulares de propiedad intelectual, La infraccin de los derechos mencionados puede ser constitutiva de delito contra la propiedad intelectual (arts. 270)' sgts. C6digo Penal). DERECHOS RESERVADOS 2005 por PEARSON EDUCACIN, S.A. Ribera del Loira, 28 28042 Madrid (Espaa) INGENIERA DEL SOFfWARE. Sptima edicin lan Sommerville ISBN: 8478290745 Depsito Legal: M-31.467-2005 PEARSON ADDlSON WESLEY es un sello editorial autorizado de PEARSON EDUCACIN, S.A. Addison-Wesley Publishers Limited 1982, 1984, Pearson Education Limited 1989.2001. 2004 This translation of SOF1WARE ENGINEERING 07 Edition is published by arrangement with Pearson Education Lirnited, United Kingdom Equipo editorial: Editor: Miguel Martn-Romo Tcnico editorial: Marta Caicoya Equipo de produccin: Director: Jos Antonio CIares Tcnico: Jos Antonio Hernn Diseo de cubierta: Equipo de diseo de Pearson Educacin, S.A. Composicin: COPIBOOK, S.L. Impreso por: TOP PRINTER PLUS, S. L. L.IMPRESO EN ESPAA - PRINTED IN SPAIN Este libro ha sido impreso con papel y tintas ecolgicos 4. .>.: ~.~:,...VPRLOGOParte 1.V ISIN l.GENERAL Introduccin....1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . .31.1. Preguntas frecuentes sobre la ingeniera del software 1.1.1. Qu es software? 1.1.2. Qu es la ingeniera del software? 1.1.3. Cul es la diferencia entre ingeniera del software y ciencia de la computacin? 1.1.4. Cul es la diferencia entre ingeniera del software e ingeniera de sistemas? 1.1.5. Qu es un proceso del software? 1.1.6. Qu es un modelo de procesos del software? . . . . . . . . . . . . . . . . . . . . . . . . 1.1.7. Cules son los costos de la ingeniera del software? 1.1.8. Qu son los mtodos de la ingeniera del software? . . . . . . . . . . . . . . . . . .. 1.1.9. Qu es CASE? 1.1.10. Cules son los atributos de un buen software? 1.1.I l. Cules son los retos fundamentales que afronta la ingeniera del software? 1.2. Responsabilidad profesional y tica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ..5 5 6 7 7 7 8 9 10 II 11 12 122. Sistemas socio-tcnicos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .192.1. 2.2.Propiedades emergentes de los sistemas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. Ingeniera de sistemas. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 2.2.1. Definicin de requerimientos del sistema 2.2.2. Diseo del sistema. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 2.2.3. Modelado de sistemas 2.2.4. Desarrollo de los subsistemas 2.2.5. Integracin del sistema 2.2.6. Evolucin del sistema 2.2.7. Desmantelamiento del sistema. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ..21 23 24 26 28 29 30 30 31 5. vindice de contenidos2.3. 2.4. 3.Organizaciones, personas y sistemas informticos 2.3.1. Procesos organizacionales Sistemas heredados31 32 35 393.1. 3.2. 3.3. 3.4. 3.5. 4.Sistemas crticos .......................................41 43 46 50 53Un sistema de seguridad crtico sencillo Confiabilidad de un sistema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. Disponibilidad y fiabilidad Seguridad........................................................... ProteccinProcesos del software ............................................594.1.Modelos del proceso del software 4.1.1. El modelo en cascada 4.1.2. Desarrollo evolutivo 4.1.3. Ingeniera del software basada en componentes Iteracin de procesos 4.2.1. Entrega incremental . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 4.2.2. Desarrollo en espiral Actividades del proceso 4.3.1. Especificacin del software 4.3.2. Diseo e implementacin del software 4.3.3. Validacin del software 4.3.4. Evolucin del software El Proceso Unificado de Rational Ingeniera del Software Asistida por computadora 4.5.1. Clasificacin de CASE60 62 63 64 66 66 68 69 69 71 74 75 76 79 79Gestin de proyectos. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ..855.1. 5.2.87 88 89 90 91 92 95 97 98 100 1004.2.4.3.4.4. 4.5. 5.5.3. 5.4.Parte 11.Actividades de gestin Planificacin del proyecto 5.2.1. El plan del proyecto 5.2.2. Hitos y entregas Calendarizacin del proyecto 5.3.1. Grficos de barras y redes de actividades Gestin de riesgos 5.4.1. Identificacin de riesgos 5.4.2. Anlisis de riesgos 5.4.3. Planificacin de riesgos 5.4.4. Supervisin de riesgos.'........REQUERIMIENTOS ..............................................1056.107Requerimientos del software ......................................... 6.1.Requerimientos funcionales y no funcionales 6.1.1. Requerimientos funcionales 6.1.2. Requerimientos no funcionales 6.1.3. Los requerimientos del dominio109 110 111 115 6. ndice de contenidos6.2. 6.3. 6.4. 6.5. 7.Requerimientos del usuario Requerimientos del sistema 6.3.1. Especificaciones en lenguaje estructurado Especificacin de la interfaz El documento de requerimientos del softwarevii 116 118 120 122 123Procesos de la ingeniera de requerimientos ................................1297.1. 7.2.131 132 135 142 144 145 146 147 147 1507.3. 7.4.8.Estudios de viabilidad Obtencin y anlisis de requerimientos 7.2.1. Descubrimiento de requerimientos 7.2.2. Etnografa Validacin de requerimientos 7.3.1. Revisiones de requerimientos Gestin de requerimientos 7.4.1. Requerimientos duraderos y voltiles 7.4.2. Planificacin de la gestin de requerimientos 7.4.3. Gestin del cambio de los requerimientosModelos del sistema ....................................................1538.1. 8.2.155 156 157 159 161 164 165 168 169 1708.3. 8.4.8.5. 9.Modelos de contexto Modelos de comportamiento 8.2.1. Modelos de flujo de datos 8.2.2. Modelos de mquina de estados Modelos de datos Modelos de objetos 8.4.1. Modelos de herencia 8.4.2. Agregacin de objetos 8.4.3. Modelado de comportamiento de objetos Mtodos estructuradosEspecificacin de sistemas crticos 9.1.9.2. 9.3. 9.4..........................................Especificacin dirigida por riesgos 9.1.1. Identificacin de riesgos 9.1.2. Anlisis y clasificacin de riesgos 9.1.3. Descomposicin de riesgos 9.1.4. Valoracin de la reduccin de riesgos Especificacin de la seguridad Especificacin de la proteccin Especificacin de la fiabilidad del software 9.4.1. Mtricas de fiabilidad 9.4.2. Requerimientos de fiabilidad no funcionales175 177 178 178 181 182 183 186 188 189 19110. Especificacin formal ... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 191 10.1. Especificacin formal en el proceso del software 10.2. Especificacin de interfaces de subsistemas 10.3. Especificacin del comportamiento199 202 208 7. vIIiIndice de contenidosParte 111.DISEO..................................................................... 11.Diseo arquitectnico.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 21911.1. Decisiones de diseo arquitectnico. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 11.2. Organizacin del sistema 11.2.1. El modelo de repositorio 11.2.2. El modelo cliente-servidor 11.2.3. El modelo de capas 11.3. Estilos de descomposicin modular 11.3.1. Descomposicin orientada a objetos 11.3.2. Descomposicin orientada a flujos de funciones 11.4. Estilos de control 11.4.1. Control centralizado 11.4.2. Sistemas dirigidos por eventos 11.5. Arquitecturas de referencia 12.217222 224 225 226 227 229 230 231 232 233 234 236Arquitecturas de sistemas distribuidos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 241 12.1. Arquitecturas multiprocesador . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 12.2. Arquitecturas cliente-servidor 12.3. Arquitecturas de objetos distribuidos 12.3.1. CORBA 12.4. Computacin distribuida interorganizacional 12.4.1. Arquitecturas peer-to-peer 12.4.2. Arquitectura de sistemas orientados a servicios14.Arquitecturas de aplicaciones26513.1. Sistemas de procesamiento de datos 13.2. Sistemas de procesamiento de transacciones 13.2.1. Sistemas de informacin y de gestin de recursos 13.3. Sistemas de procesamiento de eventos 13.4. Sistemas de procesamiento de lenguajes13.244 245 249 252 256 256 258268 270 272 276 279Diseo orientado a objetos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 285 14.1. Objetos y clases 14.1.1. Objetos concurrentes 14.2. Un proceso de diseo orientado a objetos 14.2.1. Contexto del sistema y modelos de utilizacin 14.2.2. Diseo de la arquitectura 14.2.3. Identificacin de objetos 14.2.4. Modelos de diseo 14.2.5. Especificacin de la interfaz de los objetos 14.3. Evolucin del diseo288 290 292 294 296 297 299 303 30415. Diseo de software de tiempo real . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 309 15.1. Diseo del sistema 15.1.1. Modelado de sistemas de tiempo real 15.2. Sistemas operativos de tiempo real 15.2.1. Gestin de procesos312 314 315 316 8. indice de contenidos15.3. Sistemas de monitorizacin y control 15.4. Sistemas de adquisicin de datos318 32316. Diseo de interfaces de usuario ........................................... 16.1. Asuntos de diseo 16.1.1. Interaccin del usuario 16.1.2. Presentacin de la informacin 16.2. El proceso de diseo de la interfaz de usuario 16.3. Anlisis del usuario 16.3.1. Tcnicas de anlisis 16.4. Prototipado de la interfaz de usuario 16.5. Evaluacin de la interfaz Parte IV.ix331 335 335 338 344 345 346 348 350DESARROLLO. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 355 . 17. Desarrollo. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 35717.1. Mtodos giles 17.2. Programacin extrema 17.2.1. Pruebas en XP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 17.2.2. Programacin en parejas 17.3. Desarrollo rpido de aplicaciones 17.4. Prototipado del software19.Reutilizacin del software ................................................37918.1. 18.2. 18.3. 18.4. 18.5.18.361 364 366 369 370 373382 384 387 389 391 391 394El campo de la reutilizacin Patrones de diseo Reutilizacin basada en generadores Marcos de trabajo de aplicaciones Reutilizacin de sistemas de aplicaciones 18.5.1. Reutilizacin de productos COTS 18.5.2. Lneas de productos softwareIngeniera del software basada en componentes..............................19.1. Componentes y modelos de componentes 19.1.1. Modelos de componentes 19.1.2. Desarrollo de componentes para reutilizacin 19.2. El proceso CBSE 19.3. Composicin de componentes 20.401 404 407 409 411 414Desarrollo de sistemas crticos. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 423 20.1. 20.2.20.3.20.4.Procesos confiables Programacin confiable 20.2.1. Informacin protegida . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 20.2.2. Programacin segura 20.2.3. Manejo de excepciones Tolerancia a defectos 20.3.1. Deteccin de defectos y evaluacin de daos 20.3.2. Recuperacin y reparacin de defectos Arquitecturas tolerantes a defectos427 428 428 430 432 435 435 440 441 9. xIndice de contenidos21.21.1. 21.2. 21.3. 21.4. Parte V.Dinmica de evolucin de los programas Mantenimiento del software 21.2.1. Prediccin del mantenimiento Procesos de evolucin 21.3.1. Reingeniera de sistemas Evolucin de sistemas heredados449 451 . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 454 456 459 461VERIFICACiNVALIDACiN. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 469 y .. 22.Verificacin y validacin 22.1. 22.2. 22.3. 22.4.23.23.2. 23.3.23.4. 24........................................Planificacin de la verificacin y validacin Inspecciones de software 22.2.1. El proceso de inspeccin de programas Anlisis esttico automatizado Verificacin y mtodos formales 22.4.1. Desarrollo de software de Sala LimpiaPruebas del software 23.1...........................................Pruebas del sistema 23.1.1. Pruebas de integracin 23.1.2. Pruebas de entregas 23.1.3. Pruebas de rendimiento Pruebas de componentes 23.2.1. Pruebas de interfaces Diseo de casos de prueba 23.3.1. Pruebas basadas en requerimientos 23.3.2. Pruebas de particiones 23.3.3. Pruebas estructurales 23.3.4. Pruebas de caminos Automatizacin de las pruebasValidacin de sistemas crticos 24.1.24.2.24.3. 24.4. Parte VI.447Evolucin del software471 475 477 478 482 485 486 491494 495 497 . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 500 501 502 504 505 506 509 511 513..............................Validacin de la fiabilidad 24.1.1 . Perfiles operacionales 24.1.2. Prediccin de la fiabilidad Garanta de la seguridad 24.2.1. Argumentos de seguridad 24.2.2. Garanta del proceso 24.2.3. Comprobaciones de seguridad en tiempo de ejecucin Valoracin de la proteccin Argumentos de confiabilidad y de seguridad519 521 522 523 526 527 530 531 532 534GESTIN DEPERSONAL ..........................................54125.543Gestin de personal 25.1. 25.2. 25.3........................................Seleccin de personal Motivacin........................................................ Gestionando grupos544 547 550 10. ndice de contenidos25.4. 26.25.3.1. La composicin del grupo 25.3.2. Cohesin 25.3.3. Las comunicaciones del grupo 25.3.4. La organizacin del grupo 25.3.5. Entornos de trabajo El Modelo de Madurez de la Capacidad del Personalxi 551 552 554 555 556 558Estimacin de costes del software56]26.1. 26.2. 26.3.563 567 570 572 580 58226.4. 27.Productividad...................................................... Tcnicas de estimacin Modelado algortmico de costes 26.3.1. El modelo de COCOMO 26.3.2. Modelos algortmicos de costes en la planificacin Duracin y personal del proyectoGestin de calidad58727.1. 27.2.589 591 593 594 596 597 597 598 601 602 60427.3. 27.4. 27.5.28.Mejora de procesos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 626 28.1. 28.2. 28.3. 28.4. 28.5. 28.6.29.Calidad de proceso y producto Garanta de la calidad y estndares 27.2.1. ISO 9000 27.2.2. Estndares de documentacin Planificacin de la calidad Control de la calidad 27.4.1. Revisiones de la calidad Medicin y mtricas del software 27.5.1. El proceso de medicin 27.5.2. Mtricas de producto 27.5.3. Anlisis de las medicionesCalidad de producto y de proceso Clasificacin de los procesos Medicin del proceso Anlisis y modelado de procesos 28.4.1. Excepciones del proceso Cambio en los procesos El marco de trabajo para la mejora de procesos CMMI 28.6.1. El modelo CMMI en etapas 28.6.2. El modelo CMMI continuo609 611 613 614 618 618 619 623 624Gestin de configuraciones62729.1.630 630 632 633 636 636 639 641Planificacin de la gestin de configuraciones 29.1.1. Identificacin de los elementos de configuracin 29.1.2. La base de datos de configuraciones 29.2: Gestin del cambio 29.3. Gestin de versiones y entregas 29.3.1. Identificacin de versiones 29.3.2. Gestin de entregas 29.4. Construccin del sistema 11. xlindice de contenidos29.5.Herramientas CASE para gestin de configuraciones 29.5.1. Apoyo a la gestin de cambios 29.5.2. Soporte para gestin de versiones 29.5.3. Apoyo a la construccin del sistema642643 643 644649Glosario Bibliografa. . . ......................................................ndice alfabtico.............................................661 677 12. La primera edicin de este libro de ingeniera del software fue publicada hace ms de veinte aos. Aquella edicin fue escrita utilizando un terminal de texto conectado a una minicornputadora (un PDP-ll) que posiblemente costaba cerca de 50.000 $. Yo he escrito esta edicin desde un porttil con conexin inalmbrica que cuesta menos de 2.000 $ y mucho ms potente que aquelPDP-II. El software ms comn era el software para mainframes, pero las computadoras personales estaban a punto de aparecer. Ninguno de nosotros imagin el nivel de difusin que stas iban a tener ni el cambio que este hecho iba a producir en el mundo. Los cambios en el hardware en los ltimos veinte aos han sido notables, y podra parecer que los cambios en el software han sido igual de significativos. Ciertamente, nuestra capacidad para construir sistemas grandes y complejos ha mejorado drsticamente. Nuestros servicios e infraestructuras nacionales --energa. comunicaciones y transporte- dependen de sistemas informticos muy grandes, complejos y fiables. En la construccin de sistemas software se mezclan muchas tecnologas -J2EE . NET, EJ8, SAP, BPEL4WS, SOAP. CBSE- que permiten que aplicaciones grandes basadas en Web sean desarrolladas mucho ms rpido que en el pasado. Sin embargo. a pesar de los cambios que ha habido en las dos ltimas dcadas. cuando nosotros miramos ms all de las tecnologas, hacia los procesos fundamentales de la ingeniera del software, stos se han mantenido igual. Nosotros reconocimos hace veinte aos que el modelo en cascada tena problemas serios, pero un examen publicado en diciembre de 2003 por IEEE mostraba que ms de un 40% de las compaas siguen utilizando esta aproximacin. El testeo sigue siendo la tcnica de validacin dominante. a pesar de que otras tcnicas, como las inspecciones. han sido utilizadas de una forma ms efectiva desde mediados de los aos 70. Las herramientas CASE, a pesar de estar basadas ahora en UML, siguen siendo bsicamente editores grficos con alguna funcionalidad para chequear y generar cdigo. 13. xivPrlogoNuestros actuales mtodos y tcnicas de ingeniera del software han hecho que la construccin de sistemas grandes y complejos sea mejor. A pesar de ello, sigue siendo habitual encontrar proyectos que se retrasan, que sobrepasan el presupuesto o que se entregan sin satisfacer las necesidades de los clientes. Mientras estaba escribiendo este libro, se divulg una investigacin del gobierno en Reino Unido, sobre un proyecto para proveer a los juzgados de un sistema software para casos de delincuencia menor. El coste del sistema fue estimado en 156 millones de libras y fue planificado para ser entregado en el ao 200l. En 2004. el coste haba subido a 390 millones de libras y no estaba totalmente operativo. Hay. por lo tanto, una necesidad imperiosa de educacin en ingeniera del software. En los ltimos aos, el desarrollo ms significativo en ingeniera del software ha sido la aparicin de UML como estndar para la descripcin de sistemas orientados a objetos, y el desarrollo de mtodos giles como la programacin extrema. Los mtodos giles estn permitiendo el desarrollo rpido de sistemas, explcitamente implican al usuario en el equipo de trabajo y reducen el papeleo y la burocracia en el proceso software. A pesar de lo que algunos crticos sostienen, pienso que estas aproximaciones encaman buenas prcticas de ingeniera del software. Ellas tienen unos procesos bien definidos, prestan atencin a la especificacin del sistema y a los requerimientos del usuario, y tienen estndares de alta calidad. No obstante, esta revisin no pretende ser un texto sobre mtodos giles. Prefiero centrarme en los procesos bsicos de ingeniera del software -especificacin, diseo, implementacin, verificacin, y validacin y gestin-. Es necesario entender estos procesos y las tcnicas asociadas para decidir si los mtodos giles son la estrategia de desarrollo ms adecuada y cmo adaptar los mtodos a una situacin particular. Un tema dominante en el libro son los sistemas crticos -sistemas en los que los fallos de funcionamiento tienen consecuencias nefastas y donde la seguridad del sistema es crtica. En cada parte del libro, estudiaremos las tcnicas especficas de ingeniera del software que son relevantes para la construccin sistemas crticos. Inevitablemente, los libros reflejan las opiniones y prejuicios de sus autores. Algunos lectores estarn en desacuerdo con mis opiniones y con mi eleccin del material. Este desacuerdo es un reflejo de la diversidad de disciplinas y es esencial para su evolucin. No obstante, yo espero que a todos los ingenieros de software y estudiantes de ingeniera del software les resulte interesante.Estructuradel libro La estructura del libro est basada en los procesos fundamentales de la ingeniera del software. Est organizado en seis partes, con varios capftulos en cada parte: Parte 1: Introduce la ingeniera del software, situndola en un amplio contexto de sistemas y presentando las nociones de procesos y gestin de ingeniera del software. Parte 2: Trata los procesos. tcnicas y documentacin asociados con los requerimientos de ingeniera. Incluye un estudio sobre los requerimientos software, modelado de sistemas. especificacin formal y tcnicas para especificar la fiabilidad. Parte 3: Esta parte est dedicada al diseo de software y a los procesos de diseo. Tres de los seis captulos se centran en el importante tema de las arquitecturas software. Otros temas incluyen diseo orientado a objetos, diseo de sistemas en tiempo real y diseo de interfaces de usuario. 14. PrlogoxvParte 4: Describe una serie de aproximaciones a la implementacin, incluyendo mtodos giles, reutilizacin, CBSE y desarrollo de sistemas crticos. Como los cambios son una parte importante de la implementacin, he integrado temas de evolucin y mantenimiento en esta parte. Parte 5: Se centra en temas de verificacin y validacin. Incluye captulos de validacin y verificacin esttica, testeo y validacin de sistemas crticos. Parte 6: La parte final abarca una serie de temas de gestin: gestin de personal, estimacin de costes, gestin de calidad, procesos de mejora y gestin de cambios. En la introduccin de cada parte, expondr la estructura y organizacin con mayor detalle.Cambios en la 6a edicin . Hay cambios importantes, relativos a la organizacin y contenido, respecto a la edicin previa. He incluido cuatro captulos nuevos y he hecho una importante revisin en otros once captulos. Todos los otros captulos han sido actualizados, incorporando convenientemente nuevo material. Ms y ms sistemas tienen altos requerimientos de disponibilidad y fiabilidad,y espero que nosotros tomemos la fiabilidad como un conductor bsico en la ingeniera del software. Por esta razn, los captulos de sistemas crticos han sido integrados en otras secciones. Para evitar que el volumen del libro sea excesivo, he reducido la cantidad de material sobre mantenimiento del software y he integrado los temas de mantenimiento y evolucin del software en otros captulos. Hay dos casos de estudio -uno sobre la gestin de documentos de una biblioteca y otro de un sistema mdico-, los cuales presento en diferentes captulos. El material referente a los casos de estudio est sealado con iconos en los mrgenes. La Tabla 1 resume los cambios, indicando con el nmero entre parntesis el captulo correspondiente en la 6.~edicin. En el sitio Web del libro se puede encontrar ms informacin sobre estos cambios. TABLA1. Revisin de los captulos Captulo 13: Arquitectura de las aplicaciones. Capitulo 17: Desarrollo rpido de aplicaciones. Captulo 19: Ingenierla del software basada en componentes. Capitulo 21: Evolucin del softwareCaptulo 2:Sistemas socio-tcnicos (2)Captulo 4:Procesos software (3)Capitulo 7:Procesos de ingenierla de requerimientos (6)Capitulo 9:Especificacin de sistemas crticos (17) Captulo 12: Arquitecturas de sistemas distribuidos (11) CapItulo 16: Diseo de interface de usuario (15) Capitulo 18: Reutilizacin de cdigo (14) Captulo 23: Pruebas del software (20) Capitulo 25: Gestin de personal (22) Captulo 24: Validacin de sistemas crIticas (21) Captulo 28: Mejora de procesos (25) 15. xviPrlogoCapitulo 1:Introduccin (1)Capitulo 3:Sistemas crticos (16)Captulo 5:Gestin de proyectos (4)Capitulo 6:Requerimientos software (5)Capitulo 8:Modelos de sistemas (7)Capitulo 10: Especificacinformal (9) Capitulo 11: Diseo arquitectnico (10) Capitulo 14: Disel'o orientado a objetos (12) Captulo 15: Diseo de sistemas en tiempo real (13) Capitulo 20: Implementacin de sistemas crlticos (18) Capitulo 22: Verificacin y validacin (19) Capitulo 26: Estimacin de costes del software (23) Capitulo 27: Gestin de calidad (24) Capitulo 29: Gestin de configuraciones (29)Construccin de prototipos software (8) Sistemas heredados (26) Cambios en el software (27) Reingenieria del software (28)Gua para el lector Este libro est enfocado a estudiantes, graduados e ingenieros de la industria del software. Puede ser utilizado en cursos generales de ingeniera del software o en cursos especficos. como programacin avanzada, especificacin, diseo y gestin software. A los ingenieros de software que trabajan en la industria, este libro puede resultarles til como lectura general y corno actualizacin de sus conocimientos en temas particulares como ingeniera de requerimientos. diseo de la arquitectura. desarrollo de sistemas formales y mejora de procesos. Los ejemplos en el texto han sido utilizados como una va prctica para reflejar el tipo de aplicaciones que los ingenieros deben desarrollar.Usando el libro para ensear He diseado ellbro para que pueda ser utilizado en tres tipos de cursos de ingeniera. l.Cursos de introduccin a la ingeniera del software para estudiantes que no tienen experiencia en ingeniera del software. Se puede empezar con la seccin introductoria y luego seleccionar captulos de otras secciones del libro. Esto dar a los estudiantes una visin general de la materia con la oportunidad de hacer un estudio ms detallado por parte de los alumnos interesados. Si el curso est basado en proyectos, los primeros captulos proporcionarn suficiente material para comenzar el proyecto, y captulos posteriores servirn para referenciar y dar ms informacin del avance de su trabajo. 16. PrlogoxvII2. Cursos de introduccin o nivel medio sobre temas especficos de ingenierfa del software. El libro es vlido para cursos de especificacin de requerimientos, diseo de3.software, gestin de proyectos software, desarrollo de sistemas fiables y evolucin del software. Cada parte puede servir tanto para cursos de introduccin como intermedios en los diferentes temas. As como cada captulo tiene lecturas asociadas, he incluido en el sitio web informacin sobre otros artculos y libros relevantes. Cursos avanzados en ingeniera del software. Los captulos pueden servir como base para cursos especficos, pero deben ampliarse con lecturas complementarias que traten con mayor detalle los temas. Por ejemplo, yo imparto un mdulo en Master en ingeniera de sistemas el cual se apoya en este material. He incluido detalles de este curso y de un curso en ingeniera de sistemas crticos en el sitio web.La utilidad de un libro general como ste est en que puede utilizarse en diferentes cursos. En Lancaster, nosotros empleamos el texto en un curso de introduccin a la ingeniera del software y en cursos de especificacin, diseo y sistemas crticos. Cursos de ingeniera del software basada en componentes e ingeniera de sistemas utilizan el libro a lo largo de su imparticin, junto con artculos complementarios que se distribuyen entre los alumnos. Tener un solo libro de texto da a los alumnos una visin coherente de la materia, y stos no tienen que comprar varios libros. Para reforzar la experiencia de aprendizaje de los estudiantes, he incluido un glosario de trminos, con definiciones adicionales en el sitio web. Adems, cada captulo tiene: Unos objetivos claros presentados en la primera pgina. Una lista de los puntos clave tratados en el captulo. Lecturas adicionales recomendadas -otros libros que estn actualmente en impresin o artculos fcilmente accesibles (en mi sitio web puede encontrar un listado de otras lecturas y enlaces recomendados). Ejercicios, que incluyen ejercicios de diseo. El proyecto denominado Software Engineering Body of Knowledge (http://swebok.org) fue establecido para definir las reas clave de conocimiento tcnico relevantes para los profesionales del software. Estn organizadas bajo 10 epgrafes: requerimientos, diseo, construccin, prueba, mantenimiento, gestin de configuraciones, gestin, procesos, herramientas y mtodos, y calidad. Mientras sera imposible incluir en un solo libro de texto todas las reas de conocimiento propuestas por el proyecto SWEBOK, en este libro se tratan todas las reas de alto nivel.Pginas Web El sitio web asociado a este libro es: http://www.software-engin.com Este sitio ofrece una amplia gama de material complementario de ingeniera del software. Desde aqu, usted puede acceder a las pginas web de soporte de este libro y de ediciones anteriores. sta ha sido mi poltica, en versiones anteriores y en sta, para mantener el nmero de enlaces web en el libro en un mnimo absoluto. La razn es que los enlaces web sufren muchos cambios y, una vez impreso el libro, son imposibles de actualizar. En consecuencia, la pgi- 17. xviiiPrlogona web del libro incluye un gran nmero de enlaces a recursos y material relacionado con la ingeniera del software. Si usted los utiliza y encuentra problemas, por favor hgamelo saber y actualizar esos enlaces. Para dar soporte en el uso de este libro en cursos de ingeniera del software, he incluido una amplia variedad de material en el sitio web. En los enlaces al material para el docente, podr encontrar: Presentaciones (PowerPoint y PDF) para todos los captulos del libro. Cuestiones para cada captulo. Casos de estudio. Sugerencias sobre proyectos. Descripciones sobre estructuras de cursos. Sugerencias sobre lecturas complementarias y enlaces a los recursos web de cada captulo. Soluciones para los ejercicios asociados a cada captulo y para las cuestiones (slo profesor).Sus sugerencias y comentarios sobre el libro y el sitio web sern bienvenidos. Puede contactar conmigo a travs de ian@software-engin.com. Recomiendo que incluya [SE7] en el asunto del mensaje para evitar que los filtros antispam rechacen su mensaje. Siento no tener tiempo para ayudar a los estudiantes en su trabajo; por lo tanto, no me pregunten cmo resolver ningn problema del libro.Reconocimientos A lo largo de los aos muchas personas han contribuido al desarrollo de este libro, y me gustara dar las gracias a todos los que han comentado las ediciones anteriores y han hecho sugerencias constructivas (revisores, estudiantes, lectores que me han escrito). Al personal de la editorial y produccin de Pearson Educacin en Inglaterra y en Estados Unidos por su apoyo y ayuda, y producir el libro en un tiempo rcord. Por lo tanto, gracias a Keith Mansfield, Patty Mahtani, Daniel Rausch, Carol Noble y Sharon Burkhardt por su ayuda y apoyo. Finalmente, me gustara dar las gracias a mi familia, que ha tolerado mi ausencia cuando el libro estaba comenzndose a escribir y mi frustracin cuando las palabras no surgan. Y en especial a mi esposa, Anne, y a mis hijas, Ali y Jane, por su ayuda y apoyo. Jan Sornrnerville, febrero 2004 18. l': ..GENERALCaptulo Captulo Captulo Captulo Captulo1Introduccin2Sistemas socio-tcnicos3Sistemas crticos4 Procesosdel software 5 Gestin de proyectos 19. la estructura bsica de este libro sigue 105 procesos esenciales del software de especificacin, diseo, desarrollo, verificacin y validacin, y gestin Sin embargo, ms que caer . inmediatamente en estos temas, he incluido esta seccin de v isin general para que pueda tener una idea amplia de la disciplina. Esta parte comprende 105 cinco primeros captulos:El captulo 1 es una introduccin general a la ingeniera del software. Para hacerlo accesible y fcil de entender, lo he organizado usando una estructura de pregunta/respuesta donde planteo y respondo preguntas tales como Ques la ingeniera del software?. Tambin introduzco el profesionalismo y la tica en este captulo. El Captulo 2 presenta los sistemas socio-tcnicos, un tema que ceo es absolutar mente esencial para los ingenieros de software. El software nunca es usado por si solo , pero siempre es parte de un s istema mayor que incluye el hardwa el elemento hure, mano y, a menudo, las organizaciones. Estos componentes influyen profundamente en los requerimientos y funcionamiento del software. En este captu se estudian las prolo piedades emergentes de 105 sistemas, los procesos de la ingenieria de sistemas y algunas de las formas en las que los asuntos organizacionales y humanos afectan a los sis temas de software. El Capitulo 3 trata los -sistemas crticos. los sistemas crticos son sistemas en los que un fallo de funcionamiento del software itene graves consecuencias tcnicas, econmicas o humanas, y en los que la segurdad del sistema, la proteccin y la disponibilidad i son requerimientos clave. Se incluyen captulos sobre aspectos de sistemas crlticos en cada parte del libro. En este capitulo adems, presento el primero de los casos de es, tudio del libro: el software para una bomba de insulina usado en el tratamiento de pacientes diabticos. Los tres primeros captulos establecen el escenario de la ingeniera de software y el l Capitulo 4 contina con este propsito introduciendo el proceso del software y los modelos de procesos del software. Introduzco procesos bsicos de la ingenierla del software, la materia del libro, en este capitulo Tambin trato brevemente el Proceso Unifi. cado de Rational, el cual est enfocado al desarrollo de sistemas orientados a objetos. la ltima seccin del captulo explica cmo los procesos del software p ueden ser apoyados con herramientas software automatizadas. El Capitulo 5 aborda la gestin de proyectos. La gestin de proyectos es parte de todos los desarrollos profesionales de proyectos, y aqul describo la planificacin del proyecto, la confeccin de agendas y la estimacin de riesgos. Los estudiantes de un curso de ingenierla del software implicados en un proyecto estudiantil deberlan encontrar aqul la informacin que necesitan para trazar grficos de barras para un programa del pro yecto y para la asignacin de recursos. 20. 1 IntroduccinObjetivos los objetivos de este captulo son introducir la ingeniera del software y proporcionar un marco para entender el resto del libro. Cuando haya ledo este captulo: comprender qu es la ingeniera del software y por qu es importante;conocer las respuestas a las preguntas clave que proporcionan una introduccin a la ingeniera del software;comprender algunos aspectos profesionales y de tica que son importantes para los ingenieros de software.Contenidos ~L'-.'t., .1.1 Preguntas frecuentes sobre la ingeniera del software 1.2 Responsabilidad profesional y tica 21. 4CAPTULO1 Introduccin a las computadora sActualmente casi todos los pases dependen de complejos sistemas informticos. Infraestructuras nacionales y utilidades dependen de sistemas informticos, y la mayor parte de los productos elctricos incluyen una computadora y software de control. La fabricacin industrial y distribucin est completamente informatizada, como el sistema financiero. Por lo tanto, producir software costeable es esencial para el funcionamiento de la economa nacional e internacional. La ingeniera del software es una disciplina de la ingeniera cuya meta es el desarrollo costeable de sistemas de software. ste es abstracto e intangible. No est restringido por materiales, o gobernado por leyes fsicas o por procesos de manufactura. De alguna forma, esto simplifica la ingeniera del software ya que no existen limitaciones fsicas del potencial del software. Sin embargo, esta falta de restricciones naturales significa que el software puede llegar a ser extremadamente complejo y, por lo tanto, muy difcil de entender. La nocin de ingeniera del software fue propuesta inicialmente en 1968en una conferencia para discutir lo que en ese entonces se llam la crisis del software. Esta crisis del software fue el resultado de la introduccin de las nuevas computadoras hardware basadas en circuitos integrados. Su poder hizo que las aplicaciones hasta ese entonces irrealizables fueran una propuesta factible. El software resultante fue de rdenes de magnitud ms grande y ms complejo que los sistemas de software previos. La experiencia previa en la construccin de estos sistemas mostr que un enfoque informal para el desarrollo del software no era muy bueno. Los grandes proyectos a menudo tenan aos de retraso. Costaban mucho ms de lo presupuestado, eran irrealizables, difciles de mantener y con un desempeo pobre. El desarrollo de software estaba en crisis. Los costos del hardware se tambaleaban mientras que los del software se incrementaban con rapidez. Se necesitaban nuevas tcnicas y mtodos para controlar la complejidad inherente a los sistemas grandes. Estas tcnicas han llegado a ser parte de la ingeniera del software y son ampliamente utilizadas. Sin embargo, cuanto ms crezca nuestra capacidad para producir software, tambin lo har la complejidad de los sistemas de software solicitados. Las nuevas tecnologas resultantes de la convergencia de las computadoras y de los sistemas de comunicacin y complejas interfaces grficas de usuario impusieron nuevas demandas a los ingenieros de software. Debido a que muchas compaas no aplican de forma efectiva las tcnicas de la ingeniera del software. demasiados proyectos todava producen software que es irrealizable, entregado tarde y sobrepresupuestado. Se puede afirmar que hemos hecho enormes progresos desde 1968 y que el desarrollo de esta ingeniera ha mejorado considerablemente nuestro software. Comprendemos mucho mejor de las actividades involucradas en el desarrollo de software. Hemos desarrollado mtodos efectivos de especificacin, diseo e implementacin del software. Las nuevas notaciones y herramientas reducen el esfuerzo requerido para producir sistemas grandes y complejos. Ahora sabemos que no hay una enfoque ideal a la ingeniera del software. La amplia diversidad de diferentes tipos de sistemas y organizaciones que usan estos sistemas significaque necesitamos una diversidad de enfoques al desarrollo de software. Sin embargo, las nociones fundamentales de procesos y la organizacin del sistema son la base de todas estas tcnicas, y stas son la esencia de la ingeniera del software. Los ingenieros de software pueden estar orgullosos de sus logros. Sin software complejo no habramos explorado el espacio, no tendramos Internet y telecomunicaciones modernas, y todas las formas de viajar seran ms peligrosas y caras. Dicha ingeniera ha hecho enormes contribuciones, y no cabe dudad de que. en cuanto la disciplina madure, su contribucin en el siglo XXI ser an ms grande. 22. 1 ,1 1.1Preguntas frecuentes sobre la ingeniera del software5Preguntas frecuentes sobre la ingeniera del software Esta seccin se ha diseado para resolver algunas preguntas fundamentales sobre la ingeniera del software y para proporcionar algunos de mis puntos de vista sobre la disciplina. El formato que he utilizado es el de lista de preguntas frecuentes. Este enfoque se emplea comnmente en los grupos de noticias de Internet para proveer a los recin llegados de las respuestas a las preguntas frecuentes. Creo que es una manera muy efectiva de dar una introduccin sucinta al tema de la ingeniera del software. Las preguntas que se contestan en esta seccin se muestran en la Figura l. l.1.1.1 Qu es software? Muchas personas asocian el trmino soft .... re con los programas de computadora. Sin ema bargo, yo prefiero una definicin ms amplia donde el software no son slo programas, sino todos los documentos asociados y la configuracin de datos que se necesitan para hacer que estos programas operen de manera correcta. Por lo general. un sistema de software consiste en diversos programas independientes. archivos de configuracin que se utilizan para ejecu-Progr.mas de ordenador y la documentadn asociada. Los produdos de softwiIrese pueden desarrollar para .Ign cliente en particula o para un mercado general r Qu es la ingeniena del software?La ingeniena del software es una disciplina de ingenierfa que comprende todos Jos aspectos de la produccin de software. i.CuI es la diferena enIre ingenierfa del software y ciencia de la computacin? La ciencia de la computacincomprende la teoa y los fundamentos; la ingenieria del software comprende lis tonnas pr~ para desarrollar y entregar un software til. LCU~I es la diferencia entre ingenierfa del software e ingeniera de sistemas? la ingenieffa de sisIemas se refiere a lIOdos los as-pectos del desarrollo de sistemas infol'fticos, incluyendohardware, software e ingenierfa de procesos. La ingenierla del software es parte de este proceso. Qu es un proceso del software?Un conjunto de actividades cuya meta es el desanolo o evolucin del software.Qu es un modelo de ptoeesOS del software?Una representad6n simplificada de un proceso del software, presentada desde unaCules son los costos de la ingenieria del software7A (tM'Ides rassos, el 60 % de los costos son de desarrollo, el 40 Clb restante son de pruebas. En el caso del software personalizado, los costos de evolucin a menudo exceden los de desanoIlo.Qu son Jos m~ del software?Enfoques estructurados pilra el desarrollo de software que induyen modelos de sistemas, notaones, reglas. suprencias de diseno y gulas de procesos.de la inenierfaQu es CASE (lngenjerfa del Software Asistida por Ordenador)1perspectiva espedfica.Sistemas de software que intentan proporcionar ayuda wtomatizada las adividades del proceso del software. Los sistemas CASE a menudo se utilizan como apoyoal m4ltodo. Cules son los atributos de un buen software?El software debe tlener la fundonalidad y el rendimiento requeridos por el usuario, ademAs de ser mantenible, confiable y Mel de utilizar.Cules con los retos fundamentales a los que se enfrenta la ingenierfa de software?Enfrentarse con la creciente diversidad, las demandas para reducir traga y el desarrollo de software fiable.Figura 1.1Preguntas frecuentes sobre la ingeniera del software.los tiempos de en- 23. 6cAPiTULO 1 Introduccin a lascomputadorastar estos programas, un sistema de documentacin que describe la estructura del sistema, la documentacin para el usuario que explica cmo utilizar el sistema y sitios web que permitan a los usuarios descargar la informacin de productos recientes. Los ingenieros de software se concentran en el desarrollo de productos de software, es decir, software que se vende a un cliente. Existen dos tipos de productos de software: 1. Productos genricos. Son sistemas aislados producidos por una organizacin de desarrollo y que se venden al mercado abierto a cualquier cliente que le sea posible comprarlos. Ejemplos de este tipo de producto son el softwarepara PCs tales como bases de datos, procesadoresde texto, paquetesde dibujo y herramientasde gestinde proyectos. 2. Productos personalizados (o hechos a medida). Son sistemas requeridos por un cliente en particular. Un contratista de software desarrolla el software especialmente para ese cliente. Ejemplos de este tipo de software son los sistemas de control para instrumentos electrnicos, sistemas desarrollados para llevar a cabo procesos de negocios especficos y sistemas de control del trfico areo. Una diferencia importante entre estos diferentes tipos de software es que, en los productos genricos, la organizacin que desarrolla el software controla su especificacin. La especificacin de los productos personalizados, por lo general, es desarrollada y controlada por la organizacin que compra el software. Los desarrolladores de software deben trabajar con esa especificacin. No obstante, la lnea de separacin entre estos tipos de productos se est haciendo cada vez ms borrosa. Cada vez ms compaas de software empiezan con un sistema genrico y lo adaptan a las necesidades de un cliente en particular. Los sistemas de planificacin de recursos empresariales (ERP), como los sistemas SAP, son el mejor ejemplo de este enfoque. Aqu. un sistema largo y complejo se adapta a una compaa incorporando informacin sobre reglas de negocio y de procesos, informes, etctera.1.1.2Qu es la ingenieradel software?La ingeniera del software es una disciplina de la ingeniera que comprende todos los aspectos de la produccin de software desde las etapas iniciales de la especificacin del sistema. hasta el mantenimiento de ste despus de que se utiliza. En esta definicin, existen dos frases clave: Disciplina de la ingeniera. Los ingenieros hacen que las cosas funcionen. Aplican teoras, mtodos y herramientas donde sean convenientes, pero las utilizan de forma selectiva y siempre tratando de descubrir soluciones a los problemas. aun cuando no existan teoras y mtodos aplicables para resolverlos. Los ingenieros tambin saben que deben trabajar con restricciones financieras y organizacionales, por lo que buscan soluciones tomando en cuenta estas restricciones. 2. Todos los aspectos de produccin de software. La ingeniera del software no slo comprende los procesos tcnicos del desarrollo de software, sino tambin con actividades tales como la gestin de proyectos de software y el desarrollo de herramientas, mtodos y teoras de apoyo a la produccin de software. 1.En general, los ingenieros de software adoptan un enfoque sistemtico y organizado en su trabajo, ya que es la forma ms efectiva de producir software de alta calidad. Sin embargo, aunque la ingeniera consiste en seleccionar el mtodo ms apropiado para un conjunto de circunstancias. un enfoque ms informal y creativo de desarrollo podra ser efectivo en al- 24. 1 .1 Preguntas frecuentes sobre la ingeniera del software7gunas circunstancias. El desarrollo informal es apropiado para el desarrollo de sistemas basados en Web, los cuales requieren una mezcla de tcnicas de software y de diseo grfico.1.1.3Cul es la diferencia de la computacin?entre ingenieradel software ciencia yEsencialmente, la ciencia de la computacin se refiere a las teoras y mtodos subyacentes a las computadoras y los sistemas de software, mientras que la ingeniera del software se refiere a los problemas prcticos de producir software. Los ingenieros de software requieren ciertos conocimientos de ciencia de la computacin, de la misma forma que los ingenieros elctricos requieren conocimientos de fsica. Lo ideal sera que todos los ingenieros de software conocieran las teoras de la ciencia de la computacin, pero en realidad ste no es el caso. Los ingenieros de software a menudo utilizan enfoques ad hoc para desarrollar el software. Las ingeniosas teoras de la ciencia de la computacin no siempre pueden aplicarse a problemas reales y complejos que requieren una solucin de software.1.1.4Cul esla diferencia de sistemas?entre ingenieradel software ingeniera eLa ingeniera de sistemas se refiere a todos los aspectos del desarrollo y de la evolucin de sistemas complejos donde el software desempea un papel principal. Por lo tanto, la ingeniera de sistemas comprende el desarrollo de hardware, polticas y procesos de diseo y distribucin de sistemas, as como la ingeniera del software. Los ingenieros de sistemas estn involucrados en la especificacin del sistema, en la definicin de su arquitectura y en la integracin de las diferentes partes para crear el sistema final. Estn menos relacionados con la ingeniera de los componentes del sistema (hardware, software, etc.). La ingeniera de sistemas es ms antigua que la del software. Por ms de 100aos, las personas han especificado y construido sistemas industriales complejos, como aviones y plantas qumicas. Sin embargo, puesto que se ha incrementado el porcentaje de software en los sistemas, las tcnicas de ingeniera del software tales como el modelado de casos de uso y la gestin de la configuracin se utilizan en el proceso de ingeniera de sistemas. En el Captulo 2 se trata con mayor detalle la ingeniera de sistemas.1.1.5Qu es un pro ceso del software? Un proceso del softwarees un conjunto de actividades y resultados asociados que producen un producto de software. Estas actividades son llevadas a cabo por los ingenieros de software. Existen cuatro actividades fundamentales de procesos (incluidas ms adelante en este libro) que son comunes para todos los procesos del software. Estas actividades son: l.Especificacin del software donde los clientes e ingenieros definen el software a pro-ducir y las restricciones sobre su operacin. 2. Desarrollo del software donde el software se disea y programa. 3. Validacin del software donde el software se valida para asegurar que es lo que el cliente requiere. 4. Evolucin del software donde el software se modifica para adaptarlo a los cambios requeridos por el cliente y el mercado. 25. 8CAPTULO1Introduccin a las computadorasDiferentes tipos de sistemas necesitan diferentes procesos de desarrollo. Por ejemplo, el software de tiempo real en un avin tiene que ser completamente especificado antes de que empiece el desarrollo, mientras que en un sistema de comercio electrnico, la especificacin y el programa normalmente son desarrollados juntos. Por lo tanto, estas actividades genricas pueden organizarse de diferentes formas y describirse en diferentes niveles de detalle para diferentes tipos de software. Sin embargo, el uso de un proceso inadecuado del software puede reducir la calidad o la utilidad del producto de software que se va a desarrollar y/o incrementar los costes de desarrollo. En el Captulo 4 se tratan con ms detalle los procesos del software, y en el Captulo 28 se aborda el tema de la mejora de dicho proceso.1.1.6Qu es un modelo de procesosdel software?Un modelo de procesos del software es una descripcin simplificada de un proceso del software que presenta una visin de ese proceso. Estos modelos pueden incluir actividades que son parte de los procesos y productos de software y el papel de las personas involucradas en la ingeniera del software. Algunos ejemplos de estos tipos de modelos que se pueden producir son: l.Un modelo deflujo de trabajo. Muestra la secuencia de actividades en el procesojunto con sus entradas, salidas y dependencias. Las actividades en este modelo representan acciones humanas. 2. Un modelo deflujo de datos o de actividad. Representa el proceso como un conjunto de actividades, cada una de las cuales realiza alguna transformacin en los datos. Muestra cmo la entrada en el proceso, tal como una especificacin, se transforma en una salida, tal como un diseo. Pueden representar transformaciones llevadas a cabo por las personas o por las computadoras. 3. Un modelo de rol/accin. Representa los roles de las personas involucrada en el proceso del software y las actividades de las que son responsables. La mayor parte de los modelos de procesos del software se basan en uno de los tres modelos generales o paradigmas de desarrollo de software: 1. El enfoque en cascada. Considera las actividades anteriores y las representa como fases de procesos separados, tales como la especificacin de requerimientos, el diseo del software, la implementacin, las pruebas,etctera. Despus de que cada etapa queda definida se firma y el desarrollo contina con la siguiente etapa. 2. Desarrollo iterativo. Este enfoque entrelaza las actividades de especificacin, desarrollo y validacin. Un sistema inicial se desarrolla rpidamente a partir de especificaciones muy abstractas. ste se refina basndose en las peticiones del cliente para producir un sistema que satisfaga las necesidades de dicho cliente. El sistema puede entonces ser entregado. De forma alternativa, se puede reimplementar utilizando un enfoque ms estructurado para producir un sistema ms slido y mantenible. 3. Ingeniera del software basada en componentes (CBSE). Esta tcnica supone que las partes del sistema existen. El proceso de desarrollo del sistema se enfoca en la integracin de estas partes ms que desarrollarlas desde el principio. En el Captulo 19 se estudia la CBSE. En los Captulos 4 y 17 se tratarn nuevamente estos modelos de procesos genricos. 26. 1 .1 1.1.79P untas frecuentes sobre la ingenieradel software regCules son los costos de la ingeniera del software? No existe una respuesta sencilla a esta pregunta ya que la distribucinde costos a travs de las diferentes actividades en el proceso del software depende del proceso utilizado y del tipo de software que se vaya a desarrollar. Por ejemplo, el software de tiempo real normalmente requiere una validacin y pruebas ms extensas que los sistemas basados en web. Sin embargo, cada uno de los diferentes enfoques genricos al desarrollo del software tiene un perfil de distribucin de costos diferente a travs de las actividades del proceso del software. Si se considera que el costo total del desarrollo de un sistema de software complejo es de 100 unidades de costo, la Figura 1.2 muestra cmo se gastan stas en las diferentes actividades del proceso. En el enfoque en cascada, los costos de especificacin, diseo, implementacin e integracin se miden de forma separada. Observe que la integracin y pruebas del sistemas son las actividades de desarrollo ms caras. Normalmente, ste supone alrededor del 40% del costo del desarrollo total, pero para algunos sistemas crticos es probable que sea al menos el 50% de los costos de desarrollo del sistema. Si el software se desarrolla utilizando un enfoque iterativo, no existe divisin entre la especificacin, el diseo y el desarrollo. En este enfoque, los costos de la especificacin se reducen debido a que slo se produce la especificacin de alto nivel antes que el desarrollo. La especificacin, el diseo, la implementacin, la integracin y las pruebas se llevan a cabo en paralelo dentro de una actividad de desarrollo. Sin embargo, an se necesita una actividad independiente de pruebas del sistema una vez que la implementacin inicial est completa. La ingeniera del software basada en componentes slo ha sido ampliamente utilizada durante un corto periodo de tiempo. En este enfoque. no tenemos figuras exactas para los costos de las diferentes actividades del desarrollo de software. Sin embargo, sabemos que los Modelo en usada O25EspecificacinDesarrollo iterativo O50Diseo75Integracin y pruebasDesarrollo255075Desarrollo iterativoEspecificacintOO100Pruebas del sistemaIngenierfa del software basada en componenteso25EspecificacinFigura 1.2 Distribucin de costos de las actividades de la ingeniera del software.5075100Integracin y pruebasDesarrolloCostos de desarrollo y evoludn para software de larga vida O100Desarrollo del sistema200Evolucin del sistema300400 27. 10CAPTULO1 Inroduccina lascomputadoras tcostos de desarrollo se reducen en relacin a los costos de integracin y pruebas. Los costos de integracin y pruebas se incrementan porque tenemos que asegurarnos de que los componentes que utilizamos cumplen realmente su especificacin y funcionan como se espera con otros componentes. Adems de los costos de desarrollo, existen costos asociados a cambios que se le hacen al software una vez que est en uso. Los costos de evolucin varan drsticamente dependiendo del tipo de sistema. Para sistemas software de larga vida, tales como sistemas de orden y de control que pueden ser usados durante 10 aos o ms, estos costos exceden a los de desarrollo por un factor de 3 o 4, como se muestra en la barra inferior en la Figura 1.3. Sin embargo, los sistemas de negocio ms pequeos tienen una vida mucho ms corta y, correspondientemente, costos de evolucin ms reducidos. Esta distribucin de costos se cumple para el software personalizado, el cual es especificado por un cliente y desarrollado por un contratista. Para productos de software que se venden (mayormente) para PCs, el perfil del costo es diferente. Estos productos comnmente se desarrollan a partir de una especificacin inicial utilizando un enfoque de desarrollo evolutivo. Los costos de la especificacin son relativamente bajos. Sin embargo, debido que se pretende utilizarlos en diferentes configuraciones, deben ser probados a fondo. La Figura 1.3 muestra el perfil del costo que se puede esperar para estos productos. Los costos de evolucin para productos de software genricos son difciles de estimar. En muchos casos, existe poca evolucin de un producto. Una vez que una versin de producto se entrega, se inicia el trabajo para entregar la siguiente y, por razones de mercadotecnia, sta se presenta como un producto nuevo (pero compatible) ms que como una versin modificada de un producto que el usuario ya adquiri. Por lo tanto, los costos de evolucin no se consideran de forma separada como en el caso del software personalizado, sino que son sencillamente los costos del desarrollo para la siguiente versin del sistema.1.1.8Qu son los mtodos de la ingeniera del software? Un mtodo de ingeniera del software es un enfoque estructurado para el desarrollo de software cuyo propsito es facilitar la produccin de software de alta calidad de una forma costeable. Mtodos como Anlisis Estructurado (DeMarco, 1978) y lSD (Jackson. 1983) fueron los primeros desarrollados en los aos 70. Estos mtodos intentaron identificar los componentes funcionales bsicos de un sistema, de tal forma que los mtodos orientados a funciones an se utilizan ampliamente. En los aos 80 y 90, estos mtodos orientados a funciones fueron complementados por mtodos orientados a objetos, como los propuestos por Booch (1994) y Rumbaugh (Rumbaugh el al., 1991). Estos diferentes enfoques se han integrado en un solo enfoque unificado basado en el Lenguaje de Modelado Unificado (UML) (Booch el al., 1999; Rumbaugh el al., 1999a; Rumbaugh el al., 1999b). No existe un mtodo ideal, y mtodos diferentes tienen distintas reas donde son aplicables. Por ejemplo, los mtodos orientados a objetos a menudo son apropiados para sistemas interactivos, pero no para sistemas con requerimientos rigurosos de tiempo real.o Fisura 1.3 Costos del desarrollo del producto.Especificacin25Desarrollo5075Pruebas del sistema100 28. 1 .1 Preguntas frecuentes sobre la ingeniera del software11Todos los mtodos se basan en la idea de modelos grficos de desarrollo de un sistema y en el uso de estos modelos como un sistema de especificacin o diseo. Los mtodos incluyen varios componentes diferentes (Figura 1.4).1.1.9Qu es CASE? CASE (Ingeniera del Software Asistida por Computadora) comprende un amplio abanico de diferentes tipos de programas que se utilizan para ayudar a las actividadesdel proceso del software, como el anlisis de requerimientos, el modelado de sistemas, la depuracin y las pruebas. En la actualidad, todos los mtodos vienen con tecnologa CASE asociada, como los editores para las notaciones utilizadas en el mtodo, mdulos de anlisis que verifican el modelo del sistema segn las reglas del mtodo y generadores de informes que ayudan a crear la documentacin del sistema. Las herramientas CASE tambin incluyen un generador de cdigo que automticamente genera cdigo fuente a partir del modelo del sistema y de algunas guas de procesos para los ingenieros de software.1.1.10Cules son los atrbutos de un buen software? i As como los servicios que proveen, los productos de software tienen un cierto nmero de atributos asociados que reflejan la calidad de ese software. Estos atributos no estn directamente asociados con lo que el software hace. Ms bien, reflejan su comportamiento durante su ejecucin y en la estructura y organizacin del programa fuente y en la documentacin asociada. Ejemplos de estos atributos (algunas veces llamados atributos no funcionales) son el tiempo de respuesta del software a una pregunta del usuario y la comprensin del programa fuente. El conjunto especfico de atributos que se espera de un sistema de software depende obviamente de su aplicacin. Por lo tanto, un sistema bancario debe ser seguro, un juego interactivo debe tener capacidad de respuesta, un interruptor de un sistema telefnico debe ser fiable, etctera. Esto se generaliza en el conjunto de atributos que se muestra en la Figura 1.5.el cual tiene las caractersticas esenciales de un sistema de software bien diseado.Descripciones del modelo del sistemaDesaipciones de los modelos del sistema que desarrollar" y la notacin utilizada para definir estos modelos.Modelos de objetos, de flujo de datos, de mquina de estado, etdtera.ReglasRestricciones que siempre aplican a los modelos de sistemas..cada entidad de 00 modelo de sistema debe tener un nombre nico.RecomendacionesHeurfstica que caracteriza una buena prktica de disefto en este m~o. Seguir estas recomendaciones d ebe dar como resultado un modelo del sistema bien organizado.Ningn objeto debe tener mM de siete subobjetos asoados a ~Gulas en el procesoDescripciones de las actividades que deben seguirse para desarrollar los modelos del sistema y laorganizacin e estas d actividades.Los atributos de los objetos deben docu mentalSe Intes de definir las operacio-Figura 1.4 Componentes del mtodo.nes asociadas 00obeto. 29. 12CAPTULO 1 Introduccina las computadorasEl software debe esaibirse de tal forma que pueda ewlucionar pera almpIir las necesidades de cambio de los dientes. tste es un atribulo aftico debido a que el cambio en el 50ft. ware es una consecvencia inevitable de un cambio en el entumo de negodos.MlnlenibilidadLa confiabilidad del software tiene un gren nmero de carac:tertstica incluyendo la fiabi. ded, proteccin y seauJidad. El software confiable no debe CMISIf cIIftos tIsims o econ6mtcos en el caso de UN falla del sistema_ EficienciaElsoftware no debe hacer que se maltasten los recursos del sistema, como la memoria y los ciclos de procesamiento. Por lo tanto, la eficiencia incluye tiempos de respuesta Y de procesamiento, utilizacin de la memoria, etciterI.USlbiIicIac:IEl software debe ser ficiI de utilizar, sin esfuerzo adicional, por el usuMo para quien estj di 58ftado. Esto significl que debe tener una interfaz de usuario apropiada y una documentacin adecuada. Figura 1.5 Atributos esencales de un buen software.1.1.11Cules son los retos fundamentales que afronta la ingeniera del software? En el siglo XXI, la ingeniera del software afronta tres retos fundamentales:l.2.3.El reto de la heterogeneidad. Cada vez ms, se requiere que los sistemas operen como sistemas distribuidos en redes que incluyen diferentes tipos de computadoras y con diferentes clases de sistemas de soporte. A menudo es necesario integrar software nuevo con sistemas heredados ms viejos escritos en diferentes lenguajes de programacin. El reto de la heterogeneidad es desarrollar tcnicas para construir software confiable que sea lo suficientemente flexible para adecuarse a esta heterogeneidad. El reto de la entrega. Muchas tcnicas tradicionales de ingeniera del software consumen tiempo. El tiempo que stas consumen es para producir un software de calidad. Sin embargo, los negocios de hoy en da deben tener una gran capacidad de respuesta y cambiar con mucha rapidez. Su software de soporte tambin debe cambiar con la misma rapidez. El reto de la entrega es reducir los tiempos de entrega para sistemas grandes y complejos sin comprometer la calidad del sistema. El reto de la confianza. Puesto que el software tiene relacin con todos los aspectos de nuestra vida, es esencial que podamos confiar en l. Esto es especialmente importante en sistemas remotos de software a los que se accede a travs de pginas web o de interfaces de servicios web. El reto de la confianza es desarrollar tcnicas que demuestren que los usuarios pueden confiar en el software.Por supuesto, stos no son independientes. Por ejemplo, es necesario hacer cambios rpidos a los sistemas heredados para proveerlos de una interfaz de servicio web. Para tratar estos retos, necesitaremos nuevas herramientas y tcnicas, as como formas innovadoras de combinacin y uso de mtodos de ingeniera del software existentes.1.2Responsabilidad profesional y tica Como otras disciplinas de la ingeniera, la ingeniera del software se lleva a cabo dentro de un marco legal y social que limita la libertad de los ingenieros. Los ingenieros de software 30. 1 .2 Responsabilidad profesional y tica13deben aceptar que su trabajo comprende responsabilidades ms amplias que simplemente la aplicacin de habilidades tcnicas. Deben comportarse de una forma tica y moral responsable si es que desean ser respetados como profesionales. No basta con decir que usted siempre debe poseer estndares normales de honestidad e integridad. No debera utilizar su capacidad y sus habilidades para comportarse de forma deshonesta o de forma que deshonre la profesin de la ingeniera del software. Sin embargo, existen reas donde los estndares de comportamiento aceptable no estn acotados por las leyes. sino por la ms tenue nocin de responsabilidad profesional. Algunas de stas son: 1. Confidencialidad. Usted normalmente debe respetar la confidencialidad de sus empleadores o clientes independientemente de que se haya firmado un acuerdo formal de confidencialidad. 2. Competencia. No debe falsificar su nivel de competencia. ni aceptar conscientemente trabajos que estn fuera de su capacidad. 3. Derechos de propiedad intelectual. Debe ser consciente de las leyes locales que gobiernan el uso de la propiedad intelectual, como las patentes y el copyright. Debe asegurarse de que la propiedad intelectual de los empleadores y clientes est protegida. 4. Uso inapropiado de los computadoras. No debe emplear sus habilidades tcnicas para utilizar de forma inapropiada las computadoras de otras personas. El uso inapropiado de las computadoras va desde los relativamente triviales (utilizar juegos en la mquina de un empleado. por ejemplo) hasta los extremadamente serios (difusin de virus). Las sociedades e instituciones profesionales tiene que desempear un papel importante en el establecimiento de estndares ticos. Organizaciones como la ACM. el IEEE (Instituto de Ingenieros Elctricos y Electrnicos) y la British Computer Society publican un cdigo de conducta profesional o de tica. Los miembros de estas organizaciones se comprometen a cumplir ese cdigo cuando se inscriben en ellas. Estos cdigos de conducta generalmente se refieren al comportamiento tico fundamental. La ACM y el IEEE han cooperado para crear un cdigo de tica y prctica profesional. Este cdigo existe en forma reducida, como se muestra en la Figura 1.6, y en forma extendida (Gotterbam et al.. 1999), la cual agrega detalle y sustancia a la versin reducida. El fundamento sobre el que se asienta este cdigo se resume en los dos primeros prrafos de la versin extendida: Las computadoras tienen un papel central y creciente en el comercio, la industria. el gobierno. la medicina. la educacin, el entretenimiento y la sociedad en general. Los ingenieros de software son aquellos que contrihuyen con su participacin directa o por su enseanza. al anlisis. especificacin. diseo. desarrollo, certificacin. mantenimiento .Y pruebas de los sistemas de software. Debido a sus papeles en el desarrollo de sistemas de software, los ingenieros de software tienen significativas oportunidades de hacer el bien o causar dao. permitir que otros hagan el bien o causen dao. o influir en otros para hacer el bien o causar dao. Para asegurar,tanto como sea posible. que sus esfuerzos sern utilizados para bien, los ingenieros de software deben comprometerse consigo mismos para hacer de la ingeniera del software tina profesin de beneficio y respeto. De acuerdo con este compromiso, los ingenieros de software deben cumplir el siguiente Cdigo de tica y Prctica Profesional. 31. 14CAPTULO1 Introducin a las computadoras cw.....CAWIF. Blca y Pr6cllal ACM/Im-CS Fuerza de Tarea Conjunta sobre ~cayPrActica Profesional en la Ingenierfa del SoftwarePIMIULO La versin corta del cdigo resume las aspiraciones en un alto nivel de abstraccin. Las clusulas que se induyen en la versin completa proporcionan ejemplos y detalles de cmo estas aspiraciones cambian laforma en que actuamos como profesionales de la Inpnierfa del software.Sin las aspiraciones, los detalles pueden llegar a ser slo t8minos jurfdicostediosos; sin los detalles, las aspiraciones pueden llegar a ser altisonantes petO vadas; juntas, las aspiraciones y los detalles forman uncdigo cohesivo. Los ingenieros de software deben comprometerse consigo mismos para hacer del an6lisis. la espec:ificadnel diseno, el des, arrollo, lIS pruebas y el mantenimiento del software una profesin beneficiosa y respetada. En concofdanda con su compromiso con la salud, la seguridad Y el bienestar del p6blico, los inlenieros de software deben adherirse a los siguientes ocho principios: 1. POBUCO- Los ingenieros de software deber6n actuar en consonancia con el inters plblico. 2. CUENTE Y EMPlEADOR - Los inpnieros de software deber6n aduar de forma que respondan .JI los intereses de sus dlenles y empleadores siendo consecuentes con el ~ plblico. 3. PRODUOO - Los insenieros de software deber6n aseplrar que sus productos y las modificaciones asociadas cumplan los mM altos esUndares profesionales posibles. 4. JUIOO- Los in,enieros de software debern mantener la irrtesridad e indep endencia en sus juicios profesionales. S. GESIlN - Los gerentes Y lideres inpnieros de software debenin suscribiry promoonar un enfoque ~ en la pstin del desanollo y mantenimiento del software. 6. PROFESION - Los inpnietOs de software debern mantener la intepidad y reputacin de la profesin de acuerdo con elinllris p6b1ico. 7. COlEGAS- Los inenieros de software deberin ser imparciales y apoyar a sus colegas. 8. PERSONAL Durante toda sus existencia, los insenieros de software debern aprender lo concemiente a la prctica de su profesin y promocionar un enfoque ~ en la prctica e su profesin. d Figura 1.6 Cdigo de ticade la ACM/IEEE(~IEEE/ACM 1999).El cdigo contiene ocho principios relacionados con el comportamiento y con las decisiones hechas por ingenieros de software profesionales, incluyendo practicantes, educadores, administradores, supervisores y creadores de polticas, as como aprendices)' estudiantes de la profesin. Los principios identifican las relaciones ticas en las que los individuos. grupos y organizaciones participan. y las obligaciones primarias dentro de estas relaciones. Las clusulas de cada principio son ilustraciones de algunas de las obligaciones incluidas en estas relaciones. Estas obligaciones se fundamentan en la humanidad del ingeniero de software, con especial cuidado en /0 gente afectada por el trabajo de los ingenieros de software. y los elementos nicos de la prctica de la ingenierta del software. El cdigo prescribe stas como obligaciones de cualquiera que se llame o que aspire a ser un ingeniero de software. En cualquier situacin en la que diferentes personas tienen distintos puntos de vista y objetivos, es posible encontrar problemas ticos. Por ejemplo, si usted est en desacuerdo. en principio, con las polticas de un directivo de categora superior en la compaa. ,cmo debera reaccionar? Desde luego, esto depende de cada individuo y de la naturaleza de la discordancia. Es mejor argumentar a favor de su posicin dentro de la organizacin o renunciar de acuerdo con sus principios? Si piensa que existen problemas con un proyecto de software, cundo se deben comunicar stos al gerente? Si stos se discuten cuando son slo 32. 1 .2 Resp onsabilidadpr fesional y tica o15una sospecha, puede ser una sobre reaccin a la situacin, si lo deja para ms tarde, puede ser imposible resolver las dificultades. Tales problemas ticos aparecen en nuestra vida profesional y, afortunadamente, en muchos casos son relativamente menores o se pueden resolver sin mucha dificultad. Cuando no se puedan resolver, los ingenieros se enfrentarn, quizs, con otro problema. La accin con base en sus principios podra ser renunciar a su trabajo, pero esto puede afectar a otros, por ejemplo, a sus colaboradores o sus hijos. Una situacin particularmente difcil para los ingenieros profesionales surge cuando su empleador acta de una forma no tica. Por ejemplo. una compaa es responsable de desarrollar un sistema crtico de seguridad y, debido a las presiones de tiempo. falsifica la validacin de proteccin de los registros. Es responsabilidad del ingeniero mantener la confidencialidad o alertar al cliente o hacer pblico, de alguna forma, que el sistema entregado es inseguro? El problema aqu es que no existen absolutos cuando se trata de proteccin. Aun cuando el sistema no haya sido validado de acuerdo con los criterios predefinidos, stos pueden ser demasiado estrictos. El sistema puede, de hecho, operar de forma segura a travs de su tiempo de vida. Pero puede darse el caso de que, aun cuando sea validado apropiadamente, el sistema falle y cause un accidente. El descubrimiento temprano de problemas puede resultar perjudicial para el empleador y otros empleados; la falta de descubrimiento de problemas puede resultar perjudicial para otros. Debe tomar su propia decisin en estos temas. La posicin tica apropiada depende enteramente del punto de vista de los individuos que estn involucrados. En este caso, el potencial para el dao. el grado del dao y la gente afectada por l deben influir en la decisin. Si la situacin es muy peligrosa, se justifica su publicacin en la prensa nacional (por ejemplo). Sin embargo, se debe tratar de resolver la situacin respetando los derechos del empleador. Otra cuestin tica es la participacin en el desarrollo de sistemas militares y nucleares. Algunas personas tienen una opinin firme sobre estos temas y no desean participar en ningn desarrollo de sistemas asociados con sistemas militares. Otros trabajarn en sistemas militares, pero no en sistemas de armamento. Algunos otros sentirn que la defensa de la nacin es un principio fundamental y no tienen objeciones ticas para trabajar en sistemas de armamento. En esta situacin, es importante que tanto empleadores como empleados se hagan saber con anticipacin sus puntos de vista. Cuando una organizacin est relacionada con el trabajo militar o nuclear, le debe ser posible especificar si los empleados pueden aceptar cualquier tarea. De igual forma, si un empleado hace patente que no desea trabajar en tales sistemas, los empleadores no deben presionarlo posteriormente, El rea de tica y responsabilidad profesional ha recibido creciente atencin en los pasados aos. Los principios de tica se pueden considerar desde un punto de vista filosfico, y la tica de la ingeniera del software se debe tratar con referencia a estos principios bsicos. ste es el enfoque considerado por Laudon (Laudon, 1995) y, de forma menos extensa, por Huff y Martin (Huff y Martin, 1995). Sin embargo, este enfoque me resulta abstracto y difcil de relacionar con mi experiencia diaria. Prefiero un enfoque ms concreto comprendido en cdigos de conducta y prctica. Creo que la tica se analiza mejor en un contexto de ingeniera del software y no como un tema por s solo. En este libro, por lo tanto, no incluir consideraciones ticas abstractas sino que, donde sea apropiado, incluir ejemplos en los ejercicios que puedan servir de punto de partida para una discusin tica. 33. .,-~ 16CAPTULO..... ~. ~.1 Introduccin a las computadoras...!~ .....-,PUNTOSCLAVELaIngeniera del software es una disciplina de ingenier{ que comprende todos los aspectos de la produccin de software.Los productos de software consisten en programas desarrolladosV en la documentacl6n asociada. los atributos esenciales de los productos son la mantenibilidad, conflabllidad, eficiencia y aceptabilidad.El proceso del software Incluye todas las actividades relativas al desarrollo del software Las actividades de . alto nivel de especificacin del software. el desarrollo, la validacin y la evolucin son parte de todos los procesos software. tos rMtodos son formas organizadas de producir software. Incluyen sugerencias para el proceso que se debe 5eplr,'la notacin que se va autflizar, los modelos del sistema que hay que desarrollar y las restas que gobiernan estos modelos y las pautas de dlseiio. -las herramientas CASE son sistemas de software que estn dlseiiados para ayudar a las actividades rutinarias del proceso del software. como editar diagramas de disefto, verificar la consistencia de Htos mantener y un banco de pruebIS de los propama5 efecutados. los Inpnleros de software tienen responsabilidades en la profesin de la Ingenierra y en la sociedad slo . No deben estar pendientes de los aspectos tcnicos. Las sociedades profesionales publican cdigos de conducta que definen los estndares de comportamiento esperado por sus miembros.LECTURASADICIONALES_~;. O) = 227. 214CAPTULO 10 Especificacillormal fde seguridad. En esas circunstancias, la insulina solamente se suministra si el nivel de azcar en la sangre crece y tambin se incrementa la velocidad de cambio de azcar en la sangre. El resto de los esquemas, SUGAR_LOW y SUGAR_HIGH definen la dosis a suministrar si el nivel de azcar est fuera de la zona de seguridad. Los predicados en el esquema son los siguientes: 1. El predicado inicial define la zona de seguridad; es decir, r2 debe estar entre safemin y safemax. 2. Si el nivel de azcar es estable o decreciente, indicado por r2 (la ltima lectura) siendo igualo menor que r1 (una lectura anterior), entonces la dosis de insulina a suministrar es cero. 3. Si el nivel de azcar es creciente (r2 mayor que r1) pero la velocidad de crecimiento es decreciente, entonces la dosis a suministrar es cero. 4. Si el nivel de azcar es creciente y la velocidad de crecimiento es estable, entonces se suministra una dosis mnima de insulina. 5. Si el nivel de azcar es creciente y la velocidad de crecimiento es decreciente, entonces la velocidad de insulina a suministrar se calcula aplicando una sencilla frmula a los valores calculados. No modelamos el comportamiento temporal del sistema (por ejemplo, el hecho de que el sensor de glucosa se comprueba cada 10minutos) usando el lenguaje Z. Si bien es ciertamente posible, tambin es engorroso, y podramos decir una descripcin informal realmente muestra la especificacin de forma ms concisa que una especificacin formal.PU NTOS CLAYE.~ -Los mtodos de especificacin formal de sistemas complementan a las tcni de especificaci6n Informal de cas requerimientos. Pueden utilizarse con la definlc16n de requerim ientos medIante lenguaje natural para clarificar cualquier rea de ambIgedad potencial enla especificacl6n.Las espe cificaciones formales son precisas V no ambiguas. Eliminan las reas dudosas en una especlficacl6n y evitan algunos de los problemas de malaInterpretacl6n del lenguaje. Sin embargo, los no especialistas pueden encontrar estas especificaciones formales d lffclles de entender.La ventaja fundamental de usar mtodos formales en el proceso de l software es que fuerza a un an41iss de l los requerimientos del sistema en una etapaInicial. Corregir errores en esta etapa es menos costoso que medlflcar un sistema ya entregado.Las tcnicas de especificacl6n formal son ms rentabl en el desarrollo de s es istemas crfticos en los que la segurldad, fiabilidad y protec ci6n son particularmente Importantes. Tambin pueden utilizarse para especificar est'ndares.Lastknlcas algebraicas de especlflcacl6n formal son e specialmente adecuadas para especificar Interfaces en donde la interfaz se define como un conjunto de clases de objetos o tipos abstractos de datos. Estas tcnicas ocultan el estado del s istema y especifican el sistema en funcl6n de las relaciones ente las operaciones de la r Interfaz. 228. CAPTULO 10 Ejeercicios 215Lastcnicas basadas en modelos modelan el sistema utilizando construcciones matemticas tales como conjuntos y funciones. t5tas pueden mostrar el estado del sistema, lo que simplifica ataunos tipos de especificacin del comportamiento.Las operaciones se definen en una especificacin basada en modelos definiendo las precondiclones y postcondiciones sobre el estado del sistema.LECTURASADICIONALES_."E.~.&~ " "Correctness by construction: Developing a commercially secure system. Una buena descripcin de cmo pueden usarse los mtodos formales en el desarrollo de un sistema de proteccin crtico. lA. Hall y R. Chapman, IEEESoftware, 19(1), enero 2002.] IEEE Transactions on Software Engineering. enero 1998. Este nmero de la revista incluye una seccin especial sobre usos prcticos de los mtodos formales en ingeniera del software. Incluye artculos del lenguaje Z y del lenguaje LARCH. Formalmethods: Promisesand problems. Esteartculo es un anlisis realista de los beneficios potenciales del uso de mtodos formales y de las dificultades de integrar el uso de estos mtodos en el desarrollo prctico del software. [Luqi y). Goguen. IEEESoftware, 14(1), enero 1997,)EJERCICIOS" .~V"ImI _ _ ....r .....10.1Sugiera por qu el diseo arquitectnico de un sistema debera preceder al desarrollo de una especificacin formal.10.2Se le ha asignado la tarea de vender tcnicas de especificacin formal a una empresa de desarrollo de software. Indique cmo podra explicar las ventajas de las especificaciones formales a ingenieros de software escpticos y prcticos.10.3Explique por qu es particularmente importante definir las interfaces de los subsistemas de forma precisa y por qu la especificacin algebraica es particularmente adecuada para la especificacin de estas interfaces.10.4Un tipo abstracto de datos que representa una pila tiene las siguientes operaciones asociadas: New:Crea una pila.Push:Aade un elemento en la cima de la pila.Top:Obtiene el elemento de la cima de la pila.Retract:Elimina el elemento de la cima de la pila y devuelve la pila modificada.Empty:Cierto si no hay elementos en la pila.Defina este tipo abstracto de datos utilizando una especificacin algebraica. 229. 216CAPiTULO 10 Especificacin formal10.5 Enel ejemplo de un sector controlado del espacio areo,la condicin de seguridad es que no debe estar dentro de los 300 m de altura en el mismo sector. Modifique la especificacin mostrada en la Figura 10.8 para permitir que el avin ocupe la misma altura en el sector si est separado al menos 8 km horizontalmente. Usted puede prescindir de los aviones en los sectores adyacentes. Sugerencia: tiene que modificar las operaciones de construccin para que incluyan la posicin del avn as como su altura. Tambin i tiene que definir una operacin que, dadas dos posiciones, devuelva la separac entre ellas. in10.6 los cajeros automticos de los bancos utilizan la informacin de las tarjetas delos usuarios mediante el identificador del banco, el nmero de cuentay el identificador personal del usuario. Tambin generan informacin de la cuenta a partir de una base de datos central y actualizan dicha base de datos al completar la transaccin. Empleando su conocimiento del funcionamiento de un ATM,escriba esquemas Z que definan el estado del sistema, la validacin de latarjeta (en la que se comprueba laidentificacin del usuario) y la retirada de efectivo.10.7 Modifique el esquema de bomba de insulina, mostrado en la Figura 10.10, y aada una condicin de se guridad adicional de forma que el ManualDeliveryButton? pueda tener solamente un valor distinto de cero si el interruptor de la bomba est en la posi in manual. c10.8 Escriba un esquema Z denominado SElF_TESTque compruebe los componentes hardware de la bomba de insulina y fije los valores de la variable de estado HarwareTest? A continuacin modifique el esquema RUN para comprobar que el hardware funciona correctamente antes de que se suministre insulina. Si no, la dosis suministrada debera ser cero y se debera mostrarse un error en la pantalla de a bomba de insulina. l10.9 Z soporta la nocin de sucesiones en donde una sucesin escomo un vector. Porejemplo, para una sucesin S, usted puede referirse a sus elementos como S[l], 5 [21,y as sucesivamente. Tambin le permite determinar el nmero de elementos de una sucesin usando el oper dor #. Esdecir, si una sucesin S es[a, a b, e, d], entonces #S es 4. Usted puede aadir un elemento al final de una sucesin S escribiendo S + a, y al principio de la secuencia escribiendo a + S. Usando estas construcciones, escriba una especificacin Z de la lIST que seespecifica algebraicamente en la Figura 10.7.10.10 Usted es un ingeniero de sistemas y se le pide que sugiera la mejor manera para desarrollar el software de un sistema de seguridad crtico para un marcapasosdel corazn. Usted sugiere especificar formalmente el sistema, pero su gestor rechaza su sugerencia. Usted piensa que sus razonesson dbiles y basadas en prejuicios. Estico desarrollar el sistema usando mtodos que usted piensa que son inadecuados? 230. Captulo11Diseo arquitectnicoCaptulo 12 Arquitecturas de sistemas distribuidos Captulo 13 Arquitecturas de aplicaciones Captulo 14 Diseo orientado a objetos Captulo 15 Diseo de software de tiempo real Captulo 16 Diseo de interfaces de usuario 231. La esencia del diseo del software es la toma de decisiones sobre la organizacin lgi ca del software. Algunas veces, usted representa esta organizacin lgica como un modelo en un lenguaje definido de modelado tal como UMLy otras veces usted simplemente utiliza notaciones informales y esbozos para representar el diseo. Por supuesto , usted raramente empieza desde cero cuando toma decisiones sobre la organizacin del software sino que basa su diseo sobre experiencias de diseo anteriores . Algunos autores piensan que la mejor forma de encapsular esta experiencia de dise o es mediante mtodos estructurados en donde usted sigue un proceso definido de diseo y describe su diseo utilizando diferentes tipos de modelos. Yo nunca he sido un gran seguidor de los mtodos estructurados ya que siempre he pensado que son demasiado restrictivos. El diseo es un proceso creativo y yo creo firmemente que cada uno de nosotros abordamos dicho proceso creativo de forma particular No hay una forma . buena o mala de disear el software y ni yo ni nad puede darle una 'frmula' para el ie diseo del software. Usted aprende cmo disear observando ejemplos de diseos existentes y discutiendo su diseo con otros. En lugar de representar la experiencia como un mtodo de diseo, yo prefiero una aproximacin menos estructurada. Los capitulas de esta parte encapsulan conocimiento sobre estructuras de software que han sido utlizadas con xito en otros sistemas, prei sentan algunos ejemplos y le proporcionan algn consejo sobre procesos de diseo : 1. Los Capltulos del 11 al 13 hablan sobre las estructuras abstracta del software. El s Captulo 11 discute perspectivas estructurales que se han encontrado tiles para el diseo del software, el Captulo 12 habla sobre cmo es tructurar el software para su ejecucin distribuida y el Capitulo 13 habla sobre estructuras genricas para varios tipos de aplicaciones. El CapItulo 13 es nuevo y lo he incluido en esta edicin debido a que he visto que muchos estudiantes de ingenierla del software no tienen experiencia en software de aplicaciones a parte de los sistemasinteractivos que ellos usan de forma cotidiana en sus propios ordenadores . 2.Los Capltulos del 14 al16 abordan cuestones de diseo del software ms e i specificas. El Capitulo 14, que cubre el diseo orientado a objetos, trata una forma de pensar sobre las estructuras del software. El Capitulo 15, dedicado al diseo de sistemas de tiempo real, discute las estructuras del software que usted necesita en sistemas en los que una respuesta a tiempo es un equerimiento critico. r El Capitulo 16 es un poco dife rente debido a que est centrado en el diseo de la interfaz de usuario en vez de estucturas del software. Como ingeniero, usted r tiene que pensar sobre los s istemas -no solamente sobre el software y las personas del sistema son un compon ente esencial. El diseo no termina con la definicin de las estructuras del software sino que contina con cmo se usa el software. 232. 11 Diseo arquitectnico ;'~"">""'" '.~..:.Objetivos Elobjetivo de este captulo es introducir los conceptos de la arquitectura del software y del diseo arquitectnico. Cuando haya ledo este captulo: comprender por qu es importante el diseo arquitectnico del software;comprender las decisiones que tienen que tomarse sobre la arquitectura del sistema durante el proceso de diseo arquitectnico;habr sido introducido en tres estilos arquitectnicos complementarios que abarcan la organizacin del sistema en su totalidad, la descomposicin modular y el control;comprender cmo se utilizan las arquitecturas de referencia para comunicar conceptos arquitectnicos y para evaluar las arquitecturas de los sistemas.....:Contenidos 11.1 11.2 11.3 11.4 11.5Decisiones de diseo arquitectnico Organizacin del sistema Estilos de descomposicin modular Estilos de control Arquitecturas de referencia 233. 220CAPTULO11 Diseo arquitectnicoLos grandes sistemas siempre se descomponen en subsistemas que proporcionan algn conjunto de servicios relacionados. El proceso de diseo inicial que identifica estos subsistemas y establece un marco para el control y comunicacin de los subsistemas se llama diseo arquitectnico. El resultado de este proceso de diseo es una descripcin de la arquitectura del software. En el modelo presentado en el Captulo 4, el diseo arquitectnico es la primera etapa en el proceso de diseo y representa un enlace crtico entre los procesos de ingeniera de diseo y de requerimientos. El proceso de diseo arquitectnico est relacionado con el establecimiento de un marco estructural bsico que identifica los principales componentes de un sistema y las comunicaciones entre estos componentes. Bass y otros (Bass