1. INGENIERA DEL SOFTWAREUN ENFOQUE PRCTICO Quinta edicin

2. CONSULTOR EDITORIALREA DE INFORMTICA Y COMPUTACINGerardo Quiroz VieyraIngeniero de Comunicaciones y Electrnicapor la ESIME del Instituto Politcnico NacionalProfesor de la Universidad Autnoma MetropolitanaUnjdad XochimilcoMEXICO 3. INGENIERA DEL SOFTWAREUN ENFOQUE PRCTICOQuinta edicinRoger S. PressmanR.S. Pressman & Associates, Inc. ADAPTACI~NDarrel Ince Open University TRADUCCI~N Rafael Ojeda Martn Isabel Morales Jareo Virgilio Yage Galaup Salvador Snchez AlonsoDepartamento de Lenguajes y Sistemas Informticos e Ingeniera del Software Facultad de Informtica 1Escuela Universitaria de Informtica Universidad Pontificia de Salamanca campus Madrid (Espaa) Jorge A. Torres Jimnez Director de la carrera de Ingeniera de Sistemas Computacionales Instituto Tecnolgico (TEC) de Monterrey campus Quertaro (Mxico) COLABORACI~N scar San Juan MartnezJuana Gonzlez Gonzlez Ricardo Lozano Quesada Lorena Esmoris GalnDepartamento de Lenguajes y Sistemas Informticos e Ingeniera del Software Facultad de Informtica 1Escuela Universitaria de Informtica Universidad Pontificia de Salamanca campus Madrid (Espaa)REVISI~N TCNICA Hctor Castn RodrguezDepartamento de Lenguajes y Sistemas Informticos e Ingeniera del Software Facultad de Informtica 1Escuela Universitaria de Informtica Universidad Pontificia de Salamanca campus Madrid (Espaa)COORDINACINY R E V I S I ~ N DIRECCI~N, TCNICALuis Joyanes AguilarDepartamento de Lenguajes y Sistemas Informticos e Ingeniera del Software Facultad de Informtica 1 Escuela Universitaria de Informtica Universidad Pontificia de Salamanca campus Madrid (Espaa)MADRID BUENOS AIRES CARACAS GUATEMALA LISBOA MXICO - -NUEVA YORK PANAM SAN JUAN SANTAF DE BOGOT SANTIAGO SAO PAULO AUCKLAND HAMBURGO LONDRES MILN MONTREAL NUEVA DELHI PARb SAN FRANCISCO SIDNEY SINGAPUR ST. LOUlS TOKIO TORONTO- 4. INGENIERA DEL SOFTWARE. Un enfoque prctico. (5: edicin) No est permitida la reproduccin total o parcial de este libro, ni su tratamiento infor- mtico, ni la transmisin de ninguna forma o por cualquier medio, ya sea electrnico, mecnico, por fotocopia, por registro u otros mtodos, sin el permiso previo y por escrito de los titulares del Copyright.DERECHOS RESERVADOS O 2002, respecto a la quinta edicin en espaol, porMcGRAW-HILLDNTERAMERICANADE ESPANA, S . A. U.Edificio Valrealty, l.aplantaBasauri, 1728023 Aravaca (Madrid)Traducido de la quinta edicin en ingls deSOFTWARE ENGINEERING. A Practitioners Approach. European Adaptation ISBN: 0-07-709677-0 Copyright O MMI, by The McGraw-Hill Companies ISBN: 84-481-3214-9 Depsito legal: M. 42.852-2001Editora: Concepcin Femndez MadridDiseo de cubierta: Design Master DimaCompuesto en FERImpreso en: Imprenta FARESO. S. A.IMPRESO EN ESPANA - PRINTED I SPAIN N 5. ACERCA DEL AUTOR, XXIIIPREFACIO, XXVPRLOGO A LA CUARTA EDICIN EN ESPAOL, XXIXPRLOGO A LA QUINTA EDICIN EN ESPAOL, XXXIIIUTILIZACI~N DEL LIBRO, XXXVIIPARTE PRIMERA: EL PRODUCTO Y EL PROCESO CAP~TULO1. EL PRODUCTO, 3 CAP~TULO2. EL PROCESO, 13PARTE SEGUNDA: GESTIN DE PROYECTOS DE SOFTWARE CAP~TULO3. CONCEPTOS SOBRE GESTIN DE PROYECTOS, 37 CAP~TULO 4.PROCESO DE SOFTWARE Y MTRICAS DE PROYECTOS, 53 CAPITULO 5.PLANIFICACIN DE PROYECTOS DE SOFTWARE, 77 CAPITULO 6.ANLISIS Y GESTIN DEL RIESGO, 97 CAPITULO 7.PLANIFICACIN TEMPORAL Y SEGUIMIENTO DEL PROYECTO, 111 CAPITULO 8.GARANTIA DE CALIDAD DEL SOFTWARE (SQAICCS), 131 CAPITULO 9.GESTIN DE LA CONFIGURACIN DEL SOFTWARE (GCSISCM), 151PARTE TERCERA: MTODOS coNVENCIONALES PARA LA INGENIER~ADEL SOFTWARE CAP~TULO 10. INGENIERIA DE SISTEMAS, 165 CAPITULO 11. CONCEPTOS Y PRINCIPIOS DEL ANALISIS, 181 CAP~TULO 12. MODELADO DEL ANLISIS, 199 CAP~TULO 13. CONCEPTOS Y PRINCIPIOS DE DISENO, 219 CAPITULO 14. DISENO ARQUITECTNICO, 237 CAPITULO 15. DISENO DE LA INTERFAZ DE USUARIO, 259 CAP~TULO 16. DISENO A NIVEL DE COMPONENTES, 273 CAP~TULO 17. TCNICAS DE PRUEBA DEL SOFTWARE, 281 CAPITULO 18. ESTRATEGIAS DE PRUEBA DEL SOFTWARE, 305 CAP~TULO 19. MTRICAS TCNICAS DEL SOFTWARE, 323PARTE CUARTA: INGENIERIA DEL SOFTWARE ORIENTADA A OBJETOs CAPITULO 20. CONCEPTOS Y PRINCIPIOS ORIENTADOS A OBJETOS, 343 CAPITULO 21. ANLISIS ORIENTADO A OBJETOS, 361 CAPITULO 22. DISENO ORIENTADO A OBJETOS, 379 CAPITULO 23. PRUEBAS ORIENTADAS A OBJETOS, 407 CAPITULO 24. MTRICAS TCNICASPARA SISTEMAS ORIENTADOS A OBJETOS, 421DEL SOFTWAWPARTE OUINTA: TEMAS AVANZADOS EN INGENIER~A , CAPITULO 25. MTODOS FORMALES, 435 CAP~TULO 26. INGENIERIA DEL SOFTWARE DE SALA LIMPIA, 459 CAP~TULO 27. INGENIERIA DEL SOFTWARE BASADA EN COMPONENTES, 473 CAP~TULO 28. INGENIER~ADEL SOFTWARE DEL COMERCIO ELECTR~NICOCLIENTEISERVIDOR, 491 CAP~TULO29. INGENIER~A WEB, 521 V 6. CONTENIDOS A PRIMERA VISTA CAP~TULO 30. REINGENIERIA, 541 CAPITULO 31. INGENIER~ADEL SOFTWARE ASISTIDA POR COMPUTADORA, 559 CAP~TULO 32. PERSPECTIVAS FUTURAS, 573APNDICE, 581NDICE, 589VI 7. ACERCA DEL AUTOR, XXIIIPREFACIO, XXVPRLOGO A LA CUARTA EDICIN EN ESPAOL, XXIXPRLOGO A LA QUINTA EDICIN EN ESPAOL, XXXIIIUTILIZACIN DEL LIBRO, XXXVIIPARTE PRIMERA: EL PRODUCTO Y EL PROCESOCAP~TULO EL PRODUCTO, 31:1.1. LA E V O L U C I ~ N SOFTWARE 4DEL1.2. EL SOFTWARE, 5 1.2.1. CARACTER~STICAS DEL SOFTWARE, 5 1.2.2. APLICACIONES DEL SOFTWARE, 6 1.3. SOFTWARE: LUNACRISIS EN EL HORIZONTE?, 8 1.4. MITOS DEL SOFTWARE, 8RESUMEN, 10REFERENCIAS, 10PROBLEMAS Y PUNTOS A CONSIDERAR, 11OTRAS LECTURAS Y FUENTES DE INFORMACI~N, 112:CAP~TULO EL PROCESO, 132.1. INGENIERIA DEL SOFTWARE: UNA TECNOLOGAESTRATIFICADA, 14 2.1.1. PROCESO, MTODOS Y HERRAMIENTAS, 14 2.1.2. UNA VISIN GENERAL DE LA INGENIERA DEL SOFTWARE, 142.2. EL PROCESO DEL SOFTWARE, 162.3. MODELOS DE PROCESO DEL SOFTWARE, 192.4. EL MODELO LINEAL SECUENCIAL, 202.5. EL MODELO DE CONSTRUCCI~N PROTOTIPOS, 21 DE2.6. EL MODELO DRA, 222.7. MODELOS EVOLUTIVOS DE PROCESO DEL SOFTWARE, 23 2.7.1. EL MODELO INCREMENTAL, 23 2.1.2. EL MODELO ESPIRAL, 24 2.7.3. EL MODELO ESPIRAL WINWIN (Victoria & Victoria), 26 2.7.4. EL MODELO DE DESARROLLO CONCURRENTE, 27 2.8. DESARROLLO BASADO EN COMPONENTES, 28 2.9. EL MODELO DE MTODOS FORMALES, 292.10. TCNICAS DE CUARTA GENERACI~N, 292.11. TECNOLOG~AS PROCESO, 30DE2.12. PRODUCTO Y PROCESO, 31RESUMEN, 31REFERENCIAS, 32PROBLEMAS Y PUNTOS A CONSIDERAR, 32OTRAS LECTURAS Y FUENTES DE INFORMACI~N,33PARTE SEGUNDA: GESTIN DE PROYECTOS DE SOFTWARECAP~TULO CONCEPTOS SOBRE GESTIN DE PROYECTOS, 37 3: 3.1. EL ESPECTRO DE LA GESTIN, 38 3.1.1. PERSONAL, 38 VI1 8. CONTENIDO3.1.2. PRODUCTO, 383.1.3. PROCESO, 383.1.4. PROYECT0,393.2. PERSONAL, 393.2.1. LOS PARTICIPANTES, 393.2.2. LOS JEFES DE EQUIPO, 403.2.3. EL EQUIPO DE SOFTWARE, 403.2.4. ASPECTOS SOBRE LA COORDINACI~N LA COMUNICACI~N,Y433.3. PRODUCTO, 443.3.1. MBITO DEL SOFTWARE, 443.3.2. DESCOMPOSICIN DEL PROBLEMA, 453.4. PROCESO, 45 DEL PRODUCTO Y DEL PROCESO, 463.4.1, M A D U R A C I ~ N3.4.2. DESCOMPOSICI~N DEL PROCESO, 473.5. PROYECTO, 483.6. EL PRINCIPIO W5HH, 493.7. PRCTICAS CR~TICAS,49 RESUMEN, 50 REFERENCIAS, 50 PROBLEMAS Y PUNTOS A CONSIDERAR, 51 OTRAS LECTURAS Y FUENTES DE INFORMACI~N,51CAPTULO PROCESO DE SOFTWARE Y MTRICAS DE PROYECTOS, 53 4:4.1. MEDIDAS, MTRICAS E INDICADORES, 544.2. MTRICAS EN EL PROCESO Y DOMINIOS DEL PROYECTO, 55 4.2.1. MTRICAS DEL PROCESO Y MEJORAS EN EL PROCESO DEL SOFTWARE, 554.2.2. MTRICAS DEL PROYECTO, 584.3. MEDICIONES DEL SOFTWARE, 584.3.1. MTRICAS ORIENTADAS AL TAMANO, 594.3.2. MTRICAS ORIENTADAS A LA F U N C I ~ N61 ,4.3.3. MTRICAS AMPLIADAS DE PUNTO DE FUNCIN, 614.4. RECONCILIACIN DE LOS DIFERENTES ENFOQUES DE MTRICAS, 624.5. MTRICAS PARA LA CALIDAD DEL SOFTWARE, 634.5.1. VISIN GENERAL DE LOS FACTORES QUE AFECTAN A LA CALIDAD, 634.5.2. MEDIDA DE LA CALIDAD, 44.5.3. EFICACIA DE LA ELIMINACI~N DEFECTOS, 64 DE4.6. INTEGRACI~N LAS MTRICAS DENTRO DEL PROCESO DE INGENIER~ADE DEL SOFTWARE, 654.6.1. ARGUMENTOS PARA LAS MTRICAS DEL SOFTWARE, 654.6.2. ESTABLECIMIENTO DE UNA LNEA BASE, 664.6.3. COLECCIN DE MTRICAS, CMPUTO Y EVALUACIN, 664.7. EL DESARROLLO DE LA MTRICA Y DE LA OPM (OBJETIVO, PREGUNTA, MTRICA), 674.8. V A R I A C I ~ N LA GESTIN: CONTROL DE PROCESOS ESTAD~STICOS,DE 694.9. MTRICA PARA ORGANIZACIONES PEQUEAS, 71 4.10. ESTABLECIMIENTO DE UN PROGRAMA DE MTRICAS DE SOFTWARE, 72 RESUMEN, 73 REFERENCIAS, 74 PROBLEMAS Y PUNTOS A CONSIDERAR, 75 OTRAS LECTURAS Y FUENTES DE INFORMACI~N,75CAPTULO PLANIFICACIN DE PROYECTOS DE SOFTWARE, 77 5:5.1. OBSERVACIONES SOBRE LA ESTIMACI~N,785.2. OBJETIVOS DE LA PLANIFICACI~N DEL PROYECTO, 79VI11 9. CONTENIDO 5.3. MBITO DEL SOFTWARE, 795.3.1. OBTENCI~N LA INFORMACI~N DENECESARIA PARA EL MBITO, 795.3.2. VIABILIDAD, 805.3.3. UN EJEMPLO DE MBITO, 80 5.4. RECURSOS,825.4.1. RECURSOS HUMANOS, 825.4.2. RECURSOS DE SOFTWARE REUTILIZABLES, 825.4.3. RECURSOS DE ENTORNO, 83 5.5. ESTIMACIN DEL PROYECTO D E SOFTWARE, 84 5.6. TCNICAS DE DESCOMPOSICI~N, 855.6.1 TAMAO DEL SOFTWARE, 855.6.2. ESTIMACIN BASADA EN EL PROBLEMA, 865.6.3. UN EJEMPLO DE ESTIMACIN BASADA EN LDC, 875.6.4. UN EJEMPLO DE ESTIMACI~N BASADA EN PF, 885.6.5. ESTIMACI~N BASADA EN EL PROCESO, 895.6.6. UN EJEMPLO DE ESTIMACI~N BASADA EN EL PROCESO, 89 5.7. MODELOS EMPIRICOS DE ESTIMACIN, 905.7.1. LA ESTRUCTURA DE LOS MODELOS DE ESTIMACI~N, 905.7.2. EL MODELO COCOMO, 915.7.3. L A E C U A C I ~ NDEL SOFTWARE, 92 5.8. LA DECISIN DE DESARROLLAR-COMPRAR, 925.8.1. C R E A C I ~ N UN RBOL DE DECISIONES, 93 DE5.8.2. SUBCONTRATACI~N(OUTSOURCM), 94 5.9. HERRAMIENTAS AUTOMTICAS DE ESTIMACI~N, 94RESUMEN, 95REFERENCIAS, 95PROBLEMAS Y PUNTOS A CONSIDERAR, 96OTRAS LECTURAS Y FUENTES D E INFORMACIN, 96CAPTULO 6: ANLISIS Y GESTIN DEL RIESGO, 97 6.1. ESTRATEGIAS D E RIESGO PROACTIVAS VS. REACTIVAS, 98 6.2. RIESGO DEL SOFTWARE, 98 6.3. IDENTIFICACI~N RIESGO, 99DEL6.3.1. EVALUACI~N GLOBAL DEL RIESGO DEL PROYECTO, 1006.3.2. COMPONENTES Y CONTROLADORES DEL RIESGO, 101 6.4. PROYECCIN DEL RIESGO, 1016.4.1. DESARROLLO DE UNA TABLA DE RIESGO, 1016.4.2. EVALUACIN DEL IMPACTO DEL RIESGO, 1036.4.3. EVALUACIN DEL RIESGO, 103 6.5. REFINAMIENTO DEL RIESGO, 104 6.6. REDUCCIN, SUPERVISIN Y GESTIN DEL RIESGO, 105 6.7. RIESGOS Y PELIGROS PARA LA SEGURIDAD, 106 6.8. E L PLAN RSGR, 107RESUMEN, 107REFERENCIAS, 107PROBLEMAS Y PUNTOS A CONSIDERAR, 108OTRAS LECTURAS Y FUENTES DE INFORMACI~N, 108TEMPORAL Y SEGUIMIENTO DEL PROYECTO, 111CAPTULO 7: PLANIFICACI~N 7.1. CONCEPTOS BSICOS, 1127.1.1. COMENTARIOS SOBRE LOS RETRASOS, 1127.1.2. PRINCIPIO BSICOS, 113 IX 10. CONTENIDOENTRE LAS PERSONAS Y EL ESFUERZO, 1147.2. LA R E L A C I ~ N 7.2.1. UN EJEMPLO, 115 7.2.2. UNA R E L A C I ~ N115 EMP~RICA, 7.2.3. DISTRIBUCIN DEL ESFUERZO, 115DE7.3. DEFINICI~N UN CONJ UNTO DE TAREAS PARA EL PROYECTO DE SOFTWARE, 116 7.3.1. GRADO DE RIGOR, 117 7.3.2. DEFINIR LOS CRITERIOS DE ADAPTACI~N,117 7.3.3. CLCULO DEL VALOR SELECTOR DEL CONJUNTO DE TAREAS, 117 7.3.4. INTERPRETAR EL VALOR SCT Y SELECCIONAR EL CONJUNTO DE TAREAS, 1197.4. S E L E C C I ~ N LAS TAREAS DE INGENIER~ADEL SOFTWARE, 119 DE7.5. REFINAMIENTO DE LAS TAREAS PRINCIPALES, 1201.6. DEFINIR UNA RED DE TAREAS, 1217.7. LA PLANIFICACI~NTEMPORAL, 122 7.7.1. GRFICOS DE TIEMPO, 123 7.7.2. SEGUIMIENTO DE LA PLANIFICACI~NTEMPORAL, 1247.8. ANLISIS DE VALOR GANADO, 1257.9. SEGUIMIENTO DEL ERROR, 126 7.10. EL PLAN DEL PROYECTO, 127 RESUMEN, 127 REFERENCIAS, 128 PROBLEMAS Y PUNTOS A CONSIDERAR, 128 OTRAS LECTURAS Y FUENTES DE INFORMACI~N,129CAP~TULO GARANT~A CALIDAD DEL SOFTWARE SOA/GCS), 131 8: DE8.1. CONCEPTOS DE CALIDAD, 132 8.1.1. CALIDAD, 132 8.1.2. CONTROLDE CALIDAD, 133 8.1.3. GARANTIADECALIDAD, 133 8.1.4. COSTE DE CALIDAD, 1338.2. LA TENDENCIA DE LA CALIDAD, 1348.3. GARANTIA DE CALIDAD DEL SOFTWARE, 135 8.3.1. PROBLEMAS DE FONDO, 135 8.3.2. ACTIVIDADES DE SQA, 1368.4. REVISIONES DEL SOFTWARE, 137 8.4.1. IMPACTO DE LOS DEFECTOS DEL SOFTWARE SOBRE EL COSTE, 137 8.4.2. AMPLIFICACIN Y ELIMINACIN DE DEFECTOS, 1388.5. REVISIONES TCNICAS FORMALES, 138 8.5.1. L A R E U N I ~ N REVISI~N, DE 139 8.5.2. REGISTRO E INFORME DE LAREVISI~N,140 8.5.3. DIRECTRICES PARALAREVISI~N,1408.6. GARANT~A CALIDAD ESTAD~STICA,DE1418.7. FIABILIDAD DEL SOFTWARE, 143 8.7.1. MEDIDAS DE FIABILIDAD Y DE DISPONIBILIDAD, 143 8.7.2. SEGURIDAD DEL SOFTWARE, 1448.8. PRUEBA DE ERRORES PARA EL SOFTWARE, 1458.9. EL ESTNDAR DE CALIDAD ISO 9001,146 8.10. EL PLAN DE SQA, 147 RESUMEN, 148 REFERENCIAS, 148 PROBLEMAS Y PUNTOS A CONSIDERAR, 149 OTRAS LECTURAS Y FUENTES DE INFORMACI~N,150CAP~TULO GESTIN DE LA CONFIGURACIN DEL SOFTWARE GCSISCM1,lSl 9:9.1. GESTIN DE LA CONFIGURACIN DEL SOFTWARE, 152 X 11. CONTENIDO9.1.1. LNEAS BASE, 1529.1.2. ELEMENTOS DE CONFIGURACI~NDEL SOFTWARE, 153 9.2. EL PROCESO DE GCS, 154 9.3. IDENTIFICACI~NDE OBJETOS EN LA CONFIGURACI~N DEL SOFTWARE, 154 9.4. CONTROL DE VERSIONES, 155 9.5. CONTROL DE CAMBIOS, 156DE 9.6. AUDITORA LA CONFIGURACI~N,158 9.7. INFORMES DE ESTADO, 159RESUMEN, 159REFERENCIAS, 160PROBLEMAS Y PUNTOS A CONSIDERAR, 160OTRAS LECTURAS Y FUENTES DE INFORMACI~N,161PARTE TERCERA: MTODOS CONVENCIONALES PARA LA INGENIERA DEL SOFTWARECAPTULO 10: INGENIERA DE SISTEMAS, 16510.1. SISTEMAS BASADOS EN COMPUTADORA, 16710.2. LA JERARQUA LA INGENIERA SISTEMAS, 167 DEDE10.2.1. MODELADO DEL SISTEMA, 16710.2.2. SIMULACI~NDEL SISTEMA, 16810.3. INGENIERIA DE PROCESO DE NEGOCIO: UNA VISIN GENERAL, 16910.4. INGENIERIA DE PRODUCTO: UNA VISIN GENERAL, 17110.5. INGENIERA REQUISITOS, 171 DE10.5.1. IDENTIFICACIN DE REQUISITOS, 17210.5.2. ANLISIS Y NEGOCIACI~N REQUISITOS, 173DE10.5.3. ESPECIFICACIN DE REQUISITOS, 17310.5.4. MODELADO DEL SISTEMA, 17410.5.5. VALIDACIN DE REQUISITOS, 17410.5.6. GESTIN DE REQUISITOS, 17410.6. MODELADO DEL SISTEMA, 175RESUMEN, 178REFERENCIAS, 178PROBLEMAS Y PUNTOS A CONSIDERAR, 179OTRAS LECTURAS Y FUENTES DE INFORMACION, 179CAPITULO 11: CONCEPTOS Y PRINCIPIOS DEL ANLISIS, 18111.1. ANLISIS DE REQUISITOS, 18211.2. IDENTIFICACIN DE REQUISITOS PARA EL SOFTWARE, 183 11.2.1.INICIO DEL PROCESO, 183 11.2.2.TCNICAS PARA FACILITAR LAS ESPECIFICACIONES DE UNA APLICACI~N,I 84 11.2.3.DESPLIEGUE DE LA FUNCIN DE CALIDAD, 186 11.2.4.CASOS DE USO, 18611.3. PRINCIPIOS DEL ANLISIS, 188 11.3.1.EL DOMINIO DE LA INFORMACIN, 189 11.3.2.MODELADO, 190 11.3.3.PARTICIN, 190 11.3.4.VISIONES ESENCIALES Y DE IMPLEMENTACI~N, 19111.4. CREACIN DE PROTOTIPOS DEL SOFTWARE, 19211.4.1. SELECCI~NDEL ENFOQUE DE C R E A C I ~ N PROTOTIPOS, I 92DE 11.4.2. MTODOS Y HERRAMIENTAS PARA EL DESARROLLO DE PROTOTIPOS, 19311.5. ESPECIFICACI~N,193 XI 12. CONTENIDO 11.5.1. PRINCIPIOS DE LA ESPECIFICACIN, 194 11.5.2. REPRESENTACI~N,194 11.5.3. LAESPECIFICACIN DE LOS REQUISITOS DEL SOFTWARE, 19411.6. R E V I S I ~ N LA ESPECIFICACI~N,DE 195RESUMEN, 196REFERENCIAS, 196PROBLEMAS Y PUNTOS A CONSIDERAR, 197OTRAS LECTURAS Y FUENTES DE INFORMACI~N, 197CAPTULO MODELADO DEL A NLISIS, 199 12:12.1. BREVE HISTORIA, 20012.2. LOS ELEMENTOS DEL MODELO DE ANLISIS, 20012.3. MODELADO DE DATOS, 20112.3.1. OBJETOS DE DATOS, ATRIBUTOS Y RELACIONES, 201 12.3.2. CARDINALIDAD Y MODALIDAD, 203 12.3.3. DIAGRAMAS ENTIDAD-RELACIN, 20412.4. MODELADO FUNCIONAL Y FLUJO DE INFORMACIN, 205 12.4.1. DIAGRAMAS DE FLUJO DE DATOS, 206 12.4.2. AMPLIACIONES PARA SISTEMAS DE TIEMPO REAL, 207 12.4.3. AMPLIACIONES DE WARD Y MELLOR, 207 12.4.4. AMPLIACIONES DE HATLEY Y PIRBHAI, 20812.5. MODELADO DEL COMPORTAMIENTO, 20912.6. MECANISMOS DEL ANLISIS ESTRUCTURADO, 21012.6.1. CREACI~N U N DIAGRAMA ENTIDAD-RELACI~N, DE21012.6.2. CREACI~N UN MODELO DE FLUJO DE DATOS, 211 DE 12.6.3. CREACIN DE UN MODELO DE FLUJO DE CONTROL, 213 12.6.4. LAESPECIFICACIN DE CONTROL, 214 12.6.5. LA ESPECIFICACIN DEL PROCESO, 21412.7. EL DICCIONARIO DE DATOS, 21512.8. OTROS MTODOS CLSICOS DE ANLISIS, 216RESUMEN, 216REFERENCIAS, 217PROBLEMAS Y PUNTOS A CONSIDERAR, 217OTRAS LECTURAS Y FUENTES DE INFORMACI~N, 218CAPTULO13: CONCEPTOS Y PRINCIPIOS DE DISENO, 21913.1. DISENO DEL SOFTWARE E INGENIERIA DEL SOFTWARE, 22013.2. EL PROCESO DE DISENO, 221 13.2.1. DISEOY CALIDAD DEL SOFTWARE, 221 13.2.2. LA EVOLUCI~N DEL DISENO DEL SOFTWARE, 22113.3. PRINCIPIOS DEL DISENO, 22213.4. CONCEPTOS DEL DISENO, 223 13.4.1. ABSTRACCI~N,223 13.4.2. REFINAMIENTO, 224 13.4.3. MODULARIDAD, 224 13.4.4. ARQUITECTURA DEL SOFTWARE, 226 13.4.5. JERARQU~ADE CONTROL, 226 13.4.6. DIVISIN ESTRUCTURAL, 227 13.4.7. ESTRUCTURA DE DATOS, 228 13.4.8. PROCEDIMIENTO DE SOFTWARE, 229 13.4.9. OCULTACI~N INFORMACI~N, DE 22913.5. DISENO MODULAR EFECTIVO. 229 13. CONTENIDO13.5.1. INDEPENDENCIA FUNCIONAL, 22913.5.2. COHESIN, 23013.5.3. ACOPLAMIENTO, 231 13.6. HEURSTICA DISENO PARA UNA MODULARIDAD EFECTIVA, 231DE 13.7. EL MODELO DEL DISENO, 233 13.8. DOCUMENTACI~NDEL DISENO, 233 RESUMEN, 234 REFERENCIAS, 234 PROBLEMAS Y PUNTOS A CONSIDERAR, 235 OTRAS LECTURAS Y FUENTES DE INFORMACI~N,236CAPTULO 14: DISENO AROUITECT~NICQ ,237 14.1. ARQUITECTURA DEL SOFTWARE, 238 14.1.1. LQUES ARQUITECTURA?, 238 14.1.2. POR QU ES IMPORTANTE LA ARQUITECTURA?, 238 14.2. DISENO DE DATOS, 239 14.2.1 MODELADO DE DATOS, ESTRUCTURAS DE DATOS, BASES DE DATOS Y ALMACN DE DATOS, 239 14.2.2. DISENO DE DATOS A NIVEL DE COMPONENTES, 240 14.3. ESTILOS ARQUITECT~NICOS,241 14.3.1. UNA BREVE TAXONOMADE ESTILOS Y PATRONES, 241 14.3.2. ORGANIZACIN Y REFINAMIENTO, 243 14.4. ANLISIS DE DISEHOS ARQUITECT~NICOS ALTERNATIVOS, 243 14.4.1. UN MTODO DE ANALISIS DE COMPROMISO PARA LA ARQUITECTURA, 243 14.4.2. GUA CUANTITATIVAPARA EL DISENO ARQUITECTNICO, 244 14.4.3. COMPLEJIDAD ARQUITECTNICA, 245 14.5. CONVERSIN DE LOS REQUISITOS EN UNA ARQUITECTURA DEL SOFTWARE, 245 14.5.1. FLUJO DE TRANSFORMACI~N,246 14.5.2. FLUJO DE TRANSACCIN, 246 14.6. ANLISIS DE LAS TRANSFORMACIONES, 247 14.6.1. UN EJEMPLO, 247 14.6.2. PASOS DEL DISENO, 247 14.7. ANLISIS DE LAS TRANSACCIONES, 252 14.7.1. UN EJEMPLO, 252 14.7.2. PASOS DEL DISEO, 25214.8. REFINAMIENTO DEL DISENO ARQUITECT~NICO,25s RESUMEN, 256 REFERENCIAS, 256 PROBLEMAS Y PUNTOS A CONSIDERAR, 257 OTRAS LECTURAS Y FUENTES DE INFORMACI~N,258CAPITULO 15:DISENO DE LA 1NTERFAZ DE USUARIO,25915.1. LAS REGLAS DE ORO, 260 15.1.1. DAR ELCONTROLALUSUARIO, 260 15.1.2. REDUCIR LA CARGA DE MEMORIA DEL USUARIO, 260 15.1.3. CONSTRUCCIN DE UNA INTERFAZ CONSISTENTE, 26115.2. DISEO DE LA INTERFAZ DE USUARIO, 262 15.2.1. MODELOS DE DISENO DE LAINTERFAZ, 262 15.2.2. EL PROCESO DE DISENO DE LA INTERFAZ DE USUARIO, 26315.3. ANLISIS Y MODELADO DE TAREAS, 26415.4. ACTIVIDADES DEL DISENO DE LA INTERFAZ, 264 15.4.1. DEFINICIN DE OBJETOS Y ACCIONES DE LA INTERFAZ, 265 15.4.2. PROBLEMAS DEL DISEO, 266XIII 14. CONTENIDO15.5. HERRAMIENTAS DE IMPLEMENTACI~N,26815.6. EVALUACIN DEL DISENO, 268RESUMEN, 270REFERENCIAS, 270PROBLEMAS Y PUNTOS A CONSIDERAR, 270OTRAS LECTURAS Y FUENTES DE INFORMACI~N, 271CAPTULO 16: DISENO A NIVEL DE COMPONENTES, 27316.1. PROGRAMACI~NESTRUCTURADA, 27416.1.1. NOTACIN GRFICA DEL DISENO, 274 16.1.2. NOTACIN TABULAR DE DISENO, 274 16.1.3. LENGUAJE DE DISENO DE PROGRAMAS, 276 16.1.4. UN EJEMPLO DE LDP, 27716.2. COMPARACI~N NOTACIONES DE DISENO, 278DERESUMEN, 279REFERENCIAS, 279PROBLEMAS Y PUNTOS A CONSIDERAR, 280OTRAS LECTURAS Y FUENTES DE INFORMACIN, 280CAPTULO TCNICAS DE PRUEBA DEL SOFTWARE, 281 17:17.1. FUNDAMENTOS DE LAS PRUEBAS DEL SOFTWARE, 282 17.1.1. OBJETIVOS DE LAS PRUEBAS, 282 17.1.2. PRINCIPIOS DE LAS PRUEBAS, 282 17.1.3. FACILIDAD DE PRUEBA, 28317.2. DISENO DE CASOS DE PRUEBA, 28517.3. PRUEBA DE CAJA BLANCA, 28617.4. PRUEBA DEL CAMINO BSICO, 286 17.4.1. NOTACIN DE GRAFO DE FLUJO, 286 17.4.2. COMPLEJIDAD CICLOMTICA, 287 17.4.3. OBTENCI~N CASOS DE PRUEBA, 288 DE 17.4.4. MATRICES DE GRAFOS, 29017.5. PRUEBA DE LA ESTRUCTURA DE CONTROL, 291 17.5.1. PRUEBA DE CONDICIN, 291 17.5.2. PRUEBA DEL FLUJO DE DATOS, 292 17.5.3. PRUEBA DE BUCLES, 29317.6. PRUEBA DE CAJA NEGRA, 294 17.6.1. MTODOS DE PRUEBA BASADOS EN GRAFOS, 294 17.6.2. PARTICIN EQUIVALENTE, 296 17.6.3. ANLISIS DE VALORES L~MITE,297 17.6.4. PRUEBA DE COMPARACIN, 297 17.6.5. PRUEBA DE LATABLA ORTOGONAL, 29817.7. PRUEBA DE ENTORNOS ESPECIALIZADOS, ARQUITECTURAS Y APLICACIONES, 299 17.7.1. PRUEBA DE INTERFACES GRFICAS DE USUARIO (IGUs), 299 17.7.2. PRUEBA DE ARQUITECTURA CLIENTE/SERVIDOR, 300 17.7.3. PRUEBA DE LA DOCUMENTACI~NY FACILIDADES DE AYUDA, 300 17.7.4. PRUEBA DE SISTEMAS DE TIEMPO-REAL, 300RESUMEN, 301REFERENCIAS, 302PROBLEMAS Y PUNTOS A CONSIDERAR, 302OTRAS LECTURAS Y FUENTES DE INFORMACI~N, 303 XIV 15. CONTENIDOCAPITULO 18: ESTRATEGIAS DE PRUEBA DEL SOFTWARE, 30518.1. UN ENFOQUE ESTRATGICO PARA LAS PRUEBAS DEL SOFTWARE, 306 18.1.1, VERIFICACI~N VALIDACI~N,Y306 18.1.2. ORGANIZACIN PARA LAS PRUEBAS DEL SOFTWARE, 307 18.1.3. UNA ESTRATEGIA DE PRUEBA DEL SOFTWARE, 307 18.1.4. CRITERIOS PARA COMPLETAR LA PRUEBA, 30818.2. ASPECTOS ESTRATGICOS, 30918.3. PRUEBA DE UNIDAD, 310 18.3.1. CONSIDERACIONES SOBRE LAPRUEBA DE UNIDAD, 310 18.3.2. PROCEDIMIENTOS DE PRUEBA DE UNIDAD, 31 118.4. PRUEBA DE INTEGRACI~N, 312 18.4.1. INTEGRACIN DESCENDENTE, 312 18.4.2. INTEGRACIN ASCENDENTE, 3 13 18.4.3. PRUEBA DE REGRESIN, 314 18.4.4. PRUEBA DE HUMO, 314 18.4.5. COMENTARIOS SOBRE LA PRUEBA DE INTEGRACIN, 31 518.5. PRUEBA DE VALIDACIN, 316 18.5.1. CRITERIOS DE LA PRUEBA DE VALIDACIN, 316 18.5.2. R E V I S I ~ N LACONFIGURACI~N,DE316 18.5.3. PRUEBAS ALFAY BETA, 31618.6. PRUEBA DEL SISTEMA, 317 18.6.1. PRUEBA DE RECUPERACIN, 317 18.6.2. PRUEBADE SEGURIDAD, 317 18.6.3. PRUEBA DE RESISTENCIA (STRESS), 318 18.6.4. PRUEBA DE RENDIMIENTO, 31818.7. EL ARTE DE LA DEPURACIN, 318 18.7.1. ELPROCESO DE DEPURACIN, 319 18.7.2. CONSIDERACIONES PSICOLGICAS, 319 18.7.3. ENFOQUES DE LA DEPURACIN, 320RESUMEN, 321REFERENCIAS, 321PROBLEMAS Y PUNTOS A CONSIDERAR, 322OTRAS LECTURAS Y FUENTES DE INFORMACI~N, 322CAPTULO 19: MTRICAS TCNICAS DEL SOFTWARE, 32319.1. CALIDAD DEL SOFTWARE, 324 19.1.1. FACTORES DE CALIDAD DE McALL, 324 19.1.2. FURPS, 325 19.1.3. FACTORES DE CALIDAD ISO 9126,326 19.1.4. LA TRANSICIN A UNA VISIN CUANTITATIVA, 32619.2. UNA ESTRUCTURA PARA LAS MTRICAS TCNICAS DEL SOFTWARE, 327 19.2.1. ELRETO DE LAS MTRICAS TCNICAS, 327 19.2.2. PRINCIPIOS DE MEDICIN, 328 19.2.3. CARACTER~STICASFUNDAMENTALES DE LAS MTRICAS DEL SOFTWARE, 32819.3. MTRICAS DEL MODELO DE ANLISIS, 329 19.3.1. MTRICAS BASADAS EN LAFUNCIN, 329 19.3.2. LAMTRICABANG,330 19.3.3. MTRICAS DE LA CALIDAD DE LA ESPECIFICACI~N,33119.4. MTRICAS DEL MODELO DE DISENO, 332 19.4.1. MTRICAS DEL DISENO ARQUITECT~NICO, 332 19.4.2. MTRICAS DE DISEO A NIVEL DE COMPONENTES, 333 19.4.3. MTRICAS DE DISEO DE INTERFAZ, 33519.5. MTRICAS DEL CDIGO FUENTE, 336 xv 16. CONTENIDO19.6. MTRICAS PARA PRUEBAS, 33719.7. MTRICAS DEL MANTENIMIENTO, 338RESUMEN, 338REFERENCIAS, 338PROBLEMAS Y PUNTOS A CONSIDERAR, 339OTRAS LECTURAS Y FUENTES DE INFORMACI~N, 340PARTE CUARTA: INGENIERA DEL SOFTWARE ORIENTADA A 0B.IETOSCAPTULO 20: CONCEPTOS Y PRINCIPIOS ORIENTADOS A OBJETOS, 34320.1. EL PARADIGMA ORIENTADO A OBJETOS, 34420.2. CONCEPTOS DE ORIENTACI~N OBJETOS, 345 A 20.2.1. CLASES Y OBJETOS, 346 20.2.2. ATRIBUTOS, 347 20.2.3. OPERACIONES, MTODOS Y SERVICIOS, 347 20.2.4. MENSAJES, 347 20.2.5. ENCAPSULAMIENTO, HERENCIA Y POLIMORFISMO, 34820.3. IDENTIFICACI~NDE LOS ELEMENTOS DE UN MODELO DE OBJETOS, 350 20.3.1. IDENTIFICACIN DE CLASES Y OBJETOS, 350 20.3.2. ESPECIFICACIN DE ATRIBUTOS, 353 20.3.3. DEFINICI~N OPERACIONES, 353DE 20.3.4. FIN DE LA DEFINICIN DEL OBJETO, 35420.4. GESTIN DE PROYECTOS DE SOFTWARE ORIENTADO A OBJETOS, 354 20.4.1. EL MARCO DE PROCESO COMN PARA 0 0 , 3 5 5 20.4.2. MTRICAS Y ESTIMACIN EN PROYECTOS ORIENTADOS A OBJETOS, 356 20.4.3. UN ENFOQUE O 0 PARA ESTIMACIONES Y PLANIFICACIN, 357 20.4.4. SEGUIMIENTO DEL PROGRESO EN UN PROYECTO ORIENTADO A OBJETOS, 358RESUMEN, 358REFERENCIAS, 359PROBLEMAS Y PUNTOS A CONSIDERAR, 359OTRAS LECTURAS Y FUENTES DE INFORMACIN, 360CAPITULO 21: ANLISIS ORIENTADO A OBJETOS, 36121.1. ANLISIS ORIENTADO A OBJETOS, 36220.1.1. ENFOQUES CONVENCIONALES Y ENFOQUES 0 0 , 3 6 2 21.1.2. EL PANORAMA DEL AOO, 362 21.1.3. UN ENFOQUE UNIFICADO PARA EL AOO, 36321.2. ANLISIS DEL DOMINIO, 364 21.2.1. ANLISIS DE REUTILIZACIN Y DEL DOMINIO, 364 21.2.2. EL PROCESO DE ANLISIS DEL DOMINIO, 36521.3. COMPONENTES GENRICOS DEL MODELO DE ANLISIS 00,36621.4. EL PROCESO DE AOO, 367 21.4.1. CASOS DE USO, 367 21.4.2. MODELADO DE CLASES-RESPONSABILIDADES-COLABORACIONES, 368 21.4.3. DEFINICI~NDE ESTRUCTURAS Y JERARQU~AS,371 21.4.4. DEFINICIN DE SUBSISTEMAS, 37221.5. EL MODELO OBJETO-RELACI~N, 37321.6. EL MODELO OBJETO-COMPORTAMIENTO, 374 21.6.1. IDENTIFICACIN DE SUCESOS CON CASOS DE USO, 374 21.6.2. REPRESENTACIONES DE ESTADOS, 375RESUMEN, 376REFERENCIAS, 377 XVI 17. CONTENIDOPROBLEMAS Y PUNTOS A CONSIDERAR, 377OTRAS LECTURAS Y FUENTES DE INFORMACI~N, 378CAPTULO22: DISENO ORIENTADO A OBJETOS,37922.1. DISENO PARA SISTEMAS ORIENTADOSA OBJETOS, 380 22.1.1. ENFOQUE CONVENCIONAL VS. 0 0 , 3 8 0 22.1.2. ASPECTOS DEL DISENO, 381 22.1.3. EL PANORAMA DE DOO, 382 22.1.4. UN ENFOQUE UNIFICADO PARA EL DOO, 38322.2. EL PROCESO DE DISENO DE SISTEMA, 384 22.2.1. PARTICIONAR EL MODELO DE ANALISIS, 384 22.2.2. ASIGNACI~N CONCURRENCIA Y SUBSISTEMAS, 385DE 22.2.3. COMPONENTE DE ADMINISTRACIN DE TAREAS, 386 22.2.4. COMPONENTE DE INTERFAZ DE USUARIO, 386 22.2.5. COMPONENTE DE LA ADMINISTRACI~N DATOS, 386 DE 22.2.6. COMPONENTE DE GESTIN DE RECURSOS, 387 22.2.7. COMUNICACIONES ENTRE SUBSISTEMAS, 38722.3. PROCESO DE DISENO DE OBJETOS, 388 22.3.1. DESCRIPCIN DE OBJETOS, 388 22.3.2. DISENO DE ALGORITMOS Y ESTRUCTURAS DE DATOS, 38922.4. PATRONES DE DISENO, 390 22.4.1. ~ Q U UN PATRN DE DISENO?, 390 ES 22.4.2. OTRO EJEMPLO DE UN PATRN, 391 22.4.3. UN EJEMPLO FINAL DE UN PATRN, 391 22.4.4. DESCRIPCIN DE UN PATRN DE DISENO, 392 22.4.5. EL FUTURO DE LOS PATRONES, 392 ORIENTADA A OBJETOS, 39322.5. PROGRAMACI~N 22.5.1. EL MODELO DE CLASES, 393 22.5.2. GENERALIZACI~N, 394 22.5.3. AGREGACI~N COMPOSICI~N, Y394 23.5.4. ASOCIACIONES, 395 22.5.5. CASOS DE USO, 395 22.5.6. COLABORACIONES, 396 22.5.7. DIAGRAMAS DE ESTADO, 39722.6. CASO DE ESTUDIO. LIBROS EN LNEA, 398 22.6.1. LIBROS-EN-LNEA, 39922.7. PROGRAMACI~N ORIENTADA A OBJETOS, 400RESUMEN, 404REFERENCIAS, 404PROBLEMAS Y PUNTOS A CONSIDERAR, 405OTRAS LECTURAS Y FUENTES DE INFORMACI~N,405CAPTULO 23: PRUEBAS ORIENTADAS A OBJETOS, 40723.1. AMPLIANDO LA VISIN DE LAS PRUEBAS, 40823.2. PRUEBAS DE LOS MODELOS DE A 0 0 Y DOO, 40923.2.1. EXACTITUD DE LOS MODELOS DE A 0 0 Y DOO, 409 23.2.2. CONSISTENCIA DE LOS MODELOS DE A 0 0 Y DOO, 40923.3. ESTRATEGIAS DE PRUEBAS ORIENTADAS A OBJETOS, 410 23.3.1. LAS PRUEBAS DE UNIDAD EN EL CONTEXTO DE LA00,410 23.3.2. LAS PRUEBAS DE INTEGRACI~N EL CONTEXTO 00,4i 1EN 23.3.3. PRUEBAS DE VALIDACIN EN UN CONTEXTO 0 0 , 4 1 123.4. DISENO DE CASOS DE PRUEBA PARA SOFTWARE 0 0 , 4 1 2 23.4.1. IMPLICACIONES DE LOS CONCEPTOS DE O0 AL DISENO DE CASOS DE PRUEBA, 412 XVII 18. CONTENIDO23.4.2. APLICABILIDAD DE LOS MTODOS CONVENCIONALES DE DISE NO DE CASOS DEPRUEBA, 4 1223.4.3. PRUEBAS BASADAS EN ERRORES, 41223.4.4. EL IMPACTO DE LA PROGRAMACIN O0 EN LAS PRUEBAS, 41323.4.5. CASOS DE PRUEBA Y JERARQUA DE CLASES, 41423.4.6. DISENO DE PRUEBAS BASADAS EN EL ESCENARIO, 41423.4.7. LAS ESTRUCTURAS DE PRUEBAS SUPERFICIALES Y PROFUNDAS, 41523.5. MTODOS DE PRUEBA APLICABLES AL NIVEL DE CLASES, 41623.5.1. LA VERIFICACIN ALAZAR PARA CLASES 0 0 , 4 1 623.5.2. PRUEBA DE PARTICIN AL NIVEL DE CLASES, 41623.6. DISENO DE CASOS DE PRUEBA INTERCLASES, 41723.6.1. PRUEBA DE MLTIPLES CLASES, 41723.6.2. PRUEBA DERIVADA DE LOS MODELOS DE COMPORTAMIENTO, 418RESUMEN, 419REFERENCIAS, 419PROBLEMAS Y PUNTOS A CONSIDERAR, 419OTRAS LECTURAS Y FUENTES DE INFORMACI~N, 420CAPTULO 24: MTRICAS TCNICAS PARA SISTEMAS ORIENTADOS A OBJETOS, 42124.1. EL PROPSITO DE LAS MTRICAS ORIENTADAS A OBJETOS, 42224.2. CARACTERISTICAS DISTINTIVAS DE LAS MTRICAS ORIENTADAS A OBJETOS, 42224.2.1. LOCALIZACIN, 42224.2.2. ENCAPSULACIN, 42224.2.3. OCULTACI~N INFORMACI~N,DE42324.2.4. HERENCIA, 42324.2.5. ABSTRACCIN, 42324.3. MTRICAS PARA EL MODELO DE DISENO 0 0 , 4 2 324.4. MTRICAS ORIENTADAS A CLASES, 42424.4.1. LA SERIE DE MTRICAS CK, 42524.4.2. MTRICAS PROPUESTAS POR LORENZ Y KIDD, 42624.4.3. LA COLECCIN DE MTRICAS MDOO, 42724.5. MTRICAS ORIENTADAS A OPERACIONES, 42824.6. MTRICAS PARA PRUEBAS ORIENTADAS A OBJETOS, 42824.7. MTRICAS PARA PROYECTOS ORIENTADOS A OBJETOS, 429RESUMEN, 430REFERENCIAS, 430PROBLEMAS Y PUNTOS A CONSIDERAR, 431OTRAS LECTURAS Y FUENTES DE INFORMACI~N, 431PARTE OUINTA: TEMAS AVANZADOS EN INGENIERA DEL SOFTWARECAPTULO 25: MTODOS FORMALES, 43525.1. CONCEPTOS BSICOS, 43625.1.1. DEFICIENCIAS DE LOS ENFOQUES MENOS FORMALES, 43625.1.2. MATEMTICAS EN EL DESARROLLO DEL SOFTWARE, 43725.1.3. CONCEPTOS DE LOS MTODOS FORMALES, 43825.2. PRELIMINARES MATEMTICOS, 44125.2.1. CONJUNTOS Y ESPECIFICACI~NCONSTRUCTIVA, 44225.2.2. OPERADORES DE CONJUNTOS, 44225.2.3. OPERADORES LGICOS, 44325.2.4. SUCESIONES. 443 XVIII 19. CONTENIDO25.3. APLICACI~N LA N O T A C I ~ NDEMATEMTICA PARA LA ESPECIFICACI~NFORMAL, 44425.4. LENGUAJES FORMALES DE ESPECIFICACI~N,44525.5. USO DEL LENGUAJE Z PARA REPRESENTAR UN COMPONENTE EJEMPLO DESOFTWARE, 44625.6. MTODOS FORMALES BASADOS EN OBJETOS, 44725.7. ESPECIFICACIN ALGEBRAICA, 45025.8. MTODOS FORMALES CONCURRENTES, 45225.9. LOS DIEZ MANDAMIENTOS DE LOS MTODOS FORMALES, 45525.10. MTODOS FORMALES: EL FUTURO, 456RESUMEN, 456REFERENCIAS, 457PROBLEMAS Y PUNTOS A CONSIDERAR, 457OTRAS LECTURAS Y FUENTES DE INFORMACI~N, 458CAPITULO 26: INGENIERIA DEL SOFTWARE DE SALA LIMPIA, 45926.1. EL ENFOQUE DE SALA LIMPIA, 460 26.1.1. LA ESTRATEGIA DE SALA LIMPIA, 460 26.1.2. QU HACE DIFERENTE LA SALA LIMPIA?, 46126.2. ESPECIFICACIN FUNCIONAL, 462 26.2.1. ESPECIFICACIN DE CAJA NEGRA, 463 26.2.2. ESPECIFICACIN DE CAJA DE ESTADO, 463 26.2.3. ESPECIFICACI~N CAJA LIMPIA, 464DE26.3. REFINAMIENTO Y VERIFICACI~NDEL DISENO, 46426.3.1. REFINAMIENTO Y VERIFICACIN DEL DISENO, 464 26.3.2. VENTAJAS DE LA VERIFICACI~N DEL DISENO, 46626.4. PRUEBA DE SALA LIMPIA, 467 26.4.1. PRUEBA ESTADSTICA DE CASOS PRCTICOS, 467 26.4.2. CERTIFICACI~N,468RESUMEN, 469REFERENCIAS, 469PROBLEMAS Y PUNTOS A CONSIDERAR, 470OTRAS LECTURAS Y FUENTES DE INFORMACI~N, 470CAPTULO INGENIERIA DEL SOFTWARE BASADA EN COMPONENTES, 473 27: DE27.1. INGENIERA SISTEMAS BASADA EN COMPONENTES, 47427.2. EL PROCESO DE ISBC, 47527.3. INGENIERIA DEL DOMINIO, 47627.3.1. EL PROCESO DE ANLISIS DEL DOMINIO, 47627.3.2. FUNCIONES DE CARACTERIZACI~N,477 27.3.3. MODELADO ESTRUCTURAL Y PUNTOS DE ESTRUCTURA, 47727.4. DESARROLLO BASADO EN COMPONENTES, 47827.4. I . CUALIFICACI~N, ADAPTACI~NY COMPOSICI~N COMPONENTES, 479 DE 27.4.2. INGENIERA DE COMPONENTES, 481 27.4.3. ANLISIS Y DISEO PARA LA REUTILIZACI~N,481Y27.5. CLASIFICACI~N RECUPERACI~N COMPONENTES, 482DE 27.5.1. DESCRIPCIN DE COMPONENTES REUTILIZABLES, 482 27.5.2. EL ENTORNO DE REUTILIZACIN, 48427.6. ECONOMIA DE LA ISBC, 484 27.6.1, IMPACTO EN LA CALIDAD, PRODUCTIVIDAD Y COSTE, 484 27.6.2. ANLISIS DE COSTE EMPLEANDO PUNTOS DE ESTRUCTURA, 485 XIX 20. CONTENIDO 27.6.3.MTRICAS DE REUTILIZACIN, 486 RESUMEN, 486 REFERENCIAS, 487 PROBLEMAS Y PUNTOS A CONSIDERAR, 488 OTRAS LECTURAS Y FUENTES DE INFORMACIN, 488CAPITULO 28: INGENIERIA DEL SOFTWARE DEL COMERCIO ELECTRNICO CLIENTE/SERVIDOR, 49128.1. INTRODUCCIN, 49228.2. SISTEMAS DISTRIBUIDOS, 492 28.2.1. CLIENTES Y SERVIDORES, 492 28.2.2.CATEGOR~AS SERVIDORES, 492 DE 28.2.3.SOFIWARE INTERMEDIO (MIDDLEWARE),494 28.2.4.UN EJEMPLO DE SOFIWARE INTERMEDIO, 49528.3. ARQUITECTURAS ESTRATIFICADAS, 49628.4. PROTOCOLOS, 497 28.4.1.ELCONCEPT0,497 28.4.2.IP E ICMP, 498 28.4.3. POP3,498 28.4.4.EL PROTOCOLO HITP, 49928.5. UN SISTEMA DE COMERCIO ELECTR~NICO,499 28.5.1.~ Q U EL COMERCIO ELECTRNICO?, 499 ES 28.5.2. UN SlSTEMATPICO DE COMERCIO ELECTRNICO, 50028.6. TECNOLOGIAS USADAS PARA EL COMERCIO ELECTRNICO, 502 28.6.1.CONEXIONES (SOCKETS),502 28.6.2. OBJETOS DISTRIBUIDOS, 502 28.6.3. ESPACIOS, 503 28.6.4.CGI, 503 28.6.5.CONTENIDO EJECUTABLE, 503 28.6.6.PAQUETES CLIENTE/SERVIDOR, 50428.7. EL DISENO DE SISTEMAS DISTRIBUIDOS, 504 28.7.1.CORRESPONDENCIA DEL VOLUMEN DE TRANSMISIN CON LOS MEDIOS DE TRANS- MISIN, 504 28.7.2.MANTENIMIENTO DE LOS DATOS MS USADOS EN UN ALMACENAMIENTO RPIDO, 504 28.7.3.MANTENIMIENTO DE LOS DATOS CERCA DE DONDE SE UTILIZAN, 504 28.7.4.UTILIZACIN DE LADUPLICACIN DE DATOS TODO LO POSIBLE, 505 28.7.5.ELIMINAR CUELLOS DE BOTELLA, 505 28.7.6.MINIMIZAR LA NECESIDAD DE UN GRAN CONOCIMIENTO DEL SISTEMA, 505 28.7.7.AGRUPAR DATOS AFINES EN LA MISMA UBICACIN, 505 28.7.8.CONSIDERAR LA UTILIZACIN DE SERVIDORES DEDICADOS A FUNCIONES FRECUENTES, 506 28.7.9.CORRESPONDENCIA DE LA TECNOLOGA CON LAS EXIGENCIAS DE RENDIMIENTO, 50628.7.10.EMPLEO DEL PARALELISMO TODO LO POSIBLE, 50628.7.11.UTILIZACIN DE LA COMPRESIN DE DATOS TODO LO POSIBLE, 50628.7.12.DISENO PARA EL FALLO, 50628.7.13.MINIMIZAR LA LATENCIA, 50628.7.14.EPLOGO, 50628.8. INGENIERIA DE SEGURIDAD, 507 28.8.1. ENCRIPTACIN, 507 28.8.2. FUNCIONES DE COMPENDIO DE MENSAJES, 508 28.8.3.FIRMAS DIGITALES, 508 28.8.4.CERTIFICACIONES DIGITALES, 508 xx 21. CONTENIDO 28.9. COMPONENTES DE SOFTWARE PARA SISTEMAS C/S, 509 28.9.1. INTRODUCCI~N, 50928.9.2. DISTRIBUCIN DE COMPONENTES DE SOITWARE, 50928.9.3. LNEAS GENERALES PARA LA DISTRIBUCIN DE COMPONENTES DEAPLICACIONES, 51028.9.4. ENLAZADO DE COMPONENTES DE SOFTWARE C/S, 5 1128.9.5. SOFTWARE INTERMEDIO (MIDDLEWARE) Y ARQUITECTURAS DE AGENTE DE SOLICI-TUD DE OBJETOS, 51228.10. INGENIERA SOFTWARE PARA SISTEMAS C/S, 512DEL28.11. PROBLEMAS DE MODELADO DE ANLISIS, 51228.12. DISENO DE SISTEMAS C/S, 513 28.12.1. DISEO ARQUITECT~NICOPARA SISTEMAS CLIENTEISERVIDOR, 513 28.12.2. ENFOQUES DE DISEO CONVENCIONALES PARA SOFTWARE DE APLICACIONES, 514 28.12.3. DISENO DE BASES DE DATOS, 514 28.12.4. VISIN GENERAL DE UN ENFOQUE DE DISEO, 515 28.12.5. ITERACIN DEL DISEO DE PROCESOS, 51628.13. PROBLEMAS DE LAS PRUEBAS, 516 28.13.1. ESTRATEGIA GENERAL DE PRUEBAS C/S, 516 28.13.2. TCTICADE PRUEBAS C/S, 518RESUMEN, 518REFERENCIAS, 519PROBLEMAS Y PUNTOS A CONSIDERAR, 519OTRAS LECTURAS Y FUENTES DE INFORMACI~N, 519CAPITULO 29: INGENIERIA WEB, 521 29.1. LOS ATRIBUTOS DE APLICACIONES BASADAS EN WEB, 52229.1.1. ATRIBUTOS DE CALIDAD, 52329.1.2. LAS TECNOLOGAS, 524 29.2. EL PROCESO DE IWEB, 525 29.3. UN MARCO DE TRABAJO PARA LA IWEB, 525 29.4. FORMULACI~N ANLISIS DE SISTEMAS BASADOS EN WEB, 526 Y29.4.1. FORMULACIN, 52629.4.2. ANLISIS, 527 29.5. DISENOPARA APLICACIONES BASADAS EN WEB, 52729.5.1. DISENO ARQUITECT~NICO,52829.5.2. DISENO DE NAVEGACI~N,53024.5.3. DISENO DE LA INTERFAZ, 531 29.6. PRUEBAS DE LAS APLICACIONES BASADAS EN WEB, 532 29.7. PROBLEMAS DE G E S T I ~ N533 , 29.7.1. EL EQUIPO DE iWEB, 53329.7.2. GESTIN DEL PROYECTO, 53429.1.3. PROBLEMAS GCS PARA LA IWEB, 536RESUMEN, 537REFERENCIAS, 538PROBLEMAS Y PUNTOS A CONSIDERAR, 539OTRAS LECTURAS Y FUENTES DE INFORMACI~N, 539CAPTULO 30: REINGENIERIA,541 30.1. REINGENIERA PROCESOS DE NEGOCIO, 542 DE30.1.1. PROCESOS DE NEGOCIOS, 54230.1.2. PRINCIPIOS DE REINGENIERA DE PROCESOS DE NEGOCIOS, 542 22. CONTENIDO 30.1.3. UN MODELO DE RPN, 543 30.1.4. ADVERTENCIAS, 54430.2. REINGENIER~ADEL SOFTWARE, 544 30.2.1. MANTENIMIENTO DEL SOFTWARE, 544 30.2.2. UN MODELO DE PROCESOS DE REINGENIERfA DEL SOFTWARE, 54530.3. INGENIER~AINVERSA, 547 30.3.1. INGENIERA INVERSA PARA COMPRENDER EL PROCESAMIENTO, 548 30.3.2. INGENIER~A INVERSA PARA COMPRENDER LOS DATOS, 549 30.3.3. INGENIERA INVERSA DE INTERFACES DE USUARIO, 55055030.4. REESTRUCTURACI~N,30.4.1. REESTRUCTURACI~NDEL CDIGO, 55030.4.2. REESTRUCTURACI~NDE LOS DATOS, 55130.5. INGENIERIA DIRECTA (FORWARD ENGINEERING), 55130.5.1. INGENIERA DIRECTA PARA ARQUITECTURAS CLIENTE/SERVIDOR, 55230.5.2. INGENIERA DIRECTA PARA ARQUITECTURAS ORIENTADAS A OBJETOS, 55330.5.3. INGENIERA DIRECTA PARA INTERFACES DE USUARIO, 553 DE 30.6. LA ECONOM~A LA REINGENIER~A,554RESUMEN, 555REFERENCIAS, 555PROBLEMAS Y PUNTOS A CONSIDERAR, 556OTRAS LECTURAS Y FUENTES DE INFORMACI~N, 556CAP~TULO INGENIERIA DEL SOFTWARE ASISTIDA POR COMPUTADORA, 55931:31.1. ~QU SIGNIFICA CASE?, 56031.2. CONSTRUCCIN DE BLOQUES BSICOS PARA CASE, 56031.3. UNA TAXONOM~A HERRAMIENTAS CASE, 561DE31.4. ENTORNOS CASE INTEGRADOS, 56531.5. LA ARQUITECTURA DE INTEGRACI~N,56631.6. EL REPOSITORIO CASE, 5673 1.6.1. EL PAPEL DEL REPOSITORIO EN 1-CASE, 56731.6.2. CARACTERSTICAS Y CONTENIDOS, 568RESUMEN, 571REFERENCIAS, 571PROBLEMAS Y PUNTOS A CONSIDERAR, 572OTRAS LECTURAS Y FUENTES DE INFORMACIN, 572CAPITULO 32: PERSPECTIVAS FUTURAS. 573 32.1. IMPORTANCIA DEL SOFTWARE S E G U N D A PARTE- 574, 32.2. EL MBITO DEL CAMBIO, 574 32.3. LAS PERSONAS Y LA FORMA EN QUE CONSTRUYEN SISTEMAS, 574 32.4. EL PPara resolver los problemas reales de una industria, un completo, las etapas descritas anteriormente se aplicaningeniero del software o un equipo de ingenieros debe recursivamente a las necesidades del usuario y a la espe-incorporar una estrategia de desarrollo que acompaecificacin tcnica del desarrollador del software.al proceso, mtodos y capas de herramientas descritos*eden la Seccin 2.1.1 y las fases genricas discutidas enla Seccin 2.1.2. Esta estrategia a menudo se llamamodelo de proceso o paradigma de ingeniera del soft-cVEware. Se selecciona un modelo de proceso para la inge-Todas las etapas de un proceso del software - e s t a d oniera del software segn la naturaleza del proyecto yactual, definicin del problema, desarrollo tcnico ede la aplicacin, los mtodos y las herramientas a utili- integracin de la solucin- coexisten simultneamentezarse, y los controles y entregas que se requieren. Enen algn nivel de detalle.un documento intrigante sobre la naturaleza del proce-so del software, L.B.S. Raccoon [RAC95] utiliza frac-En las secciones siguientes, se tratan diferentes mode-tales como base de estudio de la verdadera naturaleza los de procesos para la ingeniera del software. Cadadel proceso del software. una representa un intento de ordenar una actividad inhe-rentemente catica. Es importante recordar que cadauno de los modelos se han caracterizado de forma queayuden (con esperanza) al control y a la coordinacinde un proyecto de software real. Y a pesar de eso, en elfondo, todos los modelos exhiben caractersticas delModelo del Caos. DefinicinTodo el desarrollo del software se puede caracteri- de problemaszar como bucle de resolucin de problemas (Fig. 2.3a)en el que se encuentran cuatro etapas distintas: statusquo, definicin de problemas, desarrollo tcnico e inte- Desarrollogracin de soluciones. Status quo representa el estado tcnicoactual de sucesos [RAC95]; la definicin de proble-mas identifica el problema especfico a resolverse; el tdesarrollo tcnico resuelve el problema a travs de laaplicacin de alguna tecnologa y la integracin de solu-Integracinciones ofrece los resultados (por ejemplo: documentos,de solucionesprogramas, datos, nueva funcin comercial, nuevo pro-ducto) a los que solicitan la solucin en primer lugar.Las fases y los pasos genricos de ingeniera del soft-ware definidos en la Seccin 2.1.2 se divide fcilmen-te en estas etapas. >En realidad, es difcil compartimentar actividades demanera tan ntida como la Figura 2.3.b da a entender,porque existen interferencias entre las etapas. Aunqueesta visin simplificada lleva a una idea muy impor-tante: con independencia del modelo de proceso que seEstadoseleccione para un proyecto de software, todas las eta-actualpas -status quo, definicin de problemas, desarrollotcnico e integracin de soluciones-coexisten simul-tneamente en algn nivel de detalle. Dada la naturale-za recursiva de la Figura 2.3b, las cuatro etapas tratadasanteriormente se aplican igualmente al anlisis de unaaplicacin completa y a la generacin de un pequeosegmento de cdigo.Raccoon [RAC95] sugiere un Modelo del Caosque describe el desarrollodel software como una exten- FIGURA 2.3.a) Las fases de un bucle de resolucin de pro-sin desde el usuario hasta el desarrollador y la tecno- blemas [RAC 951. b) Fases dentro de las fasesloga. Conforme progresa el trabajo hacia un sistemadel bucle de resolucin de problemas [RAC 951. 19 53. INGENIERfA DEL SOFTWARE. UN ENFOQUE PRCTICO 2.4Llamado algunas veces ciclo de vida bsico o cmode-se pueda evaluar su calidad antes de que comience lalo en cascada, el modelo lineal secuencial sugiere un codificacin.enfoque5 sistemtico, secuencial, para el desarrollo delGeneracin de cdigo. El diseo se debe traducirsoftware que comienza en un nivel de sistemas y pro- en una forma legible por la mquina. El paso de gene-gresa con el anlisis, diseo, codificacin, pruebas y man-racin de cdigo lleva a cabo esta tarea. Si se lleva atenimiento. La Figura 2.4 muestra el modelo lineal cabo el diseo de una forma detallada, la generacin desecuencial para la ingeniera del software. Modelado cdigo se realiza mecnicamente.segn el ciclo de ingeniera convencional, el modelolineal secuencial comprende las siguientes actividades: Ingeniera y modelado de Sistemas/Informacin.Como el software siempre forma parte de un sistema Aunque el modelo lineal es a menudo denominadoms grande (o empresa), el trabajo comienza estable- modelo tradicional, resulto un enfoque razonableciendo requisitos de todos los elementos del sistema y cuando los requisitos se han entendido correctomente.asignando al software algn subgrupo de estos requisi-tos. Esta visin del sistema es esencial cuando el soft- Pruebas. Una vez que se ha generado el cdigo,ware se debe interconectar con otros elementos comocomienzan las pruebas del programa. El proceso de prue-hardware, personas y bases de datos. La ingeniera y elbas se centra en los procesos lgicos internos del soft-anlisis de sistemas comprende los requisitos que se ware, asegurando que todas las sentencias se hanrecogen en el nivel del sistema con una pequea partecomprobado, y en los procesos externos funcionales; esde anlisis y de diseo. La ingeniera de informacindecir, realizar las pruebas para la deteccin de erroresabarca los requisitos que se recogen en el nivel dey asegurar que la entrada definida produce resultadosempresa estratgico y en el nivel del rea de negocio. reales de acuerdo con los resultados requeridos. Mantenimiento. El software indudablemente sufrir cambios despus de ser entregado al cliente (una excep- cin posible es el software empotrado). Se producirn cambios porque se han encontrado errores, porque el soft- ware debe adaptarse para acoplarse a los cambios de su entorno externo (por ejemplo: se requiere un cambio debi- do a un sistema operativo o dispositivo perifrico nue- vo), o porque el cliente requiere mejoras funcionales o de rendimiento. El soporte y mantenimiento del softwa- re vuelve a aplicar cada una de las fases precedentes a un programa ya existente y no a uno nuevo.FIGURA 2.4. El modelo lineal secuencial.El modelo lineal secuencial es el paradigma ms anti- guo y ms extensamente utilizado en la ingeniera delAnlisis de los requisitos del software. El procesosoftware. Sin embargo, la crtica del paradigma ha pues-de reunin de requisitos se intensifica y se centra espe-to en duda su eficacia [HAN95]. Entre los problemascialmente en el software. Para comprender la naturalezaque se encuentran algunas veces en el modelo linealdel (los) programa(s) a construirse, el ingeniero (aria-secuencial se incluyen:lista) del software debe comprender el dominio deinformacin del software (descrito en el Captulo 1l), as Por qu falla algunas vecescomo la funcin requerida, comportamiento,rendimien- el modelo lineal?to e interconexin. Diseo. El diseo del software es realmente un pro-ceso de muchos pasos que se centra en cuatro atributos 1. Los proyectos reales raras veces siguen el modelodistintos de programa: estructura de datos, arquitectu- secuencial que propone el modelo. Aunque el modelora de software, representaciones de interfaz y detallelineal puede acoplar interaccin, lo hace indirecta-procedimental (algoritmo). El proceso del diseo tra- mente. Como resultado, los cambios pueden causarduce requisitos en una representacin del software dondeconfusin cuando el equipo del proyecto comienza.Aunque el modelo original en cascada propuesto por Winston Royce[ROY70] haca provisiones para ((buclesde realimentacin)b, la granmayora d e las organizaciones que aplican este modelo de procesolo hacen como si fuera estrictamente lineal.20 54. CAPfTULO 2 EL PROCESO A menudo es difcil que el cliente exponga explci-Cada uno de estos errores es real. Sin embargo, el tamente todos los requisitos. El modelo lineal secuen-paradigma del ciclo de vida clsico tiene un lugar defi- cial lo requiere y tiene dificultades a la hora denido e importante en el trabajo de la ingeniera del soft- acomodar la incertidumbre natural al comienzo deware. Proporciona una plantilla en la que se encuentran muchos proyectos. mtodos para anlisis, diseo, codificacin, pruebas y El cliente debe tener paciencia. Una versin de tra-mantenimiento. El ciclo de vida clsico sigue siendo el bajo del (los) programa(s) no estar disponible hasta modelo de proceso ms extensamente utilizado por la que el proyecto est muy avanzado. Un grave error ingeniera del software. Pese a tener debilidades, es sig- puede ser desastroso si no se detecta hasta que senificativamente mejor que un enfoque hecho al azar para revisa el programa. el desarrollo del software.Un cliente, a menudo, define un conjunto de objetivosgenerales para el software, pero no identifica los requi-sitos detallados de entrada, proceso o salida. En otros EscucharConstruir/revisarcasos, el responsable del desarrollo del software puede al clienteno estar seguro de la eficacia de un algoritmo, de la capa-cidad de adaptacin de un sistema operativo, o de la for-ma en que debera tomarse la interaccin hombre-mquina. En estas y en otras muchas situaciones, unparadigma de construccin de prototipos puede ofre-cer el mejor enfoque. El paradigma de construccin de prototipos (Fig.El clienteprueba2.5) comienza con la recoleccin de requisitos. El desa-la maquetarrollador y el cliente encuentran y definen los objeti-vos globales para el software, identifican los requisitosconocidos y las reas del esquema en donde es obli-v4 FIGURA 2.5. El paradigma de construccin de prototipos.gatoria ms definicin. Entonces aparece un diseorpido. El diseo rpido se centra en una representa-cin de esos aspectos del software que sern visibles Pero qu hacemos con el prototipo una vez que hapara el usuario/cliente (por ejemplo: enfoques de entra- servido para el propsito descrito anteriormente? Brooksda y formatos de salida). El diseo rpido lleva a la[BR075] proporciona una respuesta:construccin de un prototipo. El prototipo lo evala elcliente/usuario y se utiliza para refinar los requisitos En la mayora de los proyectos, el primer sistema construidodel software a desarrollar. La iteracin ocurre cuando apenas se puede utilizar. Puede ser demasiado lento, demasiadoel prototipo se pone a punto para satisfacer las nece- grande o torpe en su uso, o las tres a la vez. No hay otra alterna- tiva que comenzar de nuevo, aunque nos duela pero es ms inte-sidades del cliente, permitiendo al mismo tiempo que ligente, y construir una versin rediseada en la que se resuelvanel desarrollador comprenda mejor lo que se necesitaestos problemas ... Cuando se utiliza un concepto nuevo de siste-hacer. ma o una tecnologa nueva, se tiene que construir un sistema que no sirva y se tenga que tirar, porque incluso la mejor planificacin no es omnisciente como para que est perfecta la primera vez. Por lo tanto la pregunta de la gestin no es si construir un sistema pilo- to y tirarlo. Tendremos que hacerlo. La nica pregunta es si pla-Cuando el cliente tiene uno necesidad legfimo,nificar de antemano construir un desechable, o prometerpero esf desorientado sobre los defulles, entregrselo a los clientes...el primer poso es desarrollar un prototipo. El prototipo puede servir como primer sistema. El que Brooks recomienda tirar. Aunque esta puede ser Lo ideal sera que el prototipo sirviera como un meca-una visin idealizada. Es verdad que a los clientes y anismo para identificar los requisitos del software. Si selos que desarrollan les gusta el paradigma de cons-construye un prototipo de trabajo, el desarrollador inten- truccin de prototipos. A los usuarios les gusta el sis-ta hacer uso de los fragmentos del programa ya exis- tema real y a los que desarrollan les gusta construir algotentes o aplica herramientas (por ejemplo: generadores inmediatamente. Sin embargo, la construccin de pro-de informes, gestores de ventanas, etc.) que permitentotipos tambin puede ser problemtica por las siguien-generar rpidamente programas de trabajo.tes razones:21 55. INGENIERfA DEL SOFTWARE. U N E N F O Q U E PRCTICO1. El cliente ve lo que parece ser una versin de trabajo para demostrar la capacidad. Despus de algn del software, sin tener conocimiento de que el pro-tiempo, el desarrollador debe familiarizarse con estas totipo tambin est junto con el chicle y el cable de selecciones, y olvidarse de las razones por las que embalar, sin saber que con la prisa de hacer queson inadecuadas. La seleccin menos ideal ahora es funcione no se ha tenido en cuenta la calidad del soft-una parte integral del sistema. ware global o la facilidad de mantenimiento a largo plazo. Cuando se informa de que el producto se debe construir otra vez para que se puedan mantener los niveles altos de calidad, el cliente no lo entiende y Resisto lo presin de ofrecer un rnol prototipo en el pide que se apliquen a n o s pequeos ajustes>> para producto finol. Corno resultado, lo colidod se resiente casi que se pueda hacer del prototipo un producto final.siempre. De forma demasiado frecuente la gestin de desa- rrollo del software es muy lenta.Aunque pueden surgir problemas, la construccin de2. El desarrollador, a menudo, hace compromisos de prototipos puede ser un paradigma efectivo para la inge- implementacin para hacer que el prototipo funcione niera del software. La clave es definir las reglas del jue- rpidamente. Se puede utilizar un sistema operativo go al comienzo; es decir, el cliente y el desarrollador se o lenguaje de programacin inadecuado simplemente deben poner de acuerdo en que el prototipo se constru- porque est disponible y porque es conocido; un algo- ya para servir como un mecanismo de definicin de ritmo eficiente se puede implementar simplementerequisitos.El Desarrollo Rpido de Aplicaciones (DRA) un mode- esGeneracin de aplicaciones. El DRA asume la uti-lo de proceso del desarrollo del software lineal secuenciallizacin de tcnicas de cuarta generacin (Seccin 2.10).que enfatiza un ciclo de desarrollo extremadamente cor-En lugar de crear software con lenguajes de programa-to. El modelo DRA es una adaptacin a alta velocidad cin de tercera generacin, el proceso DRA trabaja paradel modelo lineal secuencial en el que se logra el desa- volver a utilizar componentes de programas ya exis-rrollo rpido utilizando una construccin basada en com- tentes (cuando es posible) o a crear componentes reuti-ponentes. Si se comprenden bien los requisitos y se limita lizables (cuando sea necesario). En todos los casos seel mbito del proyecto, el proceso DRA permite al equi-utilizan herramientas para facilitar la construccin delpo de desarrollo crear un sistema completamente fun-software.cional dentro de perodos cortos de tiempo (por ejemplo:de 60 a 90 das) [MAR91]. Cuando se utiliza principal-mente para aplicaciones de sistemas de informacin, elEquipo no 3enfoque DRA comprende las siguientes fases [KER94]: ModeladoModelado de Gestin. El flujo de informacin entre Equipo no 1 degestinlas funciones de gestin se modela de forma que res-ponda a las siguientes preguntas: Qu informacin con- Modelado Modeladoduce el proceso de gestin? Qu informacin se genera? de gestinde datosQuin la genera? A dnde va la informacin? Quinla procesa? El modelado de gestin se describe con msModelado de procesosdetalle en el Captulo 10. Modeladode datosModelado de datos. El flujo de informacin defini- Generacin 1dedo como parte de la fase de modelado de gestin se refi- aplicacionesna como un conjunto de objetos de datos necesarios paraModelado-7apoyar la empresa. Se definen las caractersticas (lla- de procesosmadas atributos) de cada uno de los objetos y las rela-ciones entre estos objetos. El modelado de datos se trata Generacinen el Captulo 12.Modelado del proceso. Los objetos de datos defi-nidos en la fase de modelado de datos quedan transfor-mados para lograr el flujo de informacin necesario paraPruebasimplementar una funcin de gestin. Las descripcionesy entregadel proceso se crean para aadir, modificar, suprimir, orecuperar un objeto de datos. b96-0-0dd-sa En ingles: RAD (Rapid Application Deveiopment)El FIGURA 2.6. modelo DRA.22 56. CAPfTULO 2 EL PROCESO Pruebas y entrega. Como el proceso DRA enfati-Al igual que todos los modelos de proceso, el enfo-za la reutilizacin, ya se han comprobado muchos deque DRA tiene inconvenientes [BUT94]:los componentes de los programas. Esto reduce tiempo Para proyectos grandes aunque por escalas, el D R Ade pruebas. Sin embargo, se deben probar todos los com-requiere recursos humanos suficientes como paraponentes nuevos y se deben ejercitar todas las interfa-crear el nmero correcto de equipos DRA.ces a fondo. D R A requiere clientes y desarrolladores compro- metidos en las rpidas actividades necesarias para completar un sistema en un marco de tiempo abre-EDRA hace un fuerte uso de tomponentes l viado. Si no hay compromiso por ninguna de las par-reutilizobles. Paro mayor informotin sobre el tes constituyentes, los proyectos DRA fracasarn.desanollo de componentes, vase el Captulo 27. No todos los tipos de aplicaciones son apropiados para DRA. Si un sistema no se puede modularizaradecuadamente, la construccin de los componentesEl modelo de proceso DRA se ilustra en la Figuranecesarios para DRA ser problemtico. S est eni2.6. Obviamente, las limitaciones de tiempo impuestas juego el alto rendimiento, y se va a conseguir el ren-en un proyecto DRA demandan mbito en escalasdimiento convirtiendo interfaces en componentes de[KER94]. Si una aplicacin de gestin puede modular-sistemas, el enfoque DRA puede que no funcione.se de forma que permita completarse cada una de lasfunciones principales en menos de tres meses (utilizandoDRA no es adecuado cuando los riesgos tcnicos sonel enfoque descrito anteriormente), es un candidato del altos. Esto ocurre cuando una nueva aplicacin haceDRA. Cada una de las funciones pueden ser afrontadasuso de tecnologas nuevas, o cuando el softwarepor un equipo DRA separado y ser integradas en un solonuevo requiere un alto grado de interoperatividadconjunto. con programas de computadora ya existentes.PROC- SOFTWWSe reconoce que el software, al igual que todos los sis- 2.7.1. El modelo incrementaltemas complejos, evoluciona con el tiempo [GIL88]. El modelo incrernental combina elementos del modeloLos requisitos de gestin y de productos a menudo cam- lineal secuencial (aplicados repetidamente) con la filo-bian conforme a que el desarrollo proceda haciendo que sofa interactiva de construccin de prototipos. Comoel camino que lleva al producto final no sea real; las muestra la Figura 2.7, el modelo incremental aplicaestrictas fechas tope del mercado hacen que sea impo-secuencias lineales de forma escalonada mientras pro-sible finalizar un producto completo, por lo que se debe gresa el tiempo en el calendario. Cada secuencia linealintroducir una versin limitada para cumplir la presinproduce un incremento del software [MDE93]. Porcompetitiva y de gestin; se comprende perfectamente ejemplo, el software de tratamiento de textos desarro-el conjunto de requisitos de productos centrales o del llado con el paradigma incremental podra extraer fun-sistema, pero todava se tienen que definir los detalles ciones de gestin de archivos bsicos y de produccinde extensiones del producto o sistema. En estas y en de documentos en el primer incremento; funciones deotras situaciones similares, los ingenieros del software edicin ms sofisticadas y de produccin de documen-necesitan un modelo de proceso que se ha diseadotos en el segundo incremento; correccin ortogrfica yexplcitamente para acomodarse a un producto que evo-gramatical en el tercero; y una funcin avanzada delucione con el tiempo. esquema de pgina en el cuarto. Se debera tener en cuen- El modelo lineal secuencial (Seccin 2.4) se disea ta que el flujo del proceso de cualquier incremento pue-para el desarrollo en lnea recta. En esencia, este enfo-de incorporar el paradigma de construccin de prototipos.que en cascada asume que se va entregar un sistemacompleto una vez que la secuencia lineal se haya fina-lizado. El modelo de construccin de prototipos (Sec-cin 2.5) se disea para ayudar al cliente (o al que % CLAVEdesarrolla) a comprender los requisitos. En general, noEmodelo incremento1entrega el software en parteslse disea para entregar un sistema de produccin. En pequenos, pero utilizables, llamadas ((incrementos).ninguno de los paradigmas de ingeniera del software En general, cado incremento se construye sobre aqulse tiene en cuenta la naturaleza evolutiva del software. que ya ho sido entregado.Los modelos evolutivos son iterativos. Se caracteri-zan por la forma en que permiten a los ingenieros del Cuando se utiliza un modelo incremental, el primersoftware desarrollar versiones cada vez ms completasincremento a menudo es un producto esencial. Es decir,del software.se afrontan requisitos bsicos, pero muchas funciones23 57. INGENIERfA DEL SOFTWARE. UN ENFOQUE PRACTICOsuplementarias (algunas conocidas, otras no) quedan sin El modelo de proceso incremental, como la cons-extraer. El cliente utiliza el producto central (o sufre latruccin de prototipos (Seccin 2.5) y otros enfoquesrevisin detallada). Como un resultado de utilizacin y/oevolutivos, es iterativo por naturaleza. Pero a dife-de evaluacin, se desarrolla un plan para el incrementorencia de la construccin de prototipos, el modelosiguiente. El plan afronta la modificacin del productoincremental se centra en la entrega de un productocentral a fin de cumplir mejor las necesidades del clien-operacional con cada incremento. Los primeros incre-te y la entrega de funciones, y caractersticas adiciona-mentos son versiones incompletas del productoles. Este proceso se repite siguiendo la entrega de cada final, pero proporcionan al usuario la funcionalidadincremento, hasta que se elabore el producto completo. que precisa y tambin una plataforma para la eva- luacin.El desarrollo incremental es particularmente til cuando la dotacin de personal no est disponible paraCuando tenga una fecha de entrega imposibleuna implementacin completa en la fecha lmite que sede cambiar, el modela incremental es un buen haya establecido para el proyecto. Los primeros incre-parodigma a considerar. mentos se pueden implementar con menos personas.incremento 1 Sistemas/informacin PruebaEntrega del l.er incremento , Cdigo + PruebaEntrega del2." incrementoDiseo + Cdigo incremento 4 Anlisis Prueba Entrega del4." incremento Tiempo de calendarioFIGURA 2.7. El modelo incremental.2.7.2. El modelo espiralEl modelo en espiral, propuesto originalmente porBoehm [BOE88], es un modelo de proceso de soft-ware evolutivo que conjuga la naturaleza iterativa deconstruccin de prototipos con los aspectos controla-nieriados y sistemticos del modelo lineal secuencial. Pro-porciona el potencial para el desarrollo rpido de del clienteversiones incrementales del software. En el modeloespiral, el software se desarrolla en una serie de ver-0Proyecto de mantenimiento de productos.siones incrementales. Durante las primeras iteraccio-0Proyecto de mejora de productos. Proyecto de desarrollo de nuevos productos.nes, la version incremental podra ser un modelo enProyecto de desarrollo de conceptos.papel o un prototipo. Durante las ltimas iteraciones,se producen versiones cada vez ms completas del sis-tema diseado. FIGURA 2.8. Un modelo espiral tpico.24 58. CAPfTULO 2 EL PROCESOEl modelo en espiral se divide en un nmero de acti- ms sofisticadas del software. Cada paso por la reginvidades de marco de trabajo, tambin llamadas regio- de planificacin produce ajustes en el plan del proyec-rzes de tareas6.Generalmente, existen entre tres y seisto. El coste y la planificacin se ajustan con la reali-regiones de tareas. La Figura 2.8 representa un modelo mentacion ante la evaluacin del cliente. Adems, elen espiral que contiene seis regiones de tareas: gestor del proyecto ajusta el nmero planificado de ite-comunicacin con el cliente- las tareas requeridas raciones requeridas para completar el software.para establecer comunicacin entre el desarrolladory el cliente.planificacin- las tareas requeridas para definirrecursos, el tiempo y otra informacin relacionadascon el proyecto.anlisis de riesgos- las tareas requeridas para eva-Modelo de proceso adaptable.luar riesgos tcnicos y de gestin.ingeniera- las tareas requeridas para construir una A diferencia del modelo de proceso clsico que ter-o ms representaciones de la aplicacin. mina cuando se entrega el software, el modelo en espi-construccin y accin- las tareas requeridas pararal puede adaptarse y aplicarse a lo largo de la vida delconstruir, probar, instalar y proporcionar soporte alsoftware de computadora. Una visin alternativa delusuario (por ejemplo: documentacin y prctica)modelo en espiral puede ser considerada examinando el eje de punto de entrada en el proyecto tambin refle-evaluacin del cliente- las tareas requeridas para jado en la Figura 2.8. Cada uno de los cubos situados aobtener la reaccin del cliente segn la evaluacinlo largo del eje pueden usarse para representar el pun-de las representaciones del software creadas durante to de arranque para diferentes tipos de proyectos. Unla etapa de ingeniera e implementada durante la proyecto de desarrollo de conceptos comienza en eletapa de instalacin.centro de la espiral y continuar (aparecen mltiples ite- a$$ raciones a lo largo de la espiral que limita la regin som- breada central) hasta que se completa el desarrollo del CLAVE concepto. Si el concepto se va a desarrollar dentro deLas actividades del marco de trabajo se aplicanun producto real, el proceso contina a travs del cubo a cualquier proyecto de software que realice, siguiente (punto de entrada del proyecto de desarrollo sin tener en cuenta el tamao ni la complejidad.del producto nuevo) y se inicia un nuevo proyecto de desarrollo. El producto nuevo evolucionar a travs de Cada una de las regiones estn compuestas por un con- iteraciones alrededor de la espiral siguiendo el caminojunto de tareas del trabajo, llamado conjunto de tareas, que limita la regin algo ms brillante que el centro.Enque se adaptan a las caractersticas del proyecto que va esencia, la espiral, cuando se caracteriza de esta forma,a emprenderse. Para proyectos pequeos, el nmero de permanece operativa hasta que el software se retira. Haytareas de trabajo y su formalidad es bajo. Para proyectosveces en que el proceso est inactivo, pero siempre quemayores y ms crticos cada regin de tareas contienese inicie un cambio, el proceso arranca en el punto detareas de trabajo que se definen para lograr un nivel msentrada adecuado (por ejemplo: mejora del producto).alto de formalidad. Enitodos los casos, se aplican las acti- El modelo en espiral es un enfoque realista del desa-vidades de proteccin (por ejemplo: gestin de configu-rrollo de sistemas y de software a gran escala. Como elracin del software y garanta de calidad del software)software evoluciona, a medida que progresa el procesomencionadas en la Seccin 2.2. el desarrollador y el cliente comprenden y reaccionan mejor ante riesgos en cada uno de los niveles evoluti- Qu es un conjunto de vos. El modelo en espiral utiliza la construccin de pro- tareas? totipos como mecanismo de reduccin de riesgos, pero,Cuando empieza este proceso evolutivo, el equipo lo que es ms importante, permite a quien lo desarrollade ingeniera del software gira alrededor de la espiralaplicar el enfoque de construccin de prototipos en cual-en la direccin de las agujas del reloj, comenzando porquier etapa de evolucin del producto. Mantiene el enfo-el centro. El primer circuito de la espiral puede produ- que sistemtico de los pasos sugeridos por el ciclo decir el desarrollo de una especificacin de productos; losvida clsico, pero lo incorpora al marco de trabajo ite-pasos siguientes en la espiral se podran utilizar pararativo que refleja de forma ms realista el mundo real.desarrollar un prototipo y progresivamente versiones El modelo en espiral demanda una consideracin direc- El modelo en espiral de esta seccin es una variante sobre el modelopropuesto por Boehm. Para ms informacin sobre el modelo en espi-ral original, consulte [BOE88]. Un tratado ms reciente del modeloen espiral puede encontrarse en [BOE98].25 59. INGENIERfA DEL SOFTWARE. UN ENFOQUE PRACTICOta de los riesgos tcnicos en todas las etapas del pro-El modelo en espiral WINWIN de Boehm [BOE98]yecto, y, si se aplica adecuadamente, debe reducir losdefine un conjunto de actividades de negociacin al prin-riesgos antes de que se conviertan en problemticos.cipio de cada paso alrededor de la espiral. Ms que unasimple actividad de comunicacin con el cliente, se defi-nen las siguientes actividades:1. Identificacin del sistema o subsistemas clave de los directivos8.la Parte cuarto.2. Determinacin de las condiciones de victoria de los directivos. Pero al igual que otros paradigmas, el modelo en 3. Negociacin de las condiciones de victoria de losespiral no es la panacea. Puede resultar difcil conven- directivos para reunirlas en un conjunto de condi-cer a grandes clientes (particularmente en situaciones ciones victoria-victoria para todos los afectadosbajo contrato) de que el enfoque evolutivo es controla-(incluyendo el equipo del proyecto de software).ble. Requiere una considerable habilidad para la eva-luacin del riesgo, y cuenta con esta habilidad para elxito. Si un riesgo importante no es descubierto y ges-tionado, indudablemente surgirn problemas. Final-mente, el modelo no se ha utilizado tanto como losparadigmas lineales secuenciales o de construccin de Habilidades de negociacinprototipos. Todava tendrn que pasar muchos aos antesde que se determine con absoluta certeza la eficacia deeste nuevo e importante paradigma. Conseguidos completamente estos pasos iniciales selogra un resultado victoria-victoria, que ser el crite-rio clave para continuar con la definicin del sistema y2.7.3. El modelo espiral WINWIN del software. El modelo en espiral WINWIN se ilustra (Victoria&Victoria)en la Figura 2.9.El modelo en espiral tratado en la Seccion 2.7.2 sugie-re una actividad del marco de trabajo que aborda la2. Identificar las condiciones 3a. Reunir las condicionescomunicacin con el cliente. El objetivo de esta activi- de victoria de victoria.dad es mostrar los requisitos del cliente. En un contex-to ideal, el desarrollador simplemente pregunta al clientelo que se necesita y el cliente proporciona detalles sufi-cientes para continuar. Desgraciadamente, esto rara-mente ocurre. En realidad el cliente y el desarrolladorentran en un proceso de negociacin, donde el clientepuede ser preguntado para sopesar la funcionalidad,ren- y comentarios.~ 5. Definir el siguiente niveldimiento, y otros productos o caractersticas del siste- 6. Validar lasdel producto y del proceso,ma frente al coste y al tiempo de comercializacin.definicionesincluyendo particiones. del producto y del proceso.FIGURA 2.9. El modelo en espiral WINWIN IBOE981.l a obtencin de requisitos del software requiere unanegociacin. Tiene xito cuando ambas partes ganan.Adems del nfasis realizado en la negociacin ini-cial, el modelo en espiral WINWIN introduce tres hitos Las mejores negociaciones se esfuerzan en obtener en el proceso, llamados puntos de fijacin [BOE96],victoria-victoria. Esto es, el cliente gana obteniendoque ayudan a establecer la completitud de un ciclo alre-el producto o sistema que satisface la mayor parte de dedor de la espiral y proporcionan hitos de decisinsus necesidadesy el desarrollador gana trabajando paraantes de continuar el proyecto de software.conseguir presupuestos y lograr una fecha de entrega En esencia, los puntos de fijacin representan tresrealista. visiones diferentes del progreso mientras que el pro-Hay docenas de libros escritos sobre habilidades en la negocia- Un directivo e s alguien e n la organizacin que tiene un interscin [p. ej., [FiC91], [DON96], [FAR97]].Es una de las cosas masdirecto, por el negocio, en el sistema o producto a construir y puedeimportantes que un ingeniero o gestor joven (o viejo) puede apren-ser premiado por un resultado con xito o criticado si el esfuerzoder. Lea uno. falla. 26 60. CAPfTULO 2EL PROCESOyecto recorre la espiral. El primer punto de fijacin, des del usuario, las decisiones de la gestin y los resultados dellamado objetivos del ciclo de vida (OCV), define un las revisiones.conjunto de objetivos para cada actividad principalEl modelo de proceso concurrente se puede repre-de ingeniera del software. Como ejemplo, de una par-sentar en forma de esquema como una serie de acti-te de OCV, un conjunto de objetivos asociados a la vidades tcnicas importantes, tareas y estadosdefinicin de los requisitos del producto/sistema delasociados a ellas. Por ejemplo, la actividad de inge-nivel ms alto. El segundo punto de fijacin, llama- niera definida para el modelo en espiral (Seccindo arquitectura del ciclo de vida (ACV), establece los 2.7.2), se lleva a cabo invocando las tareas siguien-objetivos que se deben conocer mientras que se defi- tes: modelado de construccin de prototipos y/o an-ne la arquitectura del software y el sistema. Como lisis, especificacin de requisitos y diseo.ejemplo, de una parte de la ACV, el equipo del pro-La Figura 2.10 proporciona una representacin esque-yecto de software debe demostrar que ha evaluado lamtica de una actividad dentro del modelo de procesofuncionalidad de los componentes del software reuti- concurrente. La actividad -anlisis-se puede encon-lizables y que ha considerado su impacto en las deci-trar en uno de los estados" destacados anteriormente ensiones de arquitectura. La capacidad operativa inicial cualquier momento dado. De forma similar, otras acti-(COI) es el tercer punto de fijacin y representa un vidades (por ejemplo: diseo o comunicacin con elconjunto de objetivos asociados a la preparacin del cliente) se puede representar de una forma anloga.software para la instalacin/distribucin,preparacinTodas las actividades existen concurrentemente, perodel lugar previamente a la instalacin, y la asistencia residen en estados diferentes. Por ejemplo, al principioprecisada de todas las partes que utilizar o manten- del proyecto la actividad de comunicacin con el clien-dr el software. te (no mostrada en la figura) ha finalizado su primera2.7.4. El modelo de desarrollo concurrente iteracin y est en el estado de cambios,en espera. La actividad de anlisis (que estaba en el estado ningunoDavis y Sitaram [DAV94] han descrito el modelo demientras que se iniciaba la comunicacin inicial con eldesarrollo concurrente, llamado algunas veces inge-cliente) ahora hace una transicin al estado bajo desa-niera concurrente, de la forma siguiente: rrollo. Sin embargo, si el cliente indica que se deben Los gestores de proyectos que siguen los pasos del estado hacer cambios en requisitos, la actividad anlisis cam-del proyecto en lo que se refiere a las fases importantes [del bia del estado bajo desarrollo al estado cambios enciclo de vida clsico] no tienen idea del estado de sus proyec-tos. Estos son ejemplos de un intento por seguir los pasos extre-espera.madamente complejos de actividades mediante modelosEl modelo de proceso concurrente define una seriedemasiado simples. Tenga en cuenta que aunque un proyectode acontecimientos que dispararn transiciones de[grande] est en la fase de codificacin, hay personal de ese pro- estado a estado para cada una de las actividades de layecto implicado en actividades asociadas generalmente a muchasfases de desarrollo simultneamente. Por ejemplo, ... El perso- ingeniera del software. Por ejemplo, durante las pri-nal est escribiendo requisitos, diseando, codificando, hacien- meras etapas del diseo, no se contempla una incon-do pruebas y probando la integracin [todo al mismo tiempo]. sistencia del modelo de anlisis. Esto genera laLos modelos de procesos de ingeniera del software de Humph- correccin del modelo de anlisis de sucesos, que dis-rey y Kellner [HUM89, KEL891 han mostrado la concurrenciaparar la actividad de anlisis del estado hecho alque existe para actividades que ocurren durante cualquier fase.estado cambios en espera.El trabajo ms reciente de Kellner [KEL91] utiliza diagramasde estado [una notacin que representa los estados de un pro-El modelo de proceso concurrente se utiliza a menu-ceso] para representar la relacin concurrente que existe entredo como el paradigma de desarrollo de aplicaciones clien-actividades asociadas a un acontecimiento especfico (por ejem-te/servidor" (Captulo 28). Un sistema cliente/servidorplo: un cambio de requisitos durante el ltimo desarrollo), pero se compone de un conjunto de componentes funciona-falla en capturar la riqueza de la concurrencia que existe en todasles. Cuando se aplica a cliente/servidor,el modelo de pro-las actividades de desarrollo y de gestin del software en unproyecto. .. La mayora de los modelos de procesos de desarro- ceso concurrente define actividades en dos dimensionesllo del software son dirigidos por el tiempo; cuanto ms tarde [SHE94]: una dimensin de sistemas y una dimensin desea, ms atrs se encontrar en el proceso de desarrollo. [Uncomponentes. Los aspectos del nivel de sistemas se afron-modelo de proceso concurrente] est dirigido por las necesida- tan mediante tres actividades: diseo, ensamblaje y uso.9 Se debera destacar que el anlisis JI el diseo son tareas comple-l 1 En apiicaciones cliente/servidor, la funcionalidad del Software sejas que requieren un estudio sustancial. LX Partes III y IV del librodivide entre clientes (normalmente P W Y un servidor (una compu-consideran estos temas con ms detalle.tadora ms potente) que generalmente mantiene una base de datos centralizada.l o U estado es algn modo externamente observable del compor- ntamiento.27 61. INGENIERfA DEL SOFTWARE. UN ENFOQUE PR A CTICOLa dimensin de componentes se afronta con dos activi-dades: diseo y realizacin. La concurrencia se logra dedos formas: (1) las actividades de sistemas y de compo-nentes ocurren simultneamente y pueden modelarse conel enfoque orientado a objetos descrito anteriormente; (2)una aplicacin cliente/servidor tpica se implementa conmuchos componentes, cada uno de los cuales se puedendisear y realizar concurrentemente. En realidad, el mode-lo de proceso concurrente es aplicable a todo tipo de desa- OReperesenia un estado derrollo de software y proporciona una imagen exacta deluna actividad de ingenieriadel software.estado actual de un proyecto. FIGURA 2.10. Un elemento del modelo de proceso concurrente.Las tecnologas de objetos (4.g Parte de este libro) pro-La actividad de la ingeniera comienza con la iden-porcionan el marco de trabajo tcnico para un modelo tificacin de clases candidatas. Esto se lleva a cabo exa-de proceso basado en componentes para la ingenieraminando los datos que se van a manejar por parte de ladel software. El paradigma orientado a objetos enfati- aplicacin y el algoritmo que se va a aplicar para con-za la creacin de clases que encapsulan tanto los datosseguir el tratamientoI2.Los datos y los algoritmos corres-como los algoritmos que se utilizan para manejar los pondientes se empaquetan en una clase.datos. Si se disean y se implementan adecuadamente, Las clases creadas en los proyectos de ingeniera dellas clases orientadas a objetos son reutilizables por lassoftware anteriores, se almacenan en una biblioteca dediferentes aplicaciones y arquitecturas de sistemas basa-clases o diccionario de datos (repository) (Captulo 3 1).dos en computadora.Una vez identificadas las clases candidatas, la biblioteca de clases se examina para determinar si estas clases ya existen. En caso de que as fuera, se extraen de la biblio- teca y se vuelven a utilizar. Si una clase candidata no resi- de en la biblioteca, se aplican los mtobos orientados B objetos (Captulos 2 1-23). Se compone as la primera ite- racin de la aplicacin a construirse, mediante las clases extradas de la biblioteca y las clases nuevas construidas para cumplir las necesidades nicas de la aplicacin. El flujo del proceso vuelve a la espiral y volver a introdu- cir por ltimo la iteracin ensambladora de componen- tes a travs de la actividad de ingeniera. El modelo de desarrollo basado en componentes con-FIGURA 2.1 1. Desarrollo basado en componentes.duce a la reutilizacin del software, y la reutilizacin pro- porciona beneficios a los ingenieros de software. SegnEl modelo de desarrollo basado en componentes (Fig.estudios de reutilizacin, QSM Associates, Inc. informa2.11) incorpora muchas de las caractersticas del mode-que el ensamblaje de componentes lleva a una reduccinlo en espiral. Es evolutivo por naturaleza [NIE92], y exi- del 70 por 100 de tiempo de ciclo de desarrollo, un 84ge un enfoque iterativo para la creacin del software. por 100 del coste del proyecto y un ndice de producti-Sin embargo, el modelo de desarrollo basado en com-vidad del 26.2, comparado con la norma de industria delponentes configura aplicaciones desde componentes pre- 16.9 [YOU94]. Aunque estos resultados estn en funcinparados de software (llamados clases en la Fig. 2.11). de la robustez de la biblioteca de componentes, no hay duda de que el ensamblaje de componentes proporcionatroto en lo Porteventajas significativas para los ingenieros de software. El proceso unificado de desarrollo de software esento un estudio ms detallado [JAC99] representa un nmero de modelos de desarro- llo basados en componentes que han sido propuestos en Esta es una descripcin simplificada de definicin de clase. Para un estudio ms detallado, consulte el Captulo 20.28 62. CApfTULO 2 EL PROCESOla industria. Utilizando el Lenguaje de Modelado Uni- to de vista de1 usuario). Entonces acopla la funcin conjcado (UML), el proceso unificado define los compo- un marco de trabajo arquitectnico que identifica la for-nentes que se utilizarn para construir el sistema y lasma que tomar el software.interfaces que conectarn los componentes. Utilizandouna combinacion del desarrollo incremental e iterativo,el proceso unificado define la funcin del sistema apli- En los Captulos 21 y 22 se trata UMl con ms detalle.cando un enfoque basado en escenarios (desde el pun-El modelo de mtodos formales comprende un conjun-consiguiente permiten que el ingeniero del software des-to de actividades que conducen a la especificacin mate-cubra y corrija errores que no se pudieron detectar demtica del software de computadora. Los mtodos otra manera.formales permiten que un ingeniero de software espe- Aunque todava no hay un enfoque establecido, loscifique, desarrolle y verifique un sistema basado en com- modelos de mtodos formales ofrecen la promesa de unputadora aplicando una notacin rigurosa y matemtica.software libre de defectos. Sin embargo, se ha habladoAlgunas organizaciones de desarrollo del software de una gran preocupacin sobre su aplicabilidad en unactualmente aplican una variacin de este enfoque, lla- entorno de gestin:mado ingeniera del software de sala limpia [MIL87, 1. El desarrollo de modelos formales actualmente esDYE921.bastante caro y lleva mucho tiempo.2. Se requiere un estudio detallado porque pocos res-los mtodos formales se tratan en los Captulos 25 y 26. ponsables del desarrollo de software tienen los ante- cedentes necesarios para aplicar mtodos formales. Cuando se utilizan mtodos formales (Captulos 253. Es difcil utilizar los modelos como un mecanismoy 26) durante el desarrollo, proporcionan un mecanis-de comunicacin con clientes que no tienen muchosmo para eliminar muchos de los problemas que son dif- conocimientos tcnicos.ciles de superar con paradigmas de la ingeniera del No obstante es posible que el enfoque a travs desoftware. La ambigedad, lo incompleto y la inconsis- mtodos formales tenga ms partidarios entre los desa-tencia se descubren y se corrigen ms fcilmente -norrolladores del software que deben construir softwaremediante un revisin a propsito para el caso, sino de mucha seguridad (por ejemplo: los desarrolladoresmediante la aplicacin del anlisis matemtico-. Cuan-de avinica y dispositivos mdicos), y entre los desa-do se utilizan mtodos formales durante el diseo, sir- rrolladores que pasan grandes penurias econmicas alven como basepara la verificacin de programas y por aparecer errores de software.El trmino tcnicas de cuarta generacin (T4G) abarca siguientes herramientas: lenguajes no procedimentalesun amplio espectro de herramientas de software que tie- de consulta a bases de datos, generacin de informes,nen algo en comn: todas facilitan al ingeniero del soft- manejo de datos, interaccin y definicin de pantallas,ware la especificacin de algunas caractersticas del generacin de cdigos, capacidades grficas de alto nivelsoftware a alto nivel. Luego, la herramienta genera auto- y capacidades de hoja de clculo, y generacin auto-mticamente el cdigo fuente basndose en la especifi-matizada de HTML y lenguajes similares utilizados paracacin del tcnico. Cada vez parece ms evidente quela creacin de sitios web usando herramientas de soft-cuanto mayor sea el nivel en el que se especifique el ware avanzado. Inicialmente, muchas de estas herra-software, ms rpido se podr construir el programa. El mientas estaban disponibles, pero slo para mbitos deparadigma T4G para la ingeniera del software se orien- aplicacin muy especficos, pero actualmente los entor-ta hacia la posibilidad de especificar el software usan-nos T4G se han extendido a todas las categoras de apli-do formas de lenguaje especializado o notacionescaciones del software.grficas que describa el problema que hay que resolver Al igual que otros paradigmas, T4G comienza conen trminos que los entienda el cliente. Actualmente, el paso de reunin de requisitos. Idealmente, el clienteun entorno para el desarrollo de software que soporte describe los requisitos, que son, a continuacin, tradu-el paradigma T4G puede incluir todas o algunas de las cidos directamente a un prototipo operativo. Sin embar- 29 63. INGENIERfA DEL SOFTWARE. U N ENFOQUE PRACTiCOgo, en la prctica no se puede hacer eso. El cliente pue-que facilite la realizacin del mantenimiento de formade que no est seguro de lo que necesita; puede ser ambi-expeditiva.guo en la especificacin de hechos que le son conocidos, Al igual que todos los paradigmas del software, ely puede que no sea capaz o no est dispuesto a especi- modelo T4G tiene ventajas e inconvenientes. Los defen-ficar la informacin en la forma en que puede aceptarsores aducen reducciones drsticas en el tiempo de desa-una herramienta T4G. Por esta razn, el dilogo clien- rrollo del software y una mejora significativa en late-desarrollador descrito por los otros paradigmas sigue productividad de la gente que construye el software.siendo una parte esencial del enfoque T4G. Los detractores aducen que las herramientas actuales de T4G no son ms fciles de utilizar que los lenguajes de programacin, que el cdigo fuente producido por tales herramientas es ineficiente y que el manteni- lncluso cuundo utilice unu 14G, tiene que destocarmiento de grandes sistemas de software desarrollados durumente /u inyenieru del sohore huciendo e/ an6/isis,mediante T4G es cuestionable. el diseo y /os pruebus.Hay algn mrito en lo que se refiere a indicaciones de ambos lados y es posible resumir el estado actual dePara aplicaciones pequeas, se puede ir directamen-los enfoques de T4G:te desde el paso de recoleccin de requisitos al paso de 1 . El uso de T4G es un enfoque viable para muchas deimplementacin, usando un lenguaje de cuarta genera- las diferentes reas de aplicacin. Junto con las herra-cin no procedimental (L4G) o un modelo comprimi-mientas de ingeniera de software asistida por com-do de red de iconos grficos. Sin embargo, es necesarioputadora (CASE) y los generadores de cdigo, T4Gun mayor esfuerzo para desarrollar una estrategia de ofrece una solucin fiable a muchos problemas deldiseo para el sistema, incluso si se utiliza un L4G. El software.uso de T4G sin diseo (para grandes proyectos) causa-2. Los datos recogidos en compaas que usan T4Gr las mismas dificultades (poca calidad, mantenimien- parecen indicar que el tiempo requerido para produ-to pobre, mala aceptacin por el cliente) que se cir software se reduce mucho para aplicacionesencuentran cuando se desarrolla software mediante lospequeas y de tamao medio, y que la cantidad deenfoques convencionales. anlisis y diseo para las aplicaciones pequeas tam-La implementacin mediante L4G permite, al que bin se reduce.desarrolla el software, centrarse en la representacin delos resultados deseados, que es lo que se traduce auto-3. Sin embargo, el uso de T4G para grandes trabajos demticamente en un cdigo fuente que produce dichos desarrollo de software exige el mismo o ms tiemporesultados. Obviamente, debe existir una estructura de de anlisis, diseo y prueba (actividades de ingenie-datos con informacin relevante y a la que el L4G pue- ra del software), para lograr un ahorro sustancial deda acceder rpidamente.tiempo que puede conseguirse mediante la elimina-Para transformar una implementacin T4G en uncin de la codificacin.producto, el que lo desarrolla debe dirigir una prueba Resumiendo, las tcnicas de cuarta generacin ya secompleta, desarrollar con sentido una documentacinhan convertido en una parte importante del desarrolloy ejecutar el resto de las actividades de integracin quede software. Cuando se combinan con enfoques deson tambin requeridas requeridas por otros paradig- ensamblaje de componentes (Seccin 2.8), el paradig-mas de ingeniera del software. Adems, el softwarema T4G se puede convertir en el enfoque dominantedesarrollado con T4G debe ser construido de formahacia el desarrollo del software.OLos modelos de procesos tratados en las secciones ante-cin tratadas en la Seccin 2.3. El modelo, presentadoriores se deben adaptar para utilizarse por el equipo delnormalmente como una red, se puede analizar para deter-proyecto del software. Para conseguirlo, se han desarro- minar el flujo de trabajo tpico y para examinar estruc-llado herramientas de tecnologa de procesos para ayudar turas alternativas de procesos que pudieran llevar a una organizaciones de software a analizar los procesos actua-tiempo o coste de desarrollo reducidos.les, organizar tareas de trabajo, controlar y supervisar elUna vez que se ha creado un proceso aceptable, seprogreso y gestionar la calidad tcnica [BAN95]. pueden utilizar otras herramientas de tecnologa de pro- Las herramientas de tecnologa de procesos permi- cesos para asignar, supervisar e incluso controlar todasten que una organizacin de software construya unlas tareas de ingeniera del software definidas como par-modelo automatizado del marco de trabajo comn dete del modelo de proceso. Cada uno de los miembrosproceso, conjuntos de tareas y actividades de protec-de un equipo de proyecto de software puede utilizar tales30 64. zCAP~TULOE L P R OC E S Oherramientas para desarrollar una lista de control de se puede utilizar para coordinar el uso de otras herra-tareas de trabajo a realizarse, productos de trabajo a pro- mientas de ingeniera del software asistida por compu-ducirse, y actividades de garanta de calidad a condu-tadora (Captulo 3 1) adecuadas para una tarea de trabajocirse. La herramienta de tecnologa de proceso tambinen particular.O D U O Y PR-O..Si el proceso es dbil, el producto final va a sufrir indu-Toda actividad humana puede ser un proceso, pero cada uno dedablemente. Aunque una dependencia obsesiva en el nosotros obtiene el sentido de autoestima ante esas actividades queproducen una representacin o ejemplo que ms de una personaproceso tambin es peligrosa. En un breve ensayo, Mar-puede utilizar o apreciar, una u otra vez, o en algn otro contextogaret Davis [DAV95] comenta la dualidad producto yno tenido en cuenta. Es decir, los sentimientos de satisfaccin seproceso:obtienen por volver a utilizar nuestros productos por nosotros mis- Cada diez aos o cinco aproximadamente,la comunidad del soft-mos o por otros.ware vuelve a definir el problema cambiando el foco de los aspec-As pues, mientras que la asimilacin rpida de los objetivostos de producto a los aspectos de proceso. Por consiguiente, se han de reutilizacin en el desarrollo del software aumenta potencial-abarcado lenguajes de programacin estructurados (producto) segui-mente la satisfaccin que los desarrolladores obtienen de su tra-dos por mtodos de anlisis estructurados (proceso) seguidos a su bajo, esto incrementa la urgencia de aceptar la dualidad productovez por encapsulacin de datos (producto) y despus por el nfasisy proceso. Pensar en un mecanismo reutilizable como el nicoactual en el Modelo Madurez de Capacidad de Desarrollo del soft-producto o el nico proceso, bien oscurece el contexto y la formaware del Instituto de ingeniera de software (proceso). de utilizarlo, o bien el hecho de que cada utilizacin elabora elMientras que la tendencia natural de un pndulo es parar en medio producto que a su vez se utilizar como entrada en alguna otrade dos extremos, el enfoque de la comunidad del software cambia actividad de desarrollo del software. Elegir un mtodo sobre otroconstantemente porque se aplica una fuerza nueva cuando falla elreduce enormemente las oportunidades de reutilizacin y de aqultimo movimiento. Estos movimientos son perjudicialespor s mis- que se pierda la oportunidad de aumentar la satisfaccin ante elmos y en s mismos porque confunden al desarrollador del softwa-trabajo.re medio cambiando radicalmente lo que significa realizar el trabajo,que por s mismo lo realiza bien. Los cambios tampoco resuelvenel problema, porque estn condenados al fracaso siempre que elproducto y el proceso se traten como si formasen una dicotoma enlugar de una dualidad.se aplicapuede convertirse] enLas personas obtienen tanta satisfaccin (o ms) delproceso creativo que del producto final. Un artista dis-fruta con las pinceladas de la misma forma que disfru-ta del resultado enmarcado. Un escritor disfruta con laEn la comunidad cientfica hay un precedente que se adelanta absqueda de la metfora adecuada al i