Ingenieria de SOFT Un Enfoque Practico P PDF

ACERCA DEL AUTOR.
XXIII
PREFACIO, XXV
PROLOGO A LA CUARTA EDICION EN ESPAROL, XXIX
PROLOGO A LA QUINTA EDICION EN ESPAROL, XXXIII
UTILIZACION DEL LIBRO, XXXVII
PARTE PRIMERA: EL PRODUCT0 Y EL PROCESO

CAPITULO I. EL PRODUCTO, 3
CAPITULO 2. EL PROCESO, 13
PARTE SEGUNDA: GESTION DE PROYECTOS DE SOFTWARE

CAPITULO 3. CONCEPTOS SOBRE GESTION DE PROYECTOS, 37
CAPITULO 4. PROCESO DE SOFTWAREY METRICAS DE PROYECTOS, 53
CAPITULO 5. PLANIFICACION DE PROYECTOS DE SOFTWARE,77
CAPITULO 6. ANALISIS Y GESTION DEL RIESGO, 97
CAPITULO 7. PLANIFICACION TEMPORAL Y SEGUIMIENTO DEL PROYECTO,111
CAPITULO 8. GARANTIA DE CALIDAD DEL SOFTWARE (SQAIGCS), 131
CAPITULO 9. GESTION DE LA CONFIGURACION DEL SOFTWARE (GCSISCM), 151
PARTE TERCERA: METODOS CONVENCIONALES PARA LA INGENIERIA DEL SOFTWARE

CAPITULO 10. INGENIERIA DE SISTEMAS, 165
CAPITULO 11. CONCEPTOS Y PRINCIPIOS DEL ANALISIS, 181
CAPITULO12. MODELADO DEL ANALISIS, 199
CAPITULO 13. CONCEPTOS Y PRINCIPIOS DE DISENO, 219
CAPITULO 14. DISENO ARQUITECTONICO,237
CAPITULO 15. DISENO DE LA INTERFAZ DE USUARIO, 259
CAPITULO 16. DISENO A NIVEL DE COMPONENTES,273
CAPITULO 17. TECNICAS DE PRUEBA DEL SOFTWARE, 281
CAPITULO 18. ESTRATEGIAS DE PRUEBA DEL SOFTWARE, 305
CAPITULO 19. METRIC AS TECNICAS DEL SOFTWARE, 323
PARTE CUARTA: INGENIERIA DEL SOFTWARE ORIENTADA A OBJETOS

CAPITULO 20. CONCEPTOS Y PRINCIPIOS ORIENTADOS A OBJETOS, 343
CAPITULO21. ANALISIS ORIENTADOA OBJETOS, 361
CAPITULO 22. DISENO ORIENTADO A OBJETOS, 379
CAPITULO 23. PRUEBAS ORIENTADAS A OBJETOS, 407
CAPITULO 24. METRICAS TECNICAS PARA SISTEMAS ORIENTADOSA OBJETOS, 421
CAPITULO 28. INGENIERIADEL SOFTWARE DEL COMERCIO ELECTRONICO

CLIENTEISERVIDOR, 491
CAPITULO 29. INGENIERIA WEB, 521
CONTENIDOS A PRIMERA VISTA
A C E R C A D E L AUTOR, XXIII
PREFACIO, X X V
PROLOGO A L A CUARTA EDICION E N ESPAROL, X X I X
PROLOGO A L A QUINTA EDICION E N ESPAROL, XXXIII
UTILIZACION DEL LIBRO, XXXVII
PARTE PRIMERA: EL PRODUCTO Y EL PROCESO
CAPITULO 1: EL PRODUCTO, 3
1.1. LA EVOLUCION DEL SOFTWARE4
1.2. EL SOFTWARE, 5
I .2.1. CARACTER~STICASDEL SOFTWARE, 5
1.2.2. APLICACIONES DEL SOFTWARE. 6
1.3. SOFTWARE: ;UNA CRISIS EN EL HORIZONTE?, 8
1.4. MITOS DEL SOFTWARE, 8
RESUMEN, 10
REFERENCIAS, 10
PROBLEMAS Y PUNTOS A CONSIDERAR, 11
OTRAS LECTURAS Y FUENTES DE INFORMACION, 11
CAPITULO 2: EL PROCESO, 13
2.1. INGENIERIA DEL SOFTWARE: UNA TECNOLOGIA ESTRATIFICADA,14
2. I .I. PROCESO, METODOS Y HERRAMIENTAS, 14
2.1.2. UNA V I S ~ ~GENERAL
N DE LA INGENIER~ADEL SOlTWARE, 14
2.2. EL PROCESO DEL SOFTWARE, 16
2.3. MODELOS DE PROCESO DEL SOFTWARE, 19
2.4. EL MODEL0 LINEAL SECUENCIAL, 20
2.5. EL MODELO DE CONSTRUCCION DE PROTOTIPOS, 21
2.6. EL MODEL0 DRA, 22
2.7. MODELOS EVOLUTIVOS DE PROCESO DEL SOFTWARE, 23
2.7.1. EL MODEL0 INCREMENTAL, 23
2.7.2. EL MODEL0 ESPIRAL, 24
2.7.3. EL MODEL0 ESPIRAL WINWIN (Victoria & Victoria), 26
2.7.4. EL MODEL0 DE DESARROLLO CONCURRENTE, 27
2.8. DESARROLLO BASADO EN COMPONENTES, 28
2.9. EL MODEL0 DE METODOS FORMALES, 29
2.10. TECNICAS DE CUARTA GENERACION,29
2.11. TECNOLOGIAS DE PROCESO, 30
2.12. PRODUCTO Y PROCESO, 31
RESUMEN, 31
REFERENCIAS, 32
OTRAS LECTURAS Y FUENTES DE INFORMACI~N,33
j
P RTE
CAPITULO 3: CONCEPTOS SOBRE GESTIONDE PROYECTOS, 37
3.1. EL ESPECTRO DE LA GESTION, 38
3.1.1. PERSONAL, 38
3.1.2. PRODUCTO, 38
3.1.3. PROCESO, 38
3.1.4. PROYECTO, 39
3.2. PERSONAL, 39
3.2.1. LOS PARTICIPANTES. 39
3.2.2. LOS JEFES DE EQUIPO, 40
3.2.3. EL EQUIP0 DE SOFTWARE, 40
3.2.4. ASPECTOS SOBRE LA COORDINACION Y LA COMUNICACION, 43
3.3. PRODUCTO, 44
3.3.1. AMBITO DEL SOFTWARE, 44
3.3.2. DESCOMPOS~C~ON DEL PROBLEMA, 45
3.4. PROCESO, 45
3.4.1. MADURAC~ONDEL PRODUCTO Y DEL PROCESO, 46
3.4.2. DESCOMPOSICION DEL PROCESO, 47
3.5. PROYECTO, 48
3.6. EL PRINCIPIO W5HH, 49
3.7. PRACTICAS CRITICAS, 49
RESUMEN, 50
REFERENCIAS, 50
CAPITULO 4: PROCESO DE SOFTWARE Y METRICAS DE PROYECTOS, 53

4.1. MEDIDAS, METRICAS E INDICADORES, 54
4.2. METRICAS EN EL PROCESO Y DOMINIOS DEL PROYECTO, 55
4.2.1. METRICAS DEL PROCESO Y MEJORAS EN EL PROCESO DEL SOFTWARE. 55
4.2.2. METRICAS DEL PROYECTO, 58
4.3. MEDICIONES DEL SOFTWARE, 58
4.3.1. METRICAS ORIENTADAS AL TAMANO, 59
4.3.2. METRICAS ORIENTADAS A LA FUNCION, 61
4.3.3. METRICAS AMPLIADAS DE PUNTO DE FIJNCION,61
4.4. RECONCILIACION DE LOS DIFERENTES ENFOQUES DE METRICAS, 62
4.5. METRICAS PARA LA CALIDAD DEL SOFTWARE, 63
4.5.1. VISION GENERAL DE LOS FACTORES QUE AFECTAN A LA CALIDAD, 63
4.5.2. MEDIDA DE LA CALIDAD, 64
4.5.3. EFICACIA DE LA ELIMINACION DE DEFECTOS, 64
4.6. INTEGRACION DE LAS METRICAS DENTRO DEL PROCESO DE INGENIERIA
DEL SOFTWARE, 65
4.6.1. ARGUMENTOS PARA LAS METRICAS DEL SOFTWARE, 65
4.6.2. ESTABLECIMIENTO DE UNA L ~ N E ABASE. 66
4.6.3. COLECCION DE METRICAS, COMPUTO Y EVALUACION,66
4.7. EL DESARROLLO DE LA METRICA Y DE LA OPM (OBJETIVO, PREGUNTA,
METRICA), 67
4.8. VARIACION DE LA GESTION: CONTROLDE PROCESOS ESTADISTICOS,69
4.9. METRICA PARA ORGANIZACIONESPEQUENAS, 71
4.10. ESTABLECIMIENTO DE UN PROGRAMA DE METRICAS DE SOFTWARE, 72
RESUMEN, 73
REFERENCIAS, 74
5.3. AMBITO DEL SOFTWARE,79
5.3.1. OBTENCION DE LA INFORMACION NECESARIA PARA EL AMBITO, 79
5.3.2. VIABILIDAD, 80
5.3.3. UN EJEMPLO DE AMBITO, 80
5.4. RECURSOS, 82
5.4.1. RECURSOS HUMANOS, 82
5.4.2. RECURSOS DE SOFTWARE REUTILIZABLES. 82
5.4.3. RECURSOS DE ENTORNO, 83
5.5. ESTIMACION DEL PROYECTO DE SOFTWARE,84
5.6. TECNICAS DE DESCOMPOSICION, 85
5.6.1 TAMANO DEL SOFTWARE. 85
5.6.2. ESTIMAC~ONBASADA EN EL PROBLEMA, 86
5.6.3. UN EJEMPLO DE ESTIMAC~ONBASADA EN LDC. 87
5.6.4. UN EJEMPLO DE ESTIMACION BASADA EN PF, 88
5.6.5. ESTIMACION BASADA EN EL PROCESO. 89
5.6.6. UN EJEMPLO DE ESTIMACION BASADA EN EL PROCESO, 89
5.7. MODELOS EMPIRICOS DE ESTIMACION, 90
5.7.1. LA ESTRUCTURA DE LOS MODELOS DE ESTIMACION, YO
5.7.2. EL MODEL0 COCOMO, 91
5.7.3. LA ECUAC~ONDEL SOFTWARE. 92
5.8. LA DECISION DE DESARROLLAR-COMPRAR,92
5.8.1. CREAC~ONDE UN ARBOL DE DECISIONES, 93
5.8.2. SUBCONTRATACION (OUTSOURCING).94
5.9. HERRAMIENTAS AUTOMATICASDE ESTIMACION, 94
RESUMEN. 95
REFERENCIAS, 95
OTRAS LECTURAS Y FUENTES DE INFORMACION,96
CAPITULO 6: ANALISISY GESTION DEL RIESGO, 97

6.1. ESTRATEGIAS DE RIESGO PROACTIVAS VS. REACTIVAS, 98
6.2. RIESGO DEL SOFTWARE, 98
6.3. IDENTIFICACION DEL RIESGO, 99
6.3.1. EVALUACION GLOBAL DEL RIESGO DEL PROYECTO, loo
6.3.2. COMPONENTES Y CONTROLADORES DEL RIESGO, 101
6.4. PROYECCION DEL RIESGO, 101
6.5.1. DESARROLLO DE UNA TABLA DE RIESGO, 101
6.5.2. EVALUACION DEL IMPACT0 DEL RIESGO, 103
6.4.3. EVALUAC~ONDEL RIESGO, 103
6.5. REFINAMIENTO DEL RIESGO, 104
6.6. REDUCCION,SUPERVISION Y GESTION DEL RIESGO, I05
6.7. RIESGOS Y PELIGROS PARA LA SEGURIDAD, 106
6.8. EL PLAN RSGR, I07
RESUMEN, 107
REFERENCIAS, 107
CAPITULO7: PLANIFICACION TEMPORAL Y SEGUIMIENTO DEL PROYECTO, 111

7.1. CONCEPTOS BASICOS, 112
7.1.1. COMENTARIOS SOBRE cLOS RETRASOSn. 112
7.1.2. PRINCIPIO BASICOS, 113
CONTENIDO
7.2. LA RELACION ENTRE LAS PERSONAS Y EL ESFUERZO, 114

7.2.1. UN EJEMPLO, 115
7.2.2. UNA RELACION EMP~RICA,115
7.2.3. DISTR~BUCIONDEL ESFUERZO, I15
7.3. DEFINICION DE UN CONJUNTO DE TAREAS PARA EL PROYECTO DE SOFTWARE, 116
7.3.1. GRAD0 DE RIGOR, 117
7.3.2. DEFINIR LOS CRITERIOS DE ADAPTACION, 117
7.3.3. CALCULO DEL VALOR SELECTOR DEL CONJUNTO DE TAREAS. 117
7.3.4. INTERPRETAR EL VALOR SCT Y SELECCIONAR EL CONJUNTO DE TAREAS, I19
7.4. SELECCION DE LAS TAREAS DE INGENIERIA DEL SOITWARE, 119
7.5. REFINAMIENTO DE LAS TAREAS PRINCIPALES, 120
7.6. DEFINIR UNA RED DE TAREAS, 121
7.7. LA PLANIFICACION TEMPORAL, 122
7.7.1. GRAFICOS DE TIEMPO, 123
7.7.2. SEGUIMIENTO DE LA PLANIFICACION TEMPORAL, 124
7.8. ANALISIS DE VALOR GANADO, 125
7.9. SEGUIMIENTO DEL ERROR, 126
7.10. EL PLAN DEL PROYECTO, 127
RESUMEN, 127
REFERENCIAS, 128
CAPITULO 8: GARANTIA DE CALIDAD DEL SOFTWARE (SOAIGCS), 131

8.1. CONCEPTOS DE CALIDAD, 132
8.1.1. CALIDAD, 132
8.1.2. CONTROL DE CALIDAD, 133
8.1.3. GAR ANT^ DE CALIDAD, 133
8.1.4. COSTE DE CALIDAD, 133
8.2. LA TENDENCIA DE LA CALIDAD, 134
8.3. GARANTIA DE CALIDAD DEL SOFTWARE, 135
8.3.1. PROBLEMAS DE FONDO, 135
8.3.2. ACTIVIDADES DE SQA, 136
8.4. REVISIONES DEL SOFTWARE, 137
8.4.1. IMPACT0 DE LOS DEFECTOS DEL SOFTWARE SOBRE EL COSTE ,137
8.4.2. AMPLIFICACIONY ELIMINACION DE DEFECTOS, 138
8.5. REVISIONES TECNICAS FORMALES, 138
8.5.1. LA REUNION DE REVISION, 139
8.5.2. REGISTRO E INFORME DE LA REVISION, 140
8.5.3. DIRECTRICES PARA LA REVISION, 140
8.6. GARANTIA DE CALIDAD ESTADISTICA, 141
8.7. FIABILIDAD DEL SOFTWARE, 143
8.7.1. MEDIDAS DE FIABILIDAD Y DE DISPONIBILIDAD, 143
8.7.2. SEGURIDAD DEL SOFTWARE, 144
8.8. PRUEBA DE ERRORES PARA EL SOFTWARE, 145
8.9. EL ESTANDAR DE CALIDAD I S 0 9001,146
8-10. EL PLAN DE SQA, 147
RESUMEN, 148
REFERENCIAS, 148
OTRAS LECTURAS Y FUENTES DE INFORMACION. 150
CAPITULO 9: GESTION DE LA CONFIGURACION DEL SOFTWARE (GCSISCM), 151

9.1. GESTION DE LA CONFIGURACION DEL SOFTWARE, 152
9.1.1. L~NEASBASE, 152
9.1.2. ELEMENTOS DE CONFIGURACION DEL SOFTWARE, 153
9.2. EL PROCESO DE GCS, 154
9.3. IDENTIFICACION DE OBJETOS EN LA CONFIGURACION DEL SOFTWARE, 154
9.4. CONTROL DE VERSIONES, 155
9.5. CONTROL DE CAMBIOS, 156
9.6. AUDITORIA DE LA CONFIGURACION, 158
9.7. INFORMES DE ESTADO, 159
RESUMEN, 159
REFERENCIAS, 160
PARTE TERCERA: METODOS CONVENCIONALES PARA LA ~ N G E N ~ E R IDEL

A SOFTWARE
SISTEMAS BASADOS EN COMPUTADORA, 167

LA JERARQUIA DE LA INGENIERIA DE SISTEMAS, 167
10.2.1. MODELADO DEL SISTEMA, 167
10.2.2. SIMULACION DEL SISTEMA, 168
INGENIERIA DE PROCESO DE NEGOCIO: UNA VISION GENERAL,169
INGENIERIA DE PRODUCTO: UNA VISION GENERAL, 171
INGENIERIA DE REQUISITOS, 171
10.5.1. IDENTIFICACION DE REQUISITOS, 172
10.5.2. ANALISIS Y NEGOCIACION DE REQUISITOS, 173
10.5.3. ESPECIFICACION DE REQUISITOS, 173
10.5.4. MODELADO DEL SISTEMA, 174
10.5.5. VALIDACION DE REQUISITOS, 174
10.5.6. GESTION DE REQUISITOS, 174
MODELADO DEL SISTEMA, 175
RESUMEN, 178
REFERENCIAS, 178
ANALISIS DE REQUISITOS, 182

IDENTIFICACION DE REQUISITOS PARA EL SOFTWARE, 183
11.2.1. INICIO DEL PROCESO, 183
11.2.2. TECNICAS PARA FACILITAR LAS ESPECIFICACIONES DE UNA APLICACION, 184
11.2.3. DESPLIEGUE DE LA F U N C I ~ NDE CALIDAD, 186
11.2.4. CASOS DE USO, 186
PRINCIPIOS DEL ANALISIS, 188
11.3.1. EL DOMINIO DE LA INFORMACION, 189
11.3.2. MODELADO, 190
11.3.3. PARTICION, 190
11.3.4. VISIONES ESENCIALES Y DE IMPLEMENTACION, 191
CREACION DE PROTOTIPOS DEL SOFTWARE, 192
11.4.1. SELECCION DEL ENFOQUE DE CREACION DE PROTOTIPOS, 192
11.4.2. METODOS Y HERRAMIENTAS PARA EL DESARROLLO DE PROTOTIPOS, 193
ESPECIFICACION, 193
XI
11.5.1. PRINCIPIOS DE LA ESPECIFICAC~ON,194
11.5.2. REPRESENTACION, 194
11.5.3. LAESPECIFICACION DE LOS REQUISITOS DEL SOFTWARE, 194
11.6. REVISION DE LA ESPECIFICACION, 195
RESUMEN, 196
REFERENCIAS, 196
CAPITULO 12: MODELADO DEL ANALISIS, 199

12.1. BREVE HISTORIA, 200
12.2. LOS ELEMENTOS DEL MODELO DE ANALISIS, 200
12.3. MODELADO DE DATOS, 201
12.3.1. OBJETOS DE DATOS, ATRIBUTOS Y RELACIONES, 201
12.3.2. CARDINALIDAD Y MODALIDAD, 203
12.3.3. DIAGRAMAS ENTIDAD-RELACION,204
12.4. MODELADO FUNCIONAL Y FLUJO DE INFORMACION, 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, 208
12.5. MODELADO DEL COMPORTAMIENTO, 209
12.6. MECANISMOS DEL ANALISIS ESTRUCTURADO, 210
12.6.1. CREACION DE UN DIAGRAMA ENTIDAD-RELACION, 2 10
12.6.2. CREACION DE UN MODEL0 DE FLUJO DE DATOS, 21 1
12.6.3. CREACION DE UN MODEL0 DE F'LUJO DE CONTROL, 213
12.6.4. LA ESPECIFICACION DECONTROL, 214
12.6.5. LA ESPECIFKACION DEL PROCESO, 214
12.7. EL DICCIONARIO DE DATOS, 215
12.8. OTROS METODOS CLASICOS DE ANALISIS, 216
RESUMEN, 216
REFERENCIAS, 217
CAPITULO 13: CONCEPTOS Y PRINCIPIOS DE DISENO, 219

13.1. DISENO DEL SOFTWARE E INGENIERIA DEL SOFTWARE, 220
13.2. EL PROCESO DE DISENO, 221
13.2.1. DISENO Y CALIDAD DEL SOFTWARE, 22 1
13.2.2. LA EVOLUCION DEL DISENO DEL SOFTWARE, 221
13.3. PRINCIPIOS DEL DISENO, 222
13.4. CONCEPTOS DEL DISENO, 223
13.4.1. ABSTRACCION, 223
13.4.2. REFINAMIENTO, 224
13.4.3. MODULARIDAD, 224
13.4.4. ARQUlTECTURA DEL SOFTWARE, 226
13.4.5. JERARQU~ADE CONTROL, 226
13.4.6. DIVISION ESTRUCTURAL, 227
13.4.7. ESTRUCTURA DE DATOS, 228
13.4.8. PROCEDIMIENTO DE SOFTWARE, 229
13.4.9. OCULTACION DE INFORMACION,229
13.5. DISENO MODULAR EFECTIVO, 229
CONTENIDO
13.5.1. INDEPENDENCIA FUNCIONAL, 229

13.5.2. COHESION, 230
13.5.3. ACOPLAMIENTO, 23 1
13.6. HEURISTICA DE DISENO PARA UNA MODULARIDAD EFECTIVA, 231
13.7. EL MODEL0 DEL DISENO, 233
13.8. DOCUMENTACION DEL DISENO, 233
RESUMEN, 234
REFERENCIAS, 234
CAPITULO 14: DISENO AROUITECTONICO, 237

14.1. ARQUITECTURA DEL SOFTWARE, 238
14.1.1. L~~~ ES ARQUITECTURA?, 238
14.1.2. iPOR QUE ES IMPORTANTE LA ARQUITECTURA?, 238
14.2. DISENO DE DATOS, 239
14.2.1 MODELADO DE DATOS, ESTRUCTURAS DE DATOS, BASES DE DATOS Y ALMACEN DE
DATOS, 239
14.2.2. DISENO DE DATOS A NIVEL DE COMPONENTES, 240
14.3. ESTILOS ARQUITECTONICOS, 241
14.3.1. UNA BREVE TAXONOMIA DE ESTILOS Y PATRONES, 241
14.3.2. ORGANIZACI~NY REFINAMIENTO, 243
14.4. ANALISIS DE DISENOS ARQUITECTONICOSALTERNATIVOS, 243
14.4.1. UN METODO DE ANALISIS DE COMPROMISO PARA LA ARQUITECTURA. 243
14.4.2. GUIA CUANTITATIVA PARA EL DISENO ARQUITECTONICO, 244
14.4.3. COMPLEJIDAD ARQUITECTONICA, 245
14.5. CONVERSION DE LOS REQUISITOS EN UNA ARQUITECTURA DEL SOFTWARE, 245
14.5.1. FLUJO DE TRANSFORMACION, 246
14.5.2. FLUJO DE TRANSACCION,246
14.6. ANALISISDE LAS TRANSFORMACIONES, 247
14.6.1. UN EJEMPLO, 247
14.6.2. PASOS DEL DISENO, 247
14.7. ANALISIS DE LAS TRANSACCIONES, 252
14.7.1. UN EJEMPLO, 252
14.7.2. PASOS DEL DISENO, 252
14.8. REFINAMIENTO DEL DISENOARQUITECTONICO,255
RESUMEN, 256
REFERENCIAS, 256
CAPITULO 15: DISENO DE LA INTERFAZ DE USUARIO, 259

15.1. LAS REGLAS DE ORO, 260
15.1.1. DAR EL CONTROL AL USUARIO, 260
15.1.2. REDUCIR LA CARGA DE MEMORIA DEL USUARIO, 260
15.1.3. CONSTRUCCION DE UNA INTERFAZ CONSISTENTE, 261
15.2. DISENO DE LA INTERFAZ DE USUARIO, 262
15.2.1. MODELOS DE D I S E ~ ~DE
O LA INTERFAZ, 262
15.2.2. EL PROCESO DE D I S E ~ ~DE
O LA INTERFAZ DE USUARIO. 263
15.3. ANALISIS Y MODELADO DE TAREAS, 264
15.4. ACTIVIDADES DEL DISENODE LA INTERFAZ, 264
15.4.1. DEFINICION DE OBJETOS Y ACCIONES DE LA INTERFAZ, 265
15.4.2. PROBLEMAS DEL DISENO, 266
CONTENIDO
15.5. HERRAMIENTAS DE IMPLEMENTACION, 268

15.6. EVALUACION DEL DISENO, 268
RESUMEN, 270
REFERENCIAS, 270
CAPITULO 16: DISENO A NIVEL D E COMPONENTES, 273

16.1. PROGRAMACION ESTRUCTURADA, 274
16.1.l. NOTAC~ONGRAFICA DEL DISENO, 274
16.1.2. NOTAC~ONTABULAR DE D I S E ~ O274
,
16.1.3. LENGUAJE DE DISENODE PROGRAMAS, 276
16.1.4. UN EJEMPLO DE LDP, 277
16.2. COMPARACION DE NOTACIONES DE DISENO, 278
RESUMEN, 279
REFERENCIAS, 279
CAPITULO 17: TECNICAS DE PRUEBA DEL SOFTWARE, 281

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. 283
17.2. DISENO DE CASOS DE PRUEBA, 285
17.3. PRUEBA DE CAJA BLANCA, 286
17.4. PRUEBA DEL CAMINO BASICO, 286
17.4.1. NOTACION DE GRAFO DE FLUJO, 286
17.4.2. COMPLEJIDAD CICLOMATICA, 287
17.4.3. OBTENCION DE CASOS DE PRUEBA, 288
17.4.4. MATRICES DE GRAFOS. 290
17.5. PRUEBA DE LA ESTRUCTURA DE CONTROL, 291
17.5.1. PRUEBA DE CONDICION, 291
17.5.2. PRUEBA DEL FLUJO DE DATOS, 292
17.5.3. PRUEBA DE BUCLES, 293
17.6. PRUEBA DE CAJA NEGRA, 294
17.6.1. METODOS DE PRUEBA BASADOS EN GRAFOS, 294
17.6.2. PARTICION EQUIVALENTE. 296
17.6.3. ANALISIS DE VALORES L~MITE,297
17.6.4. PRUEBA DE COMPARACION, 297
17.6.5. PRUEBA DE LA TABLA ORTOGONAL, 298
17.7. PRUEBA DE ENTORNOS ESPECIALIZADOS, ARQUITECTURAS Y APLICACIONES, 299
17.7.1. PRUEBA DE INTERFACES GRAFICAS DE USUARIO (IGUs), 299
17.7.2. PRUEBA DE ARQUITECTURA CLIENTE/SERVIDOR, 300
17.7.3. PRUEBA DE LA DOCUMENTACION Y FACILIDADES DE AYUDA, 300
17.7.4. PRUEBA DE SISTEMAS DE TIEMPO-REAL, 300
RESUMEN, 301
REFERENCIAS, 302
CONTENIDO
CAPITULO 18: ESTRATEGIAS DE PRUEBA DEL SOFTWARE, 305

18.1. UN ENFOQUE ESTRATEGICO PARA LAS PRUEBAS DEL SOFTWARE, 306
18.1.1. VERIFICACION Y VALIDACION,306
18.1.2. ORGANIZACION PARA LAS PRUEBAS DEL SOFIWARE, 307
18.1.3. UNA ESTRATEGIA DE PRUEBA DEL SOITWARE, 307
18.1.4. CRITERIOS PARA COMPLETAR LA PRUEBA, 308
18.2. ASPECTOS ESTRATEGICOS, 309
18.3. PRUEBA DE UNIDAD, 310
18.3.1. CONSIDERACIONES SOBRE LA PRUEBA DE UNIDAD, 3 10
18.3.2. PROCEDIMIENTOS DE PRUEBA DE UNIDAD, 311
18.4. PRUEBA DE INTEGRACION, 312
18.4.1. INTEGRACION DESCENDENTE, 3 12
18.4.2. INTEGRACION ASCENDENTE, 313
18.4.3. PRUEBA DE REGRESION, 314
18.4.4. PRUEBA DE HUMO, 3 14
18.4.5. COMENTARIOS SOBRE LA PRUEBA DE INTEGRAC~ON,315
18.5. PRUEBA DE VALIDACION, 316
18.5.1. CRITERIOS DE LA PRUEBA DE VALIDACION, 316
18.5.2. REVISION DE LA CONFIGURACION, 3 16
18.5.3. PRUEBAS ALFAY BETA, 316
18.6. PRUEBA DEL SISTEMA, 317
18.6.1. PRUEBA DE RECUPERACION,317
18.6.2. PRUEBA DE SEGURIDAD, 3 17
18.6.3. PRUEBA DE RESISTENCIA (STRESS),318
18.6.4. PRUEBA DE RENDIMIENTO, 3 18
18.7. EL ARTE DE LA DEPURACION, 318
18.7.1. EL PROCESO DE DEPURACION,319
18.7.2. CONSIDERACIONES PS~COLOGICAS,3 19
18.7.3. ENFOQUES DE LA DEPURAC~ON,320
RESUMEN, 321
REFERENCIAS, 321
CAPITULO 19: METRICAS TECNICAS DEL SOFTWARE, 323

19.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 I S 0 9126,326
19.1.4. LA TRANSICION A UNA VISION CUANTITATIVA,326
19.2. UNA ESTRUCTURA PARA LAS METRICAS TECNICAS DEL SOFTWARE, 327
19.2.1. EL RETO DE LAS METRICAS TECNICAS, 327
19.2.2. PRINCIPIOS DE MEDICION,328
19.2.3. CARACTER~ST~CAS FUNDAMENTALES DE LAS METRICAS DEL SOFTWARE. 328
19.3. METRICAS DEL MODEL0 DE ANALISIS, 329
19.3.1. METRICAS BASADAS EN LA FUNC~ON,329
19.3.2. LA METRICABANG, 330
19.3.3. METRICAS DE LA CALIDAD DE LA ESPECIFICACION, 331
19.4. METRICAS DEL MODEL0 DE DISENO, 332
19.4.1. METRICAS DEL DISENO ARQUITECTONICO, 332
19.4.2. ~fRICAS DE DISENO A NIVEL DE COMPONENTES, 333
19.4.3. METRICAS DE DISENO DE INTERFAZ, 335
19.5. METRICAS DEL CODIGO FUENTE, 336
19.6. METRICAS PARA PRUEBAS, 337
19.7. METRICAS DEL MANTENIMIENTO,338
RESUMEN, 338
REFERENCIAS, 338
CAPITULO 20: CONCEPTOS Y PRINCIPIOS ORIENTADOS A OBIETOS, 343

20.1. EL PARADIGMA ORIENTADO A OBJETOS, 344
20.2. CONCEPTOS DE ORIENTACION A OBJETOS, 345
20.2.1. CLASES Y OBJETOS, 346
20.2.2. ATRIBUTOS, 347
20.2.3. OPERACIONES, METODOS Y SERVICIOS. 347
20.2.4. MENSAJES. 347
20.2.5. ENCAPSULAMIENTO, HERENCIA Y POLIMORFISMO, 348
20.3. IDENTIFICACIONDE LOS ELEMENTOS DE UN MODEL0 DE OBJETOS, 350
20.3.1. IDENTIFICACION DE CLASES Y OBJETOS, 350
20.3.2. ESPECIFICACION DE ATRIBUTOS, 353
20.3.3. DEF~NICIONDE OPERACIONES. 353
20.3.4. FIN DE LA DEFINIC~ONDEL OBJETO, 354
20.4. GESTION DE PROYECTOS DE SOFTWARE ORIENTADOA OBJETOS, 354
20.4.1. EL MARC0 DE PROCESO COMUN PARA 0 0 , 3 5 5
20.4.2. METRICAS Y ESTIMACION EN PROYECTOS ORIENTADOS A OBJETOS, 356
20.4.3. UN ENFOQUE 00 PARA ESTIMAC~ONESY PLANIFICACION, 357
20.4.4. SEGUIMIENTO DEL PROGRESO EN UN PROYECTO ORIENTADO A OBJETOS, 358
RESUMEN, 358
REFERENCIAS, 359
OTRAS LECTURASY FUENTES DE INFORMACION,360
CAPITULO 21: ANALISIS ORIENTADO A OBJETOS, 361

21.1. ANALISIS ORIENTADO A OBJETOS, 362
20. I .I. 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, 363
21.2. ANALISIS DEL DOMINIO, 364
2 1.2.1. ANALISIS DE REUTILIZACION Y DEL DOMINIO. 364
21.2.2. EL PROCESO DE ANALISIS DEL DOMINIO, 365
21.3. COMPONENTES GENERICOS DEL MODEL0 DE ANALISIS00,366
21.4. EL PROCESO DE AOO, 367
21.4.2. MODELADO DE CLASES-RESPONSABILIDADES-COLABORACIONES, 368
21.4.3. DEFINIC~ONDE ESTRUCTURAS Y JERARQU~AS,371
21.4.4. DEFINIC~ONDE SUBSISTEMAS, 372
21.5. EL MODELO OBJETO-RELACION,373
21.6. EL MODEL0 OBJETO-COMPORTAMIENTO, 374
2 1.6. I . IDENTIFICACION DE SUCESOS CON CASOS DE USO. 374
21.6.2 REPRESENTACIONES DE ESTADOS, 375
RESUMEN, 376
REFERENCIAS, 377
XVI
CAPITULO 22: DISENO ORIENTADO A OBJETOS, 379

22.1. DISENO PARA SISTEMAS ORIENTADOS A OBJETOS, 380
22.1.1. ENFOQUE CONVENCIONAL VS. 0 0 , 3 8 0
22.1.2. ASPECTOS DEL DISENO, 38 1
22.1.3. EL PANORAMA DE DOO, 382
22.1.4. UN ENFOQUE UNIFICADO PARA EL DOO, 383
22.2. EL PROCESO DE DISENO DE SISTEMA, 384
22.2.1. PARTICIONAR EL MODEL0 DE ANALISIS, 384
22.2.2. ASIGNACION DE CONCURRENCIA Y SUBSISTEMAS, 385
22.2.3. COMPONENTE DE ADMINISTRACION DE TAREAS, 386
22.2.4. COMPONENTE DE INTERFAZ DE USUARIO, 386
22.2.5. COMPONENTE DE LA ADMINISTRACION DE DATOS. 386
22.2.6. COMPONENTE DE GESTION DE RECURSOS, 387
22.2.7. COMUNICACIONES ENTRE SUBSISTEMAS, 387
22.3. PROCESO DE DISENO DE OBJETOS, 388
22.3.1. DESCRIPCION DE OBJETOS, 388
22.3.2. D I S E ~ ~DE
O ALGORITMOS Y ESTRUCTURAS DE DATOS, 389
22.4. PATRONES DE DISENO, 390
22.4.1. 1~~~ES UN PATRON DE D I S E ~ ~ O390
?,
22.4.2. OTRO EJEMPLO DE UN PATRON, 391
22.4.3. UN EJEMPLO FINAL DE UN PATRON,391
22.4.4. DESCRIPCION DE UN PATRON DE DISENO, 392
22.4.5. EL FUTURO DE LOS PATRONES, 392
22.5. PROGRAMACION ORIENTADA A OBJETOS, 393
22.5.1. EL MODEL0 DE CLASES, 393
22.5.2. GENERALIZACION, 394
22.5.3. AGREGACION Y COMPOSICION, 394
23.5.4. ASOCIACIONES, 395
22.5.6. COLABORACIONES, 396
22.5.7. DIAGRAMAS DE ESTADO, 397
22.6. CASO DE ESTUDIO. LIBROS EN LINEA, 398
22.6.1. LIBROS-EN-L~NEA,
399
22.7. PROGRAMACION ORIENTADA A OBJETOS, 400
RESUMEN, 404
REFERENCIAS, 404
CAPITULO 23: PRUEBAS ORIENTADAS A OBJETOS, 407

23.1. AMPLIANDO LA VISION DE LAS PRUEBAS, 408
23.2. PRUEBAS DE LOS MODELOS DE A 0 0 Y DOO, 409
23.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, 409
23.3. ESTRATEGIAS DE PRUEBAS ORIENTADAS A OBJETOS, 410
23.3.1. LAS PRUEBAS DE UNIDAD EN EL CONTEXTO DE LA 0 0 , 4 1 0
23.3.2. LAS PRUEBAS DE INTEGRACION EN EL CONTEXTO 0 0 , 4 1 1
23.3.3. PRUEBAS DE VALIDACION EN UN CONTEXTO 0 0 , 4 1 1
23.4. DISENO DE CASOS DE PRUEBA PARA SOFTWARE 0 0 , 4 1 2
23.4.1. IMPLICACIONES DE LOS CONCEFTOS DE 00 AL DISENO DE CASOS DE PRUEBA, 412
XVII
CONTENIDO
23.4.2. APLICABILIDAD DE LOS METODOS CONVENCIONALES DE DISENO DE CASOS DE

PRUEBA, 412
23.4.3. PRUEBAS BASADAS EN ERRORES, 412
23.4.4. EL IMPACT0 DE LAPROGRAMACION 00 EN LAS PRUEBAS, 413
23.4.5. CASOS DE PRUEBAY JERARQU~ADE CLASES, 414
23.4.6. DISENO DE PRUEBAS BASADAS EN EL ESCENARIO, 414
23.4.7. LAS ESTRUCTURAS DE PRUEBAS SUPERFICIALES Y PROFUNDAS, 415
23.5. METODOS DE PRUEBA APLICABLES AL NIVEL DE CLASES, 416
23.5.1. LA VERIF~CACIONAL M A R PARA CLASES 0 0 , 4 1 6
23.5.2. PRUEBA DE PARTICION AL NIVEL DE CLASES, 416
23.6. DISENO DE CASOS DE PRUEBA INTERCLASES, 417
23.6.1. PRUEBA DE MULTIPLES CLASES, 417
23.6.2. PRUEBA DERIVADA DE LOS MODELOS DE COMPORTAMIENTO,418
RESUMEN, 419
REFERENCIAS, 419
CAPITULO 24: METRICAS TECNICAS PARA SISTEMAS ORIENTADOS A OB.IETOS, 421

24.1. EL PROPOSITO DE LAS METRICAS ORIENTADAS A OBJETOS, 422
24.2. CARACTERISTICAS DISTINTIVAS DE LAS METRICAS ORIENTADAS A OBJETOS, 422
24.2.1. LOCALIZACION, 422
24.2.2. ENCAPSULACION, 422
24.2.3. OCULTACION DE I N F O R M A C ~ ~423
N,
24.2.4. HERENCIA, 423
24.2.5. ABSTRACCI~N, 423
24.3. METRICAS PARA EL MODEL0 DE DISENO00,423
24.4. METRIC AS ORIENTADAS A CLASES, 424
24.4.1. LA SERIE DE METRICAS CK, 425
24.4.2. METRICAS PROPUESTAS POR LORENZ Y KIDD, 426
24.4.3. LA COLECC~ONDE METRICAS MDOO, 427
24.5. METRIC AS ORIENTADAS A OPERACIONES, 428
24.6. METRICAS PARA PRUEBAS ORIENTADAS A OBJETOS, 428
24.7. METRICAS PARA PROYECTOS ORIENTADOS A OBJETOS; 429
RESUMEN, 430
REFERENCIAS, 430
CAPITULO 25: METODOS FORMALES, 435

25.1. CONCEPTOS BASICOS, 436
25.1.1. DEFICIENCIAS DE LOS ENFOQUES MENOS FORMALES, 436
25.1.2. MATEMATICAS EN EL DESARROLLO DEL SOFTWARE, 437
25.1.3. CONCEPTOS DE LOS METODOS FORMALES, 438
25.2. PRELIMINARES MATEMATICOS,441
25.2.1. CONJUNTOS Y ESPECIFICACION CONSTRUCTIVA, 442
25.2.2. OPERADORES DE CONJUNTOS, 442
25.2.3. OPERADORES LOGICOS, 443
25.2.4. SUCESIONES, 443
XVIII
CONTENIDO
25.3. APLICACION DE LA NOTACION MATEMATICA PARA LA ESPECIFICACION

FORMAL, 444
25.4. LENGUAJES FORMALES DE ESPECIFICACION, 445
25.5. US0 DEL LENGUAJE Z PARA REPRESENTAR UN COMPONENTE EJEMPLO DE
SOlVWARE, 446
25.6. METODOS FORMALES BASADOS EN OBJETOS, 447
25.7. ESPECIFICACION ALGEBRAICA, 450
25.8. METODOS FORMALES CONCURRENTES, 452
25.9. LOS DIEZ MANDAMIENTOS DE LOS METODOS FORMALES, 455
25.10. METODOS FORMALES: EL FUTURO, 456
RESUMEN, 456
REFERENCIAS, 457
CAPITULO 26: INGENIERIA DEL SOFTWARE DE SALA LIMPIA, 459

26.1. EL ENFOQUE DE SALA LIMPIA, 460
26.1.1. LA ESTRATEGIA DE SALA LIMPIA, 460
26.1.2. 1~~~HACE DIFERENTE LA SALA LIMPIA?, 461
26.2. ESPECIFICACION FUNCIONAL, 462
26.2.1. ESPECIFICAC~ONDE CAJA NEGRA, 463
26.2.2. ESPECIFICAC~ONDE CAJA DE ESTADO. 463
26.2.3. ESPECIFICACION DE CAJA LIMPIA, 464
26.3. REFINAMIENTO Y VERIFICACION DEL DISENO, 464
26.3.1. REFINAMIENTO Y VERIFICACION DEL DISENO, 464
26.3.2. VENTAJAS DE LA V E R I F I C A C ~ ~DEL
N D I S E ~ ~ 466
O,
26.4. PRUEBA DE SALA LIMPIA, 467
26.4.1. PRUEBA ESTAD~ST~CADE CASOS PRACTICOS, 467
26.4.2. CERTIFICACION,468
RESUMEN, 469
REFERENCIAS, 469
OTRAS LECTURAS Y FUENTESDE INFORMACION. 470
CAPITULO 27: INGENIERIA DEL SOFTWARE BASADA EN COMPONENTES, 473

27.1. INGENIERIA DE SISTEMAS BASADA EN COMPONENTES, 474
27.2. EL PROCESO DE ISBC, 475
27.3. INGENIERIA DEL DOMINIO, 476
27.3.1. EL PROCESO DE ANALISIS DEL DOMINIO, 476
27.3.2. FUNCIONES DE CARACTERIZACION,477
27.3.3. MODELADO ESTRUCTURAL Y PUNTOS DE ESTRUCTURA, 477
27.4. DESARROLLO BASADO EN COMPONENTES, 478
27.4.1. CUALIFICACION, ADAPTACION Y COMPOSICION DE COMPONENTES, 479
27.4.2. INGENIER~ADE COMPONENTES, 481
27.4.3. ANALISISY DISENO PARA LA REUTILIZACION, 481
27.5. CLASIFICACIONY RECUPERACION DE COMPONENTES, 482
27.5.1. DESCRIPCION DE COMPONENTES REUTILIZABLES, 482
27.5.2. EL ENTORNO DE REUTILIZACI~N,
484
27.6. ECONOMIA DE LA ISBC, 484
27.6.1. IMPACT0 EN LA CALIDAD, PRODUCTIVIDAD Y COSTE, 484
27.6.2. ANALISIS DE COSTE EMPLEANDO PUNTOS DE ESTRUCTURA, 485
XIX
CONTENIDO
27.6.3. METRICAS DE REUTILUACION, 486

RESUMEN, 486
REFERENCIAS, 487
CAPITULO 28: INGENIERIA DEL SOFTWARE DEL COMERCIO ELECTRONICO

CLIENTEISERVIDOR, 491
28.1. INTRODUCCION, 492
28.2. SISTEMAS DISTRIBUIDOS, 492
28.2.1. CLIENTES Y SERVIDORES, 492
28.2.2. CATEGOR~ASDE SERVIDORES, 492
28.2.3. SOFTWARE INTERMEDIO (MIDDLEWARE), 494
28.2.4. UN EJEMPLO DE SOFTWARE INTERMEDIO, 495
28.3. ARQUITECTURAS ESTRATIFICADAS, 496
28.4. PROTOCOLOS, 497
28.4.1. EL CONCEPTO, 497
28.4.2. IP E ICMP, 498
28.4.3. POP3,498
28.4.4. EL PROTOCOL0 H'ITP, 499
28.5. UN SISTEMA DE COMERCIO ELECTRONICO, 499
28.5.1. L~~~ ES EL COMERCIO ELECTRONICO?, 499
28.5.2. UN SISTEMA T~PICODE COMERCIO ELECTRONICO, 500
28.6. TECNOLOGIAS USADAS PARA EL COMERCIO ELECTRONICO, 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 CLIENTEISERVIDOR, 504
28.7. EL DISENO DE SISTEMAS DISTRIBUIDOS, 504
28.7.1. CORRESPONDENCIA DEL VOLUMEN DE TRANSMISION CON LOS MEDIOS DE TRANS.
MISION, 504
28.7.2. MANTENIMIENTO DE LOS DATOS MAS USADOS EN UN ALMACENAMIENTO
RAPIDO, 504
28.7.3. MANTENIMIENTO DE LOS DATOS CERCA DE DONDE SE UTILIZAN, 504
28.7.4. UTILIZACION DE LA DUPLICACION 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 UBICACION, 505
28.7.8. CONSIDERAR LA UTILIZACION DE SERVIDORES DEDICADOS A FUNCIONES
FRECUENTES, 506
28.7.9. CORRESPONDENCIA DE LA TECNOLOG~ACON LAS EXIGENCIAS DE
RENDIMIENTO, 506
28.7.10. EMPLEO DEL PARALELISMO TODO LO POSIBLE, 506
28.7.1 1. UTILIZAC~ONDE LA COMPRESI~NDE DATOS TODO LO POSIBLE. 506
28.7.12. D I S E ~ ~PARAEL
O FALLO, 506
28.7.13. MINIMIZAR LALATENCIA, 506
28.7.14. E P ~ O G O 506
,
28.8. INGENIERIA DE SEGURIDAD, 507
28.8.1. ENCRIPTACION, 507
28.8.2. FUNCIONES DE COMPENDIO DE MENSAJES, 508
28.8.3. FIRMAS DIGITALES, 508
28.8.4. CERTIFICACIONES DIGITALES, 508
CONTENIDO
28.9. COMPONENTES DE SOFTWARE PARA SISTEMAS CIS, 509

28.9.1. INTRODUCC~ON, 509
28.9.2. DISTRIBUCION DE COMPONENTES DE SOFTWARE, 509
28.9.3. L~NEASGENERALES PARA LA DISTRIBUCION DE COMPONENTES DE
APLICACIONES, 510
28.9.4. ENLAZADO DE COMPONENTES DE SOFTWARE CIS, 51 1
28.9.5. SOFTWARE INTERMEDIO (MIDDLEWARE) Y ARQUITECTURAS DE AGENTE DE SOLICI-
TUD DE OBJETOS, 5 12
28.10. INGENIERIA DEL SOFTWARE PARA SISTEMAS CIS, 512
28.11. PROBLEMAS DE MODELADO DE ANALISIS, 512
28.12. DISENO DE SISTEMAS CIS, 513
28.12.1. DISENO ARQUITECTONICO PARA SISTEMAS CLIENTE/SERVIDOR, 5 13
28.12.2. ENFOQUES DE DISENO CONVENCIONALES PARA SOFTWARE DE APLICACIONES, 514
28.12.3. DISENO DE BASES DE DATOS, 514
28.12.4. VISION GENERAL DE UN ENFOQUE DE DISENO,515
28.12.5. ITERACION DEL DISENO DE PROCESOS. 516
28.13. PROBLEMAS DE LAS PRUEBAS, 516
28.13.1. ESTRATEGIA GENERAL DE PRUEBAS CIS, 5 I6
28.13.2. TACTICA DE PRUEBAS CIS, 518
RESUMEN, 518
REFERENCIAS, 519
CAPITULO 29: INGENIERIA WEB, 521

29.1. LOS ATRIBUTOS DE APLICACIONES BASADAS EN WEB, 522
29.1.1. ATRIBUTOS DE CALIDAD, 523
29.1.2. LAS TECNOLOG~AS,524
29.2. EL PROCESO DE IWEB, 525
29.3. UN MARC0 DE TRABAJO PARA LA IWEB, 525
29.4. FORMULACION Y ANALISIS DE SISTEMAS BASADOS EN WEB, 526
29.4.1. FORMULACION, 526
29.4.2. ANALISIS, 527
29.5. DISENO PARA APLICACIONES BASADAS EN WEB, 527
29.5.1. DISENO ARQUITECTONICO,528
29.5.2. DISENODE NAVEGACION, 530
29.5.3. DISENO DE LA INTERFAZ, 531
29.6. PRUEBAS DE LAS APLICACIONES BASADAS EN WEB, 532
29.7. PROBLEMAS DE GESTION, 533
29.7.1. EL EQUIP0 DE WEB, 533
29.7.2. GESTION DEL PROYECTO, 534
29.7.3. PROBLEMAS GCS PARA LA IWEB, 536
RESUMEN, 537
REFERENCIAS, 538
CAPITULO 30: REINGENIERIA, 541

30.1. REINGENIERIA DE PROCESOS DE NEGOCIO, 542
30.1.1. PROCESOS DE NEGOCIOS, 542
30.1.2. PRINCIPIOS DE REINGENIER~ADE PROCESOS DE NEGOCIOS, 542
CONTENIDO
30.1.3. UN MODEL0 DE RPN, 543

30.1.4. ADVERTENCIAS, 544
30.2. REINGENIERIADEL SOFTWARE, 544
30.2.1. MANTENIMIENTO DEL SOFIWARE, 544
30.2.2. UN MODEL0 DE PROCESOS DE REINGENIER~ADEL SOmWARE, 545
30.3. INGENIERIAINVERSA, 547
30.3.1. INGENIER~AINVERSA PARA COMPRENDER EL PROCESAMIENTO, 548
30.3.2. INGENIER~AINVERSA PARA COMPRENDER LOS DATOS, 549
30.3.3. INGENIER~AINVERSA DE INTERFACES DE USUARIO, 550
30.4. REESTRUCTURACION,
550
30.4.1. REESTRUCTURACION DEL CODIGO, 550
30.4.2. REESTRUCTURACION DE LOS DATOS, 551
30.5. INGENIERIADIRECTA (FORWARDENGINEERING),551
30.5.1. INGENIER~ADIRECTA PARA ARQUITECTURAS CLIENTEISERVIDOR,552
30.5.2. INGENIER~ADIRECTA PARA ARQUITECTURAS ORIENTADAS A OBJETOS, 553
30.5.3. INGENIER~ADIRECTA PARA INTERFACES DE USUARIO, 553
30.6. LA ECONOMIA DE LA REINGENIERIA,554
RESUMEN, 555
REFERENCIAS, 555
CAPITULO 31: INGENIERIA DEL SOFTWAREASISTIDA POR COMPUTADORA, 559

31.1. ;QUE SlGNIFICA CASE?, 560
31.2. CONSTRUCCION DE BLOQUES BASICOSPARA CASE, 560
31.3. UNA TAXONOMIA DE HERRAMIENTAS CASE, 561
31.4. ENTORNOS CASE INTEGRADOS, 565
31.5. LA ARQUITECTURA DE INTEGRACION, 566
31.6. EL REPOSITORIO CASE, 567
31.6.1. EL PAPEL DEL REPOSITORIO EN I-CASE, 567
31.6.2. CARACTER~STICASY CONTENIDOS, 568
RESUMEN, 571
REFERENCIAS, 571
OTRAS LECTURAS Y FUENTESDE INFORMACION, 572
CAPITULO 32: PERSPECTIVASFUTURAS. 573

32.1. IMPORTANCIA DEL SOITWARE S E G U N D A P A R T S , 574
32.2. EL AMBITODEL CAMBIO, 574
32.3. LAS PERSONAS Y LA FORMA EN QUE CONSTRUYEN SISTEMAS, 574
32.4. EL <<NUEVO,PROCESO DE INGENIERIA DEL SOFTWARE,575
32.5. NUEVOS MODOS DE REPRESENTAR LA INFORMACION,576
32.6. LA TECNOLOGIA COMO IMPULSOR, 577
32.7. COMENTARIO FINAL, 578
REFERENCIAS, 578
R
OGER S. Pressman es una autoridad internacionalmente reconocida en la mejora del
proceso del Software y en las tecnologias de la Ingenieria del Software. Durante tres
dCcadas, ha trabajado como ingeniero de Software, gestor, profesor, autor y consultor
centrhndose en 10s temas de la Ingenieria del Softwate.
Como especialista y gerente industrial, el Dr. Pressman ha trabajado en el desarrollo de sis-
temas CADICAM para aplicaciones avanzadas de ingenieria y fabricacibn. TambiCn ha ocu-
pado puestos de responsabilidad para programaci6n cientifica y de sistemas.
DespuCs de recibir el titulo de Doctor en Ciencias Fisicas en Ingenieria de la Universidad de
Connecticut, el Dr. Pressman se dedic6 a la ensefianza donde lleg6 a ser Profesor Asociado
(Bullard Associate Professor) de Informhtica en la Universidad de Bridgeport y Director del
Computer-Aided Design an Manufacturing Center en esta Universidad.
El Dr. Pressman es actualmente el Presidente de R. S. Pressman & Associates, Inc., una
empresa de asesoria especializada en mCtodos y formaci6n de Ingeniena del Softwate. Trabaja
como asesor jefe, y esth especializado en la asistencia a compaiiias para establecer unas prhc-
ticas eficientes de la Ingeniena del Software. TambiCn ha disefiado y desarrollado productos
para la formaci6n en Ingenieria del Softwate de la compafiia y de mejora del proceso: Essen-
tial Software Engineering, un curriculum en video totalmente actualizado que se cuenta entre
10s trabajos industriales mis extensos acerca de este tema y, Process Advisor, un sistema pro-
gramado para la mejora en el proceso de ingeniena del softwate. Ambos productos son utili-
zados por cientos de compafiias mundiales.
El Dr. Pressman ha escrito numerosos articulos tCcnicos, participa regularmente en revistas
industriales, y ha publicado 6 libros. Ademhs de Ingenieria del Software: Un Enfoque Prcic-
tico, ha escrito A Manager's Guide to Software Engineering (McGraw-Hill), un libro que hace
uso de un exclusive formato de preguntas y respuestas para presentar las lineas generales de
Administraci6n para implantar y comprender la tecnologia; Making Software Engineering Hap-
pen (Prentice-Hall), que es el primer libro que trata 10s problemas criticos de administraci6n
asociados a la mejora del proceso del Software y Software Shock (Dorset House), un tratado
centrado en el Software y su impact0 en 10s negocios y en la sociedad. El Dr. Pressman es miem-
bro del consejo editorial del IEEE Softrr~arey del Cutter IT Journal, y durante muchos afios fue
editor de la columna <<Manager>> del IEEE Software.
El Dr. Pressman es un conocido orador, impartiendo un gran nlimero de conferencias indus-
triales principalmente. Ha presentado tutoriales en la Conferencia Intemacional de Ingenieria
del Software y en muchas otras conferencias industriales. Es miembro de ACM, IEEE y Tau
Beta Pi, Phi Kappa Phi, Eta Kappa Nu y Pi Tau Sigma.
XXIII
C
UANDO un software de computadora se desarrolla con Cxito +uando satisface las
necesidades de las personas que lo utilizan; cuando funciona impecablemente durante
mucho tiempo; cuando es fhcil de modificar o incluso es rnhs fhcil de utilizar- puede
cambiar todas las cosas y de hecho las cambia para mejor. Ahora bien, cuando un software de
computadora falla d u a n d o 10s usuarios no se quedan satisfechos, cuando es propenso a erro-
res; cuando es dificil de cambiar e incluso rnhs dificil de utilizar- pueden ocurrir y de hecho
ocurren verdaderos desastres. Todos queremos desarrollar un software que haga bien las cosas,
evitando que esas cosas malas merodeen por las sombras de 10s esfuerzos fracasados. Para tener
Cxito a1 disefiar y construir un software necesitaremos disciplina. Es decir, necesitaremos un
enfoque de ingenieria.
Durante 10s 20 afios que han transcurrido desde que se escribi6 la primera edici6n de este
libro, la ingenieria del software ha pasado de ser una idea oscura y practicada por un grupo muy
pequefio de fanhticos a ser una disciplina legitima de ingenieria. Hoy en dia, esta disciplina esth
reconocida como un tema valioso y digno de ser investigado, de recibir un estudio concienzudo
y un debate acalorado. A travCs de la industria, el titulo preferido para denominar a1 ccprogra-
mador>>ha sido reemplazado por el de ccingeniero de software>>.Los modelos de proceso de
software, 10s mCtodos de ingenieria del software y las herramientas del software se han adap-
tad0 con Cxito en la enorme gama de aplicaciones de la industria.
Aunque gestores y profesionales reconocen igualmente la necesidad de un enfoque rnhs dis-
ciplinado de software, continlian debatiendo sobre la manera en que se va a aplicar esta disci-
plina. Muchos individuos y compafiias todavia desarrollan software de manera algo peligrosa,
incluso cuando construyen sistemas para dar servicio a las tecnologias mis avanzadas de hoy
en dia. Muchos profesionales y estudiantes no conocen 10s mCtodos nuevos y, como resultado,
la calidad del software que se produce sufrirh y experimentarh malas consecuencias. Ademhs,
se puede decir que seguir6 existiendo debate y controversia a cerca de la naturaleza del enfo-
que de la ingenieria del software. El estado de la ingenieria es un estudio con contrastes. Las
actitudes han cambiado y se ha progresado, per0 todavia queda mucho por hacer antes de que
la disciplina alcance una madurez total.
La quinta edicidn de la Ingenieria del Software: Un Enfoque Prcictico pretende semir de guia
para conseguir una disciplina de ingenieria madura. Esta edicibn, a1 igual que las cuatro ante-
riores, pretende servir a estudiantes y profesionales, y mantiene su encanto como guia para el
profesional de industria y como una introduccidn completa a1 tema de la ingenieria para alum-
nos de diplomatura, o para alumnos en primer afio de segundo ciclo. El formato y estilo de la
quinta edici6n ha experimentado cambios significativos, con una presentacidn rnhs agradable
y cdmoda para el lector, y con un contenido de acceso rnhs fhcil.
La quinta edicidn se puede considerar rnhs que una simple actualizacidn. La revisi6n de este
libro se ha realizado para adaptarse a1 enorme crecimiento dentro de este campo y para enfati-
zar las nuevas e importantes pricticas de la ingenieria del software. Ademhs, se ha desarrollado
un sitio Web con todo lo necesario y esencial para complementar el contenido del libro. Junto
con la quinta edici6n de Ingenieria del Software: Un Enfoque Prcictico, la Web proporciona
una gama enorrne de recursos de ingenieria del software de la que se beneficiarhn instructores,
estudiantes y profesionales de industria.
La estructura de la quinta edici6n se ha establecido en cinco partes y la intencidn ha sido la
de realizar una divisidn por temas, y ayudar asi a instructores que quizis no tengan tiempo de
abarcar todo el libro en un solo trimestre. La Parte Primera, El producto y el proceso, es una
introducci6n a1 entomo de la ingenieria del software. La intencidn de esta parte es introducir el
tema principal y, lo que es rnhs importante, presentar 10s conceptos necesarios para 10s capitu-
10s siguientes. La Parte Segunda, Gestibn de proyectos de software, presenta 10s temas rele-
vantes para planificar, gestionar y controlar un proyecto de desarrollo de ingenieria. La Parte
Tercera, Me'todos convencionales para la ingenieria del software, presenta 10s mCtodos clisi-
cos de anilisis, disefio y pruebas considerados como la escuela ccconvencional>>de la ingenie-
ria del software. La Parte Cuarta, Ingenieria del software orientada a objetos, presenta 10s
xxv
PREFACIO
metodos orientados a objetos a lo largo de todo el proceso de ingenieria del software, entre 10s
que se incluyen anhlisis, diseiio y pruebas. La Parte Quinta, Temas avanzados erz ingenieria del
software, introduce 10s capitulos especializados en mktodos formales, en ingenieria del soft-
ware de sala limpia, ingenieria del software basada en componentes, ingenieria del software
cliente/servidor, ingenieria de Web, reingenieria y herramientas CASE.
La estructura de la quinta edici6n en cinco partes permite que el instructor ccagrupen 10s temas
en funci6n del tiempo disponible y de las necesidades del estudiante. Un trimestre completo se
puede organizar en tom0 a una de las cinco partes. Por ejemplo, un cccurso de diseiion podria
centrarse solo en la Parte Tercera o Cuarta; un cccurso de mCtodosn podria presentar 10s capi-
tulos seleccionados de las Partes Tercera, Cuarta y Quinta. Un cccurso de gestiom haria hinca-
pi6 en las Partes Primera y Segunda. Con la organization de esta quinta edicibn, he intentado
proporcionar diferentes opciones para que el instructor pueda utilizarlo en sus clases.
El trabajo que se ha desarrollado en las cinco ediciones de lrzgenieria del Sofmare: Un Enfo-
que Prcictico es el proyecto tCcnico de toda una vida. Los momentos de intenupci6n 10s he dedi-
cad0 a recoger y organizar informaci6n de diferentes fuentes tCcnicas. Por esta raz6n, dedicarC
mis agradecimientos a muchos autores de libros, trabajos y articulos, asi como a la nueva gene-
raci6n de colaboradores en medios electr6nicos (grupos de noticias, boletines informativos elec-
tr6nicos y World Wide Web), quienes durante 20 aiios me han ido facilitando otras visiones,
ideas, y comentarios. En cada uno de 10s capitulos aparecen referencias a todos ellos. Todos
esthn acreditados en cuanto a su contribuci6n en la rhpida evoluci6n de este campo. TambiCn
quiero dedicar mis agradecimientos a 10s revisores de esta quinta edici6n. Sus comentarios y
criticas son de un valor incalculable. Y por 6ltimo dedicar un agradecimiento y reconocimiento
especiales a Bruce Maxim de la Universidad de Michigan -DearBom, quien me ayud6 a desa-
rrollar el sitio Web que acompaiia este libro, y como persona responsable de una gran parte del
diseiio y contenido pedad6gico-.
El contenido de la quinta edici6n de Ingenieria del Sofhyare: Urz Enfoque Prcictico ha tomado
forma gracias a profesionales de industria, profesores de universidad y estudiantes que ya habian
utilizado las ediciones anteriores, y que han dedicado mucho tiempo en mandarme sus suge-
rencias, criticas e ideas. Muchas gracias tambien a todos vosotros. Ademhs de mis agradeci-
mientos personales a muchos clientes de industria de todo el mundo, quienes ciertamente me
enseiian mucho mhs de lo que yo mismo puedo enseiiarles.
A medida que he ido realizando todas las ediciones del libro, tambiCn han ido creciendo y
madurando mis hijos Mathew y Michael. Su propia madurez, carhcter y Cxito en la vida han
sido mi inspiraci6n. Nada me ha llenado con mhs orgullo. Y, finalmente, a Bhbara, mi cariiio
y agradecimiento por animarme a elaborar esta quinta edici6n.
Roger S. Pressman
L libro de Roger Pressman sobre Ingenieria del software es verdaderamente excelente:
Siempre he admirado la profundidad del contenido y la habilidad del autor para descri-
bir datos dificiles de forma muy clara. De manera que tuve el honor de que McGraw-
Hill me pidiera elaborar la Adaptaci6n Europea de esta quinta edici6n. Esta es la tercera
adaptacibn, y su contenido es un acopio de la quinta edici6n americana y el material que yo
mismo he escrito para ofrecer una dimensi6n europea.
Las areas del libro que contienen ese material extra son las siguientes:
Existe una gran cantidad de material sobre mCtodos formales de desarrollo del software.
Estas tCcnicas fueron pioneras en el Reino Unido y Alemania, y han llegado a formar parte
de 10s juegos de herramientas criticos para 10s ingenieros de software en el desarrollo de sis-
temas altamente integrados y criticos para la seguridad.
He incluido una secci6n sobre patrones de disefio. Estos son 10s que tienen lugar general-
mente en miniarquitecturas que se dan una y otra vez en sistemas orientados a objetos, y que
representan plantillas de disefio que se reutilizarh una y otra vez. He viajado por toda Europa,
y me he encontrado constantemente compaiiias cuyo trabajo depende realmente de esta tec-
nologia.
He aportado material sobre mCtricas y en particular la utilizaci6n de GQM como mCtrica de
mCtodo de desarrollo. A medida que la ingenieria del software se va integrando poco a poco
dentro de una disciplina de ingenieria, esta tecnologia se va convirtiendo en uno de sus fun-
damentos. La mCtrica ha sido uno de 10s puntos fuertes en Europa de manera que espero que
toda la dedicaci6n que he puesto en este tema lo refleje.
He incluido tambiCn material sobre el Lenguaje de Modelado Unificado (UML) el cual refleja
el gran increment0 de utilizaci6n de este conjunto de notaciones en Europa Occidental. Ade-
mas, sospecho que van a ser de hecho las notaciones de desarrollo de software estandar
durante 10s pr6ximos tres o cuatro afios.
He dado mayor Cnfasis a1 desarrollo de sistemas distribuidos mediante el lenguaje de pro-
gramaci6n Java para ilustrar la implicaci6n de algunos de 10s c6digos. Ahora que Internet y
el comercio electr6nico estan en pleno auge en Europa, las compafiias cada vez se vuelcan
m8s en las tCcnicas de ingenieria del software a1 desarrollar aplicaciones distribuidas. Y esto
tambiCn queda reflejado en el libro.
He incluido tambiCn material sobre mCtodos de seguridad e ingenieria. Con la utilizaci6n de
Internet (una red abierta) todos 10s ingenieros del software tendrh que saber muchas mas
tCcnicas tales como firmas digitales y criptografia.
Hacia el final del libro he hecho especial hincapiC en la utilizaci6n de aplicaciones de comer-
cio electr6nico para mostrar de esta manera la tecnologia distribuida.
Existen dos part& que hacen referencia al libro: un sitio Web americano muy importante, desa-
rrollado por el Dr. Pressman; y un sitio de entrada, cuya direcci6n se proporciona a lo largo de todo
el libro a1 final de cada capitulo. Este sitio contiene el material relevante para la edici6n europea y
10s enlaces con el sitio americano. Arnbos sitios Web en combinaci6n contienen sub-webs con recur-
sos para Estudiantes, para Profesores y para Profesionales.
En 10s Recursos para el estudiante se incluye una guia de estudio que resume 10s puntos clave
del libro, una serie de autopruebas que permiten comprobar la comprensi6n del material, cientos
de enlaces a 10s recursos de ingenieria del software, un caso practice, materiales complementaries
y un tabl6n de mensajes que permite comunicarse con otros lectores.
En la parte Recursos para el profesor se incluye una guia para el instructor, un conjunto de
presentaciones en Powerpoint basadas en este libro, un conjunto de preguntas que se pueden
utilizar para practicar mediante deberes y examenes, un conjunto de herramientas muy peque-
fias (herramientas sencillas de ingenieria del software adecuadas para su utilization en clase),
una herramienta de Web que permite crear un sitio Web especifico para un curso, y un tabl6n
de mensajes que hace posible la comunicaci6n con otros instructores.
En 10s Recursos para profesionales se incluye documentaci6n para 10s procesos de inge-
nieria del software, listas de comprobaci6n para actividades tales como revisiones, enlaces a
proveedores de herramientas profesionales, cientos de enlaces a recursos de ingenieria del soft-
ware, informaci6n sobre 10s paquetes de video de Pressman, y comentarios y ensayos indus-
triales acerca de varios temas de la ingenieria del software.
Ingenieria del software es un libro excelente, y espero que 10s aportes que he incluido para
el lector europeo hagan de este libro una lectura obligada.
Darrel Ince
E L ESTADO DEL ARTE DE LA INGENIERIA DEL SOFTWARE
La Ingenieria dell Software ' es una disciplina o Area de la Informitica o Ciencias de la Com-
putacibn, que ofrece mCtodos y tCcnicas para desarrollar y mantener software de calidad que
resuelven problemas de todo tipo. Hoy dia es cada vez mis frecuente la consideraci6n de la
Ingenieria den Software como una nueva Area de la ingenieria, y el ingeniero de/l software
comienza a ser una profesi6n implantada en el mundo laboral intemacional, con derechos, debe-
res y responsabilidades que cumplir, junto a una, ya, reconocida consideraci6n social en el
mundo empresarial y, por suerte, para esas personas con brillante futuro.
La Ingenieria de/l Software trata con Areas muy diversas de la informitica y de las ciencias
de la computaci6n, tales como construcci6n de compiladores, sistemas operativos o desarro-
110s en IntranetIInternet, abordando todas las fases del ciclo de vida del desarrollo de cualquier
tipo de sistemas de informaci6n y aplicables a una infinidad de ireas tales corno: negocios,
investigaci6n cientifica, medicina, producci6n, logistica, banca, control de trifico, meteorolo-
gia, el mundo del derecho, la red de redes Internet, redes Intranet y Extranet, etc.
Definicion del termino <<Ingenieriadell Software>>
El tCrmino Ingenieria se define en el DRAEZcorno: <<I. Conjunto de conocimientos y tCcni-

cas que permiten aplicar el saber cientifico a la utilizaci6n de la materia y de las fuentes de
energia. 2. Profesi6n y ejercicio del ingenieron y el tCrmino ingeniero se define como c t l . Per-
sona que profesa o ejerce la ingenieria,,. De igual mod0 la Real Academia de Ciencias Exac-
tas, Fisicas y Naturales de Espafia define el tCrmino Ingenieria corno: <<Conjuntode
conocimientos y tCcnicas cuya aplicaci6n permite la utilizaci6n racional de 10s materiales y
de 10s recursos naturales, mediante invenciones, construcciones u otras realizaciones prove-
chosas para el hombre))3 .
Evidentemente, si la Ingenieria del Software es una nueva ingenieria, parece 16gico que reuna
las propiedades citadas en las definiciones anteriores. Sin embargo, ni el DRAE ni la Real Aca-
demia Espafiola de Ciencias han incluido todavia el tCrmino en sus ultimas ediciones; en con-
secuencia varnos a recunir para su definici6n mis precisa a algunos de 10s autores mAs acreditados
que comenzaron en su momento a utilizar el tCrmino o bien en las definiciones dadas por orga-
nismos internacionales profesionales de prestigio tales como IEEE o ACM. Asi, hemos selec-
cionado las siguientes definiciones de Ingenieria del Software:
Definicio'n 1
Ingenieria de Software es el estudio de losprincipios y metodologias para desarrollo y man-

tenimiento de sistemas de software [Zelkovitz, 19781'.
Definicio'n 2
Ingenieria del Software es la aplicaci6n prdctica del conocimiento cientifico en el disefio

y construcci6n de programas de computadora y la documentacibn asociada requerida para
desarrollar, operar (funcionar) y mantenerlos. Se conoce tambiCn como desarrollo de soft-
ware o producci6n de software [Bohem, 19761'.
' En Hispanoamerica, el termino utilizado normalmente es: Ingenieria de Software.

DRAE, Diccionario de la Real Academia Espatiola de la Lengua.
Vocabulario Cientificoy Tecnico, edicion de 1996.
ZELKOVITZ,M. V., SHAW, A. C. y GANNON, J. D.: Principles of Sopware Enpeering and Design. Prentice-Hall, Englewoods
Clif, 1979.
BOEHM,B. W.: 6oftware Engineering)),IEEE 7Fansactions on Computers, C-25, nlim. 12, diciembre, pp. 1226.1241.
PR6LOGO A LA CUARTA EDICI6N EN ESPANOL
Dejnicion 3
Ingenieria del Software trata del establecimiento de 10s principios y mCtodos de la ingenie-
ria a fin de obtener software de mod0 rentable que seafiable y trabaje en mciquinas reales [Bauer,
197216 .
Dejnicion 4
La aplicaci6n de un enfoque sistemdtico, disciplinado y cuantificable a1 desarrollo, opera-

cibn (funcionamiento) y mantenimiento del software; es decir, la aplicaci6n de ingenieria a1
software. 2. El estudio de enfoques como en (1) [IEEE, 19931'.
Tomando como base la referencia de estas definiciones seleccionadas, se producen de inme-

diato las preguntas: jcuciles son las actividades que se encuadran hoy dia en el mundo de la
ingenieria del software? y jcbmo se ensefia la disciplina de ingenieria del software en las uni-
versidades, escuelas de ingenieros e institutos tecnolbgicos?
La respuesta a la primera pregunta se manifiesta de muy diversas formas, per0 creemos que
tal vez las fuentes mfis objetivas Sean las conferencias, eventos y acontecimientos internaciona-
les mhs relevantes realizados en estos ultimos afios. Asi, de 10s estudiados, hemos considerado
como congresos significativos, 10s convocados por SIGSOFT (Special Interest Group on Soft-
ware Engineering) de la ACM ? International Conference on Software Engineering (ICSE, copa-
trocinada con IEEE) celebrada en Boston, Massachussets, USA (17-23 de mayo de 1997) y la
pr6xima conferencia anunciada para celebrarse en 1998 en Kyoto, Jap6n (ICSE, 19-25 de abril
de 1998); 5." Symposium Foundations of Software Engineering, SIGSOFT 97 (Zurich, 22-25
septiembre de 1997) y 6.' Symposium SIGSOFT 98 (Orlando, Florida, USA, 3-5 noviembre de
1998).
En 10s congresos citados anteriormente y en algunas otras fuentes como revistas de ACM/IEE
y otras de tipo profesional o comercial especificas de ingenieria de software, hemos analizado
sus programas, tutoriales, talleres de trabajo, contenidos, etc., y hemos seleccionado una lista
con 10s temas mfis candentes del actual estado del arte de la Ingenieria del Software. Los temas
mfis sobresalientes son:
Inspecci6n de software critico.

Software de Tecnologias de Procesos de Negocios.
Arquitecturas de Software Distribuido.
Introducci6n a UML (Metodologia de objetos, mCtodo unificado de Booch, Rumbaugh y
Jacobson).
Control tCcnico de proyectos software.
Marcos de trabajo (frameworks) de empresa orientados a objetos.
Una introducci6n a CORBA (Estfindar para objetos distribuidos).
Estrategias de ingenieria inversa para migraci6n de software.
Ingenieria de objetos.
Modelado y anfilisis de arquitectura de software.
Objetos distribuidos.
Sistemas Cliente/Semidor.
Reingenieria.
0 CASE.
Anfilisis y Disefio Orientados a Objetos.
0 ...
Esta cuarta edici6n ha mejorado en cantidad y calidad a la tercera edicibn, per0 su actuali-
dad en el afio 1997, reside en el hecho de que la mayoria de temas tratados o que se van a tra-
tar en 10s congresos de la ACM (listados anteriormente), estfin contemplados y tratados por el
autor en este libro. En cualquier forma, deseamos destacar muy expresamente algunas mejoras
concretas que vienen a llenar una importante laguna que existia en 10s libros de ingenieria del
BAUER, F. L.: ((SoftwareEngineering., Information Processing, 71, North Holland Publishing Co., Amsterdam, 1972
IEEE: Standards Collection:Somare Engineering, IEEE Standard 610.12-1990,IEEE, 1993.
URL de ACM, http://www.acm.org.
PR~LOGO
A LA CUARTA E D I C I ~ NEN ESPANOL
software en inglCs y, por supuesto, en espafiol. Asi, destacamos el estudio y profundidad que
se hace de temas tan candentes y de actualidad en el mundo de la ingenieria del software tales
como: Me'todosformales, reutilizacibn de software, reingenieria,me'todos de software ClientelSer-
vidor, CASE, andisisldiseiiolpruebas y me'tricas orientados a objetos, etc., junto con un epi-
logo donde muestra el estado actual y futuro de la Ingenieria del Software. Con relacion a la
tercera edicion se aprecia una consolidaci6n de tratamientos y una unificaci6n de bloques de
conocimiento que consiguen mejorar el aprendizaje del lector.
Una de las aportaciones mas relevantes que aporta esta nueva edici6n es la excelente biblio- '
grafia y referencias bibliograficas que se adjuntan en cada capitulo del libro, junto a una nove-
dad que poco a poco comienza a incorporarse en las buenas obras cientificas y que aqui alcanza
un excelente nivel: direcciones electrdnicas (URLs) de sitios Web de Internet notables, donde
se pueden ampliar conocimientos, fuentes bibliograficas, consultorias, empresas, organismos
internacionales, etc., especializados en Ingenieria de Software.
En lo relativo a la segunda pregunta antes enunciada, su respuesta implica el uso de libros
de texto y manuales que ayuden a1 estudiante a complementar las lecciones impartidas por el
profesor, asi como preparar sus trabajos, pricticas, eximenes, etc. Un libro para ser conside-
rado de texto o referencia de una determinada asignatura requiere que su contenido contenga
todos o la mayoria de 10s descriptores o t6picos considerados en el programa de la asigna-
tura. Veamos por que esta obra es id6nea como libro de texto para asignaturas del curriculum
universitario de Zngenieria de/l Software.
EL LIBRO COMO TEXT0 DE REFERENCIA UNIVERSITARIA
La importancia fundamental de la disciplina Ingenieria del Sofh.mre se esti manifestando, de mod0

destacado, en 10s curriculum de informfitica y ciencias de la computaci6n de la mayoria de las uni-
versidades de todo el mundo, y seguira creciendo su importancia a medida que nos acerquemos
a1 tercer milenio.
Debido a estas circunstancias, las organizaciones profesionales, 10s departamentos educati-
vos de 10s diversos gobiernos y 10s departamentos universitarios se han preocupado en esta
dCcada y en las anteriores de estandarizar 10s programas curriculares de las diferentes carreras,
incluyendo materias (asignaturas) troncales y obligatorias, en 10s planes de estudios de Facul-
tades y Escuelas de Ingenieros de todo el mundo.
El caso mas significativo lo constituyen las organizaciones profesionales internacionales que
se han preocupado tambiCn de este proceso. Entre las mis destacadas sobresalen ACM (Asso-
ciation of Computing Machinery) e IEEE (Institute for Electrical and Electronics Engineers).
Asi, en el afio 1991, estas dos organizaciones publicaron conjuntamente unas recomendacio-
nes con 10s requisitos (materias) imprescindibles que, a1 menos, debian contemplar todos 10s
planes de estudios de carreras relacionadas con Ciencias de la Computaci6n (Informatics). Estas
recomendaciones han sido seguidas por todas las universidades de Estados Unidos y prictica-
mente, de una u otra forma, por casi todas las universidades europeas e hispanoamericanas,
desde el atio de su publicaci6n.
Las recomendaciones ACM/IEEEqdividen 10s requisitos del curriculum en nueve Areas dife-
rentes, con subdivisiones en esas Areas. Para cada subArea se recomienda un n6mero minimo
de unidades de conocimiento (knowledge units) con una indicaci6n de tiempo para cada una de
ellas (periodos de 50 minutos/clase). En estas nueve Areas se incluyen: Algoritmos, Arquitec-
tura, Inteligencia Artificial, Bases de Datos, Interfaces Hombre/Miquina, Computaci6n nume-
rica, Sistemas Operativos, Programacibn, Ingenieria del Software, Lenguajes de Programaci6n
y Temas legales, profesionales y sociales. Los temas recomendados en el Area de Ingenieria de
Software son:
1. Conceptos fundamentales de resoluci6n de problemas.

2. Proceso de desarrollo de software.
3. Especificaciones y requisitos de software.
4. Diseiio e implementaci6n de software.
5. Verificaci6n y validaci6n.
A LA CUARTA E D I C I ~ N
PR~LOGO EN ESPANOL
En Espaiia, el Consejo de Universidades, organism0 encargado de dictar directrices y nor-

mas para 10s planes de estudios de las universidades tiene redactadas las normativas que han
de cumplir todas las universidades que deseen impartir las carreras de Ingenieria en Informa-
tics (cinco afios acadCmicos, diez semestres), Ingenieria TCcnica en Informatica de Sistemas e
Ingenieria TCcnica en Informatica de Gestion (tres afios academicos, seis semestres) y se publi-
can oficialmente en el Boletin Oficial del Estado (BOE). En estas normativas de obligado cum-
plimiento por todas las universidades, se incluyen las materias (asignaturas o conjunto de
asignaturas) troncales que se deben incluir obligatoriamente en todos 10s planes de estudios,
ademas de otras asignaturas con caracter obligatorio y opcional que cada universidad fija en
sus planes de estudios.
Ingenieria del Software es una materia troncal incluida en las carreras citadas. 18 crCditos
(cada crCdito equivale a diez horas de clase) en la ingenieria superior (ingeniero informatico)
y 12 creditos en la ingenieria tCcnica de informatica de gestion (ingeniero ttcnico informcitico).
Esto significa una carga lectiva considerable que todos 10s estudiantes de carreras de informa-
tics y de computacih han de estudiar, normalmente en 10s cursos 3.' a 5."
Este libro puede ser utilizado en diferentes tipos de cursos de ingenieria de software tanto a
nivel universitario como a nivel profesional:
1. Cursos introductorios de Ingenieria del Software. Estudiantes de primer ciclo (tres aiios)
y segundo ciclo (cinco afios), o en carreras de cuatro aiios (corno suele ser el caso de las
universidades hispanoamericanas y alguna espafiola), sin experiencia previa en Ingenie-
ria del Software, per0 con formacion de dos o tres cursos universitarios (cuatro o cinco
semestres) a1 menos.
2. Cursos introductorios y de nivel medio sobre temas especificos de Ingenieria del Soft-
ware tales como analisis de requisitos y especificaciones, gestion de proyectos de soft-
ware, mCtodos convencionales de Ingenieria del Software, etc.
3. Cursos avanzados en temas de Ingenieria del Software tales corno: analisis y disefio orien-
tados a objetos, mCtricas, ingenieria inversa, Cliente/Servidor, Reutilizacion de software,
etcktera.
Este libro explica todos 10s temas incluidos en la asignatura o materia troncal Ingenieria de2
Software por el Consejo de Universidades de Espaiia, asi como las unidades SE2 a SE5 (la uni-
dad SE1 se refiere a conceptos de tipo general que suelen incluirse en otras asignaturas bisi-
cas) del cum'culum de la ACM/IEEE de 1991. Por nuestro conocimiento personal (conferencias,
cursillos, estancias ...) de muchas universidades hispanoarnericanas, nos consta que 10s planes
de estudio de estas universidades incluyen tambiCn asignaturas de tipo obligatorio de Ingenie-
ria del Software que siguen prkticamente las recomendaciones de ACM/IEEE y son muy simi-
lares a 10s programas que se siguen tambien en EspaAa.
La obra actual incluye gran cantidad de siglas y acr6nimos en inglCs, la mayoria de las cuales,
exceptuando las ya acreditadas en inglCs como BPR ..., se han traducido a1 espaiiol. Por su espe-
cial importancia y la gran cantidad de ellas incluidas en el libro, el equipo de traduccion decidi-
mos recopilar todas las siglas en ingles y sus traducciones a1 espaiiol; a continuaci6n se ha construido
dos tablas ordenadas alfabkticamente en inglCs y en espaiiol, con el objetivo principal de que el
lector pueda localizar facilmente cualquiera de las siglas que aparecen en el texto, y en su caso,
la traduccion a1 espaiiol. Estas tablas se presentaron a la editora de la obra que tras ver el servicio
que proporcionaba a1 lector, acepto incluirlas como ApCndice. De este modo, el lector podra com-
probar en cualquier momento entradas de siglas tanto en espaiiol como en inglCs.
La traduccion de esta obra ha sido un esfuerzo comun que hemos realizado profesores de dife-
rentes universidades espafiolas e hispanoamericanas -profesores de Ingenieria del Software
que hemos utilizado, en la mayoria de 10s casos, las ediciones anteriores de esta obra como libro
de referencia en nuestras clases y continuaremos utilizfindolo. Por esta circunstancia, hemos
P R 6 L O G O A LA CUARTA EDICI6N EN ESPAROL
podido apreciar que esta cuarta edicion ha mejorado de mod0 muy notable a las ediciones ante-
riores y tenemos el convencimiento de que 10s principios y conceptos considerados en ella,
seguiran teniendo una influencia considerable en numerosos estudiantes de ingenieria, licen-
ciatura informatica o sistemas computacionales de habla espafiola, como nos consta que siguen
influyendo en el mundo de habla inglesa. Estamos seguros de que seran muchos 10s estudian-
tes que seguirhn formandose en Ingenieria del Software con este libro como referencia funda-
mental.
Esta cuarta edici6n llena numerosas lagunas en la literatura de habla espafiola, ya que actua-
liza 10s contenidos tradicionales de la Ingenieria del Software y 10s extiende a 10s temas avan-
zados modemos que ya hemos considerado. El excelente trabajo de Roger S. Pressman permitid
seguir formando numerosos y buenos profesionales de Ingenieria del Software para que esta
industria pueda seguir desarrollandose.
Madrid, septiembre de 1997
Luis Joyanes Aguilar

Director del Departamento de Lenguajes y Sistemas Informciticos
e Ingenieria del Software
Facultad de Informatica y Escuela Universitaria de Informatica
Universidad Pontificia de Salamanca. Campus de Madrid
L siglo xxr se enfrenta a la creciente implantaci6n de la sociedad del conocimiento. La
E era del conocimiento en que vivimos no s610 esta cambiando la sociedad en si misma,
sin0 que 10s nuevos modelos de negocios requieren la reformulaci6n de nuevos con-
ceptos. Conocimiento, activos intangibles, Web, etc., son algunos de 10s tkrminos mas utiliza-
dos en cualquier ambiente o negociaci6n. Esta era del conocimiento requiere de nuevas tendencias
apoyadas precisamente en el conocimiento. La ingenieria del software no es una excepcion, y
por ello se requiere no s610 una actualizaci6n de conceptos, sino tambien una comprensi6n y
una formulaci6n del nuevo conocimiento existente en torno a las nuevas innovaciones y teo-
rias de dicha disciplina.
En cada edicion de su clasica obra, Roger Pressman nos tiene acostumbrados a la sorpresa
y a la admiracion por la clara y excelente exposicion de 10s temas tratados. Esta vez tampoco
ha sido una excepcion, muy al contrario, Pressman da la sensacion de haber conseguido {{la
cuadratura del circulo>>o mejor aun, ha encontrado la piedra filosofal para formar y educar a
10s actuales y -sobre tod- futuros ingenieros de software del futuro (o a 10s ingenieros infor-
mliticos e ingenieros de sistemas y licenciados en informlitica que se forman en esta disciplina).
En esla quinta edicion, Pressman proporciona al lector una ingente cantidad de conocimiento
relativo a ingenieria del software que facilitara considerablemente su formacion con todo el
rigor profesional y cientifico que requiere la nueva era del conocimiento que viviremos en esta
decada.
EL NUEVO CONTENIDO
Una de las grandes y atractivas novedades de esta quinta edicion es su nuevo formato y estilo.
El SEPA 512, como se le conoce en la versi6n en ingles, ha mejorado el libro y lo ha hecho mis
legible y atractivo a1 lector. Mediante iconos y una lista normalizada de seis cuestiones clave,
Pressman va guiando a1 lector sobre 10s temas mas importantes de cada capitulo a la vez que
su lectura le introduce paulatina e inteligentemente en las ideas y conceptos mas importantes.
Esta quinta edicion contiene todos 10s temas importantes de la cuarta edicion e introduce una
gran cantidad de temas relativos a las nuevas tendencias, herramientas y metodologias que plan-
tea la ingenieria de software actual y futura, asi como la naciente nueva ingenieria Web. Un
estudio detenido del contenido nos conduce a 10s cambios mas sobresalientes realizados en esta
quinta edicion. que son, entre otros, 10s siguientes:
Cinco nuevos capitulos (Capitulo 14, Disefio arquitectonico; Capitulo 15, Disefio de la
interfaz de usuario, proporcionando reglas de disefio, procesos de modelado de interfaces,
disefio de tareas y metodos de evaluaci6n; Capitulo 16, Disefio a nivel de componentes;
Capitulo 27, examina 10s procesos y la tecnologia de la ingenieria de software basada en
componentes, y, Capitulo 29, que presenta 10s nuevos conceptos de Ingenieria Web (proce-
sos WebE, analisis y formulaci6n de aplicaciones Web, es decir arquitectura, navegaci6n y
disefio de interfaces, pruebas y aplicaciones Web y gesti6n de proyectos de ingenieria Web).
Gran cantidad de actualizaciones y revisiones de 10s 32 capitulos de su contenido total.
Los cambios clave son numerosos, y 10s mas sobresalientes son:
-Modelos de procesos evolutivos (WinWin) y de ingenieria basada en componentes.
-Nuevas secciones sobre control estadistico de la calidad.
-Modelo de estimaci6n de COCOMO 11.
-Tecnicas a prueba de errores para gestidn de calidad de software (SQA).
-1ngenieria de requisitos.
-El lenguaje unificado de modelado, UML (Unified Modeling Language).
-Nuevas reglas y teoria de calidad de software que siguen la normativa I S 0 9000.
P R ~ L O G OA LA QUINTA E D I C I 6 N EN ESPANOL
NUEVOS RECURSOS DOCENTES Y PROFESIONALES
Si la edicion en papel que tiene el lector en sus manos ya es de por si excelente, el sitio Web
del libro no le queda a la zaga (www.pressman5.com). Este sitio es una de las mejores herra-
mientas de las que pueden disponer estudiantes, profesores y maestros, y profesionales del
mundo del software. Destaquemos algunas.
Recursos de estudiantes
Guia de estudios.
Autotest.
Recursos basados en la Web.
Estudio de casos.
Videos.
Contenidos suplementarios.
Foros para intercambios de mensajes entre lectores.
Recursos de profesores y maestros

Guia del profesor.
Transparencias (acetatos) en Powerpoint.
Bancos de prueba.
Herramientas de ingenieria de software.
Foros de intercambio de mensajes entre colegas.
Recursos profesionales
Plantillas de productos de documentos y de trabajos.
Listas de pruebas de ingenieria de software.
Herramientas de ingenieria de software.
Herramientas CASE.
Recursos de ingenieria de software.
Modelos de procesos adaptables.
Curriculum de videos de calidad para la industria.
Comentarios de la industria.
Foros profesionales.
Una de las caracteristicas mas sobresalientes de esta obra es que recoge con gran profusion la
ingente cantidad de siglas que hoy dia se utilizan en la industria del software junto a otras muchas
mas acufiadas por el propio autor.
El equipo de profesores que ha traducido y adaptado la versi6n en inglCs de comun acuerdo
con la editora acord6 realizar un apkndice que incluyera todas las siglas incluidas en el libro y
las traducciones correspondientes en espafiol, y viceversa. Este apCndice busca, a1 igual que ya
se hiciera en la segunda edici6n en espafiol, facilitar a1 lector la lectura y seguimiento del mod0
m8s facil posible y que le permita hacer la correspondencia entre ambos idiomas cuado lo nece-
site. Por ello, este apCndice contiene un diccionario inglCs-espafiol y otro espafiol-inglCs de
siglas. El mCtodo que se ha seguido durante la traducci6n ha sido traducir pricticamente todas
las siglas, y s610 se han realizado algunas excepciones, como SQA (Software Quality Assure-
ment) por su uso frecuente en la jerga inform8tica, aunque en este caso hemos utilizado ambos
tCrminos (en inglCs, SQA y en espafiol, GCS, Gesti6n de Calidad del Software). En este caso,
estas siglas en espafiol coinciden con Gestion de Configuraci6n del Software (GCS), por lo que
a veces estas siglas se han traducido por GCVS (Gesti6n de Configuraci6n de Versiones de Soft-
P R 6 L O G O A LA QUINTA E D I C I ~EN
N ESPANOL
ware) para evitar duplicidades. ~ s t es

a una de las razones fundamentales por la que hemos
incluido el glosario de siglas.
EL EQUIP0 TRADUCTOR
La edicion britanica ha sido adaptada por un prestigioso profesor britanico, y la edici6n y la

adaptacion espaiiolas han sido realizadas por un numeroso equipo de profesores del Departa-
menro de Lenguajes y Sistemas Informciticos e Ingenieria del Software de la Facultad de Infor-
mcirica y Escuela Universitaria de Informcitica de la Universidad Pontificia de Salamanca
(Espana) del campus de Madrid, que ha contado con la inestimable colaboraci6n de profeso-
res del prestigioso Instituto Tecnologico (TEC) de Monterrey, de su campus de QuerCtaro
(MCxico). Una obra de la envergadura de esta quinta edicion requeria +om0 ya sucedi6 tam-
bien en la edici6n anterior- del trabajo y coordinacion de numerosas personas. Muchas han
sido las horas dedicadas a la traduccih, adaptacion y sucesivas revisones de galeradas de las
pruebas de imprenta. Confiamos haber cumplido nuestra obligaci6n con dignidad y profesio-
nalidad.
EL FUTURO ANUNCIADO
Esta quinta edicion ha sido actualizada sustancialmente con nuevos materiales que reflejan el
estado del arte de la ingenieria del software. El material obsoleto se ha eliminado de esta edi-
ci6n para crear un texto facil de leer y entender, y totalmente actualizado. Sin embargo, y con
ser importante todo su vasto y excelente contenido, queremos destacar que esta nueva edicion
nos brinda y abre el camino a1 futuro que seiiala la moderna ingenieria de software basada en
objetos y componentes, asi como a la ingenieria Web, consemando el rigor y la rnadurez de las
teorias ya clasicas de la ingenieria del software.
Sin lugar a dudas, Pressman ha conseguido una excelente obra, y en una prueba clara de pro-
fesionalidad y excelencia ha logrado superar sus cuatro ediciones anteriores ya de por si exce-
lentes.
Madrid y Carchelejo (Esparia),verano de 2001
Luis Joyanes Aguilar

Director del Departamento de Lenguajes, Sistemas informciticos e Ingenieria de Software
Facultad de Inforrn~tica/EscuelaUniversitaria de Inforrnatica
Universidad Pontificia de Salamanca campus Madrid
L
A quinta edicion de Ingenieria del Sofmare: Un Enfoque Practico se ha vuelto a disefiar para aumentar la
experiencia del lector y para proporcionar enlaces integrados a1 sitio Web, http://www.pressman5.com.
Dentro de este sitio 10s lectores encontraran informacion complementaria util y rica, y una gran cantidad
de recursos para 10s instructores que hayan optado por este libro de texto en clase.
A lo largo de todo el libro se van encontrando iconos que deberh interpretarse de la siguiente manera:
El icono de punto clave ayudara El icono Referencia web propor-

a encontrar de forma rapida 10s ciona punteros directos a sitios
puntos importantes. Web importantes relacionados con
Utilizodo poro enforizor un punto impr- la ingenieria del software.
tonte en el cuerpo del texto. Poro punteros que conducirbn
directomente o los recursos de lo Web.
El icono de consejo proporciona

QONSWOs una guia pragmatics que serviri de El icono de sitio Web indica que
ayuda para tomar la decision ade- se dispone de mas informacion
Un consejo practico del mundo red opli
cuada o evitar 10s problemas tipi- sobre el tenia destacado en el sitio
lo ingenierio delsohore,
cos a1 elaborar software. L Web SEPA.
Un temo seleccionodo.
El icono de signo de interroga-

iEn donde puedo cion formula preguntas que se res-
larespuesta? ponderin en el cuerpo del texto.
El icono de lista de comproba-
ci6n nos sefiala las listas de com-
probacion que ayudan a evaluar el
trabajo de ingenieria del software
que se esta llevando a cab0 y 10s
productos del trabajo.
El icono de referencia cruzada Listo de comprobocion
nos conducira a alguna otra parte
tante dento del libro
del texto en donde se podra encon-
trar informaci6n relevante sobre
el tema en cuestion.
El icono de documento nos sefia-

la 10s bocetos, descripciones y
ejemplos de documentos del sitio
El icono de cita presenta citas Web SEPA.
interesantes que tienen gran rele-
vancia para 10s temas que se estCn
antes
tratando. Documento
Palabras c l a v e
L
AS alarmas comenzaron mris de una dCcada antes del acontecimiento. Con menos de
cara<teristicas dos aiios a la fecha seiialacla, 10s medios de comunicaci6n recogieron la historia. Los
del software.. ....... 5 oficiales del gobierno expresaron su preocupaci6n,los directores cle la industria y de 10s
categorias negocios cornprometieron grandes canticlades de dinero, y por hltimo, las advertencias horri-
de aplicadon ......... 7 b l e ~de catristrofe llegaron a la conciencia del pliblico. El software, al igual que el ahora famoso
curmas error Y2K, podria fallar, y como resultado, detener el mundo conio nosotros lo conocimos.
de fallos. ............6 Como vimos durante 10s hltimos meses del aiio 1999, sin cluerer, no puedo dejar de pen-
desgaste.. ..........
.5 sar en el prirrafo prof6tico contenido en la primera prigina de la cuarta edici6n cle este libro.
ensamblaie Decia:
de componentes ......6 El software de cornpu~adorase ha convcrtido en el cll~ncrnlcr/or.. Es la rnhquina que conduce a la toma
historia.. ............ 4 dc decisiones comel&les. Sirvc de base pim la investigation cien~ilicamoderna y dc resolucion de pro-
blernas de ingenieria. Es el factor clave que difercncia 10s productos y servicios modcmos. EstL inrnerso en
ingenieria sistenias dc todo tipo: dc lransportes, rnddicos. de telecomunicaciones, militares, procesos industriales, entre-
del software ......... 4 ~enimientos,protlnctos de oficina .... la liste es caxi interminable. El software cs ca\i ineludible en un mun-
mitos. ............... 8 do moderno. A ~neditlaque nos ndentrernos en cl siglo xxr, scri cl quc nos conduzca a nue\/os wanccs cn
reutilization.. ........6 todo, desdc la etlucaci6n elemenk~ln lo ingenieria genitica.
10s ideas
y 10s descubrirnientos
tecnolhgicos
son 10s conductores
del crecimiento etonbrnico.
The Wall Street Journal
I N G E N I E R f A DEL SOFTWARE. U N ENFOQUE PRACTICO
Hoy en dia el software tiene un doble papel. Es un pro-

ducto y, a1 mismo tiempo, el vehiculo para entregarlo.
Como producto, hace entrega de la potencia informiti- Me introduie en el futuro, m6s all6 de la que el oio
ca que incorpora el hardware informritico o, mlis amplia- humano puede ver. Twe ma visidn del mundo
mente, una red de computadoras que es accesible por y todo lo moravilloso que podria ser.
hardware local. Si reside dentro de un telCfono celular Tennyroa
u opera dentro de una computadora central, el softwa-
re es un transformador de informaci6n, produciendo,
gestionando, adquiriendo, modificando, mostrando o las computadoras y el software nos llevaran a la ccdemo-
transmitiendo informacidn que puede ser tan simple cratizacion del conocimienton. A Yourdon [YOU921 le
como un solo bit, o tan complejo como una presenta- preocupaba que las compafiias en Estados Unidos pudie-
ci6n en multimedia. Como vehiculo utilizado para hacer ran perder su competitividad en empresas relativas a1
entrega del producto, el software actda como la base de software y predijo ccel declive y la caida del programa-
control de la computadora (sistemas operativos), la dor americano>>.Hammer y Champy [HAM931 argu-
comunicaci6n de information (redes) y la creacion y mentaron que las tecnologias de informaci6n iban a
control de otros programas (herramientas de software desempefiar el papel principal en la ccreingenieria de la
y entornos). compafiian. A mediados de 10s afios 90, la persistencia de
las computadoras y del software genero una erupci6n de
libros por ccneo-Luddites>>(por ejemplo: Resisririg the Vir-
t~uilLife, editado por James Brook y Ian Boal, y The F L I ~ U -
re Does not Compute de Stephen Talbot). Estos autores
Elsoftware es tonto un producto, critican enormemente la computadora, haciendo Cnfasis
como el vehiculo para su entrego en preocupaciones legitimas per0 ignorando 10s profun-
dos beneficios que se han llevado a cab0 [LEV95].
El papel del software informitico ha sufrido un cam-
bio significativo durante un period0 de tiempo superior
a 50 afios. Enormes mejoras en rendimiento del hard- 10s computadoroshacen las cosas m6s fkles,
ware, profundos cambios de arquitecturas informiticas, pero lo mayoria de las cosos que fociliton no
grandes aumentos de memoria y capacidad de almace- es precis0 hocerlos.
namiento y una gran variedad de opciones de entrada y Andy Rooney
salida han conducido a sistemas mis sofisticados y mris
complejos basados en computadora. La sofisticacion y Al final de 10s afios 90, Yourdon [YOU961 volvi6 a
la complejidad pueden producir resultados deslum- evaluar las perspectivas del software profesional y sugi-
brantes cuando un sistema tiene exito, per0 tambiCn pue- rio la ccresu1recci6ny elevaci6n~del programador ame-
den suponer grandes problemas para aquellos que deben ricano. A medida que internet creci6 en importancia, su
construir sistemas complejos. cambio de pensamiento demostr6 ser correcto. Al final
Libros populares publicados durante 10s afios 70 y 80 del siglo veinte, el enfoque cambi6 una vez mris. Aqui
proporcionan una vision hist6rica btil dentro de la per- tuvo lugar el impacto de la ccbomba de relojeriau Y2K
cepe1611calnbiante de las computadoras y del software, (por ejemplo: [YOU98b], [DEJ98], [KAR99]). Aunque
y de su impacto en nuestra cultura. Osborne [OSB791 niuchos vieron las yredicciones de 10s criticos del Y2K
hablaba de una ccnueva revoluci6n industrial>>.Toffler con10 reacciones, sus populares lecturas devolvieron la
[TOF80] llamo a la llegada de componentes microelec- difusi6n del software a sus vidas. Hoy en dia, ccla com-
tr6n1co\ la cctercera ola del cambim en la historia de la putacidn omnipresente>>[NOR981 ha producido una gene-
humanidad, y Naisbitt [NAB21 predijo la transformaci6n raci6n de aplicaciones de informaci6n que tienen
de la sociedad industrial a una ccsociedad de informa- conexi6n en banda ancha a la Web para proporcionar
c i 6 n ~Feigenbaum
. y McCorduck [FEI83] sugirieron que ccuna capa de conexi6n sobre nuestras c a m , oficinas, y
la informaci6n y el conocimiento (controlados por com- autopistaw [LEV99]. El papel del software continba su
putadora) seriim el foco de poder tlel siglo veintiuno, y expansi6n.
Stoll [ST0891 argument6 que la cccomunidad electr6ni- El programador solitario de antafio ha sido reempla-
can c~c:tdamediante redes y software es la clave para el zado por un equipo de especialistas del software, cada uno
intercambio de conocimiento alrededor del mundo. centrado en una parte de la tecnologio requerida para entre-
A1 comienzo de 10s afios 90. Toffler [TOF9O] d e w - gar una aplicaci6n concreta. Y de este modo, las cuestio-
bi6 un cccambio de poder>>en el que la\ v~ejasestructu- nes que se pregimtaba el programador solitario son las
ras de pocler (gubernamentales, educat~va\,industrialea, mismas cuestiones que nos preguntamos cuando cons-
econ6mlcas y militares) se desintegrarian a medida que truimos sistemas modernos basados en computadoras:
CAPITULO 1 EL P R O D U C T 0 Y EL P R O C E S O
~ P oquC
r lleva tanto tiempo terminar 10s programas?
LPor quC son tan elevados 10s costes de desarrollo?
LPor quC no podemos encontrar todos 10s errores
antes de entregar el software a nuestros clientes?
d L
LPor quC nos resulta dificil constatar el progreso con-
Estodisticos globoles de software forme se desarrolla el software?
En 1970, menos del uno por ciento de las personas Los costes del software se encuentran en la ingenieria.
podria haber descrito inteligentemente lo que significa- Esto significa que 10s proyectos de software no se pueden
ba ccsoftware de computadora>>. Hoy, la mayoria de 10s gestionar como si fueran proyectos de fabricacion.
profesionales y muchas personas en general piensan en
su mayoria que comprenden el software. ~ P e r olo entien- 2. El software no se ccestropea)).
den realmente? La Figura 1.1 describe, para el hardware, la proporcion
de fallos como una funcion del tiempo. Esa relacion, deno-
minada frecuentemente cccurva de bafiera>>, indica que el
1.2.1. Caracteristicas del software hardware exhibe relativamente muchos fallos a1 princi-
Para poder comprender lo que es el software (y con- pio de su vida (estos fallos son atribuibles normalmente
secuentemente la ingenieria del software), es impor- a defectos del disefio o de la fabricaci6n); una vez corre-
tante examinar las caracteristicas del software que lo gidos 10s defectos, la tasa de fallos cae hasta un nivel esta-
diferencian de otras cosas que 10s hombres pueden cionario (bastante bajo, con un poco de optimismo) donde
construir. Cuando se construye hardware, el proceso permanece durante un cierto period0 de tiempo. Sin
creativo humano (anidisis, disefio, construccion, prue- embargo, conforme pasa el tiempo, el hardware empie-
ba) se traduce finalmente en una forma fisica. Si cons- za a desgastarse y la tasa de fallos se incrementa.
truimos una nueva computadora, nuestro boceto El software no es susceptible a 10s males del entor-
inicial, diagramas formales de disefio y prototipo de no que hacen que el hardware se estropee. Por tanto, en
prueba, evolucionan hacia un product0 fisico (chips, teoria, la curva de fallos para el software tendria la for-
tarjetas de circuitos impresos, fuentes de potencia, ma que muestra la Figura 1.2. Los defectos no detecta-
etc.). dos haran que falle el programa durante las primeras
El software es un elemento del sistema que es etapas de su vida. Sin embargo, una vez que se corri-
16gic0, en lugar de fisico. Por tanto el software tie- gen (suponiendo que no se introducen nuevos errores)
ne unas caracteristicas considerablemente distintas la curva se aplana, como se muestra. La curva ideali-
a las del hardware: zada es una gran simplificacion de 10s modelos reales
de fallos del software (vease miis informacion en el
Capitulo 8). Sin embargo la implicacion es clara, el soft-
ware no se estropea. iPero se deteriora!
El softwore se desorrollo, nose fobrico.
I . El software se desarrolla, El softwore no se estropeo, pero se deterioro.

no se fabric0 en un sentido cliisico
Aunque existen similitudes entre el desarrollo del soft-
ware y la construcci6n del hardware, ambas activida-
des son fundamentalmente diferentes. En ambas
Mortalidad Se estropea
actividades la buena calidad se adquiere mediante un V)
-
buen disefio, per0 la fase de construccion del hard- m
C
w
ware puede introducir problemas de calidad que no u
w
existen (o son fhcilmente corregibles) en el software. .-
u
Ambas actividades dependen de las personas, per0 la .-
relacion entre las personas dedicadas y el trabajo rea-
. lizado es completamente diferente para el software
(vCase el Capitulo 7). Ambas actividades requieren I *
Tiernpo
la construcci6n de un ccproducton per0 10s enfoques
son diferentes. FIGURA 1.1. Curva de fallos del hardware.
Esto que parece una contradiccion, puede compren- A medida que la disciplina del software evoluciona, se
.derse mejor considerando <<lacurva actual>>mostrada en crea un grupo de componentes de disefio estindar. Tomi-
la Figura 1.2. Durante su vida, el software sufre cambios 110s esthdar y circuitos integrados preparados para la ven-
(mantenimiento). Conforme se hacen 10s cambios, es ta son solamente 10s dos mil componentes esthdar que
bastante probable que se introduzcan nuevos defectos, utilizan ingenieros mecanicos y elCctricos cuando dise-
haciendo que la curva de fallos tenga picos como se ve iian nuevos sistemas. Los componentes reutilizables se
en la Figura 1.2. Antes de que la curva pueda volver a1 han creado para que el ingeniero pueda concentrarse en
estado estacionario original, se solicita otro cambio, elementos verdaderarnente innovadores de un disefio, por
haciendo que de nuevo se Cree otro pico. Lentamente, el ejemplo, las partes del disefio que representan algo nue-
nivel minimo de fallos comienza a crecer --el software vo. En el mundo del hardware, la reutilizaci6n de com-
se va deteriorando debido a 10s cambios-. ponentes es una parte natural del proceso de ingenieria.
Otro aspect0 de ese deterioro ilustra la diferencia entre En el mundo del software es algo que solo ha comenza-
el hardware y el software. Cuando un componente de do a lograrse en una escala amplia.
hardware se estropea se sustituye por una pieza de repues- El componente de software deberia disefiarse e
to. No hay piezas de repuesto para el software. Cada fa110 implementarse para que pueda volver a ser reutiliza-
en el software indica un error en el disefio o en el procedo en muchos programas diferentes. En 10s afios 60,
so mediante el que se tradujo el disefio a codigo mfiqui- se construyeron bibliotecas de subrutinas cientificas
na ejecutable. Por tanto, el mantenimiento del software reutilizables en una amplia serie de aplicaciones cien-
tiene una complejidad considerablemente mayor que la tificas y de ingenieria. Esas bibliotecas de subrutinas
del mantenimiento del hardware. reutilizaban de forma efectiva algoritmos bien defi-
nidos, pero tenian un doniinio de aplicacion limita-
3. Aunquc la industria tiende u cnsanzhlur cumpunen- do. Hoy en dia, hemos extendido nuestra vision de
t ~ sIu, mavoriu del sofhvam se construye a meclida. reutilizacion para abarcar no so10 10s algoritmos, sino
Consideremos la forma en la que se diseiia y se cons- tambiCn estructuras de datos. Los componentes reu-
truye el hardware de control para un product0 basa- tilizables modernos encapsulan tanto datos como pro-
do en computadora. El ingeniero de disefio construye cesos que se aplican a 10s datos, permitiendo a1
un sencillo esquema de la circuiteria digital, hace ingeniero del software crear nuevas aplicaciones a
algun anlilisis fundamental para asegurar que se con- partir de las partes reutilizables. Por ejemplo, las
sigue la funcion adecuada y va al armario donde se interfaces griificas de usuario de hoy en dia se cons-
encuentran los cathlogos de componentes digitales. truyen frecuentemente a partir de componentes reu-
Despu6s de seleccionar cada componente, puede soli- tilizables que permiten la creacion de ventanas
citarse la compra. griificas, de menus despleglables y de una amplia
variedad de mecanisnlos de interaccion.
Increment0
del indice de fallos
La mayori~delsoftwore sigue construyendose a medida.
1.2.2. Aplicaciones del software

El software puede aplicarse en cualquier situation en la
que se haya definido previamente un conjunto especi-
fico de pasos procedimentales (es decir, un algoritmo)
(excepciones notables a esta regla son el software de
10s sistemas expertos y de redes neuronales). El conte-
- nido y el determinism0 de la informacion son factores
Tiernpo importantes a considerar para determinar la naturaleza
de una aplicacion de software. El contenido se refiere
FIGURA 1.2. Curvas de fallos real e idealizada del software. a1 significado y a la forma de la informacion de entra-
da y salida. Por ejemplo, muchas aplicaciones banca-
rias usan unos datos de entrada muy estructurados (una
base de datos) y producen <<informes>> con determina-
dos formatos. El software que controla una maquina
automatica (por ejemplo: un control numCrico) acepta
10srnetodos de ingenieria de software se esfuerzan elementos de datos discretos con una estructura limita-
para reducir la magnitud de 10s picos y la inclinaci6n da y produce ordenes concretas para la miiquina en rapi-
de la curvo (Fig. 1.2). da sucesi6n.
CAPfTULO 1 EL PRODUCT0 Y EL PROCESO
Software de gestion. El proceso de la informacion

La revalucibn d d software se trata en el Capitulo 13. comercial constituye la mayor de las areas de aplica-
La ingenieria de saftware basoda en componentes cion del software. Los ccsistemas>>discretos (por ejem-
se presenta en el Caphula 27. plo: nominas, cuentas de haberes-dkbitos, inventarios,
etc.) han evolucionado hacia el software de sistemas de
inf&naci6n de gestion (SIG) que accede a una o mas
El determinism0 de la informacidn se refiere a la pre- bases de datos que contienen informacion comercial.
decibilidad del orden y del tiempo de llegada de 10s Las aplicaciones en esta area reestructuran 10s datos
datos. Un programa de analisis de ingenieria acepta datos existentes para facilitar las operaciones comerciales o
que estan en un orden predefinido, ejecuta el algorit- gestionar la toma de decisiones. Ademas de las tareas
mo(s) de analisis sin interrupcion y produce 10s datos convencionales de procesamientos de datos, las aplica-
resultantes en un informe o formato grafico. Se dice que ciones de software de gestion tambiCn realizan calculo
tales aplicaciones son determinadas. Un sistema opera- interactivo (por ejemplo: el procesamiento de transac-
tivo multiusuario, por otra parte, acepta entradas que ciones en puntos de ventas).
tienen un contenido variado y que se producen en ins-
tantes arbitrarios, ejecuta algoritmos que pueden ser Software de ingenieria y cientifico. El software
interrumpidos por condiciones extemas y produce una de ingenieria y cientifico esta caracterizado por 10s
salida que depende de una funcion del entorno y del algoritmos de ccmanejo de numeros>>.Las aplicacio-
tiempo. Las aplicaciones con estas caracteristicas se dice nes van desde la astronomia a la vulcanologia, desde
que son indeterminadas. el analisis de la presion de 10s automotores a la dina-
mica orbital de las lanzaderas espaciales y desde la
Algunas veces es dificil establecer categorias genC-
biologia molecular a la fabricacion automatics. Sin
ricas para las aplicaciones del software que sean sig-
embargo, las nuevas aplicaciones del area de inge-
nificativas. Conforme aumenta la complejidad del
nierialciencia se han alejado de 10s algoritmos con-
software, es mas dificil establecer compartimentos
vencionales numCricos. El disefio asistido por
nitidamente separados. Las siguientes areas del soft-
computadora (del inglCs CAD), la simulacion de sis-
ware indican la amplitud de las aplicaciones poten-
temas y otras aplicaciones interactivas, han comen-
ciales:
zado a coger caracteristicas del software de tiempo
Software de sistemas. El software de sistemas es real e incluso del software de sistemas.
un conjunto de programas que han sido escritos para Software empotrado. Los productos inteligentes se
servir a otros programas. Algunos programas de siste- han converticio en algo comun en casi todos 10s merca-
mas (por ejemplo: compiladores, editores y utilidades dos de consumo e industriales. El software empotrado
de gestion de archivos) procesan estructuras de infor- reside en memoria de so10 lectura y se utiliza para con-
macion complejas per0 determinadas. Otras aplicacio- trolar productos y sistemas de 10s mercados industria-
nes de sistemas (por ejemplo: ciertos componentes del les y de consumo. El software empotrado puede ejecutar
sistema operativo, utilidades de manejo de perifkricos, funciones muy limitadas y curiosas (por ejemplo: el con-
procesadores de telecomunicaciones) procesan datos en trol de las teclas de un horno de microondas) o sumi-
gran medida indeterminados. En cualquier caso, el area nistrar una funcion significativa y con capacidad de
del software de sistemas se caracteriza por una fuerte control (por ejemplo: funciones digitales en un auto-
interaccion con el hardware de la computadora; una gran movil, tales como control de la gasolina, indicadores en
utilization por multiples usuarios; una operacion con- el salpicadero, sistemas de frenado, etc.).
currente que requiere una planificacion, una comparti-
cion de recursos y una sofisticada gestion de procesos;
unas estructuras de datos complejas y multiples inter-
faces extemas.
Software de tiempo real. El software que coor-
dina/analiza/controla sucesos del mundo real conforme
ocurren, se denomina de tiempo real. Entre 10s elemen-
3
Referencia Web
Se puede encontrar una de Ins mayores bibliotecas
de shorewore/freewore en www.shareware.com
tos del software de tiempo real se incluyen: un compo-
nente de adquisicion de datos que recolecta y da formato
a la informacion recibida del entomo extemo, un com- Software de computadoras personales. El mercado
ponente de analisis que transforma la informacion segun del software de computadoras personales ha germinado
lo requiera la aplicacion, un componente de controllsalida en las pasadas dos dCcadas. El procesamiento de tex-
que responda a1 entorno externo, y un componente de tos, las hojas de calculo, 10s graficos por computadora,
monitorizacion que coordina todos 10s demas compo- multimedia, entretenimientos, gestion de bases de datos,
nentes, de forma que pueda mantenerse la repuesta en aplicaciones financieras, de negocios y personales y
tiempo real (tipicamente en el rango de un milisegundo redes o acceso a bases de datos externas son algunas de
a un segundo). 10s cientos de aplicaciones.
INGENIERiA DEL SOFTWARE. U N E N F O Q U E P R A C T I C O
Software basado en Web. Las piginas Web busca- Software de inteligenciaartificial. El software de inte-
das por un explorador son software que incorpora ins- ligencia artificial (IA) hace uso de algoritrnos no numkri-
trucciones ejecutables (por ejemplo, CGI, HTML, Perl, cos para resolver problemas complejos para 10s que no son
o Java), y datos (por ejemplo, hipertexto y una varie- adecuados el cdculo o el adisis directo. Los sistemasexper-
dad de formatos de audio y visuales). En esencia, la red tos, tarnbikn llamados sistemas basados en el conocimiento,
viene a ser una gran computadora que proporciona un reconocimiento de patrones (imiigenes y voz), redes neu-
recurso software casi ilimitado que puede ser accedido ronales artificiales, prueba de teoremas, y 10s juegos son
por cualquiera con un modem. representatives de las aplicaciones de esta categoria.
Muchos observadores de la industria (incluyendo este computadoras, no ha habido ningun ccpunto crucial>>, nin-
autor) han caracterizado 10s problemas asociados con el g h ccmomento decisive>>, solamente un lento cambio evo-
desarrollo del software como una cccrisis>.Mis de unos lutivo, puntualizado por cambios tecnologicos explosivos
cuantos libros (por ejemplo: [GLA97], [FL097], en las disciplinas relacionadas con el software.
[YOU98a]) han recogido el impact0 de algunos de 10s Cualquiera que busque la palabra crisis en el dic-
fallos mas importantes que ocurrieron durante la dCca- cionario encontrari otra definicion: ccel punto decisivo
da pasada. No obstante, 10s mayores Cxitos conseguidos en el curso de una enfermedad, cuando se ve rnis claro
por la industria del software han llevado a preguntarse si el paciente vivira o morirh. Esta definicion puede
si el tCrmino (crisis del software) es a6n apropiado. darnos una pista sobre la verdadera naturaleza de 10s
Robert Glass, autor de varios libros sobre fallos del soft- problemas que han acosado el desarrollo del software.
ware, representa a aquellos que han sufrido un cambio Lo que realmente tenemos es una afliccion cr6nica1.
de pensamiento. Expone [GLA98]: ccPuedo ver en mis La palabra ajliccibn se define como ccalgo que causa pena
ensayos historicos de fallos y en mis informes de excep- o desastre.. Pero la clave de nuestro argument0 es la defi-
c i h , fallos importantes en medio de muchos Cxitos, una nici6n del adjetivo crcinica: ccmuy duradero o que reapa-
copa que esti [ahora] priicticamente 1lena.n rece con frecuencia continuando indefinidarnente,,. Es
bastante rnis precis0 describir 10s problemas que hemos
estado aguantando en el negocio del software como una
afliccion cronica, en vez de como una crisis.
Sin tener en cuenta como lo Ilamemos, el conjunto
de problemas encontrados en el desarrollo del software
de computadoras no se limitan a1 software que ccno fun-
ciona correctamenten. Es mis, el ma1 abarca 10s pro-
blemas asociados a c6mo desarrollar software, como
mantener el volumen cada vez mayor de software exis-
tente y como poder esperar mantenernos a1 corriente de
La palabra crisis se define en el diccionario Webster la demanda creciente de software.
como a n punto decisivo en el curso de algo, momento, Vivimos con esta afliccion desde este dia - d e hecho,
etapa o evento decisivo o crucial>>. Sin embargo, en tCrmi- la industria prospera a pesar de ell-. Y asi, las cosas
nos de calidad del software total y de velocidad con la cud podrin ser mejores si podemos encontrar y aplicar un
son desarrollados 10s productos y 10s sistemas basados en remedio.
Muchas de las causas de la crisis del software se pue- confusion. Los mitos del software tienen varios atribu-
den encontrar en una mitologia que surge durante 10s tos que 10s hacen insidiosos; por ejemplo, aparecieron
primeros afios del desarrollo del software. A diferencia como declaraciones razonables de hechos (algunas veces
de 10s mitos antiguos, que a menudo proporcionaban a conteniendo elementos verdaderos), tuvieron un senti-
10s hombres lecciones dignas de tener en cuenta, 10s do intuitivo y frecuentemente fueron promulgados por
mitos del software propagaron information erronea y expertos que ccestaban a1 dia>>.
Esta terminologia fue sugerida por el profesor Daniel Tiechrow de la

Universidad de Michigan en una conferencia impartida en Ginebra,
Suiza, Abril, 1989.
CAPfTULO 1 EL P R O D U C T 0 Y EL P R O C E S O
Mitos de gestion. Los gestores con responsabilidad Mitos del Cliente. Un cliente que solicita una apli-
sobre el software, como 10s gestores en la mayoria de caci6n de software puede ser una persona del despacho
las disciplinas, estan normalmente bajo la presion de de al lado, un grupo tkcnico de la sala de abajo, el depar-
cumplir 10s presupuestos, hacer que no se retrase el pro- tamento de ventas o una compaiiia exterior que solicita
yecto y mejorar la calidad. Igual que se agarra a1 vacio un software bajo contrato. En muchos casos, el cliente
una persona que se ahoga, un gestor de software se aga- Cree en 10s mitos que existen sobre el software, debido a
rra frecuentemente a un mito del software, aunque tal que 10s gestores y desarrolladoresdel software hacen muy
creencia so10 disminuya la presion temporalmente. poco para corregir la mala informacion. Los mitos con-
Mito. Tenemos ya un libro que esta lleno de estinda- ducen a que el cliente se Cree una falsa expectativa y, final-
res y procedimientos para construir software, jno le pro- mente, quede insatisfecho con el que desarrolla el software.
porciona ya a mi gente todo lo que necesita saber? Mito. Una declaration general de 10s objetivos es sufi-
Realidad. Esta muy bien que el libro exista, per0 ciente para comenzar a escribir 10s programas -pode-
jse usa?.iconocen 10s trabajadores su existencia?, mos dar 10s detalles mas adelante-.
irefleja las practicas modernas de desarrollo de soft- Realidad. Una mala definicion inicial es la principal
ware?, i e s completo?, jest5 disefiado para mejorar el causa del trabajo baldio en software. Es esencial una des-
tiempo de entrega mientras mantiene un enfoque de cripcion formal y detallada del h b i t o de la informacion,
calidad? En muchos casos, la respuesta a todas estas funciones, comportamiento, rendimiento, interfaces, liga-
preguntas es <<no>>. duras del disefio y criterios de validaci6n. Estas caracte-
risticas pueden determinarse so10 despuCs de una
exhaustiva comunicaci6n entre el cliente y el analista.
Mito. Los requisitos del proyecto cambian conti-
nuamente, per0 10s cambios pueden acomodarse ficil-
mente, ya que el software es flexible.
Mito. Mi gente dispone de las herramientas de desa- Lo gestidn y control de combio e s trotado
~
rrollo de software mis avanzadas, despuCs de todo, les con detalle en el Copitulo 9
compramos las computadoras mis modernas.
Realidad. Se necesita mucho mis que el ultimo
modelo de computadora grande o de PC para hacer desa-
rrollo de software de gran calidad. Las herramientas de
ingenieria del software asistida por computadora
(CASE) son mas importantes que el hardware para con-
seguir buena calidad y productividad, aunque la mayo-
ria de 10s desarrolladores del software todavia no las
utilicen eficazmente.
Mito. Si fallamos en la planificacion, podemos afiadir
mis programadores y adelantar el tiempo perdido (el lla-
mado algunas veces ccconcepto de la horda Mongolians,,). Definicion Desarrollo Despues
Realidad. El desarrollo de software no es un procede la entrega
so mecanico como la fabricacion. En palabras de Bro- FIGURA 1.3. El impacto del carnbio.
oks [BR075]: cc ...afiadir gente a un proyecto de software
retrasado lo retrasa aun mas>>. A1 principio, esta declara- Realidad. Es verdad que 10s requisitos del softwa-
cion puede parecer un contrasentido. Sin embargo, cuan- re cambian, per0 el impacto del carnbio varia segun el
do se afiaden nuevas personas, la necesidad de aprender y momento en que se introduzca. La Figura 1.3 ilustra el
comunicarse con el equipo puede y hace que se reduzca la impacto de 10s cambios. Si se pone cuidado a1 dar la
cantidad de tiempo gastado en el desarrollo productivo. definicion inicial, 10s cambios solicitados a1 principio
Puede afiadirse gente, per0 solo de una manera planifica- pueden acomodarse ficilmente. El cliente puede revi-
da y bien coordinada. sar 10s requisitos y recomendar las modificaciones con
relativamente poco impacto en el coste. Cuando 10s cam-
bios se solicitan durante el disefio del software, el impac-
to en el coste crece rapidamente. Ya se han acordado 10s
recursos a utilizar y se ha establecido un marco de tra-
Lo red de gesti6n de proyectos de softwore bajo del disefio. Los cambios pueden producir trastor-
en www.spmn.com puede oyudorle nos que requieran recursos adicionales e importantes
o desrnitificor estos y otros rnitos. modificaciones del disefio; es decir, coste adicional. Los
I N G E N I E R ~ ADEL SOFTWARE. UN ENFOQUE PRACTICO
cambios en la funcibn, rendimiento, interfaces u otras Mito. Hasta que no tengo el programa ccejecutindo-
caractensticas, durante la implementaci6n (codificaci6n se,>,realmente no tengo foma de comprobar su calidad.
y prueba) pueden tener un impact0 importante sobre el Realidad. Desde el principio del proyecto se puede
coste. Cuando se solicitan a1 final de un proyecto, 10s aplicar uno de 10s mecanismos rnis efectivos para garan-
cambios pueden producir un orden de magnitud rnis tizar la calidad del software: la revisidn re'cnica formal.
car0 que el mismo cambio pedido a1 principio. La revisi6n del software (descrito en el Capitulo 8) es
Mitos de los desarrolladores. Los mitos en 10s que un cfiltro de calidad,, que se ha comprobado que es rnis
a h creen muchos desarrolladores se han ido fomen- efectivo que la prueba, para encontrar ciertas clases de
tando durante 50 afios de cultura infomitica. Durante defectos en el software.
10s primeros dias del desarrollo del software, la pro-
Mito. Lo linico que se entrega a1 terminar el pro-
gramaci6n se veia como un arte. Las viejas formas y
yecto es el programa funcionando.
actitudes tardan en morir.
Mito. Una vez que escribimos el programa y hace- Realidad. Un programa que funciona es s610 una par-
mos que funcione, nuestro trabajo ha terminado. te de una configuracidn del software que incluye muchos
elementos. La documentaci6n proporciona el funda-
Realidad. Alguien dijo una vez: cccuanto rnis pronto mento para un buen desarrollo y, lo que es rnis impor-
se comience a escribir c6dig0, rnis se tardari en term- tante, proporciona guias para la tarea de mantenimiento
narlou. Los datos industriales [LIE80, JON91, PUT971 del software.
indican que entre el 60 y el 80 por ciento de todo el
esfuerzo dedicado a un programa se realizari despuCs Muchos profesionales del software reconocen la
de que se le haya entregado a1 cliente por primera vez. falacia de 10s mitos descritos anteriormente. Lamen-
tablemente, las actitudes y mCtodos habituales fomen-
tan una pobre gesti6n y malas practicas tCcnicas,
incluso cuando la realidad dicta un mCtodo mejor. El
lrobojo muy durn para entender lo que tienes que hocer reconocimiento de las realidades del software es el
antes de empezor. No serios copoz de desorrollor mdo primer paso hacia la formulaci6n de soluciones prac-
detolle; por m h que sepos, tomo el menor riesgo. ticas para su desarrollo.
El software se ha convertido en el elemento clave de ponen una configuraci6n que se crea como parte del
la evoluci6n de 10s sistemas y productos inform6ticos. proceso de la ingenieria del software. El intento de la
En 10s pasados 50 afios, el software ha pasado de ser ingenieria del software es proporcionar un marco de
una resoluci6n de problemas especializada y una herra- trabajo para construir software con mayor calidad.
mienta de anilisis de information, a ser una industria
por si misma. Pero la temprana cultura e historia de la
ccprogramaci6n>>ha creado un conjunto de problemas
que persisten todavia hoy. El software se ha converti-
do en un factor que limita la evoluci6n de 10s sistemas Cuondo te pones o pensor, no encuentos tiempo para lo
informaticos. El software se compone de programas, discipline de lo ingenieria del s o h r e , y te preguntos:
datos y documentos. Cada uno de estos elementos com- ((2 lendre tiempo para poder hocerlo?~
[BR075] Brooks, F., The Mytical Man-Month, Addison-Wes- [GLA97] Glass, R. L., Software Runaways, Prentice Hall,
ley, 1975. 1997.
[DEJ98] De Jager, P., et al, Countdown Y2K: Business Sur- [GLA98] Glass, R. L.,& there Really a Software Crisis?,>,
vival Planning for the Year 2000, Wiley, 1998. IEEE Software, vol. 15, n.", Enero 1998, pp. 104-105.
[DEM95] De Marco, T., Why Does Software Cost So Much.?, [HAM931 Hammer, M., y J. Champy, Reengineering the Cor-
Dorset House, 199.5, p. 9. poration, HarpperCollins Publisher, 1993.
[FEI83] Feigenbaum, E. A., y P. McCorduck, The Fith Gene- [JON911 Jones, C., Applied Software Measurement, McGraw-
ration, Addison-Wesley, 1983. Hill, 1991.
[FL097] Flowers, S., Software Failure, Management Fai- [KAR99] Karlson, E., y J. Kolber, A Basic Introduction to
lure-Amaicing Stories and Cautionary Tails, Wiley, Y2K: How the Year 2000 Computer Crisis Affects You?,
1997 (?). Next Era Publications, Inc., 1999.
CAP~TULO
1 EL P R O D U C T 0 Y EL P R O C E S O
[LEV951Levy, S., ((TheLuddites Are Pack,,, Newsweek, 12 de [ST0891 Stoll, C., The cuckoo's Egg, Doubleday, 1989.
Julio de 1995, p. 55. [TOF80] Toffler, A., The Third Wave, Morrow Publishers,
[LEV991 Levy, S., ccThe New Digital Galaxy,,, Newsweek, 1980.
3 1 de Mayo de 1999, p.57. [TOF90] Toffler, A., Powershift, Bantam Publishers, 1990.
[LIE801 Lientz, B., y E. Swanson, Software Maintenance
[YOU921 Yourdon, E., The Decline and Fall of the American
Management, Addison Wesley, 1980.
Programmer, Yourdon Press, 1992.
[NAI82] Naisbitt, J., Megatoends, Warner Books, 1982.
[YOU961 Yourdon. E., The Rise and Resurrection of the Ame-
[NOR981Norman, D., The Invisible Computer, MIT Press, 1998. rican Programmer, Yourdon Press, 1996.
[OSB79] Osborne, A., Running Wild-The Next Industrial [YOU98a] Yourdon, E., Death March Projects, Prentice-Hall,
Revolution, Osborne/McGraw-Hill, 1979. 1998.
[PUT971 Putnam, L., y W. Myers, Industrial Strength Soft- [YOU98b] Yourdon, E., y J. Yourdon, Time Bomb 2000, Pren-
ware, IEEE Computer Society Press, 1997. tice-Hall, 1998.
1.I. El software es la caracteristica que diferencia a muchos 1.5. A medida que el software se difunde mas, 10s riesgos para
productos y sistemas informaticos. DC ejemplos de dos o tres el public0 (debido a programas defectuosos) se convierten en una
productos y de, a1 menos, un sistema en el que el software, no preocupacidn cada vez mas significativa. Desarrolle un escena-
el hardware, sea el elemento diferenciador. no realista del juicio final (distinto a Y2K) en donde el fallo de
1.2. En 10s afios cincuenta y sesenta la programaci6n de com- computadora podria hacer un gran daiio (econbmico o humano).
putadoras era un arte aprendido en un entorno basicamente 1.6. Lea detenidamente el grupo de noticias de Internet
experimental. iC6mo ha afectado esto a las pricticas de desa- comp.risk y prepare un resumen de riesgos para las personas
rrollo del software hoy? con las que se hayan tratado ultimamente. Codigo altemati-
1.3. Muchos autores han tratado el impacto de la ccera de la vo: Software Engineering Notes publicado por la ACM.
informaci6n>>.De varios ejemplos (positivos y negativos) que 1.7. Escriba un papel que resuma las ventajas recientes en
indiquen el impacto del software en nuestra sociedad. Repa- una de las ireas de aplicaciones de software principales. Entre
se algunas referencias de la Seccion 1.1 previas a 1990 e indi- las selecciones potenciales se incluyen: aplicaciones avanza-
que donde las predicciones del autor fueron correctas y d6nde das basadas en Web, realidad virtual, redes neuronales artifi-
no lo fueron. ciales, interfaces humanas avanzadas y agentes inteligentes.
1.4. Seleccione una aplicaci6n especifica e indique: (a) la 1.8. Los mitos destacados en la Seccion 1.4 se estin vinien-
categoria de la aplicaci6n de software (Seccibn 1.2.2) en la do abajo lentamente a medida que pasan 10s aiios. Pero otros
que encaje; (b) el contenido de 10s datos asociados con la apli- se estan haciendo un lugar. Intente aiiadir un mito o dos mitos
caci6n; (c) la information determinada de la aplicacibn. ccnuevos, a cada categoria.
Literalmente existen miles de libros escritos sobre software do industrializado y casi todas las aplicaciones a la nueva
de computadora. La gran mayoria tratan 10s lenguajes de pro- infraestructura de Internet.
gramacion o aplicaciones de software, y s610 unos pocos tra- Minasi (The Software Conspiracy: Why Software Com-
tan el software en si. Pressman y Herron (Software Sock, panies Put Out Faulty Products, How They Can Hurt You,
Dorset House, 1991) presentaron una discusi6n (dirigida a no and What You Can Do, McGraw-Hill, 2000) argument6 que
profesionales) acerca del software y del modo en que lo cons- el ccazote moderno~de 10s errores del software puede elimi-
truyen 10s profesionales. narse y sugiere formas para hacerlo. DeMarco (Why Does
El libro, Cxito de ventas, de Negroponte (Being Digital, Software Cost So Much?, Dorset House, 1995) ha producido
Alfred A. Knopf, Inc., 1995) proporciona una visi6n de las una colecci6n de ensayos divertidos e interesantes sobre el
computadoras y de su impacto global en el siglo XXI. Los software y el proceso a travts del cual se desarrolla.
libros de Norman [NOR981 y Bergman (Information En Internet estan disponibles una gran variedad de fuen-
Appliances & Beyond, Academic PresJMorgan Kauffman, tes de informaci6n relacionadas con temas de gesti6n y de
2000) sugieren que el impacto extendido del PC declinari software. Se puede encontrar una lista actualizada con refe-
a1 mismo tiemPo que las aplicaciones de informaci6n y rencias a sitios (piginas) web relevantes en http://www.press-
la difusidn de la programacidn conecten a todos en el mun- man5.com.
bRA (RAD). . .. ......22
H OWARD Baetjer, Jr. [BAE98], en un libro fascinante que proporciona un punto de
vista economicista del software y de la ingenieria del software, colnenta sobre el
proceso:
Conio el softwilre, ill igual que el capital, es el conocirniento incorporado, y puesto que el conocimiento
desarrollo basado en csth inicialniente tlisperso, el desarrollo del software implicito, latente e incomplelo en gran medida, es un
romponenfes . . ...... 2 8 proceso social de aprendizaje. El proceso es un diiilogo en el que se reline el conocimiento y se incluye en
1. I, el software para converlirse en software. El proceso proporciona una interaccicjn entre 10s usunrios y los
diseiiadores, entre los usuarios y las herramientas de desarrollo, y entre los diseiiatlores y las lierrarnien-
tzs tlc desarmllo [tecnologia]. Es un proccso interactivo donde la herlamienta de dcsarrollo se L I S ~conio
rnetlio de coniunicacih, con cnda iteracicjn tlel diiilogo se obtiene mayor conocirniento de las personas
involucradas.
Realmente, construir software de computadora es un proceso de aprendizaje iterativo, y el
resultado, nlgo que Baetjer podria llamar <<capitaldel software,,, e s el colljunto del software
reunido, depurado y organizado mientras se desarrolla el proceso.
u6 es? Cuando Irabaja para construir ;Par qu6 es importante? Porque pro- software, 10s productos obtenidos son
un producto o un sistema, e s impor- porciona estabilidad, control y organi- programas, documentos y datos que se
tante seguir una serie de pasos pre- zaci6n a una actividad que puede. s i producen como consecuencia de las
decibles -un mapa de caneteras que no se controls, volverse caotica. actividades de ingenieria del software
le ayude a obtener el resultado opor-
...--- mlirlnrl-
tllnn A n
I-
mnnn .,.. rla --..-
............ , F'.1 .-...'-.-. m r r n -
&&dles
3 ..
uaao, -1
el
b, pasos? A un ,,ivel deta-
.
proceso. que . . . . .
aaopremos -IZ-_-- 4- --.---------
definidas por el proceso.
&"orno pueao csrar segurw a e qrre
3- --
teras a seguir es llamado uproceso del depende del software que estamos lo he hecho correctamente? Hay
soflware~. construyendo. Un proceso puede ser una cantidad de mecanismos de eva-
jQui6n lo hace? Los ingenieros de soft- apropiado para crear software de un luacion del proceso del software que
ware y sus gestores adaptan el proce- sistema de a v i a c i h , mientras que un permiten a las organizaciones deter-
s o a s u s necesidades y entonces lo proceso diferente por completo puede minar la *rnadurezn de su proceso del
siguen. Ademus las personas que han ser adecuado para la creacion de un software. Sin embargo, la mlidad, opor-
solicitado el software tienen un papel sitio web. tunidad y viabilidad a largo plazo del
a desempeiiar e n el proceso del soft- &Cud1es el product6 abtenido? Des- producto que esta constmyendo son 10s
ware. de el punto de vista d e un ingeniero de mejores indicadores de la eficiencia del
proceso que estamos utilizando.
Pero, iquk es exactamente el proceso del software desde un punto de vista tkcnico'? Dentro del con-
texto de este libro, detinimos un proceso de software como un marco de trnbnjo de lsls tareas quc se
requieren para construir software de aha calidad. iEs ccproceso,, sin6nimo de ingenieria clel sofwa-
re'? La respuesta es ((siny ccno,,. Un proceso de software define el enfoque que se toma cuanclo el soft-
ware es tratado por la ingenieria. Pero la ingenieria del software tarnbikn comprende las lecnologias
que tiene el proceso -me~odos tCcnicos y herramientas autornntizadas-.
Aiin m$s importante es que la ingenieria del software la realizan personas creativas, con conoci- ,
mienlo, que deberian trabajar dentro de un proceso del software definido y avanzado que es apropia-
do para 10s productos que construyen y para las dernandas de su mercado. La intenci6n de este capitulo
es proporcionar un estudio del estado actual del proceso del software y puntualizar sobre el estudio
detallaclo de 10s temas de gesti6n y tknicos presentados en este libro.
I N G E N I E R ~ ADEL SOFTWARE. U N ENFOQUE PRACTICO
Aunque cientos de autores han desarrollado definicio- -

nes personales de la ingenieria del software, una defi-
--
Herramientas --.
nicivn propuesta por Fritz Bauer [NAU69] en una
conferencia de gran influencia sobre estos temas va a
Mktodos <>-
servir como base de estudio:
FIGURA 2.1. Capas de la ingenieria del software.
M6s que !del

El fundamento de la ingenieria del software e s la
conocimienro, la mgenlerio es un verbo, uno polobro
capa de p~vceso.El proceso de la ingenieria del soft-
de occibn, un modo de enfocor el problemo.
Scan Whitmire.
ware es la unicin clue mantiene juntas las capas de tec-
nologia y que permite un desarrollo racional y oportuno
de In ingenieria del software. El proceso clef ne iln mar-
[ L a ingenicria dcl sofiwareI es cl catablecimiento y uso de prin- co de trabajo para un conjunto de L ~ W L ~ S c.luve & pro-
cipim robusto.; dc la ingcnicria a ti11 de obtener econ6micamentc
software que sea fiablc y que I'uncionc eficientcniente sobrc mliqui-
ceso (ACPs) [PAU93] que se deben estnblecer para la
nas realcs. entrega efectiva de la tecnologia dc la ingenieria del
software. Lns ireas clavcs del proceso forman la base
Casi rodos los lectorcs tendrin la tenrnci6n de del control de gcsti6n de proycctos del software y esta-
scguir cstii definicicin. No dice mucho sobre los aspcc- blccen cl contexlo cn cl clue se aplican 10s mCtodos tCc-
tus tdcnicos dc la calidad dcl software: no se enfren- nicos, se obticnen productos dcl trabajo (modelos,
ta directa~ncnlccon In nccesitlad dc la satisfncci6n dcl documcnros. datos, infimnes, formulnrios, ctc.), se esta-
cliente o de la cntregu opvrluna del producto; omire blccen hitos, se nscgura In calidad y el c;unbio sc ges-
It1 niencirin dc 1:) importiuncia dc mediciones y m c ~ r i - liunu adecuadamente.
cas; tarnpoco cxpresa la imporlancia de iln pruccso Los n~c'to~1o.s
de la ingenicria del software indican
avanzado. Y sin embargo. la definicicin de Railer nos ac6mo>,construir tdcnicamente el software. Los rn6to-
proporciona una linen base. ,Culiles son 10s ccprinci- dos aharcan una gran gama de tareas que incluyen ani-
pios robusros cle 13 ingenicriax ap1ic;iblcs al des;wru- Iisis de requisites, disefio. construccicin cle programas,
Ilo dc software de computadora? i,C6m0 construimos pruebas y manteninliento. Los mCtodos dc la ingcnieria
CI software (cccon6micamcnte~~ para que sea ccCiable,>'? del software depcndcn de un co~i.juntodc principios bisi-
;,Qui se necesita para crcar programas de coniputa- cos que gobiernnn cada rirea dc la tccnologia c incluyen
dor;~~ L I funcioncn
C cceficicnlcmcnte>>no cn una miqui- actividades dc modclxh y otrns tkcnicus dcscrip~ivas.
na si no en diferentcs ccmlicluinas reales))? Estas son
cuestiones yiic sigucn siendo un rcto para los inge-
nieros dcl software.
Lo lngemerio de sohore comprende un proceso,

9'~ C h definimos
-
I
o la rnktodos tkcnicos y de gestibn, y herrornientos.

Ingenieria del software?
Las llo~unziet~tcis de la Ingenieria del software pro-

El IEEE [IEEC)3]ha desan-ollado una defi nicibn mss porcionan un cnfoque automitico o semi-automlitico para
cornpleta: el proceso y para los mCtodos. Cuando se integran herra-
Ingenieria tlel software: ( I ) La aplicacicin dc un enfoque sis- mientas para que la informaci6n creada por una herra-
tclnlitico, disciplinatlo y cuantiticable hacia el desarrollo, opera- micnta 13 pueda utilizar otra, se ectablece un sistema de
ci611 y man~cnimicntotlcl sol'tw;ire: es decir, 1;i aplicacidn de \oportc para el desarrollo del software Ilamado itzgoiie-
ingeniel-ia nl softw:rre. (2) El estudio de enfoque.; como en (I). /%I&I s o f h v ~ ~usistidu
t~' (CASE).
p01- ~.i)i~p~tfudora
2.1.1. Proceso, m6todos y herramientas 2.1.2. Una visi6n general de la ingenieria del
La Ingcnieria del software es un tecnologia multica- software
pa. Como muestra la Figura 2.1. cualquier enlhque de La ingenieria es el anhlisis. diseiio, construccibn, veri-
ingenieria (incluida ingenieria del software) debe apo- ficacibn y gesti6n de entidades tCcnicas (o sociales).
yarse sobre un compromiso de organizaci6n de cali- Con independencia de la entidad a la que se va a apli-
dad. car ingenieria, se deben cuestionar y responder las
siguientes preguntas:
CAPfTULO 2 EL PROCESO
~ C u a es
l el problema a resolver? La fase de desarrollo se centra en el cdmo. Es decir,
iCuales son las caracteristicas de la entidad que se durante el desarrollo un ingeniero del software intenta
utiliza para resolver el problema? definir como han de disefiarse las estructuras de datos,
como ha de implementarse la funcion dentro de una
iC6m0 se realizara la entidad (y la solucion)? arquitectura de software, c6mo han de implementarse
iC6m0 se construira la entidad? 10s detalles procedimentales, como han de caracteri-
zarse interfaces, como ha de traducirse el diseiio en un
~QuC enfoque se va a utilizar para no contemplar 10s
lenguaje de programacion (o lenguaje no procedimen-
errores que se cometieron en el disefio y en la cons-
tal) y c6mo ha de realizarse la prueba. Los mCtodos apli-
trucci6n de la entidad?
cados durante la fase de desarrollo variarhn, aunque las
iC6m0 se apoyar6 la entidad cuando usuarios soli- tres tareas especificas tkcnicas deberian ocurrir siem-
citen correcciones, adaptaciones y mejoras de la enti- pre: disefio del software (Capitulos 14, 15 y 21), gene-
dad? ration de c6digo y prueba del software (Capitulos 16,
Referencia web/ Qcim:

Crosstalk es un periodic0 que proporciona consejos y Einsteinoruumentb w e debe haber una exdicacion
comentorios procticos de ingenieria del software. Estan
disponibles temos relocionodos directamente en:
o de lo nohrolezo, parque Dias no es
ni arbitrario. Esto fe no se aiusta al
www.stc.hill.af.mil Geniero de software.
A lo largo de este libro. nos vamos a centrar en Gron pork de la rompleiidad que debe dorninar es
orbitrotio.
una sola entidad -el software de computadora-.
Fred Brooks
Para construir la ingenieria del software adecuada-
mente, se debe definir un proceso de desarrollo de
software. En esta seccion se consideran las caracte- L a , f k e de nlantenimiento se centra en el cmnhio que
ri,ticas genkricas del proceso de software. Mas ade- va asociado a la correccion de errores, a las adaptacio-
lante. en este mismo capitulo, se trataran modelos nes requeridas a medida que evoluciona el entorno del
especificos de procesos. software y a cambios debidos a las mejoras producidas
El trabajo que se asocia a la ingenieria del software por 10s requisitos cambiantes del cliente. Durante la fase
se puede dividir en tres fases genkricas, con indepen- de mantenimiento se encuentran cuatro tipos de cam-
dencia del area de aplicacion, tamaiio o complejidad del bios:
proyecto. Cada fase se encuentra con una o varias cues- Correccion. Incluso llevando a cab0 las mejores acti-
tiones de las destacadas anteriormente. vidades de garantia de calidad, es muy probable que el
Lafase de deefinicicin se centra sobre el que'. Es decir, cliente descubra 10s defectos en el software. El nzante-
durante la definicion, el que desarrolla el software inten- nimiento corrective cambia el software para corregir 10s
ta identificar quC informaci6n ha de ser procesada, quC defectos.
funcion y rendimiento se desea, quC comportamiento Adaptacion. Con el paso del tiempo, es probable
del sistema, quC interfaces van a ser establecidas, quC que cambie el entorno original (por ejemplo: CPU, el
restricciones de disefio existen, y quC criterios de vali- sistema operativo, las reglas de empresa, las caracte-
dacion se necesitan para definir un sistema correcto. Por risticas externas de productos) para el que se desarro-
tanto, han de identificarse 10s requisitos clave del siste- 116 el software. El muntenimiento uduptutivo produce
ma y del software. Aunque 10s mktodos aplicados duran- modificaci6n en el software para acomodarlo a 10s cam-
te la fase de definicion variaran dependiendo del bios de su entomo extemo.
paradigma de ingenieria del software (o combinacion
de paradigmas) que se aplique, de alguna manera ten-
Mejora. Conforme se utilice el software, el clien-
te/usuario puede descubrir funciones adicionales que
dran lugar tres tareas principales: ingenieria de sistemas
van a producir beneficios. El mantenimiento perfectivo
o de informacion (Capitulo lo), planificacion del pro-
lleva a1 software mas alla de sus requisitos funcionales
yecto del software (Capitulos 3, 5, 6 y 7) y andisis de
originales.
10s requisitos (Capitulos 11, 12 y 21).
Prevencion. El software de computadora se dete-
riora debido a1 cambio, y por esto el mantenimienropre-
ventivo tambiCn llamado reingenieria del sofmare, se
debe conducir a permitir que el software sirva para las
necesidades de 10s usuarios finales. En esencia, el man-
El sohare se creo oplicando tres foses distintos que se tenimiento preventivo hace cambios en programas de
centran en lo definicibn, desarrollo y mantenimiento. computadora a fin de que se puedan corregir, adaptar y
mejorar mas fAcilrnente.
Ademlis de estas actividades de rnantenirniento, 10s
usuarios de software requieren un mantenimiento con-
tinuo. Los asistentes tCcnicos a distancia, telifonos de
ayuda y sitios Web de aplicaciones especificas se irnple-
mentan frecuentemente como parte de la fase de man-
tenirniento. Adividades de proteccibn
Entre las actividades tipicas de esta categoria se incluyen:
Seguimiento y control del proyecto de software
luondo utilizomos el termino ((mon!enimiento~,
reconocemos que es mucho mbs que uno simple
Revisiones tknicas formales
correccibn de errores. Garantia de calidad del software
Hoy en dia, el aumento de 10s programas' legales Gesticin de configuracidn del software
esti forzando a muchas compaiiias a seguir estrategias Preparaci6n y produccicin de documentos
de reingenieria del software (Capitulo 30). En un sen- Gestidn de reutilizaci6n
tido global, la reingenieria del software se considera a
Mediciones
menudo como una parte de la reingenieria de procesos
comerciales [STA95]. Gestidn de riesgos
Las fases y 10s pasos relacionados descritos en nues- Las actividades de proteccicin se aplican a lo largo
tra visi6n generica de la ingenieria del software se com- de todo el proceso del software y se tratan en las partes
plemcntan con un nlimero de (rc-tividcrdesp~wtector~rs. Segunda y Quinta del libro.
Un proceso de software se puede caracterizar como se del proyecto. Finalmente, las actividades de protccci6n
muestra en la Figura 2.2. Se establcce un tr~urr.~ wnz~in -tales como garantia de calidad del software, gestion de
clcl~wo~~c~sodefi mendo un pequeiio numcro de activida- configuration del software y rnedicicin2-abarcan el
des del rnarco de trabajo clue son aplicables a todos 10s rnodelo de procesos. Las actividades de protecci6n son
proyectos del software, con independencia de su tarnaiio independientes de cualquier actividad del marco de tra-
o complejidnd. Un nlimero de corljrlrztos c k tawus 4 a d a bajo y aparecen durante todo el proceso.
uno e\ una coleccicin dc tareas cle trabqo de ingenieria En 10s Liltimos afios, se ha hecho mucho knfasis en
del \oftware, hitos de proycctos, productos de trabajo, y la ccrnadurez del proceso,,. El Softwate Engineering Ins-
puntos de garantia de calidad-que permiten clue las acti- titute (SEI)' ha desarrollado un niodelo cornpleto que
vidades del lnarco de trabajo se adapten a las caractcris- se basa en un conjunto de funciones de ingenieria del
ticas dcl proyecto dcl softwurc y a los requisites del equipo software que deberian estar presentes con forrne oIga-
nizaciones alcanzan diferentes niveles de madurez del
I M a w de trabajo cm*m del procesa I!
proceso. Para determinar el estado actual de niadurez
del proceso de una organizacicin, el SEI utiliza un cues-
I I Actiuidades del rnarco de trabajo I 1; tionario cle evaluaci6n y un esquema de cinco grados.
Seleccione un m o m de trobojo del proceso comun que se

odecue 01 producto, 01 person01 y 01 pioyec~o.
El esquema de grados determina la conformidad con
L
Actividades de Proteccidn
"I un modelo de capacidad de madurez [PAU93] que defi-
ne las actividades clave que se requieren en 10s dife-
rentes niveles de madurez del proceso. El enfoclue del
FIGURA 2.2. El proceso del software. SEI proporciona una medida de la efectividacl global de
I El termino .programas legalest] es un eufernismo para el software Estos ternas se tratan con mas detalle en capitulos posteriores.
antiguo, a menudo disefiado y docurnentado pobrernente, que es cri- El autor se esta refiriendo al SEI de la Cannegie R,lellon University.
t ~ c opara el negocio y debe ser soportado durante algunos atios.
las practicas de ingenieria del software de una compa- ci6n ha sido detallado y se hace cumplir por medio de
Aia y establece cinco niveles de madurez del proceso, procedimientos tales como auditorias. Este nivel es aquel
que se definen de la forma siguiente: en el que la mayoria de 10s desarrolladores de softwa-
Nivel 1: Inicial. El proceso del software se caracte- re, pretenden conseguir con estandares como el I S 0
riza seg6n el caso, y ocasionalmente incluso de forma 9001, y existen pocos casos de desarrolladores de soft-
ca6tica. Se definen pocos procesos, y el Cxito depende ware que superan este nivel.
del esfuerzo individual. El nivel 4 comprende el concepto de medici6n y el
uso de metricas. El capitulo 4 describe este tema con mtis
Nivel 2: Repetible. Se establecen 10s procesos de
detalle. Sin embargo, cabe destacar el concepto de mCtri-
gesti6n del proyecto para hacer seguimiento del coste,
ca para comprender la importancia que tiene que el desa-
de la planificaci6n y de la funcionalidad. Para repetir
rrollador del software alcance el nivel4 o el nivel5.
Cxitos anteriores en proyectos con aplicaciones simila-
Una mCtrica es una cantidad insignificante que puede
res se aplica la disciplina necesaria para el proceso.
extraerse de algtin documento o cddigo dentro de un pro-
Nivel 3: Definido. El proceso del software de las yecto de software. Un ejemplo de mCtrica es el numero
actividades de gesti6n y de ingenieria se documenta, se de rarnas condicionales en una seccion de c6digo de un
estandariza y se integra dentro de un proceso de soft- programa. Esta mCtrica es significativa en el sentido de
ware de toda una organizaci6n. Todos 10s proyectos uti- que proporciona alguna indicaci6n del esfuerzo necesa-
lizan una versi6n documentada y aprobada del proceso rio para probar el c6digo: esta directamente relacionado
de la organizaci6n para el desarrollo y mantenimiento con el numero de caminos de prueba dentro del c6digo.
del software. En este nivel se incluyen todas las carac- Una organizacidn del nivel 4 maneja numerosas
tensticas definidas para el nivel 2. mCtricas. Estas metricas se utilizan entonces para super-
Nivel 4: Gestionado. Se recopilan medidas deta- visar y controlar un proyecto de software, por ejemplo:
lladas del proceso del software y de la calidad del pro- Una mCtrica de prueba puede usarse para determinar
d u c t ~Mediante
. la utilizaci6n de medidas detalladas,
cutindo finalizar la prueba de un elemento del c6digo.
se comprenden y se controlan cuantitativamente tan-
to 10s productos como el proceso del software. En este Una mCtrica de legilibilidad puede usarse para juz-
nivel se incluyen todas las caracteristicas definidas gar la legilibilidad de alglin documento en lenguaje
para el nivel 3. natural.
Nivel5: Optirnizacion. Mediante una retroalimen- Una mCtrica de comprensi6n del programa puede uti-
taci6n cuantitativa del proceso, ideas y tecnologias inno- lizarse para proporcionar algun umbra1 numCrico que
vadoras se posibilita una mejora del proceso. En este 10s programadores no pueden cruzar.
nivel se incluyen todas las caracten'sticas definidas para
Para que estas mCtricas alcancen este nivel es nece-
el nivel4. sario que todos 10s componentes del nivel3 CMM, en
castellano MCM (Modelo de Capacidad de Madurez),
2
Referencia Web
El IIS ofrece un omplio conjunto de informoci6n
estCn conseguidos, por ejemplo notaciones bien defini-
das para actividades como la especificaci6n del disefio
de requisitos, por lo que estas mCtricas pueden ser facil-
mente extraidas de mod0 autom8tico.
relocionodo con el proceso en www.sei.cmu.edu
El nivel5 es el nivel mas alto a alcanzar. Hasta aho-
Merece la pena destacar que cada nivel superior es ra, muy pocos desarrolladores de software han alcan-
la suma de 10s niveles anteriores, por ejemplo, un desa- zado esta fase. Representa la analogia del software con
rrollador de software en el nivel3 tiene que haber alcan- 10s mecanismos de control de calidad que existen en
zado el estado nivel 2 para poder disponer de sus otras industrias de mayor madurez. Por ejemplo el fabri-
procesos en el nivel 3. cante de un producto industrial como un cojinete de
El nivel 1 representa una situaci6n sin ningtin esfuer- bolas (rodamiento) puede supervisar y controlar la cali-
zo en la garantia de calidad y gesti6n del proyecto, don- dad de 10s rodamientos producidos y puede predecir esta
de cada equipo del proyecto puede desarrollar software calidad basandose en 10s procesos y maquinas utiliza-
de cualquier forma eligiendo 10s mCtodos, estandares y dos para desarrollar 10s rodamientos. Del mismo mod0
procedimientos a utilizar que podran variar desde lo que el desarrollador del sofware en el nivel5 puede pre-
mejor hasta lo peor. decir resultados como el nlimero de errores latentes en
El nivel2 representa el hecho de que un desarrolla- un producto basado en la medicidn tomada durante la
dor de software ha definido ciertas actividades tales ejecuci6n de un proyecto. Ademas, dicho desarrollador
como el informe del esfuerzo y del tiempo empleado, y puede cuantificar el efecto que un proceso nuevo o herra-
el informe de las tareas realizadas. mienta de manufacturacion ha tenido en un proyecto
El nivel3 representa el hecho de que un desarrolla- examinando metricas para ese proyecto y cornparando-
dor de software ha definido tanto procesos tCcnicos como las con proyectos anteriores que no utilizaron ese pro-
de gestion, por ejemplo un estandar para la programa- ceso o herramienta.
En este orden debe destacarse que para que un desa-

rrollador de software alcance el nivel5 tiene que tener
cada proceso definido rigurosamente y seguirlo a1 pie
de la letra; esto es una consecuencia de estar en el
Referencia web/ '
nivel3. Si el desarrollador del software no tiene defi- Uno versi6n tabular del MCM completo del IS, incluyendo
nidos rigurosamente 10s procesos pueden ocurrir una todos 10s obietivos, comentorios, hobilidodes y
octividodes esti disponible en
gran cantidad de cambios en el proceso de desarrollo
sepo.nosc.mil/CMMmatrices.html
y no se podran utilizar las estadisticas para estas acti-
vidades.
Los cinco niveles definidos por el SEI se obtienen madurez y se distribuyen en niveles diferentes de madu-
como consecuencia de evaluar las respuestas del cues- rez del proceso. Las ACPs se deberian lograr en cada
tionario de evaluation basado en el MCM (Modelo de nivel de madurez de proceso4:
capacidad de madurez). Los resultados del cuestiona- Nivel2 de Madurez del Proceso
rio se refinan en un dnico grado numkrico que propor-
Gestion de configuration del software
ciona una indicaci6n de la madurez del proceso de una
organizacion. Garantia de calidad del software
El SET ha asociado Areas claves del proceso Gesti6n de subcontratacion del software
(ACPs) a cada uno de 10s niveles de madurez. Las Seguimiento y supervision del proyecto del software
ACPs describen esas funciones de la ingenieria del
software (por ejemplo: planificacion del proyecto de Planificacion del proyecto del software
software, gestion de requisitos) que se deben pre- Gestion de requisitos
sentar para satisfacer una buena prActica a un nivel Nivel3 de Madurez del Proceso
en particular. Cada ACP se describe identificando las
Revisiones periodicas
caracteristicas siguientes:
Coordinacion entre grupos
Ingenieria de productos de software
Todo orgonizocibn deberio esforzorse poro olconzor Gestion de integracion del software
lo profundidad del MCM del 11s. Sin emborgo, Programa de formacion
lo implementocibn de cuolquier ospecta del modelo Definicion del proceso de la organizacion
puede eliminone en su siluocibn.
Enfoque del proceso de la organizacion
Objetivos- 10s objetivos globales que debe alcan- Nivel4 de Madurez del Proceso
zar la ACP Gestion de calidad del software
Conipromisos- requisitos (impuestos en la organi- Gesti6n cuantitativa del proceso
zacion) que se deben cumplir para lograr 10s objeti-
vos y que proporcionan una prueba del intento por Nivel.5 de Madurez del Proceso
ajustarse a 10s objetivos. Gestion de cambios del proceso
Capacidades- aquellos elementos que deben encon- Gestion de cambios de tecnologia
trarse (organizacional y tkcnicamente) para permitir Prevencion de defectos
que la organizacion cumpla 10s objetivos.
Actividades- las tareas especificas que se requieren Cada una de las ACPs se definen con un conjunto
para lograr la funcion ACP. deprcicticas clave que contribuyen a cumplir estos obje-
Me'todos para supervisar la iniplementacidn-la tivos. Las prActicas clave son normas, procedimientos
y actividades que deben ocurrir antes de que se haya
manera en que las actividades son supervisadas con-
instituido completamente un area clave de proceso. El
forme se aplican.
SEI define a 10s indicadores clave como ccaquellas prAc-
Me'todos para verificar la implementacici- la forma ticas clave o componentes de practicas clave que ofre-
en que se puede verificar la prActica adecuada para cen una vision mejor para lograr 10s objetivos de un
la ACP. Area clave de proceso>>.Las cuestiones de valoracion
Se definen dieciocho ACPs (descritas mediante la se diseiian para averiguar la existencia (o falta) de un
estructura destacada anteriormente) en el modelo de indicador clave.
Tengase en cuenta que las ACPs son acumulativas. Por ejemplo, el

nivel 3 de madurez del proceso contiene todas las ACPs del nivel 2
mas las destacadas para el nivel 1.
18
Para resolver 10s problemas reales de una industria, un completo, las etapas descritas anteriormente se aplican
ingeniero del software o un equipo de ingenieros debe recursivamente a las necesidades del usuario y a la espe-
incorporar una estrategia de desarrollo que acompafie cificaci6n tCcnica del desarrollador del software.
a1 proceso, mCtodos y capas de herramientas descritos
en la Secci6n 2.1.1 y las fases genCricas discutidas en
la Secci6n 2.1.2. Esta estrategia a menudo se llama
modelo de proceso o paradigma de ingenieria del soft-
ware. Se selecciona un modelo de proceso para la inge- Todos 10s etopas de un proceso del softwore -estodo
nieria del software segun la naturaleza del proyecto y ottual, definition del problerno, desorrollo tetnito e
de la aplicacih, 10s mCtodos y las herramientas a utili- integrocibn de la solucibn- coexisten sirnultuneornente
zarse, y 10s controles y entregas que se requieren. En en olgh nivel de detolle.
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 10s de procesos para la ingenieria del software. Cada
del proceso del software. una representa un intento de ordenar una actividad inhe-
rentemente ca6tica. Es importante recordar que cada
uno de 10s modelos se han caracterizado de forma que
ayuden (con esperanza) a1 control y a la coordinaci6n
sigue de un proyecto de software real. Y a pesar de eso, en el
de va fondo, todos 10s modelos exhiben caracteristicas del
<<Modelodel Caow.
Definicidn
Todo el desarrollo del software se puede caracteri- de problemas
zar como bucle de resoluci6n de problemas (Fig. 2.3a)
0
en el que se encuentran cuatro etapas distintas: <<status
quo>>, definici6n de problemas, desarrollo tkcnico e inte- Desarrol l o
Estado
graci6n de soluciones. Status quo aepresenta el estado actual tCcnico
actual de sucesos>>[RAC95]; la definici6n de proble-
mas identifica el problema especifico a resolverse; el
desarrollo tCcnico resuelve el problema a travCs de la
aplicaci6n de alguna tecnologia y la integraci6n de solu- Integraci6n
ciones ofrece 10s resultados (por ejemplo: documentos, de soluciones
programas, datos, nueva funci6n comercial, nuevo pro-
d u c t ~ a) 10s que solicitan la solucion en primer lugar.
Las fases y 10s pasos genCricos de ingenieria del soft-
ware definidos en la Seccion 2.1.2 se divide facilmen-
te en estas etapas.
En realidad, es dificil compartimentar actividades de
manera tan nitida como la Figura 2.3.b da a entender,
porque existen interferencias entre las etapas. Aunque
esta visi6n simplificada lleva a una idea muy impor-
tante: con independencia del modelo de proceso que se Estado
seleccione para un proyecto de software, todas las eta- actual
pas -status quo, definici6n de problemas, desarrollo
tCcnico e integraci6n de soluciones- coexisten simul-
taneamente en alg6n nivel de detalle. Dada la naturale-
za recursiva de la Figura 2.3b, las cuatro etapas tratadas
anteriormente se aplican igualmente a1 anilisis de una
aplicaci6n completa y a la generaci6n de un pequefio
segment0 de c6digo.
Raccoon [RAC95] sugiere un <<Modelodel Caos>>
que describe el <<desarrollodel software como una exten- FIGURA 2.3. a) Las fases de un bucle de resolucion de pro-
si6n desde el usuario hasta el desarrollador y la tecno- blemas [RAC 951. b) Fases dentro de las fases
logia>>.Conforme progresa el trabajo hacia un sistema del bucle de resolucion de problemas IRAC 951.
I N G E N I E R I A DEL S O F T W A R E . UN E N F O Q U E PRACTICO
Llamado algunas veces ccciclo de vida b8sicon o <<mode- se pueda evaluar su calidad antes de que comience la
lo en cascada,,, el modelo lineal secuencial sugiere un codificacion.
enfoque5 sistematico, secuencial, para el desarrollo del Generacion de codigo. El diseiio se debe traducir
software que comienza en un nivel de sistemas y pro- en una forma legible por la maquina. El paso de gene-
gresa con el analisis, disefio, codificacion, pruebas y man- raci6n de codigo lleva a cab0 esta tarea. Si se lleva a
tenimiento. La Figura 2.4 muestra el modelo lineal cab0 el disefio de una forma detallada, la generation de
secuencial para la ingenieria del software. Modelado c6digo se realiza mecinicamente.
segun el ciclo de ingenieria convencional, el modelo
lineal secuencial comprende las siguientes actividades:
Ingenieria y modelado de Sistemas/Informacion.
Como el software siempre forma parte de un sistema Aunque el modelo line01 es o menudo denominodo
mas grande (o empresa), el trabajo comienza estable- ((modelo trodicionol)),resulto un enfoque rozonoble
ciendo requisitos de todos 10s elementos del sistema y cuondo 10s requisitos se hon entendido correctomente.
asignando a1 software alglin subgrupo de estos requisi-
tos. Esta vision del sistema es esencial cuando el soft- Pruebas. Una vez que se ha generado el c6digo.
ware se debe interconectar con otros elementos como comienzan las pruebas del programa. El proceso de prue-
hardware, personas y bases de datos. La ingenieria y el bas se centra en 10s procesos 16gicos internos del soft-
analisis de sistemas comprende 10s requisitos que se ware, asegurando que todas las sentencias se han
recogen en el nivel del sistema con una pequeiia parte comprobado, y en 10s procesos extemos funcionales; es
de analisis y de disefio. La ingenieria de informacion decir, realizar las pruebas para la detection de errores
abarca 10s requisitos que se recogen en el nivel de y asegurar que la entrada definida produce resultados
empresa estratkgico y en el nivel del area de negocio. reales de acuerdo con 10s resultados requeridos.
Mantenimiento.El software indudablemente sufrira
cambios despuCs de ser entregado a1 cliente (una excep-
cion posible es el software empotrado). Se produciran
lngenieria de cambios porque se han encontrado errores, porque el soft-
sistemas/informacion ware debe adaptarse para acoplarse a 10s cambios de su
entomo extemo (por ejemplo: se requiere un cambio debi-
do a un sistema operativo o dispositivo perifkrico 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 m6s anti-
guo y mas extensamente utilizado en la ingenieria del
Analisis de 10s requisitos del software. El proceso software. Sin embargo, la critica del paradigma ha pues-
de reunion de requisitos se intensifica y se centra espe- to en duda su eficacia [HAN95]. Entre 10s problemas
cialmente en el software. Para comprender la naturaleza que se encuentran algunas veces en el modelo lineal
del (10s) programa(s) a construirse, el ingeniero (c<ana- secuencial se incluyen:
lists,,) del software debe comprender el dominio de
informaci6n del software (descrito en el Capitulo 1l), asi iPor que falla algunas veces
como la funcidn requerida, comportamiento, rendimien- el modelo lineal?
to e interconexi6n.
Diseno. El disefio del software es realmente un pro-
ceso de muchos pasos que se centra en cuatro atributos 1. Los proyectos reales raras veces siguen el modelo
distintos de programa: estructura de datos, arquitectu- secuencial que propone el modelo. Aunque el modelo
ra de software, representaciones de interfaz y detalle lineal puede acoplar interaceion, lo hace indirecta-
procedimental (algoritmo). El proceso del diseiio tra- mente. Como resultado, 10s cambios pueden causar
duce requisitos en una representacidn del software donde confusion cuando el equipo del proyecto comienza.
Aunque el modelo original en cascada propuesto por Winston Royce

(ROY701 hacia provisiones para ~cbuclesde realimentacion~~, la gran
mayoria de las organizaciones que aplican este modelo de proceso
lo hacen como si fuera estrictamente lineal.
CAPfTUL0 2 EL PROCESO
A menudo es dificil que el cliente exponga explici- Cada uno de estos errores es real. Sin embargo, el
tamente todos 10s requisitos. El modelo lineal secuen- paradigma del ciclo de vida clisico tiene un lugar defi-
cia1 lo requiere y tiene dificultades a la hora de nido e importante en el trabajo de la ingenieria del soft-
acomodar la incertidumbre natural a1 comienzo de ware. Proporciona una plantilla en la que se encuentran
muchos proyectos. mCtodos para anhlisis, diseiio, codificaci611, pruebas y
El cliente debe tener paciencia. Una versi6n de tra- mantenimiento. El ciclo de vida clhsico sigue siendo el
bajo del(1os) programa(s) no estarh disponible hasta modelo de proceso mhs extensamente utilizado por la
que el proyecto estC muy avanzado. Un grave error ingenieria del software. Pese a tener debilidades, es sig-
puede ser desastroso si no se detecta hasta que se nificativamente mejor que un enfoque hecho a1 azar para
revisa el programa. el desarrollo del software.
Un cliente, a menudo, define un conjunto de objetivos

generales para el software, per0 no identifica 10s requi-
sitos detallados de entrada, proceso o salida. En otros
casos, el responsable del desarrollo del software puede
no estar seguro de la eficacia de un algoritmo, de la capa-
cidad de adaptacidn de un sistema operativo, o de la for-
ma en que deberia tomarse la interacci6n hombre-
miquina. En estas y en otras muchas situaciones, un
paradigma de construccibn de prototipos puede ofre-
cer el mejor enfoque.
El paradigma de construcci6n de prototipos (Fig.
2.5) comienza con la recolecci6n de requisitos. El desa-
rrollador y el cliente encuentran y definen 10s objeti-
vos globales para el software, identifican 10s requisitos
conocidos y las hreas del esquema en donde es obli-
FIGURA 2.5. El paradigma de construccion de prototipos.
gatoria mhs definici6n. Entonces aparece un ccdiseiio
ripido>>.El diseiio rapido se centra en una representa-
ci6n de esos aspectos del software que serhn visibles Pero iquC hacemos con el prototipo una vez que ha
para el usuario/cliente (por ejemplo: enfoques de entra- servido para el proposito descrito anteriormente? Brooks
da y formatos de salida). El diseiio ripido lleva a la [BR075] proporciona una respuesta:
construcci6n de un prototipo. El prototipo lo evalfia el
cliente/usuario y se utiliza para refinar 10s requisitos En la mayona de 10s proyectos, el primer sistema construido
del software a desarrollar. La iteraci6n ocurre cuando apenas se puede utilizar. Puede ser demasiado lento, demasiado
el 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 mas inte-
sidades del cliente, permitiendo a1 mismo tiempo que ligente, y construir una versi6n redisefiada en la que se resuelvan
el desarrollador comprenda mejor lo que se necesita estos problemas ... Cuando se utiliza un concept0 nuevo de siste-
hacer. ma o una tecnologia nueva, se tiene que construir un sistema que
no sirva y se tenga que tirar, porque incluso la mejor planificaci6n
no es omnisciente como para que estC perfecta la primera vez. Por
lo tanto la pregunta de la gesti6n no es si construir un sistema pilo-
to y tirarlo. Tendremos que hacerlo. La hnica pregunta es si pla-
luondo el cliente tiene uno necesidod leyitimo, nificar de antemano construir un desechable, o prometer
pero esth desorientodo sobre 10s detolles, entregarselo a 10s clientes...
el primer poso es desorrollor un prototipo.
El prototipo puede semir como ccprimer sistema>>.
El que Brooks recomienda tirar. Aunque esta puede ser
Lo ideal seria que el prototipo sirviera como un meca- una visi6n idealizada. Es verdad que a 10s clientes y a
nismo para identificar 10s requisitos del software. Si se 10s que desarrollan les gusta el paradigma de cons-
construye un prototipo de trabajo, el desarrollador inten- trucci6n de prototipos. A 10s usuarios les gusta el sis-
ta hacer uso de 10s fragmentos del programa ya exis- tema-realy a 10s que desarrollan les gusta construir algo
tentes o aplica herramientas (por ejemplo: generadores inmediatamente. Sin embargo, la construcci6n de pro-
de informes, gestores de ventanas, etc.) que permiten totipos tambiCn puede ser problemhtica por las siguien-
generar rhpidamente programas de trabajo. tes razones:
INGENIERfA DEL SOFTWARE. UN ENFOQUE PRACTICO
El cliente ve lo que parece ser una version de trabajo para demostrar la capacidad. DespuCs de a l g h
del software, sin tener conocimiento de que el pro- tiempo, el desarrollador debe familiarizarse con estas
totipo tambiCn est8 junto con ccel chicle y el cable de selecciones, y olvidarse de las razones por las que
embalam, sin saber que con la prisa de hacer que son inadecuadas. La seleccion 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 10s
niveles altos de calidad, el cliente no lo entiende y Resisto lo presihi de ofrecer on mol prototipo en el
pide que se apliquen ccunos pequeiios ajustem para producto final. Como resoltodo, lo colidod se resiente cosi
que se pueda hacer del prototipo un producto final. siempre.
De forma demasiado frecuente la gestion de desa-
rrollo del software es muy lenta. Aunque pueden surgir problemas, la construcci6n de
El desarrollador, a menudo, hace compromisos de prototipos puede ser un paradigma efectivo para la inge-
irnplementacion para hacer que el prototipo funcione niena del software. La clave es definir las reglas del jue-
r8pidamente. Se puede utilizar un sistema operativo go a1 comienzo; es decir, el cliente y el desarrollador se
o lenguaje de programacion inadecuado simplemente deben poner de acuerdo en que el prototipo se constru-
porque est8 disponible y porque es conocido; un algo- ya para servir como un mecanismo de definicion de
ritmo eficiente se puede implementar simplemente requisitos.
El Desarrollo Rbpido de Aplicaciones (DRA)es un mode- Generacion de aplicaciones. El DRA asume la uti-
lo de proceso del desarrollo del software lineal secuencial lizacion de tkcnicas de cuarta generacion (Seccion 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 adaptaci6n a ccalta velocidad,, cion de tercera generacion, el proceso DRA trabaja para
del modelo lineal secuencial en el que se logra el desa- volver a utilizar componentes de programas ya exis-
rrollo riipido utilizando una construccion basada en com- tentes (cuando es posible) o a crear componentes reuti-
ponentes. Si se comprenden bien 10s requisitos y se limita lizables (cuando sea necesario). En todos 10s casos se
el h b i t o del proyecto, el proceso DRA permite a1 equi- utilizan herramientas para facilitar la construccion del
po de desarrollo crew un ccsistema completamente fun- software.
cional,, dentro de periodos cortos de tiempo (por ejemplo:
de 60 a 90 dias) [MAR911. Cuando se utiliza principal-
mente para aplicaciones de sistemas de informacion, el Equipo n e 3
enfoque DRA comprende las siguientes fases [KER94]:
Modelado de Gestion. El flujo de informacion entre
las funciones de gestion se modela de forma que res-
ponda a las siguientes preguntas: ~ Q u C informaci6n con-
duce el proceso de gestion? ~ Q u C informaci6n se genera?
iQuiCn la genera? i A donde va la informacion? ~QuiCn
la procesa? El modelado de gestion se describe con mas
detalle en el Capitulo 10. Modelado
Modelado de datos. El flujo de informacih defini-

do como parte de la fase de modelado de gestion se refi-
na como un conjunto de objetos de datos necesarios para
apoyar la empresa. Se definen las caracteristicas (Ila-
madas atributos) de cada uno de 10s objetos y las rela-
ciones entre estos objetos. El modelado de datos se trata
en el Capitulo 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 informacion necesario para
implementar una funcion de gestion. Las descripciones
del proceso se crean para aiiadir, modificar, suprimir, o
recuperar un objeto de datos. 6
-t09
-0 Ia
.sd
-i
" En ingles: RAD (Rapid Application Development). FIGURA 2.6. El modelo DRA.
CAPITULO 2 EL PROCESO
Pruebas y entrega. Como el proceso DRA enfati- A1 igual que todos 10s modelos de proceso, el enfo-
za la reutilizacion, ya se han comprobado muchos de que DRA tiene inconvenientes [BUT94]:
10s componentes de 10s programas. Esto reduce tiempo Para proyectos grandes aunque por escalas, el DRA
de pruebas. Sin embargo, se deben probar todos 10s com- requiere recursos humanos suficientes como para
ponentes nuevos y se deben ejercitar todas las interfa- crear el numero correct0 de equipos DRA.
ces a fondo. DRA requiere clientes y desarrolladores compro-
metidos en las rapidas actividades necesarias para
completar un sistema en un marco de tiempo abre-
El DRA hace un fuerte uso de componentes
viado. Si no hay compromiso por ninguna de las par-
reutilizables. Para mayor informacibn sobre el
desorrollo de componentes, vbase el Capltulo 27
tes constituyentes, 10s proyectos DRA fracasaran.
No todos 10s tipos de aplicaciones son apropiados
para DRA. Si un sistema no se puede modularizar
El modelo de proceso DRA se ilustra en la Figura adecuadamente, la construccion de 10s componentes
2.6. Obviamente, las limitaciones de tiempo impuestas necesarios para DRA sera problematico. Si esta en
en un proyecto DRA demandan ccfimbito en escalasn juego el alto rendimiento, y se va a conseguir el ren-
[KER94]. Si una aplicacion de gestion puede modular- dimiento convirtiendo interfaces en componentes de
se de forma que permita completarse cada una de las sistemas, el enfoque DRA puede que no funcione.
funciones principales en menos de tres meses (utilizando DRA no es adecuado cuando 10s riesgos ttknicos son
el enfoque descrito anteriormente), es un candidato del altos. Esto ocurre cuando una nueva aplicacion hace
DRA. Cada una de las funciones pueden ser afrontadas uso de tecnologias nuevas, o cuando el software
por un equipo DRA separado y ser integradas en un solo nuevo requiere un alto grado de interoperatividad
conjunto. con programas de computadora ya existentes.
2.7 -0s EVBLUTIVQS DE P R O C U O D U 'iQFTWKRE

Se reconoce que el software, a1 igual que todos 10s sis- 2.7.1. El modelo incremental
temas complejos, evoluciona con el tiempo [GIL88]. El modelo incremental combina elementos del modelo
Los requisitos de gestion y de productos a menudo cam- lineal secuencial (aplicados repetidamente) con la filo-
bian conforme a que el desarrollo proceda haciendo que sofia interactiva de construccion de prototipos. Como
el camino que lleva a1 producto final no sea real; las muestra la Figura 2.7, el modelo incremental aplica
estrictas 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 lineal
introducir una version limitada para cumplir la presi6n produce un ccincremento>>del software [MDE93]. Por
competitiva y de gestion; 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 podria extraer fun-
sistema, per0 todavia se tienen que definir 10s detalles ciones de gestion de archivos basicos y de produccion
de extensiones del producto o sistema. En estas y en de documentos en el primer incremento; funciones de
otras situaciones similares, 10s ingenieros del software edicion mas sofisticadas y de produccion de documen-
necesitan un modelo de proceso que se ha diseiiado tos en el segundo incremento; correccion ortografica y
explicitamente para acomodarse a un producto que evo- gramatical en el tercero; y una funcion avanzada de
lucione con el tiempo. esquema de pigina en el cuarto. Se deberia tener en cuen-
El modelo lineal secuencial (Seccion 2.4) se disefia ta que el flujo del proceso de cualquier incremento pue-
para el desarrollo en linea recta. En esencia, este enfo- de incorporar el paradigma de construccion de prototipos.
que en cascada asume que se va entregar un sistema
completo una vez que la secuencia lineal se haya fina-
lizado. El modelo de construccion de prototipos (Sec-
cion 2.5) se disefia para ayudar a1 cliente (o a1 que
desarrolla) a comprender 10s requisitos. En general, no El modelo increment01entrego el softwore en portes
se disefia para entregar un sistema de produccion. En pequeiios, per0 utilizobles, llomodos ((incrementos)).
ninguno de 10s paradigmas de ingenieria del software En general, coda incremento se construye sobre oquel
se tiene en cuenta la naturaleza evolutiva del software. que yo ho sido entregodo.
Los modelos evolutivos son iterativos. Se caracteri-
zan por la forma en que permiten a 10s ingenieros del Cuando se utiliza un modelo incremental, el primer
software desarrollar versiones cada vez mas completas incremento a menudo es un producto esencial. Es decir,
del software. se afrontan requisitos bisicos, per0 muchas funciones
I N G E N ~ E R ~DEL
A SOFTWARE. UN ENFOQUE PRACTICO
suplementarias (algunas conocidas, otras no) quedan sin El modelo de proceso incremental, como la cons-
extraer. El cliente utiliza el producto central (o sufre la trucci6n de prototipos (Seccibn 2.5) y otros enfoques
revisi6n detallada). Como un resultado de utilizaci6n y/o evolutivos, es iterativo por naturaleza. Pero a dife-
de evaluaci611, se desarrolla un plan para el incremento rencia de la construcci6n de prototipos, el modelo
siguiente. El plan afronta la modificaci6n del producto incremental se centra en la entrega de un producto
central a fin de cumplir mejor las necesidades del clien- operacional con cada incremento. Los primeros incre-
te y la entrega de funciones, y caractensticas adiciona- mentos son versiones <<incompletasudel producto
les. Este proceso se repite siguiendo la entrega de cada final, per0 proporcionan a1 usuario la funcionalidad
incremento, hasta que se elabore el producto completo. que precisa y tambiCn una plataforma para la eva-
luaci6n.
El desarrollo incremental es particularmente util
cuando la dotacion de personal no esta disponible para
Cuando tenga uno fecha de entrega imposible una implementaci6n completa en la fecha limite que se
de cambia6 el modela incremental es un buen
haya establecido para el proyecto. Los primeros incre-
paradigma a cansiderar.
mentos se pueden implementar con menos personas.
incrernento 1
E"rega del
Prueba
l.erincremento
Prueba E"rega del

2." incremento
increment0 3 Analisis Diseiio + Codigo
increment0 4 Analisis
4." incrernento
Tiempo de calendario
FIGURA 2.7. El rnodelo incremental.
2.7.2. El modelo espiral

El modelo en espiral, propuesto originalmente por
Boehm [BOE88], es un modelo de proceso de soft-
ware evolutivo que conjuga la naturaleza iterativa de
construcci6n de prototipos con 10s aspectos controla-
dos y sistematicos del modelo lineal secuencial. Pro-
porciona el potencial para el desarrollo rapido de
versiones incrementales del software. En el modelo del cliente / Construccidny adaptacidn
espiral, el software se desarrolla en una serie de ver- 0Proyecto de rnantenirniento de productos.
siones incrementales. Durante las primeras iteraccio- 0Proyecto de rnejora de productos.
Proyecto de desarrollo de nuevos productos.
nes, la version incremental podria ser un modelo en Proyecto de desarrollo de conceptos.
papel o un prototipo. Durante las 6ltimas iteraciones,
se producen versiones cada vez mas completas del sis-
tema diseiiado. FIGURA 2.8. Un rnodelo espiral tipico.
C A P ~ T U L O2 EL PROCESO
El modelo en espiral se divide en un numero de acti- mas sofisticadas del software. Cada paso por la region
vidades de marco de trabajo, tambikn llamadas regio- de planificacion produce ajustes en el plan del proyec-
nes de tareas6. Generalmente, existen entre tres y seis to. El coste y la planificacion se ajustan con la reali-
regiones de tareas. La Figura 2.8 representa un modelo mentacion ante la evaluacion del cliente. Ademis, el
en espiral que contiene seis regiones de tareas: gestor del proyecto ajusta el numero planificado de ite-
comunicacion con el cliente- las tareas requeridas raciones requeridas para completar el software.
para establecer comunicaci6n entre el desarrollador
y el cliente.
planificacion- las tareas requeridas para definir
recursos, el tiempo y otra informacion relacionadas
con el proyecto.
analisis de riesgos- las tareas requeridas para eva- Modelo de proceso odoptable.
luar riesgos tCcnicos y de gestion.
ingenieria- las tareas requeridas para construir una A diferencia del modelo de proceso clasico que ter-
o mas representaciones de la aplicacion. mina cuando se entrega el software, el modelo en espi-
construccion y accion- las tareas requeridas para ral puede adaptarse y aplicarse a lo largo de la vida del
construir, probar, instalar y proporcionar soporte a1 software de computadora. Una vision alternativa del
usuario (por ejemplo: documentaci6n y prhctica) modelo en espiral puede ser considerada examinando
el eje de punto de entrada en el proyecto tambikn refle-
evaluacion del cliente- las tareas requeridas para
jado en la Figura 2.8. Cada uno de 10s cubos situados a
obtener la reaccion del cliente segun la evaluacion
lo largo del eje pueden usarse para representar el pun-
de las representaciones del software creadas durante
to de arranqde para diferentes tipos de proyectos. Un
la etapa de ingenieria e implementada durante la
ccproyecto de desarrollo de conceptos)) comienza en el
etapa de instalacion.
centro de la espiral y continuarh (aparecen multiples ite-
raciones a lo largo de la espiral que limita la region som-
breada central) hasta que se completa el desarrollo del
concepto. Si el concepto se va a desarrollar dentro de
10s actividades del marco de trobaio se oplican un producto real, el proceso continlia a travCs del cub0
o cualquier proyecto de software que realice, siguiente (punto de entrada del proyecto de desarrollo
sin tener en cuenta el tamoiio ni lo compleiidod del producto nuevo) y se inicia un ccnuevo proyecto de
desarrollo". El producto nuevo evolucionara a travks de
Cada una de las regiones esthn compuestas por un con- iteraciones alrededor de la espiral siguiendo el camino
junto de tareas del trabajo, llamado &jlrnt&de tareas, que limita la region algo mas brillante que el centro.En
que se adaptan a las caracten'sticas del proyecto que va esencia, la espiral, cuando se caracteriza de esta forma,
a emprenderse. Para proyectos pequeiios, el numero de permanece operativa hasta que el software se retira. Hay
tareas de trabajo y su formalidad es bajo. Para proyectos veces en que el proceso esta inactive, per0 siempre que
mayores y mas criticos cada region de tareas contiene se inicie un cambio, el proceso arranca en el punto de
tareas de trabajo que se definen para lograr un nivel mas entrada adecuado (por ejemplo: mejora del producto).
alto de formalidad. En todos 10s casos, se aplican las acti- El modelo en espiral es un enfoque realista del desa-
vidades de proteccion (por ejemplo: gestion de configu- rrollo de sistemas y de software a gran escala. Como el
ration del software y garantia de calidad del software) software evoluciona, a medida que progresa el proceso
mencionadas en la Seccidn 2.2. el desarrollador y el cliente comprenden y reaccionan
mejor ante riesgos en cada uno de 10s niveles evoluti-
~ Q uesi un conjunto de
vos. El modelo en espiral utiliza la construcci6n de pro-
9 tareas?
totipos como mecanismo de reduccion de riesgos, pero,
Cuando empieza este proceso evolutivo, el equipo lo que es mas importante, permite a quien lo desarrolla
de ingenieria del software gira alrededor de la espiral aplicar el enfoque de construccion de prototipos en cual-
en la direccion de las agujas del reloj, comenzando por quier etapa de evolucion del producto. Mantiene el enfo-
el centro. El primer circuit0 de la espiral puede produ- que sistematico de 10s pasos sugeridos por el ciclo de
cir el desarrollo de una especificaci6n de productos; 10s vida clasico, per0 lo incorpora a1 marco de trabajo ite-
pasos siguientes en la espiral se podrian utilizar para rativo que refleja de forma mas realista el mundo real.
desarrollar un prototipo y progresivamente versiones El modelo en espiral demanda una consideraci6n direc-
El modelo en espiral de esta seccion es una variante sobre el modelo

propuesto por Boehm. Para mas informacion sobre el modelo en espi-
ral original, consulte [BOE88]. Un tratado mas reciente del modelo
en espiral puede encontrarse en [BOE98].
INGENlERfA DEL SOFTWARE. UN ENFOQUE PRACTICO
ta de 10s riesgos tCcnicos en todas las etapas del pro- El modelo en espiral WINWIN de Boehm [BOE98]
yecto, y, si se aplica adecuadamente, debe reducir 10s define un conjunto de actividades de negociaci6n a1 prin-
riesgos antes de que se conviertan en problem8ticos. cipio de cada paso alrededor de la espiral. Mas que una
simple actividad de comunicacidn con el cliente, se defi-
nen las siguientes actividades:
M o d e h evoluiivos tom el modelo en espiral, son Identificaci6n del sistema o subsistemas clave de 10s
apmpiados, porticdonnente, para el desonolla de ctdirectivo~>>~.
sisternos orientados a obietos. Poro mbs detolles, vhse
lo Pork cuorto.
Determinaci6n de las cccondiciones de victoria,) de
10s directivos.
Pero a1 igual que otros paradigmas, el modelo en Negociaci6n de las condiciones de <<victoria>> de 10s
espiral no es la panacea. Puede resultar dificil conven- directivos para reunirlas en un conjunto de condi-
cer a grandes clientes (particularmente en situaciones ciones <<victoria-victoria,,para todos 10s afectados
bajo contrato) de que el enfoque evolutivo es controla- (incluyendo el equipo del proyecto de software).
ble. Requiere una considerable habilidad para la eva-
luaci6n del riesgo, y cuenta con esta habilidad para el
Cxito. Si un riesgo importante no es descubierto y ges-
tionado, indudablemente surgiran problemas. Final-
mente, el modelo no se ha utilizado tanto como 10s
paradigmas lineales secuenciales o de construcci6n de Hobilidodes de negociocibn
prototipos. Todavia tendrAn que pasar muchos aiios antes
de que se determine con absoluta certeza la eficacia de
este nuevo e importante paradigma. Conseguidos
- completamente estos pasos iniciales se
logra un resultado <<victoria-victoria,,,que sera el crite-
ria clave para continuar con la definici6n del sistema y
2.7.3. El modelo espiral WINWIN del software. El modelo en espiral WINWIN se ilustra
(Victoria8cVictoria) 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 la 2. ldentificar las
comunicaci6n con el cliente. El objetivo de esta activi- condiciones 3a. Reunir las condiciones
dad es mostrar 10s requisitos del cliente. En un contex-
to ideal, el desarrollador simplemente pregunta a1 cliente
lo que se necesita y el cliente proporciona detalles sufi-
cientes para continuar. Desgraciadamente, esto rara-
mente ocurre. En realidad el cliente y el desarrollador
entran en un proceso de negociacibn, donde el cliente
puede ser preguntado para sopesar la funcionalidad,ren-
dimiento, y otros productos o caractensticas del siste- del producto y del proceso,
ma frente a1 coste y a1 tiempo de comercializaci6n. definiciones incluyendo particiones.
del producto
y del proceso.
a$%
CLAVE FIGURA 2.9. El m o d e l o e n e s p i r a l WlNWlN [BOE981.
Lo obtencibn de requisitos del softwore requiere uno
negociaci6n. Tiene exito cuondo ombas portes (cganon)), Ademas del Cnfasis realizado en la negociaci6n ini-
cial, el modelo en espiral WINWIN introduce tres hitos
Las mejores negociaciones se esfuerzan en obtener7 en el proceso, llamados puntos defijacidn [BOE96],
<<victoria-victoria>>.
Esto es, el cliente gana obteniendo que 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 decisi6n
sus necesidades y el desarrollador gana trabajando para antes de continuar el proyecto de software.
conseguir presupuestos y lograr una fecha de entrega En esencia, 10s puntos de fijaci6n representan tres
realista. visiones diferentes del progreso mientras que el pro-
Hay docenas de libros escritos sobre habilidades en la negocia- Un directivo e s alguien en la organization que tiene un interes
cion [p. ej., [FIS91], [DON96], [FAR97]].Es una de las cosas mas directo, por el negocio, en el sistema o producto a construir y puede
importantes que un ingeniero o gestor joven (o viejo) puede apren- ser premiado por un resultado con exito o criticado si el esfuerzo
der. Lea uno. falla.
C A P ~ T U 2L ~EL PROCESO
yecto recorre la espiral. El primer punto de fijacibn, des del usuario, las decisiones de la gestion y 10s resultados de
llamado objetivos del ciclo de vida (OCV), define un las revisiones.
conjunto de objetivos para cada actividad principal El modelo de proceso concurrente se puede repre-
de ingenieria 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 tCcnicas importantes, tareas y estados
definici6n de 10s requisitos del producto/sistema del asociados a ellas. Por ejemplo, la actividad de inge-
nivel m6s alto. El segundo punto de fijacibn, llama- nieria definida para el modelo en espiral (Secci6n
do arquitectura del ciclo de vida (ACV), establece 10s 2.7.2), se lleva a cab0 invocando las tareas siguien-
objetivos que se deben conocer mientras que se defi- tes: modelado de construcci6n de prototipos y/o ani-
ne la arquitectura del software y el sistema. Como lisis, especificaci6n de requisitos y disefio'.
ejemplo, de una parte de la ACV, el equipo del pro-
La Figura 2.10 proporciona una representaci6n esque-
yecto de software debe demostrar que ha evaluado la
m5tica de una actividad dentro del modelo de proceso
funcionalidad de 10s componentes del software reuti-
concurrente. La actividad -an6lisis- se puede encon-
lizables y que ha considerado su impact0 en las deci-
trar en uno de 10s estados1° destacados anteriormente en
siones de arquitectura. La capacidad operativa inicial
cualquier momento dado. De forma similar, otras acti-
(COI) es el tercer punto de fijaci6n y representa un
vidades (por ejemplo: disefio o comunicaci6n con el
conjunto de objetivos asociados a la preparacidn del
cliente) se puede representar de una forma andoga.
software para la instalaci6n/distribucion, preparaci6n
Todas 1as actividades existen concurrentemente, per0
del lugar previamente a la instalaci6n, y la asistencia
residen en estados diferentes. Por ejemplo, a1 principio
precisada de todas las partes que utilizara o manten-
del proyecto la actividad de comunicacidn con el clien-
dr6 el software.
te (no mostrada en la figura) ha finalizado su primera
2.7.4. El modelo d e desarrollo concurrente iteracion y esta en el estado de cambios en esdera. La
actividad de analisis (que estaba en el estado ninguno
Davis y Sitaram [DAV94] han descrito el modelo de mientras que se iniciaba la comunicacion inicial con el
desarrollo concurrente, llamado algunas veces inge- cliente) ahora hace una transici6n a1 estado bajo desa-
nieria concurrente, de la forma siguiente: rrollo. Sin embargo, si el cliente indica que se deben
Los gestores de proyectos que siguen 10s pasos del estado hacer cambios en requisitos, la actividad ancilisis cam-
del proyecto en lo que se refiere a las fases importantes [del
ciclo de vida clisico] no tienen idea del estado de sus proyec-
bia del estado bajo desarrollo a1 estado cambios en
tos. Estos son ejemplos de un intento por seguir 10s pasos extre- espera.
madamente complejos de actividades mediante modelos El modelo de proceso concurrente define una serie
demasiado simples. Tenga en cuenta que aunque un proyecto de acontecimientos que dispararan transiciones de
[grande] estC en la fase de codificacion, hay personal de ese pro- estado a estado para cada una de las actividades de la
yecto implicado en actividades asociadas generalmente a muchas
fases de desarrollo simultineamente. Por ejemplo, ... El perso-
ingenieria del software. Por ejemplo, durante las pri-
nal esta escribiendo requisitos, disefiando, codificando, hacien- meras etapas del disefio, no se contempla una incon-
do pruebas y probando la integracion [todo a1 mismo tiempo]. sistencia del modelo de an6lisis. Esto genera la
Los modelos de procesos de ingenieria del software de Humph- correccidn del modelo de ancilisis de sucesos, que dis-
rey y Kellner [HUM89, KEL891 han mostrado la concurrencia parar6 la actividad de ancilisis del estado hecho a1
que existe para actividades que ocurren durante cualquier fase. estado cambios en espera.
El trabajo mis reciente de Kellner [KEL91] utiliza diagramas
de estado [una notacion que representa los estados de un pro- El modelo de proceso concurrente se utiliza a menu-
ceso] para representar la relacion concurrente que existe entre do como el paradigma de desarrollo de aplicaciones clien-
actividades asociadas a un acontecimiento especifico (por ejem- te/servidorl' (Capitulo 28). Un sistema cliente/servidor
plo: un cambio de requisitos durante el liltimo desarrollo), pero se compone de un conjunto de componentes funciona-
falla en capturar la riqueza de la concurrencia que existe en todas les. Cuando se aplica a cliente/servidor,el modelo de pro-
las actividades de desarrollo y de gestion del software en un
proyecto.. . La mayoria de 10s modelos de procesos de desarro-
ceso concurrente define actividades en dos dimensiones
110 del software son dirigidos por el tiempo; cuanto mas tarde [SHE94]: una dimension de sistemas y una dimension de
sea, mas atrBs se encontrara en el proceso de desarrollo. [Un componentes. Los aspectos del nivel de sistemas se &on-
modelo de proceso concurrente] esta dirigido por las necesida- tan mediante tres actividades: disefio, ensamblaje y u s ~ .
9 Se deberia destacar que el analisis y el diseiio son tareas comple- 'En aplicaciones cliente/servidor, la funcionalidad del software se
jas que requieren un estudio sustancial. Las Partes III y IV del libro divide entre clientes (normalmente PCs) y un sewidor (una ComPu-
consideran estos temas con mas detalle. tadora mas potente) que generalmente mantiene una base de datos
centralizada.
'O Un estado es algun modo extemamente observable del compor-
tamiento.
La dimensi6n de componentes se afronta con dos activi-

.dades: diseiio y realizaci6n. La concurrencia se logra de
dos formas: (1) las actividades de sistemas y de compo-
nentes ocurren simultheamente y pueden modelarse con
el enfoque orientado a objetos descrito anteriormente; (2)
una aplicaci6n clientelservidor tipica se implementa con
muchos componentes, cada uno de 10s cuales se pueden
dlseiiar y realizar concurrentemente. En realidad, el mode-
lo de proceso concurrente es aplicable a todo tip0 de desa- Reperesenta un estado de
rrollo de software y proporciona una imagen exacta del una actrvldad de lngenlerla
del software
estado actual de un proyecto.
FlGURA 2.10. Un elemento del modelo de proceso concurrente.
Las tecnologias de objetos (4.Varte de este libro) pro- La actividad de la ingenieria comienza con la iden-
porcionan el marco de trabajo tCcnico para un modelo tificacion de clases candidatas. Esto se lleva a cab0 exa-
de proceso basado en componentes para la ingenieria minando 10s datos que se van a manejar por parte de la
del software. El paradigma orientado a objetos enfati- aplicacion y el algoritmo que se va a aplicar para con-
za la creaci6n de clases que encapsulan tanto 10s datos seguir el tratamiento". Los datos y 10s algoritmos corres-
como 10s algoritmos que se utilizan para manejar 10s pondientes se empaquetan en una clase.
datos. Si se diseiian y se implementan adecuadamente, Las clases creadas en 10s proyectos de ingenieria del
las clases orientadas a objetos son reutilizables por las software anteriores, se almacenan en una biblioteca de
diferentes aplicaciones y arquitecturas de sistemas basa- clases o diccionario de datos (repository) (Capitulo 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 asi fuera, se extraen de la biblio-
teca y se vuelven a utilizar. Si una clase candidata no resi-
de en la biblioteca, se aplican 10s mCtodos orientados a
objetos (Capitulos 21-23). Se compone asi la primera ite-
racidn de la aplicacidn a construirse, mediante las clases
extraidas de la biblioteca y las clases nuevas construidas
para cumplir las necesidades unicas de la aplicaci6n. El
flujo del proceso vuelve a la espiral y volveri a introdu-
cir por ultimo la iteraci6n ensambladora de componen-
tes a travCs de la actividad de ingeniena.
El modelo de desarrollo basado en componentes con-
FlGURA 2.11. Desarrollo basado en componentes. duce a la reutilizaci6n del software, y la reutilizaci6n pro-
porciona beneficios a 10s ingenieros de software. Segun
El modelo de desarrollo basado en componentes (Fig. estudios de reutilizaci6n, QSM Associates, Inc. informa
2.11) incorpora muchas de las caractensticas del mode- que el ensamblaje de componentes lleva a una reducci6n
lo en espiral. Es evolutivo por naturaleza [NIE92], y exi- del70 por 100 de tiempo de ciclo de desarrollo, un 84
ge un enfoque iterativo para la creacidn del software. por 100 del coste del proyecto y un indice de producti-
Sin embargo, el modelo de desarrollo basado en com- vidad de126.2, comparado con la norma de industria del
ponentes configura aplicaciones desde componentes pre- 16.9 [YOU94].Aunque estos resultados e s t h en funci6n
parados de software (llamados cclases>>en la Fig. 2.11). de la robustez de la biblioteca de componentes, no hay
duda de que el ensamblaje de componentes proporciona
ventajas significativas para 10s ingenieros de software.
El proceso unificado de desarrollo de software
[JAC99] representa un ndmero de modelos de desarro-
110 basados en componentes que han sido propuestos en
Esta e s una descripcion simplificada de definicion de clase. Para

un estudio mas detallado, consulte el Capitulo 20.
la industria. Utilizando el Lenguaje de Modelado Uni- to de vista del usuario). Entonces acopla la funci6n con
ficado (UML), el proceso unificado define 10s compo- un marco de trabajo arquitect6nico que identifica la for-
nentes que se utilizarin para construir el sistema y las ma que tomara el software.
interfaces que conectaran 10s componentes. Utilizando
una combinacion del desarrollo incremental e iterativo,
el proceso unificado define la funci6n del sistema apli- En los CapChrlos 21 y 22 se tmto UML con mbs &tone.
cando un enfoque basado en escenarios (desde el pun-
El modelo de mCtodos formales comprende un conjun- consiguiente permiten que el ingeniero del software des-
to de actividades que conducen a la especificaci6n mate- cubra y corrija errores que no se pudieron detectar de
matica del software de computadora. Los mCtodos otra manera.
formales permiten que un ingeniero de software espe- Aunque todavia no hay un enfoque establecido, 10s
cifique, desarrolle y verifique un sistema basado en com- modelos de mCtodos formales ofrecen la promesa de un
putadora aplicando una notaci6n rigurosa y matemhtica. software libre de defectos. Sin embargo, se ha hablado
Algunas organizaciones de desarrollo del software de una gran preocupaci6n sobre su aplicabilidad en un
actualmente aplican una variaci6n de este enfoque, lla- entorno de gesti6n:
mado ingenieria del software de sala limpia [MIL87, 1. El desarrollo de modelos formales actualmente es
DYE921. bastante caro y lleva mucho tiempo.
2. Se requiere un estudio detallado porque pocos res-
tos mbtodos formoles se trotan en 10s Coptulos 25 y 26. ponsables del desarrollo de software tienen 10s ante-
cedentes necesarios para aplicar mCtodos formales.
Cuando se utilizan mCtodos formales (Capitulos 25 3. Es dificil utilizar 10s modelos como un mecanismo
y 26) durante el desarrollo, proporcionan un mecanis- de comunicaci6n con clientes que no tienen muchos
mo para eliminar muchos de 10s problemas que son difi- conocimientos tCcnicos.
ciles de superar con paradigmas de la ingenieria del No obstante es posible que el enfoque a travCs de
software. La ambigiiedad, lo incompleto y la inconsis- mCtodos formales tenga mas partidarios entre 10s desa-
tencia se descubren y se corrigen mas facilmente -no rrolladores del software que deben construir software
mediante un revisi6n a prop6sito para el caso, sin0 de mucha seguridad (por ejemplo: 10s desarrolladores
mediante la aplicaci6n del analisis matemitic*. Cuan- de avi6nica y dispositivos mCdicos), y entre 10s desa-
do se utilizan mCtodos formales durante el disefio, sir- rrolladores que pasan grandes penurias econdmicas a1
ven corno base para la verificaci6n de programas y por aparecer errores de software.
El tCrmino tkcnicas de cuarta generacidn (T4G) abarca siguientes herramientas: lenguajes no procedimentales
un amplio espectro de herrarnientas de software que tie- de consulta a bases de datos, generaci6n de informes,
nen algo en comun: todas facilitan a1 ingeniero del soft- manejo de datos, interacci6n y definicidn de pantallas,
ware la especificaci6n de algunas caracteristicas del generaci6n de cbdigos, capacidades graficas de alto nivel
software a alto nivel. Luego, la herrarnienta genera auto- y capacidades de hoja de chlculo, y generaci6n auto-
maticamente el c6digo fuente basandose en la especifi- matizada de HTML y lenguajes similares utilizados para
caci6n del tCcnico. Cada vez parece mas evidente que la creaci6n 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, mas rhpido se podra construir el programa. El mientas estaban disponibles, per0 s610 para hmbitos de
paradigma T4G para la ingenieria del software se orien- aplicaci6n muy especificos, per0 actualmente 10s entor-
ta hacia la posibilidad de especificar el software usan- nos T4G se han extendido a todas las categorias de apli-
do formas de lenguaje especializado o notaciones caciones del software.
graficas que describa el problema que hay que resolver A1 igual que otros paradigmas, T4G comienza con
en tCrminos que 10s entienda el cliente. Actualmente, el paso de reuni6n de requisitos. Idealmente, el cliente
un entorno para el desarrollo de software que soporte describe 10s requisitos, que son, a continuaci6n, tradu-
el paradigma T4G puede incluir todas o algunas de las cidos directamente a un prototipo operativo. Sin embar-
I N G E l l E R f A DEL SOFTWARE. U N ENFOQUE PRACTICO
go, en la prictica no se puede hacer eso. El cliente pue- que facilite la realizacidn del mantenimiento de forma
.de que no estC seguro de lo que necesita; puede ser ambi- expeditiva.
guo en la especificacidn de hechos que le son conocidos, A1 igual que todos 10s paradigmas del software, el
y puede que no sea capaz o no estC dispuesto a especi- modelo T4G tiene ventajas e inconvenientes.Los defen-
ficar la informacidn en la forma en que puede aceptar sores aducen reducciones dristicas en el tiempo de desa-
una herramienta T4G. Por esta razdn, el diilogo clien- rrollo del software y una mejora significativa en la
te-desarrollador descrito por 10s 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 mis fficiles de utilizar que 10s lenguajes
de programacidn, que el cddigo fuente producido por
tales herramientas es ccineficiente>>y que el manteni-
lncluso cuondo utilice uno T4G, tiene que destocor miento de grandes sistemas de software desarrollados
clorornente lo ingenieria del sohore hociendo el on~lisis, mediante T4G es cuestionable.
el diserio y 10s pruebos. Hay algun mCrito en lo que se refiere a indicaciones
de ambos lados y es posible resumir el estado actual de
Para aplicaciones pequefias, se puede ir directamen- 10s enfoques de T4G:
te desde el paso de recoleccidn de requisitos a1 paso de El uso de T4G es un enfoque viable para muchas de
implementacidn, usando un lenguaje de cuarta genera- las diferentes ireas de aplicacidn. Junto con las herra-
cidn no procedimental (L4G) o un modelo comprimi- mientas de ingenieria de software asistida por com-
do de red de iconos grificos. Sin embargo, es necesario putadora (CASE) y 10s generadores de cddigo, T4G
un mayor esfuerzo para desarrollar una estrategia de ofrece una solucidn fiable a muchos problemas del
diseAo para el sistema, incluso si se utiliza un L4G. El software.
uso de T4G sin disefio (para grandes proyectos) causa- Los datos recogidos en compafiias que usan T4G
rfi las mismas dificultades (poca calidad, mantenimien- parecen indicar que el tiempo requerido para produ-
to pobre, mala aceptacidn por el cliente) que se cir software se reduce mucho para aplicaciones
encuentran cuando se desarrolla software mediante 10s pequefias y de tamafio medio, y que la cantidad de
enfoques convencionales. anfilisis y disefio para las aplicaciones pequefias tam-
La implementacidn mediante L4G permite, a1 que biCn se reduce.
desarrolla el software, centrarse en la representacidn de
10s resultados deseados, que es lo que se traduce auto- Sin embargo, el uso de T4G para grandes trabajos de
mfiticamente en un cddigo fuente que produce dichos desarrollo de software exige el mismo o mis tiempo
resultados. Obviamente, debe existir una estructura de de anilisis, disefio y prueba (actividades de ingenie-
datos con informacidn relevante y a la que el LAG pue- ria del software), para lograr un ahorro sustancial de
da acceder ripidamente. tiempo que puede conseguirse mediante la elimina-
Para transformar una implementacidn T4G en un cidn de la codificacidn.
producto, el que lo desarrolla debe dirigir una prueba Resumiendo, las tCcnicas de cuarta generacidn ya se
completa, desarrollar con sentido una documentacidn han convertido en una parte importante del desarrollo
y ejecutar el resto de las actividades de integracidn que de software. Cuando se combinan con enfoques de
son tambiCn requeridas requeridas por otros paradig- ensamblaje de componentes (Seccidn 2.8), el paradig-
mas de ingenieria del software. Ademis, el software ma T4G se puede convertir en el enfoque dominante
desarrollado con T4G debe ser construido de forma hacia el desarrollo del software.
Los modelos de procesos tratados en las secciones ante- cidn tratadas en la Seccidn 2.3. El modelo, presentado
riores se deben adaptar para utilizarse por el equipo del normalmente como una red, se puede analizar para deter-
proyecto del software. Para conseguirlo, se han desarro- minar el flujo de trabajo tipico y para examinar estruc-
llado herramientas de tecnologia de procesos para ayudar turas altemativas de procesos que pudieran llevar a un
a organizaciones de software a analizar 10s procesos actua- tiempo o coste de desarrollo reducidos.
les, organizar tareas de trabajo, controlar y supervisar el Una vez que se ha creado un proceso aceptable, se
progreso y gestionar la calidad tCcnica [BAN95]. pueden utilizar otras herramientas de tecnologia de pro-
Las herramientas de tecnologia de procesos permi- cesos para asignar, supervisar e incluso controlar todas
ten que una organizacidn de software construya un las tareas de ingenieria del software definidas como par-
modelo automatizado del marco de trabajo comun de te del modelo de proceso. Cada uno de 10s miembros
proceso, conjuntos de tareas y actividades de protec- de un equipo de proyecto de software puede utilizar tales
[BAE98] Baetjer, H., Jr., Software as Capital, IEEE Compu- 11th lntl. Conference on Software Engineering, IEEE Com-
ter Society Press, 1998, p. 85. puter Society Press, pp. 331-342.
[BAN951 Bandinelli, S. et al, {{Modelingand Improving an [IEE93] IEEE Standards Collection: Software Engineering,
Industrial Software Process,,, IEEE Trans. Software Engi- IEEE Standard 6 10.12-1990, IEEE, 1993.
neering, vol. 21, n.", Mayo 1995, pp. 440-454. [JAC99] Jacobson, I., G. Booch y J. Rumbaugh, The Unified
[BRA941 Bradac, M., D. Perry y L. Votta, pro to typing a Pro- Software Developement Proccess, Addison-Wesley, 1999.
cess Monitoring Experiment", IEEE Trans. Software Engi-
[KEL89] Kellner, M., Software Process Modeling: Value and
neering, vol. 20, n."O, Octubre 1994, pp. 774-784.
Experience, SEI Technical Review- 1989, SEI, Pittsburgh,
[BOE88] Boehm, B., ccA Spiral Model for Software Develo- PA, 1989.
pement and Enhancement", Computer, vol. 21, n." 5, Mayo
1988, pp. 61-72. [KEL91] Kellner, M., ccsoftware Process Modeling Support
for Management Planning and Control,,, Proc. 1st Intl.
[BOE96] Boehm, B., <<Anchoringthe Software Pocess,,, IEEE Conf, On the Software Process, IEEE Computer Society
Software, vol. 13, n."4, Julio 1996, pp.73-82. Press, 1991, pp. 8-28.
[BOE98] Boehm, B., <<Usingthe WINWIN Spiral Model: A [KER94] Ken; J., y R. Hunter, Inside RAD, McGraw-Hill, 1994.
Case Study,,, Computer, vol. 31, n."7, Julio 1998, pp. 33-
44. [MAR911 Martin, J., Rapid Aplication Developement, Pren-
tice-Hall, 1991.
[BR075] Brooks, F., The Mytical Man-Month, Addison-Wes-
ley, 1975. [MDE93] McDermid, J. y P. Rook, ccsoftware Developement
Process Models,,, en Software Ingineer's Reference Book,
[BUT941 Butler, J., <<RapidAplication Developement in CRC Press, 1993, pp. 15126-15128.
Action,,, Managing System Developement, Applied Com-
puter Research, vol. 14, n." 5, Mayo 1995, pp. 6-8. [MIL871 Mills, H.D., M. Dyer y R. Linger, ccclearoom Soft-
ware Engineering,,, IEEE Software, Septiembre 1987, pp.
[DAV94] Davis, A., y P. Sitaram, ccA Concurrent Process 19-25.
Model for Software Developement,,, Software Enginee-
ring Notes, ACM Press, vol. 19, n." 2, Abril 1994, pp. 38- [NAU69] Naur, P., y B. Randall (eds.), Software Engineering:
5 1. A Report on a Conference sponsored by the NATO Scien-
ce Committee, NATO, 1969.
[DAV95] Davis, M.J., ccprocess and Product: Dichotomy or
Duality,,, Software Engineering Notes, ACM Press, vol. [NIE92] Nierstrasz, <Component-Oriented Software Deve-
20, n." 2, Abril 1995, pp. 17- 18. lopement,,, CACM, vol. 35, n." 9, Septiembre 1992, pp.
160-165.
[DON961 Donaldson, M.C., y M. Donaldson, Negotiating for
Dummies, IDB Books Worldwide, 1996. [PAU93] Paulk, M., et al., cccapability Maturity Model for
[DYE921 Dyer, M., The Cleanroom Approach to Quality Soft- Software,,, Software Engineering Institute, Carnegie
ware Developement, Wiley, 1992. Mellon University, Pittsburgh, PA, 1993.
[FAR971 Farber, D.C., Common Sense Negotiation: The Art [RAC95] Raccoon, L.B.S, <<TheChaos Model and the Chaos
of Winning Gracefully, Bay Press, 1997. Life Cycle,,, ACM Software Engineering Notes, vol. 20,
n." , Enero 1995, pp. 55-66.
[FIS91] Fisher, R., W. Ury y Bruce Patton, Getting to Yes:
Negotiating Agreement Without Giving In, 2." ed., Penguin [ROY701Royce, W.W., <<Managingthe Developement of Large
USA, 199 1. Software Systems: Concepts and Techniques,,, Proc. WES-
CON, Agosto 1970.
[GIL88] Gilb, T., Principles of Software Engineering Mana-
gement, Addison-Wesley, 1988. [SHE941 Sheleg, W., ccConcurrent Engineering: A New Para-
dign for CIS Developement,,, Application Developement
[HAN95] Hanna, M., <<Farewellto Waterfalls,,, Software Trends, vol. 1, n." 6, Junio 1994, pp. 28-33.
Magazine, Mayo 1995, pp.38-46.
[YOU941 Yourdon, E., ccsoftware Reuse,,, Application Deve-
[HUM891 Humphrey, W., y M. Kellner, c<SoftwareProcess lopement Strategies, vol. VI, n." 12, Diciembre 1994, pp.
Modeling: Principles of Entity Process Models,,, Proc. 1-16.
2.1. La Figura 2.1 sitda las tres capas de ingenieria del soft- 2.2. hay algun caso en que no se apliquen fases genCricas
ware encima de la capa titulada ccenfoque de calidad,,. Esto del proceso de ingenieria del software? Si es asi, describalo.
implica un programa de calidad tal como Gestidn de Cali- 2.3. El Modelo Avanzado de Capacidad del SEI es un docu-
dad Total. Investigue y desarrolle un esquema de 10s prin- mento en evoluci6n. Investigue y determine si se han aiia-
cipios clave de un programa de Gesti6n de Calidad Total. dido algunas ACP nuevas desde la publicaci6n de este libro.
2.4. El modelo del caos sugiere que un bucle de resoluci6n de 2.8. Proponga un proyecto especifico de software que sea ade-
problemas se pueda aplicar en cualquier grado de resolucibn. cuado para el modelo incremental. Presente un escenario para
Estudie la forma en que se aplicaria el bucle (1) para com- aplicar el modelo a1 software.
prender 10s requisitos de un producto de tratamiento de texto; 2.9. A medida que vaya hacia afuera por el modelo en espiral,
(2) para desarrollar un componente de correccidn ortogrifica iquC puede decir del software que se esth desarrollando o man-
y gramitica avanzado para el procesador de texto; (3) para teniendo?
generar el c6digo para un m6dulo de programa que determi-
ne el sujeto, predicado y objeto de una oraci6n en inglCs. 2.10. Muchas personas creen que la h i c a forma en la que se
van a lograr mejoras de magnitud en la calidad del software y
2.5. ~ Q u Cparadigmas de ingeniena del software de 10s presen- en su productividad es a travCs del desarrollo basado en com-
tados en este capitulo piensa que sena el mis eficaz? iPor quC?
ponentes. Encuentre tres o cuatro articulos recientes sobre el
2.6. Proporcione cinco ejemplos de proyectos de desarrollo asunto y resdmalos para la clase.
del software que Sean adecuados para construir prototipos.
2.11. Describa el modelo de desarrollo concurrente con sus
Nombre dos o tres aplicaciones que fueran mis dificiles para
propias palabras.
construir prototipos.
2.12. Proporcione tres ejemplos de tCcnicas de cuarta genera-
2.7. El modelo DRA a menudo se une a herramientas CASE.
ci6n.
Investigue la literatura y proporcione un resumen de una herra-
mienta tipica CASE que soporte DRA. 2.13. iQuC es mis importante, el producto o el proceso?
El estado actual del arte en la ingenieria del software se puede controvertidos y amenos sobre el software y el proceso de la
determinar mejor a partir de publicaciones mensuales tales como ingenieria del software. Pressman y Herron (Sofhare Shock,
IEEE Software, Computer e IEEE Transactions on Software Dorset House, 1991) consideran el software y su impact0
Engineering. Peri6dicos sobre la industria tales como Applica- sobre particulares, empresas y el gobiemo.
tion Developement Trends, Cutter ITJournal y Software Deve- El Instituto de ingenieria del software (11s localizado en
lopement a menudo contienen articulos sobre temas de ingenieria la Universidad de Carnegie-Mellon) ha sido creado con la
del software. La disci~linase <<resume>> cada aiio en el Proce- responsabilidad de promocionar series monogrificas sobre
eding of the International Conference on Software Engineering, la ingenieria del software. Los profesionales acadCmicos,
promocionado por el IEEE y ACM y tratado en profundidad en en la industria y el gobierno estin contribuyendo con nue-
peribdicos como ACM Transactions on Software Engineering vos trabajos importantes. El Consorcio de Productividad del
and Methodology, ACM Software Engineering Notes y Annals Software dirige una investigaci6n adicional de ingenieria
of Software Engineering. de software.
Se han publicado muchos libros de ingenieria del softwa- En la ultima dCcada se ha publicado una gran variedad de
re en 10s ultimos afios. Algunos presentan una visi6n general est6ndares y procedimientos de ingenieria del software. El IEEE
del proceso entero mientras que otros se dedican a unos pocos Software Engineering Standards contiene muchos esthndares
temas importantes para la exclusi6n de otros. Las siguientes diferentes que abarcan casi todos 10s aspectos importantes de
son tres antologias que abarcan algunos temas importantes la tecnologia. Las directrices I S 0 9000-3 proporcionan una
de ingenieria del software: guia para las organizacionesde software que requieren un regis-
Keyes, J. (ed.), Software Engineering Productivity Hund- tro en el estandar de calidad I S 0 9001. Otros estindares de
book, McGraw-Hill, 1993. ingenieria del software se pueden obtener desde el MOD, la
McDermid, J. (ed.), Software Engineer's Reference Book, Autoridad Civil de Aviacidn y otras agencias del gobiemo y
CRC Press, 1993. sin inimo de lucro. Fairclough (Software Engineering Guides,
Marchiniak, J.J. (ed.), Encyclopedia of Software Engine- Prentice-Hall, 1996) proporciona una referencia detallada de
ering, Wiley, 1994. 10s estindares de ingenieria del software producidos por Euro-
Gautier (Distributed Engineering of Sofmare, Prentice- pean Space Agency (ESA).
Hall, 1996) proporciona sugerencias y directrices para orga- En internet se dispone de una gran variedad de fuentes de
nizaciones que deban desarrollar software en lugares informaci6n sobre la ingenieria del software y del proceso de
geograficamente distantes. software. Se puede encontrar una lista actualizada con refe-
En la parte mis brillante del libro de Robert Glass (Soft- rencias a sitios (p8ginas) web que son relevantes para el pro-
ware conflict, Yourdon Press, 1991) se presentan ensayos ceso del software en http://www.pressman5.com.
La gestion eficaz de un proyecto de software se cen- 3.1.2. Producto

tra en las cuatro P's: personal, producto, proceso y Antes de poder planificar un proyecto, se debenan esta-
proyecto. El orden no es arbitrario. El gestor que se blecer 10s objetivos y el Ambito del producto', se debe-
olvida de que el trabajo de ingenieria del software es rim considerar soluciones alternativas e identificar las
un esfuerzo humano intenso nunca tendra Cxito en la dificultades tCcnicas y de gestion. Sin esta informaci6n,
gesti6n de proyectos. Un gestor que no fomenta una es imposible definir unas estimaciones razonables (y
minuciosa comunicaci6n con el cliente a1 principio exactas) del coste; una valoraci6n efectiva del riesgo,
de la evoluci6n del proyecto se arriesga a construir una subdivision realista de las tareas del proyecto o una
una elegante soluci6n para un problema equivocado. planificacion del proyecto asequible que proporcione
El administrador que presta poca atencion a1 proce- una indicacion fiable del progreso.
so come el riesgo de arrojar mCtodos tCcnicos y herra-
mientas eficaces a1 vacio. El gestor que emprende un
proyecto sin un plan solido arriesga el Cxito del pro-
duct~. En el Capitulo 1 se trot0 uno toxonomh de las hens
de oplicodbn que producen 10s upmductos~de whore.
3.1.1. Personal
La necesidad de contar con personal para el desarrollo
del software altamente preparado y motivado se viene El desarrollador de software y el cliente deben reunir-
discutiendo desde 10s afios 60 (por ejemplo, [COUSO, se para definir 10s objetivos del producto y su h b i t o . En
WIT94, DEM981). De hecho, el <<factor humanon es tan muchos casos, esta actividad empieza como pate del pro-
importante que el Instituto de Ingenieria del Software ceso de ingenieria del sistema o del negocio (Capitulo 10)
ha desarrollado un Modelo de madurez de la c.apacidad y continlia como el primer paso en el analisis de 10s requi-
de gestidn de personal (MMCGP) <<paraaumentar la sitos del software (Capitulo 11). Los objetivos identifican
preparation de organizaciones del software para llevar las metas generales del proyecto sin considerar cdmo se
a cab0 las cada vez mas complicadas aplicaciones ayu- conseguiran (desde el punto de vista del cliente).
dando a atraer, aumentar. motivar, desplegar y retener El ambit0 identifica 10s datos primarios, funciones y
el talent0 necesario para mejorar su capacidad de desa- comportamientos que caracterizan a1 producto, y, m8s
rrollo de softwaren [CUR94]. importante, intenta ahordar estas caracteristicas de una
manera cuantitativa.
Una vez que se han entendido 10s objetivos y el ambi-
to del producto, se consideran sol~!cionesalternativas.
3.1.3. Proceso
Un proceso de software (Capitulo 2) proporciona la
estructura desde la que se puede establecer un detalla-
do plan para el desarrollo del software. Un pequeiio
El modelo de madurez de gesti6n de personal defi- nlimero de actividades estructurales se puede aplicar a
ne las siguientes areas clave pr8cticas para el personal todos 10s proyectos de software, sin tener en cuenta su
que desarrolla software: reclutamiento, selection, ges- tamafio o complejidad. Diferentes conjuntos de tareas
tion de rendimiento, entrenamiento, retribucion, desa- -tareas, hitos, productos del trabajo y puntos de garan-
rrollo de la carrera, disefio de la organizaci6n y del tia de calidad- permiten a las actividades estructura-
trabajo y desarrollo cultural y de espiritu de equipo. les adaptarse a las caracteristicas del proyecto de
El MMCGP es compaiiero del modelo de madurez software y a 10s requisitos del equipo del proyecto. Figal-
de la capacidad software (Capitulo 2), que guia a las mente, las actividades protectoras -tales como garan-
organizaciones en la creaci6n de un proceso de software tia de calidad del software, gestidn de la configuracidn
maduro. Mas adelante en este capitulo se consideran del software y medicion- cubren el modelo de proce-
aspectos asociados a la gesti6n de personal y estructu- so. Las actividades protectoras son independientes de
ras para proyectos de software. las estructurales y tienen lugar a lo largo del proceso.
En este contexto, el termino ~~producto))

es usado para abarcar cual-
quier software que sera construido a peticion de otros. Esto incluye
no solo productos de software, sino tambien sistemas basados en
computadora, sottware empotrado y software de resolucion de pro-
blemas (por ejemplo, programas para la resolucion de problemas
cientificos/de ingenieria).
C A P ~ T U L O3 CONCEPTOS SOBRE G E S T I ~DE
N PROYECTOS
por 100 experimentaron un desbordamiento en la pla-

nificacion y en el coste [REE99]. Aunque la proporcion
de Cxito para 10s proyectos de software ha mejorado un
Las atividades eseucturales se componen de toreas, hitos, poco, nuestra proporcion de fracaso de proyecto per-
productos de trabaio y puntos de gorantic de calidad. manece mas alto del que deberia ser2.
Para evitar el fracaso del proyecto, un gestor de pro-
yectos de software y 10s ingenieros de software que
3.1.4. Proyecto construyeron el producto deben eludir un conjunto de
Dirigimos 10s proyectos de software planificados y con- seiiales de peligro comunes; comprender 10s factores
trolados por una razon principal --es la unica manera del Cxito criticos que conducen a la gestion correcta del
conocida de gestionar la complejidad-. Y todavia proyecto y desarrollar un enfoque de sentido comun
seguimos esforz8ndonos. En 1998,los datos de la indus- para planificar, supemisar y controlar el proyecto. Cada
tria del software indicaron que el 26 por 100 de pro- uno de estos aspectos se trata en la Secci6n 3.5 y en 10s
yectos de software fallaron completamente y que el 46 capitulos siguientes.
En un estudio publicado por el IEEE [CUR881 se les del software, damos este aspect0 por descontado. Los
pregunt6 a 10s vicepresidentes ingenieros de tres gran- gestores argumentan (corno el grupo anterior) que el
des compaiiias tecnologicas sobre el factor mas impor- personal es algo primario, per0 10s hechos desmienten
tante que contribuye a1 Cxito de un proyecto de software. a veces sus palabras.
Respondieron de la siguiente manera: En esta section exarninamos 10s participantes que cola-
VP I: Supongo que si tuviera que elegir lo mis importante boran en el proceso del software y la manera en que se
de nuestro entorno de trabajo, diria que no son las organizan para realizar una ingenieria del software eficaz.
herramientas que empleamos, es la gente.
VP 2: El ingrediente mis importante que contribuyo a1 exi- 3.2.1. Los participantes
to de este proyecto h e tener gente lista ... pocas cosas
mas importan en mi opinion ... Lo mis importante El proceso del software (y todos 10s proyectos de soft-
que se puede hacer por un proyecto es seleccionar el ware) lo componen participantes que pueden clasificarse
personal ... El exit0 de la organization de desarrollo en una de estas cinco categorias:
del software esta muy, muy asociado con la habili-
dad de reclutar buenos profesionales.
Gestores superiores, que definen 10s aspectos de
negocios que a menudo tienen una significativa
VP 3: La unica regla que tengo en cuanto a la gestion influencia en el proyecto.
es asegurarme de que tengo buenos profesionales
-gente realmente buena-, de que preparo bue- Gestores (te'cnicos)del proyecto, que deben planifi-
na gente y de que proporciono el entorno en el car, motivar, organizar y controlar a 10s profesiona-
que 10s buenos profesionales puedan producir. les que realizan el trabajo de software.
Profesionales, que proporcionan las capacidades tdc-
nicas necesarias para la ingenieria de un producto o
aplicacion.
sensiblemente Clientes, que especifican 10s requisitos para la inge-
largo prosperorin. nieria del software y otros elementos que tienen
menor influencia en el resultado.
Usuariosfinales, que interaccionan con el software
Ciertamente, Cste es un testimonio convincente sobre una vez que se ha entregado para la produccion.
la importancia del personal en el proceso de ingenieria Para ser eficaz, el equipo del proyecto debe organizarse
del software. Y, sin embargo, todos nosotros, desde 10s de manera que maximice las habilidades y capacidades
veteranos vicepresidentes a1 m8s modesto profesional de cada persona. Y este es el trabajo del jefe del equipo.
Dadas estas estadisticas,es razonable preguntarse corno el irnpacto

de las cornputadoras continua creciendo exponencialmente y la indus-
tria del soRware continua anunciando el crecimiento de ventas al doble.
Parte de la respuesta, pienso, es que un importante nlimero de estos
proyectos ~~fallidos~~
estan ma1 concebidos desde el primer momento.
Los clientes pierden el interes rapidamente (puesto que lo que ellos
pidieron realrnente no era tan importante corno ellos habian pensado),
y 10s proyectos son cancelados.
~ N G E N I E R ~DEL
A SOFTWARE. UN ENFOOUE PRACTICO
3.2.2. Los jefes d e equipo Incentivos por logros. Para optimizar la productividad de
un equipo de proyecto, un gestor debe recompensar la inicia-
La gestidn de un proyecto es una actividad intensamente tiva y 10s logros, y demostrar a travks de sus propias acciones
humana, y por esta razdn, 10s profesionales competen- que no se penalizarh si se corren riesgos controlados.
tes del software a menudo no son buenos jefes de equi- Influencia y construcci6n de esplritu de equipo. Un ges-
po. Simplemente no tienen la mezcla adecuada de tor de proyecto eficiente debe ser capaz de ccleer* a la gente;
capacidades del personal. Y sin embargo, como dice debe ser capaz de entender setiales verbales y no verbales y
Edgemon: ccDesafortunadamente y con demasiada fre- reaccionar ante las necesidades de las personas que mandan
cuencia, hay individuos que terminan en la gestidn de esas setiales. El gestor debe mantener el control en situaciones
proyectos y se convierten en gestores de proyecto acci- de gran estres.
dentales>>[EDG95].
iEn que nos fijamos cuando

selecdonamos a alguien para On experto de sofhvore puede no tener temperomento o
conducir un proyetlo de software? deseo de ser jefe de equipo. No fuerce 01 experto poro ser
uno de ellos.
En un excelente libro sobre gestidn tCcnica, Jerry

Weinberg [WE1861 sugiere el modelo de gesti6n MOI: 3.2.3. El equipo d e software
Motivaci6n. La habilidad para motivar (con un cctira y aflo- Existen casi tantas estructuras de organizacidn de perso-
ja>)al personal tknico para que produzca conforme a sus meje
res capacidades.
nal para el desarrollo de software como organizaciones
que se dedican a ello. Para bien o para mal, el organi-
Organizacion. La habilidad para amoldar procesos exis- grama no puede cambiarse fhcilmente. Las consecuen-
tentes (o inventar unos nuevos) que permita a1 concept0 inicial
transformarse en un producto final. cias prhcticas y politicas de un carnbio de organizacidn
no estfin dentro del alcance de las responsabilidades del
Ideas o innovacion. La habilidad para motivar a1 personal
para crear y sentirse creativos incluso cuando deban de traba-
gestor de un proyecto de software. Sin embargo, la orga-
jar dentro de 10s limites establecidos para un producto o apli- nizacidn del personal directamente involucrado en un
cacion de software particular. nuevo proyecto de software esta dentro del ambit0 del
gestor del proyecto.
Las siguientes opciones pueden aplicarse a 10s recur-
sos humanos de un proyecto que requiere n personas
el que sabe a trabajando durante k aiios:
n individuos son asignados a m diferentes tareas fun-
cionales, tiene lugar relativamente poco trabajo con-
junto; la coordinacidn es responsabilidad del gestor
del software que puede que tenga otros seis proyec-
Weinberg sugiere que el Cxito de 10s gestores de pro-
tos de 10s que preocuparse.
yecto se basa en aplicar un estilo de gesti6n en la reso-
luci6n de problemas. Es decir, un gestor de proyectos de
software deberia concentrarse en entender el problema
que hay que resolver, gestionando el flujo de ideas y, a1
mismo tiempo, haciendo saber a todos 10s miembros del
equipo (mediante palabras y, mucho mas importante,
con hechos) que la calidad es importante y que no debe
verse comprometida.
Otro punto de vista [EDG95] de las caracteristicas
n individuos son asignados a m diferentes tareas fun-
que definen a un gestor de proyectos eficiente resalta
cionales ( m a ) de manera que se establecen ccequi-
cuatro apartados clave:
pow informales; se puede nombrar un lider al efecto;
Resolucion del problerna. Un gestor eficiente de un pro- la coordinacidn entre 10s equipos es responsabilidad
yecto de software puede diagnosticar 10s aspectos tCcnicos y
de organizaci6nmis relevantes, estructurar una soluci6n siste- de un gestor del software.
maticamente o motivar apropiadamente a otros profesionales n individuos se organizan en t equipos; a cada equipo
para que desarrollen la soluci6n, aplicar las lecciones aprendi- se le asignan una o mhs tareas funcionales; cada
das de anteriores proyectos a las nuevas situaciones, mante- equipo tiene una estructura especifica que se define
nerse lo suficientementeflexible para cambiar la gesti6n si 10s
intentos iniciales de resolver el problema no dan resultado.
para todos 10s equipos que trabajan en el proyecto;
la coordinaci6n es controlada por el equipo y por el
Dotes de gestion. Un buen gestor de proyectos debe tomar gestor del proyecto de software.
las riendas. Debe tener confianza para asumir el control cuan-
do sea necesario y la garantis para permitir que 10s buenos ttc- Aunque es posible encontrar argumentos en pro y en
nicos sigan sus instintos. contra para cada uno de 10s enfoques anteriores, existe
CAPfTULO 3 CONCEPTOS SOBRE G E S T I ~ N
DE PROYECTOS
una gran evidencia que indica que una organizaci6n de jar problemas sencillos. Los equipos descentralizados
equipo formal (opci6n 3) es la mas productiva. generan rnis y mejores soluciones que 10s individua-
La ccmejor,, estructura de equipo depende del esti- les. Por tanto, estos equipos tienen rnis probabilidades
lo de gesti6n de una organizaci6n, el numero de per- de Cxito en la resoluci6n de problemas complejos. Pues-
sonas que compondri el equipo, sus niveles de to que el equipo DC es centralizado para la resoluci6n
preparaci6n y la dificultad general del problema. Man- de problemas, tanto el organigrama de equipo DC como
tei [MAN811 sugiere tres organigramas de equipo el de CC pueden aplicarse con Cxito para problemas
genCricos: sencillos. La estructura DD es la mejor para problemas
Descentralizado democratic0 (DD). Este equipo de dificiles.
ingenieria del software no tiene un jefe permanente. Mis Como el rendimiento de un equipo es inversamente
bien, ccse nombran coordinadores de tareas a corto plazo y proporcional a la cantidad de comunicaci6n que se debe
se sustituyen por otros para diferentes tareas,. Las deci- entablar, 10s proyectos muy grandes son mejor dirigi-
siones sobre problemas y 10s enfoques se hacen por con- dos por equipos con estructura CC o DC, donde se pue-
senso del grupo. La comunicaci6n entre 10s miembros del
equipo es horizontal. den formar ficilmente subgrupos.
El tiempo que 10s miembros del equipo vayan a
ccvivir juntos,, afecta a la moral del equipo. Se ha des-
iComo deberia estar cubierto que 10s organigramas de equipo tipo DD pro-
organizado un equipo
ducen una moral m i s alta y rnis satisfacci6n por el
de software?
trabajo y son, por tanto, buenos para equipos que per-
manecerin juntos durante mucho tiempo.
Descentralizado controlado (DC). Este equipo de inge- El organigrama de equipo DD se aplica mejor a pro-
nien'a del software tiene un jefe definido que coordina tare- blemas con modularidad relativamente baja, debido a
as especificas y jefes secundarios que tienen responsabilidades
sobre subtareas. La resoluci6n de problemas sigue siendo la gran cantidad de comunicaci6n que se necesita. Los
una actividad del grupo, pero la implernentacion de solu- organigramas CC o DC funcionan bien cuando es posi-
ciones se reparte entre subgrupos por el jefe de equipo. La ble una modularidad alta (y la gente puede hacer cada
comunicacion entre subgrupos e individuos es horizontal. uno lo suyo).
Tambien hay comunicacion vertical a lo largo de la jerarquia
de control.
Centralizado controlado (CC). El jefe del equipo se
encarga de la resoluci6n de problemas a alto nivel y la coor-
dinacion intema del equipo. La comunicaci6n entre el jefe y Frecuentemente es mejor tener pocos equipos pequeios,
10s miembros del equipo es vertical. bien centrodos que un gron equipo solomente.
Mantei [MAN811 describe siete factores de un pro-
yecto que deberian considerarse cuando se planifica el Los equipos CC y DC producen menos defectos que
organigrama de equipos de ingenieria del software: 10s equipos DD, per0 estos datos tienen mucho que ver
la dificultad del problema que hay que resolver con las actividades especificas de garantia de calidad
el tamafio del programa(s) resultante(s) en lineas de que aplica el equipo. Los equipos descentralizados
c6digo o puntos de funci6n (Capitulo 4) requieren generalmente mis tiempo para completar un
proyecto que un organigrama centralizado y a1 mismo
el tiempo que el equipo estari junto (tiempo de vida
tiempo son mejores cuando se precisa una gran canti-
del equipo)
dad de comunicaci6n.
el grado en que el problema puede ser modulari- Constantine [CON931 sugiere cuatro ccparadigmas
zado de organizaci6n~para equipos de ingenieria del soft-
ware:
iQue factores Un paradigma cerrado estructura a un equipo con
deberiamos considerar una jerarquia tradicional de autoridad (similar a1
cuando estruduramos equipo CC). Estos equipos trabajan bien cuando pro-
un equipo de software? ducen software similar a otros anteriores, per0 pro-
bablemente Sean menos innovadores cuando trabajen
dentro de un paradigma cerrado.
la calidad requerida y fiabilidad del sistema que se
va a construir El paradigma aleatorio estructura a1 equipo libre-
la rigidez de la fecha de entrega mente y depende de la iniciativa individual de 10s
miembros del equipo. Cuando se requiere innova-
el grado de sociabilidad (comunicaci6n) requerido ci6n o avances tecnol6gicos, 10s equipos de para-
para el proyecto digma aleatorio son excelentes. Pero estos equipos
Debido a que una estructura centralizada realiza las pueden chocar cuando se requiere un ccrendimiento
tareas rnis ripidamente, es la rnis adecuada para mane- ordenadon.
I N G E N I E R ~ ADEL SOFTWARE. UN ENFOQUE P R h C T l C O
3. El paradigma abierto intenta estructurar a un equipo nen una definicion comun de Cxito o un espiritu de equi-
. de manera que consiga algunos de 10s controles aso- po identificable. Lo que falta es un fenomeno que deno-
minan~oscuajar-.
ciados con el paradigma cerrado, per0 tambien
mucha de la innovacion que tiene lugar cuando se Un equipo cuajado es un grupo de gente tejido tan fuer-
utiliza el paradigma aleatorio. El trabajo se desa- temente que el todo es mayor que la suma de las partes ...
rrolla en colaboracion, con mucha comunicacion y Una vez que el equipo empieza a cuajar, la probabilidad
toma de decisiones consensuadas y con el sello de de Cxito empieza a subir. El equipo puede convertirse en
imparable. un monstruo de Cxito ... No necesitan ser dirigi-
10s equipos de paradigma abierto. Los organigra-
dos de una manera traditional y no necesitan que se les moti-
mas de equipo de paradigma abierto son adecuados ve. Estrin en su gran momento.
para la resolucion de problemas complejos, per0
pueden no tener un rendimiento tan eficiente como DeMarco y Lister mantienen que 10s miembros de
otros equipos. equipos cuajados son significativamente mhs pro-
ductivos y estan mas motivados que la media. Com-
parten una meta comun, una cultura comun y, en
muchos casos, un ccsentimiento elitists,, que les hace
unicos.
Pero no todos 10s equipos cuajan. De hecho, muchos
equipos sufren lo que Jackman llama cctoxicidad de equi-
p ~ >[JAC98]
> define cinco factores que ccfomentan un
entomo de equipo toxico potenciab:
4. El paradigma sincronizado se basa en la comparti-
mentacion natural de un problema y organiza 10s
miembros del equipo para trabajar en partes del pro-
blema con poca comunicacion activa entre ellos.
Constantine [CON931 propone una variacion en el
equipo descentralizado democrhtico defendiendo a 10s
equipos con independencia creativa cuyo enfoque de
trabajo podria ser mejor llamado ccanarquia innova-
dora,,. Aunque se haya apelado a1 enfoque de libre una atmosfera de trabajo frenetica en la que 10s
espiritu para el desarrollo del software, el objetivo miembros del equipo gastan energia y se descentran
principal de una organizaci6n de Ingenieria del Soft- de 10s objetivos del trabajo a desarrollar;
ware debe ser ccconvertir el caos en un equipo de alto
alta frustracion causada por factores tecnologicos,
rendimienton [HYM93]. Para conseguir un equipo de
del negocio, o personales que provocan friction entre
alto rendimiento.
10s miembros del equipo;
Los miembros del equipo deben confiar unos en
otros. ccprocedimientos coordinados pobremente o frag-
mentadom o una definicion pobre o impropiamente
La distribuci6n de habilidades debe adecuarse a1 pro- elegida del modelo de procesos que se convierte en
blema. un obstaculo a saltar;
Para mantener la uni6n del equipo, 10s inconformis- definicion confusa de 10s papeles a desempefiar pro-
tas tienen que ser excluidos del mismo duciendo una falta de responsabilidad y la acusacion
Cualquiera que sea la organizacion del equipo, el correspondiente, y
objetivo para todos 10s gestores de proyecto es colabo- cccontinua y repetida exposicion a1 fallo>>que con-
rar a crear un equipo que presente cohesion. En su libro, duce a una pdrdida de confianza y a una caida de la
Peopleware, DeMarco y Lister [DEM98] estudian este moral.
aspecto:
Jackman sugiere varios antitoxicos que tratan 10s
problemas comunes destacados anteriormente.
Para evitar un entorno de trabajo frenetico, el
gestor de proyectos deberia estar seguro de que el
El popel del bibliotecario existe sin tener en cuentu
la m c t u m del equipo. Pam m6s detotles veose
equipo tiene acceso a toda la informaci6n requerida
el Capltulo 9. para hacer el trabajo y que 10s objetivos y metas prin-
cipales, una vez definidos, no deberian modificarse a
menos que fuese absolutamente necesario. Ademas,
las malas noticias no deberian guardarse en secreto,
Tendemos a usar la palabra equipo demasiado libre-
mente en el mundo de los negocios, denominando ccequi- sino entregarse a1 equipo tan pronto como fuese posi-
PO>> a cualquier grupo de gente asignado para trabajar junta. ble (mientras haya tiempo para reaccionar de un mod0
Pero muchos de estos grupos no parecen equipos. No tie- racional y controlado).
C A P ~ T U L O3 CONCEPTOS SOBRE G E S T I ~ N
DE PROYECTOS
presenta un argument0 logico, de un mod0 ordenado.

Otros son intuitivos, pudiendo tomar una decision basin-
10s equipos formodos son lo ideol, pero no es foci1 dose en sus ccsensaciones>>.Algunos desarrolladores pre-
conseguirlos. Como minimo, este seguro de evitor fieren una planificacidn detallada compuesta por tareas
un ((entorno Mxico)). organizadas que les permita lograr el cierre para algun
elemento de un proyecto. Otros prefieren un entorno
Aunque la frustracion tiene muchas causas, 10s desa- mas espontaneo donde aspectos abiertos son correctos.
rrolladores de software a menudo la sienten cuando pier- Algunos trabajan duro para tener las cosas hechas mucho
den la autoridad para controlar la situacion. Un equipo antes de la fecha de un hito, de ese mod0 eliminan la
de software puede evitar la frustracion si recibe tanta presion cuando se aproximan a las fechas, mientras que
responsabilidad para la toma de decisiones como sea otros estan apurados por las prisas para hacer la entre-
posible. Cuanto mas control se le de a1 equipo para tomar ga en el ultimo minuto. Un estudio detallado de la psi-
decisiones ttcnicas y del proceso, menos frustracion cologia de estos rasgos y de las formas en las que un
sentiran 10s miembros del equipo. jefe de equipo cualificado puede ayudar a la gente con
Una eleccion inapropiada del proceso del software rasgos opuestos para trabajar juntos esta fuera del Ambi-
(p.ej., tareas innecesarias o pesadas, pobre eleccion de to de Cste libro4. Sin embargo, es importante destacar
10s productos del trabajo) puede ser evitada de dos for- que el reconocimiento de las diferencias humanas es el
mas: ( I ) estando seguros de que las caracteristicas del primer paso hacia la creacion de equipos que cuajan.
software a construir se ajustan a1 rigor del proceso ele-
gido, y (2) permitiendo a1 equipo seleccionar el proce- 3.2.4. Aspectos sobre la coordinacion
so (con el reconocimiento completo de que, una vez y la comunicaci6n
elegido, el equipo tiene la responsabilidad de entregar
un producto de alta calidad). Hay muchos motivos por 10s que 10s proyectos de soft-
El gestor de proyectos de software, trabajando ware pueden tener problemas. La escala (tamaiio) de
junto con el equipo, deberia refinar claramente 10s roles muchos esfuerzos de desarrollo es grande, conduciendo
y las responsabilidades antes del comienzo del proyec- a complejidades, confusion y dificultades significativas
to. El equipo deberia establecer su propios mecanismos para coordinar a 10s miembros del equipo. La incerti-
para la responsabilidad (las revisiones tkcnicas forma- dumbre es comente, dando como resultado un continuo
les' son una forma para realizar esto) y definir una serie flujo de cambios que impactan a1 equipo del proyecto.
de enfoques correctivos cuando un miembro del equi- La interoperatividad se ha convertido en una caracteris-
po falla en el desarrollo. tica clave de muchos sistemas. El software nuevo debe
Todo equipo de software experimentapequeiios fallos. comunicarse con el anterior y ajustarse a restricciones
La clave para eliminar una atm6sfera de fallos sera esta- predefinidas impuestas por el sistema o el producto.
blecer tCcnicas basadas en el equipo para retroalimentar
y solucionar el problema. Ademas, cualquier fallo de un
miembro del equipo debe ser considerado como un fallo
del equipo. Esto lleva a un acercamiento del equipo a la
acci6n correctiva, en lugar de culpar y desconfiar, que
ocurre con rapidez en equipos toxicos.
Estas caracteristicas del software modern0 --esca-
~ C O debemos
~ O evitar la, incertidumbre e interoperatividad- son aspectos de
((toxinas)) que con frecuencia la vida. Para enfrentarse a ellos eficazmente, un equi-
infectan un equipo de software? po de ingenieria del software debe establecer mCtodos
efectivos para coordinar a la gente que realiza el tra-
Ademas de las cinco toxinas descritas por Jackman, bajo. Para lograr esto se deben establecer mecanismos
un equipo de software a menudo se enfrenta con 10s ras- de comunicacion formales e informales entre 10s miem-
gos humanos diferentes de sus miembros. Algunos bros del equipo y entre multiples equipos. La comuni-
miembros del equipo son extrovertidos, otros son intro- cacion formal se lleva a cab0 ccpor escrito, con reuniones
vertidos. Algunas personas recogen informaci6n intui- organizadas y otros canales de comunicacion relativa-
tivamente, separando amplios conceptos de hechos mente no interactivos e impersonales>>[KRA95]. La
dispares. Otros procesan la informacion linealmente, comunicaci6n informal es mas personal. Los miembros
reuniendo y organizando detalles minuciosos de 10s de un equipo de software comparten ideas de por si,
datos proporcionados. Algunos miembros del equipo piden ayuda a medida que surgen 10s problemas e inter-
toman las decisiones apropiadas solamente cuando se actuan 10s unos con 10s otros diariamente.
Las revisiones tecnicas formales s e tratan con detalle e n el Capi- Se puede encontrar una excelente introduccibn a estos temas rela-
tulo 8. cionados con 10s equipos de proyectos de sottware en [FER98]
INGENlERfA DEL SOFTWARE. U N ENFOQUE PRACTICO
a productos de ingenieria del software. Estos incluyen reu-

discusion entre personash niones de revision de estado e inspecciones de diseiio y de
/ c6digo.
~ C O toordinar
~ O
las attiones de 10s miembros
del equipo?
Informal, pmcedimientos interpersonales. Incluyen reu-

niones de grupo para la divulgacion de informaci6n y resolu-
ci6n de problemas asi como adefinicion de requisitos y del
personal de desarrollox.
Comunicacion electronica. Comprende correo electroni-
co, boletines de noticias electr6nicos y, por extension, sistemas
de videoconferencia.
Red interpersonal. Discusiones informales con 10s miem-
2 bros del equipo y con personas que no e s t h en el proyecto pero
2 3 4 5 6 que pueden tener experiencia o una profunda visi6n que pue-
empleo de la tecnica de coordinacion de ayudar a 10s miembros del equipo.
I
rn Enfoque impersonal, formal Para valorar la eficacia de estas tCcnicas para la coor-
Procedimiento interpersonal, formal
o Procedimiento interpersonal, informal
dinaci6n de proyectos, Kraul y Streeter estudiaron 65
0 Comunicacion electronica
proyectos de software con cientos de personas implica-
a R e d interpersonal das. La Figura 3.1 (adaptada de [KRA95]) expresa el
valor y empleo de las tCcnicas de coordinaci6n apunta-
das anteriormente. En la figura, el valor percibido (cla-
FIGURA 3.1. Valor y empleo de tecnicas de coordinacion sificado en una escala de siete puntos) de varias tCcnicas
y comunicacion. de comunicacidn y coordinaci6n es contrastado con su
frecuencia de empleo en un proyecto. Las tCcnicas situa-
Kraul y Streeter [KRA95] examinan una colecci6n
das por encima de la linea de regresi6n fueron cjuzga-
de tCcnicas de coordinaci6n de proyectos que se cate- das como relativamente valiosas, dado la cantidad de
gorizan de la siguiente manera: veces que se ernplearon,, [KRA95]. Las tdcnicas situa-
Formal, enfoque impersonal. Incluyen documentos de das por debajo de la linea se consideraron de menor valor.
ingenieria del software y entregas (incluyendo el codigo fuen- Es interesante resaltar que las redes interpersonales fue-
te), memorandos tCcnicos, hitos del proyecto, planificacio-
nes del programa y herramientas de control del proyecto ron catalogadas como las tCcnicas de mayor valor de
(Capitulo 7), peticiones de cambios y docurnentacion relati- coordinaci6n y de.comunicaci6n. Es tambiCn importan-
va (Capitulo 9), informes de seguimiento de errores e infor- te hacer notar que 10s primeros rnecanismos de garantia
maci6n almacenada (Capitulo 3 1). de calidad del software (requisitos y revisiones de dise-
Formal, procedimientos interpersonales. Se centra en Ao) parecieron tener mas valor que evaluaciones poste-
las actividades de garantia de calidad (Capitulo 8) aplicada riores de codigo fuente (inspecciones de c6digo).
El gestor de un proyecto de software se enfrenta a un dile- 3.3.1. Ambit0 del software

ma a1 inicio de un proyecto de ingenieria del software. La primera actividad de gestidn de un proyecto de soft-
Se requieren estimaciones cuantitativas y un plan orga- ware es determinar el cimbito del software. El Ambit0 se
nizado, per0 no se dispone de informacion s6lida. Un define respondiendo a las siguientes cuestiones:
analisis detallado de 10s requisitos del software pro-
porcionaria la informaci6n necesaria para las estima-
ciones, per0 el analisis a menudo lleva semanas o meses.
Aun peor, 10s requisitos pueden ser fluidos, cambiando Si no puede delimitor uno corocteristico delsohore
regularmente a medida que progresa el proyecto. Y, a6n que intento construir, considere lo corocteristicocomo
un riesgo principol del proyecto.
asi, se necesita un plan <<iya!>>.
Por tanto, debemos examinar el producto y el pro- Contexto. iC6m0 encaja el software a construir
blema a resolver justo a1 inicio del proyecto. Por lo en un sistema, producto o contexto de negocios
menos se debe establecer el ambit0 del producto y mayor y quC limitaciones se imponen como resulta-
delimitarlo. do del contexto?
CAPfTULO 3 CONCEPTOS SOBRE GEST16N DE PROYECTOS
Objetivos de informacion. jQuC objetos de datos Las funciones del software, descritas en la exposi-
visibles a1 cliente (Capitulo 11) se obtienen del softwa- ci6n del timbito, se evaluan y refinan para proporcionar
re? jQuC objetos de datos son requeridos de entrada? mas detalle antes del comienzo de la estimaci6n (Capi-
Funcion y rendimiento. jQuC funcion realiza el tulo 5). Puesto que ambos, el coste y las estimaciones
software para transformar la informacion de entra- de la planificaci6n temporal, estan orientados funcio-
da en una salida? hay caracteristicas de rendimiento nalmente; un pequeiio grado de descomposici6n suele
especiales que abordar? ser util.
El imbito de un proyecto de software debe ser uni- Por ejemplo, considere un proyecto que construira
voco y entendible a niveles de gesti6n y tCcnico. Los un nuevo procesador de textos. Entre las caracteristicas
enunciados del Ambito del software deben estar deli- peculiares del producto estfin: la introducci6n de infor-
maci6n a travCs de la voz asi como del teclado; carac-
mitados.
Es decir, 10s datos cuantitativos (por ejemplo: nume- teristicas extremadamente sofisticadas de ccedici6n
ro de usuarios simultfineos, tamaiio de la lista de correo, autornatica de copia),; capacidad de diseiio de phgina;
miximo tiempo de respuesta permitido) se establecen indexaci6n automatica y tabla de contenido, y otras. El
explicitamente; se anotan las limitaciones (por ejemplo: gestor del proyecto debe establecer primer0 la exposi-
el coste del producto limita el tamafio de la memoria) y ci6n del ambit0 que delimita estas caracteristicas (asi
se describen 10s factores de reducci6n de riesgos (por como otras funciones mas normales, como edicibn,
ejemplo: 10s algoritmos deseados se entienden muy bien administraci6n de archivos, generacidn de documen-
si estan disponibles en C++). tos). Por ejemplo, jrequerira la introduccidn de infor-
maci6n mediante voz ccentrenamienton por parte del
usuario? j Q ~ 6capacidades especificas proporcionara
3.3.2. Descomposici6n del problema la caracteristica de editar copias? jExactamente c6mo
La descomposiciondel problema, denominado a veces sera de sofisticado la capacidad de diseiio de phgina?
particionado o elaboracibn delproblema, es una activi-
dad que se asienta en el nucleo del analisis de requisitos
del software (Capitulo 11). Durante la actividad de expo-
sici6n del Ambit0 no se intenta descomponer el proble-
ma totalmente. Mas bien, la descomposici6n se aplica en
dos Areas principales: (1) la funcionalidad que debe entre-
garse y (2) el proceso que se empleara para entregarlo. A medida que evoluciona la exposici6n del Ambito,
un primer nivel de partici6n ocurre de forma natural. El
equipo del proyecto sabe que el departamento de mar-
keting ha hablado con clientes potenciales y ha averi-
guado que las siguientes funciones deberian ser parte
de la edicidn automatica de copia: (1) comprobaci6n
Poro desorrollor un plan de proyecto razonoble, tiene ortografica; (2) comprobaci6n gramatical; (3) compro-
que descornponer funcionalrnente el problerno o resolver. baci6n de referencias para documentos grandes (p. ej.:
jse puede encontrar una referencia a una entrada biblio-
Los seres humanos tienden a aplicar la estrategia de grafica en la lista de entradas de la bibliografia?), y (4)
divide y vencerhs cuando se enfrentan a problemas com- validaci6n de referencias de secci6n y capitulo para
plejos. Dicho de manera sencilla, un problema complejo documentos grandes. Cada una de estas caracteristicas
se parte en problemas m8s pequeiios que resultan mas representa una subfunci6n para implementar en soft-
manejables. ~ s t es
a la estrategia que se aplica a1 inicio ware. Cada una puede ser aun mas refinada si la des-
de la planificacion del proyecto. composici6n hace mas facil la planificacibn.
Las fases genCricas que caracterizan el proceso de soft- el modelo incremental

ware Aefinicibn, desarrollo y soporte- son aplicables el modelo en espiral
a todo software. El problema es seleccionar el modelo de el modelo en espiral WINWIN
proceso apropiado para la ingenieria del software que debe
' el modelo de desarrollo basado (ensamblaje) en com-
aplicar el equipo del proyecto. En el Capitulo 2 se estudi6
una gran gama de paradigmas de ingenieria del software: ponentes
el modelo secuencial lineal el modelo de desarrollo concurrente
el modelo de prototipo
el modelo DRA
..el modelo de mCtodos formales
el modelo de tCcnicas de cuarta generaci6n
45
I N G E N I E R ~ ADEL SOFTWARE. UN ENFOQUE PRhCTICO
Comunicacidn con el cliente- tareas requeridas para

establecer la obtencion de requisitos eficiente entre
Una vez elegido el modelo de proceso, ocomp~ielocon el desarrollador y el cliente.
el mhimo conjunto de toreas de trobojo y pmductos que Planificacidn- tareas requeridas para definir 10s
desembomron en un producto de alto colidod --evite lo recursos, la planificacih temporal del proyecto y
copocidod de destruction del procese-. cualquier informacion relativa a 61.
El gestor del proyecto debe decidir quC modelo de

proceso es el mis adecuado para (1) 10s clientes que han
solicitado el producto y la gente que realizari el traba- Recuerde.,.. 10s octividodes estructuroles se ophcon
jo; (2) las caractensticas del producto en si, y (3) el entor- en todos 10s proyectos- no hay excepciones.
no del proyecto en el que trabaja el equipo de software.
Cuando se selecciona un modelo de proceso, el equipo Andisis del riesgu- tareas requeridas para valorar
define entonces un plan de proyecto preliminar basado 10s riesgos tecnicos y de gestion.
en un conjunto de actividades estructurales. Una vez Ingenieria- tareas requeridas para construir una o
establecido el plan preliminar, empieza la descomposi- mis representaciones de la aplicacion.
cion del proceso. Es decir, se debe crear un plan com- Construcci6n y entrega- tareas requeridas para cons-
pleto reflejando las tareas requeridas a las personas para truir, probar, instalar y proporcionar asistencia a1 usua-
cubrir las actividades estructurales. Exploramos estas n o (por ejemplo: documentacion y formacion).
actividades brevemente en las secciones que siguen y Evaluacidn del cliente- tareas requeridas para obte-
presentamos una vision mas detallada en el Capitulo 7.
ner informacion de la opinion del cliente basadas en
la evaluacion de las representaciones de software
3.4.1. Maduracion del producto y del proceso creadas durante la fase de ingenieria e implementa-
La planificacion de un proyecto empieza con la madu- das durante la fase de instalacion.
racion del producto y del proceso. Todas las funciones Los miembros del equipo que trabajan en cada funcion
que se deben tratar dentro de un proceso de ingenieria aplicarh todas las actividades estructurales. En esencia,
por el equipo de software deben pasar por el conjunto se crea una matriz similar a la que se muestra en la Figu-
de actividades estructurales que se han definido para ra 3.2. Cada funcion principal del problema (la figura con-
una organizacih de software. Asuma que la organiza- tiene las funciones para el software procesador de textos
cion ha adoptado el siguiente conjunto de actividades comentado anteriormente) se lista en la colurnna de la
estructurales (Capitulo 2): izquierda. Las actividades estructurales se listan en la fila
ACTlVlDADES ESTRUCTURALES
DE PROCESO COMUNES
FIGURA 3.2. Maduracion del problema y del proceso.

CAP~TULO
3 CONCEPTOS SOBRE GESTI6N DE PROYECTOS
de aniba. Las tareas de trabajo de ingenieria del software ECP?>>.Por ejemplo, un pequefio proyecto, relativamen-
. (para cada actividad estructural) se introducirian en la fila te simple, requiere las siguientes tareas para la actividad
siguiente". El trabajo del gestor del proyecto (y de otros de comunicacibn con el cliente:
miembros del equipo) es estimar 10s requisitos de recur- 1. Desarrollar una lista de aspectos que se han de cla-
sos para cada celda de la matriz, poner fechas de inicio y rificar.
finalizacion para las tareas asociadas con cada celda y 10s 2. Reunirse con el cliente para resolver 10s aspectos
productos a fabricar como consecuencia de cada celda. que se han de clarificar.
Estas actividades se consideran en 10s Capitulos 5 y 7. 3. Desarrollar conjuntamente una exposicion del
imbito del proyecto.
4. Revisar el alcance del proyecto con todos 10s impli-
cados.
Lo descornposicion del product0 y del proceso se produce
5. Modificar el alcance del proyecto cuando se requiera.
sirnultaneornente con lo evolucion del plan de proyecto. Estos acontecimientos pueden ocurrir en un period0 de
menos de 48 horas. Representan una descomposici6n del
problema apropiado para proyectos pequefios relativa-
3.4.2. Descomposicidn del proceso mente sencillos.
Un equipo de software deberia tener un grado significa- Ahora, consideremos un proyecto mis complejo que
tivo de flexibilidad en la eleccion del paradigma de inge- tenga un Ambito mis arnplio y un mayor impact0 comer-
nieria del software que resulte mejor para el proyecto y cial. Un proyecto como Cse podria requerir las siguientes
de las tareas de ingenieria del software que conforman el tareas para la actividad de comunicacion con el cliente:
modelo de proceso una vez elegido. Un proyecto relati-
vamente pequefio similar a otros que se hayan hecho ante- 1. Revisar la peticion del cliente.
riormente se deberia realizar con el enfoque secuencial 2. Planificar y programar una reunion formal con el
lineal. Si hay limites de tiempo muy severos y el proble- cliente.
ma se puede compartimentar mucho, el modelo apropia- 3. Realizar una investigation para definir soluciones pro-
do es el DRA (en inglks RAD). Si la fecha limite esti tan puestas y enfoques existentes.
proxima que no va a ser posible entregar toda la funcio- 4. Preparar un ((documentode trabajopp y una agenda para
nalidad, una estrategia incremental puede ser lo mejor. la reunion formal.
Similarmente, proyectos con otras caractensticas (p. ej.: 5. Realizar la reunion.
requisitos inciertos, nuevas tecnologias, clientes difici- 6. Desarrollar conjuntamente mini-especificaciones que
les, potencialidad de reutilizacion) llevarin a la seleccion reflejen la informaci6n, funci6n y caracteristicas de
de otros modelos de proceso6. comportamiento del software.
Aplique siempre la EIP (Estructvra I o m h de Proceso),

sin tener en cuenta el tamalo, criticidad o tipo del
proyecto. Las tareas pueden variar pero lo EIP no.
Modelo de proceso adoptable.
Una vez que se ha elegido el modelo de proceso, la
estructura comun de proceso (ECP) se adapta a 61. En tcdos 7. Revisar todas las mini-especificaciones para compro-
10s casos, el ECP estudiado anteriormente en este capitu- bar su correccion, su consistencia, la ausencia de ambi-
lo -comunicacion con el cliente, planificacion, anilisis giiedades.
de riesgo, ingenieria, construction, entrega y evaluacion 8. Ensamblar las mini-especificaciones en un documento
del cliente- puede adaptarse al paradigma. Funcionara de alcance del proyecto.
. .
para modelos lineales, para modelos iterativos e incre- 9. Revisar ese documento general con todo lo que pueda
mentales, para modelos de evolucion e incluso para mode- afectar.
10s concurrenteso de ensamblaje de componentes. El ECP 10. Modificar el documento de alcance del proyecto
es invariable y sirve como base para todo el trabajo de cuando se requiera.
software realizado por una organizacih. Ambos proyectos realizan la actividad estructural que
Pero las tareas de trabajo reales si van'an. La descom- denorninamos comunicacibn con el cliente, per0 el equipo
posicion del proceso comienza cuando el gestor del pro- del primer proyecto lleva a cab0 la mitad de tareas de
yecto pregunta: cciC6m0 vamos a realizar esta actividad ingenieria del software que el segundo.
Se hace notar que las tareas se deben adaptar a las necesidades ~ e c u e r d eque las caracteristicas del proyecto tienen tambiirn una
especificas de un proyecto. Las actividades estructurales siempre per- fuerte influencia en la estructura del equipo que va a realizar el tra-
manecen igual, pero las tareas s e seleccionaran basandose en unos bajo. Vea la Seccion 3.2.3.
criterios de adaptacion. Este tema e s discutido mas adelante en el
Capitulo 7 y e n la pagina Web SEPA 5/e.
I N G E N I E R ~ ADEL S O F T W A R E . U N E N F O Q U E P R A C T I C O
Para gestionar un proyecto de software con Cxito, vaya a estar involucrado en el proyecto. Se refuer-
debemos comprender quC puede ir ma1 (para evitar za construyendo el equipo adecuado (Secci6n 3.2.3)
esos problemas) y c6mo hacerlo bien. En un excelente y dando a1 equipo la autonomia, autoridad y tecno-
documento sobre proyectos de software, John Reel logia necesaria para realizar el trabajo.
[REE99] define diez seiiales que indican que un pro- Mantenerse. Muchos proyectos no realizan un
yecto de sistemas de informaci6n esti en peligro: buen comienzo y entonces se desintegran lentarnente.
Para mantenerse, el gestor del proyecto debe pro-
porcionar incentivos para conseguir una rotaci6n del
personal minima, el equipo debena destacar la cali-
dad en todas las tareas que desarrolle y 10s gestores
veteranos deberian hacer todo lo posible por per-
manecer fuera de la forma de trabajo del equipo7.
Seguimiento del Progreso. Para un proyecto de
software, el progreso se sigue mientras se realizan 10s
productos del trabajo (por ejemplo, especificaciones,
1. La gente del software no comprende las necesi- c6digo fuente, conjuntos de casos de prueba) y se
dades de 10s clientes. aprueban (utilizando revisiones tCcnicas formales)
como parte de una actividad de garantia de calidad.
2. El imbito del product0 esti definido pobremente. Ademis, el proceso del software y las medidas del
3. Los cambios estin ma1 realizados. proyecto (capitulo 4) pueden ser reunidas y utilizadas
4. La tecnologia elegida cambia. para evaluar el progreso frente a promedios desarro-
llados por la organizaci6n de desarrollo de software.
5. Las necesidades del negocio cambian [o estin ma1
Tomar Decisiones Inteligentes. En esencia, las
definidas].
decisiones del gestor del proyecto y del equipo de
6. Las fechas de entrega no son realistas. software deberian ccseguir siendo sencillasu. Siem-
7. Los usuarios se resisten. pre que sea posible, utilice software del mismo
8. Se pierden 10s patrocinadores [o nunca se obtu- comercial o componentes de software existentes;
vieron adecuadamente]. evite personalizar interfaces cuando estCn dispo-
nibles aproximaciones estindar; identifique y eli-
9. El equipo del proyecto carece del personal con las mine entonces riesgos obvios; asigne m i s tiempo
habilidades apropiadas. del que pensaba necesitar para tareas arriesgadas
10. Los gestores [y 10s desarrolladores] evitan buenas o complejas (necesitari cada minuto).
pricticas y sabias lecciones.
Los profesionales veteranos de la industria hacen
referencia frecuentemente a la regla 90-90 cuando
estudian proyectos de software particularmente difi-
ciles: el primer 90 por 100 de un sistema absorbe el
Referencia web/ '
90 por 100 del tiempo y del esfuerzo asignado. El ulti- Se puede encontror un gron conjunto de recursos
que pueden oyudor tonto o gestores de proyecto
mo 10 por 100 se lleva el otro 90 por 100 del esfuer-
experimentodos como o principiontes en:
zo y del tiempo asignado [ZAH94]. Los factores que
www.pmi.org, www.4pm.com y
conducen a la regla 90-90 estin contenidos en las diez www.projectmanagement.com
seiiales destacadas en la lista anterior.
isuficiente negatividad! iC6m0 actua un gestor para
evitar 10s problemas seiialados anteriormente? Reel Realizar un Andisis c<Postmortemw(despuksdejina-
[REE99] sugiere una aproximaci6n de sentido com6n lizar el proyecto). Establecer un mecanismo consis-
a 10s proyectos de software dividida en cinco panes: tente para extraer sabias lecciones de cada proyecto.
Empezar con el pie derecho. Esto se realiza tra- Evaluar la planificaci6n real y la prevista, reunir y ana-
bajando duro (muy duro) para comprender el pro- lizar mCtricas del proyecto de software y realimentar
blema a solucionar y estableciendo entonces con datos de 10s miembros del equipo y de 10s clien-
objetivos y expectativas realistas para cualquiera que tes, y guardar 10s datos obtenidos en formato escrito.
Esta frase irnplica la reduccion al minirno de la burocracia, y la eli-

minacion tanto de reuniones extraiias como de la adherencia dog-
matica a las reglas del proceso y del proyecto. El equipo deberia estar
capacitado para realizar esto.
CAPfTULO 3 CONCEPTOS SOBRE GESTI6N DE PROYECTOS
En un excelente documento sobre proyectos y proce- ponsabilidad de cada miembro del equipo de soft-
so del software, Barry Boehm [BOE96] afirma: K... se ware debe estar definida. La respuesta a la pre-
necesita un principio de organizaci6n que haga una gunta ayuda a cumplir esto.
simplificacidn con el fin de proporcionar planes [de iDdnde estcin situados organizacionalmente?
proyectos] sencillos para proyectos pequefios>>. Boehm No todos 10s roles y responsabilidades residen en
sugiere un enfoque que trate 10s objetivos, hitos y pla- el equipo de software. El cliente, 10s usuarios, y
nificacion, responsabilidades, enfoque tCcnico y de otros directivos tambiCn tienen responsabilidades.
gestion, y 10s recursos requeridos del proyecto. Bohem
lo llama el principio ccWWWWWHH>>,despuCs de
una serie de preguntas (7 cuestiones) que conducen a
la definicidn de las caracteristicas clave del proyecto
y el plan del proyecto resultante:
iPor que' se desarrolla el sistema? La respuesta a
esta pregunta permite a todas las partes evaluar la vali-
dez de las razones del negocio para el trabajo del soft- Plon de Proyecto de S o h o r e
ware. Dicho de otra forma, tjustifica el propdsito del
negocio el gasto en personal, tiempo, y dinero? iC6m0 estara realizado el trabajo desde el pun-
,jQue' se realizara' y cua'ndo? La respuesta a estas to de vista te'cnico y de gestidn? Una vez estable-
preguntas ayuda a1 equipo a establecer la planifi- cido el ambito del producto, se debe definir una
cacion del proyecto identificando las tareas clave estrategia tCcnica y de gestion para el proyecto.
del proyecto y 10s hitos requeridos por el cliente. ,jQ~e'cantidad de cada recurso se necesita? La
respuesta a esta pregunta se deriva de las estima-
ciones realizadas (Capitulo 5) basadas en res-
i Q ~ tpreguntas
i netesitan
puestas a las preguntas anteriores.
ser respondidas para
desarrollar un Plan de Proyetto? El principio W ~ H H de Boehm es aplicable sin tener
en cuenta el tamafio o la complejidad del proyecto de
software. Las preguntas sefialadas proporcionan un
iQuie'n es el responsable de una funcidn? Antes perfil de planificacidn a1 gestor del proyecto y a1 equi-
en este capitulo, sefialamos que el papel y la res- po de software.
El ~onci1io"irlie ha desarrollado una lista de uno de 10s riesgos jcuil es la oportunidad de que
<<practicascriticas de software para la gestion basada el riesgo se convierta en un problema y cual es el
en el rendimienton. Estas practicas son ccutilizadas de impact0 si lo hace?
un mod0 consistente por, y consideradas criticas por, Coste empirico y estimacion de la planificacion.
organizaciones y proyectos de software de mucho Cxi- iCual es el tamafio actual estimado de la aplicacion
to cuyo rendimiento "final" es mas consistente que de software (sin incluir el software del sistema) que
10s promedios de la industria>>[AIR99]. En un esfuer- sera entregada en la operacibn? ~ C Ose~obtuvo?O
zo por permitir a una organizacion de software deter-
minar si un proyecto especifico ha implementado
practicas criticas, el Concilio Airlie ha desarrollado
un conjunto de preguntas de <<VisionRapids>> [AIR991
para un proyecto9:
Gestion formal del riesgo. iCuh1es son 10s diez
riesgos principales para este proyecto? Para cada Visidn rdpido del Proyecto Airlie.
El Concilio Airlie es un equipo de expertos en ingenieria del software Solo se destacan aqui aquellas practicas criticas relacionadas con
promocionado por el Departamento de Defensa U.S. ayudando en el la ~lintegridaddel proyecto~).Otras practicas mejores s e trataran en
desarrollo de directrices para practicas importantes en la gestion de capitulos posteriores.
proyectos de software y en la ingenieria del software.
Gestion de proyectos basada en metricas. jDis- de el principio del prograrna y del numero de defectos
. pone de un programa de mCtricas para dar una prime- que se comgen y se producen en la actualidad?
ra indicaci6n de 10s problemas del desarrollo? Si es asi, Gestion del programa del personal. j C d l es
jcud es la volatilidad de 10s requisitos actualmente? la media de rotaci6n de la plantilla en 10s tres ulti-
Seguimiento del valor ganado. jInforrna men- mos meses por cada uno de 10s distribuidoresldesa-
sualmente de las mCtricas del valor ganado ...? Si rrolladores involucrados en el desarrollo del
e s asi, jestan calculadas estas rnCtricas desde una software para este sistema?
red de actividades de tareas para el esfuerzo total Si un equipo de proyectos de software no puede
a la proxima entrega? responder a estas preguntas, o las responde inade-
Seguimiento de defectos frente a objetivos de cali- cuadarnente, se debe realizar una revision cornpleta
dad. jRealiza el seguimiento e informa peridicamente de las pricticas del proyecto. Cada una de las prhcti-
del nurnero de defectos encontrados en cada prueba de cas criticas sefialadas anteriormente se tratan con deta-
inspection [revision tCcnica formal] y ejecucion des- lle a lo largo de la Parte I1 de este libro.
La gesti6n de proyectos de software es una actividad pletar el trabajo. Finalmente, el proyecto debe organi-
protectora dentro de la ingenieria del software. Ernpie- zarse de una manera que permita a1 equipo de software
za antes de iniciar cualquier actividad tkcnica y contener Cxito.
tinlia a lo largo de la definicion, del desarrollo y del El elemento fundamental en todos 10s proyectos de
rnantenimiento del software. software es el personal. Los ingenieros del software
Hay cuatro << P's N que tienen una influencia sustan- pueden organizarse en diferentes organigrarnas de equi-
cia1 en la gestion de proyectos de software -personal, po que van desde las jerarquias de control tradiciona-
producto, proceso y proyect-. El personal debe orga- les a 10s equipos de ({paradigma abierto,). Se pueden
nizarse en equipos eficaces, motivados para hacer un aplicar varias tCcnicas de coordinacion y cornunica-
software de alta calidad y coordinados para alcanzar una ci6n para apoyar el trabajo del equipo. En general, las
comunicaci6n efectiva. Los requisitos del producto revisiones forrnales y las cornunicaciones inforrnales
deben comunicarse desde el cliente a1 desarrollador, persona a persona son las rn8s valiosas para 10s pro-
dividirse (descomponerse) en las partes que lo consti- fesionales.
tuyen y distribuirse para que trabaje el equipo de soft- La actividad de gesti6n del proyecto cornprende
ware. El proceso debe adaptarse a1 personal y a1 medicion y rnktricas, estirnacion, anilisis de riesgos,
problerna. Se selecciona una estructura cornfin de pro- planificacion del programa, seguirniento y control.
ceso, se aplica un paradigma apropiado de ingenieria Cada uno de estos aspectos se trata en 10s siguientes
del software y se elige un conjunto de tareas para com- capitulos.
[AIR991Airlie Council, ccperformanced Based Management: ware Engineering, vol. 31, n." 1, Noviembre de 1988,
The Program Manager's Guide Based on the 16-Point pp. 1268-1287.
Plan and Related Metria)), Draft Report, 8 de Marzo,
1999. [CUR941 Curtis, B., et al.. People Management Capabi-
lity Maturity Model, Software Engineering Institute,
[BAK72] Baker, F.T., <<ChiefProgrammer Team Manage- Pittsburgh, PA, 1994.
ment of Production Programming,, IBM Systems Jour-
nal, vol. 11, n." 1, 1972, pp. 56-73. [DEM98] DeMarco, T., y T. Lister, Peopleware, 2.Qdi-
ci6n, Dorset House, 1998.
[BOE96] Boehm, B., <<Anchoringthe Software Process)),
IEEE Software, vol. 13, n." 4, Julio de 1996, pp. 73-82. [EDG95] Edgemon, J., <<RightStuff: How to Recognize
[CON931 Constantine, L., <<WorkOrganization: Paradigms It When Selecting a Project Manager,,, Application
for Project Management and Organization*, CACM, vol. Development Trends, vol. 2, n." 5, Mayo de 1995, pp.
36, n." 10, Octubre de 1993, pp. 34-43. 37-42.
[COU80] Cougar, J., y R. Zawacky, Managing and Moti- [FER98] Ferdinandi, P. L., <<FadatingCommunication,,,
vating Computer Personnel, Wiley, 1980. IEEE Software, Septiembre de 1998, pp. 92-96.
[CUR881 Curtis, B., et al, <<AField Study of the Software [JAC98] Jackman, M., <<Homeopathic Remedies for Team
Design Process for Large Systems)),IEEE Trans. Soft- Toxicity,,, lEEE Software, Julio de 1998, pp. 43-45.
C A P ~ T U L O3 CONCEPTOS SOBRE G E S T I ~ DE
N PROYECTOS
[KRA95] Kraul, R., y L. Streeter, <<Coordinationin Software [REE99] Reel, J.S., <<CriticalSuccess Factors in Software
Development)), CACM, vol. 38, n."3, Marzo de 1995, pp. Projects)),IEEE Software, Mayo de 1999, pp. 18-23.
69-8 1. [WE1861 Weinberg, G., On Becoming a Technical Leader,
[MAN8 11 Mantei, M., <<TheEffect of Programming Team Dorset House, 1986.
Structures on Programming Tasks)), CACM, vol. 24, n.", [WIT941 Whitaker, K., Managing Software Maniacs, Wiley,
Marzo de 1981, pp. 106-113. 1994.
[PAG85] Page-Jones, M., Practical Project Management, [ZAH94] Zahniser, R., <<Timeboxingfor Top Team Perfor-
Dorset House, 1985, p. VII. mance)),SofhYare Development, Marzo de 1994, pp. 35-38.
3.1. Basandose en la informaci6n contenida en este capitu- por el mercado de entretenimiento casero es intensa, hay cier-
lo y en su propia experiencia, desarrolle c<diezmandamien- ta presion para terminar el trabajo rapidamente. ~ Q u C estruc-
tow para potenciar a 10s ingenieros del software. Es decir, tura de equipo elegiria y por quC? iQuC modelo(s) de proceso
haga una lista con las diez lineas maestras que lleven a1 per- de software elegiria y por quC?
sonal que construye software a su maxim0 potencial. 3.8. Se le ha nombrado gestor de proyecto de una gran com-
3.2. El Modelo de Madurez de Capacidad de Gesti6n de Per- paiiia de productos software. Su trabajo consiste en dirigir la
sonal (MMCGP) del Instituto de Ingenieria del Software hace versidn de la siguiente generaci6n de su famoso procesador
un estudio organizado de las <<areasclave practicas (ACP))) de textos. Como la competencia es intensa, se han estableci-
que cultivan 10s buenos profesionales del software. Su profe- do y anunciado fechas limite rigidas. ~ Q u C estructura de equi-
sor le asignara una ACP para analizar y resumir. po elegiria y por quC? iQuC modelo(s) de proceso de software
3.3. Describa tres situaciones de la vida real en las que el elegiria y por quC?
cliente y el usuario final son el mismo. Describa tres situa- 3.9. Se le ha nombrado gestor de proyecto de software de una
ciones en que son diferentes. compaiiia que trabaja en el mundo de la ingenieria gedtica.
Su trabajo es dirigir el desarrollo de un nuevo producto de soft-
3.4. Las decisiones tomadas por una gesti6n experimentada
ware que acelere el ritmo de impresidn de genes. El trabajo es
pueden tener un impact0 significativo en la eficacia de un equi-
orientado a I+D, per0 la meta es fabricar el producto dentro del
po de ingenieria del software. Proporcione cinco ejemplos para
siguiente aiio. ~ Q u Cestructura de equipo elegiria y por quC?
ilustrar que es cierto.
~QuC modelo(s) de proceso de software elegiria y por quC?
3.5. Repase el libro de Weinberg [WE1861 y escriba un resu- 3.10. Como muestra la Figura 3.1, basandose en 10s resulta-
men de dos o tres paginas de 10s aspectos que deberian tener- dos de dicho estudio, 10s documentos parecen tener mas uso
se en cuenta a1 aplicar el modelo MOI. que valor. iPor que Cree que pas6 esto y quC se puede hacer
3.6. Se le ha nombrado gestor de proyecto dentro de una para mover el punto documentos por encima de la linea de
organizaci6n de sistemas de informacibn. Su trabajo es cons- regresi6n en el grifico? Es decir, iquC se puede hacer para
truir una aplicaci6n que es bastante similar a otras que ha cons- mejorar el valor percibido de 10s documentos?
truido su equipo, aunque Csta es mayor y mas compleja. Los 3.11. Se le ha pedido que desarrolle una pequeiia aplicaci6n
requisitos han sido detalladamente documentados por el clien- que analice todos 10s cursos ofrecidos por la universidad e
te. ~ Q u C
estructura de equipo elegiria y por quC? ~ Q u Cmode- informe de las notas medias obtenidas en 10s cursos (para un
lo(s) de proceso de software elegiria y por quC? period0 determinado). Escriba una exposicion del alcance que
3.7. Se le ha nombrado gestor de proyecto de una pequefia abarca este problema.
compaiiia de productos software. Su trabajo consiste en cons- 3.12. Haga una descomposicidn funcional de primer nivel
truir un producto innovador que combine hardware de reali- de la funcion diseiio de pigina tratado brevemente en la
dad virtual con software innovador. Puesto que la competencia Secci6n 3.3.2.
Una excelente serie de cuatro volumenes escrito por Wein- proporcionar una nueva visi6n profunda de 10s aspectos del
berg (Quality Software Management, Dorset House, 1992, proyecto de software y de su gestibn. Purba y Shah (How to
1993, 1994,1996) introduce 10s conceptos basicos sobre sis- Manage a Successful Software Project, Wiley, 1995) presen-
temas y conceptos de gestibn, explica c6mo usar medicio- tan un numero de estudios de casos de proyectos que indican
nes eficazmente y menciona la ccacci6n congruente)), la por quC unos fracasaron y otros fueron un Cxito. Bennatan
habilidad de ccencajarn las necesidades del gestor, del per- (Software Project Management in a ClientlServer Environ-
sonal tCcnico y las del negocio. Proporciona informacidn ment, Wiley, 1995) estudia aspectos especificos de gesti6n
util tanto a 10s gestores noveles como a 10s experimentados. asociados con el desarrollo de sistemas cliente/servidor.
Brooks (The Mythical Man-Month, Aniversary Edition, Se puede argumentar que el aspect0 mis importante de la
Addison-Wesley, 1995) ha actualizado su clasico libro para gesti6n del proyecto de software es la gesti6n de personal. El
libro definitivo sobre este tema lo escribieron DeMarco y Lis- jo mas eficazmente. House (The Human Side of Project
ter [DEM98], per0 se han publicado en 10s dltimos aiios 10s Management, Addison-Wesley, 1988) y Crossby (Running
siguientes libros donde se examina su importancia: Things: The art of Making Things Happen. McGraw-Hill,
Beaudouin-Lafon, M., Computer Supported Coopera- 1989) proporcionan directrices practicas para gestores que
tive Work, Wiley-Liss, 1999. deban tratar con problemas humanos y tCcnicos.
Carmel, E., Global Software Teams: Collaborating Aunque no estan relacionados especificamente con el
Across Borders and Time Zones, Prentice Hall, 1999. mundo del software, y algunas veces sufren demasiadas
Humphrey, W. S., Managing Technical People: Inno- simplificaciones y amplias generalizaciones, 10s libros de
vation, Teamwork, and the Software Process, Addison-Wes- gran Cxito de Drucker (Management Challenges for the 21st
ley 1997. Century, Harperbusines, 1999), Buckingham y Coffman
Humphrey, W. S., Introduction to the Team of Software (First, Break All the Rules: What the World's Greatest
Process, Addison-Wesley, 1999. Managers Do Differently, Simon & Schuster, 1999) y Chris-
Jones, P. H., Handbook of Team Design: A Practitio- tensen (The Innovator's Dilemma, Harvard Business School
ner's Guide to Team Systems Development, McGraw-Hill, Press, 1997) enfatizan ccnuevas reglaw definidas por una
1997. economia que cambia con rapidez. Viejos titulos como The
Karolak, D. S., Global Software Development: Mana- One Minute Manager e In Search of Excellence continuan
ging Virtual Teams and Environments, IEEE Computer proporcionando enfoques valiosos que pueden ayudarle a
Society, 1998. gestionar 10s ternas relacionados con el personal de un mod0
Mayer, M., The Virtual Edge: Embracing Technology mas eficiente.
for Distributed Project Team Success, Project Management En Internet estan disponibles una gran variedad de fuen-
Institute Publications, 1999. tes de informacidn relacionadas con temas de gestidn de pro-
Otro excelente libro de Weinberg [WE1861 es lectura yectos de software. Se puede encontrar una lista actualizada
obligada para todo gestor de proyecto y jefe de equipo. Le con referencias a sitios (paginas) web que son relevantes para
dara una visidn interna y directrices para realizar su traba- 10s proyectos de software en http://www.pressman5.com.
L
A medici6n es fundamental para cualquier disciplina de ingenieria, y la ingenieria del soft-
ware no es una excepci6n. La medici6n nos permite tener una visi6n mhs profunda propor-
cionando un mecanismo para la evaluacidn objetiva. Lord Kelvin en una ocasi6n dijo:
Cuando pueda medir lo que esth diciendo y expresarlo con nlimeros, ya conoce algo sobre
ello; cuando no pueda medir, cuando no pueda expresar lo que dice con nlimeros, su conoci-
miento es precario y deficiente: puede ser el comienzo del conocimiento, pero en sus pensa-
mientos, apenas esti avanzando hacia el escenario de la ciencia.
La comunidad de la ingenieria del software ha comenzado finalmente a tomarse en serio las
palabras de Lord Kelvin. Pero no sin frustraciones y sf con gran controversia.
Las ntktricus del sofm~urese refieren a un amplio elenco de mediciones para el software de
computadora. La medici6n se puede aplicar al proceso del software con el intento de mejorar-
lo sobre una base continua. Se puede utilizar en el proyecto del software para ayudar en la esti-
macibn, el control de calidad, la evaluaci6n de productividad y el control de proyectos.
Finalmente, el ingeniero de software puede utilizar la medici6n para ayudar a evaluar la cali-
dad de 10s resultados de trabajos dcnicos y para ayudar en la toma de decisiones tictica a medi-
da que el proyecto evoluciona.
tQu6 es? El proceso del software y las ~Quien

Is b e e ? Las metricas del soft- zando matricas orientadas aI lamafia o
metricas del producto son una medida ware son analizadas y evaluadas por a la funcidn. El resultado se analiza y
cuantitativa que permite a la gente del 10s administradores del software. A s e cornpara con promedios anteriores
soitware tener una visi6n profunda de menudo las medidas son reunidas por d e proyectos similares realizados con
la eficacia del proceso del software y de 10s ingenieros del software. la organizacidn. Se evalrian las ten-
10s proyectos que dirigen utilizando el &Parqrr6 es importante? Si no mides, dencias y se generan las conclusiones.
proceso como un marc0 de trabcrjo. Se s61o podras juzgar b a s h d o t e e n una &Cuiles e l produeto obtenido? Ee un
rednen 10sdatoa b6sicos d e calidad y etraluaci6nsubjetiva. Mediante la medi- conjunto d e metricas del software que
productividad. Estos datos son entonces cidn, s e pueden sefialar las tendencias proporcionan una visi6n profunda del
analizados, comparados con pomedios b e n a s o malas), realizar mejores esti- proceso y d e la comprension del pro-
anteriores, y evaluados para determi- maciones, llevar a cabo una verdadera yecto.
nar las mejoras en la calidad y produc- mejora sobre el tiempo. ~ C 6 m pue&
o e s t e r seguro de que lo
tividad. Las mbtricas son tambibn 8Cubles son la* pasas?Comenzar defi- he heeho correctamento? Aplican-
utilizadas para sefialar &reascon pro- niendo un conjunto limitado d e medido un plan de medici6n sencillo per0
blemas de mcmera que se puedan desa- das d e procesos, proyectos y productos consistente, a u e nunca utilizaremos
rrollar bs remedios y mejorar el proceso que Sean fdciles de recoger. Estas medi- para evaluar, premlar o castigar el ren-
del software. d a s son a menudo normalizadas utili- dimiento individual.
b ingenieriadel software Dentro del context0 de la gesti6n de proyectos de software, en primer lugar existe una gran pre-
se presenton en los copihh 19 y 24. ocupaci6n por las mCtricas de productividad y de calidad -medidas ade salidan (finalizacibn) del
desarrollo del software, basadas en el esfuerzo y tiempo empleados, y medidas de la autilidadu del
producto obtenid-.
Park, Goethert y Florac [PAR961 tratan en su guia de la medicidn del software las razones por
las que medimos:
Hay cuatro razones para medir 10s procesos del software, 10s productos y 10s recursos:
10s m&icos del software
caracterizar
le permiten conocer cuhndo reir
evaluar
y cubdo Ilorar.
predecir
h Gab
- mejorar
53
INGENIER~A
DEL SOFTWARE. UN ENFOQUE PRACTICO
Caracterizamos para comprender mejor 10s procesos, 10s productos, 10s recursos y 10s entomos y para establecer
. las lineas base para las comparaciones con evaluaciones futuras.
Evaluamos para determinar el estado con respecto a1 diseiio. Las medidas utilizadas son 10s sensores que nos per-
miten conocer cubdo nuestros proyectos y nuestros procesos e s t b perdiendo la pista, de mod0 que podamos poner-
10s bajo control. TambiCn evaluamos para valorar la consecuci6n de 10s objetivos de calidad y para evaluar el impact0
de la tecnologia y las mejoras del proceso en 10s productos y procesos.
Predecimos para poder planificar. Realizar mediciones para la prediccion implica aumentar la comprension de las
relaciones entre 10s procesos y 10s productos y la construcci6n de modelos de estas relaciones, por lo que 10s valores
que observamos para algunos atributos pueden ser utilizados para predecir otros. Hacemos esto porque queremos esta-
blecer objetivos alcanzables para el coste, planificaci6n, y calidad - d e manera que se puedan aplicar 10s recursos apro-
piados-. Las medidas de prediccion tambiCn son la base para la extrapolaci6n de tendencias, con lo que la estimation
para el coste, tiempo y calidad se puede actualizar basbdose en la evidencia actual. Las proyecciones y las estima-
ciones basadas en datos hist6ricos tambiCn nos ayudan a analizar riesgos y a realizar intercambios diseiio/coste.
Medimos para mejorar cuando recogemos la information cuantitativa que nos ayuda a identificar obst8culos, pro-
blemas de raiz, ineficiencias y otras oportunidades para mejorar la calidad del producto y el rendimiento del proceso.
Aunque 10s tCrminos medida, medicidn y mktricas se [RAG95]. Un indicador proporciona una vision pro-
utilizan a menudo indistintamente, es importante des- funda que permite a1 gestor de proyectos o a 10s inge-
tacar las diferencias sutiles entre ellos. Como 10s tCr- nieros de software ajustar el producto, el proyecto o
minos ccmedidau y ccmedici6n~se pueden utilizar el proceso para que las cosas salgan mejor.
como un nombre o como un verbo, las definiciones
de estos tCrminos se pueden confundir. Dentro del con-
texto de la ingenieria del software, una medida pro-
porciona una indicaci6n cuantitativa de la extension,
cantidad, dimensiones, capacidad o tamafio de algu-
nos atributos de un proceso o producto. La medicidn
es el act0 de determinar una medida. El IEEE Stan-
dard Glossary of Software Engineering Terms [IEEE93]
define me'trica como ccuna medida cuantitativa del gra-
do en que un sistema, componente o proceso posee
un atributo dado),. Por ejemplo, cuatro equipos de software est8n tra-
Cuando, simplemente, se ha recopilado un solo bajando en un proyecto grande de software. Cada equi-
aspecto de 10s datos (por ejemplo: el nlimero de erro- po debe conducir revisiones del diseiio, per0 puede
res descubiertos en la revision de un modulo), se ha seleccionar el tipo de revision que realice. Sobre el
establecido una medida. La medicion aparece como examen de la mktrica, errores encontrados por per-
resultado de la recopilaci61-1de uno o varios aspectos sona-hora consumidas, el gestor del proyecto notifi-
de 10s datos (por ejemplo: se investiga un numero de ca que dos equipos que utilizan mCtodos de revision
revisiones de m6dulos para recopilar medidas del m8s formales presentan un 40 por 100 m5s de erro-
numero de errores encontrados durante cada revision). res encontrados por persona-hora consumidas que
Una mktrica del software relata de alguna forma las otros equipos. Suponiendo que todos 10s parametros
medidas individuales sobre alglin aspecto (por ejem- son iguales, esto proporciona a1 gestor del proyecto
plo: el nlimero medio de errores encontrados por revi- un indicador en el que 10s mCtodos de revision mAs
sion o el nlimero medio de errores encontrados por formales pueden proporcionar un ahorro mayor en
persona y hora en revisiones'). inversion de tiempo que otras revisiones con un enfo-
Un ingeniero del software recopila medidas y desa- que menos formal. Esto puede sugerir que todos 10s
rrolla mCtricas para obtener indicadores. Un indica- equipos utilicen el enfoque m8s formal. La mCtrica
do7 es una mktrica o una combinacion de mktricas que proporciona a1 gestor una visidn m8s profunda. Y ade-
proporcionan una vision profunda del proceso del soft- mas le llevar8 a una toma de decisiones m8s funda-
ware, del proyecto de software o del producto en si mentada.
' Esto asume que se recopila otra medida, persona y horas gastadas
en cada revision.
CAPfTULO 4 P R O C E S O DEL S O F T W A R E Y M ~ T R I C A SD E L P R O Y E C T O
La medici6n es algo com6n en el mundo de la ingenie- En algunos casos, se pueden utilizar las mismas
ria. Se mide el consumo de energia, el peso, las dimen- mCtricas del software para determinar tanto el pro-
siones fisicas, la temperatura, el voltaje, la relaci6n yecto como 10s indicadores del proceso. En realidad,
sefial-ruido.. . la lista es casi interminable. Por desgra- las medidas que recopila un equipo de proyecto y las
cia, la medici6n es mucho menos com6n en el mundo convierte en mCtricas para utilizarse durante un pro-
de la ingenieria del software. Existen problemas para yecto tambiCn pueden transmitirse a 10s que tienen la
ponerse de acuerdo sobre quC medir y las medidas de responsabilidad de mejorar el proceso del software.
evaluaci6n de problemas recopilados. Por esta raz6n, se utilizan muchas de las mismas mCtri-
cas tanto en el dominio del proceso como en el del
proyecto.
Referencia web L /
Se puede descorgor uno guio completa 4.2.1. Metricas del proceso y mejoras
de mitricos del software desde: en el proceso del software
www.inv.nasa.gov/SWG/resourtes/ La unica forma racional de mejorar cualquier proceso
NASA-GB-001-94.pdf es medir atributos del proceso, desarrollar un juego de
Se deberian recopilar metricas para que 10s indica- mCtricas significativas seg6n estos atributos y entonces
dores del proceso y del producto puedan ser ciertos. Los utilizar las mCtricas para proporcionar indicadores que
indicadores de proceso permiten a una organizaci6n de conducirAn a una estrategia de mejora. Pero antes de
ingenieria del software tener una visi6n profunda de la estudiar las mCtricas del software y su impacto en la
eficacia de un proceso ya existente (por ejemplo: el para- mejoras de 10s procesos del software es importante des-
digma, las tareas de ingenieria del software, productos tacar que el proceso es el 6nico factor de 4 0 s controla-
de trabajo e hitos). TambiCn permiten que 10s gestores bles a1 mejorar la calidad del software y su rendimiento
eval6en lo que funciona y lo que no. Las mCtricas del como organizaciom [PAU94].
proceso se recopilan de todos 10s proyectos y durante
un largo period0 de tiempo. Su intento es proporcionar
indicadores que lleven a mejoras de 10s procesos de soft-
ware a largo plazo.
Los indicadores de proyecto permiten a1 gestor de Lo hobilidod y lo motivoci6n del personal reolizondo
proyectos del software (1) evaluar el estado del proyecto el trobojo son 10s foctores mas importantes que influyen
en curso; (2) seguir la pista de 10s riesgos potenciales; en lo colidod del software.
(3) detectar las Areas de problemas antes de que se con-
viertan en <<criticas>>;(4) ajustar el flujo y las tareas del En la Figura 4.1, el proceso se sit6a en el centro de
trabajo, y (5) evaluar la habilidad del equipo del pro- un trihngulo que conecta tres factores con una pro-
yecto en controlar la calidad de 10s productos de traba- funda influencia en la calidad del software y en el ren-
jo del software. dimiento como organizacih. La destreza y la
motivaci6n del personal se muestran como el 6nico
Producto
factor realmente influyente en calidad y en el rendi-
miento [BOE81]. La complejidad del producto pue-
de tener un impacto sustancial sobre la calidad y el
rendimiento del equipo. La tecnologia (por ejemplo:
mCtodos de la ingenieria del software) que utiliza el
proceso tambiCn tiene su impacto. AdemBs, el triAn-
gulo de proceso existe dentro de un circulo de condi-
ciones de entomos que incluyen entomos de desarrollo
(por ejemplo: herramientas CASE), condiciones de
gesti6n (por ejemplo: fechas tope, reglas de empresa)
y caracteristicas del cliente (por ejemplo: facilidad de
comunicaci6n).
$om0 puedo medir

FIGURA 4.1. Determinantes de la calidad del software
la efectividad de un proceso
y de la efectividad de organizacion
de software?
(adaptado segun [PAU94]).
La eficacia de un proceso de software se mide indi-

. rectarnente. Esto es, se extrae un juego de mCtricas seglin
10s resultados que provienen del proceso. Entre 10s resul-
tados se incluyen medidas de errores detectados antes Los metricos publicos perrniten a uno orgonizocion
de la entrega del software, defectos detectados e infor- reolizor carnbios estrotegicos que mejoron el proceso
mados a 10s usuarios finales, productos de trabajo entre- del software y combios tbcticos duronte un proyecto
gados (productividad), esfuerzo humano y tiempo de software.
consumido, ajuste con la planificaci6n y otras medidas.
Las mCtricas de proceso tambiCn se extraen midiendo
las caracteristicas de tareas especificas de la ingenieria Las mCtricas pliblicas generalmente asimilan infor-
del software. Por ejemplo, se podria medir el tiempo y macidn que originalmente era privada de particulares y
el esfuerzo de llevar a cab0 las actividades de protec- equipos. Los indices de defectos a nivel de proyecto (no
ci6n y las actividades genericas de ingenieria del soft- atribuidos absolutamente a un particular), esfuerzo, tiem-
ware del Capitulo 2. po y datos afines se recopilan y se evallian en un inten-
Grady [GRA92] argumenta que existen unos usos to de detectar indicadores que puedan mejorar el
c<privadosy pliblicos)) para diferentes tipos de datos rendimiento del proceso organizativo.
de proceso. Como es natural que 10s ingenieros del Las mCtricas del proceso del software pueden pro-
software pudieran sentirse sensibles ante la utiliza- porcionar beneficios significativos a medida que una
ci6n de mCtricas recopiladas sobre una base particu- organization trabaja por mejorar su nivel global de
lar, estos datos deberian ser privados para el individuo madurez del proceso. Sin embargo, a1 igual que todas las
y servir s610 como un indicador de ese individuo. mCtricas, Cstas pueden usarse mal, originando mas pro-
Entre 10s ejemplos de me'tricas privadas se incluyen: blemas de 10s que pueden solucionar. Grady [GRA92]
indices de defectos (individualmente), indices de sugiere una ccetiqueta de mCtricas del softwaren adecua-
defectos (por mbdulo), errores encontrados durante el da para gestores a1 tiempo que instituyen un programa
desarrollo. de metricas de proceso:
La filosofia de ccdatos de proceso privadow se ajus-
ta bien con el enfoque del proceso personal del soft- Utilice el sentido comun y una sensibilidad organi-
ware propuesto por Humphrey [HUM95]. Humphrey zativa a1 interpretar datos de mCtricas.
describe el enfoque de la manera siguiente: Proporcione una retroalimentaci6n regular para par-
ticulares y equipos que hayan trabajado en la reco-
El proceso personal del software (PPS) es un conjunto
estructurado de descripciones de proceso, mediciones y mCto-
pilacion de medidas y metricas.
dos que pueden ayudar a que 10s ingenieros mejoren su rendi- No utilice metricas para evaluar a particulares.
miento personal. Proporcionan las formas, guiones y esthdares Trabaje con profesionales y equipos para establecer
que les ayudan a estimar y planificar su trabajo. Muestra c6mo objetivos claros y mCtricas que se vayan a utilizar
definir procesos y c6mo medir su calidad y productividad. Un
principio PPS fundamental es que todo el mundo es diferente para alcanzarlos.
y que un mCtodo que sea efectivo para un ingeniero puede que No utilice nunca mCtricas que amenacen a particu-
no sea adecuado para otro. Asi pues, el PPS ayuda a que 10s lares o equipos.
ingenieros midan y sigan la pista de su trabajo para que pue-
dan encontrar 10s mCtodos que sean mejores para ellos.
Los datos de mCtricas que indican un irea de proble-
mas no se deberian considerar c<negativos>>.
Estos datos
son meramente un indicador de mejora de proceso.
Humphrey reconoce que la mejora del proceso del
software puede y debe empezar en el nivel individual. No se obsesione con una sola metrica y excluya otras
Los datos privados de proceso pueden servir como refe- metricas importantes.
rencia importante para mejorar el trabajo individual del
ingeniero del software.
Algunas mCtricas de proceso son privadas para el i Q u i diredrkes deben
aplicarse cuando recogemos
equipo del proyecto de software, per0 pliblicas para
metricas del software?
todos 10s miembros del equipo. Entre 10s ejemplos se
incluyen 10s defectos informados de funciones impor-
tantes del software (que un grupo de profesionales han A medida que una organizaci6n esta m8s a gusto con
desarrollado), errores encontrados durante revisiones la recopilaci6n y utiliza mCtricas de proceso, la deriva-
tCcnicas formales, y lineas de c6digo o puntos de fun- ci6n de indicadores simples abre el camino hacia un
ci6n por modulo y funci6n2.El equipo revisa estos datos enfoque mas riguroso llamado mejora estadistica de
para detectar 10s indicadores que pueden mejorar el ren- proceso del software (MEPS). En esencia, MEPS utili-
dimiento del equipo. za el analisis de fallos del software para recopilar infor-
Consulte las Secciones 4.3.1 y 4.3.2 para estudios mas detallados

sobre LDC (lineas de codigo) y metricas de puntos de funcion.
I N G E N I E R ~ ADEL SOFTWARE. UN ENFOOUE PRACTICO
4.2.2. M6tricas del proyecto La utilizaci6n de mktricas para el proyecto tiene dos
Las metricas del proceso de software se utilizan para aspectos fundamentales. En primer lugar, estas metri-
propositos estrategicos. Las medidas del proyecto de cas se utilizan para minimizar la planificacion de desa-
software son tacticas. Esto es, las metricas de proyec- rrollo haciendo 10s ajustes necesarios que eviten retrasos
tos y 10s indicadores derivados de ellos 10s utilizan un y reduzcan problemas y riesgos potenciales. En segun-
gestor de proyectos y un equipo de software para adap- do lugar, las metricas para el proyecto se utilizan para
tar el flujo del trabajo del proyecto y las actividades evaluar la calidad de 10s productos en el momento actual
tecnicas. y cuando sea necesario, modificando el enfoque tecni-
co que mejore la calidad.
~Comodebemos
10s tbcnicos de estirnocibn de proyectos se estudion
utilizar las metricas
en el copitulo 5.
durante el proyecto?
La primera aplicacion de mktricas de proyectos en A medida que mejora la calidad, se minimizan 10s
la mayoria de 10s proyectos de software ocurre duran- defectos, y a1 tiempo que disminuye el ndmero de defec-
te la estimacion. Las metricas recopiladas de proyectos tos, la cantidad de trabajo que ha de rehacerse tambien
anteriores se utilizan como una base desde la que se rea- se reduce. Esto lleva a una reduccion del coste global
lizan las estimaciones del esfuerzo y del tiempo para el del proyecto.
actual trabajo del software. A medida que avanza un Otro modelo de metricas del proyecto de software
proyecto, las medidas del esfuerzo y del tiempo consu- [HET93] sugiere que todos 10s proyectos deberian medir:
mido se comparan con las estimaciones originales (y la entradas: la dimension de 10s recursos (p. ej.: perso-
planificacion de proyectos). El gestor de proyectos uti- nas, entomo) que se requieren para realizar el trabajo,
liza estos datos para supervisar y controlar el avance.
A medida que comienza el trabajo tkcnico, otras salidas: medidas de las entregas o productos creados
metricas de proyectos comienzan a tener significado. durante el proceso de ingenieria del software,
Se miden 10s indices de production representados resultados: medidas que indican la efectividad de las
mediante paginas de documentacion, las horas de revi- entregas.
sib, 10s puntos de funci6n y las lineas fuente entre- En realidad, este modelo se puede aplicar tanto a1
gadas. Ademas, se sigue la pista de 10s errores proceso como a1 proyecto. En el context0 del proyecto,
detectados durante todas las tareas de ingenieria del el modelo se puede aplicar recursivamente a medida
software. Cuando va evolucionando el software des- que aparece cada actividad estructural. Por consiguien-
de la especificacion a1 diseiio, se recopilan las mCtri- te las salidas de una actividad se convierten en las entra-
cas tkcnicas (Capitulos 19 a1 24) para evaluar la das de la siguiente. Las metricas de resultados se pueden
calidad del diseiio y para proporcionar indicadores utilizar para proporcionar una indicacion de la utilidad
que influiran en el enfoque tomado para la generacion de 10s productos de trabajo cuando fluyen de una acti-
y prueba del codigo. vidad (o tarea) a la siguiente.
Las mediciones del mundo fisico se pueden categorizar ~Cuales la diferencia

de dos maneras; nzedidas directas (por ejemplo: la lon- entre medidas directas
gitud de un tomillo) y nzedidas indirectas (por ejemplo: e indirectas?
la cccalidad>>de 10s tomillos producidos, medidos con-
tando 10s articulos defectuosos). Las mktricas del soft-
ware se pueden categorizar de forma similar. El coste y el esfuerzo requerido para construir el soft-
Entre las medidas directas del proceso de la inge- ware, el numero de lineas de codigo producidas, y otras
nieria del software se incluyen el coste y el esfuerzo medidas directas son relativamente faciles de reunir,
aplicados. Entre las medidas directas del producto se mientras que 10s convenios especificos para la medicion
incluyen las lineas de codigo (LDC) producidas, velo- se establecen mas adelante. Sin embargo, la calidad y
cidad de ejecucion, tamaiio de memoria, y 10s defectos funcionalidad del software, o su eficiencia o manteni-
informados durante un period0 de tiempo establecido. miento son mas dificiles de evaluar y solo pueden ser
Entre las medidas indirectas se incluyen la funcionali- medidas indirectamente.
dad, calidad, complejidad, eficiencia, fiabilidad, facili- El dominio de las metricas del software se dividen
dad de mantenimiento y muchas otras cccapacidadesu en mCtricas de proceso, proyecto y producto. Tambien
tratadas en el Capitulo 19. se acaba de destacar que las metricas de producto que
CAPfTULO 4 P R O C E S O DEL SOFTWARE Y MeTRICAS DEL P R O Y E C T O
son privadas para un individuo a menudo se combinan iQu6 datos deberiamos

para desarrollar mCtricas del proyecto que Sean publi- reunir para derivar metricas
cas para un equipo de software. Las mCtricas del pro- orientadus a1 tamaiio?
yecto se consolidan para crear metricas de proceso que
Sean publicas para toda la organizaci6n del software.
Pero jc6m0 combina una organizaci61-1metricas que Pag. Doc. Errores Defectos Personas
provengan de particulares o proyectos?
365 134 29 3
Beta 27,200 62 440 1224 321 86 5
Gamma 20,200 43 314 1050 256 64 6
Puesto que muchos forfares influyen en el trobojo

del s o h r e , no utilice 10s metn'cos porn comporor
. . .
penonos o equipos.
Para ilustrarlo, se va a tener en consideracidn un

ejemplo sencillo. Personas de dos equipos de proyecto
diferentes registran y categorizan todos 10s errores que
se encuentran durante el proceso del software. Las medi- FIGURA 4.4. Metricas orientadas al tamatio.
das de las personas se combinan entonces para desa-
rrollar medidas de equipo. El equipo A encontr6 342
errores durante el proceso del software antes de su rea- Para desarrollar mCtricas que se puedan comparar
lizaci6n. El equipo B encontr6184. Considerando que entre distintos proyectos, se seleccionan las lineas de
en el resto 10s equipos son iguales, jquC equipo es mis c6digo como valor de normalizaci6n. Con 10s rudi-
efectivo en detectar errores durante el proceso? Como mentarios datos contenidos en la tabla se pueden desa-
no se conoce el tamaiio o la complejidad de 10s proyec- rrollar para cada proyecto un conjunto de mCtricas
tos, no se puede responder a esta pregunta. Sin embar- simples orientadas a1 tamaiio:
go, si se normalizan las medidas, es posible crear errores por KLDC (miles de lineas de c6digo)
mCtricas de software que permitan comparar medidas defectos4 por KLDC
mis amplias de otras organizaciones. £por LDC
piginas de documentaci6n por KLDC
4.3.1. Metricas Orientadas a1 Tamaiio
Las mCtricas del software orientadas a1 tamaiio provie-
nen de la normalizacidn de las medidas de calidad y/o
productividad considerando el cctamaiio>>del software
que se haya producido. Si una organizaci6n de softwa-
re mantiene registros sencillos, se puede crew una tabla Plantilla de coleccion de m6tricas
de datos orientados a1 tamaiio, como la que muestra la
Figura 4.4. La tabla lista cada proyecto de desarrollo de Ademk, se pueden calcular oms mCtricas interesantes:
software de 10s ultimos aiios y las medidas correspon- errores por persona-mes
dientes de cada proyecto. RefiriCndonos a la entrada de
LDC por persona-mes
la tabla (Fig. 4.4) del proyecto alfa: se desarrollaron
12.100 lineas de c d i g o (LDC) con 24 personas-mes y £ por pigina de documentaci6n
con un coste de £168.000. Debe tenerse en cuenta que
el esfuerzo y el coste registrados en la tabla incluyen 4.3.2. Metricas Orientadas a la Funci6n
todas las actividades de ingenieria del software (anili- Las mktricas del software orientadas a la funci6n utili-
sis, disefio, codificaci6n y prueba) y no s610 la codifi- zan una medida de la funcionalidad entregada por la
caci6n. Otra informaci6n sobre el proyecto alfa indica aplicaci6n como un valor de normalizacibn. Ya que la
que se desarrollaron 365 piginas de documentaci6n, se ccfuncionalidad>> no se puede medir directamente, se
registraron 134 errores antes de que el software se entre- debe derivar indirectamente mediante otras medidas
gara y se encontraron 29 errores despuCs de entregh- directas. Las mCtricas orientadas a la funci6n fueron
selo a1 cliente dentro del primer aiio de utilizacibn. propuestas por primera vez por Albretch [ALB79],quien
TambiCn sabemos que trabajaron tres personas en el sugiri6 una medida llamada punto defuncidn. Los pun-
desarrollo del proyecto alfa. tos de funci6n se derivan con una relaci6n empirica
Un defect0 ocurre cuando las actividades de garantia de calidad (p.

ej.: revisiones tecnicas formales) fallan para descubrir un error en un
product0 de trabajo generado durante el proceso del sofiware.
lNGENIERfA DEL SOFTWARE. UN ENFOQUE PRACTICO
seglin las medidas contables (directas) del dominio de Factor de ponderacion

. informaci6ndel software y las evaluaciones de la com- Parametros
de medicion Cuenta Simple Medio Complejo
plejidad del software.
Numero
de entradas
de usuario
4
6 =a
Referencia web/ '
Se puede obtener informocion completo sobre 10s puntos
Numero
de salidas
de usuario ox 5
de funtion en: www.ifpug.org
Los puntos de funci6n se calculan [IFP94] comple-

Numero
de peticiones
de usuario ox 4 6 =a
tando la tabla de la Figura 4.5. Se determinan cinco
caracteristicas de dominios de informaci6n y se pro-
Numero
de archivos 5 = 01
porcionan las cuentas en la posici6n apropiada de la Numero
tabla. Los valores de 10s dominios de informaci6n se de interfaces 7
externas
definen de la forma siguiente5:
Cuenta total
Nlimero de entradas de usuario. Se cuenta cada
eritrada de usuario que proporciona diferentes datos
orientados a la aplicaci6n. Las entradas se deberian FIGURA 4.5. C a l c u l o de p u n t o s de f u n c i o n .
diferenciar de las peticiones, las cuales se cuentan de
forma separada. Para calcular puntos de funci6n (PF), se utiliza la
relaci6n siguiente:
PF = cuenta-total x [0,65 + 0,01 x 6(Fi )] (4.1)
en donde cuenta-total es la suma de todas las entradas
Los puntos de funcibn se derivon de medidos PF obtenidas de la figura 4.5.
directos del dominio de lo informoci6n. Fi (i = 1 a 14) son ccvalores de ajuste de la compleji-
dad>>seglin las respuestas a las siguientes preguntas
Nlimero de salidas de usuario. Se cuenta cada salida
[ART851:
que proporciona a1 usuario informaci6n orientada a la
aplicaci6n. En este context0 la salida se refiere a infor- 1. ~Requiereel sistema copias de seguridad y de recu-
mes, pantallas, mensajes de error, etc. Los elementos peraci6n fiables?
de datos particulms dentro de un informe no se cuen- 2. LSe requiere comunicaci6n de datos?
tan de forma separada. 3. existe en funciones de procesamiento distribuido?
Nlimero de peticiones de usuario. Una petici6n se 4. iEs critic0 el rendimiento?
define como una entrada interactiva que produce la gene- 5. iSe ejecutari el sistema en un entorno operativo
raci6n de alguna respuesta del software inrnediata en existente y fuertemente utilizado?
forma de salida interactiva. Se cuenta cada petici6n por 6. ~Requiereel sistema entrada de datos interactiva?
separado.
Nlimero de archivos. Se cuenta cada archivo maes- 7. ~Requierela entrada de datos interactiva que las
tro 16gico (esto es, un grupo Mgico de datos que puede transacciones de entrada se lleven a cab0 sobre m61-
ser una parte de una gran base de datos o un archivo tiples pantallas u operaciones?
independiente). 8. i S e actualizan 10s archivos maestros de forma
N~imerode interfaces externas. Se cuentan todas interactiva?
las interfaces legibles por la miquina (por ejemplo: 9. iSon complejas las entradas, las salidas, 10s archi-
archivos de datos de cinta o disco) que se utilizan vos o las peticiones?
para transmitir informaci6n a otro sistema. 10. iEs complejo el procesamiento interno?
Una vez que se han recopilado 10s datos anterio- 11. iSe ha diseiiado el c6digo para ser reutilizable?
res, a la cuenta se asocia un valor de complejidad. 12. i E s t h incluidas en el disefio la conversi6n y la ins-
Las organizaciones que utilizan mCtodos de puntos talaci6n?
de funci6n desarrollan criterios para determinar si 13. iSe ha disefiado el sistema para soportar m6ltiples
una entrada en particular es simple, media o com- instalaciones en diferentes organizaciones?
pleja. No obstante la determinaci6n de la compleji- 14. iSe ha diseiiado la aplicaci6n para facilitar 10s cam-
dad es algo subjetiva. bios y para ser ficilmente utilizada por el usuario?
En realidad, la definition de 10s valores del dominio de la informa-

cion y la forma en que se cuentan es un poco mas cornplejo. El lec-
tor interesado deberia consultar [IFP94] para obtener mas detalles.
PROCESO DEL SOFTWARE Y M ~ T R I C ADEL
S PROYECTO
Cada una de las preguntas anteriores es respondida

usando una escala con rangos desde 0 (no importante o
aplicable) hasta 5 (absolutamente esencial). Los valo-
res constantes de la ecuaci6n (4.1) y 10s factores de peso Referencia web/ '
que se aplican a las cuentas de 10s dominios de infor- Se puede encontror uno listo ljtil de preguntos reolizodos
macidn se determinan empiricamente. con frecuencio sobre 10s puntos de funcibn (y puntos
Una vez que se han calculado 10s puntos de funcibn, de funcibn extendidos) en:
se utilizan de forma aniloga a las LDC como forma de http://ourworkl.compuserve.com/
normalizar las medidas de productividad, calidad y otros
atributos del software.
Boeing ha desarrollado otra extension de punto de
4.3.3. Metricas ampliadas de punto de funci6n funci6n para sistemas en tiempo real y productos de
ingenieria. El enfoque de Boeing integra la dimension
La medida de punto de funci6n se disefio originalmen- de datos del software con las dimensiones funciona-
te para aplicarse a aplicaciones de sistemas de infor- les y de control para proporcionar una medida orien-
maci6n de gesti6n. Para acomodar estas aplicaciones, tada a la funci6n que es adecuada a aplicaciones que
se enfatiz6 la dimensidn de datos (10s valores de domi- enfatizan las capacidades de control y funci6n. Las
nios de informaci6n tratados anteriormente) para la caracteristicas de las tres dimensiones del software se
exclusi6n de dimensiones (control) funcionales y de cccuentan, cuantifican y transforman,, en una medida
comportamiento. Por esta raz6n, la medida del punto de que proporciona una indicaci6n de la funcionalidad
funci6n era inadecuada para muchos sistemas de inge- entregada por el software6, llamada Punto de Funcidn
nieria y sistemas empotrados (que enfatizan funci6n y 3 0 [WHI95]
control). Para remediar esta situaci6n se ha propuesto La dimensidn de datos se evallia exactamente igual
un nlimero de extensiones a la mCtrica del punto de fun- a como se describe en la Secci6n 4.3.2. Las cuentas de
ci6n bisica. datos retenidos (la estructura interna de datos de pro-
gramas, p. ej.: archivos) y 10s datos externos (entradas,
salidas, peticiones y referencias externas) se utilizan a
lo largo de las medidas de la complejidad para derivar
una cuenta de dihensi6n de datos.
Lo extension de 10s puntos de funcibn se utilizo La dimensio'n funcional se mide considerando <<el
en lo ingenierio, en 10s oplicociones de tiempo real nlimero de operaciones internas requeridas para trans-
y en 10s oplicociones orientadas ol control. formar datos de entrada en datos de salidan [WHI95].
Para propdsitos de computaci6n de 10s puntos de fun-
Una extensi6n del punto de funci6n es la llamada ci6n 3D, se observa una cctransformaci6nn como una
puntos de caracten'sticas [JON91]; es una ampliacion serie de pasos de proceso que quedan limitados por sen-
de la medida del punto de funci6n que se puede aplicar tencias seminticas. La dimensidn de control se mide
a sistemas y aplicaciones de ingenieria del software. La contando el nlimero de transiciones entre estados7.
medida de punto de caracteristica acomoda a aplica- Un estado representa alg6n mod0 de comporta-
ciones en donde la complejidad del algoritmo es alta. miento externamente observable, y una transition ocu-
Las aplicaciones de software de tiempo real, de control rre como resultado de alglin suceso que cambia el
de procesos, y empotradas tienden a tener alta comple- mod0 de comportamiento del sistema o del software
jidad de algoritmos y por lo tanto son adecuadas para (esto es, cambia el estado). Por ejemplo, un telkfono
el punto de caracteristica. inalimbrico contiene software que soporta funciones
Para calcular el punto de caracteristica, 10s valores de marcado automitico. Para introducir el estado de
de dominio de informacidn se cuentan otra vez y se pesan marcado automitico desde un estado en descanso, el
de la forma que se describe en la Secci6n 4.3.2. Ademis, usuario pulsa una tecla Auto en el teclado numCrico.
la mCtrica del punto de caracteristica cuenta una carac- Este suceso hace que una pantalla LCD pida un c6di-
teristica nueva del software -10s algoritmos. Un algo- go que indique la parte que se llama. Con la entrada
ritmo se define como can problema de cilculo limitado del c6digo y pulsando la tecla de Marcado (otro suce-
que se incluye dentro de un programa de computadora so), el software del telkfono inalimbrico hace una
especificon [JON91]. Invertir una matriz, decodificar transici6n a1 estado de marcado. Cuando se compu-
una cadena de bits o manejar una intermpci6n son ejem- tan puntos de funci6n 3D, no se asigna un valor de
plos de algoritmos. complejidad a las transiciones.
Debe setialarse que tambien han sido propuestas otras extensiones ' En el capitulo 12 se presenta un estudio detallado de la dimension
a 10s puntos de funcion para aplicarlas en trabajos de soflware de de comportamientos que incluyen estados y transiciones de estados
tiempo real (p.ej., [ALA97]). Sin embargo, ninguno de estos parece
usarse ampliamente en la industria.
INGENIERIA DEL SOFTWARE. UN ENFOQUE PRACTICO
Para calcular puntos de funci6n 3D, se utiliza la rela- El punto de funci6n (y sus extensiones), como la
.ci6n siguiente: medida LDC, es controvertido. Los partidarios afirman
que PF es independiente del lenguaje de programaci6n,
indice=I+O+Q+F+E+T+R (4.2)
lo cual es ideal para aplicaciones que utilizan lenguajes
en donde I, 0 , Q, F, E, T y R representan valores con convencionales y no procedimentales; esto se basa en
peso de complejidad en 10s elementos tratados ante- 10s datos que probablemente se conocen a1 principio de
riormente: entradas, salidas, peticiones, estructuras de la evolution de un proyecto, y asi el PF es mAs atracti-
datos internas, archivos externos, transformaciones y vo como enfoque de estimaci6n.
transiciones, respectivamente. Cada valor con peso de
complejidad se calcula con la relaci6n siguiente:
valor con peso de complejidad =
proceso
en donde Nil ,Nia y Nih representan el numero de apa-
I
1-10 Bajo I Bajo I Medio
riciones del elemento i (p. ej.: salidas) para cada nivel
Bajo Medio Alto
de complejidad (bajo, medio, alto), y Wil , Wia y Wih
son 10s pesos correspondientes. El c6lculo global de 10s Medio Alto Alto
puntos de funci6n 3D se muestran en la Figura 4.6.
Se deberia seiialar que 10s puntos de funci6n, 10s pun- FIGURA 4.6. Calculo de 10s indices de 10s puntos
tos de caracteristica y 10s puntos de funci6n 3D repre- de funcion 3D.
sentan lo mismo -ccfuncionalidad>> o ccutilidad,,
entregada por el software-. En realidad, cada una de Los detractores afirman que el mCtodo requiere algun
estas medidas producen el mismo valor si s610 se con- ccjuego de manos>>en el que el cAlculo se base en datos
sidera la dimensi6n de datos de una aplicaci6n. Para sis- subjetivos y no objetivos; y afirman que las cuentas del
temas de tiempo real mAs complejos, la cuenta de puntos dominio de informacion (y otras dimensiones) pueden
de caracten'stica a menudo se encuentra entre el 20 y el ser dificiles de recopilar despuCs de realizado, y por ulti-
35 por 100 mAs que la cuenta determinada s610 con 10s mo que el PF no tiene un significado fisico direct0 +s
puntos de funci6n. simplemente un numero-.
La relaci6n entre las lineas de c a i g o y 10s puntos de fun-

ci6n depende del lenguaje de programaci6n que se utili- Lenguaje de programacion LDCIPF (media)
ce para implementarel software,y de la calidad del diseiio. Ensamblador
Ciertos estudios han intentado relacionar las mktricas LDC C
y PF. Citando a Albrecht y Gaffney [ALB83]: COBOL
La tesis de este trabajo es que la cantidad de funci6n prc- FORTRAN
porcionada por la aplicaci6n (programa) puede ser estimada Pascal
por la descomposici6n de 10s principales componentess de datos C++
que usa o proporciona el programa. Ademk, esta estimaci6n Ada95
de la funci6n debe ser relacionada con el total de LDC a desa- Visual Basic
rrollar y con el esfuerzo de desarrollo necesario. Smalltalk
La tabla siguiente [JON981 proporciona estimacio- Powerbuilder (generador de c6digo)
nes informales del ndmero medio de lineas de c6digo SQL
que se requiere para construir un punto de funci6n en
varios lenguajes de programaci6n:
Si conoces el numero Utilice el repaso de 10s dams de un modo juicioso.

de LDCfsf ies posible estimar Es bastonte mejor calcular 10s PF utilizondo 10s mitodos
el numero de puntos de funcion? utilizados ankriormenk.
ES importante destacar que la <<laindividualizacion de compo- zacion de mantenimiento podria observar el tamaiio de 10s pro-
nentes importantes. se puede interpretar de muchas maneras. yectos en relacion con 10spedidos de cambio de ingenieria (Capi-
Algunos ingenieros del software que trabajan en un entorno de tulo 9). Una organizacion de sistemas de informacion podria
desarrollo orientado a objetos (Cuarta Parte) utilizan ciertas cla- observar el numero de procesos de negocio a 10sque impacta una
ses u objetos como metrica dominante del tamaiio. Una organi- aplicacion.
CAPfTULO 4 P R O C E S O DEL S O F T W A R E Y M ~ T R I C A SDEL P R O Y E C T O
Una revisidn de 10s datos anteriores indica que una comparar la relacidn LDCIpersonas-mes (6 PFIperso-
LDC de C++ proporciona aproximadamente 1,6 veces nas-mes) de un grupo con 10s datos similares de otro
la <<funcionalidadu(de media) que una LDC de FOR- grupo? debe en 10s gestores evaluar el rendimiento de
TRAN. Ademas, una LDC de Visual Basic proporcio- las personas usando estas mCtricas? La respuesta a estas
na 3 veces la funcionalidad de una LDC de un lenguaje preguntas es un rotundo <<NOD. La raz6n para esta res-
de programacidn convencional. En [JON981 se presen- puesta es que hay muchos factores que influyen en la
tan datos mis precisos sobre las relaciones entre 10s PF productividad, haciendo que la comparaci6n de <<man-
y las LDC, que pueden ser usados para <<repasampro- zanas y naranjaw sea ma1 interpretada con facilidad.
gramas existentes, determinando sus medidas en PF (por Se han encontrado 10s puntos de funci6n y las LDC
ejemplo, para calcular el numero de puntos de funcidn basadas en metricas para ser predicciones relativamen-
cuando se conoce la cantidad de LDC entregada). te exactas del esfuerzo y coste del desarrollo del soft-
Las medidas LDC y PF se utilizan a menudo para ware. Sin embargo, para utilizar LDC y PF en las
extraer metricas de productividad. Esta invariabilidad tCcnicas de estimacibn (capitulo S ) , debe establecerse
conduce a1 debate sobre el uso de tales datos. Se debe una linea base de informaci6n hist6rica.
El objetivo primordial de la ingenieria del software es prc-

ducir un sistema, aplicaci6n o producto de alta calidad.
Para lograr este objetivo, 10s ingenieros del software deben las aetividada de g o d o de colidod del software.
aplicar mCtodos efectivosjunto con herramientas moder-
nas dentro del context0 de un proceso maduro de desa-
rrollo de software. Adem&, un buen ingeniero del software
(y buenos gestores de la ingenieria del software) deben 4.5.1. Visi6n general de 10s factoresque afectan
medir si la alta calidad se va a llevar a cabo. a la calidad
La calidad de un sistema, aplicaci6n o producto es
tan bueno como 10s requisitos que describen el proble- Hace 25 aiios, McCall y Cavano [MCC78] definieron un
ma, el disefio que modela la soluci6n, el c6digo que con- juego de factores de cahdad como 10s primeros pasos hacia
duce a un programa ejecutable, y las pruebas que el desarrollo de mCtricas de la calidad del software. Estos
ejercitan el software para detectar errores. Un buen inge- factores evaluan el software desde tres puntos de vista dis-
niero del software utiliza mediciones que evaluan la tintos: (I) operaci6n del producto (utilizAndolo), (2) revi-
calidad del anilisis y 10s modelos de disefio, el c6digo si6n del producto (cambiindolo), y (3) transici6n del
fuente, y 10s casos de prueba que se han creado al apli- producto (modificAndolo para que funcione en un entor-
car la ingenieria del software. Para lograr esta evalua- no diferente, por ejemplo, <<portfindolo~). Los autores, en
ci6n de la calidad en tiempo real, el ingeniero debe su trabajo, describen la relaci6n entre estos factores de
utilizar medidas te'cnicas (Capitulos 19 y 24) que eva- calidad (lo que llaman un <<marc0de trabajo>>)y otros
luan la calidad con objetividad, no con subjetividad. aspectos del proceso de ingenieria del software:
En primer lugar, el marco de trabajo proporciona un meca-
nismo para que el gestor del proyecto identifique lo que consi-
3
Referencia Web
Se puede encontror una excelente fuente de informacibn
sobre lo calidad del software y temas relacionodos
dera importante. Estas cualidades son atributos del software,
ademas de su correccion y rendimiento funcional, que tiene
implicaciones en el ciclo de vida. En otros factores, como son
facilidad de mantenimiento y portabilidad, se ha demostrado
que tienen un impact0 sigmficativo en el coste del ciclo de vida.. .
En segundo lugar, el marco de trabajo pmporciona un medio
(incluyendo mitricas) en: www.qualityworld.tom de evaluar cuantitativamente lo bien que va pmgresando el desa-
rrollo en relaci6n con 10s objetivos de calidad establecidos...
El gestor de proyectos tambiCn debe evaluar la cali- En tercer lugar, el marco de trabajo proporciona m k inte-
dad objetivamente, y no subjetivarnente.A medida que racci6n del personal de QA (garantia de calidad) en el esfuer-
el proyecto progresa el gestor del proyecto tambiCn debe zo de desarrollo...
evaluar la calidad. Las metricas privadas recopiladas por Por 6ltim0,... el personal de garantia de calidad puede uti-
ingenieros del software particulares se asimilan para pro- lizar indicaciones de calidad pobre para ayudar a identificar
porcionar resultados en 10s proyectos. Aunque se pueden estkdares [mejores] a enfrentar en el futuro.
recopilar muchas medidas de calidad, el primer objetivo Un estudio detallado del marco de trabajo de McCall
en el proyecto es medir errores y defectos. Las mCtricas y Cavano, asi como otros factores de calidad, se pre-
que provienen de estas medidas proporcionan una indi- sentan en el Capitulo 19. Es interesante destacar que
caci6n de la efectividad de las actividades de control y casi todos 10s aspectos del cilculo han sufrido cambios
de la garantia de calidad en grupos o en particulares. radicales con el paso de 10s aoos desde que McCall y
1NGENIERfA DEL SOFTWARE. U N ENFOQUE PRACTICO
Cavano hicieron su trabajo, con gran influencia, en 1978. a sus usuarios finales-. Cuando la proporci6n de
.Per0 10s atributos que proporcionan una indicacibn de desperdicios en el coste global del proyecto (para
la calidad del software siguen siendo 10s mismos. muchos proyectos) se representa como una funci6n
del tiempo, el gestor puede determinar si la facilidad
total del software producido por una organization de
desarrollo esta mejorando. Se pueden emprender
acciones a partir de las conclusiones obtenidas de
Sorprendentemente, 10s foetores que definion lo colidod esa informaci6n.
del s o h a r e en el oiio 1970 son 10s mismos foctores Integridad. En esta Cpoca de <<hackers>> y <<fire-
que continhn definiendo lo ealidod del s o h o r e walls,,, la integridad del software ha llegado a tener
en la primero dkado de este siglo. mucha importancia. Este atributo mide la capacidad
de un sistema para resistir ataques (tanto accidentales
~ Q u Csignifica esto? Si una organizaci6n de software
como intencionados) contra su seguridad. El ataque
adopta un juego de factores de calidad como una dista
se puede realizar en cualquiera de 10s tres componentes
de comprobaci6n~para evaluar la calidad del softwa-
del software: programas, datos y documentos.
re, es probable que el software constmido hoy siga exhi-
biendo la calidad dentro de las primeras dCcadas de este Para medir la integridad, se tienen que definir
siglo. Incluso, cuando las arquitecturas de cfilculo sufren dos atributos adicionales: amenaza y seguridad.
cambios radicales (corno seguramente ocurriri), el soft- Amenaza es la probabilidad (que se puede estimar
ware que exhibe alta calidad en operaci6n, transition y o deducir de la evidencia empirica) de que un ata-
revisi6n continuara sirviendo tambiCn a sus usuarios. que de un tip0 determinado ocurra en un tiempo
determinado. La seguridad es la probabilidad (que
se puede estimar o deducir de la evidencia empi-
4.5.2. Medida d e l a calidad rica) de que se pueda repeler el ataque de un tip0
Aunque hay muchas medidas de la calidad de softwa- determinado. La integridad del sistema se puede
re, la correccidn,facilidad de mantenimiento, integri- definir corno:
dad, y facilidad de uso proporcionan indicadores utiles
para el equipo del proyecto. Gilb [GIL88] ha sugerido integridad = C [(l - amenaza) x (1 - seguridad)]
definiciones y medidas para cada uno de ellos. donde se suman la amenaza y la seguridad para cada
Correccion. Un programa debe operar correcta- tip0 de ataque.
mente o proporcionara poco valor a sus usuarios. La
correccion es el grado en el que el software lleva a Facilidad de uso. El calificativo ccamigable con el
cab0 su funci6n requerida. La medida m b comun de usuarion se ha convertido en omnipresente en las dis-
correccion es defectos por KLDC, en donde un cusiones sobre productos de software. Si un programa
defect0 se define como una falta verificada de con- no es <<migablecon el usuarios, frecuentemente esta
formidad con 10s requisitos. abocado a1 fracaso, incluso aunque las funciones que
realice Sean valiosas. La facilidad de uso es un intento
Facilidad de mantenimiento. El mantenimiento de cuantificar <<loamigable que puede ser con el usua-
del software cuenta con mas esfuerzo que cualquier no>>y se puede medir en funci6n de cuatro caracte-
otra actividad de ingenieria del software. La facili- nsticas: (1) habilidad intelectual y/o fisica requerida
dad de mantenimiento es la facilidad con la que se para aprender el sistema; (2) el tiempo requerido para
puede corregir un programa si se encuentra un error, llegar a ser moderadamente eficiente en el uso del sis-
se puede adaptar si su entomo cambia, o mejorar si tema; (3) aumento net0 en productividad (sobre el
el cliente desea un carnbio de requisitos. No hay enfoque que el sistema reemplaza) medida cuando
forma de medir directamente la facilidad de mante-
alguien utiliza el sistema moderadamente y eficiente-
nimiento; por consiguiente, se deben utilizar medi- mente; y (4) valoraci6n subjetiva (a veces obtenida
das indirectas. Una simple mCtrica orientada al mediante un cuestionario) de la disposici6n de 10s
tiempo es el tiempo medio de carnbio (TMC),es decir usuarios hacia el sistema. En el Capitulo 15 se estu-
el tiempo que se tarda en analizar la petici6n de cam- dia mas detalladamente este aspecto.
bio, en disefiar una modificaci6n adecuada, en imple-
mentar el carnbio, en probarlo y en distribuir el Los cuatro factores anteriores son s610 un ejemplo
carnbio a todos 10s usuarios. Como media, 10s pro- de todos 10s que se han propuesto como medidas de la
gramas que se pueden mantener tendran un TMC calidad del software. El Capitulo 19 considera este tema
mas bajo (para tipos equivalentes de cambios) que con mas detalle.
10s programas que no son mas ficiles de mantener.
Hitachi [TAJ81] ha utilizado una mCtrica orien- 4.5.3. Eficacia d e l a Elirninacion d e Defectos
tada a1 coste para la capacidad de mantenimiento lla- Una mCtrica de la calidad que proporciona beneficios
mada <<desperdiciosn- e l coste en corregir defectos tanto a nivel del proyecto como del proceso, es la efi-
encontrados despuCs de haber distribuido el software cacia de la eliminacidn de defectos (EED). En esen-
CAPfTULO 4 P R O C E S O DEL SOFTWARE Y MPTRICAS DEL P R O Y E C T O
cia, EED es una medida de la habilidad de filtrar las proyecto de software instituya tCcnicas para encontrar
actividades de la garantia de calidad y de control a1 todos 10s errores posibles antes de su entrega.
aplicarse a todas las actividades del marco de trabajo EED tambiCn se puede utilizar dentro del proyecto
del proceso. para evaluar la habilidad de un equipo en encontrar erro-
Cuando un proyecto se toma en consideracidn glo- res antes de que pasen a la siguiente actividad estructu-
balmente, EED se define de la forma siguiente: ral o tarea de ingenieria del software. Por ejemplo, la tarea
del analisis de 10s requisitos produce un modelo de an&
lisis que se puede revisar para encontrar y corregir erro-
donde E es el ndmero de errores encontrados antes de res. Esos errores que no se encuentren durante la revisidn
la entrega del software a1 usuario final y D es el nlime- del modelo de analisis se pasan a la tarea de disefio (en
ro de defectos encontrados despuCs de la entrega. donde se pueden encontrar o no). Cum60 se utilizan en
este contexto, EED se vuelve a definir como:
&ti es la efitientia
EEDi = Ei /(Ei + Ei +,) (4.5)
en donde Ei es el nlimero de errores encontrado duran- .
de elimination de defectos?
te la actividad de ingenieria del software i y Ei es el
nlimero de errores encontrado durante la actividad de
,
El valor ideal de EED es 1. Esto es, no se han encon- ingenieria del software i + I que se puede seguir para
trado defectos en el software. De forma realista, D sera llegar a errores que no se detectaron en la actividad de
mayor que cero, per0 el valor de EED todavia se pue- la ingenieria del software i.
de aproximar a 1. Cuando E aumenta (para un valor de
D dado), el valor total de EED empieza a aproximarse
a 1. De hecho, a medida que E aumenta, es probable
que el valor final de D disminuya (10s errores se filtran UtiIice EED como uno medidu de lo eficiencio
antes de que se conviertan en defectos). Si se utilizan de sus primeros octividodes de SQA. Si EED es bojo
como una mCtrica que proporciona un indicador de la duronte el onblisis y disefio, emplee olgh tiempo
habilidad de filtrar las actividades de la garantia de la mejorondo lo formu de conducir 10s revisiones tecnicos
calidad y del control, EED anima a que el equipo del formoles.
La mayoria de 10s desarrolladores de software todavia 4.6.1. Argumentos para las M6tricas del Software
no miden, y por desgracia, la mayoria no desean ni iPor quC es tan importante medir el proceso de inge-
comenzar. Como se ha sefialado en este capitulo, el pro- nieria del software y el product0 (software) que produ-
blema es cultural. En un intento por recopilar medidas ce? La respuesta es relativamente obvia. Si no se mide,
en donde no se haya recopilado nada anteriormente, a no hay una forma real de determinar si se estP mejo-
menudo se opone resistencia: <<iPorquC necesitamos rando. Y si no se est5 mejorando, se esta perdido.
hacer esto?>>,se pregunta un gestor de proyectos ago-
biado. <<Noentiendo por qu&, se queja un profesional
saturado de trabajo.
En esta seccibn, consideraremos algunos argumen-
tos para las mCtricas del software y presentaremos un
enfoque para instituir un programa de mCtricas dentro
de una organizaci6n de ingenieria del software. Pero
antes de empezar, consideremos algunas palabras de
cordura sugeridas por Grady y Caswell [GRA87]:
Algunas de las cosas que describimos aqui parecen bastan-
te fgciles. Realmente, sin embargo, establecer un prograrna de La gestidn de alto nivel puede establecer objetivos
metricas del software con exito es un trabajo duro. Cuando
decimos esto debes esperar a1 menos tres aiios antes de que
significativos de mejora del proceso de ingenieria del
esten disponibles las tendencias organizativas, lo que puede software solicitando y evaluando las medidas de pro-
darte alguna idea del h b i t o de tal esfuerzo. ductividad y de calidad. En el Capitulol se sefiald que
el software es un aspect0 de gesti6n estratCgico para
La advertencia sugerida por 10s autores se conside- muchas compaiiias. Si el proceso por el que se desa-
ra de un gran valor, per0 10s beneficios de la medicibn rrolla puede ser mejorado, se producira un impact0 d i m -
son tan convincentes que obligan a realizar este duro to en lo sustancial. Pero para establecer objetivos de
trabajo. . mejora, se debe comprender el estado actual de desa-
~ N G E N ~ E RDEL
~ A SOFTWARE. UN ENFOQUE PRACTICO
rrollo del software. Por lo tanto la medici6n se utiliza (3) las medidas deben ser consistentes, por ejemplo, una
-para establecer una linea base del proceso desde donde linea de c6digo debe interpretarse consistentemente en
se pueden evaluar las mejoras. todos 10s proyectos para 10s que se han reunido 10s datos;
Los rigores del trabajo diario de un proyecto del soft- (4) las aplicaciones deben ser semejantes para trabajar en
ware no dejan mucho tiempo para pensar en estrategias. la estimaci6n -tiene poco sentido utilizar una linea base
Los gestores de proyecto de software esthn mhs preo- obtenida en un trabajo de sistemas de informaci6n batch
cupados por aspectos mundanos (aunque igualmente para estimar una aplicaci6n empotrada de tiempo real-.
importantes): desarrollo de estimaciones significativas
del proyecto; produccidn de sistemas de alta calidad y 4.6.3. Colecci6n de metricas, c6mputo y evaluacih
terminar el producto a tiempo. Mediante el uso de medi-
ci6n para establecer una linea base del proyecto, cada El proceso que establece una linea base se muestra en la
uno de estos asuntos se hace rnhs fhcil de manejar. Ya Figura 4.7. Idealmente, 10s datos necesarios para estable-
hemos apuntado que la linea base sime como base para cer una linea base se han ido recopilando a medida que se
la estimaci6n. Ademhs, la recopilaci6n de mttricas de ha ido progresando. Por desgracia, este no es el caso. Por
calidad permite a una organizacidn ccsintonizar>> su pro- consiguiente, la recopilaci6n de datos requiere una inves-
ceso de ingenieria del software para eliminar las causas tigaci6n hist6rica de 10s proyectos anteriores para recons-
ccpoco vitalew de 10s defectos que tienen el mayor truir 10s datos requeridos. Una vez que se han recopilado
impact0 en el desarrollo del software9. medidas (incuestionablementeel paso rnhs dificil), el chl-
TCcnicamente (en el fondo), las mCtricas del soft- culo de mttricas es posible. Dependiendo de la amplitud
ware, cuando se aplican a1 producto, proporcionan bene- de las medidas recopiladas, las mttricas pueden abarcar
ficios inmediatos. Cuando se ha terminado el disefio del una gran gama de mttricas LDC y PF, asi como mitricas
software, la mayona de 10s que desarrollan pueden estar de la calidad y orientadas a1 proyecto. Finalmente, las
ansiosos por obtener respuestas a preguntas corno: mttricas se deben evaluar y aplicar durante la estimacibn,
el trabajo tkcnico, el control de proyectos y la mejora del
iQuC requisitos del usuario son rnhs susceptibles a1
proceso. La evaluaci6n de mCtricas se centra en las razo-
cambio? nes de 10s resultados obtenidos, y produce un grupo de
~QuC m6dulos del sistema son rnhs propensos a error? indicadores que guian el proyecto o el proceso.
iC6m0 se debe planificar la prueba para cada
mbdulo?
iCuhntos errores (de tipos concretos) puede esperar
cuando comience la prueba? 10sdotos de 10s m6tricos de lineo base deberion
Se pueden encontrar respuestas a esas preguntas si recogerse de uno gron muestro representoh
se han recopilado mttricas y se han usado como guia de proyectos de softwore del posodo.
tCcnica. En posteriores capitulos examinaremos c6mo
se hace esto.
4.6.2. Establecimiento de una Linea Base

Estableciendo una linea base de mCtricas se pueden obte-
ner beneficios a nivel de proceso, proyecto y producto (tk-
nico). Sin embargo la informaci6n reunida no necesita ser
fundarnentalmentediferente. Las mismas mktricas pueden
servir varias veces. Las lineas base de mCtricas constan de
datos recogidos de proyectos de software desarrollados
anteriormente y pueden ser tan simples como la tabla mos-
trada en la figura 4.4 o tan complejas como una gran base
de datos que contenga docenas de medidas de proyectos
y las mCtricas derivadas de ellos.
Para ser una ayuda efectiva en la mejora del proceso
y/o en la estimaci6n del esfuerzo y del coste, 10s datos de
lhea base deben tener 10s siguientes atributos: (1)10s datos
deben ser razonablementeexactos -se deben evitar cccon-
jetwas>>sobre proyectos pasados-; (2) 10s datos deben Proceso de recopilacion de metricas
reunirse del mayor ntimero de proyectos que sea posible; del software.
Estas ideas s e han formalizado en un enfoque denominado garan-

tia estadistica de calidad del soflware y s e estudian en detalle en el
Capitulo 8.
CAP1TULO 4 P R O C E S O DEL SOFTWARE Y MPTRICAS DEL PROYECTO
Uno de 10s problemas a1 que se han enfrentado 10s tra- Una vez que estas cuestiones se hayan establecido,
bajadores de las mCtricas durante las dos ultimas dCca- entonces es cuando puede ser desarrollada una mCtrica
das es la de desarrollar mCtricas que fueran litiles para que pueda ayudar a que se cumpla el objetivo planteado
el diseiiador de software. Ha sido toda una historia de que naturalmente emergerh a partir de estas cuestiones.
utilizaci6n de la mCtrica dentro de 10s entornos indus- La importancia de OPM proviene no solamente del
triales basada en el simple criterio de lo que era facili- hecho de que es uno de 10s primeros intentos de desa-
tar la medida, mhs que emplear cualquier criterio rrollar un conjunto de medidas adecuado que pueda ser
relacionado con la utilidad. El panorama de la 6ltima aplicado a1 software, sin0 tambiCn a1 hecho de que esta
mitad de 10s afios 80 y la primera mitad de la dCcada de relacionado con el paradigma de mejora de procesos
10s 90, constat6 el hecho de que mientras habia sido que ha sido discutido previamente. Basili ha desarro-
desarrollado mucho trabajo en la validacidn de la mCtri- llado un paradigma de mejora de calidad dentro del cual
ca y en el esclarecimiento de 10s principios te6ricos el mCtodo OPM puede encajarse perfectamente. El para-
detrhs de ella, muy poco habia sido hecho para dotar a1 digma comprende tres etapas:
disefiador de software con herramientas para la selec- Un proceso de llevar a cab0 una auditoria de un pro-
ci6n o construcci6n de mCtricas. yecto y su entorno estableciendo metas u objetivos
El objetivo de esta secci6n es describir OPM, que es de calidad para el proyecto y seleccionando herra-
casi con certeza el mCtodo de desarrollo de mCtrica mhs mientas adecuadas y mCtodos y tecnologias de ges-
ampliamente aplicado y mejor conocido y que ha sido desa- ti6n para que dichos objetivos de calidad tengan una
rrollado por Victor Basili y sus colaboradores de la Uni- oportunidad de cumplirse.
versidad de Maryland. Basili y sus colaboradores tenian
Un proceso de ejecutar un proyecto y chequear 10s
ya una larga historia de validaci6n de mCtricas en la dCca-
da de 10s 80 y el mCtodo OPM (objetivo, pregunta y mCtri- datos relacionados con esas metas u objetivos de cali-
ca) surgi6 de un trabajo que fue desarrollado dentro de un dad. Este proceso es llevado a cab0 en conjunci6n
laboratorio de ingenieria del software esponsorizado por con otro proceso paralelo de actuaci6n sobre 10s pro-
la Agencia Americana del Espacio, NASA. pios datos cuando se vea que el proyecto corre peli-
Basili establecia que para que una organizaci6n tuvie- gro de no cumplir con 10s objetivos de calidad.
ra un programa de medida exacto era necesario que Un proceso para el anilisis de 10s datos del segundo
tuviera constancia de tres componentes: paso, con el fin de poder hacer sugerencias para una
1. Un proceso donde pudieran articularse metas u obje- mayor mejora. Este proceso implicaria el analizar
tivos para sus proyectos. 10s problemas ya en la etapa de recolecci6n de datos,
problemas en la implementaci6n de las directivas de
2. Un proceso donde estas metas pudieran ser traducidas
calidad y problemas en la interpretaci6n de 10s datos.
a 10s datos del proyecto que exactamente reflejasen
dichas metas u objetivos en tkrminos de software. Basili [BAS961 ha proporcionado una serie de plan-
3. Un proceso que interpretara 10s datos del proyecto tillas que son dtiles para 10s desarrolladores que deseen
con el fin de entender 10s objetivos. utilizar el mCtodo OPM para desarrollar metricas rea-
listas sobre sus proyectos. Los objetivos de OPM pue-
Un ejemplo de un objetivo tipico que bien podria ser
den articularse por medio de tres plantillas que cubren
adoptado por una empresa es que la cantidad de trabajo
el prop6sit0, la perspectiva y el entorno.
de revisi6n sobre un diseiio de sistema debido a pro-
La plantilla o esquema de cilculo denominada de
blemas que fueran descubiertos por 10s programadores
prop6sito se utiliza para articular o comparar lo que esth
se redujera a1 80 por ciento.
siendo analizado y el prop6sito de dicha parte del pro-
A partir de este ejemplo de objetivo emerge un cier-
yecto. Por ejemplo, un disefiador puede desear analizar
to nlimero de preguntas tipicas cuya contestaci6n podria
la efectividad de las revisiones de disefio con el prop6-
ser necesaria para clarificar 10s objetivos y por consi-
sito de mejorar la tasa de eliminaci6n de errores de dicho
guiente el desarrollo de una mCtrica. Un conjunto de
proceso o el propio disefiador puede desear analizar las
ejemplos de estas preguntas, se exponen a continuaci6n:
normas utilizadas por su empresa con el objetivo de
iC6m0 realizar la cuantificaci6n de 10s trabajos de reducir la cantidad de mano de obra utilizada durante
revisibn? el mantenimiento. Una segunda plantilla esti relacio-
~Deberiaser tenido en cuenta el tamaiio del producto nada con la perspectiva. Esta plantilla pone su atenci6n "
en el cilculo de la disminuci6n de trabajos de revi- en 10s factores que son importantes dentro del propio
si6n o revisiones? proceso o producto que esti siendo evaluado. Ejemplos
Deberia ser tenido en cuenta el increment0 de mano tipicos de esto incluyen 10s factores de calidad de la
de obra de programaci6n requerida para validaciones mantenibilidad, chequeo, uso y otros factores tales como
suplementarias y trabajos de redisefio en comparaci6n el coste y la correcci6n. Esta plantilla se fundamenta en
con el proceso actual de validar un disefio comente. la perspectiva del propio proceso a1 que se dirige.
Hay varios enfoques que pueden hacerse sobre el pro- teca de software reutilizable. En este estudio se da el soft-
ceso de desarrollo de software - e l del cliente y el del ware de nuestra 5rea de aplicaci6n principal; que es l a d e
control de inventarios.
diseiiador son 10s dos mis tipicos- y la eleccidn de una
u otra perspectiva tiene un efecto muy grande sobre 10s Aqui, el prop6sito es la mejora de un esthdar de pro-
anilisis que se llevan a cabo. Por ejemplo, si un cierto gramacion; la perspectiva es la de la reutilizaci6n bajo
proceso como una revisi6n de requisitos estA siendo ana- el punto de vista del personal encargado de la adminis-
lizada con respecto a1 coste, la perspectiva del diseiiador, traci6n de una biblioteca de software reutilizable, y el
es la del que desea reducir el coste del proceso en tCrmi- entorno son todos aquellos proyectos que impliquen
nos de hacerlo mis eficiente en cuanto a la deteccibn de funciones de control de inventarios.
errores; sin embargo, si despuCs examinamos el mismo Otro ejemplo adicional es el siguiente:
prop6sito pero desde el punto de vista del cliente, con- Deseamos examinar el efecto de utilizar un constructor de
cretamente sobre si su personal puede emplear o no una interfaces grificas, sobre la mejora de las interfaces hombre-
gran cantidad de tiempo en dichas revisiones, entonces miquina, que producimos para nuestros sistemas de adminis-
la perspectiva podria involucrar el plantearse un uso mis traci6n. En particular, deseamos examinar c6mo puede esto
afectar a la facilidad de maneio de estas interfaces por park del
eficiente de dicho tiempo empleado en las revisiones. usuario. Un foco de atencioi principal es c6mo Grcibir5n 10s
Ambas perspectivas son validas -a veces se solapan y usuarios de estos sistemas que dichas interfaces han cambiado.
a veces son antidticas- existe, por ejemplo, una nece-
sidad natural en el diseiiador de maximizar el beneficio Aqui, el prop6sito es analizar una herramienta con
a la vez que el objetivo del cliente es la correcci6n m h i - el objetivo de determinar una mejora con respecto a la
ma del producto y la entrega dentro del plazo. Un punto facilidad de uso, bajo el punto de vista del usuario den-
importante a recalcar es que del examen de la perspecti- tro del context0 de 10s sistemas administrativos. Un
va del producto, el desarrollador esta en una mejor posi- ejemplo final es el siguiente:
ci6n para evaluar un proceso de software y un producto Nuestro objetivo es examinar el proceso de chequeo de
modulos de codigo de forma que podamos utilizar 10s resulta-
de software y tambiCn la mejora de 10s mismos.
dos de las comprobaciones con el fin de predecir el numero de
Una tercera plantilla implica el entomo. Este es el con- defectos de c6digo
- en comprobaciones futuras. La -perspecti--
texto dentro del cual el mCtodo OPM se aplica e implica va que deseamos tener surge de una preocupacion sobre el exce-
el examen del personal, la propia empresa y 10s entornos so de errores que se han cometido y que no han sido detectados
de recursos en 10s que el anhlisis se estA llevando a cabo. hasta el chequeo del sistema. Deseamos ver quC factores son
Factores tipicos de entomo incluyen, por ejemplo, el tipo importantes que permitan que un programad& tome decisie
de sistema informatico que esti siendo usado, las habili- - a 10s
nes sobre si un m d u l o estii disponible para ser entregado
probadores del sistema, o por el contrario requiere una com-
dades del personal implicado en el proyecto, el modelo probation adicional. Deseamos concentramosen nuestro mode-
de ciclo de vida adoptado para tal caso, la cantidad de lo de ciclo de vida actual con programadores que utilizan el
recursos adiestrados disponibles y el irea de aplicaci6n. lenguaje de programacion FORTRAN.
Una vez que tanto el prop6sito como la perspectiva Aqui, el objetivo es la prediccibn, el anilisis de un
y el entomo de un objetivo han sido bien especificados, proceso - e l de chequeo de c6dig- la perspectiva es
el proceso de planteamiento de cuestiones y el desarro- la de reduccidn de costes a travCs de una reduccidn del
110 de una mCtrica o valoraci6n puede comenzar. Antes n6mero de errores residuales, que se deslizan dentro del
de examinar este proceso, merece la pena dar algunos propio chequeo del sistema. La perspectiva es desde el
ejemplos de objetivos empleados en 10s tCrminos plan- punto de vista del programador y el entomo el de 10s
teados. El primer0 se describe a continuaci6n: proyectos convencionales que utilizan el lenguaje de
El objetivo es analizar 10s medios por 10s que revisamos programaci6n FORTRAN.
el c6digo de programacion con el proposito de evaluar la La plantilla prop6sito se utiliza para definir lo que
efectividad en la detection de errores desde el punto de vis- esti siendo estudiado: podria ser un proceso, un pro-
ta del gestor del proyecto de software dentro de 10s proyec-
tos que suministran programas cnticos bajo el punto de vista
d u c t ~un
, estindar o un procedimiento. La plantilla tam-
de la seguridad. biCn define lo que se va a hacer, y la raz6n de hacerlo.
La perspectiva tiene el objetivo de asegurar que 10s obje-
En el ejemplo planteado, el prop6sito es la evalua- tivos no son demasiado ambiciosos: a1 final del dia el
ci6n, la perspectiva es la eliminaci6n de defectos bajo mCtodo OPM requeriri la realizacidn de medidas y estas
el punto de vista del gestor de proyectos dentro del medidas y 10s datos estadisticos asociados serin s610
entomo de aplicaciones en 10s que la seguridad es un efectivos cuanto mis grande sea el n6mero de factores
aspect0 critico. Otro ejemplo es: dentro de un nivel razonable. La plantilla del entomo
Nosotros deseamos examinar la efectividad de las nor- tiene una funci6n similar: reduce el factor de espacio y
mas de programacion que usamos para el lenguaje de pro- permite que Sean hechas comparaciones estadisticas
gramacion C++, con el fin de determinar si son efectivos en
la production de software, que pueda ser reutilizado dentro
efectivas entre procesos y productos.
de otros proyectos. En particular, estamos interesados en lo Con el fin de terminar esta secci6n es provechoso
que se necesita con el fin de organizar efectivamente un depar- analizar el mCtodo OPM en accidn sobre un pequeiio
tamento nuevo encargado de el mantenimiento de una biblio- ejemplo, con el siguiente objetivo de proceso:
CAP~TULO
4 P R O C E S O DEL SOFTWARE Y METRICAS DEL P R O Y E C T O
Analicese el proceso de confection de prototipos con el pre una complejidad ponderada Ci . Entonces el tamaiio de
p6sito de evaluar desde el punto de vista del desarrollador, el 10s requisitos totales sera:
numero de requisitos que se rechazan por el cliente en m a ulti-
n
ma etapa del proyecto.
CRi.Ci
Nosotros asumiremos un modelo desechable de con- i=O
fecci6n de prototipos en el que se use una tecnologia Supongamos que una cierta proporci6n p de estos
como la de un lenguaje tipico de cuarta generaci6n para requisitos han sido puestos en cuesti6n emprendikndo-
desarrollar una version rapida de un sistema que, cuan- se un chequeo de aceptacion por parte del cliente, y que
do el cliente lo ha aceptado, se implemente de forma estos requisitos no han sido debidos a cambios en las
convencional con la eliminaci6n del propio prototipo. propias circunstancias del cliente. Entonces, la mCtrica
Esto plantea un cierto n6mero de preguntas que enton- n
ces pueden ser procesadas con el fin de evaluar el pro- e=p-CRi.Ci
ceso de confecci6n de prototipos desechables: i=O
~QuC medida tomarhmos con 10s requerimientos que representa una cierta medida de la desviaci6n de 10s
se hayan cambiado durante la parte convencional del requisitos desde el prototipo a lo largo del chequeo de
proyecto? aceptaci6n.
$e deben ponderar todos 10s requisitos de forma Este valor puede entonces ser comparado con 10s
igualitaria o son algunos mas complejos que otros? valores base de otros proyectos de confecci6n de pro-
~QuC tipos de carnbios en 10s requisitos debemos con- totipos que tengan un entorno parecido. Si se ha obser-
s i d e r ~ DespuCs
? de todo, algunos de ellos s e h debi- vado una cierta mejora, la siguiente etapa es intentar
dos a imperfeccimes en el proceso de confecci6n de descubrir cdmo se ha logrado esta mejora, por ejemplo,
prototipos mientras que otros podn'an tener que ver en este proyecto el cliente puede haber enviado el mis-
con factores extraiios que pueden ser debidos a cam- mo representante para ayudar en las demostraciones del
bios en las propias circunstancias del cliente. prototipo y por consiguiente ha conseguido una con-
Con el fin de aplicar el mCtodo OPM, necesitamos sistencia mayor que faltaba en otros proyectos, o el per-
un modelo del proceso que estC llevandose a cab0 y un sonal del desarrollo que estaba implicado en el proyecto
modelo de la perspectiva de calidad: el n6mero de cam- puede haber estado formado por analistas en lugar de
bios en 10s requisitos que son exigidos por el cliente no disefiadores, y asi haber constituido una mas s6lida rela-
provienen generalmente de cambios en sus propias cir- cion con el cliente. Si se observaba un increment0 en la
cunstancias. mCtrica e, entonces un analisis similar deberia llevarse
Supongamos que el modelo para el proceso de con- a cab0 en tCrminos de lo que constituian 10s factores
fecci6n de prototipos desechables es: desfavorables que afectaban a1 proyecto.
1. Especificar 10s requisitos. Lo ya expuesto, entonces, ha sido un resumen esque-
matico del proceso OPM. Un punto importante a con-
2. Valorar cada requisito en importancia seglin tCrmi- siderar es que ya que existe un nlimero casi infinito de
nos del cliente. mCtricas que pueden usarse para caracterizar un pro-
3. Valorar cada requisito en tCrminos de la compleji- ducto de software y un proceso de software existe una
dad de su descripci6n. necesidad de determinar la forma de seleccionarlas, o
4. Planificar una serie de reuniones de revisi6n en las que dicho de otra forma, cual de las OPM es el mejor ejem-
se presente a travCs de un prototipo una cierta selec- plo. Una vez que esto ha sido tomado en consideracion
ci6n de requisitos donde el gestor del proyecto tome en una empresa, esa empresa puede entonces implicar-
una decisi6n sobre en quC se basa la selecci6n de una se en una actividad continua de mejora de procesos, que
presentaci6n de, por ejemplo, dos horas de duraci6n. la coloque en un nivel4 6 5 de la Escala de Modelos de
Supongamos un modelo muy simple de perspectiva Madurez de Capacidades y asi distinguirla de aquellas
de calidad, donde cada requisito Ri estC asociado con otras que lleguen s610 a niveles 1 6 2.
Debido a que el proceso de software y el product0 que to no sera la misma que otras metricas similares selec-
tal proceso produce son ambos influenciados por cionadas para otro proyecto. En efecto, hay a menudo
muchos parametros (por ejemplo: el nivel de habili- variaciones significativas en las mCtricas elegidas como
dad de 10s realizadores de dichos procesos, la estruc- parte del proceso de software.
tura del equipo de software, el conocimiento del Puesto que la misma m6trica de procesos variari de un
cliente, la tecnologia que va a ser implementada, las proyecto a otro proyecto, jc6m0 podemos decir si unos
herramientas que seran usadas en la actividad de desa- valores de metricas mejoradas (o degradadas) que ocu-
rrollo), la mCtrica elegida para un proyecto o produc- rren como consecuencia de actividades de mejora e s t h
de hecho teniendo un impact0 cuantitativo real? iC6mo Calcular 10s rangos m6viles: el valor absoluto de las
.sabersi lo que nosotros estarnos contemplandoes una ten- diferencias sucesivas entre cada pareja de puntos de
dencia estadlsticamente valida o si esta <<tendencia>> es datos... Dibujar estos rangos m6viles sobre el grifico.
simplementeel resultado de un ruido estadistico? i C u h - Calcular la media de 10s rangos mbviles... dibujando
do son significativos 10s cambios (ya sean positivos o Csta (ccbarra Rm)>)como la linea central del propio
negativos) de una mCtrica de software particular? grafico.
Multiplicar la media por 3.268. Dibujar esta linea
como el limite de control superior [LCS]. Esta linea
supone tres veces el valor de la desviaci6n estindar
por encima de la media.
Usando 10s datos representados en la figura 4.8 y 10s
distintos pasos sugerihos por Zultner como anteiior-
mente se ha descrito, desarrollamos un grafico de con-
trol Rm que se muestra en la Figura 4.9. El valor (medio)
Se dispone de una tCcnica grafica para determinar si ccbarra Rm>>para 10s datos de rango m6vil es 1.71. El
10s cambios y la variaci6n en 10s datos de la mCtrica son limite de control superior (LCS) es 5.57.
significativos. Esta ttcnica llamada grafico de control
y desarrollada por Walter Shewart en 19201°, permite
que 10s individuos o las personas interesadas en la mejo-
ra de procesos de software determine si la dispersion
(variabilidad) y <<lalocalizaci6n>>(media m6vil) o mttri-
ca de procesos que es estable (esto es, si el proceso exhi-
be cambios controlados o simplemente naturales) o
inestable (esto es, si el proceso exhibe cambios fuera Para determinar si la dispersion de las mCtricas del
de control y las mCtricas no pueden usarse para prede- proceso es estable puede preguntarse una cuestidn muy
cir el rendimiento). Dos tipos diferentes de grificos de sencilla: iEst6n 10s valores de rango m6vil dentro del
control se usan en la evaluaci6n de 10s datos mCtricos LCS? Para el ejemplo descrito anteriormente, la con-
[ZUL99]: (1) el grafico de control de rango m6vil (Rm) testacion es <&>. Por consiguiente, la dispersi6n de la
y (2) el grafico de control individual. mCtrica es estable.
Para ilustrar el enfoque que significa un grhfico de El grafico de control individual se desarrolla de la
control, consideremos una organizaci6n de software que manera siguientel':
registre en la mCtrica del proceso 10s errores descubiertos 1. Dibujar 10s valores de la mCtrica individual segun se
por hora de revisidn, Er. Durante 10s pasados 15 meses, describe en la Figura 4.8.
la organizaci6n ha registrado el Er para 20 pequefios
proyectos en el mismo dominio de desarrollo de soft- 2. Calcular el valor promedio, A,, para 10s valores de
ware general. Los valores resultantes para E, e s t h repre- la mCtrica.
sentados en la figura 4.8. Si nos referimos a la figura, 3. Multiplicar la media de 10s valores Rm (la barra Rm)
Er varia desde una tasa baja de 1.2 para el proyecto 3 a por 2.660 y aiiadir el valor de A, calculado en el paso
una tasa mas alta de 5.9 para el proyecto 17. En un 2. Esto da lugar a lo que se denomina limite de pro-
esfuerzo de mejorar la efectividad de las revisiones, la ceso natural superior (LPNS). Dibujar el LPNS.
organizaci6n de software proporcionaba entrenamien- 4. Multiplicar la media de 10s valores Rm (la barra Rm)
to y asesoramiento a todos 10s miembros del equipo del por 2.660 y restar este valor del A, calculado en el
proyecto, comenzando con el proyecto 1 1. paso 2. Este cilculo da lugar a1 limite de proceso
natural inferior (LPNI). Dibujar el LPNI. Si el LPNI
es menor que 0.0, no necesita ser dibujado a menos
iComo podemos estar que la mCtrica que esti siendo evaluada tome valo-
seguros de que las metricas res que sean menores que 0.0.
que hernos recopilado son 5. Calcular la desviaci6n estindar segun la f6rmula
estadisticamente validas? (LPNS - Am)/3. Dibujar las lineas de la desviaci6n
estindar una y dos por encima y por debajo de A,.
Richard Zultner proporciona una vista general del Si cualquiera de las lineas de desviaci6n estindar es
procedimiento que se requiere para desarrollar un gra- menor de 0.0, no necesita ser dibujada a menos que
jico de control de rango m6vil (Rm) para determinar la la mCtrica que esta siendo evaluada tome valores que
estabilidad del proceso [ZUL99]: sean menores que 0.0.
l a Deberia tenerse en cuenta que aunque el grafico de control fue

desarrollado originalmente para procesos de fabricacion es igual- " El estudio que sigue es un resumen de 10s pasos sugeridos por Zult-
mente aplicable a procesos de software. ner [ZUL99].
CAPtTULO 4 P R O C E S O DEL S O F T W A R E Y M t T R I C A S DEL P R O Y E C T O
fa-
:. -:..........................................
............. ..................... ., I
FIGURA 4.8. Datos de metricas para descubrir errores FIGURA 4.9. Grafico de control de rango movil (Rm).
por hora de revision.
Aplicando estos pasos a 10s datos representados en

la Figura 4.8, se llega a un grafrco cle control indivirlual
seglin se ve en la tigura 4.10.
Referencia Web 3
Se puede encontror un Grbfico de Control Comlin
que cubre el tema en olguno dimensibn en: Proyectos
www.sytsma.com/tqmtools/ctlthfprinciples.html FIGURA 4.10. Grafico de control individual.
Zultner [ZUL99] revisa cuatro criterios, denomi-

s zonu, clue pueden usarse para evaluar
naclos r e ~ l a cle Puesto que todas estas condiciones fallan para 10s
si 10s cambios representados por la ~nCtricaindican valores mostrados para la figura 4.10, se concluye que
que un proceso estB bajo control o fuera de control. 10s datos de ias mCtricas se derivan de un proceso esta-
Si cualquiera de las siguientes condiciones es verda- ble y que se pueden deducir legitimamente a partir de
dera, 10s datos de la mCtrica indican un proceso que 10s datos recogidos en la mCtrica una informaci6n que
est5 fuera de control: constituye una verdadera tendencia. Si nos referimos
a la figura 4.10, puede verse que la variabilidad de E,
Un valor de la mCtrica individual aparece fuera del decrece a partir del proyecto 10 (esto es, despuCs de
LPNs. un esfuerzo para mejorar la efectividad de las revisio-
Dos de cada tres valores de mktricas sucesivas apa- nes). Calculando el valor medio para 10s 10 primeros
recen mhs de dos desviaciones esthndar fuera del y 10s 10 liltimos proyectos, puede demostrarse que el
valor A,. valor medio de Er para 10s proyectos del 11 a1 20,
Cuatro de cada cinco valores de mCtricas sucesivas muestran un 29 por 100 de mejora en relaci6n con la
aparecen alejados mAs de una desviaci6n esthndar E, de 10s proyectos 1 a1 10. Puesto que el grhfico de
del valor A,. control indica que el proceso es estable, parece que 10s
Ocho valores consecutivos de mCtrica aparecen todos esfuerzos para mejorar la efectividad de la revision
situados a un lado del valor A,. dan sus resultados.
La amplia mayoria de las organizaciones de desarrollo [KAU99] describe un escenario tipico que ocurre cuan-
de software tienen menos de 20 personas dedicadas a1 do se piensa en programas mCtricos para organizacio-
software. Es poco razonable, y en la mayoria de 10s casos nes pequefias de software:
no es realists, esperar que organizaciones como Cstas Originalrnente,10s desarrolladoresde software acog'an nues-
desarrollen programas mCtricos de software extensos. tras actividades con un alto grado de escepticisrno,pero al final
Sin embargo, si que es razonable sugerir que organiza- las aceptaban debido a que nosotros conseguiamos que nues-
ciones de software de todos 10s tamafios midan y des- tras rnedidas fueran simples de realizar, adaptadas a cada orga-
nizacibn y se aseguraba que dichas rnedidas producian una
puCs utilicen las mCtricas resultantes para ayudar a infomaci6n vilida y litil. Al final, 10s programas proporcio-
mejorar sus procesos de software local y la calidad y naban una base para encargarse de 10s clientes y para la plani-
oportunidad de 10s productos que realizan. Kautz ficacibn y desarrollo de su trabajo futuro.
Defectos descubiertos despuCs de que el carnbio se
haya desviado a la base del cliente, Dcambio.
Si estbs empezando a reuni mt%icas del s o h r e ,
recuerda guardarlos.Si te entierras con datos, iu esfuerzo ~Comopuedo derivar
con 10s metricas puede follar. un conjunto <simple))
de metricas del software?
Lo que Kautz sugiere es una aproximacion para la
implementaci6n de cualquier actividad relacionada con
el proceso del software: que sea simple; adaptada a satis- Una vez que estas medidas han sido recogidas para
facer las necesidades locales y que se constate que real- un cierto numero de peticiones de cambio, es posible cal-
mente &da valor. En 10s phafos siguientes examinamos cular el tiempo total transcurrido desde la peticion de
c6mo se relacionan estas lineas generales con las mCtri- carnbio hasta la implernentacion de dicho carnbio y el
cas utilizadas para negocios pequefios. porcentaje de tiempo consumido por el proceso de colas
<<Parahacerlo fhcib, es una linea de accion que iniciales, la asignaci6n de cambio y evaluacion, y la irnple-
funciona razonablemente bien en muchas actividades. mentaci6n del cambio propiamente dicho. De forma sirni-
Pero jc6m0 deducimos un conjunto sencillo de mCtri- lar, el porcentaje de esfuerzo requerido para la evaluaci6n
cas de software que proporcionen valor, y c6mo pode- y la implementaci6n puede tambiCn ser determinado.
mos estar seguros de que estas mCtricas sencillas Estas mktricas pueden ser evaluadas en el context0 de 10s
lograran satisfacer las necesidades de una organiza- datos de calidad, Ec,rnpioy D carnbio. Los porcentajes pro-
cion de software particular? Comenzamos sin cen- porcionan un anhlisis intemo para buscar el lugar donde
trarnos en la medicion, per0 si en 10s resultados 10s procesos de peticion de carnbio se ralentizan y pue-
finales. El grupo de software es interrogado para que den conducir a unos pasos de mejoras de proceso para
defina un objetivo simple que requiera mejora. Por reducir tco!, r.teml. ;Micamhior yI0 Ecarnbio. Adem's?
ejemplo, ccreducir el tiempo para evaluar e imple- la eficiencia de elimination de defectos (EED) puede ser
mentar las peticiones de cambia>>. Una organizacion calculada de la siguiente manera:
pequefia puede seleccionar el siguiente conjunto de
medidas fhcilmente recolectables:
'
EED = Ecambio (Ecarnbio+Dcarnbio)
EED puede compararse con el tiempo transcurrido y el
Tiempo (horas o dias) que transcurren desde el
esfuerzo total para determinar el impact0 de las activi-
momento que es realizada una petici6n hasta que se
dades de aseguramiento de la calidad sobre el tiempo y
complete su evaluacion, tcola.
el esfuerzo requeridos para realizar un cambio.
Esfuerzo (horas-persona) para desarrollar la evalua- Para grupos pequefios, el coste de incorporar medi-
cion, We,,,. das y mCtricas de chlculo oscila entre el 3 y el 8 por 100
Tiempo (horas o dias) transcurridos desde la termi- del presupuesto del proyecto durante la fase de apren-
naci6n de la evaluaci6n a la asignacion de una orden dizaje y despuCs cae a menos del 1 por 100 del presu-
de carnbio a1 personal, teval. puesto del proyecto una vez que la ingenieria del
Esfuerzo (horas-persona) requeridas para realizar el software y la gestion de proyectos se hayan familiari-
carnbio, Wcambio. zado con el programa de mCtricas [GRA99]. Estos cos-
Tiempo requerido (horas o dias) para realizar el cam- tes pueden representar una mejora de las inversiones
bio, tCrnbi,. siempre que el anhlisis derivado a partir de 10s datos de
Errores descubiertos durante el trabajo para realizar la mCtrica conduzcan a una mejora de procesos signifi-
el carnbio, Ecambio. cativa para la organizaci6n del software.
El Instituto de Ingenieria del Software (11s) ha desarro- 6. Identificar preguntas que puedan cuantificarse y 10s
llado una guia extensa [PAR961 para establecer un pro- indicadores relacionados que se van a usar para
grama de medici6n de software dirigido hacia objetivos. ayudar a conseguir 10s objetivos de medicion.
La guia sugiere 10s siguientes pasos para trabajar: 7. Identificar 10s elementos de datos que se van a reco-
1. Identificar 10s objetivos del negocio. ger para construir 10s indicadores que ayuden a res-
2. Identificar lo que se desea saber o aprender. ponder a las preguntas planteadas.
8. Definir las medidas a usar y hacer que estas defi-
3. Identificar 10s subobjetivos. niciones Sean operativas.
4. Identificar las entidades y atributos relativos a esos 9. Identificar las acciones que serhn tomadas para
subobjetivos. mejorar las medidas indicadas.
5. Formalizar 10s objetivos de la medicion. 10. Preparar un plan para implementar estas medidas.
CAPfTULO 4 P R O C E S O DEL SOFTWARE Y M e T R I C A S DEL PROYECTO
nizaci6n de software Sean anotadas convenientemente.
3
Referencia Web
Se puede descorgor una guio para lo medicibn del software
orientodo o obietivos desde: www.sei.cmu.edu
Ejemplo de tales entidades incluye: recursos de desarro-
110, productos de trabajo, codigo fuente, casos de prueba,
peticiones de cambio, tareas de ingenieria de software y
planificaciones. Para cada entidad listada, el personal dedi-
cad0 al software desarrolla una sene de preguntas que eva-
Si se quiere entrar en una discusi6n rnis profunda de 16an las caracteristicas cuantitativas de la entidad (por
10s pasos anteriores, lo mejor es acudir directamente a ejemplo: tamafio, coste, tiempo para desarrollarlo). Las
la guia ya comentada del IIS (SEI) Instituto de Inge- cuestiones derivadas como una consecuencia de la crea-
nieria del Softwate. Sin embargo, merece la pena repa- ci6n de una lista tal de preguntas-entidad, conducen a la
sar brevemente 10s puntos clave de Csta. derivacih de un conjunto de objetivos de segundo nivel
Ya que el software, en primer lugar, soporta las fun- (subobjetivos) que se relacionan directarnente con las enti-
ciones del negocio, en segundo lugar, diferencia o clasi- dades creadas y las actividades desarrolladas como una
fica 10s sistemas o productos basados en computadora, y parte del proceso del software.
en tercer lugar puede actuar como un producto en si mis- ConsidCrese el cuarto objetivo apuntado antes:
mo, 10s objetivos definidos para el propio negocio pue- {~Hacer que el soporte para nuestros productos sea rnis
den casi siempre ser seguidos de arriba abajo hasta 10s ficih. La siguiente lista de preguntas pueden ser deri-
objetivos rnis especificos a nivel de ingenieria de soft- vadas a partir de este objetivo [PAR96]:
ware. Por ejemplo, considCrese una compaiiia que fabri- icontienen las preguntas de cambio del cliente la
ca sistemas avanzados para la seguridad del hogar que informaci6n que nosotros requerimos para evaluar
tienen un contenido de software sustancial. Trabajando adecuadamente el cambio y de esa forma realizarle
como un equipo, 10s ingenieros de software y 10s gesto- en un tiempo y formas oportunos?
res del negocio, pueden desarrollar una lista de objetivos iC6mo es de grande el registro de peticiones de
del propio negocio convenientemente priorizados: cambio?
1. Mejorar la satisfacci6n de nuestro cliente con nues- jEs aceptable nuestm tiempo de respuesta para localizar
tros productos. errores de acuerdo a las necesidades del cliente?
2. Hacer que nuestros productos Sean rnis ficiles de usar. i S e sigue convenientemente nuestro proceso de
3. Reducir el tiempo que nos lleva sacar un nuevo control de cambios (Capitulo 9)?
producto a1 mercado. iSe llevan a cab0 10s cambios de alta prioridad de
4. Hacer que el soporte que se dC a nuestros produc- manera oportuna y sincronizada?
tos sea mis ficil. Basindose en estas cuestiones, la organizaci6n de
5. Mejorar nuestro beneficio global. software puede deducir 10s objetivos de segundo nivel
(subobjetivos) siguientes: Mejorar el rendimiento del
proceso de gesti6n del cambio. Las entidades de proceso
de software y atributos que son relevantes para 10s
10s metricas del software que elijos estorbn conducidos prop6sitos u objetivos rnis especificos o de segundo
por el negocio o por 10s obietivos tkcnicos que desees nivel son identificados y se definen ademis las metas u
cumplir. objetivos de medida asociados con dichos atributos.
El IIS [PAR961 proporciona una guia detallada para
La organizaci6n de software examina cada objetivo de 10s pasos 6 a1 10 de este enfoque de medida orienta-
negocios y se pregunta: qQuC actividades gestionaremos do hacia objetivos. En esencia, se aplica un proceso
(ejecutaremos) y quC queremos mejorar con estas activi- de refinamiento por pasos en el que 10s objetivos son
dades?u Para responder a estas preguntas el IIS recornienda refinados en preguntas que son a su vez refinadas de
la creaci6n de una dista de preguntas-entidadu, en la que forma rnis detallada en entidades y atributos que por
todas las cosas (entidades) dentro del proceso de softwa- ultimo se analizan en un 6ltimo paso de forma rnis
re que Sean gestionadas o estCn influenciadas por la orga- minuciosa a nivel de la mCtrica en si.
La medici6n permite que gestores y desarrolladores to se utilizan para calcular las metricas del softwa-
mejoren el proceso del software, ayuden en la pla- re. Estas metricas se pueden analizar para propor-
nificaci61-1, seguimiento y control de un proyecto de cionar indicadores que guian acciones de gesti6n y
software, y evaluen la calidad del producto (soft- tCcnicas.
ware) que se produce. Las medidas de 10s atributos Las mCtricas del proceso permiten que una orga-
especificos del proceso, del proyecto y del produc- nizaci6n tome una visi6n estratCgica proporcionan-
do mayor profundidad de la efectividad de un proce- ireas de proceso del software que son la causa de 10s
so de software. Las mCtricas del proyecto son ticti- defectos del software.
cas. Estas permiten que un gestor de proyectos adapte Las metricas tienen significado solo si han sido
el enfoque a flujos de trabajo del proyecto y a pro- examinadas para una validez estadistica. El grifico
yectos t6cnicos en tiempo real. de control es un mCtodo sencillo para realizar esto y
Las metricas orientadas tanto a1 tamaiio como a la a1 mismo tiempo examinar la variaci6n y la localiza-
funci6n se utilizan en toda la industria. Las metricas ci6n de 10s resultados de las mktricas.
orientadas a1 tamafio hacen uso de la linea de c6digo La medici6n produce cambios culturales. La reco-
como factor de normalizaci6n para otras medidas, pilaci6n de datos, el cilculo de metricas y la evaluaci6n
como persona-mes o defectos. El punto de funci6n de metricas son 10s tres pasos que deben implementar-
proviene de las medidas del dominio de informaci6n se a1 comenzar un programa de metricas. En general,
y de una evaluaci6n subjetiva de la complejidad del un enfoque orientado a 10s objetivos ayuda a una orga-
problema. nizaci6n a centrarse en las metricas adecuadas para su
Las metricas de la calidad del software, como negocio. Los ingenieros del software y sus gestores pue-
metricas de productividad, se centran en el proceso, den obtener una visidn m8s profunda del trabajo que
en el proyecto y en el producto. Desarrollando y ana- realizan y del producto que elaboran creando una linea
lizando una linea base de metricas de calidad, una base de metricas -una base de datos que contenga
organizaci6n puede actuar con objeto de corregir esas mediciones del proceso y del product-.
[ALA97] Alain, A., M. Maya, J. M. Deshamais y S. St. Pie- [IEE93] IEEE Software Engineering Standards, Std. 6 10.12-
rre, <<AdaptingFunction Points to Real-Time Software,,, 1990, pp. 47-48.
American Programmer, vol. 10, n." 11, Noviembre 1997,
pp. 32-43. [IFF941 Function Point Counting Practices Manual, Release
4.0, International Function Point Users Group (IFPUG), 1994.
[ART851Arthur, L. J., Measuring Programmer Productivity
and Software Quality, Wiley-Interscience, 1985.
[JON861 Jones, C., Programming Productivity, McGraw-Hill,
1986.
[ALB79] Albrecht, A. J., <<MeasuringApplication Develop-
[JON911 Jones, C., Applied Software Costs, McGraw-Hill,
ment Productivity,>,Proc. IBM Application Development
1991.
Symposium, Monterey, CA, Octubre 1979, pp. 83-92.
[JON981 Jones, C., Estimating Software Costs, McGraw-Hill,
[ALB83] Albretch, A. J., y J. E. Gaffney, <<SoftwareFunc- 1998.
tion, Source Lines of Code and Development ~ f f o rPre-
t
diction: A Software Science Validation>>,IEEE Trans. [KAU99] Kautz, K., <<MakingSense of Measurement for Small
Software Engineering, Noviembre 1983, pp. 639-648. Organizations,, IEEE Software, Marzo 1999, pp. 14-20.
[BOE8 I ] Boehm, B., Software Engineering Economics, Pren- [MCC78] McCall, J. A., y J. P. Cavano, <<AFramework for
tice Hall, 1981. the Measurement of Software Quality,, ACM Software
Quality Assurance Workshop, Noviembre 1978.
[GRA87] Grady, R.B., y D.L. Caswell, Software Metrics: Esta-
blishing a Company-Wide Program, Prentice-Hall, 1987. [PAU94] Paulish, D., y A. Carleton, <<CaseStudies of Soft-
ware Process Improvement Measurement,,, Computer, vol.
[GRA92] Grady, R.G., Practical Software Metrics for Pro- 27, n.' 9, Septiembre 1994, pp. 50-57.
ject Management and Process Improvement, Prentice-Hall,
1992. [PAR961 Park, R. E., W. B. Goethert y W. A. Florac, Goal
Driven Software Measurement-A Guidebook, CMU/SEI-
[GRA94] Grady, R., ccSuccesfully Applying Software 96-BH-002, Software Engineering Institute, Camegie
Metricw, Computer, vol. 27, n.' 9, Septiembre 1994, pp. Mellon University, Agosto 1996.
18-25.
[RAG951 Ragland, B., <<Measure, Metric or Indicator: What's
[GRA99] Grable, R., et al., c<Metricsfor Small Projects: Expe- the Difference?,,, Crosstalk, vol. 8, n.' 3, Marzo 1995,
riences at SEDB,IEEE Software, Marzo 1999, pp. 21-29. pp. 29-30.
[GIL88] Gilb, T., Principles of Software Project Manage- [TAL81] Tjima, D., y T. Matsubara, <<TheComputer Software
ment, Addison-Wesley, 1998. Industry in Japan,,, Computer, Mayo 1981, p. 96.
[HET93] Hetzel, W., Making Software Measurement Work, [WH195] Whitmire, S. A., <<AnIntroduction to 3D Function
QED Publishing Group, 1993. Points>>,Software Development, Abril 1995, pp. 43-53.
[HUM951 Humphrey, W., A Discipline for Software Engi- [ZUL99] Zultner, R. E., aWhat Do Our Metrics Mean?*,
neering, Addison-Wesley, 1995. Cutter IT Journal, vol. 12, n.' 4, Abril 1999, pp. 11-19.
CAPfWLO 4 P R O C E S O DEL SOFTWARE Y METRICAS DEL PROYECTO
4.1. Sugiera tres medidas, tres mCtricas y 10s indicadores que Nlimero de archivos: 8
se podrian utilizar para evaluar un automovil. Numero de interfaces extemos: 2
4.2. Sugiera tres medidas, tres metricas y 10s indicadores Asuma que todos 10s valores de ajuste de complejidad e s h
correspondientes que se podrian utilizar para evaluar el en la media.
departamento de servicios de un concesionario de automo-
viles. 4.12. Calcule el valor del punto de funcion de un sistema empo-
trado con las caracteristicas siguientes:
4.3. Describa, con sus propias palabras, la diferencia entre
mCtricas del proceso y del proyecto. Estructuras de datos intema: 6
4.4. iPor quC las metricas del software deberian mantenerse
Estructuras de datos extema: 3
ccprivadas>>?Proporcione ejemplos de tres metricas que debie- Numero de entradas de usuario: 12
ran ser privadas. Proporcione ejemplos de tres metricas que Numero de salidas de usuario: 60
debieran ser publicas. Numero de peticiones de usuario: 9
4.5. Obtenga una copia de [HUM951 y escriba un resumen en Nlimero de interfaces extemos: 3
una o dos piginas que esquematice el enfoque PSP. Transformaciones: 36
Transiciones: 24
4.6. Grady sugiere una etiqueta para las metricas del soft-
ware. ~ P u e d eafiadir m i s reglas a las sefialadas en la Sec- Asuma que la complejidad de las cuentas anteriores se divi-
ci6n 4.2. I? de de igual manera entre bajo, medio y alto.
4.7. Intente completar el diagrarna en espina de la Figura 4.3. 4.13. El software utilizado para controlar una fotocopiadora
Esto es, siguiendo el enfoque utilizado para especificaciones avanzada requiere 32.000 lineas de C y 4.200 lineas de Small-
<<incorrectas>>,
proporcione informacion analoga para ccperdi- talk. Estime el numero de puntos de funci6n del software de
do, ambiguo y cambiow. la fotocopiadora.
4.8. L Q Ues
~ una medida indirecta y por quC son comunes tales 4.14. McCall y Cavano (Seccion 4.5.1) definen un ccmarco de
cambios en un trabajo de metricas de software? trabajon de la calidad del software. Con la utilization de la
informacion de este libro y de otros se amplian 10s tres ccpun-
4.9. El equipo A encontro 342 errores durante el proceso de tos de vista* importantes dentro del conjunto de factores y de
ingenieria del software antes de entregarlo. El equipo B encon- metricas de calidad.
tro 184 errores. i Q u t medidas adicionales se tendrian que
tomar para que 10s proyectos A y B determinen quC equipos 4.15. Desarrolle sus propias metricas (no utilice las presenta-
eliminaron 10s errores mis eficientemente?iQuCmCtricas pro- das en este capitulo) de correction, facilidad de mantenimiento,
pondrian para ayudar a tomar determinaciones? ~ Q u Cdatos integridad y facilidad de uso. Asegurese de que se pueden tra-
historicos podrian ser litiles? ducir en valores cuantitativos.
4.10. Presente un argument0 en contra de las lineas de c6di- 4.16. ~ E posible

s que 10s desperdicios aumenten mientras que
go como una medida de la productividad del software. iSe va disminuyen defectos/KLDC? Expliquelo.
a sostener su propuesta cuando se consideren docenas o cien- 4.17. ~ T i e n ealgun sentido la medida LDC cuando se utiliza
tos de proyectos? el lenguaje de cuarta generation? Expliquelo.
4.11. Calcule el valor del punto de funci6n de un proyecto con 4.18. Una organization de software tiene datos EED para 15
las siguientes caracteristicas del dominio de informacion: proyectos durante 10s 2 ultimos aiios. Los valores recogidos
son: 0.81,0.71,0.87,0.54,0.63,0.71,0.90,0.82,0.61,0.84,
Numero de entradas de usuario: 32
0.73,0.88,0.74,0.86,0.83. Cree Rm y cuadros de control indi-
Numero de salidas de usuario: 60 viduales para determinar si estos datos se pueden utilizar para
NCmero de peticiones de usuario: 24 evaluar tendencias.
La mejora del proceso del software (MPS) ha recibido una Garmus, D., y D. Herron, Measuring the Software Pro-
significativa atencion durante la pasada decada. Puesto que cess: A Practical Guide to Functional Measurements, Pren-
la medicion y las mCtricas del software son claves para con- tice-Hall, 1996.
seguir una mejora del proceso del software, muchos libros Kan, S. H., Metrics and Models in Software Quality Engi-
sobre MPS tambiCn tratan las mCtricas. Otras lecturas adi- neering, Addison-Wesley, 1995.
cionales que merecen la pena incluyen: Humphrey [HUM95], Yeh (Sofn~areProcess Control,
Burr, A., y M. Owen, Statistical Methosfor Software Qua- McGraw-Hill, 1993), Hetzel [HET93] y Grady [GRA92] estu-
lity, International Thomson Publishing, 1996. dim c6mo se pueden utilizar las metricas del software para pro-
Florac, W. A., y A. D. Carleton, Measuring the Software porcionar 10s indicadores necesarios que mejoren el proceso
Process: Statistical Process Control for Software Process . del software. Putnarn y Myers (ExecutiveBriefing: Controlling
Improvement, Addison-Wesley, 1999. Software Development, IEEE Computer Society, 1996) y Pul-
ford y sus colegas (A QuantitativeApproach to Sofhvare Mana- cas del software. Park y otros [PAR961 han desarrollado una
gement, Addison-Wesley, 1996) estudian las mCtricas del pro- guia detallada que proporciona paso a paso sugerencias para
ceso y su uso desde el punto de vista de la gesti6n. instituir un programa de las mCtricas del software para la
Weinberg (Quality Sofhvare Management, Volume 2: First mejora del proceso del software.
Order Measurement, Dorset House, 1993) presenta un mode- La hoja informativa lTMetrics (Editada por Howard Rubin
lo 6til para observar proyectos de software, asegurindose el y publicada por 10s Sewicios de Informaci6n Cutter) presen-
significado de la observaci6n y determinando el significado ta comentarios 6tiles sobre el estado de las mCtricas del soft-
de las decisiones tacticas y estratkgicas. Garmus y Herron ware en la industria. Las revistas Cutter IT Journal y Sofware
(Measuring the Software Process, Prentice-Hall, 1996) trata Development tienen habitualmente articulos y caracteristi-
las mktricas del proceso en el analisis del punto de funci6n. cas completas dedicadas a las mktricas del software.
El Software Productivity Consortium (The Sofhvare Measu- En Internet estan disponibles una gran variedad de fuen-
rement Guidebook, Thomson Computer Press, 1995) pro- tes de informaci6n relacionadas con temas del proceso del
porciona sugerencias 6tiles para instituir un enfoque efectivo software y de las mCtricas del software. Se puede encontrar
de mCtricas. Oman y Pfleeger (Applying Software Metrics, una lista actualizada con referencias a sitios (paginas) web
IEEE Computer Society Press, 1997) han editado una exce- que son relevantes para el proceso del Software y para las
lente antologia de documentos importantes sobre las mCtri- metricas del proyecto en http://www.pressman5.com.
&Qu6e ~ ?La planificacidn de un proyec- mas y prcductos basados en computa- &Cudes e8 producto obtenido? Se
to d e software realmente comprende dora cuestan considerablemente m&s obtiene una tabla que indica las tare-
todas las actividades tratadas en 10s que construir una casa grande, podria a s a desarrollar, las funciones a imple-
Capifulos 5 a1 9. Sin embargo, en el ser razanable descmollar y estimarantes mentar, y el coste, esfuerzo y tiempo
context0 de este capitulo, la planifica- de empezar a construir el software. necesario para la realizaci6n d e cada
ci6n implica la estimaci6n -su inten- una. T a m b i h s e obtiene una lista d e
#,CuL!es son 10s pasos? La estimaci6n
to por determinar cudnto dinero. recursos necesarios para el proyecto.
comienza con una descripci6n del
esfuerzo, recursos, y tiempo supondr6
6mbito del producto. Hasta que no s e kC6mo puedo eshr segura de que
construir un sistema o producto espe-
rdelimita. el dmbito no e s posible rea- lo he hecho eorrectamente? Esto
cifico de software--.
lizar una estimaci6n con sentido. El e s dificil, puesto que realmente no lo
&QuI&nlo hace? Los gestores del soft- problema e s entonces descompuesto sabrd hasta que el proyecto haya h a -
ware -utilizando la informaci6n soli- en un conjunto de problemas de menor lizado. Sin embargo, si tiene experien-
citada (I10s clientes y a 10s ingenleros tamafio y cada uno de Bstos s e estima cia y sigue un enfoque sistemdtico,
d e software g 10s datos de metricas de
cnftornra nlulnnirln. .-la nrnnartna nntn-
guidndose con datos hist6ricos y con
1 . . - C ... - .. ...*. ,...
realiza estimaciones utilizando datos
1 3 ..
problema se considera antes de reali-

zur una estimaci6n final.
A un destacado ejecutivo se le pregunt6 una vez por la
caracteristica mis .importante que debe tener un gestor
de proyectos. Respondi6: << ...una persona con la habi-
lidad de saber quC es lo que va a ir ma1 antes de que ocu-
l o complejidad del proyecto, el tomoiio del proyecto y el
rra...,, . Debemos afiadir: << ...y con el coraje para hacer grodo de incerh'dumbreestructurol afectan o lo fiabilidod
estimaciones cuando el futuro no esti claro...D. de lo estimocibn.
La estimaci6n de recursos, costes y planificaci6n tem-
poral de un esfuerzo en el desarrollo de software requie- El grado de incertidumbre estructural tiene tambiCn
re experiencia, acceder a una buena informacidn efecto en el riesgo de la estimaci6n. En este contexto,
hist6rica y el coraje de confiar en predicciones (medi- la estructura se refiere a1 grado en el que 10s requisitos
das) cuantitativas cuando todo lo que existe son datos se han definido, la facilidad con la que pueden subdi-
cualitativos. La estimaci6n conlleva un riesgo inheren- vidirse funciones, y la naturaleza jerkquica de la infor-
tel y es este riesgo el que lleva a la incertidumbre. maci6n que debe procesarse.
La disponibilidad de informaci6n hist6rica tiene una
fuerte influencia en el riesgo de la estimaci6n. A1 mirar
atris, podemos emular lo que se ha trabajado y mejorar
las keas en donde surgieron problemas. Cuando se dis-
pone de las mCtricas completas de software de proyectos
anteriores (Capitulo 4), se pueden hacer estimaciones con
mayor seguridad; establecer planificaciones para evitar
La complejidad del proyecto tiene un gran efecto en la dificultades anteriores, y asi reducir el riesgo global.
incertidumbre, que es inherente en la planificaci6n. Sin
embargo, la complejidad es una medida relativa que se ve
afectada por la familiaridad con esfuerzos anteriores. Se
podria considerar una aplicaci6n sofisticada de comercio
electr6nicocomo ccexcesivamente compleja>> para un desa-
rrollador que haya realizado su primera aplicaci6n. Sin
embargo para un equipo de software que desarrolle su
enCsimo sitio web de comercio electr6nico podria consi-
derarse ccsumamente f i c i b (una de tantas). Se han pro-
puesto una serie de medidas cuantitativas de la complejidad
del software (por ejemplo, [ZU597]). Tales medidas se El riesgo se mide por el grado de incertidumbre en las
aplican en el nivel de disefio y de codificacibn, y por con- estimaciones cuantitativas establecidas por recursos, cos-
siguiente son dificiles de utilizar durante la planificaci6n te y planificacih krnporal: Si no se entiende bien el h b i -
del software (antes de que exista un disefio o un c6digo). to del proyecto o 10s requisitos del proyecto estin sujetos
Sin embargo, al comienzo del proceso de planificaci6n se a cambios, la incertidumbre y el riesgo son peligrosamen-
pueden establecer otras valoraciones de complejidad m k te altos. El planificador del software deberia solicitar defi-
subjetivas (por ejemplo, 10s factores de ajuste de la com- niciones completas de rendhiento y de interfaz (dentro
plejidad del punto de funcion descritos en el Capitulo 4). de una especificaci6n del sistema). El planificador y, lo que
El tamaiio del proyecto es otro factor importante que es mis importante, el cliente, deben tener presente que
puede afectar a la precision y a la eficiencia de las esti- cualquier cambio en 10s requisitos del software significa
maciones. A medida que el tarnaiio aumenta, crece rfipi- inestabilidad en el coste y en la planificacion temporal.
damente2la interdependencia entre varios elementos del Sin embargo, un gestor de proyecto no deberia obse-
software. El problema de la descomposici6n, un enfo- sionarse con la estimacion. Los enfoques modernos de
que importante hacia la estimacion, se hace mfis dificil ingenieria del software (por ejemplo, modelos de pro-
porque 10s elementos descompuestos pueden ser toda- cesos evolutivos) toman un punto de vista iterativo del
via excesivamente grandes. Parafraseando la ley de desarrollo. En tales enfoques, es posible3revisar la esti-
Murphy: <<loque puede ir ma1 irfi m a b , y si hay mis maci6n (a medida que se conoce mfis informaci6n), y
cosas que puedan fallar, mas cosas fallarfin. variarla cuando el cliente haga cambios de requisitos.
En el Capitulo 6 se presentan tecnicas sistematicas para el analisis 3 Esto n o significa que siempre sea aceptable politicamente modifi-
del riesgo. car las estimaciones iniciales. Una organization de software madura
El tamario se incrementa con frecuencia debido a1 cambio del ambito. y sus gestores reconocen que el cambio no es libre. Y sin embargo
que ocurre cuando el cliente modifica 10s requisitos. El increment0 del muchos clientes solicitan (incorrectamente) que una vez realizada la
tamario del proyecto puede tener un impacto geometric0 en el coste y estimacion deberia mantenerse independientemente de que las cir-
en la planificacion del proyecto [MAH96]. cunstancias cambien.
CAPfTULO 5 PLANIFICACI~N
DE P R O Y E C T O S DE SOFTWARE
El objetivo de la planificaci6n del proyecto de softwa- El objetivo de la planificaci6n se logra mediante un

re es proporcionar un marco de trabajo que permita a1 proceso de descubrimiento de la informaci6n que lleve
gestor hacer estimaciones razonables de recursos, cos- a estimaciones razonables. En las secciones siguientes,
te y planificaci6n temporal. Estas estimaciones se hacen se estudian cada una de las actividades asociadas a la
dentro de un marco de tiempo limitado a1 comienzo de planificaci6n del proyecto de software.
un proyecto de software, y deberian actualizarse regu-
larmente a medida que progresa el proyecto. Ademis,
las estimaciones deberian definir 10s escenarios del
Cuonto mbs sepo, mejor reolizord lo estimocih
ccmejor cason y ccpeor cason de forma que 10s resulta- Por cansiguiente, octuolice sus estimociones
dos del proyecto puedan limitarse. o medido que prayreso el proyecto.
La primera actividad de la planificaci6n del proyecto de tado; ambos esthn pensando hasta d6nde podrian llegar
software es determinar el Ambit0 del software. Se deben (probablemente 10s dos tienen aqui diferentes expecta-
evaluar la funci6n y el rendimiento que se asignaron a1 tivas); ambos quieren quitirselo pronto de encima; per0
software durante la ingenieria del sistema de computa- a1 mismo tiempo quieren que salga bien.
dora (Capitulo lo), para establecer un imbito de pro-
yecto que no sea ambiguo, ni incomprensible para ~Comodeberia empezar la
directivos y tkcnicos. Se debe delimitar la declaraci6n comunicacion entre el
del hmbito del software. desarrollador y el cliente?
El cimhito del software describe el control y 10s
datos a procesar, la funcibn, el rendimiento, las res- Sin embargo, se debe iniciar la comunicacibn. Gau-
tricciones, las interfaces y la fiabilidad. Se evallian las se y Weinberg [GAU89] sugieren que el analista comien-
funciones descritas en la declaraci6n del imbito, y en ce haciendo preguntas de contexto lihre. Es decir, una
algunos casos se refinan para dar mhs detalles antes serie de preguntas que lleven a un entendimiento bhsi-
del comienzo de la estimaci6n. Dado que las estima- co del problema, las personas que esthn interesadas en
ciones del coste y de la planificaci6n temporal estin la solucibn, la naturaleza de la solucidn que se desea y
orientadas a la funcibn, muchas veces es litil llegar a la efectividad prevista del primer encuentro.
un cierto grado de descomposici6n. Las consideracio- El primer conjunto de cuestiones de contexto libre se
nes de rendimiento abarcan 10s requisitos de tiempo centran en el cliente, en 10s objetivos globales y en 10s
de respuesta y de procesamiento. Las restricciones beneficios. Por ejemplo, el analista podria preguntar:
identifican 10s limites del software originados por el iQuiCn esti detris de la solicitud de este trabajo?
hardware externo, por la memoria disponible y por iQuiCn utilizarh la soluci6n?
otros sistemas existentes. ~ C U seri
A el beneficio econ6mico de una buena solu-
ci6n?
5.3.1.Obtenci6n de la informaci6n necesaria iHay otro camino para la soluci6n?
para el ambito Las preguntas siguientes permiten que el analista
A1 principio de un proyecto de software las cosas siem- comprenda mejor el problema y que el cliente exprese
pre estin un poco borrosas. Se ha definido una necesi- sus percepciones sobre una soluci6n:
dad y se han enunciado las metas y objetivos bisicos, iC6m0 caracterizaria' [el cliente] un resultado
per0 todavia no se ha establecido la informaci6n nece- cccorrecto>> que se generan'a con una soluci6n satis-
saria para definir el imbito (prerrequisito para la esti- factoria?
maci6n). i c o n quC problema(s) se afrontari esta soluci6n?
La tCcnica utilizada con mis frecuencia para acercar iPuede mostrarme (o describirme) el entorno en el
a1 cliente y a1 desarrollador, y para hacer que comien- que se utilizarh la soluci6n?
ce el proceso de comunicaci6n es establecer una reu-
ni6n o una entrevista preliminar. La primera reuni6n iHay aspectos o lirnitaciones especiales de rendimiento
entre un ingeniero de software (el analista) y el cliente que afecten a la forma en que se aborde la soluci6n?
puede compararse a la primera cita entre adolescentes. La liltima serie de preguntas se centra en la efecti-
Ninguna persona sabe lo que decir o preguntar; ambos vidad de la reuni6n. Gause y Weinberg las llaman ccmeta-
estin preocupados por si lo que dicen es mal interpre- cuestionesn y proponen la lista siguiente (abreviada):
~ E usted
s la persona apropiada para responder a estas
preguntas?iSon <<oficiales>> sus respuestas?
i s o n relevantes mis preguntas para su problema?
iEstoy realizando muchas preguntas?
iHay alguien mas que pueda proporcionar informa-
cion adicional?
iHay algo mas que debiera preguntarle?
...no todo lo imaginable es factible,ni siquiera en el softwa-
Estas preguntas (y otras) ayudarh a <<romperel hie- re, fugaz como puede aparecer un forastero. Por el contrario la
lo>>y a iniciar la comunicacion esencial para establecer factibilidad del software tiene cuatro dimensiones s6lidas: Tec-
nologia-iEs factible un proyecto tkcnicamente? iEsti dentro
el Ambito del proyecto. Sin embargo, una reunion basa- del estado actual de la %ca? Financiacibn--iEs factible finan-
da en preguntas y respuestas no es un enfoque que haya cieramente? j h e d e realizarse a un coste asurnible por la empre-
tenido un Cxito abrumador. En realidad, la sesion P&R sa de software y por el cliente? 7'iempejheden 10s proyectos
so10 se deberia utilizar para el primer encuentro, reem- adelantarse a 10s de la competencia?Recursos-iLa organiza-
plazandose posteriormente por un tip0 de reunion que ci6n cuenta con 10s recursos suficientes para tener Cxito?
combine elementos de resoluci6n de problemas, nego- La respuesta es sencilla para algunos proyectos en ciertas
ciacion y especificacion. tireas, ya que se ha hecho antes algun proyecto de este tipo. A
Los clientes y 10s ingenieros de software con fre- las pocas horas, o, a veces, en pocas semanas de investigacion,
se puede estar seguro que se puede hacer de nuevo.
cuencia tienen establecido inconscientemente el pen-
samiento de <<nosotrosy ellos,,. En lugar de trabajar Los proyectos de 10s que no se tiene experiencia no son fhci-
les. Un equipo puede pasarse varios meses descubriendo cuC
como un equipo para identificar y refinar 10s requisi- les son 10s requisitos principales, y cuiles son aquCllos dificiles
tos, cada uno define su propio <<territorio>>y se comu- de implementar para una nueva aplicaci6n. iPodria ocunir que
nica por medio de memorandos, documentos formales alguno de estos requerimientos presentara algunos riesgos que
de situation, sesiones de preguntas y respuestas e infor- hicieran inviable el proyecto? ~Podriansuperarse estos ries-
mes. La historia ha demostrado que este enfoque es gos? El equipo de factibilidad debe asumir la arquitectura y el
muy pobre. Abundan 10s malentendidos, se omite infor- diseiio de 10s requerimientos de alto riesgo hasta el punto de
poder responder todas estas preguntas. En algunos casos, cuan-
macion importante y nunca se establece una relacion do el equip proporciona respuestas negativas, esto puede nego-
de trabajo con Cxito. ciarse con una reduccion de 10s requisitos.
Mientras tanto, 10s altos ejecutivos e s t h repicando sus dedos
en la mesa. A menudo, mueven sus cigarnos de forma elegan-
te, pero de forma impaciente y rodeados de humo exclaman
iYa es suficiente! iHazlo!
Muchos de estos proyectos que se han aprobado de esta for-
ma aparecen a 10s pocos aAos en la prensa como proyectos
Con estos problemas en mente un grupo de investi- defectuosos.
gadores independientes ha desarrollado un enfoque orien-
tad0 a1 equipo para la recopilacion de requisitos que
pueden aplicarse para ayudar a establecer el ambit0 de
un proyecto. Las tCcnicas denominadas tkcnicas para faci-
N estudio de viobilidod es impomnte, per0 10s
litar las especificaciones de la aplicacion (TFEA) (faci-
necesidodes de lo ges176n son incluso mbs importontes.
litated application specification techniques [FAST]), No es bueno construir un pmducto o sistemo de olto
pertenecen a un enfoque que alienta a la creacion de un tecnologio que en reolidod nodie quiero.
equipo compuesto de clientes y de desarolladores que tra-
bajen juntos para identificar el problema, proponer ele- Putnam y Myers sugieren, de forma acertada, que el
mentos de solution, negociar diferentes enfoques y estudio del hmbito no es suficiente. Una vez que se ha
especificar un conjunto preliminar de requisitos. comprendido el hmbito, tanto el equipo de desarrollo
como el resto deben trabajar para determinar si puede
ser construido dentro de las dimensiones reflejadas ante-
5.3.2. Viabilidad riormente. Esto es crucial, aunque es una parte del pro-
Una vez se ha identificado el irnbito (con la ayuda del ceso de estimation pasada por alto a menudo.
cliente), es razonable preguntarse: <<iPodemosconstruir
el software de acuerdo a este hmbito? ~ E factible
s el
proyecto?>>.Con frecuencia, las prisas de 10s ingenie- 5.3.3. Un ejemplo de ambito
ros de software sobrepasan estas preguntas (o e s t h obli- La comunicaci6n con el cliente lleva a una definici6n
gados a pasarlas por 10s clientes o gestores impacientes), del control y de 10s datos procesados, de las funciones
solo se tienen en cuenta en un proyecto condenado des- que deben ser implementadas, del rendimiento y res-
de el comienzo. Putnam y Myers [PUT97a] tratan este tricciones que delimitan el sistema, y de la informaci6n
aspect0 cuando escriben: relacionada. Como ejemplo, consideremos el software
CAPfTULO 5 PLANIFICACION DE PROYECTOS DE SOFTWARE
que se debe desarrollar para controlar un sistema de cla- Busqueda en la base datos.
sificaci6n de cinta transportadora (SCCT). La especifi- Determinar la posici6n del compartimento.
caci6n del h b i t o del SCCT es la siguiente: Producci6n de la seiial de control para el mecanismo
El sistema de clasifrcaci6n & cinta transportadora (SCCT) de maniobra.
clasifica las cajas que se mueven por una cinta transportadora.
Cada caja estara identificada por un c6digo de barras que con- Mantener una lista de 10s destinos de las cajas
tiene un numero de pieza y se clasifica en uno de seis comparti- En este caso, el rendimiento est6 determinado por la
mentos a1 final de la cinta. Las cajas pasarh por una estaci6n de
clasificaci6n que consta de un lector de cMigo de barras y un PC.
velocidad de la cinta transportadora. Se tiene que iermi-
El PC de la estaci6n de clasificaci6n esti conectado a un meca- nar el procesamiento de cada caja antes de que llegue la
nismo de maniobra que clasifica las cajas en 10s compartimen- siguiente caja a1 lector de cddigo de barras. El software
tos. Las cajas pasan en orden aleatorio y estin espaciadas del SCCT est6 limitado por el hardware a1 que tiene que
uniformemente. La cinta se mueve a cinco pies por minuto. En acceder --el lector de c6digo de barras, el mecanismo de
la Figura 5.1 esti representado esquemiticamente el SCCT. maniobra, la computadora personal (PC)-, la memoria
El software del SCCT debe recibir informacidn de entrada de disponible y la configuraci6n global de la cinta trans-
un lector de codigo de barras a intervalos de tiempo que se ajus-
ten a la velocidad de la cinta transportadora. Los datos del cMi-
portadora (cajas uniformemente espaciadas).
go de barras se decodifican a1 formato de identificaci6n de caja.
El software Ilevari a cab0 una inspecci6n en la base de datos de
numeros de piezas que contiene un miximo de 1000 entradas
para determinar la posici6n del compartimento adecuada para la Ajuste la estimacih para refleior 10s requisites
caja que se encuentre actualmente en el lector (estacih de clasi- del rendimiento y 10s resfricciones del diseno dificiles,
ficacion). La posici6n correcta del compartimento se pasari a un incluso si el umbito es sencillo.
mecanismo de maniobra de ordenaci6n que sihia las cajas en el
lugar adecuado. Se mantendrh una lista con 10s compartimentos
destino de cada caja para su posterior recuperaci6n e informe. El La funci6n, el rendimiento y las restricciones se eva-
software del SCCT recibiri tambiCn entrada de un tac6metro de luan a la vez. Una misma funci6n puede producir una
pulsos que se utilizari para sincronizar la seiial de control del diferencia de un orden de magnitud en el esfuerzo de
mecanismo de maniobra. Basindonos en el numero de pulsos desarrollo cuando se considera en un context0 con dife-
que se generen entre la estaci6n de clasificaci6ny el mecanismo
de maniobra. el software ~ r 0 d ~ c una
k 6 seiial de control para que
rentes limites de rendimiento. El esfuerzo y 10s costes
la maniobra &e adecuahamente la caja. requeridos para desarrollar el software SCCT serian
drhsticamente diferentes si la funci6n fuera la misma
(por ejemplo: la cinta transportadora siguiese colocan-
Movimiento do cajas en contenedores), per0 el rendimiento variar6.
de la cinta transportadora Por ejemplo, si la velocidad media de la cinta transpor-
tadora aumentara en un factor de 10 (rendimiento) y las
cajas no estuvieran uniformemente espaciadas (una res-
tricci6n), el software podna ser considerablemente m6s
complejo -requiriendo, por tanto, un mayor esfuerzo
de desarroll-. La funcibn, el rendimiento y las res-
cddigo tricciones e s t h intimarnente relacionadas.
de barras
Conexion
decontrol
FIGURA 5.1. Un sistema de clasificacion de cinta Lo considerocidn del bmbito del software debe contener
transportadora. uno evoluoci6n de todas 10s interfoces externas.
El planificador del proyecto examina la especificaci6n El software interactua con otros elementos del sis-
del 6mbito y extrae todas las funciones importantes del tema inform6tico. El planificador considera la natura-
software. Este proceso, denominado descomposicibn,se leza y la complejidad de cada interfaz para determinar
trat6 en el Capitulo 3 y produce como resultado las fun- cualquier efecto sobre 10s recursos, 10s costes y la pla-
ciones siguientes4: nificaci6n temporal del desarrollo. El concept0 de inter-
faz abarca .lo siguiente: (1) hardware (por ejemplo:
Lectura de la entrada del c6digo de barras. procesador, perifkricos) que ejecuta el software y 10s
Lectura del tac6metro de pulsos. dispositivos (por ejemplo: miquinas, pantallas) que e s t h
Descodificacidn de 10s datos del c6digo de pieza. controlados indirectamente por el software; (2) softwa-
En realidad, la descomposicion funcional se hace durante la inge-

nieria del sistema (Capitulo 10 ). El planificador utiliza la informacion
obtenida a partir de la especificacion del sistema para definir funcio-
nes del software.
re ya existente (por ejemplo, rutinas de acceso a una Si se ha desarrollado adecuadamente la especijica-

.base de datos, componentes de software reutilizables, ci6n del sisterna (vCase el Capitulo lo), casi toda la infor-
sistemas operativos) que debe ser integrado con el nue- maci6n requerida para la descripci6n del imbito del
vo software; (3) personas que hacen uso del software software estarh disponible y documentada antes de que
por medio del teclado (terminales) u otros dispositivos comience la planificaci6n del proyecto de software. En
de entradafsalida; (4) procedimientos que preceden o 10s casos en 10s que no haya sido desarrollada la espe-
suceden a1 software en una secuencia de operaciones. cificaci611, el planificador debe hacer el papel del ana-
En cada caso, debe comprenderse claramente la infor- lista de sistemas para determinar las caracteristicas y las
maci6n que se transfiere a travCs de la interfaz. restricciones que influirin en las tareas de estimaci6n.
La segunda tarea de la planificaci6n del desarrollo de

software es la estimaci6n de 10s recursos requeridos para
acometer el esfuerzo de desarrollo de software. La Figu-
ra 5.2 ilustra 10s recursos de desarrollo en forma de pirC
mide. En la base de la pirimide de recursos se encuentra
el entorno de desarrollo -herrarnientas de hardware y
softwareque proporciona la infraestructura de sopor-
te a1 esfuerzo de desarrollo. En un nivel mis alto se
encuentran 10s componentes de software reutilizables
-10s bloques de software que pueden reducir dristica-
mente 10s costes de desarrollo y acelerar la entrega-.
En la parte mis alta de la pirhmide esti el recurso pri-
mario -el personal-. Cada recurso queda especifica-
FIGURA 5.2. Recursos del proyecto.
do mediante cuatro caracteristicas: descripci6n del
recurso, informe de disponibilidad, fecha cronol6gica
en la que se requiere el recurso, tiempo durante el que 5.4.2. Recursos de software reutilizables
sera aplicado el recurso. Las dos ultimas caracteristicas La ingenieria del software basada en componentes
pueden verse como una ventana temporal. La disponi- (ISBC)~destaca la reutilizaci6n +st0 es, la creaci6n
bilidad del recurso para una ventana especifica tiene que y la reutilizaci6n de bloques de construcci6n de soft-
establecerse lo mhs pronto posible. ware [H0091]-. Dichos bloques de construcci611, lla-
mados componentes, deben establecerse en catilogos
~ C u aes
l la fuente de para una consulta rnis ficil, estandarizarsepara una ficil
information principal para aplicacidn y validarse para una ficil integraci6n.
determinar el ambito?
5.4.1. Recursos humanos El popel que iuegon 10s penonas implidos

en el software y los agonuadones del equip0
El encargado de la planificaci6n comienza elevando el
d que pertperteneten se baton en el Capitulo 3.
imbito y seleccionando las habilidades que se requieren
para llevar a cab0 el desarrollo. Hay que especificar tanto
la posici6n dentro de la organizaci6n (por ejemplo: gestor, Bennatan [BEN921 sugiere cuatro categorias de
ingeniero de software experimentado, etc.) como la espe- recursos de software que se deberian tener en cuenta a
cialidad (por ejemplo: telecomunicaciones, bases de datos, medida que se avanza con la planificaci6n:
clientefservidor). Para proyectos relativamente pequeiios Componentes ya desarrollados. El software
(una persona-aiio o menos) una sola persona puede llevar existente se puede adquirir de una tercera parte o
a cabo todos 10s pasos de ingenieria del software, consul- provenir de uno desarrollado internamente para un
tando con especialistas siempre que sea necesario. proyecto anterior. Llamados componentes CCYD
El numero de personas requerido para un proyecto (componentes comercialmente ya desarrollados),
de software s610 puede ser determinado despuCs de hacer estos componentes estfin listos para utilizarse en el
una estimaci6n del esfuerzo de desarrollo (por ejemplo, proyecto actual y se han validado totalmente.
personas-mes). Estas tCcnicas de estimaci6n del esfuer- Componentes ya experimentados. Especifica-
zo se estudiarfin despuCs en este mismo capitulo. ciones, diseiios, c6digo o datos de prueba existentes
La ingenieria del sottware basada en componentes se trata con

detalle en el Capitulo 27.
C A P ~ T U L O5 P L A N I F I C A C I ~ NDE P R O Y E C T O S DE SOFTWARE
desarrollados para proyectos anteriores que son simi- generalmente se aceptan. El plan del proyecto debe-
lares a1 software que se va a construir para el pro- ria reflejar la utilizaci6n de estos componentes.
yecto actual. Los miembros del equipo de software 3. Si se dispone de componentes de experiencia parcial
actual ya han tenido la experiencia completa en el para el proyecto actual, su uso se debe analizar con
area de la aplicaci6n representada para estos com- detalle. Si antes de que se integren adecuadamente
ponentes. Las modificaciones, por tanto, requeridas 10s componentes con otros elementos del software
para componentes de total experiencia, tendrhn un se requiere una gran modificaci61-1,proceda cuida-
riesgo relativamente bajo. dosamente - e l riesgo es alto-. El coste de modi-
ficar 10s componentes de experiencia parcial algunas
veces puede ser mayor que el coste de desarrollar
componentes nuevos.
Para que lo reutilizacion sea eficiente, 10s componentes De forma irbnica, a menudo se descuida la utili-
de software deben estar cotalogados, estandarizados y zacion de componentes de software reutilizables
volidados. durante la planificaci61-1,llegando a convertirse en la
preocupaci6n primordial durante la fase de desarro-
Componentes con experiencia parcial. Especi- 110 del proceso de software. Es mucho mejor especi-
ficaciones, disefios, c6digo o datos de prueba exis- ficar al principio las necesidades de recursos del
software. De esta forma se puede dirigir la evaluaci6n
tentes desarrollados para proyectos anteriores que
se relacionan con el software que se va a construir tkcnica de alternativas y puede tener lugar la adqui-
para el proyecto actual, per0 que requerirhn una sici6n oportuna.
modificaci6n sustancial. Los miembros del equipo
de software actual han limitado su experiencia s610 5.4.3. Recursos de entorno
a1 area de aplicaci6n representada por estos compo- El entorno es donde se apoya el proyecto de software,
nentes. Las modificaciones, por tanto, requeridas llamado a menudo entorno de ingenieria del software
para componentes de experiencia parcial tendran (EIS),incorpora hardware y software. El hardware pro-
bastante grado de riesgo. porciona una plataforma con las herramientas (soft-
Componentes nuevos. Los componentes de software) requeridas para producir 10s productos que son
ware que el equipo de software debe construir espe- el resultado de una buena practica de la ingenieria del
cificamente para las necesidades del proyecto software7. Como la mayoria de las organizaciones de
actual. software tienen muchos aspectos que requieren acce-
so a EIS, un planificador de proyecto debe determinar
~ Q u eospectos debemos la ventana temporal requerida para el hardware y el
consideror cuondo plonificamos software, y verificar que estos recursos estaran dispo-
la reutilizacion de componentes de nibles.
software existentes? Cuando se va a desarrollar un sistema basado en com-
putadora (que incorpora hardware y software especia-
lizado), el equipo de software puede requerir acceso a
Deberian ser consideradas las directrices siguientes 10s elementos en desarrollo por otros equipos de inge-
por el planificador de software cuando 10s componen- nieria. Por ejemplo, el software para un control nume'-
tes reutilizables se especifiquen como recurso: rico (CN)utilizado en una clase de maquina herramienta
1. Si 10s componentes ya desarrollados cumplen 10s puede requerir una maquina herrarnienta especifica (por
requisitos del proyecto, adquikralos. El coste de la ejemplo, el CN de un torno) como parte del paso de
adquisici6n y de la integraci6n de 10s componentes prueba de validaci6n; un proyecto de software para el
ya desarrollados seran casi siempre menores que el disefio de paginas avanzado puede necesitar un sistema
coste para desarrollar el software equivalente6.Ade- de composici6n fotografica o escritura digital en algu-
mas, el riesgo es relativarnente bajo. na fase durante el desarrollo. Cada elemento de hard-
2. Si se dispone de componentes ya experimentados, 10s ware debe ser especificado por el planificador del
riesgos asociados a la modificaci6n y a la integraci6n proyecto de software.
Cuando 10s componentes de sofiware existentes se utilizan durante OtrO hardware entorno destin* es la cOm~utadOrasobre la
un proyecto, la reducci6n del coste global puede ser importante. En que Se a ejecutar entregarse al usuariO
efecto, 10s datos de la industria indican que el coste, el tiempo de
adquisicion y el n~imerode defectos entregados a1 cliente s e redu-
cen.
A1 principio, el coste del software constituia un peque- (por ejemplo: el cliente, las condiciones de gestibn, el
fio porcentaje del coste total de 10s sistemas basados EIS [Entorno de Ingenieria del software], las fechas
en computadora. Un error considerable en las esti- limites) son similares. Por desgracia, la experiencia
maciones del coste del software tenia relativamente anterior no ha sido siempre un buen indicador de futu-
poco impacto. Hoy en dia, el software es el elemen- ros resultados.
to mas car0 de la mayoria de 10s sistemas informhti- Las opciones restantes son mCtodos viables para la
cos. Para sistemas complejos, personalizados, un gran estimaci6n del proyecto de software. Desde un pun-
error en la estimaci6n del coste puede ser lo que mar- to de vista ideal, se deben aplicar conjuntamente las
que la diferencia entre beneficios y pCrdidas. Sobre- tCcnicas indicadas; usando cada una de ellas como
pasarse en el coste puede ser desastroso para el comprobaci6n de las otras. Las te'cnicas de descom-
desarrollador. posicidn utilizan un enfoque de <<dividey vencerhw
La estimaci6n del coste y del esfuerzo del software para la estimaci6n del proyecto de software. Median-
nunca sera una ciencia exacta. Son demasiadas las varia- te la descomposici6n del proyecto en sus funciones
bles -humanas, tCcnicas, de entorno, politicas- que principales y en las tareas de ingenieria del software
pueden afectar a1 coste final del software y a1 esfuerzo correspondientes, la estimaci6n del coste y del esfuer-
aplicado para desarrollarlo. Sin embargo, la estimaci6n zo puede realizarse de una forma escalonada idbnea.
del proyecto de software puede dejar de ser un oscuro Se pueden utilizar 10s modelos empiricos de estima-
arte para convertirse en una serie de pasos sistemhticos cidn como complemento de las tCcnicas de descom-
que proporcionen estimaciones con un grado de riesgo position, ofreciendo un enfoque de estimaci6n
aceptable. potencialmente valioso por derecho propio. Cada
modelo se basa en la experiencia (datos hist6ricos) y
toma como base:
donde d es uno de 10s valores estimados (por ejemplo,

esfuerzo, coste, duraci6n del proyecto) y 10s vi,son deter-
minados parametros independientes (por ejemplo, LDC
o PF estimados).
Las herramientas automciticas de estimacidn imple-
Para realizar estimaciones seguras de costes y esfuer- mentan una o varias tCcnicas de descomposici6n o
zos tenemos varias opciones posibles: modelos empiricos. Cuando se combinan con una inter-
faz grhfica de usuario, las herramientas automaticas son
Dejar la estimaci6n para mas adelante (obviamente,
una opci6n atractiva para la estimaci6n. En sistemas de
ipodemos realizar una estimaci6n a1 cien por cien
este tipo, se describen las caracteristicas de la organi-
*
fiable tras haber terminado el proyecto!).
zaci6n de desarrollo (por ejemplo, la experiencia, el
Basar las estimaciones en proyectos similares ya ter- entorno) y el software a desarrollar. De estos datos se
minados. obtienen las estimaciones de coste y de esfuerzo.
Utilizar cctkcnicas de descomposici6n>>relativarnente
sencillas para generar las estimaciones de coste y de
esfuerzo del proyecto.
Utilizar uno o mhs modelos empiricos para la esti-
maci6n del coste y esfuerzo del software.
Desgraciadamente, la primera opci6n, aunque atrac- Herramientas CASE.
tiva, noes prhctica. Las estimaciones de costes han de
ser proporcionadas a priori. Sin embargo, hay que reco- Cada una de las opciones viables para la estimaci6n
nocer que cuanto mhs tiempo esperemos, mas cosas de costes del software, s610 sera buena si 10s datos his-
sabremos, y cuanto mas sepamos, menor sera la pro- t6ricos que se utilizan como base de la estimaci6n son
babilidad de cometer serios errores en nuestras esti- buenos. Si no existen datos hist6ricos, la estimaci6n del
maciones. coste descansari sobre una base muy inestable. En el
La segunda opci6n puede funcionar razonablemente Capitulo 4 examinamos las caracteristicas de 10s datos
bien, si el proyecto actual es bastante similar a 10s de productividad del software y c6mo pueden utilizar-
esfuerzos pasados y si otras influencias del proyecto se como base hist6rica para la estimaci6n.
C A P ~ T U L O5 DE
PLANIFICAC~~ N PROYECTOS DE SOFTWARE
La estimaci6n de proyectos de software es una forma Tamano en <<Mgicadifusa>>.Este enfoque utiliza

de resoluci6n de problemas y, en la mayoria de 10s casos, las tkcnicas aproximadas de razonamiento que son
el problema a resolver (es decir, desarrollar estimacio- la piedra angular de la 16gica difusa. Para aplicar este
nes de coste y de esfuerzo para un proyecto de softwa- enfoque, el planificador debe identificar el tipo de
re) es demasiado complejo para considerarlo como un aplicaci6n, establecer su magnitud en una escala
todo. Por esta raz6n, descomponemos el problema, vol- cuantitativa y refinar la magnitud dentro del rango
viCndolo a definir como un conjunto de pequefios pro- original. Aunque se puede utilizar la experiencia per-
blemas (esperando que sean mfis manejables). sonal, el planificador tambiCn deberia tener acceso
En el Capitulo 3, se estudi6 el enfoque de descom- a una base de datos hist6rica de proyectos8 para que
posici6n desde dos puntos de vista diferentes: descom- las estimaciones se puedan comparar con la expe-
posici6n del problema y descomposici6n del proceso. riencia real.
La estimacidn hace uso de una o ambas formas de par- Tamano en punto de funcion. El planificador
ticionamiento. Pero antes de hacer una estimaci6n, el desarrolla estimaciones de caracten'sticas del domi-
planificador del proyecto debe comprender el hmbito nio de informacidn estudiadas en el Capitulo 4.
del software a construir y generar una estimaci6n de su
cctamafio>~. ~ C O medimos
~ O el
software que estamos
5.6.1. Tamaiio del software planeando construir?
La precisi6n de una estimaci6n del proyecto de soft-
ware se predice basfindose en una serie de cosas: (1) el Tamano de componentes estandar. El software
grado en el que el planificador ha estimado adecuada- se compone de un n6mero de cccomponentes estfin-
mente el tamafio del product0 a construir; (2) la habili- d a r ~que son genCricos para un Lea en particular de
dad para traducir la estimaci6n del tamafio en esfuerzo la aplicaci6n. Por ejemplo, 10s componentes estfin-
humano, tiempo y dinero (una funci6n de la disponibi- dar para un sistema de informaci6n son: subsistemas,
lidad de mCtricas fiables de software de proyectos ante- mbdulos, pantallas, informes, programas interacti-
riores); (3) el grado en el que el plan del proyecto refleja vos, programas por lotes, archivos, LDC e instruc-
las habilidades del equipo de software, y (4) la estabi- ciones para objetos. El planificador de proyectos
lidad de 10s requisitos del software y el entorno que estima el n6mero de incidencias de cada uno de 10s
soporta el esfuerzo de la ingenieria del software. componentes esthndar, y utiliza datos de proyectos
hist6ricos para determinar el tamafio de entrega por
componente estindar. Para ilustrarlo, considere una
aplicaci6n de sistemas de information. El planifica-
dor estima que se generarhn 18 informes. Los datos
El ((tamoiio)) del softwore o construir puede estimorse hist6ricos indican que por informe se requieren 967
utilizando uno medida directo, LDC, a uno medido lineas de Cobol [PUT92]. Esto permite que el plani-
indirecta, PF. ficador estime que se requieren 17.000 LDC para el
componente de informes. Para otros componentes
En esta seccibn, consideramos el problema del tama- esthndar se hacen estimaciones y chlculos similares,
rio del software. Puesto que una estimaci6n del proyec- y se producen resultados combinados de valores de
to es tan buena como la estimaci6n del tamafio del tamafios (ajustados estadisticamente).
trabajo que va a llevarse a cabo, el tamaiio representa Tamano del cambio. Este enfoque se utiliza
el primer reto importante del planificador de proyectos. cuando un proyecto comprende la utilizaci6n de soft-
En el context0 de la planificaci6n de proyectos, el tama- ware existente que se debe modificar de alguna
fio se refiere a una producci6n cuantificable del proyecto manera como parte de un proyecto. El planificador
de software. Si se toma un enfoque directo, el tamafio estima el n6mero y tipo (por ejemplo: reutilizackh,
se puede medir en LDC. Si se selecciona un enfoque aiiadir codigo, cambiar c6dig0, suprimir c6digo) de
indirecto, el tamafio se representa como PF. modificaciones que se deben llevar a cabo. Mediante
Putnam y Myers [PUT921 sugieren cuatro enfoques m a ccproporci6n de esfuerzo>>[PUT921 para cada tip0
diferentes del problema del tamaiio: de cambio, se puede estimar el tamaiio del cambio.
Consulte la Seccion 5.9 que trata brevemente las herrarnientas de

estimacion que utilizan una base de datos historica y otras tecnicas
de tamaAo estudiadas en esta seccion.
Putnam y Myers sugieren que 10s resultados de cada do sospechar que se utilice unicamente una mCtrica de
.uno de 10s mCtodos de tamafio seiialados anteriomente productividad de linea base. En general, el dominio del
se combinan estadisticamente para crear una estimacibn proyecto deberia calcular las medias de LDCIpm o PFfpm.
de tres puntos o del valor esperado. Esto se lleva a cab0 Es decir, 10s proyectos se deberian agrupar por tamaiio
desarrollando valores de tamaiio optimistas (bajos), y m h de equipo, irea de aplicaci6n, complejidad y otros pari-
probables, y pesimistas (altos), y se combinan utilizando metros relevantes. Entonces se deberian calcular las
la Ecuaci6n (5.1) que se describe en la secci6n siguiente. medias del dominio local. Cuando se estima un proyec-
to nuevo, primero se debena asignar a un dominio, y a
continuaci6n utilizar la media del dominio adecuado p&a
5.6.2. Estimaci6n basada en el problema la productividad a1 genera la estimaci6n. Las tCcnicas
En el Capitulo 4, las lineas de codigo (LDC) y 10s pun- de estimaci6n de LDC y PF difieren en el nivel de deta-
tos de funci6n (PF) se describieron como medidas bhsi- lle que se requiere para la descomposici6n y el objetivo
cas a partir de las que se pueden calcular mCtricas de de la partici6n. Cuando se utiliza LDC como variable de
productividad. Los datos de LDC y PF se utilizan de dos estimaci6n, la descomposi~i6n'~ es absolutamente esen-
formas durante la estimaci6n del proyecto de software: cia1 y con frecuencia se toman para considerables nive-
(1) como una variable de estimaci6n que se utiliza para les de detalle. El enfoque de descomposici6n siguiente
ccdimensionar>> cada elemento del software, y (2) como ha sido adaptado por Phillips [PHI98I1':
mCtricas de linea base recopiladas de proyectos anterio-
res y utilizadas junto con variables de estimaci6n para
desarrollar proyecciones de coste y de esfuerzo.
Las estimaciones de LDC y PF son tCcnicas de esti-
maci6n distintas. A pesar de que ambas tienen varias Poro esiimaciones de LDC, lo descomposici6n
se centro en loshnciones del software.
caractensticas en comun. El planificador del proyecto
comienza con un enfoque limitado para el imbito del definir el h b i t o del producto;
software y desde este estado intenta descomponer el identificar funciones descomponiendo el h b i t o ;
software en funciones que se pueden estimar indivi- hacer mientras haya funciones
dualmente. Para cada funci6n entonces se estiman las seleccionar una funci6n.
J
asignar todas las funciones a la lista de subfunciones;
LDC y el PF (la variable de estimaci6n). De forma alter-
hacer mientras haya subfunciones
nativa, el planificador puede seleccionar otro compo- seleccionar m a subfunci6nk
nente para dimensionar clases u objetos, cambios o si subfunci6nk= subfunci6nddescrita en m a base
procesos de gesti6n en 10s que puede tener impacto. de datos historica
entonces anotar datos hist6ricos del coste,
lQue tienen en comun la esfuerzo, tiimaiio, (LDC o PF) para
estimacion orientada a PF la subfunci6nd;
ajustar datos hist6ricos del coste,
y a LDC? esfuerzo. tamaiio basados en cual-
Las mCtricas de productividad de linea base (por use datos del coste, esfuerzo, tama-
ejemplo: LDCIpm o P F / ~ se ~ aplican
~ ) entonces para iio ajustados para obtener una esti-
la variable de estimaci6n adecuada y se extrae el coste maci6n parcial, En;
o el esfuerzo de la funci6n. Las estimaciones de fun- estimacion proykcto = suma de
cion se combinan para producir una estimaci6n global I Ep I ;
sino si se puede estimar coste, esfuerzo,
del proyecto entero. tamaiio (LDC o PF) para subfunci6nk
entonces obtener estimaci6n
EP;.
estimaci6n proyecto = suma de
Cuondo se comporon mihicos de productividod poro
{ Ep 1;
proyectos, esti seguro de estoblecer uno dosificocibn sino subdividu subfunci6nk en sub-
de 10s tipos de proyectos. Esto le permiti16 tolculor funciones mis pequeiias;
promedias porn dominios especifcos y lo estimocih aiiadirlas a la lista de subfunciones;
sem m6s exocto. fin si
fin si
Es importante seiialar, sin embargo, que hay una sus- fin hacer
tancial diversidad en metricas de productividad, hacien- fin hacer
El acronimo pm hace referencia a personas-mes. l o En general se descomponen las funciones del problema. Sin embargo.
se puede utilizar una lista de componentes esthdar (Seccion 5.6.1).
I I El lenguaje informal de disetio del proceso setialado aqui se expone
para ilustrar el enfoque general para el dimensionamiento. No tiene
en cuenta ninguna eventualidad logica.
CAP~TULO
5 P L A N I F I C A C I ~ NDE P R O Y E C T O S DE S O F T W A R E
El enfoque de descomposici6n visto anterionnente asu- 5.6.3. Un ejemplo de estimaci6n basada en LDC
me que todas las funciones pueden descomponerse en sub- Como ejemplo de tCcnicas de estimaci6n de LDC y PF,
funciones que podrin asemejarse a entradas de una base tomemos en consideracih un paquete de software a
de datos hist6rica. Si este no es el caso, deberd aplicarse desanollarse para una aplicaci6n de disefio asistido por
otro enfoque de dimensionamiento. Cuanto m& grande computadora (computer-aided design, CAD) de com-
sea el grado de particionamiento, rnhs probable sera que ponentes mecinicos. Una revisi6n de la especijicacidn
pueda desarrollar estirnaciones de LDC m& exactas. del sistema indica que el software va a ejecutarse en una
Para estimaciones de PF, la descomposici6n funcio- estaci6n de trabajo de ingenieria y que debe interconec- ,
na de diferente manera. En lugar de centrarse en la fun- tarse con varios perifkricos de graficos de computadora
ci6n, se estiman cada una de las caracteristicas del entre 10s que se incluyen un ratbn, un digitalizador, una
dominio de informacidn -entradas, salidas, archivos pantalla a color de alta resoluci6n y una impresora lfiser.
de datos, peticiones, e interfaces externas- y 10s cator- Utilizando como guia una especijicacidn de sistema,
ce valores de ajuste de la complejidad estudiados en el se puede desarrollar una descripci6n preliminar del
Capitulo 4. Las estimaciones resultantes se pueden uti- fimbito del software:
lizar para derivar un valor de PF que se pueda unir a
El software de CAD aceptari datos geomCtricos de dos y
datos pasados y utilizar para generar una estimacion. tres dimensiones por parte del ingeniero. El ingeniero se inter-
conectari y controlari el sistema de CAD por medio de una
interfaz de usuario que va a exhibir las caracteristicas de un
buen diseiio de interfaz hombre-miquina. Una base de datos
de CAD contiene todos 10s datos geomCtricos y la informa-
Poro estimociones de PF, la descomposicibn se centro en ci6n de soporte. Se desanollarhn m6dulos de anilisis de dise-
los carocteristicas &I dominio de informacibn. iio para producir la salida requerida que se va a visualizar en
varios dispositivos graficos. El software se diseiiara para con-
trolar e interconectar dispositivos perifkricos entre 10s que
Con independencia de la variable de estimaci6n que se incluyen un rat6n, un digitalizador, una impresora liser y
se utilice, el planificador del proyecto comienza por un trazador grifico (plotter).
estimar un rango de valores para cada funci6n o valor La descripci6n anterior del ambit0 es preliminar
del dominio de informaci6n. Mediante 10s datos hist6- -no esth limitada-. Para proporcionar detalles con-
ricos o (cuando todo lo demhs falla) la intuicibn, el pla- cretos y un limite cuantitativo se tendrian que ampliar
nificador estima un valor de tamaiio optimista, rnhs todas las descripciones. Por ejemplo, antes de que la
probable y pesimista para cada funcibn, o cuenta para estimacion pueda comenzar, el planificador debe
cada valor del dominio de informaci6n. A1 especificar determinar quC significa aaracteristicas de un buen
un rango de valores, se proporciona una indicaci6n disefio de interfaz hombre-mfiquina>>y cu6l sera el
implicita del grado de incertidumbre. tamafio y la sofisticacion de la <<basede datos de
CAD>>.
~ C O calcular
~ O el valor Para estos propbsitos, se asume que ha habido rnhs
esperado para el tamaiio del refinamiento y que se identifican las funciones de soft-
software? ware siguientes:
interfaz de usuario y facilidades de control (IUFC),
Entonces se calcula un valor de tres puntos o espe-
rado. El valor esperado de la variable de estimaci6n anhlisis geomCtrico de dos dimensiones (AG2D),
(tamaiio), VE, se puede calcular como una media pon- anhlisis geomCtrico de tres dimensiones (AG3D),
derada de las estimaciones optimistas (Sop[),las mas gesti6n de base de datos (GBD),
probables (S,), y las pesimistas (Spess).Por ejemplo, facilidades de presentaci6n grhfica de computadora
V E = (Sop,+ 4Sm+ S,,,) / 6 (5.1) (FPGC),
da credit0 a la estimaci6n ccmfis probable>>y sigue una control de perifCricos (CP),
distribuci6n de probabilidad beta. Se asume que existe m6dulos de anfilisis del disefio (MAD).
una probabilidad muy pequeiia en donde el resultado
del tarnaiio real quedarh fuera de 10s valores pesimistas
y optimistas. Muchos oplicociones modernos residen en uno redo son
Una vez que se ha determinado el valor esperado de porte de uno oquitecfiro cliente/servidor. Por
la variable de estimacibn, se aplican datos hist6ricos de consiguiente, estb seguro que sus estimociones contienen
productividad de LDC y PF. iSon correctas las estima- el esfuerzo requerido porn el desorrollo del sohore de lo
ciones? La unica respuesta razonable a esto es: <<No cinfmestiucfiro~.
podemos estar segurosn. Cualquier tCcnica de estima-
ci6n, no importa lo sofisticada que sea, se debe volver Siguiendo la tCcnica de descomposici6n de LDC, se
a comprobar con otro enfoque. Incluso entonces, va a desarrolla la tabla de estimaci6n mostrada en la Figura
prevalecer el sentido comun y la expenencia. 5.3. Se desarrolla un rango de estimaciones de LDC para
INGENIER~A DEL SOFTWARE. UN ENFOQUE PR~CTICO
cada funci6n. Por ejemplo, el rango de estimaciones

.de LDC de la funci6n del anilisis geomktrico de tres
dimensiones es: optimista 4 . 6 0 0 LDC-; mis pro-
bable -6.900-, y pesimista -8.600 LDC-. Apli-
cando la Ecuaci6n (5. I), el valor esperado de la funci6n Se puede obtener informocidn sobre 10s herromientos de
del anilisis geomCtrico es 6.800 LDC. Este n6mero se estimocibn del coste medionte PF en www.spr.com
introduce en la tabla. De forma similar se derivan otras
estimaciones. Sumando en vertical la columna esti- Valor de dominio Opt. Probable Pes. Cuenta Peso Cuenta PF
mada de LDC, se establece una estimaci6n de 33.200 de information est.
lineas de c6digo para el sistema de CAD. Numero de entradas 20 24 30 24 4 97
Numero de salidas 12 15 22 16 5 78
Numero de peticiones 16 22 28 22 5 88
Numero de archivos 4 4 5 4 1 0 42
Numero de interfaces
externas 2 2 3 2 7 15
No sucumbo o lo tentocibn de utilizor este resultodo coma Cuenta total 320
estimocibn. Deberh obtener o h estimocibn utilizondo
un metodo diferente. FIGURA 5.4. Estirnacion de 10s valores del dominio
de informacion.
Una revision de datos hist6ricos indica que la pro-
ductividad media de la organizaci6n para sistemas de Como se describe en el Capitulo 4, se estima cada
este tip0 es de 620 LDC/pm. Seg6n una tarifa laboral uno de 10s factores de ponderacih de la complejidad,
de £8.000 por mes, el coste por linea de c6digo es apro- y se calcula el factor de ajuste de la complejidad:
ximadamente de £13,00. Segun la estimaci6n de LDC
y 10s datos de productividad hist6ricos, el coste total Factor Valor
estimado del proyecto es de £43 1.000 y el esfuerzo esti- Copia de seguridad y recuperaci6n 4
mado es de 54 personas-mes12. Comunicaciones de datos 2
Proceso distribuido 0
Rendimiento critic0 4
Entorno operativo existente 3
Funcion LDC estimada
Entrada de datos en linea (on-line) 4
Interface del usuario y facilidades de control (IUFC) Transacciones de entrada en mliltiples
Analisis geometrico de dos dimensiones (AG2D) pantallas 5
Analisis geometrico de tres dimensiones (A32D) Archivos maestros actualizados en linea
Gestion de base de datos (GBD)
Facilidades de presentacion grafica (on-line) 3
de computadora (FPGC) Complejidad de valores del dominio
Control de perifericos (CP)
Modulos de analisis del disefio (MAD)
de informaci6n 5
Complejidad del procesamiento interno 5
I Lineas de cddigos estimadas C6digo disefiado para la reutilizaci6n 4
Conversi6n/instalaci6n en disefio 3
FIGURA 5.3. Tabla de estimacion para el metodo de LDC. Instalaciones m6ltiples 5
Aplicacih diseiiada para el cambio 5
Factor de ajuste de la complejidad 1,17
5.6.4. Un ejemplo de estimaci6n basada en PF Finalmente, se obtiene el n6mero estimado de PF:
La descomposici6n de estimaci6n basada en PF se cen- PFesti,,, = cuenta total x [0,65 + 0.01 x C(Fi )]
tra en 10s valores de dominio de informaci6n, y no en
las funciones del software. Teniendo en cuenta la tabla PFestimado = 375
de cilculos de punto de funci6n presentada en la Figu- La productividad media organizacional para sistemas
ra 5.4, el planificador del proyecto estima las entradas, de este tipo es de 6,5 PF/pm. Seg6n la tarifa laboral de
salidas, peticiones, archivos e interfaces externas del £8.000 por mes, el coste por PF es aproximadamente de
software de CAD. Para 10s prop6sitos de esta estima- £1.230. Seg6n la estimaci6n de LDC y 10s datos de pro-
c i h , el factor de ponderaci6n de la complejidad se asu- ductividad hist6ricos, el coste total estirnado del proyecto
me como la media. La Figura 5.4 presenta 10s resultados es de £461.000, y el esfuerzo estimado es de 58 perso-
de esta estimaci6n. nas/mes.
l 2 La estimacion se redondea acercandose l o m a s posible a £1.000 y

persona-mes.
C A P ~ T U L O5 P L A N I F I C A C l 6 N DE PROYECTOS DE SOFTWARE
5.6.5. Estimaci6n basada en el proceso ra tendremos dos o tres estimaciones del coste y del
La tCcnica mis c o m h para estimar un proyecto es basar esfuerzo que se pueden comparar y evaluar. Si ambos
la estimaci6n en el proceso que se va a utilizar. Es decir, tipos de estimaciones muestran una concordancia razo-
el proceso se descompone en un conjunto relativamen- nable, hay una buena raz6n para creer que las estima-
te pequefio de actividades o tareas, y en el esfuerzo ciones son fiables. Si, por otro lado, 10s resultados de
requerido para llevar a cab0 la estimaci6n de cada tarea. estas tCcnicas de descomposici6n muestran poca con-
cordancia, se debe realizar mis investigacibn y anilisis.
A1 igual que las tCcnicas basadas en problemas, la
estimaci6n basada en el proceso comienza con un esbo-
zo de las funciones del software obtenidas a partir del 5.6.6. Un ejemplo de estimaci6n basada
imbito del proyecto. Para cada funci6n se debe llevar en el proceso
a cab0 una serie de actividades del proceso de softwa- Para ilustrar el uso de la estimaci6n basada en el pro-
re. Las funciones y las actividades del proceso de soft- ceso, de nuevo consideremos el software de CAD pre-
ware relacionadas se pueden representar como parte de sentado en la Secci6n 5.6.3. La configuraci6n del sistema
una tabla similar a la presentada en la Figura 3.2. y todas las funciones del software permanecen iguales
y estin indicadas en el imbito del proyecto.
Elmorco de hobaio comh del proceso (MCP)
se estudio en el Copitulo 2.
Si el tiempo lo permite, reolice uno moyor
Una vez que se mezclan las funciones del proble- descomposicih ol especificor los toreos; en lo Figuro 5.5,
ma y las actividades del proceso, el planificador esti- p. ei., se divide el onalisis en sus tareos principoles y se
ma el esfuerzo (por ejemplo: personas-mes) que se estimo coda uno por seporodo.
requerirh para llevar a cab0 cada una de las activida-
des del proceso de software en cada funci6n. Estos En la tabla de estimaci6n de esfuerzos ya termina-
datos constituyen la matriz central de la tabla de la da, que se muestra en la Figura 5.5 aparecen las esti-
Figura 3.2. Los indices de trabajo medios (es decir, maciones de esfuerzo (en personas-mes) para cada
esfuerzo costelunidad) se aplican entonces a1 esfuer- actividad de ingenieria del software proporcionada para
zo estimado a cada actividad del proceso. Es muy pro- cada funci6n del software de CAD (abreviada para
bable que en cada tarea varie el indice de trabajo. El mayor rapidez). Las actividades de ingenieria y de cons-
personal veterano se involucra de lleno con las pri- truccidnlentrega se subdividen en las tareas principa-
meras actividades y generalmente es mucho mhs car0 les de ingenieria del software mostradas. Las estima-
que el personal junior, quienes estin relacionados con ciones iniciales del esfuerzo se proporcionan para la
las tareas de diseiio posteriores, con la generaci6n del comunicacidn con el cliente, planijicacidn y andlisis de
c6digo y con las pruebas iniciales. riesgos. Estos se sefialan en la fila Total en la parte infe-
rior de la tabla. Los totales horizontales y verticales pro-
porcionan una indicaci6n del esfuerzo estimado que se
Actividad Construccion requiere para el anhlisis, disefio, codificaci6n y pruebas.
+ cc p 1 a n i f i c a c i 6 n ~ ~ ~Ingenieria
de riesgo
~~~~~ entrega EC Totales
Se deberia sefialar que el 53 por 100 de todo el esfuer-
Tarea -b AnalisislDiseAo CodigolPrueba
I 1
I I
I I
zo se aplica en las tareas de ingenieria <<frontales)) (an&
I
I I I I I
Funcion I I lisis y diseiio de 10s requisitos) indicando la importancia
v I I I I I I I I I
relativa de este trabajo.
Basado en una tarifa laboral de £5.000 por mes, el
coste total estimado del proyecto es de £230.000 y el
esfuerzo estimado es de 46 personaslmes. A cada acti-
vidad de proceso del software o tareas de ingenieria del
software se le podria asociar diferentes indices de tra-
bajo y calcularlos por separado.
El esfuerzo total estimado para el software de CAD
oscila de un indice bajo de 46 personas-mes (obtenido
CC = Comunicacion cliente EC = Evaluation cliente mediante un enfoque de estimaci6n basado en el pro-
ceso) a un alto de 58 personas-mes (obtenido median-
FIGURA 5.5. Tabla de estimacion basada en el proceso. te un enfoque de estimaci6n de PF). La estimaci6n media
(utilizando 10s tres enfoques) es de 53 personas-mes.
Como ultimo paso se calculan 10s costes y el esfuer- La variation mhxima de la estimaci6n media es apro-
zo de cada funcibn, y la actividad del proceso de soft- ximadamente del 13 por ciento.
ware. Si la estimacion basada en el proceso se realiza ~ Q u Cocurre cuando la concordancia entre las esti-
independientemente de la estimaci6n de LDC o PF, aho- maciones es mala? Para responder a esta pregunta se ha
de reevaluar la informaci6n que se ha utilizado para 1. No se entiende adecuadamente el ambito del pro-
hacer las estimaciones. yecto o el planificador lo ha ma1 interpretado.
Muchas divergencias entre estimaciones se deben a
2. Los datos de productividad usados para tCcnicas de
una de dos causas:
estimaci6n basados en problemas no son apropiados
para la aplicaci611, e s t h obsoletos (ya no reflejan con
precisi6n la organizacibn de la ingenieria del soft-
No espere que todos 10s estimociones coincidon ware), o se han aplicado err6neamente.
en uno o dos porcentojes. Silo estimocibn eshj
demo de uno bondo del20 por 100, puede El planificador debe determinar la causa de la diver-
reconcilio~seen un inico volor. gencia y conciliar las estimaciones.
Un modelo de estimacidn para el software de computa- seiialada en la Ecuaci6n (5.2) la mayoria de 10s mode-
dora utiliza f61mulas derivadas empiricamente para pre- 10s de estimaci6n tienen algun componente de ajuste del
decir el esfuerzo como una funci6n de LDC o PF. Los proyecto que permite ajustar E por otras caracteristicas
valores para LDC o PF son estimados utilizando el enfo- del proyecto (por ejemplo: complejidad del problema,
que descrito en las Secciones 5.6.2 y 5.6.3. Pero en lugar experiencia del personal, entorno de desarrollo). Entre
de utilizar las tablas descritas en esas secciones, 10s valo- 10s muchos modelos de estimaci6n orientados a LDC
res resultantes para LDC o PF se unen a1 modelo de esti- propuestos en la bibliografia se encuentran 10s siguien-
maci6n. Los datos empiricos que soportan la mayoria tes:
de 10s modelos de estimaci6n se obtienen de una mues- E = 5,2 x (KLDC)~.~' Modelo de Walston-Felix
tra limitada de proyectos. Por esta razon, el modelo de E = $5 + 0,73 x
estimacidn no es adecuado para todas las clases de soft- (KLDC)'.'~ Modelo de Bailey-Basili
ware y en todos 10s entornos de desarrollo. Por consi- E = 3,2 x (KLDC)'"~ Modelo simple de Boehm
guiente, dos resultados obtenidos de dichos modelos se E = 5,288 x (KLDC)',M7 Modelo Doty para KLDC > 9
deben utilizar con prudencia13.
TambiCn se han propuesto 10s modelos orientados a
5.7.1. La estructura de 10s modelos de estimaci6n PF. Entre estos modelos se incluyen:
E = - 13,39 + 0,0545 PF Modelo de Albretch
Y Gaffney
E = 60,62 x 7,728 x
x 10.' PF' Modelo de Kemerer
Un modelo de estimacion refleja la contidad de proyectos E = 585,7 + l5,l2 PF Modelo de Matson, Barnett
y Mellicharnp
a portir de donde se ha obtenido. Por consiguiente,
el modelo es susceptible ol dominio. Un ripido examen de 10s modelos listados anterior-
mente indica que cada uno produciri un resultado dife-
Un modelo comun de estimaci6n se extrae utilizando el rente14para el mismo valor de LDC y PF. La implicaci6n
analisis de regresi6n sobre 10s datos recopilados de pro- es clara. Los modelos de estimaci6n se deben calibrar
yectos de software anteriores. La estructura global de para necesidades locales.
tales modelos adquiere la forma de [MAT94]:
E =A +B x ( e ~ ) ~ (5.2)
donde A, B y C son constantes obtenidas empiricamen- Ninguno de estos modelos debeio ser oplicodo
te, E es el esfuerzo en personas-mes, y ev es la variable inodecuodomente o su entarno.
de estimacion (de LDC o PF). Ademis de la relacion
l 3 En general se deberia calibrar un rnodelo de estirnacion para las l 4 Esta referencia se fundarnenta en que estos modelos a menudo se
condiciones locales. El modelo se deberia ejecutar utilizando 10s resul- derivan de un nurnero relativamente pequeAo de proyectos solo en
tados de proyectos terminados. Los datos previstos por el modelo se unos cuantos dominios de la aplicacion.
deberian cornparar con 10s resultados reales, y la eficacia del modelo
(para condiciones locales) deberia ser evaluada. Si la concordancia
no es buena, 10s coeficientes del modelo se deben volver a calcular
utilizando datos locales.
C A P ~ T U L O5 P L A N I F I C A C I 6 N DE P R O Y E C T O S DE SOFTWARE
5.7.2. El modelo COCOMO una pantalla o informe) se clasifica en uno de 10s tres
Barry Boehm [BOE81], en su libro clasico sobre cceco- niveles de complejidad (esto es, basico, intermedio, o
nomia de la ingenieria del softwaren, introduce una jerar- avanzado) utilizando 10s criterios sugeridos por Boehm
quia de modelos de estirnacion de software con el [BOE96]. En esencia, la complejidad es una funci6n del
nombre de COCOMO, por Constructi~leCost Model numero y origen de las tablas de datos del cliente y ser-
(Modelo Constructivo de Coste). El modelo COCOMO vidor necesario para generar la pantalla o el informe y
original se ha convertido en uno de 10s modelos de esti- el numero de vistas o secciones presentadas como par-
macion de coste del software mis utilizados y estudia- te de la pantalla o del informe.
dos en la industria. El modelo original ha evolucionado
a un modelo de estimaci6n mas completo llamado Tipo d e objeto
Peso d e la cornplejidad )
COCOMO I1 [BOE 96, BOE 001. A1 igual que su pre- Basico
decesor, COCOMO I1 es en realidad una jerarquia de
modelos de estirnacion que tratan las Areas siguientes :
Modelo de composicion de aplicacion. Utilizado
durante las primeras etapas de la ingenieria del soft-
ware, donde el prototipado de las interfaces de usua-
rio, la interaction del sistema y del software, la TABLA 5.1. Factores de peso de la complejidad para tipos
evaluacion del rendimiento, y la evaluaci6n de la de objeto IBOE961.
madurez de la tecnologia son de suma importancia. Una vez que se ha determinado la complejidad, se
Modelo de fase de diseno previo. Utilizado una valora el numero de pantallas, informes, y componen-
vez que se han estabilizado 10s requisitos y que se tes de acuerdo con la Tabla 5.1. La cuenta de punto obje-
ha establecido la arquitectura basica del software. to se determina multiplicando el numero original de
Modelo de fase posterior a la arquitectura. Uti- instancias del objeto por el factor de peso de la tabla 5.1
lizado durante la construccion del software. y se suman para obtener la cuenta total de punto obje-
A1 igual que todos 10s modelos de estimaci6n del to. Cuando se va a aplicar el desarrollo basado en com-
software, el modelo COCOMO I1 descrito antes nece- ponentes o la reutilizaci6n de software en general, se
sita informaci6n del tamaiio. Dentro de la jerarquia del estima el porcentaje de reutilizacion (%reutilizaci6n) y
modelo hay tres opciones de tamaiio distintas: puntos se ajusta la cuenta del punto objeto:
objeto, puntos de funcion, y lineas de c6digo fuente. PON = (puntos objeto) x [(I00 - %reutilizacion)/100]
El modelo de composicion de aplicaci6n COCOMO donde PON significa ccpuntos objeto nuevos,,.
I1 utiliza 10s puntos objeto como se ilustra en 10s pkafos
siguientes. Deberia seiialarse que tambitn e s t h disponi-
~ Q u ees un ccpunto obieto))?
bles otros modelos de estirnacion mas sofisticados (utili-
zando PF y KLDC) que forman parte del COCOMO 11.
Para obtener una estimacion del esfuerzo basada en el
valor PON calculado, se debe calcular la ccproporci6n de
productividadn. La Tabla 5.2 presenta la proporcion de
Referenda web/ productividad para 10s diferentes niveles de experiencia
del desarrollador y de madurez del entomo de desarrollo.
Se puede obtener informoci6n detollodo sobre el
Una vez determinada la proporcion de productividad, se
COCOMO II, incluyendo softwore que puede descorgor, en
puede obtener una estimaci6n del esfuerzo del proyecto:
sunset.usc.edu/C0C0MOll/cocomo.html
Esfuerzo estimado = PON / PROD
Del mismo mod0 que 10s puntos de funci6n (Capi- En modelos COCOMO I1 mas avanzados15, se
tulo 4), el punto objeto es una medida indirecta de soft- requiere una variedad de factores de escala, conducto-
ware que se calcula utilizando el total de (1) pantallas res de coste y procedimientos de ajuste. Un estudio com-
(de la interface de usuario), (2) informes, y (3) compo- pleto de estos temas e s t h fuera del Ambit0 de este libro.
nentes que probablemente se necesiten para construir El lector interesado deberia consultar [BOEOO] o visi-
la aplicacion. Cada instancia de objeto (por ejemplo, tar el sitio web COCOMO 11.
l 5 Como se sefialo anteriormente, estos rnodelos hacen uso de las

cuentas de PF y KLDC para la variable tamafio.
INGENIERIA DEL S O F T W A R E . UN E N F O Q U E PRACTICO
sistemas". El parametro de productividad se puede ex-

M traer para las condiciones locales mediante datos histo-
Experiencia/capacidad baja Baja Normal Alta ricos recopilados de esfuerzos de desarrollo pasados.
del desarrollador
Madurezlcapacidad
del entorno yil Baja
Normal Alta
Se puede obtener information de las herramientos de

PROD 4 7 13 25 estimation del coste del software que se han desorrollodo
a partir de la ecuoci6n del software en www.qsm.com
TABLA 5.2. Proporciones de productividad para puntos
objeto [BOE961.
5.7.3. L a ecuacion del software Es importante seiialar que la ecuacion del software
tiene dos parametros independientes: (1) una estima-
La ecuacion del software [PUT921 es un modelo multiva-
ci6n del tamaiio (en LDC) y (2) una indicacion de la
riable dinfimico que asume una distribution especificadel
duracion del proyecto en meses o aiios.
esfuerzo a lo largo de la vida de un proyecto de desarrollo
Para simplificar el proceso de estimacion y utilizar
de software. El modelo se ha obtenido a partir de 10s datos
una forma rnis comlin para su modelo de estimacion,
de productividad para unos 4.000 proyectos actuales de
Putnam y Myers sugieren un conjunto de ecuaciones
software, un modelo de estimacion tiene esta forma:
obtenidas de la ecuacion del software. Un tiempo mini-
E = [LDC x B',"~/P l3 x (1 / t4) (5.3) mo de desarrollo se define como:
donde tmi, = 8,14 ( L D C / P ) ~en, ~meses
~ para tmrn> 6 meses (5.4a)
E = esfuerzo en personas-mes o personas-aiio, E = 180 B$ en personas-mes para E 2 20 personas-mes (5.4b)

t = duracion del proyecto en meses o aiios, Tenga en cuenta que t en la ecuacion (5.4b) se repre-
B = ccfactor especial de destrezas>>16, senta en aiios.
P = ccparimetro de productividad>>que refleja: Mediante las ecuaciones (5.4) con P = 12.000 (valor
recomendado para software cientifico) para el softwa-
Madurez global del proceso y de las pricticas
re de CAD estudiado anteriormente en este capitulo,
de gestion.
La amplitud hasta donde se utilizan correcta- t,,, = 8,14 (33.200 / I~.OOO)'.~'
mente las normas de la ingenieria del software. tmin= 12,6 meses
El nivel de 10s lenguajes de programacidn uti- E = 180 x 0,28 x (1,05)'
lizados. El estado del entorno del software. E = 58 personas-mes
Las habilidades y la experiencia del equipo del
software. Los resultados de la ecuaci6n del software se corres-
ponde favorablemente con las estimaciones desarrolla-
La complejidad de la aplicacion. das en la Section 5.6. Del mismo mod0 que el modelo
Los valores tipicos para el desarrollo del software COCOMO expuesto en la seccion anterior, la ecuacion
empotrado en tiempo real podrian ser P = 2.000; del software ha evolucionado durante la dCcada pasa-
P = 10.000 para telecomunicaciones y software de sis- da. Se puede encontrar un estudio de la versi6n exten-
temas; y P = 28.000 para aplicaciones comerciales de dida de este enfoque de estimacion en [PUT97].
En muchas Leas de aplicacion del software, a menu- componentes de software cctotalmente experimentado>>
do es rnis rentable adquirir el software de computado- o ccparcialmente experimentado>>(Consulte la Seccion
ra que desarrollarlo. Los gestores de ingenieria del 5.4.2), y entonces modificarse e integrarse para cum-
software se enfrentan con una decision desarrollar o plir las necesidades especificas, o (3) el software pue-
comprar que se puede complicar aun rnis con las opcio- de ser construido de forma personalizada por una
nes de adquisicion: (1) el software se puede comprar empresa externa para cumplir las especificaciones del
(con licencia) ya desarrollado; (2) se pueden adquirir comprador.
l 6 B s e incrementa lentamente a medida que crecen .la necesidad de l 7 Es importante destacar que el parametro de productividad puede
integracion, pruebas, garantia de calidad, documentacion y habilidad obtenerse empiricamente de 10s datos locales de un proyecto.
de gestion))[PUT92]. Para programas pequefios (KLDC = 5 a 15), B =
0,16. Para programas mayores de 70 KLDC, B = 0,39.
CAPfTULO 5 PLANIFICACION DE PROYECTOS DE SOFTWARE
Los pasos dados en la adquisicion del software se En el analisis final, la decision de desarrollar+om-
definen seg6n el sentido critico del software que se va prar se basa en las condiciones siguientes: (1) iLa fecha
a comprar y el coste final. En algunos casos (por ejem- de entrega del producto de software sera anterior que la
plo: software para PC de bajo coste) es menos caro com- del software desarrollado internamente? (2) isera el
prar y experimentar que llevar a cab0 una larga coste de adquisicion junto con el de personalizacion
evaluacidn de potenciales paquetes de software. Para menor que el coste de desarrollo interno del software?
productos de software mas caros, se pueden aplicar las (3) isera el coste del soporte externo (por ejemplo: un
directrices siguientes: contrato de mantenimiento) menor que el coste del
1. Desarrollo de una especificacion para la funci6n y soporte interno? Estas condiciones se aplican a cada una
rendimiento del software deseado. Definici6n de las de las opciones sefialadas anteriormente.
caracteristicas medibles, siempre que sea posible.
5.8.1. Creacion de un arbol de decisiones
Los pasos descritos anteriormente se pueden especifi-
car mediante tCcnicas estadisticas tales como el anali-
Hoy veces en 10s que el sohwore proporciono uno sis del drbol de decisidn [BOE89]. Por ejemplo, la
solucion ((perfecto))excepto poro olgunos ospectos Figura 5.6 representa un arbol de decision para un sis-
especioles de 10s que puede prescindir. En muchos cosos,
tema X basado en software. En este caso, la organiza-
jmerece lo peno vivir sin btos!
cion de la ingenieria del software puede (1) construir el
sistema X desde el principio; (2) reutilizar 10s compo-
2. Estimation del coste interno de desarrollo y la fecha nentes existentes de <<experienciaparciah para cons-
de entrega. truir el sistema; (3) comprar un producto de software
3a.Seleccion de tres o cuatro aplicaciones candidatos disponible y modificarlo para cumplir las necesidades
que cumplan mejor las especificaciones. locales; o (4) contratar el desarrollo del software a un
3b.Seleccion de componentes de software reutilizables vendedor externo.
que ayudaran e n l a construccion de la aplicacion iExiste un metodo sistematico para
requerida. ordenar las opciones relacionadas con
Desarrollo de una matriz de comparacion que presente la decision desarrollar-comprar?
la comparaci6n m a a una de las funciones clave. Alter-
nativarnente, realizar el seguimientode las pruebas de Si se va a construir un sistema desde el principio,
evaluaci6n para comparar el software candidato. existe una probabilidad del 70 por 100 de que el tra-
Evaluation de cada paquete de software o compo- bajo sea dificil. Mediante las tCcnicas de estimaci6n
nente segun la calidad de productos anteriores, estudiadas en este capitulo, el planificador del pro-
soporte del vendedor, direccion del producto, repu- yecto estima que un esfuerzo de desarrollo dificil cos-
tacion, etc. tara £450.000. Un esfuerzo de desarrollo <<simple>> se
Contacto con otros usuarios de dicho software y peti- estima que cueste £380.000. El valor esperado del cos-
cion de opiniones. te, calculado a lo largo de la rama del Arb01 de deci-
sion es:
£380.000
coste esperado = C (probabilidad del cam in^)^ x (coste esti-
£450.000
mado del camino)
Construccion
Cambios menores U75.000 donde i es el camino del arbol de decision. Para el
camino construir,
coste = 0,30 (f380K) + 0,70 (5450K)
Sistema X
= 5429K
importantes TambiCn se muestran 10s otros caminos del kbol de
£490.000
decision, 10s costes proyectados para la reutilizacion,
\\ Cambios menores c?qn nnn
compra y contrato, bajo diferentes circunstancias. Los
costes esperados de estas rutas son:
Cambios
£400.000 = 0,40 (5275K) + 0,60 [0,20(&310K)
coste esperad~,~,~,~,~~,
+ 0,80(£490K)]= 5382K
\ importantes (0,30)
coste esperado = 0,70(&210K)+ 0,30(&400K)= 5267K
£350.000
coste esperadocan,,, = 0,60(5350K)+ 0,40(&500K)]= 5410K
£ 500.000
Con cambios (0,401
Seg6n la probabilidad y 10s costes proyectados que
FIGURA 5.6. ~ r b ode
l decision para apoyar la decision se han sefialado en la Figura 5.6, el coste mas bajo espe-
desarrollar-comprar. rado es la opci6n crcompra>>.
INGENIERiA DEL SOFTWARE. UN ENFOQUE PRACTICO
con un tercero, quien hace el trabajo a bajo coste ase-
3
Referencia Web
Se puede encontrar un tutorial excelente sobre el analisis
del 6rbol de decisibn en
gurando una alta calidad. El trabajo de software lleva-
do dentro de la compaiiia se reduce a una actividad de
gestion de contratos.
www.demon.co.uk/mindtool/dectree.html
Sin embargo, es importante seiialar que se deben con-

siderar muchos criterios -no solo el coste- durante
el proceso de toma de decisiones. La disponibilidad, la
experiencia del desarrollador/vendedor/contratante, la La decisi6n de contratar fuentes extemas puede ser
conformidad con 10s requisitos, la politica cclocal~~,y la estrategica o tactica. En el nivel estratkgico, 10s gesto-
probabilidad de cambios son solo uno de 10s pocos cri- res tienen en consideracion si una parte importante de
terios que pueden afectar la ultima decision para cons- todo el trabajo del software puede ser contratado a otros.
truir, volver a utilizar o contratar. En el nivel thctico, un jefe de proyecto determina si algu-
nas partes o todo el proyecto es aconsejable realizarlo
5.8.2. Subcontrataci6n (outsourcing) mediante subcontratacibn.
Mas pronto o m b tarde toda compaZa que desarrolla soft- Con independencia de la amplitud del enfoque, la
ware de computadora hace una pregunta fundamental: decision de elegir outsourcing es a menudo financiera.
eciExiste alguna forma por la que podamos conseguir a Un estudio detallado del analisis financier0 de la deci-
bajo precio el software y 10s sistemas que necesitamos?,, sidn del outsourcing esta fuera del ambito de este libro
La respuesta a esta pregunta no es simple, y las discusio- y se reserva mejor para otros (por ejemplo: [MIN95]).
nes sobre esta cuesti6n dan como respuesta una simple Sin embargo, merece la pena realizar un repaso de 10s
palabra: subcontrataci6n (outsourcing). pros y 10s contras de la decisi6n.
En el lado positivo, 10s ahorros de coste se pueden
lograr reduciendo el numero de personas y las instala-
Referencia web/ '~ ciones (por ejemplo: computadoras, infraestructura)que
10s apoyan. En el lado negativo, una compaiiia pierde
Se puede encontrar informatihi 661 (documentos, enlaces)
acerca del outsourcing en www.outsourcing.com control sobre el software que necesita. Como el soft-
ware es una tecnologia que diferencia sus sistemas, ser-
El concept0 outsourcing es extremadamente simple. vicios, y productos, una compaiiia corre el riesgo de
Las actividades de ingenieria del software se contratan poner su destino en manos de un tercero.
Las tecnicas de descomposici6n y 10s modelos empiri- (Capitulo 2) y se especifica el conjunto de tareas de
cos de estimaci6n descritos en las secciones anteriores se ingenieria del software.
pueden implementar con software.Las herramientas auto- 3. Prediccion de 10s niveles de la plantilla. Se espe-
maticas de estimaci6n permiten a1 planificador estimar cifica el numero de personas disponibles para reali-
costes y esfuerzos, asi como llevar a cab0 analisis del tipo zar el trabajo. Esto es muy importante, puesto que la
ccquk pasa sin con importantes variables del proyecto, relaci6n entre las personas disponibles y el trabajo
tales como la fecha de entrega o la selecci6n de perso- (esfuerzo previsto) no es muy lineal.
nal. Aunque existen muchas herramientas automaticas de 4. Prediccion del esfuerzo del software. Las herra-
estimacion, todas exhiben las mismas caracteristicas gene- mientas de estimaci6n utilizan uno o mas modelos
rales y todas realizan las seis funciones genericas mos- (por ejemplo, Seccidn 5.7) que relacionan el tamaiio
tradas a continuaci6n [JON96]: de las entregas del proyecto con el esfuerzo necesa-
1. Dimensionamiento de las entregas del proyecto. rio para producirlas.
Se estima el cctamaiio)) de uno o m6s productos de 5. Prediccion del coste del software. Dado 10s resul-
software. Los productos incluyen la representacion tados del paso 4,los costes pueden calcularse asig-
extema del software (por ejemplo, pantallas, infor- nando proporciones del trabajo a las actividades del
mes), el software en si (por ejemplo, KLDC), su fun- proyecto seiialadas en el paso 2.
cionalidad (por ejemplo, puntos de funcidn), y la 6. Prediccion de la planificacion del software. Cuando
informaci6n descriptiva (por ejemplo, documentos). se conoce el esfuerzo, 10s niveles de la plantilla y las
2. Selection de las actividades del proyecto. Se selec- actividades del proyecto, se puede realizar un borra-
ciona el marco de trabajo del proceso adecuado dor de la planificacidn asignando el trabajo a travks
C A P ~ T U L O5 P L A N I F I C A C I ~ ND E P R O Y E C T O S DE S O F T W A R E
de actividades de ingenieria del software basadas en Cuando se aplican distintas herramientas de esti-
modelos recomendados para la distribuci6n del maci6n a 10s mismos datos del proyecto, se observa
esfuerzo (Capitulo 7). una variaci6n relativamente grande entre 10s resulta-
dos estimados. Pero lo que es mas importante, a veces
10s valores son bastante diferentes de 10s valores rea-
les. Esto refuerza la idea de que 10s resultados obte-
nidos por las herramientas de estimaci6n se deben usar
s610 como ccpunto de partida>>para la obtenci6n de
estimaciones -no como 6nica fuente para la estima-
Herrornientas Cose. ci6n-.
El planificador del proyecto de software tiene que esti- de personas-mes requeridas para cada actividad de inge-
mar tres cosas antes de que comience el proyecto: cuan- nieria del software. Las tecnicas empiricas usan expre-
to durara, cuhto esfuerzo requerira y cuanta gente estara siones empiricamente obtenidas para el esfuerzo y para
implicada. Ademas, el planificador debe predecir 10s el tiempo, con las que se predicen esas magnitudes del
recursos (de hardware y de software) que va a requerir, proyecto. Las herramientas automaticas implementan
y el riesgo implicado. un determinado modelo empirico.
El enunciado del ambit0 ayuda a desarrollar estima- Para obtener estimaciones exactas para un proyecto,
ciones mediante una o varias de las tecnicas siguientes: generalmente se utilizan a1 menos dos de las tres tecni-
descomposici6n, modelos empiricos y herramientas cas referidas anteriormente. Mediante la comparaci6n
automaticas. Las tkcnicas de descomposici6n requieren y la conciliaci6n de las estimaciones obtenidas con las
un esbozo de las principales funciones del software, diferentes tecnicas, el planificador puede obtener una
seguido de estimaciones (1) del n6mero de LDC's, (2) estimaci6n mas exacta. La estimaci6n del proyecto de
de 10s valores seleccionados dentro del dominio de la software nunca sera una ciencia exacta, pert la combi-
informaci6n, (3) del n6mero de personas-mes requeri- naci6n de buenos datos hist6ricos y de tecnicas siste-
das para implementar cada funcion, o (4) del n6mero maticas pueden mejorar la precisi6n de la estimaci6n.
[BEN921 Bennatan, E. M., Sofmare Project Management: A [MAH96] Mah, M., Quantitive Software Management, Inc.,
Practitioner's Approach, McGraw-Hill, 1992. private communication.
[BOE811 Boehm, B., Sofmare Engineering Economics, Pren- [MAT941 Matson, J., B. Barrett y J. Mellichamp, (<Software
tice-Hall. 1981. Development Cost Estimation Using Function Points)>,
[BOE89] Boehm, B., Risk Management, IEEE Computer lEEE Trans. Software Engineering, vol. 20, n.P 4, Abril
Society Press, 1989. 1994, pp. 275-287.
[BOE96] Boehm, B., <<Anchoringthe Software Process,,, IEE [MIN95] Minoli, D., Analizing Outsourcing, McGraw-Hill,
Sofmare, vol. 13, n.", Julio 1996, pp. 73-82. 1995.
[BOEOO] Boehm, B., et al., Software Cost Estimation in [PHI981 Phillips, D., The Software Project Manager's Hand-
COCOMO 11, Prentice Hall, 2000. book, IEEE Computer Society Press, 1998.
[BR075] Brooks, F., The Mythical Man-Month, Addison- [PUT921 Putnam, L., y W. Myers, Measures for Excellence,
Wesley, 1975. Yourdon Press, 1992.
[GAU89] Gause, D. C., y G. M. Weinberg, Exploring Requi- [PUT97a] Putnam, L., y W. Myers, CHOWSolved is the Cost
rements: Quality Before Design, Dorset House, 1989. Estimation Problem,,, IEEE Sofh~are,Noviembre 1997,
[H0091] Hooper, J. W. E., y R. 0 . Chester, Software Reuse: pp. 105-107.
Guidelines and Methods, Plenum Press, 1991. [PUT97b] Putnam, L., y W. Myers, Industrial Strength Soft-
[JON961 Jones, C., <<HowSoftware Estimation Tools Work,,, ware: Effective Management Using Measurement, IEEE
American Programmer, vol. 9, n." 7, Julio 1996, pp. 19-27. Computer Society Press, 1997.
INGENlERfA DEL SOFTWARE. U N ENFOQUE P R ~ C T I C O
5.1. Suponga que es el gestor de proyectos de una compaiiia damente 80 componentes de software. Asuma complejidad
que construye software para productos de consumo. Ha con- ccmedia)) y maduracion desarrollador/entomo media. Utilice
tratado una construcci6n de software para un sistema de segu- el modelo de composicion de aplicacion con puntos objeto.
ridad del hogar. Escriba una especificacion del Bmbito que 5.7. Utilice la ccecuacion del softwares para estimar el soft-
describa el software. Asegdrese de que su enunciado del ambi- ware del sistema de seguridad del hogar. Suponga que las Ecua-
to sea limitado. Si no esta familiarizado con sistemas de segu- ciones (5.4) son aplicables y que P = 8.000.
ridad del hogar, investigue un poco antes de comenzar a
5.8. Compare las estimaciones de esfuerzo obtenidas de 10s
escribir. Alternativa: sustituya el sistema de seguridad del
Problemas 5.5 y 5.7. Desarrolle una estimacion simple para
hogar por otro problema que le sea de inter&.
el proyecto mediante una estimacion de tres puntos. LCual es
5.2. La complejidad del proyecto de software se trata breve- la desviacion estfindar?, y jc6mo afecta a su grado de certeza
mente en la Seccion 5.1. Desarrolle una lista de las caracte- sobre la estimacion?
risticas de software (por ejemplo: operation concurrente, salida
grafica, etc.), que afecte a la complejidad de un proyecto. DC 5.9. Mediante 10s resultados obtenidos del Problema 5.8, deter-
prioridad a la lista. mine si es razonable esperar que el resultado se pueda cons-
truir dentro de 10s seis meses siguientes y cuantas personas se
5.3. El rendimiento es una consideracion importante durante
tendrian que utilizar para terminar el trabajo.
la planificacibn. Discuta si puede interpretar el rendimiento de
otra manera. dependiendo del area de aplicacion del software. 5.10. Desarrolle un modelo de hoja de calculo que implemente
5.4. Haga una descomposicion de las funciones software
una tCcnica de estimacion o mas, descritas en el capitulo. Alter-
para el sistema de seguridad del hogar descrita en el Pro- nativamente, obtenga uno o mas modelos directos para la esti-
blema 5.1. Estime el tamafio de cada funci6n en LDC. Asu- maci6n desde la web.
miendo que su organizacion produce 450LDC/pm con una 5.11. Para un equipo deproyecto: Desarrolle una herramien-
tarifa laboral de $7.000 por persona-mes, estime el esfuer- ta de software que implemente cada una de las tecnicas de esti-
zo y el coste requerido para construir el software utilizan- macibn desarrolladas en este capitulo.
do la tecnica de estimacion basada en LDC que se describe 5.12. Parece extraiio que las estimaciones de costes y plani-
en la Secci6n 5.6.3. ficaciones temporales se desarrollen durante la planificacion
5.5. Utilizando las medidas de punto de funcion de tres dimen- del proyecto de software -antes de haber realizado un ana-
siones que se describe en el Capitulo 4, calcule el ndmero de PF lisis de requisitos o un diseiio detallad*. ~ P o que
r Cree que
para el software del sistema de seguridad del hogar, y extraiga las se hace asi? existe en circunstancias en las que no deba pro-
estimaciones del esfuerzo y del coste mediante la tecnica de esti- cederse de esta forma?
macion basada en PF que se describe en la Section 5.6.4. 5.13. Vuelva a calcular 10s valores esperados seiialados en el
5.6. Utilice el modelo COCOMO I1 para estimar el esfuerzo arb01 de decision de la Figura 5.6 suboniendo que todas las
necesario para construir software para un simple ATM que ramas tienen una probabilidad de 50-50. ~ P oquCr cambia esto
produzca 12 pantallas, 10 informes, y que necesite aproxima- su decision final?
La mayoria de 10s libros de gestion de proyectos de softwa- empiricos para la estimacion del software. Estos libros propor-
re contienen estudios sobre la estimacion de proyectos. Jones cionan un anilisis detallado de datos que provienen de cientos
(Estimating Software Costs, McGraw Hill, 1998) ha escrito de proyectos de software. Un libro excelente de DeMarco (Con-
el tratado mas extenso sobre la estimacion de proyectos pu- trolling Software Projects, Yourdon Press, 1982) proporciona
blicado hasta la fecha. Su libro contiene modelos y datos apli- una profunda y valiosa vision de la gestion, medicion y esti-
cables a la estimacion del software en todo el dominio de la maci6n de proyectos de software. Sneed (Software Engineering
aplicacion. Roetzheim y Beasley (Software Project Cost and Management, Wiley, 1989) y Macro (Software Engineering:
Schedule Estimating: Best Practices, Prentice-Hall, 1997) Concepts and Management, Prentice-Hall, 1990) estudian la
presentan varios modelos dtiles y sugieren las directrices paso estimacibn del proyecto de software con gran detalle.
a paso para genera las estimaciones mejores posibles. La estimacion del coste de lineas de codigo es el enfoque
Los libros de Phillips [PHI98], Bennatan (On Time, Wit- miis comdnrnente utilizado. Sin embargo, el impact0 del para-
hin Budget: Software Project Management Practices and digma orientado a objetos (consulte la Parte Cuarta) puede
Techniques, Wiley, 1995), Whitten (Managing Software Deve- invalidar algunos modelos de estimacion. Lorenz y - ~ i d d
lopment Projects: Formula for Success, Wiley, 1995), Well- (Object-Oriented Software Metrics, Prentice-Hall, 1994)
man (Software Costing, Prentice-Hall, 1992), Londeix (Cost y Cockburn (Surviving Object-Oriented Projects, Addi-
Estimationfor Software Development, Addison-Wesley, 1987) son-Wesley, 1998) estudian la estimacion para sisternas orien-
contienen informacion dtil sobre la planificacion y la esti- tados a objetos.
macibn de proyectos de software. En Intemet e s t h disponibles una gran variedad de fuen-
El tratarniento detallado de la estirnacidn del coste de soft- tes de informacion sobre la planificacion y estimacion del
ware de Putnam y Myers ([PUT921 y [PUT97b]), y el libro de software. Se puede encontrar una lista actualizada con refe-
Boehrn sobre la economia de la ingenieria del software ([BOE81] rencias a sitios (paginas) web que son relevantes para la esti-
y COCOMO I1 [BOEOO]) describen 10s modelos de estimacion macion del software en http://www.pressman5.com.
Palabrae c l a v e
E
N su libro sobre anlilisis y gesti6n del riesgo, Robert Charette [CHA89] presenta la
Componentes y siguiente definicion de riesgo:
Controladores ..... .I01
Estrategias de En primer lugar, el riesgo afecta a 10s futuros acontecimientos. El hoy y el ayer estin mris
Riesgo ............ -98 all6 de lo que nos pueda preocupar, pues ya estamos cosechando lo que sembramos previamente
Evaluacih ........ .I03 con nuestras acciones del pasado. La pregunta es, podemos, por tanto, canlbiando nuestras
Exposicibn a1 acciones actuales, crear una oportunidad para una situacicin diferente y, con suerte, mejor para
Riesgo ........... .I03 nosotros en el futuro. Esto significa, en segundo lugar, que el riesgo implica cambio, que pue-
Identifitacibn.. ......99 de venir dado por cambios de opini6n. de acciones, de lugares ... [En tercer lugar,] el riesgo
implica election, y la incertidumbre que entrafia la elecci6n. Por tanto, el riesgo, como la muer-
Plan ASGR .........I07
te y 10s impuestos, es una de las pocas cosas inevitables en la vida.
Proyecciin ........ .I01 Cuando se considera el riesgo en el context0 de la ingenieria del software, 10s tres pilares
Reducciin.. ....... .I05 conceptuales de Charette se hacen continuamente evidentes. El futuro es lo que nos preocupa
Refinamienta...... .I04 - i q ~ 6 riesgos podrian hacer que nuestro proyecto fracasara?-. El cambio es nuestra preocu-
Seguridad y paci6n jc6m0 afectarrin 10s cambios en 10s requisites del cliente, en las tecnologias de d e w
Peligros ..........,106 rrollo, en las computadoras a las que va dirigido el proyecto y a todas las entidades relacionadas
Supervisidn ....... .lo5 con 61, al cumplimiento de la planificaci6n temporal y a1 Cxito en general?. Para terrninar, debe-
Tabla de riesgo .... .I01 mos enfrentarnos a decisiones p i q u e mCtodos y herramientas deberiamos emplear, cuinta gen-
te deberia estar implicada, cuinta importancia hay que darle a la calidad?--.
iQu6 es? El a n d i s i s y la gesti6n del &POT

q u B er importante? Pensemos en babilidad y del impacto. Por dtimo, s e
riesgo son una serie d e pasos que el lema de 10s boys scout: uestar p r e p - desarrolla un plan para gestionar
ayudan nl e q u i p del software n com- radosn. El software es una empresa difi- uquellos riesgos con gran probabilidad
prender y a gestionar la incertidum- cil. Muchas m a s pueden ir mal. y e impacto.
bre. Un proyecto d e software puede francamente,u menudo van mal. Estaes &Cue1es el product0 obtenido? Se
estar lleno de problemas. Un riesgo la r d n para estar preparados --corn- realiza un Plan de Reduccidn, Super-
e s un problema potencial -puede prendiendo los riesgos y tomando las visi6n y Gesti6n del Riesgo (RSGR) o
dcurrir o no-. Pero sin lener e n cuen- medidas procrctivas para evitarlo o ges- un infmme de riesgos.
t a el resul!ado. realmente e s una tionarlo- e s un elemento clave de una LC6mo puedo estar seguro de qre
buena idea identiiicarlo, evaluar s u buena gesti6n de proyettos d e software. lo he hecho correctamente? Los
probabilidad d e aparicibn, estimar &Crr&lesson 16s pasos? El reconoci- riesgos analizados y gestionados debe-
s u impacto, y establecer un plan d e miento de que algo puede ir ma1 e s el rIan derivarse del estudio del personal,
contingencia por s i ocurre el proble- primer paso, llamado identilicaci6n del del producto, del proceso y del proyec-
ma. riesgo. A continuaci6n. cada riesgo es to. El RSGR d e b ser revisado mientras
8Quien lo hace? Todos 10s que estQn analizado para determinat la probabi- el proyecto s e realiza para usegurar
involucrados e n el proceso del softwa- lidad de que pueda ocurrir y el daiio que 10s riesgos est6n siendo conirola-
re --gestores, ingenieros de software y que puede causar s i ocurre. Una vez dos hasta la iecha. Los planes de con-
clientes- participan en el an6lisis y establecida esta informaclbn, se prio- tingencia para la gesticin del riesgo
la gestidn del riesgo. rizan 10s riesgos, en funcidn de la pro- deben ser realistas.
Peter Drucker [DRU75] dijo una vez: c<Mientrasque es i n W intentar eliminar el riesgo y
cuestionable el poder minimizarlo, es esencial que 10s riesgos que se tomen Sean 10s riesgos
adecuadosu. Antes de poder identificar 10s ccriesgos adecuados>>a tener en cuenta en un pro-
yecto de software, es importante poder identificar todos 10s riesgos que Sean obvios a jefes de
proyecto y profesionales del software.
Las estrategias se han denominado humoristicamente te, en caso de que pudieran convertirse en problemas
ccEscuela de gestion del riesgo de Indiana Jones>> reales. Pero lo mas frecuente es que el equipo de soft-
[TH092]. En las peliculas, Indiana Jones, cuando se ware no haga nada respecto a 10s riesgos hasta que algo
enfrentaba a una dificultad insuperable, siempre decia, va mal. DespuCs el equip0 vuela para corregir el pro-
NO te preocupes, pensark en alga!>>. Nunca se preo- blema rapidamente. Este es el mCtodo denominado a
cupaba de 10s problemas hasta que ocurrian, entonces menudo cede bomberos>>.Cuando falla, <<lagestion de
Indy reaccionaba de alguna manera heroica. crisis>>[CHA92] entra en accion y el proyecto se encuen-
tra en peligro real.
Una estrategia considerablemente mas inteligente
para el control del riesgo es ser proactivo. La estrate-
os octivamente, ellos le gia proactiva empieza mucho antes de que comiencen
ted. 10s trabajos tCcnicos. Se identifican 10s riesgos poten-
ciales, se evalua su probabilidad y su impacto y se
establece una prioridad segun su importancia. Des-
puks, el equipo de Software establece un plan para
Desgraciadamente, el jefe del proyecto de software controlar el riesgo. El primer objetivo es evitar el ries-
normalmente no es Indiana Jones y 10s miembros de su go, per0 como no se pueden evitar todos 10s riesgos,
equipo no son sus fiables colaboradores. Sin embargo, el equipo trabaja para desarrollar un plan de contin-
la mayoria de 10s equipos de software confian solarnente gencia que le permita responder de una manera efi-
en las estrategias de riesgo reactivas. En el mejor de 10s caz y controlada. A lo largo de lo que queda de este
casos, la estrategia reactiva supervisa el proyecto en pre- capitulo, estudiamos la estrategia proactiva para el
vision de posibles riesgos. Los recursos se ponen apar- control de riesgos.
Aunque ha habido amplios debates sobre la definicion cion y organization), recursos, cliente y requisitos y su
adecuada para riesgo de software, hay acuerdo comun impacto en un proyecto de software. En el Capitulo 5, la
en que el riesgo siempre implica dos caracteristicas complejidad del proyecto, tamafio y el grado de incerti-
[HIG95]: dumbre estructural fueron tambikn definidos como fac-
Incertidurnbre: el acontecimiento que caracteriza a1 tores (y estimados) de riesgo del proyecto.
riesgo puede o no puede ocurrir; por ejemplo, no hay Los riesgos te'cnicos amenazan la calidad y la plani-
riesgos de un 100 por 100 de probabilidadl. ficacion temporal del software que hay que producir. Si
un riesgo tkcnico se convierte en realidad, la imple-
Pe'rdida: si el riesgo se convierte en una realidad,
mentacion puede llegar a ser dificil o imposible. Los
ocurriran consecuencias no deseadas o pCrdidas.
riesgos tCcnicos identifican problemas potenciales de
Cuando se analizan 10s riesgos es importante cuan- disefio, implernentacion, de interfaz, verificacion y de
tificar el nivel de incertidumbre y el grado de pkrdidas mantenimiento. Ademas, las ambigiiedades de especi-
asociado con cada riesgo. Para hacerlo, se consideran ficaciones, incertidumbre tkcnica, tCcnicas anticuadas
diferentes categorias de riesgos. y las crtecnologias punts>> son tambiCn factores de ries-
go. Los riesgos tCcnicos ocurren porque el problema es
iQue tip0 de riesgos es problable mas dificil de resolver de lo que pensabamos.
que nos encontremos en el Los riesgos del negocio amenazan la viabilidad del
software que se construye? software a construir. Los riesgos del negocio a menudo
ponen en peligro el proyecto o el producto. Los candi-
Los riesgos del proyecto amenazan a1 plan del pro- datos para 10s cinco principales riesgos del negocio son:
yecto; es decir, si 10s riesgos del proyecto se hacen rea- (1) construir un producto o sistema excelente que no
lidad, es probable que la planificacion temporal del quiere nadie en realidad (riesgo de mercado); (2) cons-
proyecto se retrase y que 10s costes aumenten. Los ries- truir un producto que no encaja en la estrategia comer-
gos del proyecto identifican 10s problemas potenciales de cia1 general de la compafiia (riesgo estratkgico); (3)
presupuesto, planificacion temporal, personal (asigna- construir un producto que el departamento de ventas no
I Un riesgo del I00 por 100 es una limitacion del proyecto de soft-
ware.
C A P ~ T U L O6 ANALISIS Y G E S T I 6 N D E L R I E S G O
sabe corn0 vender; (4) perder el apoyo de una gestion Otra categorizaci6n general de 10s riesgos ha sido p r e
experta debido a cambios de enfoque o a cambios de puesta por Charette [CHA89]. Los riesgos conocidos son
personal (riesgo de direccion); (5) perder presupuesto todos aquellos que se pueden descubrir despuCs de una
o personal asignado (riesgos de presupuesto). Es extre- cuidadosa evaluacion del plan del proyecto, del entomo
madamente importante recalcar que no siempre fun- tCcnico y comercial en el que se desarrolla el proyecto y
ciona una categorization tan sencilla. Algunos riesgos otras fuentes de informaci6n fiables (por ejemplo: fechas
son simplemente imposibles de predecir. de entrega poco realistas, falta de especificacion de requi-
sitos o de ambito del software, o un entorno pobre de
desarrollo). Los riesgos predecibles se extrapolan de la
u~i
tcr
: experiencia en proyectos antenores (por ejemplo: cam-
Bn dla,] d i e se permite el luio de conocer ton bio de personal, mala comunicaci6n con el cliente, dis-
no contengo ninguno sorpreso, y minucion del esfuerzo del personal a medida que atienden
peticiones de mantenimiento). Los riesgos impredecibles
son el comodin de la baraja. Pueden ocurrir, per0 son
extremadamente dificiles de identificar por adelantado.
La identificacibn del riesgo es un intento sistemati- Impacto en el negocio: riesgos asociados con las limi-
co para especificar las amenazas a1 plan del proyecto taciones impuestas por la gestion o por el mercado.
(estimaciones, planificacion temporal, carga de recur- Caracteristicas del cliente: riesgos asociados con la
sos, etc.). Identificando 10s riesgos conocidos y prede- sofisticacion del cliente y la habilidad del desarro-
cibles, el gestor del proyecto da un paso adelante para llador para comunicarse con el cliente en 10s momen-
evitarlos cuando sea posible y controlarlos cuando sea tos oportunos.
necesario. Definicibn del proceso: riesgos asociados con el
grado de definicion del proceso del software y su
seguimiento por la organization de desarrollo.
Entorno de desarrollo: riesgos asociados con la dis-
Aunque 10s riesgos genericos son irnportontes o tener en
cuento, hobituolrnente 10s riesgos especificos del producto ponibilidad y calidad de las herramientas que se van
provocon lo rnoyorio de 10s dolores de cobezo. Fste a emplear en la construcci6n del producto.
convencido 01 invertir el tiernpo en identificor tontos Tecnologia a construir: riesgos asociados con la com-
riesgos especificos del producto corno seo posible. plejidad del sistema a construir y la tecnologia punta
que contiene el sistema.
Existen dos tipos diferenciados de riesgos para cada Tamaiio Y experiencia de la plantilla: riesgos asocia-
categoria presentada en la Seccion 6.2: riesgos generi- dos con la experiencia tCcnica y de proyectos de 10s
cos y riesgos especificos del producto. Los riesgos gene'- ingenieros del software que van a realizar el trabajo.
ricos son una arnenaza potencial para todos 10s proyectos
de software. Los riesgos especljclcos de producto so10
10s pueden identificar 10s que tienen una clara vision de
la tecnologia, el personal y el entomo especifico del pro-
yecto en cuestion. Para identificar 10s riesgos especifi-
cos del producto, se examinan el plan del proyecto y la
declaracion del ambit0 del software y se desarrolla una Listo de comprobocibn de elementos del riesgo.
respuesta a la siguiente pregunta: <<iQuC caractensticas
especiales de este producto pueden estar amenazadas La lista de comprobaci6n de elementos de riesgo pue-
por nuestro plan del proyecto?>> de organizarse de diferentes maneras. Se pueden res-
ponder a cuestiones relevantes de cada uno de 10s temas
Un metodo para identificar riesgos es crear una lis- apuntados anteriormente para cada proyecto de soft-
ta de comprobacibn de elementos de riesgo. La lista ware. Las respuestas a estas preguntas permiten a1 pla-
de comprobacion se puede utilizar para identificar ries- nificador del proyecto estimar el impact0 del riesgo. Un
gos y se centra en un subconjunto de riesgos conoci- formato diferente de lista de comprobacion de elemen-
dos y predecibles en las siguientes subcategorias tos de riesgo contiene simplemente las caracteristicas
genericas: relevantes para cada subcategoria genCrica. Finalmen-
Tarnafiodelproducto: riesgos asociados con el tamaiio te, se lista un conjunto de <<componentesy controlado-
general del software a construir o a modificar. res del riesgo,, [AFCSS] junto con sus probabilidades
I N G E N I E R ~ ADEL SOFTWARE. UN E N F O Q U E PRACTICO
de aparicion. Los controladores del rendimiento, el tores de proyectos de software expertos de diferentes
soporte, el coste y la planificacion temporal del proyecto partes del mundo [KEI98]. Las preguntas estin orde-
se estudian como respuesta a preguntas posteriores. nadas por su importancia relativa para el Cxito de un
Se ha propuesto un gran numero de listas de com- proyecto.
probacion para el riesgo del proyecto de software en 10s
textos (por ejemplo, [SEI93], [KAR96]). Estos propor- iCorre un riesgo grave el proyecto de
cionan una vision util de riesgos genkricos para pro- software en el que estamos trabajando?
yectos de software y deberian utilizarse cada vez que
se realice el anilisis y la gesti6n del riesgo. Sin embar-
go, se puede utilizar una lista de preguntas relativamente 1. i S e han entregado 10s gestores del software
pequeiia para proporcionar una indicacion preliminar y clientes formalmente para dar soporte a1 pro-
de cuando un proyecto es <<arriesgado>>. yecto?
2. iEsthn completamente entusiasmados 10s usuarios
finales con el proyecto y con el sistema/producto a
construir?
3. iHan comprendido el equipo de ingenieros de soft-
ware y 10s clientes todos 10s requisitos?
4. iHan estado 10s clientes involucrados por completo
en la definition de 10s requisitos?
6.3.1. Evaluaci6n Global del Riesgo del Proyecto
Las siguientes preguntas provienen de 10s datos del ries-
5. ti en en 10s usuarios finales expectativas realistas?
go obtenidos mediante las encuestas realizadas a ges- 6. iEs estable el hmbito del proyecto?
RENDlMlENTO I SOPORTE
Dejar de cumplir 10s requisitos provocaria Malos resultados en un aumento de costes y retrasos de la
el fallo de la mision
significativa para responde o no

no alcanzar admite soporte excedidos
el rendimiento tecnico
Dejar de cumplir 10s requisitos degradaria Malos resultados en retrasos operativos y/o
el rendimiento del sistema hasta donde aumento de coste con un valor esperado
el exito de la mision es cuestionable de f100.000 a £500.000
AIgunos recortes de 10s 1 Posibles retrasos
en el rendimiento en modificaciones
Dejar de cumplir 10s requisitos provocaria

excesos del presupuesto I
recursos financieros, posibles en la fecha de entrega
I
Los costes, impactos y/o retrasos recuperables
la degradacion de la mision secundaria
MARGINAL
De minima a pequena El soporte
reduccion en el del software
rendimiento tecnico responde
Dejar de cumplir 10s requisitos provocaria Los errores provocan impactos minimos en el coste y/o
inconvenientes o impactos no operativos planificacion temporal con un valor esperado de menos
DESPRECIABLE
en el rendimiento de dar soporte

tecnico
Nota : (1) Posibles consecuencias de errores o defectos del software no detectados.

(2) Posibles consecuencias si el resultado deseado no se consigue.
FIGURA 6.2. Evaluation del irnpacto [BOE89].

C A P ~ T U L O6 ANALISIS Y GESTI6N DEL RIESGO
7. ~ T i e n eel ingeniero de software el conjunto ade- riesgo de la planificaci6n temporal: el grado de incer-
cuado de habilidades? tidumbre con que se podri mantener la planificacion
8. iSon estables 10s requisitos del proyecto? temporal y de que el producto se entregue a tiempo.
9. iTiene experiencia el equipo del proyecto con la El impacto de cada controlador del riesgo en el com-
tecnologia a implementar? ponente de riesgo se divide en cuatro categorias de impac-
to -despreciable, marginal, critico y catastrofico-.
10. iEs adecuado el numero de personas del equipo del Como muestra la Figura 6.1 [BOE89], se describe una
proyecto para realizar el trabajo? caracterizaci6n de las consecuenciaspotenciales de erro-
11. iEsttin de acuerdo todos 10s clientes/usuarios en la res (filas etiquetadas con 1) o la imposibilidad de conse-
importancia del proyecto y en 10s requisitos del sis- guir el producto deseado (filas etiquetadas con 2). La
tema/producto a construir? categoria de impacto es elegida bastindose en la caracte-
rizacion que mejor encaja con la descripci6n de la tabla.
Referencia web/ ' -

Riesgos robabilidad mpacto RSGR
((Un rodor del riesgo)) es uno base de dotos de gestibn de
riesgo que oyudo o 10s gestores del proyetto a identificor, --
priorizor y tomunicor 10s riesgos del proyecto. Se puede La estimacidn del tamaio puedc 2
ser significativamente baja
encontror en www.spmn.com/rsktrkr.html
Mayor nljmero de usuarios 3
de 10s previstos
Menos reutilizacion 2
6.3.2. Componentes y controladores del riesgo de la prevista
Las Fuerzas ACreas de Estados Unidos [AFC88] han Los usuarios finales 3
se resisten al sistema
redactado un documento que contiene excelentes direc-
trices para identificar riesgos del software y evitarlos. La fecha de entrega estara 2
muy ajustada
El enfoque de las Fuerzas ACreas requiere que el ges- Se perderan 10s presupuestos 1
tor del proyecto identifique 10s controladores del ries- El cliente cambiara 2
go que afectan a 10s componentes de riesgo del software 10s requisitos
-rendimiento, coste, soporte y planificacion tempo- La tecnologia no alcanzara 1
ral-. En el context0 de este estudio, 10s componentes las espectativas
de riesgo se definen de la siguiente manera: Falta de formacion 3
-
en las herramientas
riesgo de rendimiento: el grado de incertidumbre con Personal sin experiencia 2
el que el producto encontrara sus requisitos y se ade- Habra muchos cambios 2
cue para su empleo pretendido; de personal
riesgo de coste: el grado de incertidumbre que man-
tendra el presupuesto del proyecto; Valores de impact0 :
2 - critico
riesgo de soporte: el grado de incertidumbre de la 4 - despreciable
facilidad del software para corregirse, adaptarse y FIGURA 6.2. Ejernplo de u n a t a b l a de riesgo a n t e s
ser mejorado; de l a c l a s i f i c a c i o n .
Laproyeccidn del riesgo, tambiin denominada estima- del riesgo en el proyecto y en el producto, y (4) apun-
ci6n del riesgo, intenta medir cada riesgo de dos mane- tar la exactitud general de la proyecci6n del riesgo de
ras -la probabilidad de que el riesgo sea real y las manera que no haya confusiones.
consecuencias de 10s problemas asociados con el ries-
go, si ocurriera-. El jefe del proyecto, junto con otros
gestores y personal tCcnico, realiza cuatro actividades 6.4.1. DesarrO110 de una de riesgo
de proyeccion del riesgo [I]: (1) establecer una escala Una tabla de riesgo le proporciona a1jefe del proyecto una
que refleje la probabilidad percibida del riesgo; (2) defi- sencilla tCcnica para la proyecci6n del riesgo2.En la Figu-
nir las consecuencias del riesgo; (3) estimar el impacto ra 6.2 se ilustra una tabla de riesgo como ejemplo.
* La tabla de riesgo deberia implementarse como un modelo de hoja

de calculo. Esto permite un facil manejo y ordenacion de las entra-
das.
Un equipo de proyecto empieza por listar todos 10s Una vez que se han completado las cuatro primeras
riesgos (no importa lo remotos que sean) en la primera columnas de la tabla de riesgo, la tabla es ordenada por
columna de la tabla. Se puede hacer con la ayuda de la probabilidad y por impacto. Los riesgos de aha proba-
lista de comprobaci6n de elementos de riesgo presen- bilidad y de alto impacto pasan a lo alto de la tabla, y
tada en la Seccion 6.3. Cada riesgo es categorizado en 10s riesgos de baja probabilidad caen a la parte de aba-
la segunda columna (por ejemplo: PS implica un ries- jo. Esto consigue una priorizaci6n del riesgo de primer
go del tamaiio del proyecto, BU implica un riesgo de orden.
negocio). La probabilidad de aparici6n de cada riesgo El jefe del proyecto estudia la tabla ordenada resul-
se introduce en la siguiente columna de la tabla. El valor tante y define una linea de corte. La linea de corte (dibu-
de la probabilidad de cada riesgo puede estimarse por jada horizontalmente desde un punto en la tabla) implica
cada miembro del equipo individualmente. Se sondea que s61o a 10s riesgos que quedan por encima de la linea
a 10s miembros del equipo individualmente de un mod0 se les prestara atencion en adelante. Los riesgos que
rotativo (round-robin) hasta que comience a converger caen por debajo de la linea son reevaluados para con-
su evaluation sobre la probabilidad del riesgo. seguir una priorizacion de segundo orden. Como mues-
tra la Figura 6.3, el impacto del riesgo y la probabilidad
Muy alto
t tienen diferente influencia en la gestion. Un factor de
riesgo que tenga un gran impacto per0 muy poca pro-
babilidad de que ocurra no deberia absorber una canti-
dad significativa de tiempo de gestion. Sin embargo, 10s
riesgos de gran impacto con una probabilidad moderada
a aha y 10s riesgos de poco impacto pero de gran pro-
babilidad deberian tenerse en cuenta en 10s procedi-
mientos de andisis de riesgos que se estudian a conti-
nuacion.
Alto
/
Relevancia
para
la gestion
La tabla de riesgos esta ordenada por probabilidad
y por el impact0 poro asignar una prioridad o 10s riesgos.
Todos 10s riesgos que se encuentran por encima de

la linea de corte deben ser considerados. La columna
etiquetada RSGR* contiene una referencia que apunta
hacia un Plan de reduccidn, supervisidn y gestidn del
riesgo, o altemativamente, a un informe del riesgo desa-
rrollado para todos 10s riesgos que se encuentran por
encima de la linea de corte. El plan RSGR y el informe
FIGURA 6.3. R i e s g o s y relevancia para la gestion.
del riesgo se estudian en la Seccion 6.5.
A continuaci6n se valora el impacto de cada riesgo.
Cada componente de riesgo se valora usando la carac-
terizaci6n presentada en la Figura 6.1, y se determina
una categoria de impacto. Las categonas para cada uno
de 10s cuatro componentes de riesgo -rendimiento,
soporte, coste y planificaci6n temporal- son prome- La probabilidad de riesgo puede determinarse hacien-
diados3para determinar un valor general de impacto. do estimaciones individuales y desarrollando desputs
un linico valor de consenso. Aunque este enfoque es fac-
tible, se han desarrollado ttcnicas m6s sofisticadas para
determinar la probabilidad de riesgo [AFC88]. Los con-
Piense sermmente en el sofhvore que esM construyendo troladores de riesgo pueden valorarse en una escala de
y pregirntese o si mismo ((&8 puede ir mol?)) Cree su probabilidad cualitativa que tiene 10s siguientes valo-
propio listo y consulte a atros miernbras del equipo de res: imposible, improbable, probable y frecuente. Des-
sohare poro hacer lo rnismo. puts puede asociarse una probabilidad matematica con
3 Puede usarse una media ponderada si un componente de riesgo * En ingles RMMM (Risk Mitigation, Monitoring and Management)
tiene mas influencia en el proyecto.
CAPfTULO 6 ANALISISY GESTI6N DEL RIESGO
cada valor cualitativo (por ejemplo: una probabilidad desarrollo). Puesto que la media por componente es
de10.7 a1 1.0 implica un riesgo muy probable). de 100 LDC y 10s datos locales indican que el cos-
te de la ingenieria del software para cada LDC es de
6.4.2. Evaluacion del impacto del riesgo £14,00; el coste global (impacto) para el desarrollo
de componentes seria 18 x 100 x 14 = £25.200
Tres factores afectan a las consecuencias probables de
un riesgo si ocurre: su naturaleza, su alcance y cuando Exposicion a1 riesgo : ER = 0,80 x 25.200 -
ocurre. La naturaleza del riesgo indica 10s problemas £20.200
probables que apareceran si ocurre. Por ejemplo, una La exposicion a1 riesgo se puede calcular para cada
interfaz externa ma1 definida para el hardware del clien- riesgo en la tabla de riesgos, una vez que se ha hecho
te (un riesgo tCcnico) impedira un disefio y pruebas tem- una estimation del coste del riesgo. La exposicion a1
pranas y probablemente lleve a problemas de integracion riesgo total para todos 10s riesgos (sobre la linea de cor-
mfis adelante en el proyecto. El alcance de un riesgo te en la tabla de riesgos) puede proporcionar un signifi-
combina la severidad (jc6mo de serio es el problema?) cad0 para ajustar el coste final estimado para un proyecto.
con su distribucion general (iquC proporcion del pro- TambiCn puede ser usado para predecir el increment0
yecto se vera afectado y cuantos clientes se veran per- probable de recursos de plantilla necesarios para varios
judicados?). Finalmente, la temporizaci6n de un riesgo puntos durante la planificaci6n del proyecto.
considera cuando y por cuanto tiempo se dejarfi sentir La proyeccion del riesgo y las tCcnicas de analisis
el impacto. En la mayoria de 10s casos, un jefe de pro- descritas en las Secciones 6.4.1 y 6.4.2 se aplican rei-
yecto prefiere las ccmalas noticias>>cuanto antes, per0 teradamente a medida que progresa el proyecto de soft-
en algunos casos, cuanto mas tarden, mejor. ware. El equipo del proyecto deberia volver a la tabla
Volviendo una veL mas a1 enfoque del analisis de de riesgos a intervalos regulares, volver a evaluar cada
riesgo propuesto por las Fuerzas ACreas de Estados Uni- riesgo para determinar quC nuevas circunstancias hayan
dos [AFC88], se recomiendan 10s siguientes pasos para podido cambiar su impacto o probabilidad. Como con-
determinar las consecuencias generales de un riesgo: secuencia de esta actividad, puede ser necesario afiadir
Determinar la probabilidad media de que ocurra un nuevos riesgos a la tabla, quitar algunos que ya no Sean
valor para cada componente de riesgo. relevantes y cambiar la posicion relativa de otros.
Empleando la Figura 6.1, determinar el impacto de
cada componente basandose en 10s criterios mos-
trados. Compare lo ER para todos 10s riesgos con el coste estimado
Completar la tabla de riesgo y analizar 10s resulta- del proyecto. Si lo ER es superior 0150 por 100 del coste
dos como se describe en las secciones precedentes. del proyecto, se deberb evoluor la viobilidod del proyecto.
~ C O evaluamos
~ O las
6.4.3. Evaluacion del riesgo
consecuencias de un riesgo?
En este punto del proceso de gestion del riesgo, hemos
La exposicion a1 riesgo en general, ER, se determi- establecido un conjunto de ternas de la forma [CHA89]:
na utilizando la siguiente relacion [HAL981 : [ri , li , xi I
ER=PxC donde ri es el riesgo, li es la probabilidad del riesgo y
xi es el impacto del riesgo. Durante la evaluacion del
donde P es la probabilidad de que ocurra un riesgo, y
riesgo, se sigue examinando la exactitud de las estima-
C es el coste del proyecto si el riesgo ocurriera.
ciones que fueron hechas durante la proyeccion del ries-
Por ejemplo, supongamos que el equipo del pro- go, se intenta dar prioridades a 10s riesgos que no se
yecto define un riesgo para el proyecto de la siguien- habian cubierto y se empieza a pensar las maneras de
te manera: controlar y/o impedir 10s riesgos que sea mas probable
Identificacion del riesgo :Solo el 70 por 100 de que aparezcan.
10s componentes del software planificados para reu- Para que sea litil la evaluacion, se debe definir un nivel
tilizarlos pueden, de hecho, integrarse en la aplica- de referencia de riesgo [CHA89]. Para la mayoria de 10s
ci6n. La funcionalidad restante tendrfi que ser proyectos, 10s componentes de riesgo estudiados ante-
desarrollada de un mod0 personalizado. riormente -rendimiento, coste, soporte y planificacion
temporal- tambiCn representan niveles de referencia
Probabilidad del riesgo :80 por 100 (probable). de riesgos. Es decir, hay un nivel para la degradation del
Impacto del riesgo : 60 componentes de software rendimiento, exceso de coste, dificultades de soporte o
reutilizables fueron planificados. Si solo el 70 por retrasos de la planificacion temporal (o cualquier com-
100 pueden usarse, 18 componentes tendran que binacion de 10s cuatro) que provoquen que se termine el
desarrollarse irqprovisadarnente (ademfis de otro soft- proyecto. Si una combination de riesgos crea problemas
ware personalizado que ha sido planificado para su de manera que uno o mfis de estos niveles de referencia
A SOFTWARE. U N ENFOQUE PRACTICO
se excedan, se parari el trabajo. En el context0 del ani-

h i s de riesgos del software, un nivel de referencia de
riesgo tiene un solo punto, denominado punto de refe-
rencia o punto de ruptura, en el que la decision de seguir Elnivel de referencia del riesgo establece su tolerancia para
con el proyecto o dejarlo (10s problemas son demasiado el sufrimiento. Una vez que la exposicion al riesgo supera el
graves) son igualmente aceptables. La Figura 6.4 repre- nivel de referencia,el proyecto puede ser terminado.
senta esta situacion grificamente.
En realidad, el nivel de referencia puede raramente
representarse como una linea nitida en el grafico. En la
mayoria de 10s casos es una region en la que hay Areas
-E de incertidumbre, es decir, intentar predecir una deci-
0 sion de gestion basindose en la combinaci6n de valo-
n Punto de referencia (valor res de referencia es a menudo imposible. Por tanto,
$
CI
del coste. valor del tiempo) durante la evaluacion del riesgo, se realizan 10s siguien-
C
.-
'0 tes pasos:
0 Tendra lugar el abandono
1. Definir 10s niveles de referencia de riesgo para el
.-a
0
'C
,
del proyecto
proyecto;
-nac 2. Intentar desarrollar una relacion entre cada (ri , li, xi)
-m
P)
y cada uno de 10s niveles de referencia;
u 3. Predecir el conjunto de puntos de referencia que defi-
SI nan la region de abandono, limitado por una curva o
0)
0 Areas de incertidumbre;
x
W
4. Intentar predecir como afectarin las combinaciones
compuestas de riesgos a un nivel de referencia.
- Es mejor dejar un estudio mis detallado para libros
Exceso en el coste previsto
especializados en el anilisis de riesgos (por ejemplo:
FIGURA 6.4. Nivel de referencia de riesgo. [CHA89], [ROW88]).
Durante las primeras etapas de la planificacion del en el sistema que se esta construyendo, teniendo como
proyecto, un riesgo puede ser declarado de un mod0 muy resultado la necesidad de que el ingeniero tenga que cons-
general. Con el paso del tiempo y con el aprendizaje truir el 30 por 100 de 10s componentes restantes.
sobre el proyecto y sobre el riesgo, es posible refinar el La condition general que acabamos de destacar pue-
riesgo en un conjunto de riesgos mas detallados, cada de ser refinada de la siguiente manera:
uno algo mis ficil de reducir, supervisar y gestionar. Subcondicion 1: Ciertos componentes reutiliza-
bles fueron desarrollados por terceras personas sin el
&al es uno buena forma conocimiento de 10s esthdares internos de diseiio.
de describir un riesgo?
Subcondicion 2: El esthdar de diseiio para inter-
Una forma de hacer esto es presentar el riesgo de faces de componentes no ha sido asentado y puede
la forma condici6n-rransici6n-consecuencia(CTC) no ajustarse a ciertos componentes reutilizables exis-
[GLU94]. Es decir, el riesgo se presenta de la siguien- tentes.
te forma: Subcondicion 3: Ciertos componentes reutiliza-
Dada esta <condition> entonces existe preocupacion bles han sido implementados en un lenguaje no
por (posiblemente) <consecuencia>. soportado por el entorno para el que el sistema ha
sido construido.
Utilizando el formato CTC para volver a utilizar el ries-
go presentado en la Secci6n 6.4.2, podemos escribir: Las consecuencias relacionadas con estas subcondi-
Dado que todos 10s componentes reutilizables del soft- ciones refinadas siguen siendo las mismas (por ejemplo,
ware deben ajustarse a 10s estindares especificos del dise- el 30 por 100 de 10s componentes del software deben ser
iio y que algunos no lo hacen, es entonces preocupante construidos de un mod0 personalizado), per0 el refina-
que (posiblemente) solo el 70 por 100 de 10s modules miento ayuda a aislar 10s riesgos sefialados y puede con-
planificados para reutilizar puedan realmente integrarse ducir a un analisis y respuesta mis sencilla.
C A P ~ T U L O6 A N A L I S I S Y G E S T I ~ NDEL R I E S G O
Todas las actividades de analisis de riesgo presentadas yecto supervisa factores que pueden proporcionar una
hasta ahora tienen un solo objetivo -ayudar a1 equipo indication sobre si el riesgo se esti haciendo mis o
del proyecto a desarrollar una estrategia para tratar 10s menos probable. En el caso de gran movilidad del per-
riesgos-. Una estrategia eficaz debe considerar tres sonal, se pueden supervisar 10s siguientes factores:
aspectos: Actitud general de 10s miembros del equipo b a s h -
Evitar el riesgo. dose en las presiones del proyecto;
Supervisar el riesgo, y Grado de compenetracion del equipo;
Gestionar el riesgo y planes de contingencia. Relaciones interpersonales entre 10s miembros del
equipo;
Problemas potenciales con compensaciones y bene-
ficios;
Disponibilidad de empleo dentro y fuera de la com-
paiiia.
Si un equipo de software adopta un enfoque proac-

tivo frente a1 riesgo, evitarlo es siempre la mejor estra-
tegia. Esto se consigue desarrollando un plan de
reduccidn del riesgo. Por ejemplo, asuma que se ha
detectado mucha movilidad de la plantilla como un ries-
go del proyecto, ri.Basandose en casos anteriores y en Ademis de supervisar 10s factores apuntados ante-
la intuicion de gestion, la probabilidad, li, de mucha riormente, el jefe del proyecto deberia supervisar tam-
movilidad se estima en un 0,70 (70 por 100, bastante biin la efectividad de 10s pasos de reduccion del riesgo.
alto) y el impacto, xi, esta previsto en el nivel 2. Esto Por ejemplo, un paso de reduccion de riesgo apuntado
es, un gran cambio puede tener un impacto critico en el anteriormente instaba a la definicion de ccestandares de
coste y planificacion temporal del proyecto. documentacion y mecanismos para asegurarse de que
Para reducir el riesgo, la gestion del proyecto debe 10s documentos se cumplimenten puntualmente>>.~ s t e
desarrollar una estrategia para reducir la movilidad. es un mecanismo para asegurarse la continuidad, en caso
Entre 10s pasos que se pueden tomar: de que un individuo critico abandone el proyecto. El
Reunirse con la plantilla actual y determinar las causas jefe del proyecto deberia comprobar 10s documentos
de la movilidad (por ejemplo: malas condiciones de tra- cuidadosamente para asegurarse de que son vilidos y
bajo. salarios bajos, mercado laboral competitivo). de que cada uno contiene la informacion necesaria en
Actuar para reducir esas causas que estCn a1 alcance caso de que un miembro nuevo se viera obligado a unir-
de nuestro control antes de que comience el proyecto. se a1 equipo de software a mitad del proyecto.
Una vez que comienza el proyecto, asumir que habra La gestidn del riesgo y 10s planes de contingencia
movilidad y desarrollar tCcnicas que aseguren la con- asumen que 10s esfuerzos de reduccion han fracasado y
tinuidad cuando se vaya la gente. que el riesgo se ha convertido en una realidad. Conti-
nuando con el ejemplo, el proyecto va muy retrasado y
Organizar 10s equipos del proyecto de manera que
un numero de personas anuncia que se va. Si se ha segui-
la informacion sobre cada actividad de desarrollo
do la estrategia de reduccion, tendremos copias de segu-
estC ampliamente dispersa.
ridad disponibles, la informacion esta documentada y
Definir estindares de documentacion y establecer el conocimiento del proyecto se ha dispersado por todo
mecanismos para estar seguro de que 10s documen- el equipo. Ademis, el jefe del proyecto puede tempo-
tos se cumplimentan puntualmente. ralmente volver a reasignar 10s recursos (y reajustar la
planificacion temporal del proyecto) desde 1as funcio-
nes que tienen todo su personal, permitiendo a 10s recikn
llegados que deben unirse a1 equipo que vayan cccogien-
do el ritmo>>.A 10s individuos que se van se les pide que
Se puede obtener una excelente CPF (cuestiones que
se preguntan frecuentemente) en
dejen lo que estkn haciendo y dediquen sus ultimas
www.sei.cmu.edu/organization/programs/
semanas a cctransferir sus conocimientos>>.Esto podria
sepm/risk/risk.faq.html incluir la adquisicion de conocimientos por medio de
videos, el desarrollo de ccdocumentos con comentarios>>
A medida que progresa el proyecto, comienzan las ylo reuniones con otros miembros del equipo que per-
actividades de supervisi6n del riesgo. El jefe del pro- manezcan en el proyecto.
5 por 100 y de la duraci6n en un 3 por 100, la gesti6n
probablemente lo haga.
Si el valor pora un riesga especifico es menor que el coste Para un proyecto grande se pueden identificar unos
de la reduccion del riesgo, no tote de reducir el riesga 30 6 40 riesgos. Si se pueden identificar entre tres y
pem continlie supervisandolo. siete pasos de gestion de riesgo para cada uno, ila ges-
ti6n del riesgo puede convertirse en un proyecto por
Es importante advertir que 10s pasos RSGR provo- si misma! Por este motivo, adaptamos la regla de Pare-
can aumentos del coste del proyecto. Por ejemplo, to 80120 a1 riesgo del software. La experiencia dice
emplear tiempo en conseguir ttun reserva>>de cada tCc- que el 80 por 100 del riesgo total de un proyecto (por
nico critico cuesta dinero. Parte de la gesti6n de riesgos ejemplo: el 80 por 100 de la probabilidad de fracas0
es evaluar cuando 10s beneficios obtenidos por 10s pasos del proyecto) se debe solamente a1 20 por 100 de 10s
RSGR superan 10s costes asociados con su implemen- riesgos identificados. El trabajo realizado durante pro-
taci6n. En esencia, quien planifique el proyecto realiza cesos de anhlisis de riesgo anteriores ayudard a1 jefe
el clhsico anhlisis coste/beneficio. Si 10s procedimien- de proyecto a determinar quC riesgos pertenecen a ese
tos para evitar el riesgo de gran movilidad aumentan el 20 por 100 (por ejemplo, riesgos que conducen a una
coste y duracion del proyecto aproximadamente en un exposicion a1 riesgo alta). Por este motivo, algunos
15 por 100, per0 el factor coste principal es la ucopia de 10s riesgos identificados, valorados y previstos pue-
de seguridad>>,el gestor puede decidir no implementar den no pasar por el plan RSGR -no pertenecen a1 20
este paso. Por otra parte si 10s pasos para evitar el ries- por 100 critico- (10s riesgos con la mayor prioridad
go llevan a una proyeccion de un aumento de costes del del proyecto).
El riesgo no se limita a1 proyecto de software solamente.

Pueden aparecer riesgos despuCs de haber desarrollado Hoja de informaci6n de riesgo I
con Cxito el software y de haberlo entregado a1 cliente.
Estos riesgos esthn tipicarnente asociados con las conse- Id. Riesgo: POI1-32 I hcha:W/O2 I Probabiidad: 80% I mpacto: alto I
cuencias del fallo del software una vez en el mercado. Description :
Solo el 70 por 100 de 10s componentes del software planificados
En 10s comienzos de la informdtica, habia un recha- lara reutilizar pueden, de hecho, integrarse en la aplicacion.
zo a1 uso de las computadoras (y del software) para el .a funcionalidad restante tendra que desarrollarse
control de procesos criticos de seguridad como por ejem- i e un mod0 personalizado.
plo reactores nucleares, control de vuelos de aviones, Refinamientolcontexto:

sistemas de armamento y grandes procesos industria- Subcondicion 1: Ciertos componentes reutilizables fueron desarrollados
por terceras personas sin el conocimiento
les. Aunque la probabilidad de fallo de un sistema de de 10s estandares internos de diseho.
alta ingenieria es pequeiia, un defect0 no detectado en Subcondicion 2: El estandar de disefio para interfaces de componentes
un sistema de control y supervision basados en com- no ha sido asentado y puede no ajustarse a ciertos
componentes reutilizables existentes.
putadora podria provocar unas pCrdidas economicas
Subcondicion 3: Ciertos componentes reutilizables han sido implementados
enormes o, peor, daAos fisicos significativos o pCrdida en un lenguaje no soportado por el entorno para el que
de vidas humanas. Pero el coste y beneficios funciona- el sistema ha sido construido.
les del control y supervision basados en computadora a ReduccionlSupe~ision:
menudo superan a1 riesgo. Hoy en dia, se emplean regu- 1. Contactar con terceras personas para determinar
larmente hardware y software para el control de siste- la conformidad con 10s estandares de disefio.
2. Presionar para completar 10s estandares de la interfaz;
mas de seguridad critica. considerar la estructura de componentes cuando se decide
Cuando se emplea software como parte de un siste- el protocolo de la interfaz.
3. Comprobacion para determinar 10s componentes en la
ma de control, la complejidad puede aumentar del orden categoria de subcondicion 3; comprobacion para determinar
de una magnitud o mas. Defectos sutiles de diseAo indu- si se puede adquirir el soporte del lenguaje
cidos por error humano -algo que puede descubrirse GestionIPlan de Contingencia/Accion:
y eliminarse con controles convencionales basados en Se calcula que la ER es de £20,200. Esta cantidad se coloca dentro del coste
de contingencia del proyecto. La planificacion del proyecto revisado asume
hardware- se convierten en mucho mds dificiles de que se tendran que construir 18 componentes adicionales; por consiguiente
descubrir cuando se emplea software. se asignara el personal de acuerdo con las necesidades.
Accion: Las fases de reduccion se llevaran a cab0 a partir de 7/1/02
Estado actual:
Referencia web/ ' 5/12/02: Fases de reduccion iniciadas.
Se puede encontrar uno gron bose de dotos con todos los

Autor: John Gagne
I Asignado: B. Laster
entrodos del Foro ACM sobre riesgos en

catless.ncl.oc.uk/Risks/swrch.html FIGURA 6.5. Hoja de inforrnacion de riesgo [WIL971.
CAP~TULO
6 ANALISISY GEST16N DEL RIESGO
La seguridad del software y el analisis del peligro falle el sistema entero. Si se pueden identificar 10s
. son actividades para garantizar la calidad del soft- peligros a1 principio del proceso de ingenieria del
ware (Capitulo 8) que se centra en la identification software, se pueden especificar caracteristicas de dise-
y evaluacion de peligros potenciales que pueden Ao software que eliminen o controlen esos peligros
impactar a1 software negativamente y provocar que potenciales.
Se puede incluir una estrategia de gestion de riesgo en el que la creacion y entrada de information, ordenacion
plan del proyecto de software o se podrian ~rganizar10s por prioridad, busquedas y otros analisis pueden ser rea-
pasos de gestion del riesgo en un Plan diferente de reduc- lizados con facilidad.. El formato de la HIR se muestra
cion, supervision y gestion del riesgo (Plan RSGR). Todos en la Figura 6.5.
10s documentos del plan RSGR se llevan a cab0 como Una vez que se ha desarrollado el plan RSGR y el
parte del analisis de riesgo y son empleados por el jefe proyecto ha comenzado, empiezan 10s procedimientos
del proyecto como parte del Plan del Proyecto general. de reduccion y supervision del riesgo. Como ya hemos
dicho antes, la reduccion del riesgo es una actividad para
evitar problemas. La supervision del riesgo es una acti-
vidad de seguimiento del proyecto con tres objetivos
principales: (1) evaluar cuando un riesgo previsto ocu-
rre de hecho; (2) asegurarse de que 10s procedimientos
para reducir el riesgo definidos para el riesgo en cues-
Plan RSGR ti6n se estan aplicando apropiadamente; y (3) recoger
informaci6n que pueda emplearse en el futuro para ana-
Algunos equipos de software no desarrollan un docu- lizar riesgos. En muchos casos, 10s problemas que ocu-
mento RSGR formal. Mas bien, cada riesgo se docu- rren durante un proyecto pueden afectar a mas de un
menta utilizando una hoja de informaci6rz de riesgo riesgo. Otro trabajo de la supervision de riesgos es inten-
(HIR) [WIL97]. En la mayoria de 10s casos, la HIR se tar determinar el origen +uC riesgo(s) ocasionaron tal
mantiene utilizando un sistema de base de datos, por lo problema a lo largo cle todo el proyectc+-.
Cuando se pone mucho en juego en un proyecto de soft- El analisis de riesgos puede absorber una cantidad
ware el sentido c o m h nos aconseja realizar un analisis significativa del esfuerzo de planificacion del proyec-
de riesgo. Y sin embargo, la mayoria de 10s jefes de pro- to. Pero el esfuerzo merece la pena. Por citar a Sun Tzu,
yecto lo hacen informal y superficialmente, si es que lo un general chino que vivi6 hace 2.500 aiios, << Si cono-
hacen. El tiempo invertido identificando, analizando y ces a1 enemigo y te conoces a ti mismo, no tendras que
gestionando el riesgo merece la pena por muchas razo- temer el resultado de cien batallas,,. Para el jefe de pro-
nes: menos trastomos durante el proyecto, una mayor habi- yectos de software, el enemigo es el riesgo.
lidad de seguir y controlar el proyecto y la confianza que
da planificar 10s problemas antes de que ocurran.
[AFC88] Software Risk Abatement, AFCS/AFLC Pamphlet [DRU75] Drucker, P., Management, W. Heinemann, Ltd.,
800-45, U.S. Air Force, 30 de Septiembre 1988. 1975.
[BOE89] Boehm, B. W., Sojhvare Risk Management, IEEE [GIL88] Gilb, T., Principies of Software Engineering Mana-
Computes Society Press, 1989. gement, Addison-Wesley, 1988.
[CHA89] Charette, R. N., Software Engineering Risk Analy- [GLU94] Gluch, D.P., <<AConstruct for Describing Softwa-
sis and Management, McGraw-Hillflntertext,1989. re Development Risk)),CMU/SEI-94-TR-13, Software
[CHA92] Charette, R. N., <<Building
Bridges Over Intelligent Engineering Institute*1994.
Rivers D, American Programmer, vol. 5, n." 7, Septiem- [HAL981 Hall, E. M., Managing Risk:Methods for Software
bre 1992, pp. 2-9. Systems Development, Addison Wesley, 1998.
I N G E N I E R ~ ADEL SOFTWARE. UN ENFOQUE P R A C T I C O
[HIG95] Higuera, R.P, <<TeamRisk Management)), CrossTalk, [ROW881 Rowe, W. D., An Anatomy of Risk, Robert E. Krie-
, US Dept. of Defense, Enero 1995, pp. 2-4. ger Publishing Co., Malabar, FL, 1988.
[KAR96] Karolak, D.W., Software Engineering Risk Mana- [SEI93] Tawonomy-Based Risk Ident$cation, Software Engi-
gement, IEEE Computer Society Press, 1996. neering Institute, CMUISEI-93-TR-6, 1993.
[THO921 Thomsett, R., ccThe Indiana Jones School of Risk
[KEI98] Keil, M. et al., ccA Framework for Identifying Soft- Management,), American Programmer, vol. 5, n." 7, Sep-
ware Project Risks),, CACM, vol 4 1, n."l I, Noviembre
tiembre 1992, pp. 10- 18.
1998, pp. 76-83.
[WIL97] Williams, R.C., J.A.Walker y A.J. Dorofee, <<Put-
[LEV951 Leveson, N. G., Safeware: System Safety and Com- ting Risk Management into Practice)), IEEE Software,
putes, Adisson-Wesley, 1995. Mayo 1997, pp. 75-8 1.
6.1. Proporcione cinco ejemplos de otros campos que ilustren 6.8. Desarrolle una estrategia de supervision del riesgo y sus acti-
10s problemas asociados con una estrategia reactiva frente a1 vidades especificas para tres de 10s riesgos seiialados en la Figu-
riesgo. ra 6.2. Asegfirese de identificar 10s factores que va a supervisar
para determinar si el riesgo se hace mas o menos probable.
6.2. Describa la diferencia entre ccriesgos conocidos) y ccries-
gos predecibles,). 6.9. Desarrolle una estrategia de gestion del riesgo y sus acti-
vidades especificas para tres de 10s riesgos seiialados en la
6.3. Aiiada tres cuestiones o temas a cada una de las listas de Figura 6.2.
comprobaci6n de elementos de riesgo que se presentan en el
sitio web SEPA. 6.10. Trate de refinar tres de 10s riesgos sefialados en la figura
6.2 y realice las hojas de informacion del riesgo para cada uno.
6.4. Se le ha pedido que construya un software que soporte un
sistema de edici6n de video de bajo coste. El sistema acepta 6.11. Represente 3 de 10s riesgos seiialados en la figura 6.2 uti-
cintas de video como entrada de informaci6n, almacena el lizando el formato CTC.
video en disco, y despuCs permite a1 usuario realizar un amplio
6.12. Vuelva a calcular la exposici6n a1 riesgo tratada en la
abanico de opciones de edici6n al video digitalizado. El resul- Secci6n 6.4.2 donde el coste/LDC es 6:16 y la probabilidad es
tad0 (salida) se envia a una cinta. Realice una pequeiia inves-
de160 por 100.
tigaci6n sobre sistemas de este tipo, y despuCs haga una lista
de riesgos tecnol6gicos a 10s que se enfrentaria a1 comenzar 6.13. iSe le ocurre alguna situaci6n en la que un riesgo de alta
un proyecto de este tipo. probabilidad y gran impact0 no formari parte de su plan
RSGR?
6.5. Usted es el jefe de proyectos de una gran compaiiia de
software. Se le ha pedido que dirija a un equipo que e s t i 6.14. Respecto a la referencia de riesgo mostrada en la Figu-
desarrollando un software de un procesador de textos de ra 6.4, jsera siempre la curva un arco simCtrico con10 el que
ccnueva generation)) (ver Seccion 3.4.2 para obtener una bre- aparece, o habra situaciones en las que la curva estC mis dis-
ve descripcibn). Construya una tabla de riesgo para el pro- torsionada? Si es asi, sugiera un escenario en el que esto pue-
yecto. da ocurrir.
6.6. Describa la diferencia entre componentes de riesgo y con- 6.15. Realice una investigacion sobre aspectos de seguridad
troladores de riesgo. del software y escriba una pequeiia redacci6n sobre el tema.
Desarrolle un buscador web para obtener informacidn actual.
6.7. Desarrolle una estrategia de reduccion del riesgo y sus
actividades especificas para tres de 10s riesgos seiialados en la 6.16. Describa cinco areas de aplicaci6n de software en las que
Figura 6.2. la seguridad del software y el analisis de riesgo Sean vitales.
Las lecturas sobre la gesti6n del riesgo del software se han Chapman, C.B., y S. Ward, Project Risk Management:
expandido significativamente en 10s ultirnos aiios. Hall Processes. Techniques and Insights, Wiley. 1997.
[HAL981presenta uno de 10s tratados mas completes del tema. Schuyler, J. R., Decision Analysis in Projects, Project
Karolak [KAR96] ha escrito una guia que introduce un mode- Management Institute Publications, 1997.
lo de analisi5 del riesgo facil de usar con listas de compro-
baci6n y cuestionarios que merece la pena. Grey ha realizado Wideman, R. M. (editor), Project & Program Risk Mana-
una instantanea de la evaluaci6n del riesgo (Practical Risk gement: A Guide to Managing Project Risk and Opportuni-
Assessment for Project Management, Wiley, 1995). Su trata- ties, Project Management Institute Publications, 1998.
do abreviado proporciona una buena introduccion al tema. Capers Jones (Assesment and Control of Software Risks.
Otros libros que merecen la pena son: Prentice-Hall, 1994) presenta un detallado estudio sobre ries-
CAPfTULO 6 ANALISIS Y G E S T I 6 N D E L R I E S G O
gos del software que incluye inforrnacidn reunida de cientos Los tratados de Marzo 1995 de American Programmer,
de proyectos de software. Jones define 60 factores de riesgo Mayo 1997 de IEEE Software, y Junio 1998 Cutter IT Jour-
que pueden afectar a1 resultado de 10s proyectos de softwa- nal estin dedicados a la gestidn del riesgo.
re. Boehm [BOE89] sugiere unos excelentes cuestionarios y El Institute de Ingenieria del Software ha publicado muchos
forrnatos de listas de comprobacidn que pueden resultar de informes y guias detallados sobre el anilisis y gestidn del ries-
valor incalculable a la hora de identificar riesgos. Charrette go. El Air Force Systems Command Pamphlet AFSCP 800-45
[CHA89] presenta un detallado tratado de 10s mecanismos de [AFC88] describe tCcnicas de identificacidn y reduccidn de
anilisis de riesgo, recurriendo a la teoria de probabilidades y riesgos. Todos 10s numeros de ACM Software Engineering
tCcnicas estadisticas para analizar riesgos. En un volumen Notes publican una seccidn titulada ccRiesgos para el publicon
adjunto, Charette (Application Strategies for Risk Analysis, (editor, P. G. Neumann). Si quiere las ultimas y mejores his-
McGrawHill, 1990) analiza el riesgo en el context0 tanto del torias de horror de software, Cste es el lugar adonde ir.
sistema como de la ingenieria del software y define unas estra- En Internet estin disponibles una gran variedad de fuen-
tegias pragmaticas para la gestidn del riesgo. Gilb [GIL88] tes de inforrnacidn relacionadas con temas de anilisis y ges-
presenta un conjunto de ccprincipios>)(que son a menudo diver- tidn del riesgo. Se puede encontrar una lista actualizada con
tidos y algunas veces profundos) que pueden servir como una referencias a sitios (piginas) web que son relevantes para el
util directriz para la gestidn del riesgo. riesgo en http://www.pressrnan5.corn.
PLANIFICACI~N TEMPORAL
Y SEGUIMIENTO DEL PROYECTO
Palabras
A
finales de 10s aiios 60, un joven y brillante ingeniero fue elegido para ccescribir,, un pro-
clave grama de computadora para una aplicaci6n de fabricaci6n autoniiitica. El motivo para
comino critics. ..... . I 2 2 ru selecci6n fue sencillo. Era la unica persona de su grupo ~6cnicoque habia asisticlo
conjunto a un seminario de programacih de computadoras. Sabia todo sobre el lenguaje ensamblador y
de toreas.. ........1 l6 Fortran, pero nada sobre ingenieria del software y muclio menos sobre la planificaci6n tempo-
rriterior ral y seguimiento del proyecto.
de adopfacihn ......I17
Su jefe le dio 10s manuales adecuados y una description verbal de lo que tenia que hacer. Se
estructuro de le inform6 de clue el proyecto debia terminarse en dos meses.
descomposicibn
de trobojo. Work Ley6 10s manuales, consider6 su enfoclue y empez6 a escribir codigo. Despues de dos sema-
Breakdown Strudure nas de trabajo, el jefe le llam6 a su oficina y le pregunt6 qu6 tal iban las cosas.
(WBS). ............I22 ccMuy b i e n ~ dijo
, el joven ingeniero con entusiasmo juvenil, cces mris ficil de lo que pen-
grafito saba. He terniinado cerca del 75 por 100~.
de tiernpo.. ....... . l 2 3 El jefe sonri6. ccEs realmente estupendow, dijo, alentando al joven ingeniero a que siguiera
personas trabajando del mismo modo. Acordaron que se reunirinn otra vez en unn semana.
y esfuerzo ........ .I14 Una semana miis tarde el jefe llam6 al ingeniero a su oficina y le pregunz6: cciPor d6nde
plnn vanios?~~
del proyecto.. .....
.l27
ccTodo va muy biem, dijo el joven, ccpero me he encontrado con unos pequeiios obstliculos.
prinripios
de planifiroirbn Los solucionark y volver6 al ritmo de trabajo pronto.,,
temporal.. ......... 113 (ciC6m0 ves las fechaf limite de entrega?,,, pregunt6 el jefe.
red de tarws. ..... . l 2 1 ccNo hay problenia,,, dijo el ingeniero, ccestoy cerca de terminar el 90 por 1 0 b .
retrasos Si ha estado trabajando en el mundo del software durante algunos aiios, sabr5 el final de la his-
(demoros) ......... 1 12 toria. No es una sorpresa qile el joven ingenieso' se estancara en el 90 p r 100 durante el resto del
seguimiento proyecto y que terminara (con la ayuda de otros) con un mes de retraso.
de errores ........
.I26 Esla hirtoria se ha repetido docenas de miles de veces con 10s desarrolladores de software
seguimiento durance la\ liltimas tres d6cadas. La gran pregunta es i,por clui.?
del proyecto. .......I24
valor gonodo. .....
.I25
LQuees? Usted ha seleccionado un mode- lizan la informaci6n solicitada a 10s truir. El esfuerzo y la duraci6n s e asig-
lode procesoadecuado. ha identificado ingenieros de software. A nivel indivi- na a c a d a tarea y s e crea una red de
las tareas d e ingenieria del software dual, 10s mismos ingenieros d e soft- tareos {tambien llamada red de activi-
que hay que llevar a cabo, ha estimado ware. dades) que permita a1 e q u i p de soft-
la cantidad de trabajo y el ndmero de &Parqu8 cs importante? Pam cons- ware conseguir la fecha limite de
personas necesario, conoce las fechas trulr un sistema complejo, muchas entrega establecida.
limite de entrega e incluso ha conside- tareas de ingenieria del software se ;Cud1 es el product0 obtenldo? Se
rado Ios riesgos. Ahora es el momento realizan e n paralelo y e!resultado del obtiene la planificacidn del proyecfo e
d e unit todos 10s puntos. Esto es, tiene trabajo desamollado durante una tarea informaci6n relacionada.
que crear una red de tareas de ingenie- puede tener un gran efecto e n el tra- kC6mo puedo asrgurar que lo he
ria del software que le permitan conse- bajo a realizar en otra tarea. Estas hecho comectamente? Una plani-
guir el trabajo realizado a tiempo. Una interdependencias son muy dificiles ficacidn adecuada requiere que (1)
vez creada la red, tiene que asignar la de comprender sin una planificacidn. todas las Yareas aparezcan en la red;
responsabilidad para cada tarea, ase- Tambibn e s virtualmente imposible (2) el esfuerzo y el tiempo s e ssigne
gdrese de hacerlo y de adaptar la red evaluar el progreso en un proyecto de inteligentemente a cada tarea; (3) las
antes de que 10s rlesgos s e conviertan software normal o grande sin una pla- relaciones entre tareas e s t h indica-
en realidad. En resumidas cuentas, esto nificaci6n detallada. das comectamente;(4) 10s recursos Sean
e s la planificaci6n temporal y el segui-
;Cuales son 10s pasos? Las tareas de asignados a1 trabap a realizar, y (5)10s
miento del proyecto de software.
ingenieria del software dictadas por el hitos s e sitden rigurosamente espa-
aQui6nlo hate? A nivel de proyecto, los modelo de proceso del software son ciados para que se pueda seguir el pro-
gestores de proyectos de software, uti- refinadas por La funcionalidad a cons- greso.
Si se pregu%i esta historia es autobiografica, ilo es!

~ N G E N ~ E RDEL
. . . ..%.. :..,:,.- . . . . . . . . . ... . .. . .. .. :,. .. . . . .. .<.:. . . . . . . .. ...... . .

.. .:... .. . . ... ,-'
... . " . . . ., ......
. . . . . . . . . . .1 .:
. . . . . . . . < .......
:
. . ..
TOS ~ O ..,,. . .. . . . S .... . .
Aunque hay muchas razones por las que el software se mentan a menudo bajo la restricci6n de una fecha limi-
entrega tarde, la mayoria pertenecen a una o mhs de las te definida. Si las mejores estimaciones indican que la
siguientes causas: fecha limite es poco realista, un gestor de proyecto com-
Una fecha limite de entrega poco realista, estable- petente deberia ccproteger a su equipo de una presi6n
cida por alguien que no pertenece a1 grupo de inge- [de la planificaci6n temporal] innecesaria ...[y] devol-
nieria del software e impuesta a 10s gestores y ver la presi6n a quienes la originarom [PAG85].
profesionales del grupo.
Cambio de 10s requisitos del cliente que no se refle-
jan en 10s cambios de la planificaci6n temporal.
Una subestimaci6n honesta de la cantidad de esfuerzo
ylo el ndmero de recursos que serhn necesarios para
hacer el trabajo.
Riesgos predecibles y no predecibles que no se con- Para ilustrarlo, imaginese que un grupo de desarro-
sideraron cuando comenz6 el proyecto. 110 de software ha sido comisionado para construir un
Dificultades tCcnicas que no pudieron ser previstas controlador de tiempo real para un instrumento mCdico
por adelantado. de diagn6stico que quiere introducirse en el mercado en
Dificultades humanas que no pudieron ser previstas nueve meses. DespuCs de una cuidadosa estimaci6n y
por adelantado. anhlisis de riesgos, el gestor del proyecto de software
llega a la conclusi6n de que el software, tal y como se
Falta de comunicaci6n entre la plantilla del proyecto ha pedido, requerirh 14 meses para crearlo con la plan-
que causa retrasos. tilla de la que se dispone. iC6mo debe proceder el jefe
Falta de reconocimiento por parte de la gesti6n del del proyecto?
proyecto de su retraso y falta de medidas para corre- Es poco realista ir a la oficina del cliente (en este
gir el problema. caso el cliente probable es mercadotecnia/ventas) y exi-
girle que se cambie la fecha de entrega. Las presiones
externas del mercado han dictado la fecha y el produc-
to debe entregarse. TambiCn es absurd0 rechazar el tra-
bajo (desde el punto de vista de la carrera profesional).
Asi pues, iquC hacer?
;Que deberiamos hacer
Las fechas limite de entrega agresivas (1Case <<poco iuando la gestiin exige
realistas>>),son un hecho consumado en el mundo del que cumplamos una fecho limite
software. Algunas veces estas fechas limite se piden por de entrega que es imposible?
motivos legitimos desde el punto de vista de la persona Se recomiendan 10s siguientes pasos en esta situaci6n:
que las establece, per0 el sentido comlin tambiCn dice que 1. Realice una estimaci6n detallada usando informa-
la legitimidad debe ser percibida por las personas que ci6n de proyectos anteriores. Determine el esfuerzo
hacen el trabajo. estimado y la duraci6n del proyecto.
2. Empleando un modelo de proceso incremental (Capi-
7.1.1. Comentarios sobre 10s aetrasos,,
tulo 2), establezca una estrategia de desarrollo que
Napole6n dijo una vez: <<Uncomandante en jefe que proporcione una funcionalidad critica minima para
acepta llevar a cabo un plan que considera defectuoso la fecha limite impuesta, per0 deje otras funcionali-
esth cometiendo un error; debe exponer sus razones, dades para mhs tarde. Documente el plan.
insistir en cambiar el plan y finalmente presentar su 3. Rednase con el cliente y (empleando la estimaci6n
dimisi6n antes de ser el instrumento de la destrucci6n detallada) explique por quC la fecha limite impuesta
de su ejCrcito.>>Duras palabras que muchos gestores de no es realista. Asegdrese de apuntar que todas las esti-
proyecto de software deberian considerar. maciones se basan en proyectos del pasado. Asegd-
Las actividades de estimaci6n y anhlisis de riesgos rese tambiCn de indicar la mejora de porcentaje que
estudiadas en 10s Capitulos 5 y 6, y las tkcnicas de pla- se requerirh para conseguir la fecha limite tal y como
nificaci6n temporal descritas en este capitulo, se imple- esth ahora2.El siguiente comentario seria apropiado:
Si la mejora de porcentaje es del 10 a1 25 por ciento, puede ser posi-

ble, de hecho, terminar el trabajo. Pero si se necesita que la mejora
del porcentaje en el rendimiento del equipo sea mayor del 50 por
ciento. Esta es una prevision no realista.
CAPITULO 7 PLANIFICACION TEMPORAL Y SEGUIMIENTO DEL P R O D U C T 0
&re0 que podemos tener un problema con la fecha camino principal y pueden completarse sin preocupar-
de entrega del software de controlador XYZ. Les he se del impact0 en la fecha de termination del proyecto.
entregado a cada uno de ustedes una descomposici6n Otras tareas se encuentran en el <<camin0criticon4. Si
abreviada de 10s ritmos de production de proyectos estas tareas <<criticas>>
se retrasan, la fecha de termina-
anteriores y una estimation que hemos hecho de varias ci6n del proyecto entero se pone en peligro.
maneras diferentes. Se fijarin en que he asumido un
20 por 100 de mejora con respecto a 10s ritmos de pro-
duccion del pasado, per0 todavia obtenemos una fecha
de entrega que esti mis bien a 14 meses de calenda- 10s toreos requeridos poro logror el objetivo
rio que a 9 meses de la presente fecha.>> de 10s gestores del proyecto no se deberfon reolizor
monuolmente. Hoy muchos herromientas excelentes
de plonificocian de proyectos. Utilicelos.
10s modelos de procesos incrementales se estudian El objetivo del gestor del proyecto es definir todas
en el Copitulo 2.
las tareas del proyecto, construir una red que describa
sus interdependencias, identificar las tareas que son cri-
Oferte la estrategia de desarrollo incremental como
ticas dentro de la red y despuCs hacerles un seguimien-
alternativa.
to para asegurarse de que el retraso se reconoce <<de
<<Tenemos pocas opciones y me gustaria que toma- inmediatou. Para conseguirlo, el gestor debe tener una
ran una decision basindose en ellas. Primero, pode- planificaci6n temporal que se haya definido con un gra-
mos aumentar el presupuesto y conseguir recursos do de resolution que le permita supervisar el progreso
adicionales de manera que tengamos la oportunidad y controlar el proyecto.
de tener el trabajo hecho en nueve meses, per0 entien- La planificacidn temporal de un proyecto de soft-
dan que esto aumenta el riesgo de poca calidad debi- ware es una actividad que distribuye el esfuerzo esti-
do a lo apretado de las fechas3. mado a lo largo de la duracion prevista del proyecto,
Segundo, podemos quitar un n6mero determina- asignando el esfuerzo a las tareas especificas de la inge-
do de funciones software y capacidades de las que nieria del software. Es importante resaltar, sin embar-
piden. Esto hari la version preliminar del producto go, que la planificacion temporal evoluciona con el
algo menos funcional, per0 podemos anunciar la fun- tiempo. Durante las primeras etapas de la planificacion
cionalidad completa para lanzarla a 10s 14 meses. del proyecto, se desarrolla una planijicacidn temporal
Tercero, podemos contradecir a la realidad y desear macroscdpica. Este tipo de planificacion temporal iden-
poder completarlo en 9 meses. Nos encontraremos tifica las principales actividades de la ingenieria del soft-
con algo que no se pueda entregar a un cliente de ware y las funciones del producto a las que se aplican.
manera alguna. La tercera opcion, espero que estCn A medida que el proyecto va progresando, cada entra-
de acuerdo, es inaceptable. Nuestra experiencia y da en la planificacion temporal macroscopica se refina
nuestras mejores estimaciones dicen que es poco rea- en una planificacidn temporal detallada. Aqui, se iden-
lista y una receta para el desastre.u tifican y programan las tareas del software especificas
Habri grufiidos, per0 si se presentan estimaciones (requeridas para realizar una actividad).
solidas basadas en una buena informacion historica, es
probable que se opte por alguna version negociada de
las opciones 1 6 2. La fecha limite no realista se desva-
neceri.
7.1.2. Principios basicos

A Fred Brooks, el conocido autor de The Mythical La planificacion temporal para proyectos de desa-
Man-Month [BR095], se le pregunto una vez corn0 se rrollo de software puede verse desde dos perspectivas
retrasan las planificaciones temporales de 10s proyec- bastante diferentes. En la primera se ha establecido ya
tos. Su respuesta fue tan simple como profunda: c<Dia- (irrevocablemente) una fecha final de entrega de un sis-
riamente.,, tema basado en computadora. La organizacion del soft-
La realidad de un proyecto tCcnico (tanto si implica ware esti limitada a distribuir el esfuerzo dentro del
la construccion de una planta hidroelkctrica o desarro- marco de tiempo previsto. El segundo punto de vista de
llar un sistema operativo) es que hay que realizar cien- la planificacion temporal asume que se han estudiado
tos de pequeiias tareas antes de poder alcan'zar el unos limites cronol6gicos aproximados per0 que la fecha
objetivo final. Algunas de estas tareas quedan fuera del final seri establecida por la organizacion de la ingenie-
Puede afiadir que agregar mas personal no reducira la planificacion El camino critic0 se estudiara con mas detalle, mas adelante en este
temporal proporcionalmente capitulo.
A SOFTWARE. UN ENFOQUE P R ~ c T ~ C O
ria del software. El esfuerzo se distribuye para conse- a cada tarea se le debe asignar una fecha de inicio y otra
guir el mejor empleo de 10s recursos, y se define una de finalizaci6n que son funci6n de las interdependencias
fecha final despuCs de un cuidadoso anilisis del soft- y de si el trabajo se hari a tiempo total o tiempo parcial.
ware. Desgraciadamente, la primera situaci6n es mhs Validacion de esfuerzo. Todos 10s proyectos tienen
frecuente que la segunda. un numero definido de miembros de la plantilla. A medi-
Como todas las areas de la ingenieria del software, da que se hace la asignacion de tiempo, el gestor del
la planificaci6n temporal de proyectos de software se proyecto debe asegurarse de que no se ha asignado un
guia por unos principios basicos: numero de personas mayor que el de la plantilla en ese
Compartimentacion. El proyecto debe dividirse en momento. Por ejemplo, considere un proyecto que tie-
un numero de actividades y tareas manejables. Para lle- ne una plantilla asignada de tres miembros (por ejem-
var a cab0 esta compartimentacion, se descomponen plo, 3 personas-dia est5n disponibles por dia de esfuerzo
tanto el producto como el proceso (Capitulo 3). asignado5). Un dia cualquiera, se deben realizar siete
Interdependencia. Se deben determinar las intertareas concurrentemente. Cada tarea requiere 0,50 per-
dependencias de cada actividad o tarea compartimen- sonas-dia de esfuerzo. Se ha asignado mas esfuerzo del
tada. Algunas tareas deben ocurrir en una secuencia que pueden realizar las personas disponibles.
delerminada; otras pueden darse en paralelo. Algunas Responsabilidades definidas. Cada tarea que se pro-
actividades no pueden comenzar hasta que el resultado grame debe asignarse a un miembro del equipo especi-
de otras no estC disponible. Otras actividades pueden fico.
ocurrir independientemente. Resultados definidos. Cada tarea programada debe-
ria tener un resultado definido. Para 10s proyectos de
software, el resultado es nonnalmente un producto (por
ejemplo, el disefio de un modulo) o una parte de un pro-
d u c t ~Los
. productos se combinan frecuentemente en
Cuando realice uno planificacion temporal, entregas.
comportimentalice el trabajo, represente interdependencias
Hitos definidos. Todas las tareas o grupos de tareas
de tareas, asigne el esfueno y tiempo a cada torea, defina
responsabilidades para el trabaio a desarrollar,
deberian asociarse con un hito del proyecto. Se consi-
y defina 10s resultadosy 10s hitos. gue un hito cuando se ha revisado la calidad de uno o
mis productos (Capitulo 8) y se han aceptado.
Asignacion de tiempo. A cada tarea que se vaya a pro- Cada uno de 10s principios anteriores se aplica a
gramar se le debe asignar cierto numero de unidades de medida que evoluciona la planificacion temporal del
trabajo (por ejemplo, personas-dia de esfuerzo). Ademis, proyecto.
En un proyecto de desarrollo de software pequeiio una gente que les ensefia es la misma que estaba trabajando.
sola persona puede analizar 10s requisitos, realizar el Mientras esthn enseiiando no se trabaja, y el proyecto se
disefio, generar codigo y realizar las pruebas. A medi- retrasa todavia mas.
da que crece el tamaiio del proyecto m8s personas se
ven envueltas. (Raramente podemos pennitirnos el lujo
de enfocar el esfuerzo de diez personas-aiio con una per-
sona trabajando durante diez afios.) Si debe oriodir recursos o un proyecto con retroso,
Hay un mito cornfin (estudiado en el Capitulo 1) que oseglirese de que les ho osignodo troboja oltomente
todavia creen muchos gestores responsables de esfuer- comportimentol~zodo.
zos de desarrollo del software: <<Sise retrasa el progra-
ma, siempre podremos aiiadir mas programadores y Ademas del tiempo que se tarda en aprender el sis-
recuperar el ritmo mas adelante en el pr0yecto.u Des- tema, el involucrar mas personas aumenta el numero de
graciadamente, afiadir gente tarde a un proyecto tiene a vias de comunicaci6n y la complejidad de la comuni-
menudo un efecto negativo, provocando aun mis retra- caci6n a lo largo del proyecto. Aunque la comunicaci6n
so. El personal agregado debe aprenderse el sistema y la es absolutamente esencial para el Cxito del desarrollo
En realidad, se dispone de menos de tres personas-dia debido a reu-

niones no mencionadas, enfermedades, vacaciones y otras razones.
Para nuestro proposito, sin embargo, asumimos un 100 por 100 de
disponibilidad.
CAPfTULO 7 P L A N I F I C A C I ~ NT E M P O R A L Y S E G U I M I E N T O DEL P R O D U C T 0
del software, cada nueva via de comunicaci6n requie-

re un esfuerzo adicional y, por tanto, un tiempo adi-
donde E es el esfuerzo de desarrollo en personas-mes;
cional.
P es un parhetro de productividad que refleja una varie-
dad de factores que llevan a un trabajo de ingenieria del
7.2.1. Un ejemplo software de alta calidad (10s valores tipicos de P se
Considere cuatro ingenieros del software, cada uno encuentran entre 2.000 y 12.000); y t es la duraci6n del
capaz de producir 5000 LDClafio cuando trabajan en proyecto en meses.
proyectos individuales. Cuando se pone a estos cuatro
ingenieros en un proyecto de equipo, son posibles seis
vias de comunicacion potenciales. Cada via de comu-
nicaci6n requiere un tiempo que podria de otra manera luondo lo fecho limite de entrego es coda vez m6s
ojustado, se olconzo un punto en el que el trobojo
emplearse en desarrollar software. Asumiremos que la
no se puede completor segun lo p/onificoci6n,
productividad del equipo (medida en LDC) se ver6 redu-
sin tener en cuento el numero de personas
cida en 250 LDC/afio por cada via de comunicacion, que lo esten reolizondo. Afronte lo reolidod
debido a1 gasto indirect0 asociado con la comunicaci6n. y defino uno nuevo fecho de entrego.
Por tanto, la productividad del equipo es 20.000 -(250
x 6) = 18.500 LDC/aii- un 7,5 por ciento menos de Despejando la ecuaci6n del software anterior, pode-
lo que podriamos esperarh. mos llegar a la expresion del esfuerzo de desarrollo E:
El proyecto de un afio en el que esta trabajando el
equipo anterior se retrasa y a dos meses de la fecha E = L~ 1 (p3 t4) (7.1)
de entrega se agregan dos personas adicionales a1 equi- donde E es el esfuerzo invertido (en personas-aiio) duran-
po. El numero de vias de comunicaci6n se dispara a te el ciclo entero de la vida del desarrollo del software y
14. La productividad de la nueva plantilla es la equi- del mantenimiento, y t es el tiempo de desarrollo en afios.
valente a 840 x 2 = 1.680 LDC para 10s dos meses La ecuacion de esfuerzo de desarrollo puede relacionar-
restantes antes de la entrega. La productividad del se con el coste de desarrollo con la inclusi6n de un fac-
equipo es ahora 20.000 + 1.680 - (250 x 14) = 18.180 tor de coste laboral del trabajo ($/personas-afio).
LDC/afio. Esto lleva a unos interesantes resultados. Considere
un proyecto complejo de software de tiempo real esti-
mado en 33.000 LDC, un esfuerzo de 12 personas-aiio.
Si se han asignado ocho personas a1 equipo del proyecto.
el proyecto puede estar terminado en 1,3 afios. Sin
Lo relaci6n entre el numero de personas que trabojan embargo, si extendemos la fecha de finalizacion a 1,75
en un proyecto de softwore y lo productividod total aiios, la naturaleza altamente no lineal del modelo des-
no es lined. crito en la Ecuacion (7.1) lleva a:
Aunque el ejemplo anterior es una burda simplifica-

-
E = L~ I (p3 t4) 3,8 personas-aiio
ci6n exagerada de las circunstancias del mundo real, Esto implica que extendiendo la fecha de finaliza-
sirve para ilustrar otro punto clave: la relaci6n entre el ci6n seis meses, ipodemos reducir el numero de perso-
numero de personas que trabajan en un proyecto de soft- nas desde ocho hasta cuatro! La validez de estos
ware y la productividad global no es lineal. resultados esta abierta a debate, per0 la implicaci6n es
clara: se pueden obtener beneficios usando menos gen-
7.2.2. Una relacibn empirica te durante un period0 de tiempo algo mayor para reali-
zar el mismo trabajo.
Recordando la ccecuacion del software>>[PUT921 que
se introdujo en el Capitulo 5 , podemos demostrar la
relacion altamente no lineal entre el tiempo cronol6- 7.2.3. Distribucibn del esfuerzo
gico para completar un proyecto y el esfuerzo huma- Cada una de las tCcnicas de estimaci6n del proyecto de
no aplicado a1 proyecto. El numero de lineas de c6digo software tratadas en el Capitulo 5 lleva a estimaciones
entregadas (sentencias fuente), L , esta relacionado de las unidades de trabajo (por ejemplo, personas-mes)
con el esfuerzo y el tiempo de desarrollo por la ecua- requeridas para completar un desarrollo de software. Una
ci6n: distribution recomendada de esfuerzo en las fases de
Es posible presentar un argument0 en contra: la comunicacion, si

e s efectiva, puede aumentar la calidad del trabajo que se esta reali-
zando, reduciendo, por tanto, la cantidad de repasos y aumentando
la productividad individual de 10s miembros del equipo. iTodavia no
hay veredicto final!
INGENIER~A
DEL SOFTWARE. UN ENFOQUE P R ~ C T I C O
definition y desarrollo se conoce normalmente como la den comprender de un 10 a un 25 por 100 del esfuer-
regla 40-20-407.El cuarenta por ciento de todo el esfuerzo del proyecto. El esfuerzo invertido en analisis o
zo o m b se asigna a las tareas de analisis y diseiio. Un creaci6n de prototipos deberia crecer proporcional-
porcentaje similar se aplica a las pruebas. Se puede dedu- mente con el tamaiio y la complejidad del proyecto.
cir correctamente que no se insiste mucho en la creaci6n Entre un 20 y un 25 por 100 del esfuerzo se aplica
de c6digo (un 20 por 100 del esfuerzo). normalmente a1 diseiio del software. TambiCn debe
considerarse el tiempo empleado en la revision del
iCu6nt0 esfuerzo deberia disefio y la repeticion subsiguiente.
emplearse en cada una de Debido a1 esfuerzo aplicado a1 diseiio de software, el
las princripales tareas de codigo deberia realizarse con relativa poca dificultad. Se
ingenieria del software? puede alcanzar un rango d e l l 5 a1 20 por 100 del esfuer-
zo global. Las pruebas y las subsiguientes depuraciones
Esta distribution de esfuerzo deberia usarse como de errores pueden dar cuenta de entre un 30 y un 40 por
una directriz solamente. Las caracteristicas de cada 100 restante del esfuerzo de desarrollo del software. La
proyecto dictan la distribuci6n del esfuerzo. El esfuer- importancia del software dicta a menudo la cantidad de
zo gastado en la planificaci6n de un proyecto rara- pruebas que se requieren. Si el software se ve desde el
mente supera mds del 2 6 el 3 por 100, a no ser que punto de vista humano (es decir, el fa110 del software
el plan comprometa a una organizaci6n a grandes gas- puede generar pCrdidas de vidas humanas), se pueden
tos por el gran riesgo. El andlisis de 10s requisitos pue- considerar incluso porcentajes mas altos.
En el Capitulo 2 se describieron diferentes modelos de ciplina para alcanzar una alta calidad para el software.
proceso. Estos modelos ofrecen paradigmas diferentes Pero, a1 mismo tiempo, no se debe cargar a1 equipo del
para el desarrollo del software. Independientemente de proyecto con trabajo innecesario.
que un equipo de software elija un paradigma secuen- Los conjuntos de tareas se diseiian para acomodar
cia1 lineal, uno iterativo, uno evolutivo, uno concurrente diferentes tipos de proyectos y diferentes grados de rigor.
o alguna combinaci6n, el modelo de proceso estd lleno Aunque es dificil desarrollar una completa taxonomia
de conjuntos de tareas que permiten a1 equipo del soft- sobre 10s tipos de proyectos de software, la mayoria de
ware definir, desarrollar y finalmente mantener el soft- las organizaciones de software encuentran proyectos de
ware de computadora. 10s siguientes tipos:
No hay un unico conjunto de tareas que sea apropia- I. Proyectos de desarrollo del concepto que se ini-
do para todos 10s proyectos. El conjunto de tareas que cian para explorar algun nuevo concepto de negocios o
seria apropiado para un sistema grande y complejo seria aplicaci6n de alguna nueva tecnologia.
considerado exagerado para un product0 de software
pequeiio, relativamente sencillo. Por tanto, un proceso de 11. Proyectos de desarrollo de una nueva aplicaci6n
software eficaz deberia definir una colecci6n de conjun- que se aceptan como consecuencia del encargo de un
tos de tareas, cada una diseiiada para satisfacer las nece- cliente especifico.
sidades de diferentes tipos de proyectos. 111. Proyectos de mejoras de aplicaciones que ocu-
rren cuando un software existente sufre grandes modi-
g ficaciones de su funcionamiento, rendimiento o
interfaces que son observables por el usuario final.
CLAVE
Un ((tonjunto de toreosa es uno colectibn de entregos, IV. Proyectos de rnantenimiento de aplicaciones que
hitos y toreos de ingenieria del software. corrigen, adaptan o amplian un software existente en
mCtodos que pueden no ser obvios de forma inmediata
U n conjunto de tareas es una coleccidn de tareas de para el usuario final.
la ingenieria del software, hitos y entregas que deben V. Proyectos de reingenieria que se lleva a cab0 con
realizarse para completar un proyecto particular. El con- la intention de reconstruir un sistema existente (here-
junto de tareas a elegir debe proporcionar suficiente dis- dado) en su totalidad o en parte.
7 Hoy en dia, se recomienda normalmente aplicar al analisis y a las

tareas de disetio de grandes proyectos de desarrollo de software mas
del40 por 100 de todo el esfuerzo del proyecto. De ahi que el nom-
bre de ((40-20-4011no se aplique en un sentido estricto.
C A P ~ T U L O7 P L A N I F I C A C I 6 N T E M P O R A L Y S E G U I M I E N T O DEL P R O D U C T 0
Incluso dentro de un tip0 de proyecto simple, hay

muchos factores que influyen en el conjunto de tareas
a elegir. Cuando se toman en combinaci6n, estos fac- Si todo es uno emergencio, hobra olgo mol en su proceso
tores proporcionan una indicaci6n del grado de rigor del softwore o en 10s personos que lo dirigen o en ombos
con el que deberia aplicarse el proceso del software.
El gestor del proyecto debe desarrollar un enfoque
sistemitico para seleccionar el grado de rigor apropia-
7.3.1. Grado de rigor do para cada proyecto. Para conseguirlo, se definen unos
criterios de adaptacion del proyecto y se calcula un valor
selector del conjunto de tareas.
7.3.2. Definir 10s criterios de adaptaci6n

El coniunto de toreos crecera en tomono y compleiidod Los criterios de adaptacibn se emplean para determi-
al mismo tiempo que crece el grodo de rigor. nar el grado de rigor recomendado con el que el proce-
so del software deberia aplicarse en un proyecto. Se
Incluso para un proyecto de un tip0 en particular, el gra- definen once criterios de adaptacion para proyectos de
do de rigor con el que se aplica el proceso del softwa- software [PRE99]:
re puede variar significativamente. El grado de rigor es
Tamaiio del proyecto.
funcion de muchas caracteristicas del proyecto. Por
ejemplo, 10s pequefios proyectos no criticos del nego- Numero potencial de usuarios.
cio pueden ser tratados con algo menos de rigor que Importancia de la misi6n.
grandes y complejas aplicaciones criticas desde el pun- Antigiiedad de la aplicacion.
to de vista del negocio. Debe advertirse, no obstante, Estabilidad de 10s requisitos.
que todos 10s proyectos deben ejecutarse de manera que Facilidad de comunicaci6n cliente/desarrollador.
terminen en puntuales entregas de alta calidad. Se pue-
den definir cuatro grados de rigor: Madurez de la tecnologia aplicable.
Casual. Se aplican todas las actividades estructura- Limitaciones de rendimiento.
les del proceso (Capitulo 2), per0 so10 se requiere un Caracteristicas empotradas/no empotradas.
conjunto de tareas minimo. En general, las tareas pro- Personal del proyecto.
tectoras se minimizaran y se reduciran 10s requisitos de Factores de reingenieria.
documentacion. Son aplicables todavia todos 10s prin-
cipios basicos de la ingenieria del software.
Estructurado. Se aplicara la estructura del proceso
a este proyecto. Se aplicaran las actividades estructura-
les y las tareas relativas apropiadas para el tip0 de pro-
yecto, asi como las actividades protectoras necesarias
Modelo de proceso odoptoble
para garantizar una alta calidad. Se llevaran a cab0 SQA
(GCS), documentaci6n y tareas de medicion de mane- A cada uno de 10s criterios de adaptaci6n se le asig-
ra fluida. na un grado que va desde 1 hasta 5 , donde 1 represen-
Estricto. Se aplicara el proceso completo para este ta un proyecto en el que se requiere un pequefio
proyecto con un grado de disciplina tal que garantice una subconjunto de tareas de proceso, y 10s requisitos gene-
alta calidad. Se aplicaran todas las actividades protecto- rales metodol6gicos y de documentaci6n son minimos,
ras y se producira una robusta documentaci6n. y 5 representa un proyecto en el que se deberia aplicar
un conjunto completo de tareas de proceso y en el que
Reaccion rapida. Se aplicara la estructura del pro-
10s requisitos generales metodologicos y de documen-
ceso a este proyecto, per0 debido a una situation de
taci6n son sustanciales.
emergencias, so10 se aplicaran aquellas tareas esen-
ciales para mantener una alta calidad. Se realizara un
<<back-filling>>
(es decir, desarrollar un conjunto com- 7.3.3. Calculo del valor selector del conjunto
pleto de documentaci6n, realizar revisiones adicio- de tareas
nales) despuks de entregar la aplicaci6n/producto a1 Para seleccionar el conjunto apropiado de tareas para
cliente. un proyecto, se deberian seguir 10s siguientes pasos:
8 Las situaciones de emergencia deberian ser raras (no deberia ocu-

rrir en mas de un I0 por 100 de todo el trabajo realizado dentro del
context0 de la ingenieria del software). Una emergencia no e s lo
mismo que un proyecto con apretadas limitaciones de tiempo.
1. Revise cada uno de 10s criterios de adaptaci6n en la

~Comoelegimos el conjunto
Secci6n 7.3.2 y asigne 10s grados apropiados (1 a 5)
de tareas apropiado para
bashdose en las caracteristicas del proyecto. Estos
nuestro proyecto?
grados deberian introducirse en la Tabla 7.1.
Criterios de Adaptacion Grado Peso Multiplicador de punto de entrada Producto

- - - - - - - - -
Concur. Ndev. Mejora Mant. Reing.
Tamatio del proyecto

N ~ j m e r ode usuarios
lmportancia para el negocio
Antiguedad
Estabilidad de 10s requisitos
Facilidad de Comunicacion
Madurez de la tecnologia
Limitaciones de rendimiento
Empotrado/no empotrado
Personal del proyecto
lnteroperabilidad
Factores de reingenieria
Selector de conjunto de tareas (SCT) -
TABLA 7.1. CALCULO DEL SELECTOR DEL CONJUNTO DE TAREAS. UN EJEMPLO
Revise 10s factores de ponderacibn asignados a 0 y 1, e indica la importancia del criterio de adaptaci6n
cada criterio. El valor de un factor de ponderaci6n para el tip0 de proyecto. El resultado del producto:
va desde 0.8 a 1.2 y proporciona una indication de
Grado x factor de ponderacion x multiplicador
la relativa importancia de un criterio de adaptaci6n
de punto de entrada
en particular a 10s tipos de software desarrollados
dentro del entomo local. Si son necesarias modifi- se coloca en la columna Producto de la Tabla 7.1
caciones para reflejar mejor las circunstancias loca- para cada criterio de adaptaci6n individual.
les, se deberian hacer. 4. Calcule la media de todas las entradas en la columna
Multiplique el grado introducido en la Tabla 7.1 por el Producto y ponga el resultado en el espacio mar-
factor de ponderacion (peso) y por el multiplicador cad0 selector del conjunto de tareas (SCT). Este valor
de punto de entrada del tip0 de proyecto a realizar. El se usarfi para ayudarle a seleccionar el conjunto de
multiplicador de punto de entrada toma un valor entre tareas mAs apropiado para el proyecto.
Criterios de Adaptacion Grado Peso Multiplicador de punto de entrada Product0

Concur. Ndev. Mejora Mant. Reing.
Tamaiio del proyecto

Numero de usuarios
lmportancia para el negocio
Antiguedad
Estabilidad de 10s requisitos
Facilidad de Comunicacion
Madurez de la tecnologia
Limitaciones de rendimiento
Empotrado/no empotrado
Personal del proyecto
lnteroperabilidad
Factores de reingenieria
Selector de conjunto de tareas (SCT)
TABLA 7.2. CALCULO DEL SELECTOR DEL CONJUNTO DE TAREAS. UN EJEMPLO

118
CAPiTULO 7 P L A N I F I C A C I 6 N T E M P O R A L Y S E G U I M I E N T O DEL P R O D U C T 0
7.3.4. Interpretar el valor SCT y seleccionar ras tan definidas cuando se seleccionan conjuntos de
el conjunto de tareas tareas. En el analisis final, el valor del selector del con-
Una vez que se ha calculado el selector del conjunto de junto de tareas, la experiencia acumulada y el sentido
tareas, se pueden utilizar las siguientes directrices para com6n deben tenerse en cuenta en la eleccidn del con-
seleccionar el conjunto de tareas apropiado para un pro- junto de tareas para el proyecto.
yecto: La Tabla 7.2 ilustra c6mo podria calcularse el SCT
para un hipotktico proyecto. El gestor del proyecto selec-
Valor del selector ciona 10s grados mostrados en la columna Grado. El
del conjunto de tareas Grado de rigor tipo de proyecto es el desarrollo de una nueva aplica-
SCT < 1,2 Casual ci6n. Por tanto, 10s multiplicadores de punto de entra-
1.0 < SCT < 3,O Estructurado da se seleccionan de la columna NDev. La entrada en
SCT > 2,4 Estricto la columna Producto se calcula empleando
Grado x Peso x Multiplicador de punto
de entrada Ndev(NewDeve1op.)
Si el volor del seledor del conjunto de toreos es un dreo
solopado, normolmente es correcto elegi el menor grdo de
El valor de SCT (calculado corno la media de todas
rigor formal, o no ser que el riesgo delproyecto sea alto. las entradas de la columna Producto) es 2,8. Usando 10s
criterios estudiados anteriormente, el gestor tiene la
El solapamiento en 10s valores SCT de un conjunto opci6n de usar tanto el conjunto de tareas estructurado
de tareas recomendado con otro esta hecho a prop6si- como el estricto. La decisi6n se toma una vez que se
to y pretende ilustrar que no son posibles unas fronte- han considerado todos 10s factores del proyecto.
Para desarrollar una planificacion temporal del proyecto, Los proyectos de desarrollo de concepto se inician
se debe distribuir un conjunto de tareas a lo largo de la cuando se debe explorar el potencial de alguna nueva
duraci6n del proyecto. Como apuntamos en la Secci6n tecnologia. No hay certeza de que la tecnologia sea apli-
7.3 el conjunto de tareas variara dependiendo del tipo de cable, per0 el cliente (por ejemplo, marketing) Cree que
proyecto y del grado de rigor. Cada uno de 10s tipos de existe un beneficio potencial. Los proyectos de desa-
proyectos descritos en la Seccion 7.3 puede enfocarse rrollo de concepto se enfocan aplicando las siguientes
usando un modelo de proceso lineal secuencial e iterati- tareas principales:
vo (por ejemplo, el modelo incremental o de creaci6n de
Ambit0 del concept* determina el ambit0 gene-
prototipos) o evolutivo (por ejemplo, el modelo en espi-
ral del proyecto.
ral). En algunos casos, un tip0 de proyecto fluye suave-
mente hacia el siguiente. Por ejemplo, 10s proyectos de Planificacion preliminar del concept* estable-
desarrollo de concepto que tienen Cxito evolucionan a ce la capacidad de la organizacidn para llevar a cab0 el
menudo en nuevos proyectos de desarrollo de aplicacidn. trabajo implicado por el ambito del proyecto.
Cuando termina un proyecto de desarrollo de una nueva Valoracion del riesgo tecnologic* eval6a el ries-
aplicaci61-1,empieza a veces un proyecto de mejora de la go asociado con la tecnologia a implementar como par-
aplicacicin. Esta progresidn es natural y predecible y ocu- te del proyecto.
rrira sea cual sea el modelo de proceso que adopte una Prueba de concept* demuestra la viabilidad de
organizaci6n. Por consiguiente, las principales tareas de una nueva tecnologia en el context0 del software.
ingenieria del software descritas en las secciones siguien- Implernentacion del concepto- implementa la
tes son aplicables a todos 10s flujos del modelo de proce- representaci6n del concepto de manera que pueda revi-
so. Como ejemplo, consideremos las tareas principales de sarlo un cliente y se emplea para propdsitos de ccmar-
ingenieria para 10s proyectos de desarrollo de concepto. keting>>cuando hay que vender un concepto a otros
clientes o departamentos de gesti6n.
Reaccion del cliente ante el concept* solicita la opi-
ni6n del cliente sobre un nuevo concepto de tecnologia y
va encaminada a aplicaciones especificas del cliente.
No deberian producirse sorpresas si echamos un vis-
Un modelo de proceso adoptable tazo rapid0 a estas tareas principales. De hecho el flujo
(MPA) completo incluye uno de las tareas de ingeniena del software para proyectos
voriedod de coniuntos de toreos de desarrollo de concepto (y tambiCn para 10s otros tipos
y estb disponible para su uso. de proyectos) es poco mas que sentido com6n.
CAPITULO 7 P L A N I F I C A C I ~ NT E M P O R A L Y S E G U I M I E N T O DEL P R O D U C T 0
Caso de: procedimientos Procedimientos = Analisis estructurado

Procedimientos = despl iegue de l a funcidn obtener un diagrama de flujo de datos a nivel
calidad de contexto;
reunirse con e l c l i e n t e para a i s l a r 10s refinar el diagrama de flujo de datos para
principales requisitos del concepto; proporcionar mas d e t a l l e s ;
entrevistar a 10s usuarios finales; escribir narrativas de proceso para l a s fun-
observar el enfoque actual a1 problema, pro- ciones a ma's bajo nivel de refinamiento;
ceso actual; Procedimientos = visidn de objeto
revisar requisitos y quejas anteriores; definir operaciones/m&odos relevantes para
PI-ocedimientos = a n d l i s i s estructurado cada clase;
fin caso
hacer una l i s t a de 10s objetos de datos
principales; 1.1.3.3. Revisar funciones/comportamientos con
definir l a s relaciones entre 10s objetos; el c l i e n t e y r e v i s a r segfin sea necesa-
rio;
definir 10s atributos de 10s objetos;
Fin de tarea Tarea I . 1.3
Procedimientos = visidn del objeto
1.1.4. Aislar aquellos elementos de l a tecnologia a
hacer una l i s t a de l a s clases de problemas;
implementar en software;
desarrollar l a jerarquia de clases y l a s
1.1.5. Investigar l a disponibilidad de informacidn
conexiones de clases; sobre el software e x i s t e n t e ;
definir 10s atributos de l a s clases; 1.1.6. Definir viabilidad tgcnica;
f i ~caso I . 1.7. Hacer una estimacidn rSpida del tamafio;
1.1.2.3. RTF: revisar l a s entradaslsalidas con el 1.1.8. Crear una definicidn de rimbito;
c l i e n t e y adaptar segfin se requiem;
Fin de tarea: Tarea I . 1
Fin de tarea Tarea I . 1.2
1 . 1 . 3 . Definir l a funcionalidad/comportamiento para
cada funcidn principal que es desarrollada;
Empezar Tarea I . 1.3
1 . 1 . 3 . 1 . RTF: r e v i s a r 10s objetos de datos de
entrada y salida obtenidos en l a tarea
I . 1 . 3 . 2 . Obtener un modelo de f unciones/compor-
tamientos; El rnodelo de proteso adaptable
Caso de: procedimientos (MPA) tontiene una destriptibn
Procedimien t o s = Despliegue de l a f uncidn del lenguaie de diseiio de
calidad procesos cornpleta para todas las
reunirse con el c l i e n t e para r e v i s a r 10s tareas de ingenieria del software.
requisi tos del concepto principal;
entrevistar a 10s usuarios finales;
observar el enfoque actual del problema, Las tareas y subtareas apuntadas en el refinamiento
proceso actual; del lenguaje de diseiio del proceso forman la base para
desarrollar un esquema jerdrquico de fun- una planificaci6n temporal detallada de las actividades
ciones/comportarnientos; del Ambito del concepto.
Las tareas y subtareas individuales tienen interdepen- Una red de tareas, tambiCn llamada red de activida-
dencias basadas en su secuencia. Ademas, cuando hay des, es una representaci6n grfifica del flujo de tareas de
m8s de una persona implicada en un proyecto de inge- un proyecto. Se emplea a veces como el mecanismo
niena del software, es probable que las actividades de a travCs del cual se introduce la secuencia de tareas y
desarrollo y tareas se realicen en paralelo. Cuando ocu- las dependencias en una herramienta de programaci6n
rre esto, las tareas concunentes deben coordinarse de automhtica de la planificacidn temporal de un pro-
manera que estCn finalizadas cuando tareas posteriores yecto. En su fonna m& sencilla (la que se emplea en
requieran su(s) resultado(s). una planificacih temporal macroscbpica), la red de
tareas muestra las tareas principales de ingenieria del
software. La Figura 7.3 muestra una red de tareas
esquemhtica para un proyecto de desarrollo de con-
cepto.
La red de tareas es un rnecanismo irtil La naturaleza concurrente de las actividades de inge-
para representar la dependencia entre tareas nieria del software lleva a varios requisitos importan-
y para deterrninar el carnino critito. tes de la planificaci6n temporal. Como las tareas
paralelas ocurren asincronamente, el planificador debe
determinar las dependencias entre las tareas para garan-
tizar un progreso continuo hasta su finalizaci6n. Ade-
mas, el gestor del proyecto deberia estar a1 tanto de las
tareas que pertenecen a1 camino critico. Es decir, tare-
as que deben finalizarse segun la planificacion tempo-
ral si se quiere que el proyecto en general se termine a
tiempo. Estos aspectos se tratan con mis detalle mhs
adelante en este capitulo.
Es importante resaltar que la red de tareas mos-
trada en la Figura 7.3 es macrosc6pica. En una red
de tareas detallada (el precursor de la planificacion
temporal detallada) cada actividad mostrada en la Se aplican 3 tareas 1.3. Se aplican 3 tareas 1.5.
Figura 7.3 se expandiria. Por ejemplo, la Tarea I. 1 se en paralelo a 3 funciones en paralelo a 3funciones
de conceplo diferentes de concept0 diferentes
expandiria para mostrar todas las tareas detalladas en
el refinamiento de tareas 1.1 mostrado en la Sec- FIGURA 7.3. Una red de tareas para un proyecto
cion 7.5. de desarrollo de concepto.
La planificacion temporal de un proyecto de software blecer las dimensiones de tiempo ccmas probablew
no difiere mucho del de cualquier esfuerzo de ingenie- para las tareas individuales aplicando modelos esta-
ria multitarea. Por tanto, se pueden aplicar herramien- disticos, y (3) calcular las limitaciones de tiempo que
tas de planificacion temporal de proyectos y tCcnicas definen una ccventana>>de tiempo de una tarea deter-
generales a1 software con una pequefia modificacion en minada.
10s proyectos del software. Los calculos de las limitaciones de tiempo pueden
ser muy litiles en la planificacion temporal de proyec-
tos de software. El retraso en el disefio de una funcion,
por ejemplo, puede retardar el posterior disefio de otras
Poro 10s proyectos m6s sencillos, lo p/onikoci6n tempo101 funciones. Riggs [RIG811 describe importantes limita-
deberio reolizorse con lo oyudo de uno herromiento ciones de tiempo que pueden discernirse de una red
de plonificocion temporal de proyectos. PERT o CPM: (1) lo antes posible que puede empezar
La te'cnica de evaluacidn y revisidn de programa una tarea cuando las tareas precedentes se completen
(PERT)y el mktodo del camino critico (CPM) [MOD831 tambiCn lo antes posible; (2) lo mas tarde que se puede
son dos mCtodos de la planificacion temporal de un pro- empezar una tarea antes de que se retrase el tiempo mini-
yecto que pueden aplicarse a1 desarrollo de software. mo para finalizar el proyecto; (3) la fecha mas tempra-
Ambas tkcnicas son dirigidas por la informacion ya desa- na de finalizacion -la suma de la fecha mhs temprana
rrollada en actividades anteriores de la planificacion del de inicio y la duraci6n de la tarea-; (4) la fecha limi-
proyecto: te de finalizacion -la fecha mis tardia de inicio suma-
da a la duracion de la tarea-, y (5j el margen total -la
Estimaciones de esfuerzo. cantidad de tiempo extra o atrasos permitidos en la pla-
Una descomposicion de la funcidn del producto. nificacion temporal de las tareas de manera que el cami-
La seleccidn del modelo de proceso adecuado y del no critico de la red se mantenga conforme a la
conjunto de tareas. planificaci6n temporal-. Los calculos de 10s tiempos
La descomposicion de tareas. limite llevan a la determination del camino critico y
proporcionan a1 gestor un mCtodo cuantitativo para eva-
Las interdependencias entre las tareas deben defi- luar el progreso a medida que se completan las tareas.
nirse empleando una red de tareas. Las tareas, a veces
denominadas estructura de descomposicidn del tra-
bajo del proyecto (en inglCs, WBS), se definen para el
producto como un todo o para las funciones indivi-
duales.
Tanto PERT como CPM proporcionan herramien-
tas cuantitativas que permiten a1 planificador del soft- Herramientos CASE
ware : (1) determinar el camino cl-itico, la cadena de para la plonificocibn temporal
tareas que determina la duracion del proyecto; (2) esta- y programacibn del proyecto.
C A P ~ T U L O7 TEMPORAL Y SEGUIMIENTO DEL P R O D U C T 0
PLANIFICACI~N
Tanto PERT como CPM se han implementado en Ademas, se asignan las tareas a individuos especificos.
varias herramientas automaticas disponibles virtual-
mente para todos 10s ordenadores personales [THE93].
Tales herramientas son faciles de usar y hacen asequi-
bles 10s mCtodos de la planificacion temporal descritos
g
anteriormente a todos 10s gestores de proyectos de soft- CLAVE
ware. Un grafico de tiempo le permite conocer que tureus serun
conducidos en un punto determinudo en el tiempo.
7.7.1. Graficos de tiempo
Cuando se crea una planificacion temporal de un pro-
yecto de software, el planificador empieza un con- Como consecuencia de esta entrada, se genera un
junto de tareas (la estructura de descomposici6n del grhfico de tiempo, tambiCn denominado Grafico Gantt.
trabajo). Si se emplean herramientas automaticas, la Se puede desarrollar un grafico de tiempo para todo el
descomposicion del trabajo es introducida como una proyecto. Altemativamente, se pueden desarrollar dife-
red de tareas o esquema de tareas. El esfuerzo, dura- rentes graficos para cada funci6n del proyecto o para
ci6n y fecha de inicio son las entradas de cada tarea. cada individuo que trabaje en el proyecto.
Tareas Semana 1 Semana 2 Semana 3 Semana 4 ana 5
1.1 ldentificar necesidades y beneficios

Reunirse con los clientes
Identificar las necesidades y las limitaciones
del proyecto
Establecer la declaracidn de producto
Hito: declaraci6n de producto definida
.1.2 Definir las salidas/control/entradas deseadas (SCE
Alcance de las funciones del teclado
Alcance de las funciones de entrada de voz
Alcance de 10s modos de interaccion
Alcance de documento de diagndsticos
Alcance otras funciones W P
Documento SCE
RTF: revisar el SCE con el cliente
Revisar el SCE segiin se requiera
Hito: SCE definido
.1.3 Definir la funcionalidad/comportamiento
Definir las funciones del teclado
Definir las funciones de entrada de voz
Describir los modos de interaccion
Describir las comprobaciones de ortografial
gramatica
Describir otras funciones WP
RTF: Revisar la definicidn SCE con el cliente
Revisar sepin sea necesario
Hito: Definicidn de SCE completa
L.1.4 Aislar los elementos soRware
Hito: Elementos software definidos
1.1.5 Investigar la disponibilidad del software existente
Investigar 10s componentes de edicion de texto
Investigar 10s componentes de la entrada de voz
Investigar 10s componentes de la administration
de archivos
Investigar 10s componentes de la comprobacion
de ortografia y gramatica
Hito: Componentes reutilizables identificados
1.1.6 Definir la viabilidad tecnica
Evaluar la entrada de voz
Evaluar la comprobaci6n de gramatica
Hito: Viabilidad tecnica valorada
1.1.7 Hacer una estimacion rapida del tamafio
1.1.8 Crear una definicidn de ambit0
Revisar el documento de dmbito con el diente
Revisar el documento se&n se requiera
Hito: Documento de dmbita completo
FIGURA 7.4. Un ejemplo de grafico de tiempo.

1NGENIERfA DEL SOFTWARE. UN ENFOQUE PRACTICO
La Figura 7.4 ilustra el formato de un grifico de tiem- progreso hasta la fecha y 10s problemas que se ave-
po. Muestra una parte de la planificacidn temporal de cinan, o
un proyecto de software que enfatiza la tarea de Bmbi- utilizando el anilisis del valor ganado (Secci6n 7.8)
to del concepto (Secci6n 7.5) para un nuevo producto para evaluar el progreso cuantitativamente.
de software de procesador de textos. Todas las tareas
del proyecto (para Bmbito del concepto) se listan en la
columna de la izquierda. Las barras horizontales indi-
can la duraci6n de cada tarea. Cuando aparecen mlilti- N mejor indicador del progreso es lo finolizacion
ples barras a1 mismo tiempo en la planificaci6n temporal, y la revisibn exitosa de on praducto de software.
implican concurrencia de tareas. Los rombos indican
hitos. El control lo usa el gestor para administrar 10s recur-
Una vez que se ha introducido la information nece- sos del proyecto, enfrentarse a 10s problemas y dirigir
saria para generar el grBfico de tiempo, la mayoria de a1 personal del proyecto. Si las cosas van bien (es decir,
las herramientas de la planificaci6n temporal de pro- el proyecto va seglin la planificaci6n temporal y dentro
yectos de software producen tablas de proyecto -un del presupuesto, las revisiones indican que se estB
1istado.tabular de todas las tareas del proyecto, sus haciendo un progreso real y que se e s t b alcanzando 10s
fechas previstas y reales de inicio y finalizaci6n, e hitos), el control es liviano. Pero cuando aparecen 10s
informaci6n varia relativa a1 tema- (Fig. 7.5). Em- problemas, el gestor debe ejercer el control para solu-
pleando las tablas junto con 10s grificos de tiempo, le cionarlos tan pronto como sea posible. Una vez que el
permiten a1 gestor del proyecto hacer un seguimiento problema se ha diagnosticadolo, se pueden concentrar
del progreso. recursos adicionales en el irea del problema: se puede
redistribuir la plantilla, o se puede redefinir la planifi-
caci6n temporal del proyecto.
7.7.2. Seguimiento de la planificacibn temporal Cuando se enfrentan a la presi6n de una fecha de
La planificaci6n temporal del proyecto le proporcio- entrega muy ajustada, 10s gestores de proyecto utilizan
na a1 gestor un mapa de carreteras. Si se ha desarro- a veces una planificaci6n temporal de proyecto y una
llado apropiadamente, define las tareas e hitos que tecnica de control denominada time-boxing (tiempo
deben seguirse y controlarse a medida que progresa el encajonado) [ZAH95]. Esta estrategia reconoce que qui-
proyecto. El seguimiento se puede hacer de diferentes zBs no se pueda entregar el producto completo para la
maneras: fecha limite predefinida. Por tanto, se elige un paradig-
realizando reuniones peri6dicas del estado del pro- ma incremental del software (Capitulo 2) y se crea una
yecto en las que todos 10s miembros del equipo infor- planificaci6n temporal para cada entrega de un incre-
man del progreso y de 10s problemas; mento.
evaluando 10s resultados de todas las revisiones reali- Las tareas asociadas con cada incremento se enca-
zadas a lo largo del proceso de ingenieria del software; jonan en el tiempo. Esto significa que la planificacih
temporal para cada tarea se ajusta trabajando hacia atris
desde la fecha de entrega para cada incremento. Se pone
una <<caja>> alrededor de cada tarea. Cuando una tarea
estodo del alcanza el limite de su caja de tiempo (mBs o menos un
mse: (( j ninguno 10 por loo), se termina el trabajo y se empieza la
siguiente tarea.
La primera reacci6n frente a1 enfoque de encajona-
miento de tiempo es a menudo negativa: <<Sino se ha
terminado el trabajo, jc6m0 podemos proseguir?,, La
determinando si se han conseguido 10s hitos forma- respuesta se encuentra en la manera en que se realiza el
les del proyecto (10s rombos mostrados en la Fig. 7.4) trabajo. Cuando se llega a1 limite de la caja de tiempo,
en la fecha programada; es probable que se haya completado el 90 por 100 de la
comparando la fecha real de inicio con las previstas tarea". El restante 10 por 100, aunque importante, pue-
para cada tarea del proyecto listada en la tabla del de (1) retrasarse hasta el siguiente incremento, o (2)
proyecto (Fig. 7.5); completarse mis tarde si es necesario. En vez de estar
reuniendose informalmente con 10s profesionales del <<estancado>> en una tarea, el proyecto progresa hacia la
software para obtener sus valoraciones subjetivas del fecha de entrega.
l o Es importante resaltar que un retraso del programa e s un sintoma Un cinico podria recordar el dicho: ((Elprimer 90 por 100 de un sis-
de algun problema oculto. El papel del gestor e s diagnosticar cual e s tema se lleva el 10 por 100 del tiempo. El ultimo 10 por 100 del sistema
el problema y actuar para corregirlo. se lleva el 90 por 100 del tiempo..
CAPfTULO 7 P L A N I F I C A C I ~ NT E M P O R A L Y SEGUIMIENTO DEL P R O D U C T 0
lnicio lnicio Terminaci6n Terminaci6n Personas

Tareas de trabajo Obsewaciones
previsto real prevista real asignadas
ldentificar necesidades y beneficios Es previsible
Reunirse con 10s clientes Sem 1,dl Sem 1,dl Sem l,d2 Sem l,d2 BLS 2 p-d que requiera
ldentificar las necesidades y limitaciones Sem 1.d2 Sem l,d2 Sem l,d2 Sem l,d2 JPP 1 p-d m8s esfuerzol
del proyecto tiempo
Establecer la declaracion del producto Sem l,d3 Sem 1.d3 Sem l,d3 Sem l,d3 BLSIJPP 1 p-d
Hito: declaracion de producto definida Sem l,d3 Sem l,d3 Sem l,d3 Sem l,d3
Definir las salidas/control/entradas
deseadas W E )
Ambito de las funciones del teclado Sem l,d4 Sem l,d4 Sern 2.d2 BLS 1,5 p-d
Ambito de las funciones de entrada de voz Sem 1.d3 Sem l,d3 Sern 2,d2 JPP 2 p-d
Ambito de 10s modos de interaccidn Sern 2,dl Sern 2,d3 MLL 1 p-d
Ambito de 10s diagn6sticos del documento Sem 2,dl Sern 2,d2 BLS 1.5 p-d
Ambito de otras funciones WP Sem l,d4 Sern l,d4 Sern 2.d3 JPP 2 p-d
Documento SCE Sem 2,dl Sem 2.d3 MLL 3 p-d
RTF : revisar SCE con el cliente Sem 2.d3 Sern 2.d3 Todos 3 p-d
Revisar SCE segljn se requiera; Sem 2.d4 Sern 2.d4 Todos 3 D-d
Hito: SCE definido Sem 2.d5 Sern 2.d5
1.1.3 Definir la funcionalidadlcomportamiento
FIGURA 7.5. Un ejemplo de t a b l a de proyecto.
En la seccih 7.7.2, ya discutimos un numero de aproxi- Para determinar el valor ganado se desarrollan 10s
maciones cualitativas a1 seguimiento del proyecto. Cada siguientes pasos:
una de ellas proporciona al gestor del proyecto una indi- 1. El coste presupuestado del trabajoplanificado (CPTP)
caci6n del progreso, pero teniendo en cuenta que esta eva- se determina para cada tarea de trabajo que se repre-
luacih proporcionada de la informaci6n es en cierto modo senta en el plan. Durante la actividad de estimaci6n
subjetiva. Ahora bien, jes razonable preguntarse si exis- (Capitulo 3,el trabajo (en personas-hora, personas-
te una tkcnica cuantitativapara evaluar el progreso a medi- dia) de cada tarea de ingenieria del software es con-
da que el equipo de software avanza a travCs de las tareas venientemente planificada. Por consiguiente, CPTPi
de trabajo asignadas en la planificacih del proyecto? En es el trabajo que se ha planificado para una cierta tarea
efecto, una tkcnica para desarrollar anilisis cuantitativo i. Para determinar el progreso en un punto dado a lo
del progreso realizado existe. Es denominada andisis de largo de la planificacih del proyecto, el valor de CPTP
valor ganado (AVG). es la suma de 10s valores CFTPi para todas las tareas
del trabajo que deberian haber sido completadas en ese
momento en el plan del proyecto.
~Comose calcula el valor
El valor gonodo proporciono uno indicocibn cuontitotivo
del progreso.
ganado para evaluar
el progreso?
Humphrey [HUM951 estudia el valor ganado de la
manera siguiente: 2. Los valores CPTP para todas las tareas del trabajo
se suman para obtener el presupuesto a la termina-
El sistema de valor ganado proporciona una escalade valor
comun para cada tarea [proyecto de software], independiente-
cidn que se denomina PAT. Por consiguiente,
mente del tipo de trabajo que est6 siendo llevado a cabo. Se PAT = C (CPTP,) para todas las tareas k
estiman entonces el total de horn para realizar el proyecto com-
pleto y a cada tarea se le da un valor ganado basado en su por- 3. A continuacih, se calcula el valor para el coste pre-
centaje estimado respecto al total. supuestado del trabajo desarrollado (CPTD). El
valor para CPTD es la suma de 10s valores CPTP
Dicho de forma mas simple, el valor ganado es una
para todas las tareas de trabajo que hayan sido real-
medida del progreso. Nos permite evaluar el ccporcen-
mente terminadas en un punto determinado de la pla-
taje de realizaci6n~de un proyecto utilizando el anali-
nificaci6n del proyecto.
sis cuantitativo mis que la opini6n particular que de ello
tengamos. En efecto, Fleming y Koppleman [FLE98] Wilkens [WIL99] afirma que ccla distinci6n entre el
aducen que el anfilisis de valor ganado ccproporcionan CPTP y el CPTD es que el primer0 representa el pre-
unas lecturas exactas y fiables del desarrollo desde esta- supuesto de las actividades que estaban planificadas para
dos iniciales como cuando tan s610 se haya realizado un ser completadas, y el ultimo representa el presupuesto
15 por ciento del proyecto>>. de las actividades que realmente estaban acabadaw.
INGENIERfA DEL SOFTWARE. U N ENFOQUE PRACTICO
Dados 10s valores para CPTP, PAT, CPTD, pueden ser po de la planificacion del proyecto. Es entonces posi-
~calculados10s siguientes indicadores de progreso: ble calcular:
indice de desarrollo de planificacidn, IDP = CP'TD/ClTP indice de desarrollo del coste, IDC = CPTPICRTR
Varianza de la planificacidn, VP = CPTD - CPTP Varianza del coste, VC = CPTP - CRTR
IDP es una indicaci6n de la eficiencia con que el pro-
yecto esth utilizando 10s recursos de la planificacion.
Un valor IDP cercano a 1.0 indica una ejecuci6n efi-
ciente de la planificaci6n del proyecto. VP es simple-
mente una indicaci6n absoluta de la varianza de la Se puede encontror un gron conjunto de recunos
para el onalisis del valor gonodo (bibliogrofio complete,
planificaci6n prevista.
documentos, enlaces) en www.acq.osd.mil/pm/.
Porcentaje planijicado para terminar = CPTDPAT Un valor de IDC cercano a 1.0 proporciona una indi-
proporciona una indicaci6n del porcentaje de trabajo caci6n evidente de que el proyecto esth dentro del pre-
que deberia estar terminado en el instante t. supuesto que para Cl se ha definido. VC es una indicaci6n
absoluta de 10s ahorros en coste (en relaci6n con 10s cos-
Porcentaje completado = CPTPPAT
tes planificados) o de las carencias en una etapa parti-
proporciona una indicaci6n cuantitativa del <<grad0de cular del proyecto.
avance en la realizaci6n en tanto por cienton del pro- Como ya ocurri6 en la aparici6n del radar, el anhli-
yecto en un instante determinado de tiempo t. sis del valor ganado aclara las dificultades de planifica-
Es tambiCn posible calcular el coste real de traba- ci6n antes de que ellas puedan aparecer. Esto permite
jo realizado, CRTR. El valor para CRTR es la suma a1 gestor del proyecto de software tomar las acciones
del esfuerzo realmente desarrollado en tareas de tra- correctivas adecuadas antes de que la crisis del proyec-
bajo que hayan sido realizadas en un instante de tiem- to estalle.
A travCs del proceso de software, un equipo que se dedi- han encontrado en tareas posteriores) se considera que son
ca a1 proyecto crea productos de trabajo (por ejemplo, defectos llamados D. La eficiencia de eliminaci6n de
especificaciones de 10s requisitos o prototipos, docu- defectos (Capitulo 4) ha sido definida como:
mentos de diseiio, c6digo fuente). Pero este equipo tam- EED = EI(E+D)
biCn crea (y comge afortunadamente) errores asociados
con cada product0 de trabajo realizado. Si las medidas EED es una mCtrica de proceso que proporciona una indi-
relacionadas con 10s errores y las metricas resultantes caci6n clara de la efectividad de las actividades de garan-
son registradas a lo largo de muchos proyectos de soft- tia de calidad, per0 EED y el chlculo de errores y defectos
ware, un gestor de proyectos puede utilizar estos datos asociados con ella puede ser tambiCn usada para ayudar
como una linea base para comparar esto con 10s datos a1 gestor de proyectos a determinar el progreso que se esti
de errores recogidos en tiempo real. El seguimiento del realizando a medlda que el proyecto de software se mue-
error puede utilizarse como una medida para evaluar el ve a travCs de las tareas de trabajo planificadas.
estado del proyecto actual. Asumamos que una organizaci6n de software ha
registrado datos de errores y defectos durante 10s 24
meses pasados y ha desarrollado promedios para las
mCtricas siguientes:
Errores por pigina de especificaci6n de requisitos,
El seguimiento del error nos permite comporar Ereq
el hobajo octuol con esfuerzos posodos y proporciono Errores por componentes a nivel de diseiio, Ediseiio
uno indication cuontitotivo de lo colidod del troboio
que estemos reolizondo. Errores por componente a nivel de c6dig0, Ecodigo
EED-andisis de requisitos
En el Capitulo 4, el concept0 de eficiencia de elimi- EED-diseiio arquitect6nico
nation de defectos ya fue discutido. Para recordarlo bre-
EED-diseiio a nivel de componentes
vemente, el equipo de software desarrolla revisiones
tCcnicas formales (y, mhs tarde, comprobaciones) para EED-codification
encontrar y corregir 10s errores, E, en productos realiza- A medida que el proyecto progresa a travCs de cada
dos durante las tareas de ingenieria de software. Cual- paso de la ingenieria de software, el equipo de soft-
quiera de 10s errores que no se hayan descubierto (pero se ware registra e informa del n6mero de errores encon-
CAP~TULO7 P L A N I F I C A C I ~ NTEMPORAL Y SEGUIMIENTO DEL P R O D U C T 0
trados en 10s requisitos, disefio y revisiones de c6di- si6n. Si el segundo escenario parece mis probable, el
go. El gestor del proyecto calcula 10s valores actua- gestor de proyecto deberia adoptar 10s pasos necesarios
les para Ereq, Edisefio y Ecodigo. Estos son despuCs para construir un tiempol* de disefio adicional dentro
comparados con 10s promedios de proyectos anterio- del plan con el fin de acomodar 10s defectos de requisi-
res. Si 10s resultados actuales discrepan en mas de un tos que probablemente hayan podido propagarse a tra-
20 por 100 de dicho promedio, ello puede ser causa vCs de la actividad propia de disefio.
de preocupaci6n, y debe ser objeto de una investiga- La mCtrica de seguimiento de errores descrita ante-
ci6n posterior. riormente puede ser utilizada tambiCn para 10s recur-
sos de comprobaci6n y/o revisi6n de objetivos. Por
ejemplo, si un sistema se compone de 120 compo-
nentes, per0 32 de dichos componentes muestran valo-
Cuanto mas cuantihtivo seo su enfoque para el res Edisefio que tengan una varianza sustancial a partir
seguimiento y control del proyecto, eshrd probablemente
del promedio, el gestor del proyecto puede elegir dedi-
mas preporodo pora prevenir problemas potenciales y
car recursos de revisi6n de c6digo a 10s 32 compo-
responder ante ellos de un mod0 proactive. Utilice
metricas de seguimiento y de valor ganado.
nentes y permitir a otros pasar a su comprobaci6n con
una revisi6n de c6digo. Aunque todos 10s componen-
tes deberian ser sometidos a una revisi6n de c6digo en
Por ejemplo, si Ereq =2.1 en el proyecto X, y el pro- una supuesta revisi6n ideal, para 10s proyectos que se
medio de la organizaci6n es 3.6, es posible uno de estos hayan pasado de presupuesto puede ser un medio efec-
dos escenarios: (1) que el equipo de software haya desa- tivo realizar una aproximacion selectiva (revisando
rrollado el trabajo preferente de desarrollar las especi- s610 aquellos m6dulos que tengan una calidad dudosa
ficaciones de requisitos o (2) que el equipo haya prestado basindose en el valor Edisefio) con el fin de recupe-
una atenci6n secundaria en la aproximaci6n a la revi- rar el tiempo perdido y/o ahorrar 10s costes.
Cada paso en el proceso de ingenieria del software debe- cionado con el proyecto, y (5) describir c6mo se garan-
ria obtener una entrega que pueda revisarse y que pueda tizari la calidad y se gestionan 10s cambios.
hacer de fundamento para 10s siguientes pasos. El Plan
del Proyecto de Software se produce a la culminaci6n de
las tareas de planificaci6n. Proporciona informaci6n bhi-
ca de costes y planificaci6n temporal que sera empleada
a lo largo del proceso de software.
El Plan del Proyecto de Software es un documento
relativamente breve dirigido a una audiencia diversa. Plan del Proyecto de Software
Debe (1) comunicar el imbito y recursos a 10s gestores Es importante sefialar que el Plan del Proyecto del Soft-
del software, personal tCcnico y a1 cliente; (2) definir ware no es un documento estitico. Esto es, el equipo del
10s riesgos y sugerir tCcnicas de aversi6n a1 riesgo; (3) proyecto consulta el plan repetidarnente -actualizando
definir 10s costes y planificaci6n temporal para la revi- riesgos, estimaciones, planificaciones e informaci6n rela-
si6n de la gesti6n; (4) proporcionar un enfoque general cionada- a la vez que el proyecto avanza y es mis cono-
del desarrollo del software para todo el personal rela- cido.
La planificaci6n temporal es la culminaci6n de una acti- nificaci6n temporal se convierte en un mapa de carre-
vidad de planificaci61-1,componente primordial de la teras a seguir por el gestor del proyecto.
direcci6n de proyectos de software. Cuando se combi- La planificacion temporal empieza con la des-
nan mCtodos de estimaci6n y anilisis de riesgo, la pla- composici6n del proceso. Las caracteristicas del pro-
l 2 En realidad, el tiempo extra sera gastado en volver a trabajar en

10s defectos de requisitos, pero este trabajo tendra lugar cuando s e
emprenda el trabajo de disefio.
yecto se emplean para adaptar un conjunto de tare- tico del proyecto, un grafico de tiempo e informa-
.as apropiado a1 trabajo a realizar. Una red de tareas cion diversa del proyecto. El gestor del proyecto pue-
muestra todas las tareas de ingenieria, sus depende seguir y controlar todos 10s pasos del proceso de
dencias con otras tareas y sus duraciones previstas. software usando la planificacion temporal como
La red de tareas se usa para calcular el camino cri- directriz.
[BR095] Brooks, M., The Mythical Man-Month, ed. Aniver- [PRE99] Pressman, R. S., Adaptable Process Model, R. S.
sario, Adison-Wesley, 1995. Pressman&Associates, 1999.
[FLE98] Fleming, Q.W., y J.M. Koppelman, <<EarnedValue [PUT921 Putman, L., y W. Myers, Measures for Excellence,
Project Management,,, Crosstalk, vol. 11, n.V, Julio 1998, Yourdon Press, 1992.
p. 19.
[RIG811 Riggs, J., Production Systems Planning, Analysis
[HUM951 Humphrey, W., A Discipline for Software Engine- and Control, 3.%d., Wiley, 1981.
ering, Addison-Wesley, 1995. [THE931 ThC, L., <<ProjectManagement Software That's IS
Friendly,,, Datamation, Octubre 1993, pp. 55-58.
[MOD831 Moder, J. J., C. R. Philips y E. W. Davis, Pro-
ject Management with CPM, PERTand Precedence Dia- [WIL99] Wilkens, T.T., <<EarnedValue, Clear and Simple,,,
gramming, 3.+d., VanNostrad Reinhold, 1983. Primavera Systems, Inc, Abril 1999, p. 2.
[PAG85] Page-Jones, M., Practical Project Management, [ZAH95] Zahniser, R., <<Time-boxingfor Top Team Perfor-
Dorset House, 1985, pp. 90-91. mance,,, Software Development, Marzo 1995, pp. 34-38.
7.1. Las fechas limite ccirracionales,, son un hecho consuma- 7.6. La relacidn entre el personal y el tiempo no es lineal.
do del negocio del software. iC6m0 procederia si se encuen- Usando la ecuacidn del software de Putman (descrita en la
tra en esta situacibn? Secci6n 7.2.2), desarrolle una tabla que relacione el ndme-
ro de gente con la duraci6n del proyecto para un proyecto
7.2. iCuil es la diferencia entre una planificaci6n temporal de software que requiera 50.000 LDC y 15 personas-afio
macrosc6pica y una detallada? iEs posible dirigir un proyec- de esfuerzo (el parimetro de productividad es 5.000 y
to si s610 se desarrolla una planificaci6n temporal macrosc6- B = 0,37). Asuma que el software debe entregarse en 24
pica? iPor quC? meses, mis/menos 12 meses.
7.3. iHay algdn caso en el que un hito de un proyecto no esti 7.7. Asuma que ha sido contratado por una universidad para
sujeto a una revisibn? Si es asi, proporcione uno o mis ejem- desarrollar un sistema interactive para apuntarse a cursos
plos. (OLCRS).Primero, actlie como el cliente (jsi usted es un estu-
diante, le resultari ficil!) y especifique las caracteristicas de
7.4. En la Secci6n 7.2.1, se presenta un ejemplo de <<sobre- un buen sistema. [Alternativamente, su profesor le propor-
carga de comunicaciones~~ que puede ocumr cuando mucha cionari un conjunto de requisitos preliminares para el sistema.]
gente trabaja en un proyecto de software. Desarrolle un Usando 10s mCtodos de estimaci6n estudiados en el Capitulo
ejemplo que ilustre c6mo unos ingenieros expertos, y con 5, desarrolle una estimaci6n de esfuerzo y duraci6n para un
buenas experiencias en ingenieria del software y que utili- OLCRS. Sugiera c6mo:
zan revisiones tCcnicas formales, pueden mejorar el ritmo a) definiria las actividades paralelas de trabajo durante el pro-
de producci6n de un equipo (comparado con la suma de 10s yecto OLCRS;
ritmos individuales de producci6n). Pista: puede asumir que
las revisiones reducen el retrabajo y que estas repeticiones b) distribuiria el esfuerzo a lo largo del proyecto;
del trabajo suponen de un 20 a un 40 por 100 del tiempo C) estableceria hitos para el proyecto.
de una persona.
7.8. Usando la Secci6n 7.3 como directriz, calcule el SCT
7.5. Aunque agregar gente a un proyecto atrasado lo puede para OLCRS. Asegdrese de mostrar todo su trabajo. Selec-
retrasar adn mis, hay circunstancias en las que no es verdad. cione un tip0 de proyecto y Cree un conjunto apropiado de
Descnialas. tareas para el proyecto.
CAP~TULO
7 P L A N I F I C A C ~ ~TNE M P O R A L Y S E G U I M I E N T O DEL P R O D U C T 0
7.9. Defina una red de tareas para OLCRS o, altemativamente,

para otro proyecto de software que le interese. Asegurese de tarea esfuerzo planificado esfuerzo real
mostrar las tareas e hitos y adjuntar las estimaciones de
esfuerzo y tiempo para cada tarea. Si es posible, utilice una
herramienta de programaci6n automatica para realizar este
trabajo.
7.10. Si dispone de una herramienta'de programaci6n auto-
matica, determine el camino critic0 para la red definida en el
problema 7.9.
7.11. Usando una herramienta de programacidn automatica (si
es posible) o papel y lapiz (si es necesario), desarrolle un gra-
fico de tiempo para el proyecto OLCRS.
7.12. Refine la tarea denominada evaluacion del riesgo tec-
nologico en la secci6n 7.4 del mismo modo que se refino el
ambito del concept0 en la Secci6n 7.5.
7.13. Suponga que es un gestor de proyectos de software y
que se le ha pedido que calcule estadisticas del valor gana-
do para un proyecto de software sencillo. El proyecto tiene Calcule IDP, la varianza de la planificacibn, el porcentaje pla-
56 tareas planificadas que se estima que necesiten 582 per- nificado para terminacibn, el porcentaje cornpleto IDC y la
sonas-dia para realizarlas. A1 tiempo que ha sido solicitado varianza del coste para el proyecto.
para realizar el analisis del valor ganado, se han completa-
do 12 tareas. Sin embargo, la planificaci6n temporal del pro- 7.14. Es posible utilizar EED como una mCtrica para el
yecto indica que se deberian haber completado 15 tareas. seguimiento de errores en un proyecto de software. Estu-
Estan disponibles 10s siguientes datos de planificaci6n (en die 10s pros y 10s contras de utilizar EED para este propo-
personas-dia): sito.
McConnel (Rapid Development, Microsoft Press, 1996) TambiCn se puede obtener informaci6n que merece la pena
presenta un estudio excelente acerca de 10s aspectos que con- en 10s libros de gesti6n de proyectos de prop6sito general.
ducen a una planificacidn de proyectos de software demasia- Entre ellos se encuentran:
do optimists y lo que se puede hacer con ella. O'Connell (How
to Run Successful Projects 1l:The Silver Bullet, Prentice Hall, Kezner, H., Project Management: A Systems Approach to
1997) presenta un enfoque paso a paso para la gestidn de pro- Planning, Schrduling, and Controlling, Wiley, 1998.
yectos que pueden ayudarle a desarrollar una planificaci6n Lewis, J. P., Mastering Project Management: Applying
temporal realista para sus proyectos. Advanced Concepts of Systems Thinking, Control and Eva-
Los aspectos de la planificacidn temporal estin cubier- luation, McGraw-Hill, 1988.
tos en la mayoria de 10s libros sobre gesti6n de proyectos
de software. McConnell (Software Project Survival Gui- Fleming y Koppelman (Earned Value Project Manage-
d e , Microsoft Press, 1998), Hoffman y Beaumont (Appli- ment, Project Management Institute Publications, 1996) tra-
cation Development: Managing a Project's Life Cycle, tan con mucho detalle el uso de tCcnicas de valor ganado para
Midrange Computing, 1997), Wysoki y sus colegas (Effec- el seguimiento y control de proyectos.
tive Project Management, Wiley, 1995) y Whitten (Mana- En Intemet e s t h disponibles una gran variedad de fuentes
ging Software Development Projects, 2.%d., Wiley, 1995)
de informacion relacionadas con ternas de gesti6n y planifica-
consideran el tema en detalle. Boddie (Crunch Mode, Pren-
tice-Hall, 1987) han escrito un libro para todos 10s gesto- ci6n temporal de proyectos. Se puede encontrar una lista actua-
res que {{tienen 90 dias para hacer un proyecto de seis lizada con referencias a sitios (piginas) web que son relevantes
mesew. para la planificaci6n en http:llwww.pressman5.com.
Se dice que dos copos de nieve no son iguales. Cierta- iC6mo se aplica esto a1 software? iC6m0 puede
mente cuando se obsema caer la nieve, es dificil ima- una organizaci6n de desarrollo de software necesitar
ginar que son totalmente diferentes, por no mencionar controlar la variacibn? De un proyecto a otro, quere-
que cada cop0 posee una estructura dnica. Para obser- mos reducir la diferencia entre 10s recursos necesa-
var las diferencias entre 10s copos de nieve, debemos rios planificados para terminar un proyecto y 10s
examinar 10s especimenes muy de cerca, y quizi con recursos reales utilizados, entre 10s que se incluyen
un cristal de aumento. En efecto, cuanto rnis cerca 10s personal, equipo y tiempo. En general, nos gustaria
obsememos, mis diferencias podremos detectar. aseguramos de que nuestro programa de pruebas abar-
Este fenomeno, variacidn entre muestras, se aplica ca un porcentaje conocido del software de una entre-
a todos 10s productos del hombre asi como a la creaci6n ga a otra. No s610 queremos reducir el numero de
natural. Por ejemplo, si dos tarjetas de circuit0 ccidknti- defectos que se extraen para ese campo, sino tambiCn
caw se examinan muy de cerca, podremos obsemar que nos gustaria asegurarnos de que 10s errores ocultos
las lineas de cobre sobre las tarjetas difieren ligeramente tambikn se reducen de una entrego a otra. (Es proba-
en la geometria, colocaci6n y grosor. Ademis, la loca- ble que nuestros clientes se molesten si la tercera
lizaci6n y el d i h e t r o de 10s orificios de las tarjetas tam- entrega de un producto tiene diez veces rnis defectos
biCn varian. que la anterior.) Nos gustaria reducir las diferencias
en velocidad y precisi6n de nuestras respuestas de
soporte a 10s problemas de 10s clientes. La lista se
podria ampliar rnis y mis.
8.1.1. Calidad
El American Heritage Dictionary, define la calidad como
El control de variacidn es el centro del control de ccuna caracteristica o atributo de alga>>. Como un atri-
calidad. Un fabricante quiere reducir la variaci6n entre but0 de un elemento, la calidad se refiere a las caracte-
10s productos que se fabrican, incluso cuando se reali- risticas mensurables - c o s a s que se pueden comparar
za algo relativamente sencillo como la duplicaci6n de con estindares conocidos como longitud, color, propie-
disquetes. Seguramente, esto puede no ser un problema dades elkctricas, maleabilidad, etc.-. Sin embargo, el
-la duplicaci6n de disquetes es una operacidn de fabri- software en su gran extensibn, como entidad intelectual,
caci6n trivial y podemos garantizar que se crean dupli- es mhs dificil de caracterizar que 10s objetos fisicos.
cados exactos de software-. No obstante, si existen las medidas de caracteristi-
ipodemos?. Necesitamos asegurar que las pistas se cas de un programa. Entre estas propiedades se inclu-
situen dentro de una tolerancia especifica para que la yen complejidad ciclom6tica, cohesidn, numero de
gran mayoria de las disqueteras puedan leer 10s dis- puntos de funcibn, lineas de c6digo y muchas otras estu-
quetes. Ademis, necesitamos asegurar que el flujo mag- diadas en 10s Capitulos 19 y 24. Cuando se examina un
nCtico para distinguir un cero de un uno sea suficiente elemento segiin sus caracteristicas mensurables, se pue-
para que 10s detecten las cabezas de lectura/escritura. den encontrar dos tipos de calidad: calidad del diseiio
Las miquinas de duplicaci6n de discos aceptan o recha- y calidad de concordancia.
zan la tolerancia. Por consiguiente, incluso un proceso
<<simple>>,como la duplicaci61-1,puede encontrarse con
problemas debidos a la variaci6n entre muestras.
Controlor lo vorioci6n es lo clove de un producto de alto La calidad de diseiio se refiere a las caracteristicas
colidod. En el context0 del software, nos esforzornos que especifican 10s ingenieros de software para un ele-
en controlar lo vorioci6n en el proceso que oplicomos, mento. El grado de materiales, tolerancias y las especi-
recursos que consumimos y 10s otributos de colidad ficaciones del rendimiento contribuyen a la calidad del
del producto final. diseiio. Cuando se utilizan materiales de alto grado y se
Esta seccion, escrita por Michael Stovsky, se ha adaptado de .Fun-

damentals of IS0 9000n, un libro de trabajo desarrollado para Essen-
tial Software Engineering, un video curriculum desarrollado por R.S.
Pressman&Asociados, Inc. Reimpresion autorizada.
CAPfTULO 8 G A R A N T ~ ADE CALIDAD DEL S O F T W A R E
especifican tolerancias mas estrictas y niveles rnis altos cificaciones mensurables en las que se puedan com-
de rendimiento, la calidad de disefio de un producto parar 10s resultados de cada proceso. El bucle de rea-
aumenta, si el producto se fabrica de acuerdo con las limentaci6n es esencial para reducir 10s defectos
especificaciones. producidos.
La calidad de concordancia es el grado de cumpli-
miento de las especificaciones de disefio durante su rea- 8.1.3. Garantia de calidad
lizaci6n. Una vez mhs, cuanto mayor sea el grado de
cumplimento, rnis alto seri el nivel de calidad de con- La garantia de calidad consiste en la auditona y las fun-
cordancia. ciones de informaci6n de la gesti6n. El objetivo de la
En el desarrollo del software, la calidad de disefio garantia de calidad es proporcionar la gesti6n para infor-
comprende 10s requisitos, especificaciones y el disefio mar de 10s datos necesarios sobre la calidad del pro-
del sistema. La calidad de concordancia es un aspect0 d u c t ~por
, lo que se va adquiriendo una visi6n rnis
centrado principalmente en la implementacibn. Si la profunda y segura de que la calidad del producto esti
implementacih sigue el disefio, y el sistema resultan- cumpliendo sus objetivos. Por supuesto, si 10s datos pro-
te cumple 10s objetivos de requisitos y de rendimiento, porcionados mediante la garantia de calidad identifican
la calidad de concordancia es alta. problemas, es responsabilidad de la gesti6n afrontar 10s
Pero, json la calidad del disefio y la calidad de problemas y aplicar 10s recursos necesarios para resol-
concordancia 10s linicos aspectos que deben consi- ver aspectos de calidad.
derar 10s ingenieros de software? Robert Glass
[GLA98] establece para ello una relacion mas <<intui-
tiva>>:
satisfacci6n del usuario = producto satisfactorio+buenacali-
Referencia web /'
dad+ entrega dentro de presu- Se puede encontror uno gron voriedod de recursos de
puesto y del tiempo establecidos tolidod del software en
www.qualitytree.com/links/links.htm
En la ultima linea, Glass afirma que la cahdad es impor-
tante, per0 si el usuario no queda satisfecho, ninguna otra
cosa realmente irnporta. DeMarco [DEM99] refuerza este 8.1.4. Coste de calidad
punto de vista cuando afirma: <<Lacalidad del producto El coste de calidad incluye todos 10s costes acarreados
es una funci6n de cuhnto cambia el mundo para mejor.>> en la busqueda de la calidad o en las actividades rela-
Esta visi6n de la calidad establece que si el producto de cionadas en la obtenci6n de la calidad. Se realizan estu-
software proporciona un beneficio sustancial a 10s usua- dios sobre el coste de calidad para proporcionar una linea
nos finales, pueden estar dispuestos para tolerar proble- base del coste actual de calidad, para identificar oportu-
mas ocasionales del rendimiento o de fiabilidad. nidades de reducir este coste, y para proporcionar una
base normalizada de comparaci6n. La base de normali-
zaci6n siempre tiene un precio. Una vez que se han nor-
8.1.2. Control de calidad
malizado 10s costes de calidad sobre un precio base,
El control de cambios puede equipararse a1 control de tenemos 10s datos necesarios para evaluar el lugar en
calidad. Pero, jc6m0 se logra el control de calidad? El donde hay oportunidades de mejorar nuestros procesos.
control de calidad es una serie de inspecciones, revi- Es mas, podemos evaluar c6mo afectan 10s cambios en
siones y pruebas utilizados a lo largo del proceso del tkrminos de dinero.
software para asegurar que cada producto cumple con Los costes de calidad se pueden dividir en costes
10s requisitos que le han sido asignados. El control de asociados con la prevencibn, la evaluaci6n y 10s fallos.
calidad incluye un bucle de realimentaci6n (feedback) Entre 10s costes de prevencidn se incluyen:
del proceso que cre6 el producto. La combinaci6n de
medici6n y realimentaci6n permite afinar el proceso planificaci6n de la calidad,
cuando 10s productos de trabajo creados fallan a1 cum- revisiones tCcnicas formales,
plir sus especificaciones. Este enfoque ve el control de equipo de pruebas,
calidad como parte del proceso de fabricaci6n. formaci6n.
iCuiles son
iQu6 es el control de calidad
del software? 10s componentes
del coste de calidad?
Las actividades de control de calidad pueden ser Entre 10s costes de evaluacidn se incluyen activida-
manuales, completamente automiticas o una combi- des para tener una visi6n rnis profunda de la condici6n
naci6n de herramientas automiticas e interacci6n del producto <<laprimera vez a travCs de>>cada proce-
humana. Un concept0 clave del control de calidad es so. A continuation se incluyen algunos ejemplos de cos-
que se hayan definido todos 10s productos y las espe- tes de evaluaci6n:
inspecci6n en el proceso y entre procesos, Se han dedicado 7.053 horas inspeccionando 200.000 li-
neas de c6digo con el resultado de 3.112 errores potenciales
: calibrado y mantenimiento del equipo,
descubiertos. Dando por sentado un coste de programador de
pruebas. 40 dolares por hora, el coste de eliminar 3.1 12 defectos ha sido
de 282.120 ddares, o aproximadamente unos 91 d6lares por
defecto.
Compare estos nlimeros con el coste de eliminaci6n de
No tenga miedo de incurrir en costes siynfirotivos defectos una vez que el producto se ha enviado a1 cliente.
de prevencibn. €st6 seguro de que su inversion Suponga que no ha habido inspecciones, per0 que 10s progra-
le proporcionarb un beneficio excelente. madores han sido muy cuidadosos y solamente se ha escapa-
do un defecto por 1.000 lineas de c d i g o [significativamente
mejor que la media en industrial] en el producto enviado. Eso
Los costes de fallos son 10s costes que desapare- significan'a que se tendrian que corregir todavia 200 defectos
cerian si no surgieran defectos antes del envio de un en la casa del cliente o desputs de la entrega. A un coste esti-
producto a 10s clientes. Estos costes se pueden sub- mado de 25.000 dolares por reparation decamp, el coste seria
dividir en costes de fallos internos y costes de fallos de 5 millones de dolares, o aproximadamente 18 veces mas
externos. Los internos se producen cuando se detec- caro que el coste total del esfuerzo de prevention de defectos.
ta un error en el producto antes de su envio. Entre
estos se incluyen:
40-1000
retrabajo (revision), veces
reparacibn,
analisis de las modalidades de fallos. 30-70
veces
Los costes de fallos externos son 10s que se asocian 15-40
a 10s defectos encontrados una vez enviado el produc- veces
to a1 cliente. A continuacion se incluyen algunos ejem- 10
veces
plos de costes de fallos extemos: 3-6
resoluci6n de quejas, veces
devolucion y sustitucion de productos, 1
vez
soporte de linea de ayuda,
trabajo de garantia.
Como es de esperar, 10s costes relativos para encon-
trar y reparar un defecto aumentan dramaticamente a
Requisitos Diseho Codigo Prueba
Prueba En fase de
medida que se cambia de prevenci6n a deteccion y des- dr, de explotacion
de el fallo intemo a1 extemo. La Figura 8.1, basada en desarrollo sisterna
datos recopilados por Boehm [BOE81], ilustra este f e d - FIGURA 8.1. Coste relativo de corregir un error.
meno.
Es verdad que IBM produce software utilizado por
cientos de miles de clientes y que sus costes por repa-
10s pruebas son necesarias, pen, tombien raci6n en casa del cliente o despuCs de la entrega pue-
es uno f o r m costosa de encontrar errores. Goste den ser mhs altos que 10s de organizaciones de software
el tiempo en enrontrar errores 01 comienzo del praceso que construyen sistemas personalizados. Esto, de nin-
y podro reducir significotivomente10s castes de pruebos guna manera, niega 10s resultados sefialados anterior-
y depurocion. mente. Aunque la organization media de software tiene
costes de reparaci6n despuCs de la entrega que son el
Kaplan y sus colegas [KAP95] refuerzan las esta- 25 por 100 de 10s de IBM (ila mayoria no tienen ni idea
disticas de costes anteriores informando con datos anec- de cuales son sus costes!), se esthn imponiendo ahorros
doticos basados en un trabajo realizado en las en el coste asociados con actividades de garantia y con-
instalaciones de desarrollo de IBM en Rochester: trol de calidad.
Hoy en dia 10s responsables expertos de compafiias de La tendencia de la calidad comenz6 en 10s afios cuarenta
todo el mundo industrializadoreconocen que la alta cali- con el influyente trabajo de W. Edwards Deming
dad del producto se traduce en ahorro de coste y en una [DEM86], y se hizo la primera verification en Jap6n.
mejora general. Sin embargo, esto no era siempre el caso. Mediante las ideas de Deming como piedra angular, 10s
CAPfTULO 8 G A R A N T ~ ADE CALIDAD DEL SOFTWARE
japoneses han desarrollado un enfoque sistematico para Mientras que 10s dos primeros pasos se centran en
la eliminaci6n de las causas raiz de defectos en produc- el proceso, el paso siguiente llamado kansei (traducido
tos. A lo largo de 10s aiios setenta y ochenta, su trabajo como 4 0 s cinco sentidow) se centra en el usuario del
emigr6 a1 mundo occidental y a veces se llama <<gesti6n producto (en este caso, software). En esencia, exami-
total de calidad (GTC)))~. Aunque la terminologia difiere nando la forma en que el usuario aplica el producto,
seg6n 10s diferentes paises y autores, normalmente se kansei conduce a la mejora en el producto mismo, y
encuentra una progresi6n basica de cuatro pasos que cons- potencialmente a1 proceso que lo cre6.
tituye el fundamento de cualquier programa de GTC. Finalmente, un paso llamado miryokuteki hinshitsu
amplia la preocupaci6n de la gesti6n mas all5 del pro-
ducto inmediato. Este es un paso orientado a la gesti6n
que busca la oportunidad en areas relacionadas que se
pueden identificar obsemando la utilizacih del pro-
Se puede oplitar GTC al software de tomputadoro. ducto en el mercado. En el mundo del software, miwo-
El enfoque GTC se tentro en lo meiora tontinua kuteki hinshitsu se podria ver como un intento de
del proteso.
detectar productos nuevos y beneficiosos, o aplicacio-
El primer paso se llama kaizen y se refiere a un sis- nes que sean una extension de un sistema ya existente
tema de mejora continua del proceso. El objetivo de kai- basado en computadora.
Zen es desarrollar un proceso (en este caso, proceso del
software) que sea visible, repetible y mensurable.
El segundo paso, invocado solo una vez que se ha
al~anzadokaizen, se llama atarimae hinshitsu. Este paso
examina lo intangible que afecta a1 proceso y trabaja
Referencia web/ '
Se puede entontrar una gran variedad de retursos
para optimizar su impacto en el proceso. Por ejemplo, para la meiora tontinua del proteso y GTC en
el proceso de software se puede ver afectado por la alta deming.eng.clemsom.edu/
rotacion de personal que ya en si mismo se ve afectado
por reorganizaciones dentro de una compaiiia. Puede Para la mayoria de las compaiiias, kaizen deberia
ser que una estructura organizativa estable haga mucho ser de preocupacion inmediata. Hasta que se haya logra-
para mejorar la calidad del software. Atarimae hinshit- do un proceso de software avanzado (Capitulo 2), no
su llevaria a la gestion a sugerir cambios en la forma en hay muchcs argumentos para seguir con 10s pasos
que ocurre la reorganizacion. siguientes.
Hasta el desarrollador de software mas agobiado esta- ware. Para 10s propositos de este libro, la anterior defini-
ra de acuerdo con que el software de alta calidad es una cion sine para hacer hlncapii en tres puntos importantes:
meta importante. Pero, jc6m0 definimos la calidad? Un 1. Los requisitos del software son la base de las medi-
bromista dijo una vez: <<Cualquierprograma hace algo das de la calidad. La falta de concordancia con 10s
bien, lo que puede pasar es que no sea lo que nosotros requisitos es una falta de calidad.
queremos que hags,>. 2. Los estandares especificados definen un conjunto de
~ C o m ose define ((talidad criterios de desarrollo que guian la forma en que se
del software))? aplica la ingenieria del software. Si no se siguen esos
criterios, casi siempre habra falta de calidad.
En 10s libros se han propuesto muchas definiciones 3. Existe un conjunto de requisitos implicitos que a
de calidad del software. Por lo que a nosotros respecta, menudo no se mencionan (por ejemplo: el deseo por
la calidad del software se define como: facilitar el uso y un buen mantenimiento). Si el soft-
Concordancia con 10s requisitos funcionales y de rendi- ware se ajusta a sus requisitos explicitos per0 falla
miento explicitamenteestablecidos, con 10s estkndares de desa- en alcanzar 10s requisitos implicitos, la calidad del
rrollo explicitamente documentados, y con las caracteristicas software queda en entredicho.
implicitas que se espera de todo software desarrollado profe-
sionalmente. 8.3.1. Problemas de fondo
No hay duda de que la anterior definici6n puede ser La historia de la garantia de calidad en el desarrollo de
modificada o ampliada. De hecho, no tendria fin una dis- software es paralela a la historia de la calidad en la crea-
cusion sobre una definicion formal de calidad del soft- ci6n de hardware. Durante 10s primeros aiios de la infor-
Consulte [ART921 para un estudio mas completo del GTC y su uso
en un context0 de software, y [KAP95] para un estudio sobre el uso
de criterio ~BalbridgeAward. en el mundo del software.
mitica (10s aiios cincuenta y sesenta), la calidad era res- des de SQA que se enfrentan con la planificaci6n de garan-
ponsabilidad 6nicamente del programador. Durante 10s tia de calidad, supe~isi6n,mantenimiento de registros,
afios setenta se introdujeron estindares de garantia de anfilisis e informes. st as son las actividades que realizan
calidad para el software en 10s contratos militares para (o facilitan) un grupo independiente de SQA:
desarrollo de software y se han extendido ripidamente Establecimiento de un plan de SQA para un proyec-
a 10s desarrollos de software en el mundo comercial to. El plan se desarrolla durante la planificaci6n del pro-
[IEE94]. Ampliando la definici6n presentada anterior- yecto y es revisado por todas las partes interesadas. Las
mente, la garantia de calidad del software (SQA) es un actividades de garantia de calidad realizadas por el equi-
<<patr6n de acciones planificado y sistemitico>>[SCH97] po de ingenieria del software y el grupo SQA son gober-
que se requiere para asegurar la calidad del software. El nadas por el plan. El plan identifica:
fimbito de la responsabilidad de la garantia de calidad se
evaluaciones a realizar,
puede caracterizar mejor parafraseando un popular anun-
cio de coches: <<Lacalidad es la l."area.>> La implica- auditonas y revisiones a realizar,
ci6n para el software es que muchos de 10s que esthdares que se pueden aplicar a1 proyecto,
constituyen una organization tienen responsabilidad de procedimientos para informacibn y seguimiento de
garantia de calidad del software -ingenieros de soft- errores,
ware, jefes de proyectos, clientes, vendedores, y aque- documentos producidos por el grupo SQA,
llas personas que trabajan dentro de un grupo de SQA-.
realimentaci6n de informaci6n proporcionada a1
equipo de proyecto del software.
Referencia web/ ' ~ C u i es

l el papel
de un grupo de SQA?
Se puede encontrar un tutorial profundo y amplios
recursos para la gestion de calidad en
www.management.gov
Participacidn en el desarrollo de la descripcidn del
proceso de software delproyecto. El equipo de ingenie-
ria del software selecciona un proceso para el trabajo
El grupo de SQA sirve como representaci6n del clien- que se va a realizar. El grupo de SQA revisa la descrip-
te en casa. Es decir, la gente que lleva a cab0 la SQA ci6n del proceso para ajustarse a la politica de la empre-
debe mirar el software desde el punto de vista del clien- sa, 10s estindares internos del software, 10s estindares
te. isatisface de forma adecuada el software 10s facto- impuestos externamente (por ejemplo: I S 0 9001), y a
res de calidad apuntados en el Capitulo 19? iSe ha otras partes del plan de proyecto del software.
realizado el desarrollo del software de acuerdo con esth- Revisidn de las actividades de ingenieria del soft-
dares preestablecidos? iHan desempefiado apropiada- ware para verificar su ajuste a1 proceso de software
mente sus papeles las disciplinas tCcnicas como parte definido. El grupo de SQA identifica, documenta y sigue
de la actividad de SQA? El grupo de SQA intenta res- la pista de las desviaciones desde el proceso y verifica
ponder a estas y otras preguntas para asegurar que se que se han hecho las correcciones.
mantiene la calidad del software. Auditoria de 10s productos de software designados
para verificar el ajuste con 10s definidos conzo parte del
8.3.2. Actividades d e SQA proceso del software. El grupo de SQA revisa 10s pro-
ductos seleccionados; identifica, documenta y sigue la
La garantia de calidad del software comprende una gran
pista de las desviaciones; verifica que se han hecho las
variedad de tareas, asociadas con dos constitutivos dife-
correcciones, e informa peri6dicamente de 10s resulta-
rentes -10s ingenieros de software que realizan traba-
dos de su trabajo a1 gestor del proyecto.
jo tkcnico y un grupo de SQA que tiene la responsabilidad
Asegurar que las desviaciones del trabajo y 10s pro-
de la planificaci6n de garantia de calidad, supe~isi6n,
ductos del software se docunzentan y se manejan de
mantenimiento de registros, anfilisis e informes-.
acuerdo con un procedimiento establecido. Las des-
Los ingenieros de software afrontan la calidad (y rea-
viaciones se pueden encontrar en el plan del proyecto,
lizan garantia de calidad) aplicando mCtodos tCcnicos
en la descripci6n del proceso, en 10s estindares aplica-
d i d o s y medidas, realizando revisiones tCcnicas for-
bles o en 10s productos tkcnicos.
males y llevando a cab0 pruebas de software bien pla-
Registrar lo que no se ajuste a 10s requisitos e infor-
nificadas. Solamente las revisiones son tratadas en este
mar a sus superiores. Los elementos que no se ajustan
capitulo. Los temas de tecnologia se estudian en las Par-
a 10s requisitos estin bajo seguimiento hasta que se
tes Tercera a Quinta de este libro.
resuelven.
Las reglas del grupo de SQA tratan de ayudar a1 equi-
po de ingenieria del software en la consecuci6n de un pro- Ademis de estas actividades, el grupo de SQA coor-
ducto final de alta calidad. El Institute de Ingenieria del dina el control y la gesti6n de cambios (Capitulo 9) y ayu-
Software [PAU93] recomienda un conjunto de activida- da a recopilar y a analizar las mktricas del software.
C A P ~ T U L O8 G A R A N T f A D E C A L I D A D DEL S O F T W A R E
Las revisiones del software son un c<filtronpara el pro- defecto como una ccanomalia del producto,,. La defini-
ceso de ingenieria del software. Esto es, las revisiones ci6n de ccfallon en el contexto del hardware se puede
se aplican en varios momentos del desarrollo del soft- encontrar en IEEE Standard 610. 12-1990:
ware y sirven para detectar errores y defectos que pue- (a) Un defecto en un dispositivo de hardware o componen-
dan asi ser eliminados. Las revisiones del software sirven te: por ejemplo, un corto circuit0 o un cable roto.
para ccpurificar,, las actividades de ingenieria del soft- (b) Un paso incorrecto, proceso o definicion de datos en
ware que suceden como resultado del analisis, el diseAo un programa de computadora. Nota: Esta definicion
y la codificaci6n. Freedman y Weinberg [FRE90] argu- se usa principalmente por la disciplina de tolerancia
mentan de la siguiente forma la necesidad de revisiones: de fallos. En su uso normal, 10s tCrminos <<error>> y
ccfallo~~se utilizan para expresar este significado. Con-
El trabajo tCcnico necesita ser revisado por la misma raz6n sulte tambiCn: fallo sensible a1 dato; fallo sensible a1
que 10s Iapices necesitan gomas: e m es humano. La segunda programa; fallos equivalentes; enmascaramiento de
razon por la que necesitarnos revisiones tCcnicas es que, aun- fallos; fallo intermitente.
que la gente es buena descubriendo algunos de sus propios erre
res, algunas clases de errores se le pasan por alto m b ficilmente Dentro del contexto del proceso del software, 10s ter-
al que 10s origina que a otras personas. El proceso de revision minos defecto y fallo son sin6nimos. Ambos implican
es, por tanto, la respuesta a la plegaria de Robert Bums: un problema de calidad que es descubierto despue's de
~QuCgran regalo seria poder vemos wmo nos ven 10s demb! entregar el software a 10s usuarios finales (o a otra acti-
Una revision +ualquier revisiones una forma de apro-
vidad del proceso del software). En 10s primeros capi-
vechar la diversidad de un grupo de personas para: tulos, se utilizo el tCrmino error para representar un
I. seiialar la necesidad de mejoras en el producto de una
problema de calidad que es descubierto por 10s inge-
sola persona o un equipo; nieros del software (u otros) antes de entregar el soft-
2. confirmar las partes de un producto en las que no es nece- ware a1 usuario final (o a otra actividad del proceso del
saria o no es deseable una mejora; y software).
3. conseguir un trabajo tCcnico de una calidad mas unifor-
me, o a1 menos mis predecible, que la que puede ser con-
seguida sin revisiones, con el fin de hacer mhs manejable
el trabajo tCcnico. Paso de desarrollo
Defectos Deteccion
A1 iguol que 10s filtros de oguo, 10s RTFs tienden o

retardor el ((flujo)) de 10s octividodes de ingenieria del
sofhvare. Muy pocos y el flujo es ((sucio)). Muchas y el
flujo se reduciri o un goteo. Utilice metricas para
determinor quk revisiones son efectivas y cubles no.
Soque 10s que no seon efectivos fuera del flujo. FIGURA 8.2. Modelo de arnplificacion de defectos.
Existen muchos tipos diferentes de revisiones que se

pueden llevar adelante como parte de la ingenieria del El objetivo primario de las revisiones tCcnicas for-
software. Cada una tiene su lugar. Una reunion informales es encontrar errores durante el proceso, de forma
mal alrededor de la maquina de cafC es una forma de que se conviertan en defectos despues de la entrega del
revision, si se discuten problemas tCcnicos. Una pre- software. El beneficio obvio de estas revisiones tCcni-
sentacion formal de un disefio de software a una audien- cas formales es el descubrimiento de errores a1 princi-
cia de clientes, ejecutivos y personal tCcnico es una pio para que no se propaguen a1 paso siguiente del
forma de revision. Sin embargo, en este libro nos cen- proceso del software.
traremos en la revision tkcnica formal (RTF)-a veces
denominada inspeccidn-. Una revision tCcnica formal
es el filtro mas efectivo desde el punto de vista de garan-
tia de calidad. Llevada a cab0 por ingenieros del soft-
ware (y otros), la RTF es para ellos un medio efectivo El objetivo principal de uno RTF es encontror errores
para mejorar la calidad del software. antes de posor o otro octividod de ingenierio
del sotiwore o de entregor ol cliente.
8.4.1. Impacto de 10s defectos del software sobre Una serie de estudios (TRW, Nippon Electric y Mitre
el coste Corp., entre otros) indican que las actividades del dise-
El IEEE Standard Dictionary of Electrical and Elec- Ao introducen entre el 50 a1 65 por ciento de todos 10s
tronics Terms (IEEE Standard 100-1992) define un errores (y en Gltimo lugar, todos 10s defectos) durante
el proceso del software. Sin embargo, se ha demostra- corrige el 50 por 100 de 10s errores que le llegan, sin intro-
d o que las revisiones tCcnicas formales son efectivas en ducir ningun error nuevo (una suposici6n muy optimis-
un 75 por 100 a la hora de detectar errores [JON86]. ta). Antes de que comience la prueba, se han amplificado
Con la detecci6n y la eliminaci6n de un gran porcenta- diez errores del diseiio preliminar a 94 errores. A1 termi-
je de errores, el proceso de revisi6n reduce substan- nar quedan 12 errores latentes. La Figura 8.4 considera
cialmente el coste de 10s pasos siguientes en las fases las mismas condiciones, per0 llevando a cab0 revisiones
de desarrollo y de mantenimiento. del diseiio y de la codificaci6n dentro de cada paso del
Para ilustrar el impact0 sobre el coste de la detec- desarrollo. En este caso 10s 10 errores del diseiio preli-
ci6n anticipada de errores, consideremos una serie de minar se amplifican a 24 antes del comienzo de la prue-
costes relativos que se basan en datos de coste realmente ba. So10 quedan 3 errores latentes. Recordando 10s costes
recogidos en grandes proyectos de software 1 1 ~ ~ 8 1 1 ~relativos
. asociados con el descubrimiento y la correction
Supongamos que un error descubierto durante el dise- de errores, se puede establecer el coste total (con y sin
iio cuesta corregirlo 1,O unidad monetaria. De acuerdo revisiones para nuestro ejemplo hipotktico). El numero
con este coste, el mismo error descubierto justo antes de errores encontrado durante cada paso mostrado en las
de que comienza la prueba costar6 6,5 unidades; duran- figuras 8.3 y 8.4 se multiplica por el coste de eliminar un
te la prueba 15 unidades; y despuCs de la entrega, entre error (1.5 unidades de coste del diseiio, 6.5 unidades de
60 y 100 unidades. coste antes de las pruebas, 15 unidades de coste durante
las pruebas, y 67 unidades de coste despuCs de la entre-
ga. Utilizmdo estos datos, se puede ver que el coste total
8.4.2. Arnplificacion y eliminaci6n de defectos para el desarrollo y el mantenimiento cuando se realizan
Se puede usar un modelo de amplificacion de defectos revisiones es de 783 unidades. Cuando no hay revisio-
[IBM81] para ilustrar la generation y detecci6n de erro- nes, el coste total es de 2.177 unidades - c a s i tres veces
res durante 10s pasos de disefio preliminar, disefio deta- mas c a r e .
llado y codificaci6n del proceso de ingenieria del
software. En la Figura 8.2 se ilustra esquematicamente
el modelo. Cada cuadro representa un paso en el desa-
rrollo del software. Durante cada paso se pueden gene-
rar errores que se pasan inadvertidos. La revisi6n puede
fallar en descubrir nuevos errores y errores de pasos
anteriores, produciendo un mayor ndmero de errores
que pasan inadvertidos. En algunos casos, 10s errores
que pasan inadvertidos desde pasos anteriores se ampli-
fican (factor de amplificacion, x) con el trabajo actual.
Las subdivisiones de 10s cuadros representan cada una Para llevar a cab0 revisiones, el equipo de desarrollo
de estas caracteristicas y el porcentaje de eficiencia para debe dedicar tiempo y esfuerzo, y la organizaci6n de
la detecci6n de errores, una funci6n de la profundidad desarrollo debe gastar dinero. Sin embargo, 10s resulta-
de la revisi6n. dos del ejemplo anterior no dejan duda de que hemos
La Figura 8.3 ilustra un ejemplo hipotCtico de la ampli- encontrado el sindrome de ccpague ahora o pague, des-
ficaci6n de defectos en un proceso de desarrollo de soft- puCs, mucho m&>. Las revisiones tkcnicas formales (para
ware en el que no se llevan a cab0 revisiones. Como el diseiio y otras actividades tCcnicas) producen un bene-
muestra la figura, se asume que cada paso descubre y ficio en coste demostrable. Deben llevarse a cabo.
Una revisi6n tCcnica formal (RTF) es una actividad de desarrollado de forma uniforme y (5) hacer que 10s
garantia de calidad del software llevada a cab0 por 10s proyectos Sean mas manejables. Ademas, la RTF sir-
ingenieros del software (y otros). Los objetivos de la ve como campo de entrenamiento, permitiendo que 10s
RTF son: ( I ) descubrir errores en la funcibn, la 16gi- ingenieros mas j6venes puedan obsemar 10s diferen-
ca o la implementaci6n de cualquier representaci6n tes enfoques de analisis, disefio e implementaci6n del
del software; (2) vsrificar que el software bajo revi- software. La RTF tambiCn sine para promover la segu-
si6n alcanza sus requisitos; (3) garantizar que el soft- ridad y la continuidad, ya que varias personas se fami-
ware ha sido representado de acuerdo con ciertos liarizaran con partes del software que, de otro modo,
estandares predefinidos; (4) conseguir un software no hubieran visto nunca.
Aunque estos datos son de hace mas de 20 aAos, pueden ser apli-
cados en un context0 moderno.
C A P ~ T U L O8 G A R A N T f A DE CALIDAD DEL S O F T W A R E
La RTF es realmente una clase de revisidn que inclu-

ye recorridos, inspecciones, revisiones ciclicas y otro
pequefio grupo de evaluaciones tCcnicas del software. un evento donde
Cada RTF se lleva a cab0 mediante una reuni6n y s610 e pierden horas.
tendrh Cxito si es bien planificada, controlada y atendi-
da. En las siguientes secciones se presentan directrices
similares a las de las inspecciones [FRE90, GIL931 como Con las anteriores limitaciones, debe resultar obvio
representativas para las revisiones tCcnicas formales. que cada RTF se centra en una parte especifica (y
Diseiio preliminar pequefia) del software total. Por ejemplo, en lugar de
intentar revisar un disefio completo, se hacen ins-
pecciones para cada m6dulo (componente) o peque-
iio grupo de modulos. A1 limitar el centro de atencion
de la RTF, la probabilidad de descubrir errores es
mayor.
94 Prueba de integracion
El centro de atenci6n de la RTF es un producto de
Para la integracion trabajo (por ejemplo, una porcion de una especifica-
Prueba del sistema cidn de requisitos, un diseiio detallado del m6dul0,
un listado del c6digo fuente de un m6dulo). El indi-
I viduo que ha desarrollado el producto -el produc-
tor- informa a1 jefe del proyecto de que el producto
L esth terminado y que se requiere una revisi6n. El jefe
Errores latentes
del proyecto contacta con un jefe de revisidn, que eva-
FIGURA 8.3. Arnplificacion de defectos, sin revisiones. llia la disponibilidad del producto, genera copias del
material del producto y las distribuye a dos o tres revi-
Diseno preliminar
sores para que se preparen por adelantado. Cada revi-
sor estara entre una y dos horas revisando el producto,
8 detallado
Cod~ficac~onl tomando notas y tambiCn familiarizhndose con el tra-
Prueba de un~dad
bajo. De forma concurrente, tambikn el jefe de revi-
sidn revisa el producto y establece una agenda para
la reunidn de revisi6n que, normalmente, queda con-
vocada para el dia siguiente.
- Je vahdacm
Para la lntegraclon
Prueba del ststerna
l a RTF se centra en una porcion relativarnente pequeiia

de un producto de trabaio.
L
Errores latentes
FIGURA 8.4. Arnplificacion de defectos, llevando a cab0 La reunidn de revisi6n es llevada a cab0 por el jefe
revisiones. de revisibn, 10s revisores y el productor. Uno de 10s revi-
sores toma el papel de registrador, o sea, de persona que
registra (de forma escrita) todos 10s sucesos importan-
tes que se produzcan durante la revisi6n. La RTF
8.5.1. L a reuni6n de revisi6n
comienza con una explicacion de la agenda y una bre-
Independientemente del formato que se elija para la ve introducci6n a cargo del productor. Entonces el pro-
RTF, cualquier reuni6n de revisi6n debe acogerse a las ductor procede con el ccrecorrido de inspection,, del
siguientes restricciones: producto, explicando el material, mientras que 10s revi-
deben convocarse para la revisidn (normalmente) sores exponen sus pegas bashndose en su preparaci6n
entre tres y cinco personas; previa. Cuando se descubren problemas o errores vhli-
se debe preparar por adelantado, per0 sin que requiera dos, el registrador 10s va anotando.
mhs de dos horas de trabajo a cada persona; y
la duraci6n de la reuni6n de revisi6n debe ser rnenor
de dos horas. Referendo web/ '
Puede descargarse el NASA SATC
Cuondo realizamos RTF's,
Formal InspectionGuideboock de
i d e s son nuestros
satc.gsfc.nasa.gov/fi/fipage.html
obietivos?
A SOFTWARE. UN ENFOQUE P R ~ C T I C O
A1 final de la revision, todos 10s participantes en la Revisar el producto, no a1productor. Una RTF invo-
RTF deben decidir si (I) aceptan el producto sin poste- lucra gente y egos. Conducida adecuadamente, la
riores modificaciones; (2) rechazan el producto debido RTF debe llevar a todos 10s participantes a un senti-
a 10s serios errores encontrados (una vez corregidos, ha miento agradable de estar cumpliendo su deber. Si
de hacerse otra revisi6n) o (3) aceptan el producto pro- se lleva a cab0 incorrectamente, la RTF puede tomar
visionalmente (se han encontrado errores menores que el aura de inquisition. Se deben seiialar 10s errores
deben ser corregidos, per0 sin necesidad de otra poste- educadamente; el tono de la reuni6n debe ser dis-
rior revisi6n). Una vez tomada la decisibn, todos 10s tendido y constructive; no debe intentarse dificultar
participantes terminan firmando, indicando asi que han o batallar. El jefe de revision debe moderar la reu-
participado en la revision y que esthn de acuerdo con ni6n para garantizar que se mantiene un tono y una
las conclusiones del equipo de revisi6n. actitud adecuados y debe inmediatamente cortar cual-
quier revisi6n que haya escapado a1 control.
8.5.2. Registro e informe d e la revision
Durante la RTF, uno de 10s revisores (el registrador)
procede a registrar todas las pegas que vayan surgien-
do. A1 final de la reuni6n de revisibn, resume todas las No seiole broscomente10s errores. Uno formo de ser
pegas y genera una lista de sucesos de revision. Ade- educodo es hocer uno pregunmito que permimitool productor
mhs, prepara un informe sumario de la revisi6n tCcnica descubrir su propio error.
formal. El informe sumario de revisi6n responde a tres
preguntas: Fijar una agenda y mantenerla. Un ma1 de las reu-
niones de todo tipo es la deriva. La RTF debe seguir
I. ~ Q u Cfue revisado? un plan de trabajo concreto. El jefe de revisi6n es el
2. ~QuiCnlo revis6? que carga con la responsabilidad de mantener el plan
3. ~ Q u Cse descubri6 y cuhles son las conclusiones? de la reuni6n y no debe tener miedo de cortar a la
El informe sumario de revisi6n es una phgina sim- gente cuando se empiece a divagar.
ple (con posibles suplementos). Se adjunta a1 registro 5 . Limitar el debate y las impugnaciones. Cuando un
hist6rico del proyecto y puede ser enviada a1 jefe del revisor ponga de manifiesto una pega, podrA no haber
proyecto y a otras partes interesadas. unanimidad sobre su impacto. En lugar de perder el
tiempo debatiendo la cuestibn, debe registrarse el
hecho y dejar que la cuesti6n se lleve a cab0 en otro
momento.
4. Enunciar h e a s de problemas, pero no intentar resol-
ver cualquier problema que se ponga de manijiesto.
Una revisi6n no es una sesi6n de resoluci6n de pro-
Inform Sumoriol y Listo de Sucesos de Revision TBcnico.
blemas. A menudo, la resolution de 10s problemas
puede ser encargada a1 productor por si solo o con
La lista de sucesos de revisidn sirve para dos pro- la ayuda de otra persona. La resolucibn de 10s pro-
p6sitos: (I) identificar hreas problemhticas dentro del blemas debe ser pospuesta para despuCs de la reu-
producto y (2) servir como lista de comprobacion de ni6n de revisi6n.
puntos de acci6n que guie a1 productor para hacer las
correcciones. Normalmente se adjunta una lista de con-
clusiones a1 informe sumario.
Es importante establecer un procedimiento de segui- i ~ m m a c i o n e smas bonitos
miento que asegure que 10s puntos de la lista de suce-
sos son corregidos adecuadamente. A menos que se haga
asi, es posible que las pegas surgidas cccaigan en sac0
rota>>. Un enfoque consiste en asignar la responsabili-
dad del seguimiento a1 revisor jefe 5. Tomar notas escritas. A veces es buena idea que el
registrador tome las notas en una pizarra, de forma
8.5.3. Directrices para la revision que las declaraciones o la asignaci6n de prioridades
Se deben establecer de antemano directrices para con- pueda ser comprobada por el resto de 10s revisores,
ducir las revisiones tCcnicas formales, distribuyhdolas a medida que se va registrando la informaci6n.
despuCs entre 10s revisores, para ser consensuadas y, 6. Limitar el numero de participantes e insistil- en lapre-
finalmente, seguidas. A menudo, una revisi6n incon- paracidn anticipada. Dos personas son mejores que
trolada puede ser peor que no hacer ning6n tip0 de revi- una, per0 catorce no son necesariamente mejores que
sion. A continuaci6n se muestra un conjunto minimo de cuatro. Se ha de mantener el numero de participantes
directrices para las revisiones tCcnicas formales: en el minimo necesario. Ademhs, todos 10s miembros
del equip0 de revisi6n deben prepararse por anticipado. Llevar a cabo un buen entrenamiento de todos 10s
El jefe de revisi6n debe solicitar comentarios (que revisores. Por razones de efectividad, todos 10s par-
muestren que cada revisor ha revisado el material). ticipantes en la revisi6n deben recibir algdn entre-
Desarrollar una lista de comprobacidn para cada namiento formal. El entrenamiento se debe basar en
producto que huya de ser revisado. Una lista de com- 10s aspectos relacionados con el proceso, asi como
probaciones ayuda a1 jefe de revisi6n a estructurar las consideraciones de psicologia humana que ata-
la reunidn de RTF y ayuda a cada revisor a centrarse Aen a la revisi6n. Freedman y Weinberg [FRE90]
en 10s asuntos importantes. Se deben desarrollar lis- estiman en un mes la curva de aprendizaje para cada
tas de comprobaciones para 10s documentos de an& veinte personas que vayan a participar de forma efec-
lisis, de disefio, de codificaci6n e incluso de prueba. tiva en las revisiones.
10. Repasar las revisiones anteriores. Las sesiones de
informaci6n pueden ser beneficiosas para descubrir
problemas en el propio proceso de revisi6n. El pri-
mer producto que se haya revisado puede estable-
cer las propias directivas de revisi6n.
Como existen muchas variables (por ejemplo, ndme-
Listos de comprobocibn de RTF
ro de participantes, tip0 de productos de trabajo, tiem-
Disponer recursos y una agenda para las RTF. Para po y duraci61-1,enfoque de revisi6n especifico) que tienen
que las revisiones Sean efectivas, se deben planificar impact0 en una revisi6n satisfactoria, una organizaci6n
como una tarea del proceso de ingenieria del soft- de software deberia determinar quC mCtodo funciona
ware. Ademas se debe trazar un plan de actuaci6n mejor en un context0 local. Porter y sus'colegas
para las modificaciones inevitables que aparecen [POR95] proporcionan una guia excelente para este tip0
como resultado de una RTF. de experimentos.
La garantia de calidad estadistica refleja una ten-

dencia, creciente en toda la industria, a establecer la
calidad mhs cuantitativamente. Para el software, la
garantia de calidad estadistica implica 10s siguientes
pasos:
Se agrupa y se clasifica la informaci6n sobre 10s
defectos del software. Para ilustrar el proceso, supongamos que una orga-
Se intenta encontrar la causa subyacente de cada nizaci6n de desarrollo de software recoge informaci6n
defect0 (por ejemplo, no concordancia con la espe- sobre defectos durante un period0 de un aAo. Algunos
cificacibn, error de diseAo, incumplimiento de 10s de 10s defectos se descubren mientras se desarrolla el
estindares, pobre comunicaci6n con el cliente). software. Otros se encuentran despuCs de que el soft-
ware se haya distribuido a1 usuario final. Aunque se des-
~ Q u pasos
e se requieren cubren cientos de errores diferentes, todos se pueden
para desarrollar una SQA encontrar en una (o mhs) de las siguientes causas:
estadistica?
Especificaci6n incompleta o err6nea (EIE).
Mala interpretaci6n de la comunicaci6n del cliente
Mediante el principio de Pareto (el 80 por 100 de 10s (MCC).
defectos se pueden encontrar en el 20 por 100 de
todas las posibles causas), se aisla el 20 por 100 (10s Desviaci6n deliberada de la especificaci6n (DDE).
<<pocosvitalew). Incumplimiento de 10s esthndares de programaci6n
(IEP).
Una vez que se han identificado 10s defectos vitales,
se actda para corregir 10s problemas que han produ- Error en la representacih de 10s datos (ERD).
cido 10s defectos. Interfaz de m6dulo inconsistente (IMI).
Este concept0 relativamente sencillo representa un Error en la 16gica de diseAo (ELD).
paso importante hacia la creaci6n de un proceso de inge- Prueba incompleta o err6nea (PIE).
nieria del software adaptativo en el cual se realizan cam- Documentaci6n imprecisa o incompleta (DII).
bios para mejorar aquellos elementos del proceso que Error en la traducci6n del diseAo a1 lenguaje de pro-
introducen errores. gramaci6n (TLP).
A SOFTWARE. U N E N F O Q U E PRACTICO
Interfaz hombre-mhquina arnbigua o inconsistente En cada etapa del proceso de ingenieria del softwa-
(IHM) . re se calcula un indice de fase, IFi:
Varios (VAR).
IFi = W, (Si/Ei) +W, (MiiEi) + W, (Ti/Ei)
El indice de errores (IE) se obtiene mediante el calcu-
lo del defect0 acumulativo de cada IFi, asignando mhs
peso a 10s errores encontrados mhs tarde en el proceso de
l o Asocioci6n Chino de Colidod del Software present0 ingenieria del software, que a 10s que se encuentran en las
uno de 10s sitios web rn6s cornpletos poro lo colidod en primeras etapas:
www.cosq.org
IE = E (i x IF,) I PS
Para aplicar la SQA estadistica se construye la Tabla = (IF, + 2IF, + 3IF, + ... iIFi) I PS
8.1. La tabla indica que EIE, MCC y ERD son las cau-
sas vitales que contabilizan el 53 por 100 de todos 10s
errores. Sin embargo, debe observarse que si s610 se Total Grave Moderado Leve
consideraran errores serios, se seleccionan'an las siguien-
tes causas vitales: EIE, ERD, TLP y ELD. Una vez deter- Error No. % No. % No. % No. %
minadas las causas vitales, la organizaci6n de desarrollo
de software puede comenzar la accidn correctiva. Por IEE
ejemplo, para corregir la MCC, el equipo de desarrollo
del software podria implementar tCcnicas que facilita- MCC
ran la especificaci6n de la aplicacidn (Capitulo 11) para
mejorar la calidad de la especificaci6n y la comunica- DDE
ci6n con el cliente. Para mejorar el ERD, el equipo de
desarrollo del software podria adquirir herramientas IEP
CASE para la modelizaci6n de datos y realizar revisio-
nes del diseiio de datos mAs rigurosas. ERD
Es importante destacar que la accidn correctiva se
IMI
centra principalmente en las causas vitales. Cuando Cstas
son corregidas, nuevas candidatas saltan a1 principio de ELD
la lista.
Se han mostrado las tkcnicas de garantia de calidad PIE
del software estadisticas para proporcionar una mejora
sustancial en la calidad [ART97]. En algunos casos, las DII
organizaciones de software han conseguido una reduc-
ci6n anual del50 por 100 de 10s errores despuCs de la TLP
aplicacidn de estas tCcnicas.
Junto con la recopilaci6n de informaci6n sobre defec- IHM
tos, 10s equipos de desarrollo del software pueden cal-
cular un indice de errores (IE) para cada etapa principal VAR
del proceso de ingenieria del software [IEE94]. Des-
puks del analisis, el diseiio, la codificacidn, la prueba y Totales 942 100% 128 100% 379 100% 435 100%
la entrega, se recopilan 10s siguientes datos:
TABLA 8.1. Recoleccion de datos para la SQA estadistica
Ei= numero total de defectos descubiertos durante la eta-
pa i-Csima del proceso de ingenieria del software;
Si= numero de defectos graves; Se puede utilizar el indice de errores junto con la
M i=numero de defectos moderados; informacidn recogida en la Tabla 8.1, para desarrollar
Ti= numero de defectos leves; una indicacidn global de la mejora en la calidad del soft-
ware.
PS =tamaiio del product0 (LDC, sentencias de disefio, La aplicacidn de la SQA estadistica y el principio de
paginas de documentacibn) en la etapa i-ksima. Pareto se pueden resumir en una sola frase: iUtilizar el
W s, W , , W ,= factores de peso de errores graves, mode- tiempo para centrarse en cosas que realmente intere-
rados, y leves, en donde 10s valores recomendados san, pero primer0 asegurarse que se entiende que' es lo
son W s = 10, W , = 3, Wt = 1. Los factores de peso que realmente interesa!
de cada fase deberian agrandarse a medida que el Un estudio exhaustivo de la SQA estadistica se sale
desarrollo evoluciona. Esto favorece a la organi- del alcance de este libro. Los lectores interesados debe-
zacidn que encuentra 10s errores a1 principio. rian consultar [SCH98], [KAP95] y [KAN95].
CAPfTULO 8 GARANTfA DE CALIDAD DEL SOFTWARE
No hay duda de que la fiabilidad de un programa de

computadora es un elemento importante de su calidad
general. Si un programa falla frecuente y repetidamen-
te en su funcionamiento, no importa si el resto de 10s
10s problemos de lo fiobilidod del software se deben cosi
factores de calidad son aceptables.
siempre o errores en el diseiio o en lo implementocibn.
Todavia se debate sobre la relaci6n entre 10s con-

ceptos clave de la fiabilidad del hardware y su aplica-
Referencia web/ ' bilidad a1 software (por ejemplo, [LIT89], [R0090]).
El Centro de Analisis de Fiobilidod proporciono mucho Aunque adn falta por establecer un nexo irrefutable,
informocibn util sobre lo fiobilidad, montenibilidod, merece la pena considerar unos cuantos conceptos que
soporte y colidad en rac.iitri.org conciernen a ambos elementos de 10s sistemas.
Considerando un sistema basado en computadora,
La fiabilidad del software, a diferencia de otros una sencilla medida de la fiabilidad es el tiempo medio
factores de calidad, puede ser medida o estimada entre fallos (TMEF), donde;
mediante datos hist6ricos o de desarrollo. Lafiabili-
dad del software se define en tCrminos estadisticos TMEF = TMDF + TMDR
como ccla probabilidad de operaci6n libre de fallos de
un programa de computadora en un entorno determi- Las siglas TMDF y TMDR corresponden a tiempo
nado y durante un tiempo especifico,, [MUS87]. Por medio de fallo y tiempo medio de reparacibn, respecti-
ejemplo, un programa X puede tener una fiabilidad vamente.
estimada de 0,96 durante un interval0 de proceso de
ocho horas. En otras palabras, si se fuera a ejecutar el r es TMEF
~ P o que
programa X 100 veces, necesitando ocho horas de . una mitrica mas util
tiempo de proceso (tiempo de ejecuci6n), lo probable que errores/LDC?
es que funcione correctamente (sin fallos) 96 de cada
100 veces. Muchos investigadores argumentan que el TMDF
Siempre que se habla de fiabilidad del software, sur- es, con mucho, una medida rnis fitil que 10s defec-
ge la pregunta fundamental: ~ Q u C se entiende por el tCr- tos/KLDC o defectos/PF. Sencillamente, el usuario
mino fallo'?En el context0 de cualquier discusi6n sobre final se enfrenta a 10s fallos, no a1 ndmero total de erro-
calidad y fiabilidad del software, el fallo es cualquier res. Como cada error de un programa no tiene la mis-
falta de concordancia con 10s requisitos del software. ma tasa de fallo, la cuenta total de errores no es una
Incluso en esta definici6n existen grados. Los fallos pue- buena indicaci6n de la fiabilidad de un sistema. Por
den ser simplemente desconcertantes o ser catastr6fi- ejemplo, consideremos un programa que ha estado fun-
cos. Puede que un fallo sea corregido en segundos cionando durante 14 meses. Muchos de 10s errores del
mientras que otro lleve semanas o incluso meses. Para programa pueden pasar desapercibidos durante dCca-
complicar mis las cosas, la correcci6n de un fallo pue- das antes de que se detecten. El TMEF de esos erro-
de llevar a la introducci6n de otros errores que, final- res puede ser de 50 e incluso de 100 aiios. Otros
mente. lleven a mis fallos. errores, aunque no se hayan descubierto a h , pueden
tener una tasa de fallo de 18 6 24 meses. Incluso aun-
que se eliminen todos 10s errores de la primera cate-
8.7.1. Medidas de fiabilidad y de disponibilidad
goria (10s que tienen un gran TMEF), el impact0 sobre
Los primeros trabajos sobre fiabilidad intentaron extra- la fiabilidad del software sera muy escaso.
polar las matematicas de la teoria de fiabilidad del hard- Ademhs de una medida de la fiabilidad debemos
ware (por ejemplo: [ALV64]) a la predicci6n de la obtener una medida de la disponibilidad. La disponibi-
fiabilidad del software. La mayoria de 10s modelos de lidad del sofmare es la probabilidad de que un progra-
fiabilidad relativos a1 hardware van rnis orientados a ma funcione de acuerdo con 10s requisitos en un
10s fallos debidos a1 desajuste que a 10s fallos debidos momento dado, y se define como:
a defectos de diseiio. En el hardware, son mis proba-
b l e ~10s fallos debidos a1 desgaste fisico (por ejemplo: Disponibilidad = [TMDF/(TMDF + TMDR)] x 100 %
el efecto de la temperatura, de la corrosi6n y 10s gol-
pes) que 10s fallos relativos a1 diseiio. Desgraciadamente, La medida de fiabilidad TMEF es igualmente sen-
para el software lo que ocurre es lo contrario. De hecho, sible al.TMDF que a1 TMDR. La medida de disponi-
todos 10s fallos del software, se producen por proble- bilidad es algo rnis sensible a1 TMDR, una medida
mas de diseiio o de implementaci6n; el desajuste (con- indirecta de la facilidad de mantenimiento del soft-
sulte el Capitulo 1) no entra en este panorama. ware.
INGEN1ERfA DEL SOFTWARE. U N ENFOQUE PRICTICO
8.7.2. Seguridad del software

Leveson [LEV861 discute el impacto del software en
sistemas criticos de seguridad, diciendo:
Antes de que se usara software en sistemas m'ticos de segu-
ridad, normalmente tstos se controlaban mediante dispositi-
3
Referencia Web
Se pueden encontror documentos sobre lo seguridod
del software (y un glosorio detollodo) que merecen
vos electr6nicos y mecinicos convencionales (no progra- lo pen0 en www.rstcorp.corn/hotlist/topics-
mables). Las ttcnicas de seguridad de sistemas se diseiiaban
safety.htrnl
para hacer frente a fallos aleatorios en esos dispositivos [no
programables]. Los errores humanos de diseiio no se consi-
deraban porque se suponia que todos 10s defectos producidos vedad y su probabilidad de ocurrencia4. Para que sea
por 10s errores humanos se podian evitar o eliminar comple- efectivo, se tiene que analizar el software en el contex-
tamente antes de su distribuci6n y funcionamiento. to del sistema completo. Por ejemplo, puede que un sutil
error en la entrada del usuario (las personas son com-
ponentes del sistema) se magnifique por un fallo del
software que producen 10s datos de control que actuan
de forma inadecuada sobre un dispositivo mecinico. Si
ede &e borco. l o construction se dan un conjunto de condiciones extemas del entor-
ahadio nt6s o f de eso. no (y s61o si se dan), la situaci6n inadecuada del dis-
ikllltonk positivo mecanico producira un fallo desastroso. Se
pueden usar tCcnicas de analisis, como el analisis del
Cuando se utiliza el software como parte del siste- arb01 de fallos [VES81], la lbgica de tiempo real
ma de control, la complejidad puede aumentar en un [JAN861 o 10s modelos de redes de Petri [LEV87], para
orden de magnitud o mas. Los defectos sutiles de dise- predecir la cadena de sucesos que pueden producir 10s
iio, producidos por un error humano -algo que se pue- riesgos y la probabilidad de que se dC cada uno de 10s
de descubrir y eliminar en el control convencional sucesos que componen la cadena.
basado en el hardware- llegan a ser mucho mas difi- Una vez que se han identificado y analizado 10s ries-
ciles de descubrir cuando se utiliza el software. gos, se pueden especificar 10s requisitos relacionados
La seguridad del software es una actividad de garan- con la seguridad para el software. Esto es, la especifi-
tia de calidad del software que se centra en la identifi- caci6n puede contener una lista de eventos no desea-
caci6n y evaluacidn de 10s riesgos potenciales que bles y las respuestas del sistema a estos eventos. El papel
pueden producir un impacto negativo en el software y del software en la gesti6n de eventos no deseados es
hacer que falle el sistema completo. Si se pueden iden- entonces apropiado.
tificar pronto 10s riesgos en el proceso de ingenieria del
software podrh especificarse las caracteristicas del dise- ~ C u aes
l la diferencia
iio del software que permitan eliminar o controlar 10s entre fiabilidad del software
riesgos potenciales. y seguridad del software?
Como parte de la seguridad del software, se puede Aunque la fiabilidad y la seguridad del software e s t h
dirigir un proceso de analisis y modelado. Inicialmente, bastante relacionadas, es importante entender la sutil
se identifican 10s riesgos y se clasifican por su impor- diferencia que existe entre ellas. La fiabilidad del soft-
tancia y su grado de riesgo. Por ejemplo, algunos de ware utiliza el analisis estadistico para determinar la
10s riesgos asociados con el control basado en com- probabilidad de que pueda ocurrir un fallo del softwa-
putadora del sistema de conducci6n de un autom6vil re. Sin embargo, la ocurrencia de un fallo no lleva nece-
podrian ser: sariamente a un riesgo o a un accidente. La seguridad
Produce una aceleraci6n incontrolada que no se del software examina 10s modos segun 10s cuales 10s
puede detener. fallos producen condiciones que pueden llevar a acci-
No responde a la presi6n del pedal del freno (dete- dentes. Es decir, 10s fallos no se consideran en vacio,
nikndose). sino que se evaluan en el context0 de un completo sis-
No responde cuando se activa el contacto. tema basado en computadora.
Un estudio completo sobre seguridad del software y
Pierde o gana velocidad lentarnente. anasis del riesgo va mAs allh del Ambit0 de este libro. Para
Cuando se han identificado estos riesgos del siste- aquellos lectores que estCn mas interesados,deberian con-
ma, se utilizan tCcnicas de analisis para asignar su gra- sultar el libro de Leveson [LEV951 sobre este tema.
Este metodo e s anologo al metodo de analisis de riesgos descrito

para la gestion del proyecto de software en el capitulo 6. La princi-
pal diferencia es el enfasis en aspectos de tecnologia frente a temas
relacionados con el proyecto.
C A P ~ T U L O8 GARANTfA DE CALIDAD DEL SOFTWARE
Si William Shakespeare hubiera escrito sobre las con- Para llevar a cab0 la entrada adecuada del menu para cada apli-
diciones del ingeniero de software modemo, podria per- cacion, un cdocalizadorn (una persona que habla en el idioma
local y con la terminologia de ese lugar) traduce 10s menus de
fectamente haber escrito: <<Errares humano, encontrar acuerda con el idioma en uso. El problema es asegurar que (1)
el error rapida y correctamente es divine.,, En 10s afios cada entrada de menu (pueden existir cientos de ellas) se ade-
sesenta, un ingeniero industrial japonCs, Shigeo Shin- cue a 10s estindares apropiados y que no existan conflictos,
go [SHI86], que trabajaba en Toyota, desarroll6 una tCc- independientemente del lenguaje que se esti utilizando.
nica de garantia de calidad que conducia a la prevention El uso del poka-yoke para la prueba de diversos
y/o a la temprana correcci6n de errores en el proceso de mends de aplicacion desarrollados en diferentes len-
fabricaci6n. Denominado poka-yoke (prueba de erro- guajes, tal y como se ha descrito anteriormente, se dis-
res), el concepto de Shingo hacia uso de dispositivos cute en un articulo de Harry Robinson [ROB97]:
poka-yoke -mecanismos que conducen (1) a la pre- Nosotros primero decidimos dividir el problema de prue-
venci6n de un problema de calidad potencial antes de bas de menus en partes que puedan ser resueltas mis facil-
que Cste ocurra, o (2) a la rhpida detecci6n de proble- mente. Nuestro primer avance para la resolucion del problema
mas de calidad si se han introducido ya-. Nosotros fue el comprender que existian dos aspectos separados para 10s
encontramos dispositivos poka-yoke en nuestra vida catilogos de mensaje. Habia por una parte el aspecto de con-
cotidiana (incluso si nosotros no tenemos conciencia de tenidos: las traducciones de texto muy simples tales como cam-
biar meramente &losen por la palabra ccFermern. Puesto que
este concepto). Por ejemplo, el interruptor de arranque el equipo que realizaba las comprobaciones no hablaba de for-
de un coche no trabaja si esth metida una marcha en la ma fluida el lenguaje en el que se pretendia trabajar, teniamos
transmision automatics (un dispositivo de prevencidn); que dejar estos aspectos a traductores expertos del lenguaje.
un pitido de aviso del coche sonar6 si 10s cinturones de El segundo aspecto de 10s catalogos del mensaje era
seguridad no esthn bien sujetos (un dispositivo de detec- la estructura, las reglas sinticticas que debia obedecer
cidn de fallos). un cathlogo de objetivos adecuadamente construido. A
Un dispositivo de poka-yoke presenta un conjunto diferencia del contenido, en este caso si que era posible
de caracteristicas comunes: para el equipo de comprobaci6n el verificar 10s aspec-
Es simple y barato -si un dispositivo es demasiado tos estructurales de 10s cat8logos.
complicado y caro, no sera efectivo en cuanto a Como un ejemplo de lo que significa estructura, con-
cost*; sideremos las etiquetas y 10s mnem6nicos de un mend
Es parte del proceso +st0 es, el dispositivo poka- de aplicacion. Un mend esta constituido por etiquetas
yoke esta integrado en una actividad de ingenieria-; y sus mnem6nicos (abreviaturas) asociados. Cada mend,
Esth localizado cerca de la tarea del proceso donde independientemente de su contenido o su localizaci6n,
esthn ocurriendo 10s errores -por consiguiente pro- debe obedecer las siguientes reglas listadas en la Guia
porciona una realimentacion rhpida en cuanto a la de Estilo Motif:
correcci6n de errores se refiere-. Cada nemotCcnico debe estar contenido en su eti-
queta asociada;
2
Referencia Web
Se puede obtener uno coleccibn cornpleta de recursos
de poko-yoke en
Cada nemotkcnico debe ser dnico dentro del mend;
Cada nemotCcnico debe ser un carhcter dnico;
Cada nemotkcnico debe estar en ASCII.
Estas reglas son invariantes a travCs de las localiza-
www.campbell.berry.edu/faculty/igrout/ ciones, y pueden ser utilizadas para verificar que un mend
pokayoke.shtml esth correctamente construido en la localizaci6n objetivo.
Existen varias posibilidades para realizar la prueba
de errores de 10s mnem6nicos del mend:
Aunque el poka-yoke fue originariamente desarro- Dispositivo de prevencidn. Nosotros podemos escri-
llado para su uso en <<controlde calidad cero,, [SHI86] bir un programa para generar 10s mnem6nicos automh-
para el hardware fabricado, puede ser adaptado para su ticamente, dada una lista de etiquetas en cada mend.
uso en ingenieria del software. Para ilustrar esto, con- Este enfoque evitaria errores, per0 el problema es que
sideremos el problema siguiente [ROB97]: escoger un mnem6nico adecuado es dificil, y el esfuer-
Una compaiiia de productos de software vende el software zo requerido para escribir el programa no estaria justi-
de aplicacion en el mercado intemacional. Los menus desple- ficado con el beneficio obtenido.
gables y todos 10s codigos asociados proporcionados con cada
aplicacion deben reflejar el lenguaje que se ernplea en el lugar
Dispositivo de prevencidn. Podriamos escribir un
donde se usa. Por ejemplo, el elemento del menu del lenguaje programa que prevendria a1 localizador de elegir unos
inglCs para c<Closen,tiene el mnem6nico <<Cnasociado con ello. mnemdnicos que no satisfagan el criterio. Este enfoque
Cuando la aplicacion se vende en un pais de habla francesa, el tarnbiCn evitaria errores, per0 el beneficio obtenido seria
mismo elemento del menu es ctFermen) con el mnem6nico <<F,). minimo; 10s mnem6nicos incorrectos son lo suficiente-
mente f a d e s de detectar y corregir despuCs de que apa- estructurales de 10s men6s . Un pequeiio <<script>> poka-
. rezcan. yoke leeria la tabla, recuperaria 10s mnemhicos y eti-
Dispositivo de deteccidn. Nosotros podriamos pro- quetas a partir del catalog0 de mensajes, y compararia
porcionar un programa para verificar que las etiquetas posteriormente las cadenas recuperadas con el criterio
del men6 escogidas y 10s mnem6nicos satisfacen 10s establecido descrito anteriormente.
criterios anteriores. Nuestros localizadores podnan eje- Los <<scripts>>poka-yoke eran pequefios (aproximada-
cutar 10s programas sobre 10s catalogos de mensaje tra- mente 100 lineas), fhciles de escribir (algunos de 10s escri-
ducidos antes de enviarnos a nosotros dichos catalogos. tos estaban en cuanto a1 tiempo por debajo de una hora)
Este enfoque proporcionan'a una realimentacion rapida y faciles de ejecutar. Nosotros ejecutabamos nuestros
sobre 10s errores y sera, probablemente, un paso a dar c<scripts>>poka-yoke sobre 16 aplicaciones en la ubicaci6n
en el futuro. en inglCs por defect0 y en 11 ubicaciones extranjeras. Cada
Dispositivo de deteccidn. Nosotros podnamos escri- ubicaci6n contenia 100 menus para un total de 1.200
bir un programa que verificase las etiquetas y mnem6ni- menus. Los dispositivospoka-yoke encontraron 3 11 erro-
cos del men6, y ejecutara el programa sobre catalogos de res en menus y mnem6nicos. Pocos de 10s problemas que
mensajes despuCs de que nos 10s hayan devuelto 10s loca- nosotros descubrimos eran como muy llamativos, pero en
lizadores. Este enfoque es el camino que actualmente total habnan supuesto una gran preocupacion en la prue-
estamos tomando. No es tan eficiente como alguno de 10s ba y ejecuci6n de nuestras aplicaciones localizadas.
mCtodos anteriormente mencionados y puede requerir El ejemplo descrito antes representa un dispositivo
que se establezca una comunicacion fluida hacia delan- poka-yoke que ha sido integrado en la actividad de prue-
te y hacia atras con 10s localizadores, per0 10s errores bas de ingenieria del software. La tecnica poka-yoke
detectados son incluso faciles de corregir en este punto. puede aplicarse a 10s niveles de disefio, codificaci6n y
Varios textos pequefios de poka-yoke se utilizaron pruebas y proporciona un filtro efectivo de garantia de
como dispositivos poka-yoke para validar 10s aspectos calidad.
Esta seccion contiene varios objetivos, siendo el prin- IS0 9004-2. Quality Management and Quality Sys-
cipal describir el cada vez mas importante esthdar inter- tem Elements -Part 2-. Este documento propor-
national I S 0 9001. El estandar, que ha sido adoptado ciona las directrices para el semicio de facilidades
por mas de 130 paises para su uso, se esta convirtiendo del software como soporte de usuarios.
en el medio principal con el que 10s clientes pueden juz- Los requisitos se agrupan bajo 20 titulos:
gar la competencia de un desarrollador de software. Uno
de 10s problemas con el estandar I S 0 9001 esta en que Responsabilidad de la gesti6n.
no es especifico de la industria: esta expresado en tCr- Inspecci6n, medicion y equipo de pruebas.
minos generales, y puede ser interpretado por 10s desa- Sistema de calidad.
rrolladores de diversos productos como cojinetes de Inspecci6n y estado de pruebas.
bolas (rodamientos), secadores de pelo, autom6viles, Revision de contrato.
equipamientos deportivos y televisiones, asi como por Acci6n correctiva.
desarrolladores de software. Se han realizado muchos Control de disefio.
documentos que relacionan el estandar con la industria Control de producto no aceptado.
del software, per0 no entran en una gran cantidad de Control de documento.
detalles. El objetivo de esta secci6n es describir lo que Tratamiento, almacenamiento, empaquetamiento y
significa el I S 0 9001 en tCrminos de elementos de cali- entrega.
dad y tCcnicas de desarrollo. Compras.
Para la industria del software 10s estandares rele- Producto proporcionado a1 comprador.
vantes son: Registros de calidad.
IS0 9001. Quality Systems- Model for Quality Assu- Identficaci6n y ysibilidad de seguimiento del producto.
Auditonas internas de calidad.
rance in Design, Development, Production, Insta-
llation and Servicing. Este es un esthndar que Formaci6n
describe el sistema de calidad utilizado para mante- Control del proceso
Semicios.
ner el desarrollo de un producto que implique disefio.
IS0 9000-3. Guidelinesfor Application of I S 0 9001 Inspeccion y estado de prueba.
to the Development, Supply and Maintainance of Tkcnicas estadisticas.
Software. Este es un documento especifico que Merece la pena ver un pequefio extract0 de la I S 0
interpreta el I S 0 9001 para el desarrollador de soft- 9001. Este le darh a1 lector una idea del nivel con el que
ware. la I S 0 9001 trata la garantia de calidad y el proceso de
CAPiTULO 8 GARANTLA DE CALIDAD DEL SOFTWARE
desarrollo. El extract0 elegido proviene de la secci6n ci6n del parrafo -es pretendido obviamente por 10s
1.11: procesos estandar de ingenieria donde equipos tales
4.11. El equipo de Inspecci6n, medici6n y pruebas. como indicadores de calibraci6n y potenci6metros son
habituales-.
El suministradordebe controlar,calibrar y mantener la ins-
pecci6n, medir y probar el equipo, ya sea el dueiio el suminis- Una interpretaci6n del parrafo anterior es que el dis-
trador, prestado o proporcionado por el comprador, para tribuidor debe asegurar que cualquiera de las herramien-
demostrar la conformidad del producto con 10s requisitos espe- tas de software utilizadas para las pruebas tiene, por lo
cificados. El equipo debe utilizarse de un mod0 que asegure menos, la misma calidad que el software a desarrollar, y
que se conoce la incertidumbre de la medici6n y que es con- que cualquier prueba del equipo produce valores de medi-
sistente con la capacidad de medici6n requerida.
ci6n, por ejemplo, 10s monitores del rendimiento, tienen
Lo primer0 a destacar es su generalidad; se puede una precisi6n aceptable cuando se compara con la preci-
aplicar a1 desarrollador de cualquier producto. Lo si6n especificada para el rendimiento en la especificaci6n
segundo a considerar es la dificultad en la interpreta- de 10s requisitos.
. . . .
. . .
DE SOA
El plan de SQA proporciona un mapa para institucio- : documentos de usuario (por ejemplo: archivos de
nalizar la garantia de calidad del software. El plan, desa- ayuda).
rrollado por un grupo de SQA, sirve como plantilla para AdemAs, esta secci6n define el conjunto minimo de
actividades de SQA instituidas para cada proyecto de productos de trabajo que se pueden aceptar para lograr
software. alta calidad.
Los esthndares, practicas y convenciones muestran
todos 10s estAndares/practicasque se aplican durante el
proceso de software (por ejemplo: estindares de docu-
mentos, estandares de codificaci6n y directrices de revi-
si6n). Ademas, se listan todos 10s proyectos, procesos y
El Plan GCS (en algunos casos) mktricas de producto que se van a reco-
ger como parte del trabajo de ingenieria del software.
El IEEE [IEEE94] ha recomendado un esthndar para La secci6n Revisiones y Auditorias del plan identi-
10s planes de SQA. Las secciones iniciales describen el fica las revisiones y auditorias que se van a llevar a cab0
prop6sito y el alcance del documento e indican aque- por el equipo de ingenieria del software, el grupo de
llas actividades del proceso del software cubiertas por SQA y el cliente. Proporciona una visi6n general del
la garantia de calidad. Se listan todos 10s documentos enfoque de cada revisi6n y auditoria.
seiialados en el plan de SQA y se destacan todos 10s La secci6n Prueba hace referencia a1 Plan y Procedi-
estandares aplicables. La secci6n de Gestidn del plan miento de Pruebas del Sofh~are(Capitulo 18). TambiCn
describe la situaci6n de la SQA dentro de la estructura define requisitos de mantenimiento de registros de prue-
organizativa; las tareas y las actividades de SQA y su bas. La Informacibn sobre problemas y accidn correcti-
emplazamiento a lo largo del proceso del software; asi va define procedimientos para informar, hacer segui-
como 10s papeles y responsabilidades organizativas rela- miento y resolver errores y defectos, e identifica las res-
tivas a la calidad del producto. ponsabilidades organizativas para estas actividades.
La secci6n de Documentacibn describe (por referen- El resto del plan de SQA identifica las herramientas
cia) cada uno de 10s productos de trabajo producidos como y mCtodos que soportan actividades y tareas de SQA;
parte del proceso de software. Entre estos se incluyen: hace referencia a 10s procedimientos de gesti6n de con-
figuraci6n del software para controlar el cambio; defi-
documentos del proyecto (por ejemplo: plan del pro- ne un enfoque de gesti6n de contratos; establece mCtodos
yecto), para reunir, salvaguardar y mantener todos 10s registros;
modelos (por ejemplo: DERs, jerarquias de clases), identifica la formaci6n que se requiere para cumplir las
documentos tCcnicos (por ejemplo: especificaciones, necesidades del plan y define mCtodos para identificar,
planes de prueba), evaluar, supervisar y controlar riesgos.
lNGENIERiA DEL SOFTWARE. U N ENFOQUE PRACTICO
La garantia de calidad del software es una ccactividad mostrado extremadamenteefectiva en el descubrimiento

de protecci6n~que se aplica a cada paso del proceso de errores.
del software. La SQA comprende procedimientos para Para llevar a cab0 adecuadamente una garantia de
la aplicaci6n efectiva de mitodos y herramientas, revi- calidad del software, se deben recopilar, evaluar y dis-
siones tkcnicas formales, tkcnicas y estrategias de prue- tribuir todos 10s datos relacionados con el proceso de
ba, dispositivos poka-yoke, procedimientos de control ingenieria del software. La SQA estadistica ayuda a
de cambios, procedimientos de garantia de ajuste a 10s mejorar la calidad del product0 y la del proceso de soft-
estandares y mecanismos de medida e informaci6n. ware. Los modelos de fiabilidad del software amplian
La SQA es complicada por la compleja naturaleza de las medidas, permitiendo extrapolar 10s datos recogidos
la calidad del software -un atributo de 10s programas sobre 10s defectos, a predicciones de tasas de fa110 y de
de computadora que se define como ccconcordancia con fiabilidad.
10s requisitos definidos explicita e implicitamente>>-. Resumiendo, recordemos las palabras de Dunn y U11-
Cuando se considera de forma mas general, la calidad del man [DUN82]: <<Lagarantia de calidad del software es
software engloba muchos factores de proceso y de pro- la guia de 10s preceptos de gesti6n y de las disciplinas
ducto diferentes con sus mktricas asociadas. de disefio de la garantia de calidad para el espacio tec-
Las revisiones del software son una de las activida- nol6gico y la aplicaci6n de la ingenieria del software.,,
des mas importantes de la SQA. Las revisiones sirven La capacidad para garantizar la calidad es la medida de
como filtros durante todas las actividades de ingenieria madurez de la disciplina de ingenieria. Cuando se sigue
del software, eliminando defectos mientras que no son de forma adecuada esa guia anteriormente menciona-
relativarnente costosos de encontrar y corregir. La revi- da, lo que se obtiene es la madurez de la ingenieria del
si6n tkcnica formal es una revision especifica que se ha software.
[ALV64] von Alvin, W. H. (ed.), Reliability Engineering, [GLA98] Glass, R., <<Defining
Quality Intuitively>>,
IEEE Soft-
Prentice-Hall, 1964. ware, Mayo 1998, pp. 103-104 y 107.
[ANS87] ANSIJASQC A3-1987, Quality Systems Termino- [HOY98] Hoyle, D., Iso 9000 Quality Systems Development
logy, 1987. Handbook: A Systems Engineering Approach, Buttenvorth-
Heinimann, 1998.
[ART921Arthur, L. J., Improving Software Quality: An Insi-
der's Guide to TQM, Wiley, 1992. [IBM81] cdmplementating Software Inspections>>,notas del
curso, IBM Systems Sciences Institute, IBM Corporation,
[ART971 Arthur, L. J., <<QuantumImprovements in Softwa- 1981.
re System Quality,,, CACM, vol. 40, n." 6, Junio 1997, pp.
47-52. [LEE901 Software Quality Assurance: Model Procedures, Ins-
titution of Electrical Engineers, 1990.
[BOE8 I] Boehm, B., Software Engineering Economics, Pren-
tice-Hall, 1981. [IEE94] Soffware Engineering Standards, ed. de 1994, IEEE
Computer Society, 1994
[CR075] Crosby, P., Quality is Free, McGraw-Hill, 1975. [JAN861 Jahanian, F., y A. K. Mok, <<SafetyAnalysis of
[CR079] Crosby, P., Quality is Free, McGraw-Hill, 1979. Timing Properties of Real Time Systems*, IEEE Trans.
Software Engineering, vol. SE-12, n." 9, Septiembre 1986,
[DEM86] Deming, W. W., Out of the Crisis, MIT Press, 1986.
pp. 890-904.
[DEM99] DeMarco, T., ((Management Can Make Quality [JON861 Jones, T. C., Programming Productivity, McGraw-
(Irn)possible>>,presentacidn de Cutter Summit '99, Bos- Hill, 1986.
ton, MA, 26 de Abril 1999.
[KAN95] Kan, S. H., Metrics and Models in Software Qua-
[DIJ76] Dijkstra, E., A Discipline of Programming, Prentice- lity Engineering, Addison Wesley, 1995.
Hall, 1976.
[ U P 9 5 1 Kaplan, C., R. Clark y V. Tang, Secrets of Softwa-
[DUN821 Dunn, R., y R. Ullman, Quality Assurance for Com- re Quality: 40 Innovations from IBM, McGraw-Hill, 1995.
puter Software, McGraw-Hill, 1982.
[LEV861 Leveson, N.G., <<SoftwareSafety: Why, What, and
[FRE90] Freedman, D. P., y G. M. Weinberg, Handbook of How>>,ACM Computing Surveys, vol. 18, n.", Junio 1986,
Walkthroughs, Inspections and Technical Reviews, 3.%d., pp. 125-163.
Dorset House, 1990. [LEV871 Leveson, N. G., y J.L. Stolzy, ((SafetyAnalysis using
[GIL93] Gilb, T., y D. Graham, Software Inspections, Addi- Petri Netsa, IEEE Trans. Software Engineering, vol. SE-13,
son-Wesley, 1993. n." 3, Marzo 1987, pp. 386-397.
CApfTULO 8 G A R A N T f A D E CALIDAD DEL S O F T W A R E
[LEV951 Leveson, N.G., Safeware: System Safety and Com- [ROO901Rook, J., Sofhvare Reliability Handbook, Elsevier,
puters, Addison-Wesley, 1995. 1990.
[LIN79] Linger, R., H. Mills y B. Witt, Structured Program- [SCH98] Schulmeyer, G. C., y J.I. McManus (eds.), Hand-
ming, Addison-Wesley, 1979. book of Software Quality Assurance, Prentice-Hall, 3.%d.,
[LIT891 Littlewood, B., <<ForecastingSoftware Reliability>>, 1998.
en Sofhvare Reliability: Modelling and identification (S. [SCH94] Schmauch, C.H., IS0 9000 for Sofiware Develo-
Bittanti, ed.), Springer-Verlag, 1989, pp. 141-209. pers, ASQC Quality Press, Milwaukee, WI, 1994.
[MAN961 Manns, T. y M. Coleman, Sofhvare Quality Assu- [SCH97] Schoonmaker, S.J., IS0 9000 for Engineers and
rance, MacMillan Press, 1996. Designers, McGraw Hill, 1997.
[MUS87] Musa, J. D., A. Iannino y K. Okumoto, Enginee-
[SHI86] Shigeo Shingo, Zero Quality Control: Source Ins-
ring and Managing Sofiware with Reliability Measures,
pection and the Poka-Yoke System, Productivity Press,
McGraw-Hill, 1987.
1986.
[PAU93] Paulk, M., et al., Capability Maturiry Model for
Software, Software Engineering Institute, Carnegie Mellon [SOM96] Somerville, I., Software Engineering, 5.%d., Addi-
University, Pittsburgh, PA, 1993. son-Wesley, 1996.
[POR95] Porter, A., H. Siv, C. A. Toman, y L. G. Votta, aAn [TIN961 Tingey, M., Comparing IS0 9000, Malcolm Bal-
Experiment to Assess the Cost-Benefits of Code Inspec- dridge y a1 SEI CMM para Software, Prentice-Hall, 1996.
tions in Large Scale Software Development>>,Proc. Third [TRI97] Tricker, R., IS0 9000 for Small Bussinesses, But-
ACM SIGSOFT Symposium on the Foundations of Soft- terworth-Heinemann, 1997.
ware Engineering, Washington DC, Octubre 1996, ACM
Press, pp. 92-103. [VES81] Veseley, W.E., et al., Fault Tree Handbook, U S
Nuclear Regulatory Commision, NUREG-0492, Enero
[ROB971 Robinson, H., <<UsingPoka-Yoke Techniques for 1981.
Early Error Detection>>,Proc. Sixth International Confe-
rence on Sofhvare Testing Analysis and Review (STAR'97), [WI494] Wilson, L. A., 8 stp to Succesful IS0 9000, Cam-
1997, pp. 119-142. bridge Interactive Publications, 1996.
8.1. A1 principio del capitulo se seiial6 que <<el

control de varia- 8.10. Algunas personas piensan que una RTF debe evaluar el
ci6n est5 en el centro del control de calidadn. Como todos 10s estilo de programaci6n a1 igual que la correction. jEs una bue-
programas que se crean son diferentes unos de otros, jcuiles na idea? jPor quC?
son las variaciones que se buscan y c6mo se controlan? 8.11. Revise la Tabla 8.1 y seleccione las cuatro causas vita-
8.2. ~ E posible
s evaluar la calidad del software si el clien- les de errores serios y moderados. Sugiera acciones correc-
te no se pone de acuerdo sobre lo que se supone que ha de toras basandose en la information presentada en otros
hacer? capitulos.
8.3. La calidad y la fiabilidad son conceptos relacionados, 8.12. Una organizaci6n utiliza un proceso de ingenieria del
per0 son fundamentalmente diferentes en varias formas. Dis- software de cinco pasos en el cual 10s errores se encuentran
cutalas. de acuerdo a la siguiente distribuci6n de porcentajes:
8.4. jPuede un programa ser correcto y aun asi no ser fiable?
Explique por quC. Paso Porcentaje de errores encontrados
8.5. jPuede un programa ser correcto y aun asi no exhibir una 1 20 %
buena calidad? Explique por quC. 2 15 %
8.6. jPor quC a menudo existen fricciones entre un grupo de 3 15 %
ingenieria del software y un grupo independiente de garantia
de calidad del software? ~ E esto
s provechoso? 4 40 %
8.7. Si se le da la responsabilidad de mejorar la calidad del 5 10 %
software en su organizaci6n. jQuC es lo primer0 que haria?
jQuC seria lo siguiente? Mediante la informaci6n de la Tabla 8.1 y la distribucidn de
porcentajes anterior, calcule el indice de defectos global para
8.8. Ademas de 10s errores, jhay otras caracteristicas claras
dicha organizaci6n. Suponga que PS = 100.000.
del software que impliquen calidad? jCu5les son y c6mo se
pueden medir directamente? 8.13. Investigue en 10s libros sobre fiabilidad del software y
escriba un articulo que explique un modelo de fiabilidad del
8.9. Una revisi6n tCcnica formal s610 es efectiva si todo el
software. Aseglirese de incluir un ejemplo.
mundo se la prepara por adelantado. jC6mo descubriria que
uno de 10s participantes no se la ha preparado? jQuC haria si 8.14. El concept0 de TMEF del software sigue abierto a deba-
fuera el jefe de revisi6n? te. jPuede pensar en algunas razones para ello?
INGENIERfA DEL SOFTWARE. U N E N F O Q U E P R h C T l C O
, 8.15. Considere dos sistemas de seguridad critica que estCn 8.17. Sugiera unos cuantos dispositivos poka-yoke que pue-
. controlados por una computadora. Liste a1 menos tres peligros dan ser usados para detectar y/o prevenir errores que son
para cada uno de ellos que se puedan relacionar directamen- encontrados habitualmente antes de ccenviam un mensaje
te con 10s fallos del software. por e-mail.
8.16. Utilizando recursos web y de impresidn, desarrolle un 8.18. Adquiera una copia de I S 0 9001 e I S 0 9000-3. Prepa-
tutorial de 20 minutos sobrepoka-yoke y exp6ngaselo a su cla- re una presentacidn que trate tres requisitos I S 0 9001 y cdmo
se. se aplican en el context0 del software.
Los libros de Moriguchi (Software Excellence: A Total Qua- Sanders, J., Software Quality: A Framework for Success
lity Management Guide, Productivity Press, 1997), Horch in Software Development, Addison-Wesley, 1994.
(Practical Guide to Software Quality Management, Artech Sumner, F. H. Software Quality Assurance, MacMillan,
Publishing, 1996) son unas excelentes presentaciones a nivel 1993.
de gestion sobre 10s beneficios de 10s programas formales de Wallmuller, E., Software Quality Assurance: A Practical
garantia de calidad para el software de computadora. Los Approach, Prentice-Hall, 1995.
libros de Deming IDEM861 y Crosby [CR079], aunque no
se centran en el software, ambos libros son de lectura obli- Weinberg, G. M., Quality Software Management, 4 vols.,
gada para 10s gestores senior con responsabilidades en el desa- Dorset House, 1992, 1993, 1994 y 1996.
rrollo de software. Gluckrnan y Roome (Every day Heroes of Wilson, R. C., Software Rx: Secrets of Engineering Qua-
the Quality Movement, Dorset House, 1993) humaniza 10s lity Software, Prentice-Hall, 1997.
aspectos de calidad contando la historia de 10s participantes Una antologia editada por Wheeler, Bryczynsky y Mee-
en el proceso de calidad. Kan (Metrics and Models in Soft- son (Software Inspection: lndustry Best Practice, IEEE Com-
ware Quality Engineering, Addison-Wesley, 1995) presenta puter Society press, 1996) presenta informacidn util sobre
una visidn cuantitativa de la calidad del software. Manns (Soft- esta importante actividad de GCS. Friedman y Voas (Software
MqareQuality Assurance, Macmillan, 1996) es una excelente Assessment, Wiley, 1995) estudian 10s soportes y mCtodos
introduccidn a la garantia de calidad del software. pricticos para asegurar la fiabilidad y la seguridad de pro-
Tingley (Compering I S 0 9000, Malcom Baldridge, and gramas de computadora.
the SEI CMM for Software, Prentice-Hall, 1996) proporciona Musa (Software Reliability Engineering: More Reliable
una guia util para las organizacionesque se esfuerzan en mejo- Software, Faster Development and Testing, McGraw-Hill,
rar sus procesos de gestion de calidad. Oskarsson (An I S 0 1998) ha escrito una guia practica para aplicar a las tCcnicas
9000 Approach to Building Quality Software, Prentice-Hall, de fiabilidad del software. Han sido editadas antologias de
1995) estudia cdmo se aplica el estandar I S 0 a1 software. articulos importantes sobre la fiabilidad del software por Kapur
Durante 10s ultimos aiios se han escrito docenas de libros y otros (Contributions to Hardware and Software Reability
sobre aspectos de garantia de calidad. La lista siguiente es Modelling, World Scientific Publishing Co., 1999), Gritzails
una pequeiia muestra de fuentes dtiles: (Reliability, Quality and Safety of Software-Intensive Systems,
Clapp, J. A., et al., Software Quality Control, ErrorAnaly- Kluwer Academic Publishing, 1997), y Lyu (Handbook of
sis and Testing, Noyes Data Corp.. Park Ridge, NJ,1995. Software Reliability Engineering, McGraw-Hill, 1996). Sto-
Dunn, R. H., y R.S. Ullman, TQM for Computer Softwa- rey (Safety-Critical Computer Systems, Addison-Wesley,
re, McGrawHill, 1994. 1996) y Leveson [LEV951continuan siendo 10s estudios mas
Fenton, N., R. Whitty y Y. Iizuka, Software QualityAssu- completos sobre la seguridad del software publicados hasta
ranee and Measurement: Worldwide Industrial Applications, la fecha.
Chapman & Hall, 1994. Adem& de [SHI86], la tCcnica poka-yoke para el software
Ferdinand, A. E., Systems, Software, and Quality Enginee- de prueba de errores es estudiada Shingo (The Shingo Pro-
ring, Van Nostrand Reinhold, 1993. duction Management System: Improving Product Quality by
Preventing Defects, Productivity Press, 1989) y por Shimbun
Ginac, F. P., Customer Oriented Software Quality Assu-
(Poka-Yoke:Improving Product Quality by Preventing Defects,
rance, Prentice-Hall, 1998.
Productivity Press, 1989).
Ince, D., I S 0 9001 and Software Quality Assurance, En Internet e s t h disponibles una gran variedad de fuen-
McGraw-Hill, 1994. tes de informacidn sobre la garantia de calidad del software,
Ince, D., An Introduction to Software Quality Assurance fiabilidad del software y otros temas relacionados. Se puede
and Implementation, McGraw-Hill, 1994. encontrar una lista actualizada con referencias a sitios (pagi-
Jarvis, A., y V. Crandall, Inroads to Soft~vareQuality: nas) web que son relevantes para la calidad del software en
CHOWTONGuide and Toolkit, Prentice-Hall, 1997.
~ NLA
O E S T ~ DE
DEL SOFTWARE
Palabras c l a v e
C
UANDO se construye software de computadora, 10s cambios son inevitables. Ademzis,
auditoria 10s cambios aumentan el grado de confusi6n entre 10s ingenieros del software que estAn
de la cdguracih ..I58 trabajando en el proyecto. La confusi6n surge cuando no se han analizado 10s cambios
control antes de realizarlos, no se han registrado antes de implementarlos, no se les han comunicado a
de rlncronizw6n....I58 aquellas personas que necesitan saberlo o no se han controlado de manera que mejoren la cali-
control deversii. .. 155 dad y reduzcan 10s errores. Babich [BAB86] se refiere a este asunto cuando dice:
control del accm. ..I58 El arte de coordinar el desmollo de software para minimizar...la confusi6n, se denomina gesti6n de con-
control del cambio. ..I58 figuraci6n. La gesti6n de contiguraci6n es el arte de identificar, organizar y controlar las modificaciones que
sufre el software que construye un equipo de programacibn. La meta es rnaximizar la productividad rnini-
ECSs .............,152 rnizando 10s errores.
identificadh .......I54
informe de estado.. .I59 La gestion de configuraci6n del software (GCS) es una actividad de autoproteccih que se
aplica durante el proceso del software. Como el carnbio se puede producir en cualquier momen-
fineas base.. .......I52
to, las actividades de GCS sirven para (1) identificar el carnbio, (2) controlar el carnbio, (3)
obletos garantizar que el carnbio se implementa adecuadamente y (4) informar del carnbio a todos aque-
de configuraciC ....I53
110s que puedan estar interesados.
p r o c c ~GCS. .......I54 Es importante distinguir claramente entre el mantenimiento del software y la gestion de con-
figuration del software. El mantenimiento es un conjunto de actividades de ingenieria del soft-
ware que se producen despuCs de que el software se haya entregado a1 cliente y este en
funcionamiento. La gesti6n de configuraci6n del software es un conjunto de actividades de
seguimiento y control que comienzan cuando se inicia el proyecto de ingenieria del software y
termina s61o cuando el software queda fuera de la circulaci6n.
--
&Qu&c+?Cucmdo construimcw software de & P Opub

~ es importante? Si no con- que necesitan conocer 1oa cambios son
computadora, surgen cambios. Debido trolamos el cambio. 61 nos controlard a informados, se redlizan 10s informes.
a esto. necesitamos controlarlos eficaz- nosotros. Y esto nunca e s bueno. Es ~ C u aes
l e l producto obtenido? El
mente. La gesti6n d e la configuration muy fdcil para un flujo d e cambios Plan de Gestidn de la Configu~acion
del software (GCS) e s un conjunto d e incontrolados llevar a l caos a un pro- del Software define la estrategia del
actividadesdiseiiadas puracontrolar el yecto d e software correcto. Por esta proyecto para la GCS. Ademas, cuan-
cambio identificando b a productos del razdn, la GCS e s una parteesencial de do se realiza la GCS formal, el proce-
tmbajo que probablemente cambien, una buena gestidn del proyecto y una so d e control del carnbio ptovoca
estableciendo relaciones entre ellos. prbctica formal de la ingenieria del peticiones d e carnbio del software e
definiendo mecanismos porn gestionar soitware. informes d e 6rdenes d e cambios d e
distintas versiones de estos productos. ;Cu&les son lor pasos? Puesto que ingenieria.
controlando 10scambios realizados, y muchos productos de trabajo s e obtie- iC6m0 puedo d a r seguro de qae lo
auditando e informando de 10scambios he hecho correcfarnente? Cuando
nen cuando s e constmye el software,
realizados. cada uno debe estar identificado unl- cualquier producto d e trabajo puede
& Q u i hlo hace? Todos aquellos que vocamente. Una vez que esto se ha ser estimado para ser supervisado y
e s t h involucrados en el proceso d e logrado, s e pueden establecer 10s controlado: cuando cualquier carnbio
ingenieria d e software est&n relacio- mecanismos para el control del cam- pueda ser seguido y analizado; cuan-
nados con la GCS hasta cierto punto, bio y de las versiones, Para garantizar do cualquiera que necesite saber algo
p r o las posiciones de mantenimiento que s e mantiene la calidad mientras sobre algrin carnbio ha sido informa-
especializadas son creadas a veces s e realizan 10s cambios, s e audita el do, lo habremos realizado correcta-
para la gesti6n del proceso d e GCS. proceso, y para asegurar que aquellos mente.
Configuration Management
151
El resultado del proceso de ingenieria del software es

una informaci6n que se puede dividir en tres amplias
categorias: (1) programas de computadora (tanto en for- La mayoria de 10s combios son jus/ikados. No lamente
ma de c6digo fuente como ejecutable), (2) documentos 10s cambios. Mejor dicho, e s l seguro que tiene
que describen 10s programas de computadora (tanto tCc- 10s mecanismospreporodospora realizarlos.
nicos como de usuario) y (3) datos (contenidos en el pro-
grama o extemos a 61). Los elementos que componen
toda la informaci6n producida como p a t e del proceso 9.1.1. Lineas base
de ingenieria del software se denominan colectivamen- Una linea base es un concept0 de gesti6n de configura-
te configuraci6n del software. ci6n del software que nos ayuda a controlar 10s cam-
A medida que progresa el proceso del software, el bios sin impedir seriamente 10s cambios justificados. La
numero de elementos de configuracibn del software IEEE (Estandar IEEE 610.12-1990) define una linea
(ECSs) crece rapidamente. Una especificaci6n del sis- base corno:
tema produce un plan del proyecto del software y una Una especificaci6n o producto que se ha revisado formal-
especificacidn de requisitos del software (asi como mente y sobre 10s que se ha llegado a un acuerdo, y que de ahi
otros documentos relativos a1 hardware). A su vez, en adelante s h e como base para un desarrollo posterior y que
Cstos producen otros documentos para crear una jerar- puede cambiarse solamente a travCs de procedimientos for-
quia de informaci6n. Si simplemente cada ECS pro- males de control de cambios.
dujera otros ECSs, no habria practicamente confusi6n. Una forma de describir la linea base es mediante una
Desgraciadamente, en el proceso entra en juego otra analogia:
variable --el cambio-. El cambio se puede producir Considere las puertas de la cocina en un gran restaurante.
en cualquier momento y por cualquier raz6n. De hecho, Para evitar colisiones, una puerta esti marcada como SALIDA
la Primera Ley de la Ingenieria de Sistemas [BER80] y la Oha como ENTRADA. Las puertas tienen topes que hacen
establece: Sin importar en quC momento del ciclo de que solo se puedan abrir en la direction apropiada.
vida del sistema nos encontremos, el sistema cambia- Si un camarero recoge un pedido en la cocina, lo coloca en
r i y el deseo de cambiarlo persistira a lo largo de todo una bandeja luego se da cuenta de que ha cogido un plato equi-
el ciclo de vida. vocado, puede cambiar el plato correcto rgpida e informalrnente
antes de salir de la cocina.
Sin embargo, si abandona la cocina, le da el plato a1
cliente y luego se le informa de su error, debe seguir el
siguiente procedimiento: (1) mirar en la orden de pedido si
ha habido algdn error; (2) disculparse insistentemente; (3)
volver a la cocina por la puerta de ENTRADA; (4) expli-
iCual es el origen de estos cambios? La respuesta a car el problema, etc.
esta pregunta es tan variada como 10s cambios mismos.
Sin embargo, hay cuatro fuentes fundamentales de cam-
bios:
@&CLAVE
nuevos negocios o condiciones comerciales que dic- Un producto de traboio de la ingenieria
tan 10s cambios en 10s requisitos del producto o en del software se convierte en una lineo base,
las normas comerciales; solomente despues de haber sido revisodo y aprobado.
nuevas necesidades del cliente que demandan la Una linea base es analoga a la cocina de un restau-
modificaci6n de 10s datos producidos por sistemas rante. Antes de que un elemento de configuraci6n de
de informaci6n, funcionalidades entregadas por pro- software se convierta en una linea base, el cambio se
ductos o semicios entregados por un sistema basado puede llevar a cab0 rapida e informalmente. Sin embar-
en computadora; go, una vez que se establece una linea base, pasamos,
reorganizacidn o crecimiento/reducci6n del negocio de forma figurada, por una puerta de un solo sentido.
que provoca cambios en las prioridades del proyecto Se pueden llevar a cab0 10s cambios, per0 se debe apli-
o en la estmctura del equipo de ingenieria del software; car un procedimiento formal para evaluar y verificar
cada cambio.
restricciones presupuestarias o de planificaci6n que En el context0 de la ingenieria del software, defini-
provocan una redefinition del sistema o producto. mos una linea base como un punto de referencia en el
La gesti6n de configuraci6n del software (GCS) es un desarrollo del software que queda marcado por el envio
conjunto de actividades desarrolladas para gestionar 10s de uno o mas elementos de configuraci6n del software
cambios a lo largo del ciclo de vida del software de com- y la aprobaci6n del ECS obtenido mediante una revi-
putadora. si6n tCcnica formal (Capitulo 8). Por ejemplo, 10s ele-
9 GESTI6N DE LA C O N F I G U R A C I ~DEL
CAP~TULO N SOFTWARE
mentos de una Especifrcacibn de Diseiio se documen- so de ingenieria del software. Llevado a1 extreme, se pue-
- tan y se revisan. Se encuentran errores y se corrigen. de considerar un ECS como una secci6n individual de
Cuando todas las partes de la especificaci6n se han revi- una gran especificaci6n o cada caso de prueba de un gran
sado, corregido y aprobado, la EspecijicucYbrz de Dise- conjunto de pruebas. De forma mhs realista, un ECS es
fio se convierte en una linea base. Solo se pueden realizar un documento, un conjunto completo de casos de prue-
cambios futuros en la arquitectura del software (docu- ba o un componente de un prograrna dado (p. ej., una fun-
mentado en la Especijkuc-idnde Disefio)trns haber sido ci6n de C++ o un paquete de ADA).
evaluados y aprobados. Aunque se pueden definir las En realidad, 10s ECSs se organizan como ol,jc.tos de
lineas base con cualquier nivel de detalle, las lineas base configumcibn que han de ser catalogados en la base de
rnlis comunes son las que se muestran en la Figura 9.1. datos del proyecto con un nombre dnico. Un objeto de
configuraci6n tiene un nombre y unos atributos y estri
ccconectado~a otros objetos mediante relaciones. De acuer-
do con la Figura 9.2,los objelos de configuraci6n, Espe-
Aseglirese que lo bose de dotos del proyecto se montiene
cificacion de Diseno, modelo de datos, componente N,
sobre un entorno controlado, centrolizodo.
codigo fuente y Especificacion de Prueba, esthn detini-
La progresi6n de acontecimientos que conducen a un dos por separado. Sin embargo, cada objeto estli relacio-
linea base esth tambiin ilustrada en la Figura 9.1. Las nado con otros como muestran las flechas. Una flecha
lareas de la ingenieria del software producen uno o mris curvada representa una relacibn de composicih. Es decir,
ECSs. Una vez que un ECS se ha revisado y aprobado, modelo de datos y componente N son parte del objeto
se coloca en una hase ck dotes del pr-oycro (tambiCn Especificaci6n de DiseAo. Una flecha recta con dos pun-
denonlinada bibliorecn d d pi-oyecro o depbsiro dc sojl- tas representa una interrelaci6n. Si se lleva a crtbo un cam-
ware).Cuando un miembro del equipo de ingenieria del bio sobre el objeto c6digo fuente, las interrelaciones
software quiere hacer moditicaciones en un ECS de linea permiten a1 ingeniero de software determinar quC otros
base, se copia de la base de datos del proyecto a un Area objetos (y ECSs) pueden verse afectados'.
de trabajo privada del ingeniero. Sin embargo, este ECS
extraido puede modificarse s61o si se siguen 10s contro-
les GCS (tratados mris adelante en este capitulo). Las
flechas punteadas de la Figura 9.1 muestran el camino
de modificaci6n de una linea base ECS.
modificada
9i4 Elemenlos de conhguration del software.
* 2
/
Base de datos del proyecto
v aprobada 1I
Tareas
d e ingenieria
del software - A
.
Revisiones
tknicas
formales
w r""
-I /
extraida \
controles
GCS >*
1
L~NEASBASE:
Especificacion del sistema Description de la intetfaz
Requisitos del software Descripcidn del algoritmo
Especificaciones de disetio PDL
Codigo fuente
Planes1Procedimientosl
Datos de prueba
Sistema de funcionamiento
FIGURA 9.1. ECS de linea base y base de datos del proyecto.
9.1.2. Elementos de configuraci6n del software

Ya hemos definido un elemento de configuraci6n del soft- 1
ware como la informaci6n creada como parte del proce- FIGURA 9.2. Objetos de configuracion.
Estas relaciones se tratan en la Secci6n 9.2.1 y la estructura de la

base de datos del proyecto se trata con detalle en el Capitulo 31.
La gesti6n de configuraci6n del software es un elemento iC6m0 identifica y gestiona una organizaci6n las
importante de garantia de calidad del software. Su res- diferentes versiones existentes de un programa (y su
ponsabilidad principal es el control de cambios. Sin documentacibn) de forma que se puedan introducir
embargo, la GCS tambiCn es responsable de la identi- cambios eficientemente?
ficaci6n de ECSs individuales y de las distintas versio-
nes del software, de las auditorias de la configuraci6n iC6m0 controla la organizaci6n 10s cambios antes
del software para asegurar que se desarrollan-adecua- y despuCs de que el software sea distribuido a1
damente y de la generaci6n de informes sobre todos 10s cliente?
cambios realizados en la configuraci6n. LQuiCn tiene la responsabilidad de aprobar y de asig-
nar prioridades a 10s cambios?
iC6m0 podemos garantizar que 10s cambios se han
llevado a cab0 adecuadamente?
10s paginos omorillos de gestion de configurocibn
contienen el listodo mas complejo de los recursos de GCS ~ Q u Cmecanismo se usa para avisar a otros de 10s
en lo web. Poro mbs informocibn, consultor: cambios realizados?
www.ts.tolorado.edu/users/andre/
configuration-management.html
Estas cuestiones nos llevan a la definici6n de cinco
tareas de GCS: ldentijicacibn, control de versiones, con-
Cualquier estudio de la GCS plantea una serie de pre- trol de cambios, auditorias de configuracibn y genera-
guntas complejas: cibn de informes.
Para controlar y gestionar 10s elementos de configura-

cibn, se debe identificar cada uno de forma unica y lue-
go organizarlos mediante un enfoque orientado a objetos.
Se pueden identificar dos tipos de objetos [CH089]: obje- 10s relociones estoblecidos entre 10s obietos de
tos bhsicos y objetos compuestos2.Un objeto basic0 es configurocibn permiten al ingeniero del software
una ccunidad de texto>>creado por un ingeniero de soft- evoluor el impocto del combio.
ware durante el anhlisis, diseiio, codificaci6n o pruebas.
Por ejemplo, un objeto basic0 podria ser una secci6n de Los recursos son ccentidades que proporciona, proce-
una especificaci6n de requisitos, un listado fuente de un sa, referencia o son, de alguna otra forma, requeridas por
m6dulo o un conjunto de casos prueba que se usan para el objetou. [CH089], por ejemplo, 10s tipos de datos, las
ejercitar el codigo. Un objeto compuesto es una colec- funciones especificas e incluso 10s nombres de las varia-
ci6n de objetos basicos y de otros objetos compuestos. bles pueden ser considerados recursos de objetos. La rea-
De acuerdo con la Figura 9.2, la Especificacion de Dise- lizaci6n es una referencia a la ccunidad de texto,, para un
iio es un objeto compuesto. Conceptualmente, se puede objeto basico y nulo para un objeto compuesto.
ver como una lista de referencias con nombre (identifi- La identificaci6n del objeto de configuraci6n tam-
cadas) que especifican objetos basicos, tales como mode- biCn debe considerar las relaciones existentes entre 10s
lo de datos y componente N. objetos identificados. Un objeto puede estar identifica-
Cada objeto tiene un conjunto de caractensticas dis- do como cparte-de> un objeto compuesto. La relacibn
tintas que le identifican de forma 6nica: un nombre, una cparte-de> define una jerarquia de objetos. Por ejem-
descripci6n, una lista de recursos y una ccrealizaci6nn. El plo, utilizando esta sencilla notacion
nombre del objeto es una cadena de caracteres que iden- Diagrama E-R 1.4 <pate-de> modelo de datos;
tifica a1 objeto sin ambigiiedad. La descripci6n del obje- Modelo de datos <parte-de> especificaci6n de disefio;
to es una lista de elementos de datos que identifican:
el tip0 de ECS (por ejemplo: documento, programa, creamos una jerarquia de ECSs.
datos) que esta representado por el objeto; No es realista asumir que la 6nica relacibn entre 10s
objetos de la jerarquia de objetos se establece median-
un identificador del proyecto; te largos carninos del kbol jerkquico. En muchos casos,
la informaci6n de la versi6n y/o el cambio; 10s objetos estan interrelacionados entre ramas de la
--
como rnecanisrnos para representar una version completa de la

configuracion del software se ha propuesto el concept0 de objeto
agregado [GUS891
puesta de diferentes variantes. Para ilustrar este concep- objetos del mismo nivel de revision. Una variante es
to, consideremos una version de un sencillo programa una colecci6n diferente de objetos del mismo nivel de
que esta formado por 10s componentes 1 , 2 , 3 , 4 y 53.El revision y, por tanto, coexiste en paralelo con otras
componente 4 solo se usa cuando el software se imple- variantes. Una nueva version se define cuando se reali-
menta para monitores de color. El componente 5 se imple- zan cambios significativos en uno o mas objetos.
menta cuando se dispone de monitor monocromo. Por En la pasada dCcada se propusieron diferentes enfo-
tanto, se pueden definir dos variantes de la version: ( I ) ques automatizados para el control de versiones. La prin-
componentes 1 , 2 , 3 y 4; (2) componentes 1 , 2 , 3 y 5. cipal diferencia entre 10s distintos enfoques esti en la
Para construir la wriante adecuada de una determina- sofisticacion de 10s atributos que se usan para construir
da version de un programa, a cada componente se le asig- versiones y variantes especificas de un sistema y en la
na una cctupla de atributow -una lista de caractensticas mecanica del proceso de construction.
que definen si se ha de utilizar el componente cuando se va
a construir una determinada version del software-. A cada variantes
A
variante se le asigna uno o mas atributos. Por ejemplo, se
podria usar un atributo color para definir quC componentes
se deben incluir para soporte de monitores en color.
mtidades
componentes)
Otra forma de establecer 10s conceptos de la relacion

entre componentes, variantes y versiones (revisiones)
es representarlas como un fondo de objetos [REI89]. De
acuerdo con la Figura 9.4, la relacion entre 10s objetos
de configuration y 10s componentes, las variantes y las FIGURA 9.4. Representacion en fondo de objetos
versiones se pueden representar como un espacio tridi- de 10s componentes, variantes y versiones
mensional. Un componente consta de una coleccion de [RE189].
La realidad del control de carnbio en un contexto moder-

no de ingenieria de software ha sido bien resumida por
James Bach [BAC98] :
El control de cambio es vital. Pero las fuerzas que lo hacen
necesario tambien lo hacen molesto. Nos preocupamos por el
cambio porque una diminuta perturbation en el c6digo puede
crear un gran fallo en el producto. Pero tambien puede reparar
un gran fallo o habiitar excelentes capacidades nuevas. Nos prw-
cupamos por el cambio porque un desarrollador picaro puede yectos, el control de cambios combina 10s procedimien-
hacer fracasar el proyecto; sin embargo las brillantes ideas naci- tos humanos y las herramientas automiticas para propor-
das en la mente de estos picaros, y un pesado proceso de con- cionar un mecanismo para el control del carnbio. El
trol de cambio pueden disuadirle de hacer un trabajo creativo.
proceso de control de cambios esta ilustrado esquemati-
Bach reconoce que nos enfrentamos a una situacion camente en la Figura 9.5. Se hace una peticibn de cam-
a equilibrar. Mucho control de carnbio y crearemos pro- bio4 y se evalda para calcular el esfuerzo tCcnico, 10s
blemas. Poco, y crearemos otros problemas. posibles efectos secundarios, el impact0 global sobre otras
En un gran proyecto de ingenieria de software, el cam- funciones del sistema y sobre otros objetos de la confi-
bio incontrolado lleva ripidamente a1 caos. Para estos pro- guracion. Los resultados de la evaluation se presentan
En este contexto, el terrnino ((cornponente. se refiere a todos 10s Aunque muchas de las peticiones de carnbio se reciben durante la
objetos compuestos y objetos basicos de un ESC de linea base. Por fase de mantenimiento, en este estudio tornamos un punto de vista
ejemplo, un componente de (lentrada))puede estar constituido por mas amplio. Una peticion de carnbio puede aparecer en cualquier
seis componentes de sottware distintos, cada uno responsable de rnomento durante el proceso del sottware.
una subfuncion de entrada.
C A P ~ T U L O9 G E S T I ~ NDE LA C O N F I G U R A C I ~ NDEL SOFTWARE
como un informe de cambios a la autoridad de control de y de auditoria. El objeto a cambiar es <<dadode baja>>de
cambios (ACC)-una persona o grupo que toma la deci- la base de datos del proyecto; se realiza el cambio y se apli-
si6n final del estado y la prioridad del c a m b i e . Para cada can las adecuadas actividades de SQA. Luego, el objeto
carnbio aprobado se genera una orden de carnbio de inge- es <<dado de altan en la base de datos y se usan 10s meca-
nieria (OCI).La OCI describe el cambio a realizar, las res- nismos de control de versiones apropiados (Secci6n 9.4)
tricciones que se deben respetar y 10s criterios de revisi6n para crear la siguiente versi6n del software.
Se reconoce la necesidad del carnbio

4
El usuario suscribe la peticion de carnbio
4
El desarrollador la evalua
i
Se genera un informe de cambios
i
La autoridad de control de cambios decide
La peticion queda pendiente de a c t u d n . >ticion de carnbio denegada
se genera la OCI .f
lnformaclon del usuario
4.
Asignacion personallzada a 10s objetos
de configuracion
4
"Dar de baja" objetos (elementos) de configuracion
4
Realizacion del carnbio
4 .
LOSelementos de configuracion qui
Revision de camblo (auditoria)
han cambiado son "dados de akau
Establecimiento de una linea base para la prueba
4
Realizacion de actividades de garantia de calidad y de prueba
4 .
"Promocion" de 10s cambios para ser incluldos en la siguiente version (revision)
i.
Reconstruccion de la verslon adecuada del software
4
Revision (auditoria) de 10s cambios en,todos 10s elementos de configuracion
+
Cambios incluidos en la nueva version
t
Distribucion de a nueva version
FIGURA 9.5. El proceso de control de carnbios.
Objeto de configuracion
(version de linea
Base de datos
\
Objeto de configuracion Bloqueo Objeto de configuracion
FIGURA 9.6. Control de acceso y de sincronizacion.

~ N G E N ~ E RDEL
~ A SOFTWARE. U N E N F O Q U E PRACTICO
Antes de que un ECS se convierta en una linea

base, s61o es necesario aplicar un control de cambios
informal. El que haya desarrollado el ECS en cues-
Lo confusion conduce o 10s errores --olgunos de ellos
ti6n podri hacer cualquier carnbio justificado por el
muy serios-. Los controles de occeso
y de sincronizocion eviton lo confusian. lmplemente
proyecto y por 10s requisitos tCcnicos (siempre que
ombos, incluso si su enfoque tiene que ser simplficodo 10s cambios no impacten en otros requisitos del sis-
poro odoptorlo o su culh~rode desorrollo. tema mis amplios que queden fuera del imbito de tra-
bajo del encargado del desarrollo). Una vez que el
Los procesos de ccaltau y ccbaja~implementan dos objeto ha pasado la revisidn tCcnica formal y ha sido
elementos importantes del control de cambios +on- aprobado, se crea la linea base. Una vez que el ECS
trol de acceso y control de sincronizacidn-. El control se convierte en una linea base, aparece el control de
de acceso gobierna 10s derechos de 10s ingenieros de cambios a nivel de proyecto. Ahora, para hacer un
software a acceder y modificar objetos de configuracidn carnbio, el encargado del desarrollo debe recibir la .
concretos. El control de sincronizaci6n asegura que 10s aprobacidn del gestor del proyecto (si el carnbio es
cambios en paralelo, realizados por personas diferen- <<local>>) o de la ACC si el carnbio impacta en otros
tes, no se sobreescriben mutuamente [HAR89]. ECSs. En algunos casos, se dispensa de generar for-
El flujo de control de acceso y de sincronizaci6n estin malmente las peticiones de carnbio, 10s informes de
esquemiticamente ilustrados en la Figura 9.6. De acuer- carnbio y las OCI. Sin embargo, hay que hacer una
do con una peticidn de carnbio aprobada y una OCI, un evaluaci6n de cada carnbio asi como un seguimiento
ingeniero de software da de baja a un objeto de configu- y revisi6n de 10s mismos.
racibn. Una funcidn de control de acceso comprueba que Cuando se distribuye el producto de software a 10s
el ingeniero tiene autoridad para dar de baja el objeto, y clientes, se instituye el control de cambios formal. El
el control de sincronizacidn bloquea el objeto en la base procedimiento de control de cambios formal es el que
de datos del proyecto, de forma que no se puedan hacer aparece definido en la Figura 9.5.
mis actualizaciones hasta que se haya reemplazado con La autoridad de control de cambios (ACC) desem-
la nueva versi6n. Fijese que se pueden dar de baja otras pefia un papel activo en el segundo y tercer nivel de
copias, per0 no se podrin hacer otras actualizaciones. El control. Dependiendo del tamafio y de las caracteris-
ingeniero de software modifica una copia del objeto de ticas del proyecto de software, la ACC puede estar
linea base, denominada versi6n extraida. Tras la SQA y compuesta por una persona -el gestor del proyec-
la prueba apropiada, se da de alta la version modificada to- o por varias personas (por ejemplo, represen-
del objeto y se desbloquea el nuevo objeto de linea base. tantes del software, del hardware, de la ingenieria de
Puede que algunos lectores empiecen a sentirse incd- las bases de datos, del soporte o del departamento
modos con el nivel de burocracia que implica el proceso comercial, etc.). El papel de la ACC es el de tener una
anterior. Esta sensacidn es normal. Sin la proteccidn ade- visidn general, o sea, evaluar el impact0 del carnbio
cuada, el control de cambios puede ralentizar el progre- fuera del ECS en cuestion. iC6m0 impactari el cam-
so y crear un papeleo innecesario. La mayoria de 10s bio en el hardware? iC6m0 impactari en el rendi-
desarrolladores de software que disponen de mecanis- miento? iCdmo alterarfi el carnbio la percepcidn del
mos de control de cambios (desgraciadamente la mayo- cliente sobre el producto? iC6m0 afectari el carnbio
ria no tienen ninguno) han creado varios niveles de control a la calidad y a la fiabilidad? La ACC se plantea estas
para evitar 10s problemas mencionados anteriormente. y otras muchas cuestiones.
Opte par un poco mos de control de combio

del que pensobo necesitor en on principio. Es probable
que mucho puedo ser lo contidod opropiodo.
La identificacidn, el control de versiones y el control de ha implementado correctamente? La respuesta es doble:

cambios ayudan a1 equipo de desarrollo de software a (I) revisiones tCcnicas formales y (2) auditorias de con-
mantener un orden que, de otro modo, llevaria a una figuracidn del software.
situaci6n ca6tica y sin salida. Sin embargo, incluso 10s Las revisiones tCcnicas formales (presentadas en deta-
mecanismos mfis correctos de control de cambios hacen lle en el Capitulo 8) se centran en la correccidn tCcnica
un seguimiento a1 carnbio s610 hasta que se ha genera- del elemento de configuracidn que ha sido modificado.
do la OCI. iC6m0 podemos asegurar que el carnbio se Los revisores evallian el ECS para determinar la con-
158
C A P ~ T U L O9 G E S T I 6 N DE LA C O N F I G U R A C I ~ NDEL SOFTWARE
sistencia con otros ECSs, las omisiones o 10s posibles iSe ha seguido el proceso del software y se han apli-
efectos secundarios. Se debe llevar a cab0 una revisi6n cad0 adecuadamente 10s estindares de ingenieria del
tkcnica formal para cualquier cambio que no sea trivial. software?
Una auditoria de configuracibn del software com- iSe han ccresaltadou 10s cambios en el ECS? iSe han
plementa la revision tCcnica formal a1 cornprobar carac- especificado la fecha del cambio y el autor? ~Reflejan
teristicas que generalmente no tiene en cuenta la 10s cambios 10s atributos del objeto de configuracibn?
revisi6n. La auditoria se plantea y responde las siguien-
tes preguntas: iSe han seguido procedimientos de GCS para sefia-
lar el cambio, registrarlo y divulgarlo?
L Cuales son las principales
preguntas que hacemos en iSe han actualizado adecuadamente todos 10s ECSs
una auditoria de configuraciin? relacionados?
En algunos casos, las preguntas de auditoria se inclu-
1. iSe ha hecho el cambio especificado en la OCI? iSe yen en la revisi6n tkcnica formal. Sin embargo, cuando
han incorporado modificaciones adicionales? la GCS es una actividad formal, la auditoria de la GCS
2. iSe ha llevado a cab0 una revisi6n tkcnica formal se lleva a cab0 independientemente por el grupo de
para evaluar la correcci6n tkcnica? garantia de calidad.
La generacibn de informes de estado de la conjigura-

cidn (a veces denominada contabilidad de estado) es
una tarea de GCS que responde a las siguientes pre- Desormlle una & u que se necesita conocern
guntas: (1) ~ Q u Cpas6? (2) iQuikn lo hizo? (3) iCuin- poro coda ECS y montt?~golooctmlizodo. Cuondo
do pasb? (4) ~ Q u Cmis se vio afectado? se realice un combio, oseg~heseque se informo
En la Figura 9.5 se ilustra el flujo de informaci6n o todos 10s que estan en la lista.
para la generaci6n de informes de estado de la confi-
guracidn (IEC). Cada vez que se asigna una nueva iden- La generaci6n de informes de estado de la configura-
tificaci6n a un ECS o una identificaci6n actualizada se ci6n desempeiia un papel vital en el Cxito del proyecto de
genera una entrada en el IEC. Cada vez que la ACC desarrollo de software. Cuando aparece involucrada mucha
aprueba un cambio (o sea, se expide una OCI), se gene- gente es muy ficil que se dC el sindrome de que <<lamano
ra una entrada en el IEC. Cada vez que se lleva a cab0 izquierda ignora lo que hace la mano derechau. Puede que
una auditoria de configuraci6n,los resultados aparecen dos programadores intenten modificar el mismo ECS con
como parte de una tarea de generaci6n de un IEC. La intenciones diferentes y conflictivas. Un equipo de inge-
salida del IEC se puede situar en una base de datos inte- nieria del software puede emplear meses de esfuerzo en
ractiva [TAY85] de forma que 10s encargados del desa- construir un software a partir de unas especificaciones de
rrollo o del mantenimiento del software puedan acceder hardware obsoletas. Puede que la persona que descubra
a la informaci6n de cambios por categorias clave. Ade- 10s efectos secundarios serios de un cambio propuesto no
mis, se genera un IEC regularmente con intenci6n de estC enterada de que el cambio se esti realizando. El IEC
mantener a 10s gestores y a 10s profesionales a1 tanto de ayuda a eliminar esos problemas, mejorando la comuni-
10s cambios importantes. caci6n entre todas las personas involucradas.
La gesti6n de configuraci6n del software es una activi- La configuraci6n del software esti compuesta por un
dad de protecci6n que se aplica a lo largo de todo el pro- conjunto de objetos interrelacionados, tambiCn deno-
ceso del software. La GCS identifica, controla, audita e minados elementos de configuracidn del software, que
informa de las modificaciones que invariablemente se se producen como resultado de alguna actividad de inge-
dan a1 desarrollar el software una vez que ha sido dis-. nieria del software. Ademis de 10s documentos, 10s pro-
tribuido a 10s clientes. Cualquier informaci6n produci- gramas y 10s datos, tambiCn se puede poner bajo control
da como parte de la ingenieria del software se convierte de configuraci6n el entomo de desarrollo utilizado para
en parte de una configuraci6n del software. La confi- crear el software.
guraci6n se organiza de tal forma que sea posible un Una vez que se ha desarrollado y revisado un obje-
control organizado de 10s cambios. to de configuraci6n, se convierte en una linea base. Los
INGENIERfA DEL SOFTWARE. UN ENFOQUE P R A C T I C O
cambios sobre un objeto de linea base conducen a la da que se realizan cambios en 10s objetos de la con-
creacion de una nueva version del objeto. La evolution figuration. El proceso de control de cambios comien-
de un programa se puede seguir examinando el histo- za con una petici6n de cambio, lleva a una decision
rial de las revisiones de todos 10s objetos de su confi- de proseguir o no con el cambio y culmina con una
guracion. Los objetos basicos y 10s compuestos forman actualizaci6n controlada del ECS que se ha de
un asociacion de objetos que refleja las variantes y las cambiar.
versiones creadas. El control de versiones es un con- La auditoria de configuraci6n es una actividad de
junto de procedimientos y herramientas que se usan para SQA que ayuda a asegurar que se mantiene la calidad
gestionar el uso de 10s objetos. durante la realization de 10s cambios. Los informes de
El control de cambios es una actividad procedi- estado proporcionan informaci61-1sobre cada cambio a
mental que asegura la calidad y la consistencia a medi- aquellos que tienen que estar informados.
[ADA891 Adams, E., M. Honda y T. Miller, <<ObjectMana- [IEE94] Software Engineering Standards, edici6n de 1994,
gement in a CASE Environment,,, Proc. 11 th Intl. Conf IEEE Computer Society, 1994.
Software Engineering, IEEE, Pittsburg, PA, Mayo 1989,
[LIE891 Lie, A. et al., ((Change Oriented Versioning in a Soft-
pp. 154-163. ware Engineeering Database,,, Proc. 2nd Intl. Workshop
[BAC98] Bach, J., <<TheHighs and Lows of Change Con- on Software Configuration Management, ACM, Prince-
trol,,, Computer, vol. 3 1, n.", Agosto 1998. pp. 113-115. ton, NJ, Octubre 1989, pp. 56-65
{BER80] Bersoff, E.H., V.D. Henderson y S. G. Siegel, Soft- [NAR87] Narayanaswamy, K., y W. Scacchi, <<Maintatning
ware Configuration Management, Prentice-Hall, 1980. Configurations of Evolving Software Systems>>,IEEE
[BRY80] Bryan, W., C. Chadboume, y S. Siegel, SoMare Con- Trans. Software Engineering, vol. SE-13, n." 3, Marzo
figuration Management. IEEE Computer Society Press, 1980. 1987, pp. 324-334.
[CH089] Choi, S. C.. y W. Scacchi, <<Assuringthe Correct- [RE1891 Reichenberger, C., <<OrthogonalVersion Manage-
ness of a Configured Software Description>>,Proc. 2nd ment>>,Proc. 2nd lntl. Workshop on Software Confrgura-
Intl. Workshop on Software Conftguration Management, tion Management, ACM, Princeton, NJ, Octubre 1989,
ACM, Princeton, NJ, Octubre 1989, pp. 66-75. pp. 137-140.
[CLE89] Clemm, G. M., <<ReplacingVersion Control with [ROC751 Rochkind, M., <<TheSource Code Control System,,,
Job Control>>,
Proc. 2nd lntl. Workshop on Software Con- IEEE Trans.Sofi7at-eEngineering, vol. SE-I, n." 4, Diciem-
figuration Management, ACM, Princeton, NJ, Octubre bre 1975, pp. 364-370.
1989, pp. 162-169. [TAY85] Taylor, B., <<ADatabase Approach to Configuration
[GUS891 Gustavsson, A., <<Maintainingthe Evaluation of Management for Large Projects,,, Proc. Conf. Software
Software Objects in an Integrated Environment)), Proc. Maintenance-1985, IEEE, Noviembre 1985, pp. 15-23.
2nd Intl. Workshop on Software Configuration Manage- [TIC821 Tichy, W. F., <<Design,Implementation and Evalua-
ment, ACM, Princeton, NJ, Octubre 1989, pp. 1 14-117. tion of a Revision Control System,,, Proc. 6IhIntl. Conf.
[HAR89] Harter, R., <<ConfigurationManagement,,, HP Pro- Sofijare Engineering, IEEE, Tokyo, Septiembre 1982, pp.
fessional, vol. 3, n.", Junio 1989. 58-67.
9.1. iPor quC es cierta la primera ley de la ingenieria de sis- mo programa? iSe manejaria de forma diferente el c6digo
temas? iC6m0 afecta a nuestra percepci6n de 10s paradigmas fuente que la documentaci6n? iC6m0 se evitaria que dos pro-
de la ingenieria del software? gramadores hicieran cambios diferentes sobre el mismo ECS
a1 mismo tiempo?
9.2. Exponga las razones de la existencia de lineas base con
sus propias
- - -palabras. 9.5. Investigue un poco sobre bases de datos orientadas a
objetos y escriba unarticulo que describa c6mo se podrian
9.3. Asuma que es el gestor de un pequeiio proyecto. ~ Q u C
usar en el context0 de la GCS.
lineas base definiria para el proyecto y cdmo las controlaria?
- ~
9.6. Utilice un modelo E-R (Capitulo 12) para describir las

9.4. Diseiie un sistema de base de datos que permita a un
interrelaciones entre 10s ECS (objetos) de la Secci6n 9.1.2.
ingeniero del software guardar, obtener referencias de forma
cruzada, buscar, actualizar, cambiar, etc., todos 10s elemen- 9.7. Investigue sobre herramientas de GCS existentes y des-
tos de la configuraci6n del software importantes. iC6m0 criba c6mo implementan el control de versiones, de cambios
manejaria la base de datos de diferentes versiones de un mis- y de objetos de configuraci6n en general.
C A P ~ T U L O9 DE LA C O N F I G U R A C I ~DEL.
GESTI~N N SOFTWARE
9.8. Las relaciones ccparte-de>>e ccinterrelacionadon repre- 9.1O.Utilizando la Figura 9.5 como guia, desarrolle un
sentan relaciones sencillas entre 10s objetos de configuracion. esquema de trabajo miis detallado a6n para el control de cam-
Describa cinco relaciones adicionales que pudieran ser utiles bios. Describa el papel de la ACC y sugiera formatos para la
en el context0 de la base de datos del proyecto. peticidn de cambio, el informe de cambios e IEC.
9.9. Investigue sobre una herramienta de GCS existente y 9.11. Desarrolle una lista de comprobaciones que se pueda
describa c6mo implementa 10s mecanismos de control de ver- utilizar en las auditorias de configuracion.
siones. Alternativamente, lea dos o tres de 10s articulos a 10s
que se hace referencia en este capitulo e investigue en las 9.1 2.iCuiil es la diferencia entre una auditoria de GCS y una
estructuras de datos y 10s mecanismos que se usan para el con- revision tkcnica formal? iSe pueden juntar sus funciones en
trol de versiones. una sola revision? iCuiiles son 10s pros y 10s contras?
Uno de 10s pocos libros escritos sobre la GCS en 10s ultimo~ de las principales actividades de GC). Rawlings (SCM for
aiios lo realizaron Brown et al. (AntiPatterns and Patterns in Network Development Environments, McGraw-Hill, 1994)
Software Configuration Management. Wiley, 1989). es el primer libro de GCS en tratar el asunto con un Cnfasis
Los autores tratan las cosas que no hay que hacer (anti- especifico en el desarrollo de software en un entorno de red.
patrones) cuando se implementa un proceso de GCS y enton- Whitgift (Methods and Tools for Software Configuration
ces consideran sus remedios. Management, Wiley, 1991) contiene una razonable cobertu-
Lyon(Practica1 CM: Best Configuration Management ra de todos 10s temas importantes de GCS, pero se distingue
Practices for the 21StCentury, Raven Publishing, 1999) y por su estudio del diccionario de datos y tratamiento de aspec-
Mikkelsen y Pherigo (Practical Soft~,areConfiguration tos de entomos CASE. Arnold y Bohner (Software Change
Management: The Latenight Developer's Handbook, Allyn & Impact Analysis, IEEE Computer Society Press, 1996) han
Bacon, 1997) proporcionan tutoriales practicos importantes editado una antologia que estudia como analizar el impact0
de GCS. Ben-Menachem (Software Configuration Manage- del cambio dentro de sistemas complejos basados en soft-
ment Guidebook, McGraw-Hill, 1994), Vacca (Implementing ware.
a Successful. Configuration. Change. Management. Program, Puesto que la GCS identifica y controla documentos de
I S . Management Group, 1993), y Ayer y Patrinnostro (Soft- ingenieria del software, 10s libros de Nagle (Handbook for
ware Configuration Management, McGrawHill, 1992) pre- Preparing Engineering Documents: From Concept to Com-
sentan correctas visiones para aquellos que todavia no se han pletion, IEEE, 1996), Watts (Engineering Documentation
introducido en la materia. Berlack (Software Configuration Control Handbook: Configuration Management for Industry,
Management, Wiley, 1992, presenta una estudio iitil de con- Noyes Publication, 1993). Ayer y Patrinnostro (Documenting
ceptos de la GCS, haciendo incapik en la importancia del dic- the Softcl!are Process, McGraw-Hill, 1992) proporciona un
cionario de datos (repository) y de las herramientas en la complemento con textos mas centrados en la GCS. La edi-
gestion del cambio. Babich [BAB86] es un tratado abrevia- ci6n de Marzo de 1999 de Crosstalk contiene varios articu-
do, aunque eficaz, de temas practicos sobre la gesti6n de con- 10s utiles de la GCS.
figuration del software. En Internet estiin disponibles una gran variedad de fuen-
Buckley (Implementing Configuration Management, IEEE tes de information relacionadas con temas de gesti6n y de
Computer Society Press, 1993) estudia enfoques de gestion software. Se puede encontrar una lista actualizada con refe-
de configuracionpara todos 10s elementos de un sistema (hard- rencias a sitios (pkginas) web que son relevantes para el Soft-
ware, software y firmware con unos detallados tratamientos ware en http://www.pressman5.com.
PARTE
MSTODOS CONVENCIONALES
DEL SOFTWARE
E
N esta parte de Ingenieria del Soylware: Un Enfoque Practico considera-
mos 10sconceptos tecnicos, metodos y mediciones que son aplicables
a! analisis, disefio y pruebas del software. En 10s capitulos siguientes,
aprenderas las respuestas a las siguientes cuestiones:
;Cbmo se define el software dentro del context0 de un gran sistema y quk

papel juega la ingenieria de sistemas?
;Cuhles son 10s principios y conceptos basicos que se aplican al analisis
de requisitos del software?
L Q Ues~ el analisis estructurado y como sus diferentes modelos te permi-
ten entender las funciones, datos y cornportamientos?
;Cuales son Ios conceptos basicos y los principios que se aplican en la acti-
vidad de disefia del software?
~ C o m se
o realiza el disefio de los modelos de datos, arquitectura, interfa-
ces y componentes?
~Cu5lesson 10sconceptos basicos, principios y estrategias que se aplican
a las pruebas del software?
iC6m0 se utilizan 10s metodos d e prueba de caja negra y caja blanca para
diseiiar eficientes casos de prueba?
;Qu& mktricas tkcnicas estan disponibles para valorar la calidad de 10s
modelos de andisis y diseiio, codigo fuente y casos de prueba?
Una vez que estas cuestiones Sean contestadas, comprenderas c6mo cons:
truir software utilizando un enfoque disciplinado de ingenieria.
H
Palabrae c l o v e ACE casi 500 afios, Maquiavelo dijo: a... no hay nada m l s dificil de llevar a cabo, mis
urquitectura peligroso de realizar o de 6xito mls incierto que tomar el liderazgo en la introduccibn
de aplicacion ....... -770 de un nuevo orden de cosaw. Durante 10s liltimos 50 afios, 10s sistemas basados en com-
urquitectura da dalor 169 putadora han introducido un nuevo orden. Aunque la tecnologia ha conseguido grandes avan-
elemento~ ces desde que hablo Maquiavelo, sus palabras siguen sonando a verdad.
del sislema .........l66 La ingenieria del software aparece como consecuencia de un proceso denominado i n p n i e -
identificacih ria de sistemas. En lugar de centrarse linicamente en el software, la ingenieria de sislemas se
de requisitor ........I72 centra en diversos elementos, analizando, disefiando y organizando esos ele~nentosen un sis-
ingenieria de proceso tema que pueden ser un producto, un servicio o unn tecnologia para la transformacidn de infor-
de negocio ..........I69 macidn o control de informacibn.
ingenieria de produdo. 171 El proceso de ingenieria de sistemas es denominado ingenieria deprocesos de negocio cuando
ingenieria el conlexto del trabajo de ingenieria se enfoca a una empresa. Cuando hay que construir un pro-
de requisitos ....... .I71 d u c t ~el
, proceso se denomina ingenieria de prod~rclo.
ierarquia .......... .I67 Tanto la ingenieria de proceso de negocio como la de producto intentan poner orden a1 desa-
modeknladd sistema. 167 rrollo de sistemas basados en computadoras. Aunque cada una se aplica en un dominio de apli-
simulation .........,168 caci6n diferente, ambas intentan poner a1 software en su contexto.
validacibn ......... ,172
cQu6 en Antes dle que el software s e pue- es el sistema, y los drrboles son l w ele- LCo&le s el producto obtenido? Se debe
d a construir, el -sistemaa e n el que mentos tecno16gicos (incluido el soft- obtener una correcta representaci6n
residirdr s e i e b e comprender. Para ware) que son requeridos para realizar del sistema como consecuencia de la
lograrla se d,eben definir 10s objetivos el sistema. El empeiio en construir ele- ingenieria de sislemas. Se puede rea-
generales de'I sistema; se debe identi- mentos tecnol6gicos, antes de com- lizar a traves d e un prototipo, una
ficar el papel del hardware, software, prender el sistema, lleva a cometer especificaci6n o,incluso, un modelo
personas, bcxses de datos, procedi- errores que desagradar6n a 10s clientes. simb6lic0, debiendo comunicar la
mientos y otnw elementos del sistema; operativa. l a iuncionalidad y l a s
~ C u 6 l e eon
s 10s pasos? Los objetivos y
y 10s requer imientos operacionales 10s requisitos operacionales de mayor caracteristicas de comportamiento del
deben ser idcmtificados; analizados, sistema que se va a construir e incor-
detalle son identificados gracias a la
;.
especificados modelizados, validados
informacibn facllitada por el cliente. porarlo dentro d e la arquirectura del
y gestionadoB. Estas actividades son sistema.
Los requisitos son analizados p r o
la base de la ingenieria de sistemas.
valorar su claridad, complelitud y ~ C d m opuedo estar neguro d e que lo he
GQulbn 10 hace? IUn ingenieto d e sistemas consistencia. Una especificacih, hecho correctamente? El producto obte-
trabaja para :omprender 10s requisitos incorporada a un modelo del sistema. nido, a travbs d e la aplicacion d e la
del sistema e n colaboraci6n con el s e crea y valida posteriormente por ingenieria de sistemas. debe ser revi-
cliente, 10s fuiluros usuarios y otras par- 10sclientes y l a s partes interesadas. sado para determinar su claridad, cam-
tes interesad as. Finalmente, 10s requisitos del siste- pletitud y consistencia. Es importante
iPor q d er i m prtante? Hay un viejo dicho ma son gestionados para asegurar que 10scambios en 10s requisitos d e un
que dice que nlos drrboles no dejan ver q u e 10s cumbios s e controlan ade- sistema Sean gestionados ulilizando
el bosque*.EnL este mntexto, el d x s q e * cuadamente. mbtodos solidos d e GCS (Capitulo 9).
Es decir, tanto la ingenieria de procesos de negocio' como la de producto trabajan para asignar un
papel a1 software de computadora y para establecer 10s enlaces que unen a1 software con otros ele-
mentos de un sistema basado en computadora.
En este capitulo, profundizamos en las necesidades de gesti6n y en las actividades especificas del
proceso que permitan asegurar una organizaci6n del software que consiga resultados satisfactorios en
el tiernpo fijado y por el mCtodo definido.
' En realidad, el terrnino ingenieria desistcmas se ernplea a rnenudo en este contexto. Sin embargo, en cste libro, el
terrnino .ingenieria de sisternasn e s generic0 y s e usa para abarcar a la ingenieria d e proceso de negocio y a la inge-
nieria de producto.
La palabra sistemu es posiblemente el tCrmino mhs usa- ciones especificas, en un conjunto de seiiales de control
do y abusado del ltxico tkcnico. Hablamos de sistemas que provocan alguna acci6n fisica especifica. Tanto la
politicos y de sistemas educativos, de sistemas de avia- creaci6n de un sistema de informaci6n para asesorar a un
ci6n y de sistemas de fabricacibn, de sistemas banca- departamento de marketing, como el software de control
rios y de sistemas de locomoci6n. La palabra no nos para el robot, requieren de la ingenieria de sistemas.
dice gran cosa. Usarnos el adjetivo para describir el sis- Una caracteristica complicada de 10s sistemas basa-
tema y para entender el contexto en que se emplea. El dos en computadora es que 10s elementos que compo-
diccionario Webster define sistema como: nen un sistema pueden tambiCn representar un
I. un conjunto o disposici6n de cosas relacionadas de rnane- macroelemento de un sistema atin mhs grande. El macro-
ra que forman una unidad o un todo orghico; 2. un conjunto elemento es un sistema basado en computadora que es
de hechos, principios, reglas, etc., clasificadas y dispuestas de parte de un sistema miis grande basado en computado-
rnanera ordenada rnostrando un plan logico de union de las par- ra. Por ejemplo, consideremos un ccsistema de automa-
tes; 3. un rnetodo o plan de clasificaci6n o disposicion; 4. una tizacion de una fhbrica>>que es esencialmente una
manera establecida de hacer algo; mCtodo; procedimiento ...
jerarquia de sistemas. En el nivel inferior de la jerar-
Se proporcionan cinco definiciones mas en el dic- quia tenemos una mhquina de control numCrico, robots
cionario, pero no se sugiere un sinonimo preciso. Sis- y dispositivos de entrada de informaci6n. Cada uno es
tema es una palabra especial. un sistema basado en computadora por derecho propio.
Tomando prestada la definition del diccionario Webs- Los elementos de la maquina de control numCrico inclu-
ter, definimos un sistema busado en computudora como: yen hardware electrhico y electromechnico (por ejem-
Un conjunto o disposicion de elernentos que estin organi- plo, procesador y memoria, motores, sensores); software
zados para realizar un objetivo predefinido procesando infor- (para comunicaciones, control de la mhquina e interpo-
rnacion. lacion); personas (el operador de la mhquina); una base
El objetivo puede ser soportar alguna funci6n de de datos (el programa CN almacenado); documentacion
negocio o desarrollar un producto que pueda venderse y procedimientos. Se podria aplicar una descomposi-
para generar beneficios. Para conseguir el objetivo, un cion similar a 10s dispositivos de entrada de informa-
sistema basado en computadora hace uso de varios ele- ci6n y a1 robot. Todos son sistemas basados en
mentos del sistema: computadora.
Software. Programas de cornputadora, estructuras de datos
y su documentacion que sirven para hacer efectivo el metodo
16gic0, procedimiento o control requerido.
Hardware. Dispositivos electr6nicos que proporcionan
capacidad de calculo, dispositivos de interconexion (por 10s sistemos tomplejos son actuolmentd uno jerorquio
ejemplo, conmutadores de red, dispositivos de telecornuni- de macro elementos que son sistemos en si mismos.
caci6n) y dispositivos electrornecanicos (por ejemplo, sen-
sores, rnotores, bornbas) que proporcionan una funci6n En el siguiente nivel de la jerarquia, se define una
extema, del mundo real. cClula de fabricaci6n. La cClula de fabricaci6n es un sis-
Personas. Usuarios y operadores del hardware y software. tema basado en computadora que puede tener elemen-
tos propios (por ejemplo, computadoras, fijaciones
Documentacion. Manuales, formularios y otra informa-
cidn descriptiva que plasma el empleo y/o funcionarniento
mechicas) y tambiCn integra 10s macroelementos que
del sisterna. hemos denominado mhquina de control numCrico, robot
y dispositivo de entrada de informaci6n.
Procedimientos. Los pasos que definen el ernpleo especi-
fico de cada elemento del sisterna o el contexto procedimental Para resumir, la cClula de fabricaci6n y sus macroe-
en que reside el sisterna. lementos esthn compuestos de elementos del sistema
con las etiquetas genCricas: software, hardware, perso-
nas, base de datos, procedimientos y documentaci6n.
En algunos casos, 10s macroelementos pueden compartir
No e s l otraido por hoblor de un plonteomiento un elemento genirico. Por ejemplo, el robot y la mhqui-
((centrodo en el s o b r e ) ) . Comience por consideror na CN podrian ser manejadgs por el mismo operador
todos 10s elementos de un sistemo ontes de concentrorse (el elemento personas). En otros casos, 10s elementos
en el sofhvore. genCricos son exclusivos de un sistema.
El papel del ingeniero de sistemas es definir 10s ele-
Los elementos se combinan de varias maneras para mentos de un sistema especifico basado en computa-
transformar la informaci6n.Por ejemplo, un departamento dora en el contexto de la jerarquia global de sistemas
de marketing transforma la inforrnacion bruta de ventas (macroelementos).
en un perfil del tipico comprador del producto; un robot En las siguientes secciones, examinarnos las tareas que
transforma un archivo de ordenes, que contiene instruc- constituyen la ingenieria de sistemas de computadoras.
CAPfTULO 10 I N G E N ~ E R ~DAE S I S T E M A S
Dorninio
de negocio Vista global
o de producto
Dorninio d e interes
Elernento
del sisterna
FIGURA 10.1. La jerarquia de la ingenieria de sistemas de computadora.
Independientemente del dominio de enfoque, la ingenie- definan 10s procesos que satisfagan las necesidades
ria de sistemas comprende una colecci6n de mCtodos para de la vision en consideraci6n;
navegar de arriba abajo y de abajo arriba en la jerarquia representen el comportamiento de 10s procesos y 10s
ilustrada en la Figura 10.1. El proceso de la ingenieria de supuestos en 10s que se basa el comportamiento;
sistemas empieza normalmente con una ccvisi6n global,,. definan explicitamente las entradas exbgenas3y end6-
Es decir, se exarnina el dominio entero del negocio o del genas de information a1 modelo;
producto para asegurarse de que se puede establecer el representen todos las uniones (incluyendo las sali-
contexto de negocio o tecnol6gico apropiado. La visi6n das) que permitan a1 ingeniero entender mejor la
global se refina para enfocarse totalmente en un dominio visi6n.
de inter& especifico. Dentro de un dominio especifico, se
analiza la necesidad de elementos del sistema (por ejem-
plo, informaci6n, software, hardware, personas). Final-
mente, se inicia el analisis, disefio y construcci6n del
elemento del sistema deseado. En la parte alta de la jerar-
quia se establece un contexto muy amplio y en la parte 10sbuenos sistemas de ingenierio comienzan por
baja se llevan a cabo actividades t6cnicas detalladas, rea- clarificar el comportamiento de contexto -lo vision
lizadas por la disciplina de ingenieria correspondiente (por globoC y progresivomente se von estrechando hasto
ejemplo, ingenieria hardware o software12. el nivel de detolle necesario.
10.2.1. Modelado del sistema Para construir un modelo del sistema, el ingeniero
La ingenieria de sistemas de computadora es un proce- deberia considerar algunas restricciones:
so de modelado. Tanto si el punto de mira esta en la 1. Supuestos que reducen el numero de permutaciones
visi6n global o en la visi6n detallada, el ingeniero crea y variaciones posibles, permitiendo asi a1 modelo
modelos que [MOT92]: reflejar el problema de manera razonable. Por ejem-
' En algunas situaciones, sin embargo, 10s ingenieros del sistema Las entradas exogenas unen un elemento de una vision dada con
deben considerar primero 10s elementos individuales del sistema y/o otros elementos al mismo o a otros niveles; las entradas endogenas
10s requisitos detallados. Empleando este enfoque, 10s subsistemas unen componentes individuales de un elemento en una vision par-
se escriben de abajo a arriba considerando primero 10scomponen- ticular.
tes de detalle del subsistema.
plo, considere un product0 de representacion en tres cliente es a menudo tomada en cuenta hasta el punto
dimensiones usado por la industria de entretenimiento de realizar su enfoque preferido.
para crear animaciones realistas. Un dominio del pro- El modelo de sistema resultante (desde cualquier
ducto permite la representacion de formas humanas vision) puede reclamar una soluci6n completamente
en 3D. Las entradas a este dominio comprenden la automatics, semiautomatics o un enfoque manual. De
habilidad de introducir movimiento de un ccactor,, hecho, es posible a menudo caracterizar modelos de
humano vivo, desde video o creando modelos grhfi- cada tip0 que sirven de soluciones alternativas para el
cos. El ingeniero del sistema hace ciertos supuestos problema que tenemos entre manos. En esencia, el
sobre el rango de movimientos humanos permitidos ingeniero del sistema modifica simplemente la influen-
(por ejemplo, las piernas no pueden enrollarse alre- cia relativa de 10s diferentes elementos del sistema
dedor del tronco) de manera que puede limitarse el (personas, hardware, software) para crear modelos de
proceso y el rango de entradas. cada tipo.
Simplificaciones que permiten crear el modelo a
tiempo. Para ilustrarlo, considere una compafiia de 10.2.2. Simulacidn del sistema
productos de oficina que vende y suministra una
amplia variedad de fotocopiadoras, faxes y equipos En 10s aiios 60, R.M. Graham [GRA69] hizo un comen-
similares. El ingeniero del sistema esta modelando tario critic0 sobre la manera en que se construian 10s sis-
las necesidades de la organizacion suministradora y temas basados en computadora: ccConstruimos sistemas
esta trabajando para entender el flujo de informaci6n igual que 10s hermanos Wright construian aviones: cons-
que engendra una orden de suministro. Aunque una truimos todo el sistema, lo empujamos barranco abajo,
orden de suministro puede generarse desde muchos le dejamos que se estrelle y empezamos de nuevo.>>De
origenes, el ingeniero categoriza solamente dos fuen- hecho, para a1 menos un tip0 de sistema -el sistema
tes: demanda interna o petici6n externa. Esto per- reactive- lo continuamos haciendo hoy en dia.
mite una particion simplificada de entradas necesaria Muchos sistemas basados en computadora interac-
para generar una orden de trabajo. cionan con el mundo real de forma reactiva. Es decir,
10s acontecimientos del mundo real son vigilados por
Limitaciones que ayudan a delimitar el sistema. Por
el hardware y el software que componen el sistema, y
ejemplo, se esta modelando un sistema de avionica
basandose en esos sucesos, el sistema aplica su control
para un avion de proxima generacion. Como el avion
sobre las maquinas, procesos e incluso las personas que
tendra un diseiio de dos motores, todos 10s dominios
motivan 10s acontecimientos. Los sistemas de tiempo
de supervision de la propulsion se modelaran para
real y sistemas empotrados pertenecen a menudo a la
albergar un maximo de dos motores y sus sistemas
categoria de sistemas reactivos.
redundantes asociados.
1DQde acaba el modelo

de ingenieria del sistema?
Si lo copocidod de simulocian no esta disponible
para un sistemo reoctivo, el riesgo del proyecto
Restricciones que guian la manera de crear el modelo se incremento. Considerorpara su utilizocibn un modelo
y el enfoque que se toma a1 implementar el modelo. de proceso iterotivo que te permito obtener un resultodo
Por ejemplo, la infraestructura tecnologica para el en uno primem iterocih y utilizer ootros itemcionespara
sistema de representacion en tres dimensiones des- ojustor sus corocteristicos.
crita anteriormente es un solo procesador basado en
un Power-PC. La complejidad de calculo de 10s pro- Desgraciadamente, 10s desarrolladores de sistemas
blemas deben restringirse para encajar en 10s limi- reactivos luchan a veces para hacerlos funcionar correc-
tes de proceso impuestos por el procesador. tamente. Hasta hace poco, ha sido dificil predecir el ren-
dimiento, la eficacia y el comportamiento de estos
sistemas antes de construirlos. Realmente, la construc-
cion de muchos sistemas de tiempo real era una aven-
tura. Las sorpresas (la mayoria desagradables) no se
Un ingeniero del sistemo considera 10s siguientes factores descubrian hasta que el sistema era construido y ccarro-
cuando desorrolla soluciones olternotivos: plonteomientos, jado colina abajo,,. Si el sistema se estrellaba debido a
simplificaciones, limitaciones, restricciones y preferencias un funcionamiento incorrecto, comportamiento inapro-
de 10s clientes. piado o escaso rendimiento, cogiarnos las piezas y empe-
zabamos de nuevo.
Preferencias que indican la arquitectura preferida Muchos sistemas de la categoria de 10s reactivos con-
para todos 10s datos, funciones y tecnologia. La solu- trolan miquinas ylo procesos (por ejemplo, aerolineas
cion preferida entra a veces en conflicto con otros comerciales o refinerias de petroleo) que deben operar
factores restrictivos. Aunque la satisfaction del con extrema fiabilidad.
C A P ~ T U L O10 I N G E N I E R ~ ADE S I S T E M A S
Si el sistema falla, podrian ocurrir pCrdidas econ6- ficaci6n del sistema. En el Capitulo 31 se estudian
micas o humanas significativas. Por este motivo, el enfo- brevemente 10s detalles tCcnicos y tCcnicas especia-
que descrito por Graham es penoso y peligroso. les de modelado que se emplean para llevar a cab0
Hoy en dia se utilizan herramientas software para estas pruebas.
el modelado y simulacion de sistemas para ayudar a
eliminar sorpresas cuando se construyen sistemas
reactivos basados en computadora. Estas herramien-
tas se aplican durante el proceso de ingenieria de sis-
temas, mientras se estan especificando las necesidades
del hardware, software, bases de datos y de personas.
Las herramientas de modelado y simulacion capaci- Herrornientos CASE
tan a1 ingeniero de sistemas para probar una especi- Modelodo y Sirnuloci6n
El objetivo de la ingenieria de proceso de negocio (IPN) Se deben analizar y diseiiar tres arquitecturas dife-
es definir arquitecturas que permitan a las empresas rentes dentro del context0 de objetivos y metas de
emplear la infomacion eficazmente. Michael Guttman negocio:
[GUT991 describe el desafio cuando dice: arquitectura de datos
El actual entomo computacional consiste en un poder de arquitectura de aplicaciones
computacion distribuido en toda la empresa con multiples
unidades diferentes de procesamiento, dividido y configura- infraestructura de la tecnologia
do por una amplia variedad de tareas. Nuevos planteamien-
tos como la computaci6n cliente-servidor, procesamiento
distribuido, el trabajo en red (por nombrar algunos de 10s ttr- 10s obiptos de dotos son trotodos en detolle
minos mas sobreusados) permiten gestionar las demandas
en el Copitulo 12.
aportando mayor funcionalidad y flexibilidad.
Sin embargo, el coste de estos cambios es ampliamente La arquitectura de datos proporciona una estructu-
discutido por la organizaciones de TI (Tecnologiasde la Infor-
n~acidn)que deben soportar esta poliglota configuraci6n. ra para las necesidades de infomacion de un negocio o
Hoy, cada organizaci6n de TI debe favorecer la integration de una funci6n de negocio. Los ladrillos de la arquitq-
de sus sistemas. Debe diseiiar, implementar y soportar su tura son 10s objetos de datos que emplea la empresa. ~n
propia configuraci6n de recursos de computacion heterogC- objeto de datos contiene un conjunto de atributos que
nea, distribuidos ldgica y geogrificamente por toda la empre- definen aspectos, cualidades, caracteristicas o descrip-
sa, conectindola a travts de un esquema apropiado para el tor de 10s datos que han sido descritos. Por ejemplo, un
trabajo en red.
ingeniero de la infomacion puede definir el objeto de
Por otra parte, esta configuracion debe ser diseiiada para
datos: cliente. Para describir mas en detalle a1 cliente,
cambios continuos, desigualmente localizados en la empre-
sa, debido a cambios en requisitos del negocio y en las pro- se definen 10s siguientes atributos:
pias tecnologias. Estos diversos e incrementales cambios Objeto: Clienre
deben ser coordinados a traves del entorno distribuido, con- Atributos:
sistente en hardware y software suministrado por decenas,
cuando no cientos, de vendedores. Por supuesto, esperamos nombre
que estos cambios 10s incorporemos sin ruptura con la ope- nomhre de la compaiiia
rativa habitual permitiendo ademas ampliar la operativa.
clasijicacidn del trabajo y autoridad en compra
Cuando hablamos de una vision general de las nece- direccidn comercia1 e informacidn de conracto
sidades de tecnologia de infomaci6n de una compaiiia,
existen pequeiias incertidumbres que son planteadas a compra(s) anteriores
la ingenieria de sistemas. La ingenieria de proceso de
negocio es un acercamiento para crear un plan gene- fecha de iltimo contacto
ral para implementar la arquitectura de computacion situacidn del contacto
[SPE93]. Una vez definido el conjunto de datos, se identifican
sus relaciones. Una relacion indica como 10s objetos
e s t h conectados. Como ejemplo, considerar 10s obje-
tos: cliente y producto A. Los dos objetos pueden conec-
Tres orquitecturos diferentes son desorrollodos duronte tarse por la relaci6n compra; es decir, un cliente compra
lo IPN: lo orquitecturo de dotos, la arquitectura el producto A o el producto A es comprado por un clien-
de aplicocion y la infraestructura tecnologica. te. Los objetos de datos (pueden existir cientos o miles
INGENIERIA DEL SOFTWARE. UN ENFOQUE P R A C T l C O
para una actividad de negocio importante) fluyen entre dad de la empresa. La PEI define 10s objetos de datos
las funciones de negocio, estAn organizados dentro de visibles a nivel empresa, sus relaciones y c6mo fluyen
una base de datos y se transforman para proveer infor- entre 10s dominios del negocio [MAR90].
maci6n que sirva a las necesidades del negocio.
La arquitecrura de aplicacidn comprende aquellos
elementos de un sistema que transforman objetos den-
lomo ingeniero del sohare, no debes profundizar en PEI
tro de la arquitectura de datos por alg6n proposito del
ni en el A N . No obstante, si no esW dm que estas
negocio. En el contexto de este libro, consideramos
actividades hayon sido realizadas, informe o su superior
normalmente que la arquitectura de aplicacion es el sis- que el riesgo del proyecto es muy alto.
tema de programas (software) que realiza esta trans-
formation. Sin embargo, en un contexto mhs amplio, La vista del dominio se trata con una actividad IPN
la arquitectura de aplicacion podna incorporar el papel denominada analisis del area de negocio (AAN).Hares
de las personas (por ejemplo, cliente/servidor) que ha [HAR93] describe AAN de la siguiente manera:
sido disefiado para implementar estas tecnologias. El AAN se ocupa de identificaren detalle la informaci6n (en
la forma de tipos de entidad [objeto datos]) y 10s requisitos de
las funciones (en la forma de procesos) de areas de negocio
Eldetolle sobre lo orquitecturo del software seleccionadas [dominios] identificadas durante el PEI, averi-
es presentodo en el Capitulo 14. guando sus interacciones (en forma de matrices). Se ocupa sola-
rnente de especificar qut se requiere en un Area de negocio.
La infraestructura tecnoldgica proporciona el fun- A medida que el ingeniero de informaci6n comienza el

damento de las arquitecturas de datos y de aplicaciones. AAN, el enfoque se estrecha hacia un dominio del nego-
La infraestructura comprende el hardware y el software cio especifico. El AAN ve el irea del negocio como una
empleados para dar soporte a las aplicaciones y datos. entidad y aisla las funciones de negocio y procedimientos
Esto incluye computadoras y redes de computadora, enla- que permiten a1 Area del negocio lograr sus objetivos y
ces de telecomunicaciones, tecnologias de almacena- metas. El AAN, a1 igual que el PEI, define objetos de datos,
miento y la arquitectura (por ejemplo, cliente/servidor) sus relaciones y c6mo fluye la informaci6n. Pero a este
disefiada para implementar estas tecnologias. nivel, estas caractensticasestkn delimitadas por el irea de
negocio que se estA analizando. El resultado de AAN es
aislar las ireas de oportunidad en las que 10s sistemas de
Planificacion informaci6n pueden prestar soporte a1 irea de negocio.
estrategica
de la informacion
(vista global)
/
~ r e de
a negocio
Ana lsls de area

de negocio Ingenieria de Procesos de Negocio
lvista
del dorn'nioj
Una vez que se ha aislado un sistema de informacion
para un desarrollo posterior, la IPN hace una transition
a la ingenieria del software. Invocando la fase del dise-
iio de sistema de negocio (DSN), se modelan 10s requi-
sitos bisicos de un sistema de informacion especifico y
estos requisitos se traducen en arquitectura de datos,
FlGURA 10.2. La jerarquia de la ingenieria de procesos.
Para modelar las arquitecturas de sistema descritas

Construccion
e integracion
(vista detallada)
I software
arquitectura de aplicacion e infraestructura tecnologica.
El paso final de la IPN (construccidn e integracidn,
C&I) se centra en 10s detalles de la implementation. La
arquitectura e infraestructura se implementan constru-
yendo una base de datos apropiada y estructuras internas
de datos, mediante la construcci6n de aplicaciones que
estAn constituidas por programas, y seleccionando 10s
elementos apropiados de una infraestructura tecnologica
anteriormente, se dcfine una jerarquia de actividades de para dar soporte a1 disefio creado durante el DSN. Cada
ingenieria de la informaci6n. Como muestra la Figura uno de estos componentes del sistema debe integrarse
10.2, la vision global se consigue a travCs de la plan$- para formar una aplicacion o sistema de informacion com-
cacidn de la estrategia de informacidn (PEI). La PEI pleto. La actividad de integracion tambiCn coloca a1 nue-
ve todo el negocio como una entidad y aisla 10s domi- vo sistema de informacion en el contexto del Area de
nios del negocio (por ejemplo, ingenieria, fabricacion, negocio, realizando todo el entrenamiento de usuario y
marketing, finanzas, ventas) importantes para la totali- soporte logistic0 para conseguir una suave transici6n.
CAPfTULO 10 INGENIERIA DE SISTEMAS
La meta de la ingenieria de producto es traducir el

deseo de un cliente, de un conjunto de capacidades Analisis
definidas, a un producto operativo4. Para conseguir del sisterna
esta meta, la ingenieria de producto (como la inge- (vista global)
nieria de proceso de negocio) debe crear una arqui-
tectura y una infraestructura. La arquitectura Capa
comprende cuatro componentes de sistema distintos:
software, hardware, datos (bases de datos) y perso-
nas. Se establece una infraestructura de soporte e
incluye la tecnologia requerida para unir 10s compo-
nentes y la informacion (por ejemplo, documentos, -1
Requisito de proces
CD-ROM, video) que se emplea para dar soporte a
10s componentes.
Como se muestra en la Figura 10.3, la vision glo-
bal se consigue a travks de la ingenieria de requisi- / J 1ae prograrna
tos. Los requisitos generales del producto se obtienen
del cliente. Estos requisitos comprenden necesidades Construction
de informacion y control, funcionalidad del produc-
to y comportamiento, rendimiento general del pro-
d u c t ~ disefio,
, restricciones de la interfaz y otras FIGURA 10.3. La jerarquia de la ingenieria de productos.
necesidades especiales. Una vez que se conocen estos
requisitos, la misi6n del analisis del sistema es asig- Parte del papel del andisis de sistemas es establecer 10s
nar funcionalidad y comportamiento a cada uno de mecanismos de interfaz que permitirh que esto suceda.
10s cuatro componentes mencionados anteriormente. La vision de elemento para la ingenieria de produc-
Una vez que se ha hecho la asignacion, comienza to es la disciplina de ingenieria aplicada a la asignacion
la ingenieria de componentes del sistema. La inge- de componentes. Para la ingenieria del software, esto
nieria de componentes del sistema es, de hecho, un significa actit?dades de modelado del analisis y diseiio
conjunto de actividades concurrentes que se dirigen (cubierto en detalle en posteriores capitulos) y activi-
separadamente a cada uno de 10s componentes del sis- dades de construccidn e integracidn que comprenden
tema: la ingenieria del software, ingenieria hardware, generation de codigo, pruebas y actividades de sopor-
ingenieria humana e ingenieria de bases de datos. Cada te. El modelado de la fase de analisis asigna requisitos
una de estas disciplinas de ingenieria toma una vista a las representaciones de datos, funciones y comporta-
de dominio especifica, per0 es importante resaltar que miento. El disefio convierte el modelo de analisis en
las disciplinas de ingenieria deben establecer y man- disefios de datos, arquitectonicos, de interfaz y a nivel
tener una comunicacion activa entre ellas. de componentes del software.
La consecuencia del proceso de ingenieria de sistemas

es la especificacion de un sistema o producto basado en
computadora que se describe geniricamente, en dife-
rentes niveles en la Figura 10.1. Pero el desafio de la
ingenieria del sistema (y de 10s ingenieros del softwa-
re) es importante: ~ C Opodemos
~ O asegurar que hemos
especificado un sistema que recoge las necesidades del
cliente y satisface sus expectativas? No hay una res-
puesta segura a esta dificil pregunta, per0 un solido pro- .
ceso de ingenieria de requisitos es la mejor solucion de La ingenieria de requisitos facilita el mecanismo
que disponemos actualmente. apropiado para comprender lo que quiere el cliente, ana-
Debemos hacer notar que la terrninologia (adaptada por [MAR90])

utilizada en la Figura 10.2 esta asociada con la ingenieria de la infor-
macion, la predecesora del modern0 IPN. Sin embargo, el area cen-
tral implicada e n cada actividad seAalada e s dirigida por todos
aquellos que consideran el tema.
lizando necesidades, confirmando su viabilidad, nego- iPor que es tan dificil
ciando una soluci6n razonable, especificando la solu- obtener un planteamiento
cion sin ambigiiedad, validando la especificacidn y claro de lo que necesita
gestionando 10s requisitos para que se transformen en el cliente?
un sistema operacional [THA97]. El proceso de inge-
nieria de requisitos puede ser descrito en 5 pasos dis- identificar las personas que ayudarhn a especificar
tintos [SOM97]: Identificacidn de Requisitos, Andisis requisitos y contrastar su papel en la organization;
de Requisitos y Negociaci6n, Especificaci6n de Requi- definir el entorno tCcnico (arquitectura de computa-
sites, Modelizado del Sistema, Validaci6n de Requisi- cibn, sistema operativo, necesidades de telecomuni-
tos y Gestidn de Requisitos. caciones) en el sistema o producto a desarrollar e
integrar;
10.5.1. ldentificacih de requisitos identificar ccrestricciones de dominie>> (caracten'sti-
En principio, parece bastante simple -preguntar a1 cas especificas del entorno de negocio en el domi-
cliente, a 10s usuarios y a 10s que esthn involucrados en nio de la aplicaci6n) que limiten la funcionalidad y
10s objetivos del sistema o producto y sean expertos, rendimientos del sistema o producto a construir;
investigar c6mo 10s sistemas o productos se ajustan a definir uno o mis mCtodos de obtenci6n de requisi-
las necesidades del negocio, y finalmente, c6mo el sis- tos (entrevistas, grupos de trabajo, equipos de dis-
tema o producto va a ser utilizado en el dia a dia-. Esto cusi6n);
que parece simple, es muy complicado. solicitar la participaci6n de muchas personas para
Christel y Kang [CRI92] identifican una sene de pro- que 10s requisitos se definan desde diferentes puntos
blemas que nos ayudan a comprender por quC la obten- de vista, asegurarse de identificar lo fundamental de
ci6n de requisitos es costosa. cada requisito registrado;
problemas de alcance. El limite del sistema esth ma1 identificar requisitos ambiguos como candidates para
definido o 10s detalles tCcnicos innecesarios, que han el prototipado, y
sido aportados por 10s clientes/usuarios,pueden con- crear escenarios de uso (ver Capitulo 11) para ayu-
fundir mhs que clarificar 10s objetivos del sistema. dar a 10s clientes/usuarios a identificar mejor 10s
problemas de comprensidn. Los clientes/usuarios no requisitos fundamentales.
esthn completamente seguros de lo que necesitan,
tienen una pobre compresi6n de las capacidades y
limitaciones de su entorno de computacibn, no existe
un total entendimiento del dominio del problema, Aseglirote de hober volorodo 10s corocteristicos generoles
existen dificultades para comunicar las necesidades antes de especificor el esfuerzo y plozo poro obtener
a1 ingeniero del sistema, la omisi6n de informaci6n 10s requisitos de detolle.
por considerar que es <cobvia>>, especificacion de
El resultado alcanzado como consecuencia de la iden-
requisitos que esthn en conflict0 con las necesidades
tificaci6n de requisitos variarh dependiendo del tama-
de otros clientes/usuarios, o especificar requisitos
iio del sistema o producto a construir. Para grandes
ambiguos o poco estables.
sistemas, el producto obtenido debe incluir:
Problemas de volatilidad. Los requisitos cambian
una relaci6n de necesidades y caracteristicas;
con el tiempo.
un informe conciso del alcance del sistema o producto;
una lista de clientes, usuarios y otros intervinientes
que deben participar en la actividad de obtenci6n de
requisitos;
Un informe detollodo bolo el ftulo ((Necesidades una descripci6n del entorno tCcnico del sistema;
en lo Obtention de Requisitos)) puede ser descorgodo de una relaci6n de requisitos (perfectamente agrupados
www.sei.cmu.edu/publications/documents/
por funcionalidad) y las restricciones del dominio
92.reports/92.tr.012.html
aplicables a cada uno;
Para ayudar a solucionar estos problemas, 10s inge- un conjunto de escenarios que permiten profundizar
nieros de sistemas deben aproximarse de una mane- en el uso del sistema o producto bajo diferentes con-
ra organizada a travCs de reuniones para definir diciones operativas, y
requisitos. cualquier prototipo desarrollado para definir mejor
Sommerville y Sawyer [SOM97] sugieren un con- 10s requisitos.
junto de actuaciones para la obtenci6n de requisitos, que
esthn descritos en las tareas siguientes:
valorar el impact0 en el negocio y la viabilidad t6c- 10s rnitodos de obtencibn de requisitos
nica del sistema propuesto; san presentudos en el Copitulo 11.
CAP~TULO
LO I N G E N I E R ~ ADE SISTEMAS
Cada uno de 10s productos obtenidos debe ser revi- El ingeniero del sistema debe resolver estos conflic-
sad0 por las personas que hayan participado en la obten- tos a traves de un proceso de negociaci6n. Los clientes,
ci6n de sus requisitos. usuarios y el resto de intervinientes deberan clasificar
sus requisitos y discutir 10s posibles conflictos segun su
10.5.2. Analisis y negociaci6n de requisitos prioridad. Los riesgos asociados con cada requisito s e r h
identificados y analizados (ver Capitulo 6). Se efectuan
Una vez recopilados 10s requisitos, el producto obteni- ccestimacionesn del esfuerzo de desarrollo que se utili-
do configura la base del ancilisis de requisitos. Los requi- zan para valorar el impact0 de cada requisito en el cos-
sitos se agrupan por categorias y se organizan en te del proyecto y en el plazo de entrega. Utilizando un
subconjuntos, se estudia cada requisito en relaci6n con procedimiento iterativo, se iran eliminando requisitos,
el resto, se examinan 10s requisitos en su consistencia, se iran combinando y/o modificando para conseguir
completitud y ambiguedad, y se clasifican en base a las satisfacer 10s objetivos planteados.
necesidades de 10s clientes/usuarios.
iQue tuestiones deben ser 10.5.3. Especificacih de requisitos

preguntadas y tontestadas En el context0 de un sistema basado en computadoras
durante el analisis de requisitos? (y software), el termino especificacidn significa distin-
tas cosas para diferentes personas. Una especificaci6n
A1 iniciarse la actividad del analisis de requisitos se puede ser un documento escrito, un modelo grafico, un
plantean las siguientes cuestiones: modelo matemadco formal, una colecci6n de escena-
jCada requisito es consistente con 10s objetivos gene- rios de uso, un prototipo o una combinaci6n de lo ante-
rales del sistema/producto? riormente citado.
jTienen todos 10s requisitos especificados el nivel Algunos sugieren que debe desarrollarse una ccplan-
adecuado de abstraccibn? Es decir, jalgunos requi- tilla estandarn [SOM97] y usarse en la especificaci6n
sitos tienen un nivel de detalle tecnico inapropiado del sistema, argumentando que asi se conseguirian requi-
en esta etapa? sitos que Sean presentados de una forma mas consis-
tente y mas comprensible. No obstante, en muchas
jEl requisito es necesario o representa una caracte- ocasiones es necesario buscar la flexibilidad cuando una
ristica afiadida que puede no ser esencial a la finali- especificaci6n va a ser desarrollada. Para grandes sis-
dad del sistema? temas, un documento escrito, combinado con descrip-
jCada requisito esta delimitado y sin ambiguedad? ciones en lenguajes natural y modelos graficos puede
Cada requisito tiene procedencia. Es decir, jexiste ser la mejor altemativa. En cualquier caso, 10s escena-
un origen (general o especifico) conocido para cada rios a utilizar pueden ser tanto 10s requeridos para pro-
requisito? ductos de tamafio pequefio o 10s de sistemas que residan
jExisten requisitos incompatibles con otros requi- en entomos tecnicos bien conocidos.
sitos?
~ E posible
s lograr cada requisito en el entomo tic-
nico donde se integrara el sistema o producto?
jSe puede probar el requisito una vez implementado?
Tecnicos de Negociocion
La Especificacidn del Sistema es el producto final sobre

10s requisitos del sistema obtenido por el ingeniero. Sir-
ve como fundamento para la ingenieria del hardware,
ingenieria del software, la ingenieria de bases de datos y
Anolisis de Requisitos la ingenieria humana. Describe la funcion y caracteristi-
Es corriente en clientes y usuarios solicitar mas de cas de un sistema de computation y las restricciones que
lo que puede realizarse, consumiendo recursos de nego- gobieman su desarrollo. La especificaci6n delimita cada
cio limitados. TambiCn es relativamente comun en clien- elemento del sistema. La Especificacidn del Sistema des-
tes y usuarios el proponer requisitos contradictorios, cribe la informaci6n (datos y control) que entra y sale del
argumentando que su versi6n es ccesencial por necesi- sistema.
dades especialesn.
Si 10s diferentes clientes/usuarios no pueden facilitar

10s requisitos, el riesgo de error es rnuy alto. Procedo
con extrerno precoucion. Especificocion del sistemo
10.5.4. Modelado del sistema (es un problema importante), requisitos contradictorios,
Considere por un momento que a usted se le ha reque- o requisitos imposibles o inalcanzables.
rido para especificar 10s requisitos para la construcci6n Aunque la validaci6n de requisitos puede guiarse de
de una cocina. Se conocen las dimensiones del lugar, la manera que se descubran errores, es util chequear cada
localizaci6n de las puertas y ventanas y el espacio de requisito con un cuestionario. Las siguientes cuestiones
pared disponible. Debes especificar todos 10s armarios representan un pequefio subconjunto de las preguntas
y electrodomCsticos e indicar d6nde colocarlos. iSeri que pueden plantearse:
una especificaci6n vilida? LEsti el requisito claramente definido? ~Puedeinter-
La respuesta es obvia. Para especificar completamente pretarse mal?
lo que vamos a desarrollar, necesitamos un modelo de iEsta identificado el origen del requisito (por ejem-
la cocina con toda su informaci6n, esto es, un antepro- plo: persona, norma, documento)? LEIplanteamiento
yecto o una representaci6n en tres dimensiones que mues- final del requisito ha sido contrastado con la fuente
tre las posiciones de 10s armarios y electrodomCsticos, original?
y sus relaciones. Con el modelo sera relativamente facil LEIrequisito esti delimitado en tCrminos cuantita-
asegurar la eficiencia del trabajo (un requisito de todas tivos?
las cocinas), la estCtica ccvisualn de la sala (es un requi-
~ Q u Cotros requisitos hacen referencia a1 requisito
sito personal, aunque muy importante).
estudiado? ~ E s t claramente
h identificados por medio
Se construyen modelos del sistema por la misma
de una matriz de referencias cruzadas o por cualquier
raz6n que desarrollamos para una cocina un antepro-
otro mecanismo?
yecto o una representaci6n en 3D. Es importante eva-
luar 10s componentes del sistema y sus relaciones entre iEl requisito incumple alguna restricci6n definida?
si; determinar c6mo estan reflejados 10s requisitos, y iEl requisito es verificable? Si es asi, ipodemos efec-
valorar como se ha concebido la ccestCtican en el siste- tuar pruebas (algunas veces llamadas criterios de
ma. Se profundiza en el modelado del sistema en la validaci6n) para verificar el requisito?
Secci6n 10.6. iSe puede seguir el requisito en el modelo del sis-
tema que hemos desarrollado?
10.5.5. Validaci6n d e requisitos iSe puede localizar el requisito en el conjunto de
El resultado del trabajo realizado es una consecuencia objetivos del sistema/producto?
de la ingenieria de requisitos (especificacion del siste- iEsti el requisito asociado con 10s rendimientos del
ma e informaci6n relacionada) y es evaluada su calidad sistema o con su comportamiento y han sido esta-
en la fase de validaci6n. La vulidacidn de requisitos exa- blecidas claramente sus caracteristicas operaciona-
mina las especificaciones para asegurar que todos 10s les? iEl requisito esti implicitamente definido?
requisitos del sistema han sido establecidos sin ambi-
giiedad, sin inconsistencias, sin omisiones, que 10s erro-
res detectados hayan sido corregidos, y que el resultado
del trabajo se ajusta a 10s estandares establecidos para
el proceso, el proyecto y el producto.
Requisitos
On punto fundornentol dumnte la validocihn Las preguntas planteadas en la lista de comproba-

de 10s requisitos es la consistencia. UfiIice el rnodelo ci6n ayudan-aasegurar que el equipo de validaci6n dis-
del sisterno porn osegurar que 10s requisitos pone de lo necesario para realizar una revisi6n completa
hon sido consistenternente estoblecidos. de cada requisito.
El primer mecanismo para la validation de 10s requi-
sitos es la revisi6n tCcnica formal (Capitulo 8). El equi- 10.5.6. Gesti6n de requisitos
po de revisi6n incluye ingenieros del sistema, clientes, En el capitulo anterior se advertia que 10s requisitos del
usuarios, y otros intervinientes que exarninan la espe- sistema cambian y que el deseo de cambiar 10s requisi-
cificaci6n del sistema5 buscando errores en el conteni- tos persiste a lo largo de la vida del sistema. La gestidn
do o en la interpretation, ireas donde se necesitan de requisitos es un conjunto de actividades que ayudan
aclaraciones, informaci6n incompleta, inconsistencias a1 equipo de trabajo a identificar, controlar y seguir 10s
En realidad, muchas Revisiones Tecnicas Formales son dirigidas a

medida que se desarrolla la especificacion del sistema. Es mejor para
el equipo de revision examinar pequefias partes de la especificacion,
de forma que s e pueda centrar la atencion en un aspect0 especifico
de 10s requisitos.
requisitos y 10s cambios en cualquier momento. Muchas miento. En la Figura 10.4 s e muestra de forma
de estas actividades son idknticas a las tCcnicas de ges- esquemitica este planteamiento. Cada matriz d e
ti6n de configuraci6n del software que se referencian seguimiento identifica 10s requisitos relacionados
en el Capitulo 9. con uno o m i s aspectos del sistema o su entorno.
Entre las posibles matrices de seguimiento citamos
las siguientes:
Referencia web/ Matriz de se,puimieizto cle cur.acter.isticas. Muestra
Un orticulo titulodo donfigurondo el lroboio de gesti6n 10s requisitos identificados en relacion a las caracte-
de requisitos poro tir contiene uno guio progmbtico: risticas definidas por el cliente del sistema/producto.
s1sc.hill.af.mil./crosstalk/l999/apr/davis.asp Mcrtriz cle seg~limieiztode origenes. Identifica el
origen de cada requisito.
Como en la Gesti6n de Configuraci6n del Software
(GCS). la gesti6n de requisitos comienza con la activi- Matriz do seguirniento de dependencius. Indica
dad de identificacicin. A cada requisito se le asigna un c6mo se relacionan 10s requisitos entre si.
unico identifi cador, clue puede tomar la forma: Matriz de segrlinrieizto de suhsisteincrs. Vincula
10s requisitos a 10s subsistemas que 10s manejan.
El tip0 dc rccluisito toma nlguno de 10s siguientes Matriz tlc segr~irnientocle interfaces. ~Muestra
v:ilores: F = recluisito funcional, D = requisito de datos. como 10s requisitos estkn vinculados a las interfaces
C = requisito de comportamiento, I = requisito de inter- externas o internas del sistema.
faz, y S = requisito de salida. De esta forma, un requi-
site iclentilicado como F09 indica clue se trata de un
rccluisito f~~ncional y clue tiene asignado el numero 9
dentro de 10s citaclos requisitos. luondo un sisremo es gronde y complejo, determinor
10s ccconexionesa entre 10s requisitos puede ser uno toreo
desolentodoro. Utilice 10s toblos de seguimiento
p r o hocer el troboio on poco mas facil.
fluchos actividades de gesti6n de requisitos En muchos casos, las matrices de seguimiento sc

son tornadas de lo GCS. incorporan colno parte de un requisito dc basc de datos
y se utiliza para buscar ripidamente 10s diferentes aspec-
Una vez 10s requisitos han siclo identificados, se tos del sistema a construir afectados por el cambio de
desarrollarlin un con.junto de matrices para su segui- requisito.
Todos 10s sistemas basados en computadora pueden I I I , , , . ,

modelarse con10 una transformacicin de la informaci6n \ A s ~ e c t oe s ~ e c i f i ~del
o sistema o d e su entorno
empleando una arquitectura del tipo entrada-proceso- Requ i
salida. Hatley y Pirbhai [HAT871 han extendido esta
vision para incluir dos caracteristicas adicionales del
sistema: tratamiento de la interfaz de usuario y trata-
miento del mantenimiento y autocomprobaci6n. Aun-
que estas caracteristicas adicionales no est6n presentes
en todos 10s sistemas basados en computadora, son muy
comunes y su especificacion hace mis robusto cualquier
modelo del sistema.
Mediante la representacion de entrada, proceso, sali-
da, tratamiento de la interfaz de usuario y de autocom-
probacibn, un ingeniero de sistemas puede crear un
modelo de componentes de sistema que establezca el fun-
damento para analisis de requisitosposteriores y etapas .
de disefio en cada una de las disciplinas de ingenieria. FIGURA 10.4. M a t r i z d e s e g u i m i e n t o g e n e r i c a .
A SOFTWARE. UN ENFOQUE P R ~ C T ~ C O
codigo de bmas equivalente), las cajas se mandarin a lob con-
Proceso de interfaz de usuario

I tenedores apropiados. Las cajas pasan aleatoriamente y estin
igualmente espaciadas. La linea se mueve lentamente.
Proceso Funciones d e proceso Proceso !

de entrada y control de salida
Codigo Comandos
de barras Sisterna de conlrol MecanisrnO
de codigo - *
de clasificacion
I
de clasificaci6n
de cinta
transportadora MOS form ateados del informe
Mantenirniento L a Estructura
transportadora lndicador de la
y autocornprobacion Datos de
velocidad de la cinta diagnostic0
*-
-
principal
FIGURA 10.5. Plantilla del modelo del sistema [HAT87]. de la estacion
Para desarrollar el modelo de sistema, se emplea un

FIGURA 10.6. Diagrama de contexto de Arquitectura
esqwma del moclelado clel sistcrnu [HAT87]. El inge-
del SCCT (ampliado).
niero de sistemas asigna elementos a cada una de las
cinco regiones de tratamiento del esquema: ( I ) inte~faz
de usuario. (2) entrada, (3) tratamiento y control del sis- Para este ejemplo, la versi6n ampliada utiliza un PC
tema, (4) salida y (5) mantenimiento y autocomproba- en la estaci6n clasificadora. El PC ejecuta todo el software
cibn. En la Figura 10.5 se muestra el formato del del SCCT; interacciona con el lector de c6digo de barras
esquema de arquitectura. para leer park de 10s ndmeros de cada caja; interacciona
con la cinta transportadora vigilando 10s equipos que con-
trolan velocidad en dicha cinta; almacena todos 10s n6me-
ros de pieza clasificados; interacciona con el operador
Otros rnhtodos de rnodelizocibn del sisterno tmon
uno visibn orientada a obietos. Elenfoque UML puede
de la estacion clasificadora para producir una variedad
ser apliiodo a estos sistemas, plantebndose de informes y diagn6sticos; envia seiiales de control al
en 10s Copitulos 21 y 22. hardware separador para clasificar las cajas; y se comu-
nica con la estructura central de la automatization de la
fhbrica. En la Figura 10.6 se muestra el DCS para SCCT
Como casi todas las tCcnicas de modelado usadas en (ampliado).
la ingenieria del software y de sistemas, el esquema del
tnodelado del sistema permite a1 analista crear una jerar-
quia en detalle. En la parte alta de la jerarquia reside el
cliagrurnu de contexto del sistema (DCS). El diagrama
N DCS permite uno visibn ((global)) del sisterno
de contexto ccestablece el liniite de informacion entre el que debes cofitrui~.10sdetolles que necesites
sistema que se esth implementando y el entorno en que no deben especificorse en este nivel. Refino
va a operaro [HAT87]. Es decir, el DCS define todos 10s jerbrquicornente el DCS poro eloboror el sisterno.
suministradores externos de informaci6n que emplea el
sistema, todos 10s consumidores externos de informa- Cada caja de la Figura 10.6 representa una cntidad
ci6n creados por el sistema y todas las entidades que se extcrna, es decir, un suministrador o consumidor de
comunican a travCs de la interfaz o realizan manteni- informaci6n del sistema. Por ejemplo, el lector del cMi-
miento y autocomprobaci6n. go de barras produce informaci6n que es introducida en
Para ilustrar el empleo del DCS, considere una ver- el sistema SCCT. El simbolo para representar todo el
si6n ampliada del sisternu cle clasificuci6n de cintu trans- sistema (o a niveles mhs bajos, subsistemas principa-
portcrcloru (SCCT) estudiado anteriormente en el les) es un recthngulo con las esquinas redondeadas. De
Capitulo 5. Al ingeniero del sistema se le presenta la ahi que SCCT se represente en la regi6n de proceso y
siguiente declaraci6n (algo confusa) de objetivos para control en el centro del DCS. Las flechas etiquetadas
el SCCT: mostradas en el DCS representan informaci6n (datos y
E l sistema SCCTdebe desarrollarse de manera que la cajas
control) que va desde el entorno exterior a1 sistema
que se mueven a lo largo de la cinta transportadora scan iden-
tificndas y ordenadas en uno de los seis contenedores al final
SCCT. La entidad externa lector del c6digo de barras
de la cinta. Las cajas p a s a h a travCs de una estaci6n clasifi- produce una entrada de informaci6n etiquetada como
cadora donde se i d e n ~ i f i c ~ iBarindose
n. en un nljmero de iden- codigo de barras. En esencia, el DCS sitlia a cualquier
tificacion impreso en un latcral de la ca,ja (se proporciona un sistema en el contexto de su entorno exterior.
lnterfaz
con el operador Peticiones de operador subsistema Respuestas, informes y visualizaciones del SCCT
de interfaz b
con el
operador
[~eticionde adquisicion del codigo de barras
Clasificacion de informes TI Estado del control de maniobras
Proceso y control Peticion Datos dc calizacion temporal

del SCCT de informe
4
9
Subsistema Nlimero
lector decodificador de piezas Subsistema
de codigo del codigo decontrol - Controlador
de barras de barras de maniobras de maniobras
I
4
I Datos I I Posicion
del codigo del contenedo~ 0rdenes de maniobra
Codigo de barras
de barras --
Subsistema c
de acceso lnforrnes de SCCT
a la base de datos Subsistema -
de configuracion
Velocidad 4 Clave
Subsistema de informes
del sensor de la cinta I ---+ i
de adquisicion Clasificacion \
Controlador
de datos de registros de las
-1
-
Estado BCR cornunicaciones
con la computadora
Estado de maniobra central
Estado del sensol Subsistema
~nttada
de tacometro de diagnosticOs Estado de cornunicaciones configuracion
de impulsos de 10s datos
Estado del lector
del informe
de codigo de barras
lnterfaz de adquisicion
de datos lnterfaz de diagnostic0 lnterfaz de salida
FIGURA 10.7. Diagrama de flujo de arquitectura para el SCCT (ampliado).
ejemplo, hardware, software, personas) tal y como los

ha asignado el ingeniero de sistemas.
DCS es un precursor del diagrama de fluio de datos, El diagrama inicial de flujo del sistema (DFS) se con-
e se estudia en el Copitulo 12. vierte en el nudo superior de una jerarquia de DFS. Cada
rectlingulo redondeado del DFS original puede expan-
El ingeniero de sistemas refina el diagrama de con- dirse en otra plantilla de arquitectura dedicacla exclusi-
texto de arquitectura estudiando con mris detalle el rec- vamente a ella. Este proceso se ilustra esquemliticarncnte
t6ngulo sombreado de la Figura 10.6. Se identifican 10s en la Figura 10.8. Cada uno de 10s DFS del sistema pue-
subsistemas principales que perrniten funcionar a1 sis- de usarse como punto de partida de subsiguientes fases
tema clasifi cador de cinta transportadora dentro del con- de ingenieria para el subsistema que se describe.
texto definido por el DCS. En la Figura 10.7 10s
subsisternas principales se defi nen en un diugr~umude
jl~!jodel sislrmu ( D F S )que se obtiene del DCS. El flu-
jo de informaci6n a travks de las regiones clel DCS se
usa para guiar al ingeniero de sistemas en el desarrollo
de DFS (un ccesquerna,) mris detallado del SCCT). El
3
Referencia Web
Para concretar el metada de HatleyPirbhoise puede acudir o
www.hasys.com/papers/hp-description.html
diagrama de f l ~ ~de
j o la arquitectura muestra 10s subsis-
temas principales y el flujo de las lineas de informaci6n Sc pueden especificar (delimitar) 10s subsisternas y
importantes (clatos y control). Ademris, el esquerna del la informaci6n que fluyen entre ellos para 10s subsi-
sistema divide el proceso clel subsistema en cada una guientes trabajos de ingenieria. Una descripcion narra-
de las cinco regiones de proceso estudiadas anterior- tiva de cada subsistema y una definici6n de todos 10s
mente. En este punto, cada uno de 10s subsisternas pue- datos que fluyen entre 10s subsisternas son elernenros
de contener uno o n16s elementos del sistema (por importantes de la Espc~c~ificcrc~ih
del Sis~mra.
FIGURA 10.8. Construccion de una jerarquia DFA.
Un sistema de alta tecnologia coniprende varios comprende una planificicncicin cle In e.wicnre,qi'n d e la itlfor-
ponentes: hardware, software, personas, bases de datos, tnac.iciti (PEI), un uncjlisis del Area do t y q o c i o ( A A N ) y
documentaci6n y procedimientos. La ingenieria de sis- un analisis especifico de aplicaci6n que de hecho for-
temas ayuda a traducir las necesidades del cliente en un man parte de la ingenieria del software.
modelo de sistenia que utiliza uno o m i s de estos com- La ingenieria de productos es un enfoque de la inge-
ponentes. nieria de sistemas que empieza con el an;ilisis del sis-
La ingenieria de sistemas comienza tomando una tema. El ingeniero de sistemas identifica las necesidades
ccvision global>>.Se analiza el dominio de negocio o del cliente, determina la viabilidad econ6mica y tkcni-
product0 para establecer todos 10s requisitos basicos. ca, y asigna funciones y rendimientos a1 software, hard-
El enfoque s e estrecha entonces a una ccvisi6n d e ware, personas y bases de datos; 10s componente claves
dominie>>, donde cada uno de 10s elementos del sis- de la ingenieria.
terna se analiza individualmente. Cada elemento es La ingenieria del sistema demanda una intensa
asignado a uno o m8s componentes de ingenieria que comunicaci6n entre el cliente y el ingeniero del siste-
son estudiados por la disciplina de ingenieria corres- ma. Esto se realiza a travCs de un conjunto de activi-
pondiente. dades bajo la denominaci6n de ingenieria de requisitos
La ingenieria de procesos de negocio es un enfoque -identificaci6n, andisis y negociaci611,especificaci611,
de la ingenieria de sistemas que se usa para definir arqui- modelizaci6n, validaci6n y gesti6n-.
tecturds que permitan a un negocio utlizar la informa- Una vez que 10s requisitos hayan sido aislados, el
cioii eficazmente. La intenci6n de la ingenieria de niodelado del sistema puede ser realizado, y las repre-
procesos de negocio es crear minuciosas arquitecturas sentaciones de 10s subsistemas principales pueden ser
de datos, una arquitectura de aplicaci6n y una infraes- desarrolladas. La tarea de la ingenieria del sistema fina-
tructura tecnol6gica que satisfaga las necesidades de la liza con la elaboraci6n de una Especificicnc.idti del Si.src.-
estrategia de negocio y 10s objetivos de cada rirea de ma -un documento que sirve de base para las tareas de
negocio. La ingenieria de procesos de negocio com- ingenieria que se realizarin posteriormente-.
ICRI921 Christel, M.G., y K C . Kang, ctlssuesin Requirernents [MAR901 Martin, J., Itformution Engineering: Book I 1 -
Elicitation)),Software Engineering Institute, CMU/SEI- Plannitrg und Anulysrs, Prentice Hall, 1990.
92-TR- 12 7, September 1992. [MOT921 Motamarri, S., <<SystemsModelling and Descrip-
[GRA69] Graham, R.M., en Proceedings 1969 NATO Con- tion)), Softwut~eEngitreer.ing Notes, vol. 17, n." 2, Abril
fer.encv on Softwurc~Engineering, 1969. 1992, pp. 57-63.
[GUT991 Guttnian, M., ccArchitectural Requirements for a ISOM971 Sornerville, I., y P. Sawyer, Re~lrrirumentsEngitwe-
Changing Business World)),R~sc~urr.11 Briefs jrotn Cutter ring, Wiley, 1997
Con.\ortirwr (un onlitre service), June 1 , 1999. [SPE93]Spewak, S., Enterprise Alrhitectrit-c Plutmitzg, QED
[HAR93] Hares. J.S., Itlformcrtion Engineeringfcv-the Advan- Publishing, 1993.
red Pructition~r.,Wiley, 1993, pp. 12-13. [THA97] Thayer, R.H., y M. Dorfnian, Softuwe Reqrrire-
[HAT871 Hatley, D.J., e I.A. Pirbhai, Str.utegics,forReul-Time ments Engineering, 2." ed., IEEE Computer Society Press,
Systetn Specification, Dorset House, 1987. 1997.
CAPfTULO 10 I N G E N I E R ~ AD E S I S T E M A S
10.1. Encuentre tantos sinonimos como pueda de la palabra 10.10. Investigue las tCcnicas de contabilidad que se emplean
ccsistema>>.iBuena suerte! para un analisis detallado de coste/beneficio de un sistema
10.2. Construya una descripci6n en estructura jerirquica para que requiera algo de fabricacion y montaje de hardware.
un sistema, producto o servicio que le sea familiar. El plantea- Intente escribir un libro de directrices que pueda aplicar un
miento abarcari 10s elementos fundamentales del sistema (hard- gestor tCcnico.
ware, software, etc.) de una rama concreta de dicha estructura. 10.11. Desarrolle el diagrama de context0 DCS y el resto de
10.3. Seleccione un gran sistema o producto con el que estC diagramas de flujo de un sistema a su eleccidn (o definido por
familiarizado. Defina el conjunto de dominios que describen la su profesor).
vision global de 61. Describa el conjunto de elementos que com- 10.12. Escriba una descripcion de un modulo del sistema que
pongan uno o dos dominios. Para un elemento, identifique 10s pudiera estar contenido en la especificacion de diagrama de
componentes tCcnicos con 10s que hay que hacer ingenieria. arquitectura de uno o mis de 10s subsistemas definidos en 10s
10.4. Seleccione un gran sistema o producto con el que estC DFA desarrollados para el problema 10.1 1.
familiarizado. Establezca 10s supuestos, simplificaciones, limi- 10.13. Investigue documentacion sobre herramientas CASE
taciones, restricciones y preferencias que deberian haberse y escriba un breve documento describiendo como trabajan las
hecho para construir un modelo de sistema eficaz y realizable. herramientas de modelado y sirnulacion. Altemativa: Relina
10.5. La ingenieria de proceso de negocio requiere definir informacidn de dos o miis vendedores de CASE que suminis-
datos, arquitectura de aplicaciones, ademas de una infraes- tren herramientas de modelado y sirnulacion y valore las simi-
tructura tecnologica. Describa cada uno de estos tCrminos litudes y las diferencias.
mediante un ejemplo.
10.14. Basindose en la documentacion que le proporcione su
10.6. La planificacidn de la estrategia de la informacion empie- profesor, desarrolle una pequefia Especificacidn de Sistema
za por la definition de objetivos. Ponga ejemplos de cad0 uno para uno de 10s siguientes sistemas:
de 10s dominios de negocio.
a. Un sistema de edicion de video digital no lineal
10.7. Un ingeniero de sistemas puede venir de una de tres pro-
b. Un escAner digital para ordenador personal
cedencias: el desarrollo de sistemas, el cliente o una tercera
organizacion. Discuta 10s pros y contras de cada procedencia. c. Un sistema de correo electronico
Describa a un ingeniero de sistemas ccidealn. d. Un sistema para apuntarse a la universidad
10.8. Su profesor les repartira una descripcion de alto nivel de e. Un proveedor de acceso a internet
un sistema o producto.
f. Un sistema interactivo de reserva de hoteles
a. Desarrolle un conjunto de cuestiones que deberia pre-
guntar como ingeniero de sistemas. g. Un sistema de inter& local
b. Proponga a1 menos dos asignaciones diferentes para el Aseglirese de crear 10s modelos de arquitectura descritos en
sistema basandose en las respuestas de su profesor a la Seccidn 10.6
sus preguntas. 10.15. existe en caractensticas de un sistema que no se pue-
c. En clase, compare sus respuestas con las de sus com- dan establecer durante las actividades de ingenieria de siste-
paiieros. mas? Describa las caracteristicas, si existen, y explique por
quC se debe retrasar su consideration a fases posteriores de la
10.9. Desarrolle una lista de comprobacion para 10s atributos ingenieria.
a considerar cuando hay que evaluar la ccviabilidadr de un sis-
tema o producto. Estudie la interaction entre 10s atributos e 10.16. existe en situaciones en las que se pueda abreviar o eli-
intente proporcionar un mCtodo para puntuar cada uno de minar completamente la especificacicin formal del sistema?
manera que se obtenga una ccpuntuacion de viabilidad,,. Expliquelo.
Se han publicado relativamente pocos libros sobre inge- ring Guidebook, CRC Press, 1996), Wymore (Model-Based
nieria de sistemas en 10s filtimos aiios. Entre ellos desta- Systems Engineering, CRC Press, 1993), Lacy (System Engi-
camos: neering Management, McGraw-Hill, 1992), Aslaksen y Bel-
Blanchard, B.S., System Engineering Management, 2.a ed., cher (Systems Engineering, Prentice-Hall,l992), Athey
Wiley, 1997. (Systematic Systems Approach, Prentice-Hall, 1982), y Blan-
Rechtin, E., y M.W. Maier, The Art of Systems Architec- chard y Fabrycky (Systems Engineering and Analysis, Pren-
ting, CRC Press, 1996. tice-Hall, 1981) presentan el proceso de la ingenieria del
Weiss, D., et al., Sofhzare Product-Line Engineering, Addi- sistema (con un Cnfasis diferente de la ingenieria) y ofrecen
son-Wesley, 1999. una valiosa guia.
Libros como 10s de Armstrong y Sage (Intoduction to Sys- En 10s liltimos aiios, 10s textos de ingenieria de la infor-
tems Engineering, Wiley, 1997), Martin (Systems Enginee- macion han sido reemplazados por libros que se centran en
la ingenieria de proceso de negocio. Scheer (Business Pro- ware Requirements Engineering, IEEE Computer Society
cess Engineering: Reference Models for Industrial Enterpri- Press, 1990) presenta un planteamiento de estkndares y direc-
ses, Springer-Verlag, 1998) describe rnCtodos de rnodelado trices para el trabajo de anklisis.
de procesos de negocio para ernpresas con arnplios sisternas Para aquellos lectores involucrados activarnente en el tra-
de informacion. Lozinsky (Enterprise-Wide Sofiware Solu- bajo de sisternas o interesados en un tratarniento mas sofisti-
tions: Integration Strategies and Practices, Addison-Wesley, cado sobre el terna. se propone 10s libros de Gerald Weinberg's
1998) plantea el uso de paquetes software corno una soluci6n (An Introduction to General System Thinking, Wiley- Inters-
que permita a una cornpafiia rnigrar de 10s sisternas hereda- cience, 1976, y On the Design of Stable Systems, Wilwy-
dos a procesos de negocio modernos. Martin (Information Interscience, 1979) permiten una excelente discusion sobre
Engineering. 3 volurnenes, Prentice-Hall, 1989, 1990, 1991) el ccpensamiento general de sisternas>> que irnplicitamente Ile-
presenta un plantearniento cornprensivo sobre 10s topicos de va a un acercarniento general al anhlisis y disefio de sisternas.
la ingenieria de la inforrnacion. Libros corno 10s de Hares Libros mas recientes son 10s de Weinberg (General Princi-
[HAR93], Spewak [SPE93] y Flynn y Fragoso-Diaz (Infor- ples of Systems Design, Dorset House, 1998, y Rethinking
mation Modeling: An International Perspective. Prentice- systems Analysis and Design, Dorset House, 1988) continuan
Hall, 1996) tratan este terna con detalle. en la tradicion de su mas avanzado trabajo.
Davis y Yen (The Information system Consultant's Hand- Una amplia variacidn de fuentes de informacion sobre inge-
book: Systems Analysis and Design, CRC Press, 1998) pre- nieria de sisternas y elernentos relacionados estan disponibles
sentan una cobertura enciclopCdica de 10s resultados del en internet. Una lista actualizada de referencias a paginas web
analisis y disefio de sisternas en el dorninio de 10s sitemas de sobre ingenieria de sisternas, ingenieria de la inforrnacion,
inforrnacion. Un volurnen mas reciente de 10s misrnos auto- ingenieria de procesos de negocio e ingenieria de productos
res (Standards, Guidelines and Exanples: System and Soft- pueden ser encontradas en http://www.pressman5.com
TULO
L
A ingenieria de requisitos del software es un proceso de descubrimiento, refinamiento,
modelado y especificacicin. Se refinan en detalle 10s requisitos del sistema y el papel
asignado a1 software -inicialmente asignado por el ingeniero del sistema-. Se crean
modelos de 10s requisitos de datos, flujo de informaci6n y control, y del comportamiento ope-
rativo. Se analizan soluciones alternativas y el modelo completo del andlisis es creado. Donald
Reifer [RE1941 describe el proceso de ingenieria de requisitos del software en el siguiente
pdrrafo:
La ingeniesia de requisitos es el uso sisterndtico de psocedirnientos, tecnicas, lengu;ijes y hermrnientas para
obtenes con un coste seducido el andisis, docurnentaci6n, evoluci6n continua de las necesidades del usuasio
y la especificacicin clel cornportamiento externo de un sistema que satisfaga las necesidades del usu;isio. Tenp;i
cn cuenta que todas las disciplinas de la ingenieria son semejantes, la ingeniesia de requisitos no se guia pol
conductas esporidicas, aleatol-ias o pos modns pasajeras. si no que se debe basar en el uso sisterndtico de i~pso-
x irnaciones contr;istadas.
Tanto el desarrollador como el cliente tienen un papel activo en la ingenieria de requisito4

del software -un conjunto de actividades que qon denominadas undli.ris-. El cliente intenta
replantear un \i\tema confuso, a nivel de descripci6n de datos, funciones y comportamiento,
en detalles concrete\. El desarrollador actua como un interrogador, como consultor. como per-
sona que resuelve problemas y como negociador.
El atztilisis de 10s requisitos es una tarea de ingenieria informaci6n se le proporcionarh a1 sistema. Por ejem-
del software que cubre el hueco entre la definicibn del plo, el cliente desea un informe diario que indique quC
software a nivel sistema y el disefio del software (Fig. piezas se han tomado del inventario y cuhntas piezas
1 1.1). El anhlisis de requisitos permite a1 ingeniero de sirnilares quedan. El cliente indica que 10s encargados
sistemas especificar las caracteristicas operacionales del del inventario registrarin el nfimero de identificacibn de
software (funci61-1,datos y rendimientos), indica la inter- cada pieza cuando salga del inventario.
faz del software con otros elementos del sistema y esta-
blece las restricciones que debe cumplir el software.
/ Ingenieria
de sisternas
Gastamos mucho hempa -lo mayor porte
del tiernpo del poyectc- no implementando
o probando, sino intentando decidir qu8 construir.
lMan lawream
El andisis de requisitos del software puede dividir-

se en cinco Areas de esfuerzo: (1) reconocimiento del
problema, (2) evaluaci6n y sintesis, (3) modelado, (4)
especificacibn y (5) revisibn. Inicialmente, el analista
estudia la Especijicacibn del Sistema (si existe alguna)
y el Plan del Proyecto de Sojhvare. Es importante enten-
der el software en el contexto de un sistema y revisar el FIGURA 11.1. Analisis como puente entre la ingenieria
Gmbito del software que se emple6 para generar las esti- y el diseiio de software.
maciones de la planificacibn. A continuacibn, se debe
establecer la comunicaci6n para el anilisis de manera
que nos garantice un correct0 reconocimiento del pro-
blema. El objetivo del analista es el reconocimiento de
10s elementos bisicos del problema tal y como 10s per- Cuento con hocer una porte del diseno duronte el onilisis
cibe el cliente/usuario. de requisitos y una pope del an6lisis de requisitos durante
La evaluaci6n del problema y la sintesis de la soluci6n el diseiio.
es la siguiente hrea principal de esfuerzo en el anilisis. El
analista debe definir todos 10s objetos de datos obsewa- Una vez evaluados 10s problemas actuales y la infor-
bles externamente, evaluar el flujo y contenido de la informacion deseada (entradas y salidas), el analista empie-
macibn, definir y elaborar todas las funciones del software, za a sintetizar una o mis soluciones. Para empezar, se
entender el comportamiento del software en el contexto definen en detalle 10s datos, las funciones de tratamiento
de acontecimientos que afectan a1 sistema, establecer y el comportamiento del sistema. Una vez que se ha
las cawcteristicas de la interfaz del sistema y descubrir establecido esta informaci6n, se consideran las arqui-
restricciones adicionales del disefio. Cada una de estas tecturas bhsicas para la implementacibn. Un enfoque
tareas sirve para describir el problema de manera que se cliente/servidor pareceria apropiada, pero jest6 dentro
pueda sintetizar un enfoque o solucibn global. del imbito esbozado en el Plan del Software? Parece
Por ejemplo, un mayorista de recambios de auto- que seria necesario un sistema de gestibn de bases de
moviles necesita un sistema de control de inventario. El datos, pero, jest6 justificada la necesidad de asociaci6n
analista averigua que 10s problemas del sistema manual del usuario/cliente? El proceso de evaluaci6n y sintesis
que se emplea actualmente son: (1) incapacidad de obte- continua hasta que ambos, el analista y el cliente, s e
ner rhpidamente el estado de un componente; (2) dos o sienten seguros de que se puede especificar adecuada-
tres dias de media para actualizar un archivo a base de mente el software para posteriores fases de desarrollo.
tarjetas; (3) mliltiples brdenes repetidas para el mismo A lo largo de la evaluaci6n y sintesis de la soluci611,
vendedor debido a que no hay manera de asociar a 10s el enfoque primario del analista estj. en el ccquC>>y no
vendedores con 10s componentes, etc. Una vez que se en el cccbmou. ~ Q u C datos produce y consume el siste-
han identificado 10s problemas, el analista determina ma, quC funciones debe realizar el sistema, quC interfa-
quC informaci6n va a producir el nuevo sistema y quC ces se definen y quC restricciones son aplicables?'.
'Davis (DAV93l argumenta que 10s tkrminos ~ ~ q u yC (como))

)~ son
demasiado vagos. Puede leer su libro si desea encontrar un intere-
sante debate sobre el tema.
CAP~TULO
11 CONCEPTOS Y PRlNCIPlOS DEL ANALISIS
Durante la actividad de evaluaci6n y sintesis de la En el Capitulo 2, indicamos que puede no ser posi-
solucion, el analista crea modelos del sistema en un ble una especificaci6n detallada en esta etapa. El clien-
esfuerzo de entender mejor el flujo de datos y de control, te puede no estar seguro de lo que quiere. El
el tratamiento funcional y el comportamiento operativo desarrollador puede no estar seguro de que un enfoque
y el contenido de la informaci6n. El modelo siwe como especifico consiga apropiadamente el funcionamiento
fundamento para el diseiio del software y como base para y rendimiento adecuados. Por estas y otras muchas razo-
la creaci6n de una especificaci6n del software. nes, se puede llevar a cabo un enfoque alternativo del
anhlisis de requisitos, denominado creacih de prototi-
@ kCubl serb mi primer pos o prototipado. El prototipado se comenta m i s tar-
objetivo en esta etapa? de en este capitulo.
- - - --------
, 1-1.2 I D E N T I F I C A C ~ ~DE
N REQUISITOS PARA EL SOFTWARE --
Antes que 10s requisitos puedan ser analizados, mode- Estas preguntas ayudan a identificar todos 10s purti-
lados o especificados, deben ser recogidos a travCs de cipantes que tienen un inter& en el software a construir.
un proceso de obtenci6n. Un cliente tiene un problema Ademis, las preguntas identifican 10s beneficios medi-
que pretende sea resuelto con una soluci6n basada en bles en una implementaci6n correcta de posibles alter-
computadora. Un desarrollador responde a la solicitud nativas para un desarrollo normal del software.
de ayuda del cliente. La comunicaci6n ha empezado. El siguiente conjunto de preguntas permite a1 ana-
Pero como ya hemos seiialado, el camino de la comuni- lista obtener un mejor entendimiento del problema y a1
caci6n a1 entendimiento esth a menudo lleno de baches. cliente comentar sus opiniones sobre la soluci6n:
iC6m0 caracterizaria una ccbuenan salida (resultado)
11.2.1. Inicio del proceso generada para una buena solucion?
La tCcnica de obtenci6n de requisitos mis usada es Ile- LAquC tipo de problema(s) va dirigida esta soluci6n?
var a cabo una reunion o entrevista preliminar. La pri- iPuede mostrarme (o describirme) el entorno en que
mera reuni6n entre el ingeniero del software (el analista) se utilizarh la soluci6n?
y el cliente puede compararse con la primera cita entre iHay aspectos o restricciones especiales del rendi-
dos adolescentes. Nadie sabe quC decir o preguntar; 10s miento que afecten a la manera de enfocar la soluci6n?
dos estin preocupados de que lo que digan sea malen-
tendido; ambos piensan quC pasarri (10s dos pueden tener
expectativas radicalmente diferentes); 10s dos esthn dese-
ando que aquello ternline, pero, a1 mismo tiempo, ambos Reguntas doras y resp muchas
desean que la cita sea un Cxito.
El liltimo conjunto de preguntas se concentra en la

~ui4nhaceuno pregunto es un tanto par cinco eficacia de la reuni6n. Gauge y Weinberg [GAU89] las
minutos; quih na lo hace es tonto para siempre. denominan ccmeta-preguntaw y proponen la siguiente
Provarbio chino
lista (abreviada):
Sin embargo, hay que empezar la comunicaci6n. ~ E usted
s la persona adecuada para responder a estas
Gause y Weinberg [GAU89] sugieren que el analista preguntas? ~ S Urespuestas
S son ccoficiales>>?
empiece preguntando cuestiones de contexto libre. Es iEstoy preguntando demasiado?
decir, un conjunto de preguntas que Ilevarin a un enten- iHay alguien m6s que pueda proporcionar informa-
dimiento bisico del problema, quC soluci6n busca, la
ci6n adicional?
naturalem de la soluci6n que se desea y la efectividad
del primer encuentro. El primer conjunto de cuestiones iHay algo m i s que deberia preguntarle?
de contexto libre se enfoca sobre el cliente, 10s objeti-
vos generales y 10s beneficios esperados. Por ejemplo,
el analista podria preguntar:
Si un sistemo o producto vo o servir poro muchos usuorios,
iQuiCn esth detrhs de la solicitud de este trabajo? 10s requisitos deberon ser obtenidos de un grupo
iQuiCn utilizari la solucibn? representotivode usuorios. Si s6lo uno persono define
~ C U seri
A el beneficio econ6mico del Cxito de una rodos 10s requisitos, el riesgo de oceptocidn ser6 olto.
solucibn? Estas preguntas (y otras) ayudarhn a ccromper el hie-
&Hay alguna otra alternativa para la soluci6n que lon e iniciar la comunicaci6n tan esencial para el Cxito
necesita? del anhlisis. Pero el formato de reuni6n tipo ccpregunta
I N G E N I E R I A DEL SOFTWARE. U N E N F O Q U E PRACTICO
y respuesta,, no es un enfoque que haya tenido mucho lo suficientemente informal como para animar el libre
Cxito. De hecho, esta sesi6n de preguntas y respuestas flujo de ideas.
deberia emplearse solamente en el primer encuentro y un cccoordinador>>(que puede ser un cliente, un desa-
sustituirse despuCs por una modalidad que combine ele- rrollador o un tercero) que controle la reuni6n.
mentos de resoluci6n del problema, negociaci6n y espe- se usa un ccmecanismo de definici6nn (que puede ser
cificaci6n. En la siguiente secci6n se presenta un enfoque hojas de trabajo, grAficos, carteles o pizarras).
a reuniones de este tipo.
el objetivo es identificar el problema, proponer ele-
mentos de soluci6n, negociar diferentes enfoques y
11.2.2. Tecnicas para facilitar las especificacio- especificar un conjunto preliminar de requisitos de
nes de una aplicacidn la soluci6n en una atn16sfera que permita alcanzar el
Los clientes y 10s ingenieros del software a menudo tie- objetivo.
nen una mentalidad inconsciente de ccnosotros y ellos>>.
En vez de trabajar como un equipo para identificar y refi-
'9
iQu6 diferendas eristen
entre una reunion TFEA
nar 10s requisitos, cada uno define por derecho su propio y una reunion ordinaria?
ccterritorio>>y se comunica a travb de una serie de memo-
randos, papeles de posiciones formales, documentos y Para coniprender mejor el flujo de acontecimientos
sesiones de preguntas y respueslas. La historia ha demos- tal y como ocurren en una reunion TFEA, presentamos
trado que este mktodo no funciona muy bien. Abundan un pequeiio escenario que esboza la secuencia de acon-
lo.; malentendidos, se omite informaci6n importante y tecimientos que llevan a la reunion, 10s que ocurren en
nunca se establcce una buena relaci6n de trabajo. la reunion y 10s que la siguen.
Referencia web/ ' los hechos no deion de existir por ignorarlos.

Aldous Huxley
Uno oproximacidn o FAST es llarnada ((Diseiio tomfin de
oplicociones)) (JAD). Un detollado estudio de JAD puede
encontrorse en En las reuniones iniciales entre el desarrollador y el
www.bee.net/bhrebird/jaddoc.htm cliente (Secci6n 1 1.2.1) se dan preguntas y respuestas
bisicas que ayudan a establecer el 6mbito dcl problema
Con estos problemas en mente es por lo que algunos y la percepci6n global de una soluci6n. Fuera cle estas
investigiidores independientes han desarrollado un enfo- reuniones iniciales, el cliente y el desarrollador escri-
clue orientatlo a1 ecluipo para la reuni6n de requisitos ben una ccsolicitud de producto>>de una o dos priginas.
que se aplica tlurante las primeras fases del an6lisis y Se selecciona lugar, fecha y hora de reunion TFEA y se
espccificacion. Denominadas Tknicus put-trjocilitcrr elige un coordinador. Se invita a participar a represen-
lus e.~pecijiccrcionesde lo crplicocicin (TFEA), este enfo- tantes de ambas organizaciones; la del cliente y la de
que ec partidario de la creacion de un equipo conjunto desarrollo. Se distribuye la solicitud de product0 a los
de clientes y desarrollndores que trabajan juntos para asistentes antes de la fecha de reuni6n.
identificar el problema, proponer soluciones, negociar
diferentes enfoclues y especificar un conjunto prelimi-
niir de requisitos de la solucion [ZAH9O]. Hoy en dia,
las TFEA son empleadas de forma general por 10s sis- Antes de una reunibn FAST confecciona una lista de
temas de informaci6n, pero la tCcnica ofrece un poten- objetos, servicios, restricciones y criterios de rendimiento.
cia1 de mejora en aplicaciones de todo tipo.
Se han propuesto muchos enfoques diferentes de Mientras se revisa la solicitud dias antes de la reu-
TFEA~.Cada uno utiliza un escenario ligeramente dife- nibn, se picle a todos 10s asistentes que hagan un a I 'lsta
rente, pero todos aplican alguna variation en las siguien- de ohjetos que formen parte del entorno del sistema,
tes directrices blisicas: otros objetos que debe producir el sistema y objetos que
la reuni6n se celebra en un lugar neutral y acuden usa el sistema para desarrollar sus funciones. Ademlis,
tanto 10s clientes como 10s desarrolladores. se pide a todos 10s asistentes que hagan otra lista de ser-
se establecen normas de preparaci6n y de partici- vicios (procesos o funciones) que manipulan o interac-
paci6n. tcan con 10s objetos. Finalmente, se desarrollan tambikn
se sugiere una agenda lo suficientemente formal listas de restricciorres (por ejemplo, costes, taniafio,
como para cubrir todos 10s puntos importantes, pero peso) y criterios de rendimiento (por ejemplo, veloci-
Dos de 10s e n f o q ~ ~ emas

s populares d e TFEA son Desarrollo Con-
junlo d e Aplicaciones (IAD), desarrollado por IBM, y The METHOD,
desarrollado por Performance Resources, Inc., Falls Church, VA.
CAP~TULO
11 CONCEPTOS Y PRINCIPIOS DEL ANALISIS
dad, precision). Se informa a 10s asistentes que no se producto, pues todo el mundo deberia estar de acuer-
. espera que las listas Sean exhaustivas, per0 que si que do en que el desarrollo (o adquisicion) del producto
reflejen su punto de vista del sistema. esta justificada. Una vez que se ha conseguido el acuer-
Por ejemplo3,imaginese que a un equipo de trabajo do, cada participante presenta sus listas para su estu-
TFEA de una compafiia de productos para el consumi- dio. Las listas pueden exponerse en las paredes de la
dor se le ha dado la siguiente description del producto: habitation usando largas hojas de papel, pinchadas o
Nuestras investigaciones indican que el mercado de siste- pegadas, o escritas en una pizarra. Idealmente deberia
mas de seguridad para el hogar esta creciendo a un ritmo del poderse manejar separadamente cada entrada de las
40 por 100 anual. Nos gustaria entrar en este mercado cons- listas para poder combinarlas, borrarlas o afiadir otras.
truyendo un sistema de seguridad para el hogar basado en un En esta fase, esta estrictamente prohibido el debate o
microprocesador que proteja ylo reconozca varias situaciones
indeseables tales como irmpciones ilegales, fuego, inundacio-
las criticas.
nes y otras. El producto, provisionalmente llamado HogarSe-
guro, utilizara 10s sensores adecuados para detectar cada
situacion, puede programarse por el propietario del hogar y lla-
mara automaticamente a una agencia de vigilancia cuando se Evita el impulso de cortor lo idea de un cliente
detecte alguna de estas situaciones. por sdemasiado castosa)) o ((poco practice)).
l a idea es negaciar algo que sea oceptoble para tadas.
En realidad, se proporcionaria considerablemente mas Es decir, debes tener una mente obierto.
informacion en esta fase. Pero incluso con informacih
adicional, habria ambigiiedades presentes, existiran omi- Una vez que se han presentado las listas individua-
siones probablemente y podrian ocunir errores. Por aho- les sobre un tema, el grupo crea una lista combinada.
ra, la ccdescripci6n de producto>>anterior bastarh. La lista combinada elimina las entradas redundantes y
El equipo TFEA esth compuesto por representantes de aiiade las ideas nuevas que se les ocurran durante la pre-
marketing, ingenieria del software y del hardware, y de la sentacion, per0 no se elimina nada mhs. Cuando se han
fabricacion tarnbiCn participara un coordinador extemo. creado las listas combinadas de todos 10s temas, sigue
el estudio -moderado por el coordinador-. La lista
combinada es ordenada, ampliada o redactada de nue-
vo para reflejar apropiadamente el producto o sistema
que se va a desarrollar. El objetivo es desarrollar una
10s objetos deben ser monipulodos por servicios y deben lista de consenso por cada tema (objetos, semicios, res-
((contemplor)) 111s restricciones y rendimientos definidos tricciones y rendimiento). DespuCs estas listas se ponen
por el equipo FAST.
aparte para utilizarlas posteriormente.
Todos 10s componentes del equipo TFEA desarrollan Una vez que se han completado las listas de con-
las listas descritas anteriormente. Los objetos descritos senso, el equipo se divide en subequipos; cada uno tra-
para HogarSeguro podrian incluir detectores de humo, baja para desarrollar una mini-especificacion de una o
sensores de ventanas y puertas, detectores de movimien- mas entradas de cada lista4. La mini-especificacion es
tos, una alarma, un acontecimiento (se ha activado un una elaboration de la palabra o frase contenida en una
sensor), un panel de control, una pantalla, n6meros lista. Por ejemplo, la mini-especificacion del objeto
de telkfono, una llamada de telCfono, etc. La lista de panel de control de HogarSeguro podna ser: montado
semicios podria incluir la instalacion de la alarma, vigi- en la pared; tamafio aproximado 23 * 13 centimetros;
lancia de 10s sensores, marcado de telCfono, programa- contiene el teclado esthndar de 12 teclas y teclas espe-
cion del panel de control y lectura de la pantalla (fijese ciales; contiene una pantalla LCD de la forma mostra-
que 10s servici0.s act6an sobre 10s objetos). De igual da en el bosquejo (no presentado aqui); toda la
manera, todos 10s asistentes TFEA desarrollarhn una lis- interacci6n del cliente se hace a travCs de las teclas usa-
ta de restricciones (por ejemplo, el sistema debe tener das para activar o desactivar el sistema; software para
un coste de fabricacion de menos de £80, debe tener proporcionar una directriz de empleo, recordatorios,
una ccinterfaz amigable,, con el usuario y debe conectar etc., conectado a todos 10s sensores.
directamente con una linea telefonica esthndar) y de cri- Cada subequipo presenta entonces sus mini-especi-
terios de rendimiento (por ejemplo, un acontecimiento ficaciones a todos 10s asistentes TFEA para estudiarlas.
detectado por un sensor debe reconocerse en un segun- Se realizan nuevos afiadidos, eliminaciones y se sigue
do; se deberia implementar un esquema de prioridad de elaborando. En algunos casos, el desarrollo de algunas
acontecimientos). mini-especificaciones descubrirh nuevos objetos, ser-
Cuando empieza la reunion TFEA, el primer tema vicios, restricciones o requisitos de rendimiento que se
de estudio es la necesidad y justification del nuevo aiiadirdn a las listas originales. Durante todos 10s estu-
' Este ejemplo (con extensiones y variaciones) se empleara para ilus- Una alternativa puede ser la creacion de casos de uso. Ver Seccion
trar metodos importantes de ingenieria del software en muchos de 1 1.2.4 para
mas detalles.
10s capitulos siguientes. Como ejercicio, seria ~itilque realizara su
propia reunion TFEA y desarrollara un conjunto de listas.
~ N G E N ~ E RDEL
dios, el equipo sacara a relucir aspectos que no podran

resolverse durante la reunion. Se harh una lista de estas
ideas para tratarlas mas adelante. Todos querernos implernentar rnuchos requisitos
oposionontes, pero debernos ser cuidodosos. Podernos
concretor ccrequisitosinitiles)), o conduck o requisitos
innovodores que conducen o un producto dernosiodo
fuhrrista.
En realidad, el DFC se extiende a todo el proceso de

Una vez que se han completado las mini-especifica- ingenieria [AKA90]. Sin embargo, muchos conceptos
ciones, cada asistente de la TFEA hace una lista de crite- DFC son aplicables a1 problema de la comunicaci6n con
rios de validacidn del producto/sistema y presenta su lista el cliente a que se enfrenta un ingeniero del software duran-
a1 equipo. Se crea asi una lista de consenso de criterios de te las primeras fases del analisis de requisitos. Presenta-
validaci6n. Finalmente, uno o mas participantes (o algfin mos una visi6n general s610 de estos conceptos (adaptados
tercero) es asignado para escribir el borrador entero de a1 software de computadora) en 10s phafos siguientes.
especificaci6n con todo lo expuesto en la reuni6n TFEA. En las reuniones con el cliente el despliegue de fun-
TFEA no es la panacea para 10s problemas que se cidn se emplea para determinar el valor de cada fun-
encuentran en las primeras reuniones de requisitos, pero ci6n requerida para el sistema. El despliegue de
el enfoque de equipo proporciona las ventajas de muchos informacidn identifica tanto 10s objetos de datos como
puntos de vista, estudio y refinamiento instanthneo y un 10s acontecimientos que el sistema debe producir y
paso adelante hacia el desarrollo de una especificaci6n. consumir. Estos estan unidos a las funciones. Final-
mente, el despliegue de tareas examina el comporta-
11.2.3. Despliegue de la funci6n de calidad miento del sistema o producto dentro del context0 de
su entorno. El andisis de valor es llevado a cab0 para
El despliegue de la funcidn calidad (DFC) es una tCc- determinar la prioridad relativa de requisitos determi-
nica de gesti6n de calidad que traduce las necesidades nada durante cada uno de 10s tres despliegues men-
del cliente en requisitos tCcnicos del software. Origi- cionados anteriormente.
nalmente desarrollado en Jap6n y usado por primera vez
en Kobe Shipyard of Mitsubishi Heavy Industries, Ltd.
A primeros de 10s aAos 70, DFC ccse concentra en maxi-
mizar la satisfacci6n del cliente>>[ZUL92]. Para con-
seguirlo, DFC hace Cnfasis en entender lo que resulta
Referencia web/ '-
El lnsiituto DFC es uno excelente fuente de informocion:
valioso para el cliente y despuCs desplegar estos valo- www.qfdi.org
res a lo largo del proceso de ingenieria. DFC identifica
tres tipos de requisitos [ZUL92]: El DFC utiliza observaciones y entrevistas con el clien-
te, emplea encuestas y examina datos historicos (por ejem-
plo, informes de problemas) como datos de base para la
actividad de recogida de requisitos. Estos datos se tradu-
DFC define 10s requisitos orientodos o moximizor cen despuCs en una tabla de requisitos 4enominada tabla
lo saiidoccibn del cliente. de opini6n del cliente- que se revisa con el cliente. Enton-
ces se usa una variedad de diagramas, mauices y mCto-
Requisitos nornlales.Se declaran objetivos y metas para un dos de evaluaci6n para extraer 10s requisitos esperados e
producto o sistema durante las reuniones con el cliente. Si estos intentar obtener requisitos innovadores [BOS91].
requisitos e s t h presentes, el cliente quedari satisfecho. Ejem-
plos de requisitos normales podnan ser peticiones de tipos de
presentaci6n grafica, funciones especificas del sistema y nive- 11.2.4. Casos de uso
les definidos de rendimiento. Una vez recopilados 10s requisitos, bien por reunio-
Requisitos esperados. Estos requisitos son implicitos a1 nes informales, TFEA o DFC, el ingeniero del software
producto o sistema y pueden ser tan fundamentales que el (analista) puede crear un conjunto de escenarios que
cliente no 10s declara explicitamente. Su ausencia sena moti- identifiquen una linea de utilizaci6n para el sistema que
vo de una insatisfaccih significativa. Ejemplos de requisi-
tos esperados son: facilidad de interaction hombre-miquina,
va a ser constmido. Los escenarios, algunas veces lla-
buen funcionamiento y fiabilidad general, y facilidad de ins- mados casos de uso [JAC92], facilitan una descripci6n
talacion del software. de c6mo el sistema se usara.
Requisitos innovadores. Estas caracteristicas van m k all6
de las expectativas del cliente y suelen ser muy satisfactorias.
Por ejemplo, se pide un software procesador de textos con las
caracteristicas est6ndar. El producto entregado contiene cier-
tas capacidades de diseiio de pigina que resultan muy validas Un coso de uso es un escenorio que describe c6mo
y que no eran esperadas. el softwore vo a ser usado en uno determinodo situacib.
C A P h U L O 11 CONCEPTOS Y PRINCIPIOS DEL ANALISIS
Para crear un caso de uso, el analista debe primer0 '

a
. identificar 10s diferentes tipos de personas (o dispositi- %
vos) que utiliza el sistema o producto. Estos actores CLAVE
actualmente representan papeles que la gente (o dispo- 10s tosos de usos estbn definidos desde el punto de visto
sitivos) juegan como impulsores del sislema. Definido de un ottor. Un ottor es un p p e l que las personas
m8s formalmente, un actor es algo que conwnica con (usuorios) o dispositivos juegon tuondo interottionon
el sistema o producto y que es externo a1 sistema en si ton el software.
mismo. En general, un caso de uso es, simplemente, un tex-
Es importante indicar que un actor y un usuario no to escrito que describe el papel de un actor que interac-
son la misma cosa. Un usuario normal puede jugar un tua con el acontecer del sistema.
numero de papeles diferentes cuando utiliza un sistema, Volviendo a 10s requisitos bisicos de HogarSq~rrz,
por lo tanto un actor representa una clase de entidades (Secci6n 11.2.2), podemos identificar tres actores: el
externas (a veces, per0 no siempre personas) que lleva propietario (el usuario), sensores (dispositivos vincula-
a cabo un papel. Como ejemplo, considerar un operador dos a1 sktema), y el subsislema de monitorizacibn y res-
de una mAquina (un usuario) que interactua con el orde- puegra (la estacibn central que monitoriza Ho'qarSe~rrro).
nador central para un elemento de Fdbricacion que con- Para 10s propositos de este ejemplo, consideremos uni-
tienc un numero de robots y m8quinas bajo control camente a1 actor propietario. El propietario interactua
numCrico. Despuks de una revision cuidadosa de 10s con el producto en un numero de diferentes caminos:
requisitos, el software del compulador central recluiere introduce una contrasefia para permitir cualquier
cuatro modelos diferentes (papeles) de interacci6n: mod0 interaccih
programacibn, mod0 prueba, mod0 monitorizaci6n y
pregunta acerca del estado de una zona de seguridad
modo investigacibn. Ademlis, se pueden definir cuatro
actores: programador, probador, supervisor e investiga- pregunta acerca del estado de un sensor
dor. En algunos casos, el operador de la m8quina puede presiona el bot6n de alarma en caso de emergencia
realizar todos 10s papeles. En otras ocasiones. diferen- activaldesactiva el sistema de seguridad
tes personas pueden jugar el papel de cada actor.
Referencia web/ '

Uno discusibn detollada de 10s cosos de usos, incluyendo
ejemplos, referencios y plantillos, se presenta en
members.dcom/acokhrm/ppers/OnUse(psesh
Cosos de us0 Un caso de uso para el sistetna de a c ~ i ~ ~ apersigue:

cih
Porque la obtenci6n de requisitos es una actividad El propietario 0 b s e ~ un
a prototipo del panel de con-
de evoluci6n, no todos los actores se identifican duran- trol de HogurSegurz, (Fig. 1 1.2) para determinar si
te la primera ileraci6n. Es posible identificar actores ini- el sistema esti preparado para la entrada. Si el sis-
ciales [JAC93] durante la primera iteraci6n y actores tema no estli preparado, el propietario debe fisica-
secundarios cuando mlis se aprende del sistema. Los mente cerrar ventanaslpuertas para que se encienda
actores iniciales interactuan para conseguir funciones el indicador de preparado. (El indicador no prepa-
del sistema y derivar el beneficio deseado del sistema. rado implica que el sensor esti abierto, por ejemplo,
Ellos trabajan directa y frecuentemente con el software. que la puerta o ventana esti abierta.)
Los actores secundarios existen para dar soporte a1 sis-
temn que 10s actores iniciales har, dado forma con su away
trabajo. (21
Una vez que se han idenlificado 10s actores, se pue-
den desarrollar 10s casos de uso. El caso de uso descri-
be la manera en que 10s actores interactuan con el
instant
bypass
3
instant code chime
sistema. Jacobson [JAC93] sugiere un numero de pre- not readv
guntas que deberlin responderse por el caso de uso:
C7) C8) 19)
armed power
~ C U A Ison
~ S las principales tareas o funciones que
serin realizadas por el actor?
lndicsdores
en inal&
0 0 panic
LCuil es el sistema de informaci6n que el actor
adquiere, produce o cambia?
FIGURA 11.2. Panel de control de Hogar Seguro.
~QuC actor informar2 a1 sistema de 10s cambios en
el entorno externo? 2. El propietario utiliza el teclado para introducir una
~QuC informaci6n necesita el actor sobre el sistema? contrasefia de cuatro digitos. La contrasefia es com-
parada con la contrasefia valida almacenada en el sis- indican que ocurrira 30 segundos despues de pulsar la
. tema. Si la contrasefia es erronea, el panel de control tecla stay o away. Esta informaci6n puede aiiadirse a1
emitira un sonido y se restaurar6 para incorporar una caso de uso.
nueva entrada. Los casos de uso describen escenarios que ser6n per-
3. El propietario selecciona y pulsa stay o away (ver cibidos de distinta forma por distintos actores. Wyder
Fig. 11.2) para activar el sistema. Stay activa sola- [WYD96] indica que la calidad de la funci6n desplegada
mente sensores perimetrales (cuando detectan movi- puede ser usada para desanollar un amplio valor de prio-
miento intemo se desactivan). Away activa todos 10s ridades para cada caso de uso. Para acabar, 10s casos de
sensores. uso son evaluados desde el punto de vista de todos 10s
actores definidos para el sistema. Se asigna un valor de
4. Cuando ocurre una activation, una luz de alarma prioridad a cada caso de uso (por ejemplo, un valor de 1
puede ser obsewada por el propietario. a 10) para cada acto15. Se calcula una prioridad, indican-
Cada caso de uso facilita un escenario sin ambi- do la importancia percibida de cada caso de uso.
giiedad en la interacci6n entre el actor y el software. Cuando un modelo de proceso iterativo es usado por
Esto puede usarse para especificar requisitos de tiem- la ingenieria del software orientado a objetos, las prio-
po u otras restricciones del escenario. Por ejemplo, en ridades pueden influir en quC funcionalidad del sistema
el caso de uso referido anteriormente, 10s requisitos sera entregada primero.
Durante las dos pasadas decadas, se han desarrollado reducir la complejidad. Son necesarias las visiones esen-
un gran nlimero de mitodos de modelado. Los inves- ciales y de implementation del software para acomo-
tigadores han identificado 10s problemas del analisis y dar las restricciones logicas impuestas por 10s requisitos
sus causas y han desarrollado varias notaciones de del procesamiento y las restricciones fisicas impuestas
modelado y sus correspondientes conjuntos de heuris- por otros elementos del sistema.
ticas para solucionarlos. Cada metodo de anilisis tie- Ademas de 10s principios operativos de anaisis men-
ne su punto de vista. Sin embargo, todos 10s metodos cionados anteriormente, Davis [DAV95a] sugiere un
de analisis se relacionan por un conjunto de principios conjunto6 de principios directrices para la <<ingenieria
operativos: de requisitos,,:
1. Debe representarse y entenderse el dominio de infor- Entender el problema antes de empezar a crear el
maci6n de un problema. modelo de andisis. Hay tendencia a precipitarse en
2. Deben definirse las funciones que debe realizar el busca de una soluci6n, incluso antes de entender el
software. problema. ~ E s ~ lleva
o a menudo a un elegante soft-
3. Debe representarse el comportamiento del software ware para el problema equivocado!
(como consecuencia de acontecimientos extemos). Desarrollar prototipos que permitan a1 usuario
4. Deben dividirse 10s modelos que representan infor- entender cdmo serci la interacci6n hombre-mdquina.
macidn, funci6n y comportamiento de manera que Como el concept0 de calidad del software se basa a
se descubran 10s detalles por capas (o jerirquica- menudo en la opini6n sobre la ccamigabilidad,, de la
mente). interfaz, el desarrollo de prototipos (y la iteraci6n
que se produce) es altamente recomendable.
5. El proceso de anilisis deberia ir desde la informa-
Registrar el origen y la raz6n de cada requisito. Este
ci6n esencial hasta el detalle de la implementaci6n.
es el primer paso para establecer un seguimiento
i C ~ 6 l e sson 10s prindpios hasta el cliente.
subyocentes que guian el Usar mdtiples planteamientos de requisitos. La cons-
trabaio de analisis? trucci6n de modelos de datos, funcionales y de com-
Aplicando estos principios, el analista se aproxima portamiento, le proporcionan a1 ingeniero del
a1 problema sistemiticamente. Se examina el dominio software tres puntos de vista diferentes. Esto reduce
de informaci6n de manera que pueda entenderse com- la probabilidad de que se olvide algo y aumenta la
pletamente la funci6n. Se emplean modelos para poder probabilidad de reconocer la falta de consistencia.
comunicar de forma compacta las caracten'sticas de la Darprioridad a 10s requisitos. Las fechas ajustadas
hnci6n y su comportamiento. Se aplica la partici6n para de entrega pueden impedir la implementaci6n de
Lo ideal e s que la evaluacion sea realizada por funciones indi- Aqui se menciona solo un pequeiio subconjunto de 10s principios
viduales de la organizacion o negocio representadas por un actor. de ingenieria de requisitos de Davis. Para obtener mas informacion.
vease [DAV95a].
C A P ~ T U L O11 CONCEPTOS Y PRINCIPIOS DEL ANALISIS
todos 10s requisitos del software. Si se aplica un un modelo de datos. Este dominio contiene tres visio-
modelo de proceso incremental (Capitulo 2), se deben nes diferentes de 10s datos y del control a medida que
identificar 10s requisitos que se van a entregar en la se procesa cada uno en un programa de computadora:
primera entrega. (1) contenido de la informacion y relaciones, (2) flujo
Trabajar para eliminar la ambigiiedad. Como la de la informacion y (3) estructura de la informacion.
mayoria de 10s requisitos estan descritos en un len- Para entender completamente el dominio de la infor-
guaje natural, abunda la oportunidad de ambigueda- macion, deberia estudiarse cada una de estas visiones.
des. El empleo de revisiones tCcnicas formales es
una manera de descubrir y eliminar la ambiguedad.
Poro comenzor o comprender el dominio de informocian,

lo primero pregunto que debe ser reolizodo es:
((2Que informocibn de solido generora el sisterno?))
El contenido de la informacidn representa 10s obje-

tos individuales de datos y de control que componen
alguna coleccion mayor de informaci6n a la que trans-
Un ingeniero del software que se aprenda estos prin- forma el software. Por ejemplo, el objeto datos cheque
cipios de memoria es muy probable que desarrolle una es una composicion de varios componentes de infor-
especificacion del software que proporcione un exce- maci6n importantes: el nombre del beneficiario, la can-
lente fundamento para el diseiio. tidad neta a pagar, el importe bruto, deducciones, etc.
Por tanto, el contenido de cheque es definido por 10s
atributos necesarios para crearlo. De forma similar, el
1 1.3.1. El dominio de la informacion contenido de un objeto de control denominado estado
Todas las aplicaciones software pueden denominarse del sistema podria definirse mediante una cadena de
colectivamente procesamiento de datos. Es interesan- bits. Cada bit representa un elemento diferente de infor-
te que este tCrmino contenga una clave para nuestro macion que indica si un dispositivo en particular esta
entendimiento de 10s requisitos del software. El soft- en linea o fuera de linea.
ware se construye para procesar datos, para transfor- Los objetos de datos y de control pueden relacio-
mar datos de una forma a otra, es decir, para aceptar narse con otros objetos de datos o de control. Por ejem-
una entrada de informacion, manipularla de alguna plo, el objeto de datos cheque tiene una o mas relaciones
manera y producir una salida de informacion. Esta con 10s objetos empleado, banco y otros. Durante el ana-
declaracion fundamental de objetivos es cierta, tanto lisis del dominio de la informacion, se deberian definir
si construimos software por lotes para un sistema de estas relaciones.
nominas, como si construimos software dedicado de E l j h j o de la informacidn representa como cambian
tiempo real para controlar el flujo de combustible de 10s datos y el control a medida que se mueven dentro
un motor de automovil. de un sistema. Como se muestra en la Figura 11.3,los
objetos de entrada se transforman para intercambiar
informacion (datos y/o control), hasta que se transfor-
man en informacion de salida. A lo largo de este cami-
El dominio de informocibn de un problemo ogrupan
no de transformacion (o caminos), se puede introducir
elementos de datos u objetos que contienen numeros,
informacion adicional de un almacCn de datos (por ejem-
texto, imageries audio, video o cuolquier combinoci6n plo, un archivo en disco o memoria intermedia). Las trans-
de ellos. formaciones que se aplican a 10s datos son funciones o
subfunciones que debe realizar un prograrna. Los datos y
Es importante recalcar, sin embargo, que el softwa- control que se mueven entre dos transformaciones (fun-
re tambiCn procesa sucesos. Un suceso representa algun ciones) definen la interfaz de cada funcion.
aspect0 de control del sistema y no es mas que un dato La estructura de la informacidn representa la orga-
binario (es encendido o apagado, verdadero o falso, esta nizacion interna de 10s elementos de datos o de con-
alli o no). Por ejemplo, un sensor de presion detecta la trol. iHay que organizar 10s elementos de datos o de
presi6n que excede de un valor seguro y envia una seiial control como una tabla de dimension n o como una
de alarma a1 software de vigilancia. La sefial de alarma estructura jerhquica en Brbol? Dentro del context0 de
es un suceso que controla el comportamiento del siste- la estructura, iqu6 informacion esta relacionada con
ma. Por tanto, 10s datos (numeros, caracteres, image- otra informacion? iEst6 contenida toda la informaci6n
nes, sonidos, etc.) y el control (acontecimientos)residen en una sola estructura o se van a utilizar varias? iC6m0
dentro del dominio de la informaci6n de un problema. se relaciona la informacion de una estructura con la de
El primer principio operativo de analisis requiere el otra? Estas y otras preguntas se responden mediante
examen del dominio de la informaci6n y la creaci6n de una valoracion de la estructura de la informacion.
Deberia resaltarse que la estructura de datos, un con- na rnanera. Un rnodelo de cornportarniento crea una repre-
cepto afin que se estudiara mis adelante en este libro, sentaci6n de 10s estados del software y 10s sucesos que cau-
se refiere a1 disefio e implementaci6n de la estructura san que carnbie de estado.
de la informaci6n. Los modelos creados durante el anilisis de requisi-
tos desempefian unos papeles muy importantes:
11.3.2. Modelado El modelo ayuda a1 analista a entender la informa-
ci6n, la funci6n y el comportamiento del sistema,
Los modelos se crean para entender mejor la entidad que haciendo por tanto mis facil y sistematica la tarea de
se va a construir. Cuando la entidad es algo fisico (un edi- analisis de requisitos.
ficio, un avion, una mhquina), podemos construir un
modelo idintico en forma, per0 mis pequefio. Sin embar- El modelo se convierte en el punto de mira para la
go, cuando la entidad que se va a construir es software, revisi6n y por tanto la clave para determinar si se ha
nuestro modelo debe tomar una forma diferente. Debe completado, su consistencia y la precisi6n de la espe-
ser capaz de modelar la informaci6n que transforma el cificacion.
software, las funciones (y subfunciones) que permiten El modelo se convierte en el fundamento para el
que ocurran las transformaciones y el comportamiento disefio, proporcionando a1 disefiador una represen-
del sistema cuando ocurren estas transformaciones. taci6n esencial del software que pueda trasladarse a1
El segundo y tercer principios operativos del anili- contexto de la implementaci6n.
sis requieren la construction de modelos de funci6n y
comportamiento. i Como usor 10s modelos
creados durante el trabajo
i Que tipos de modelos de analisis de requisitos?
debemos crear durante
Los mCtodos de analisis estudiados en 10s Capitulos
el analisis de requisitos?
12 y 2 1 son de hecho metodos de modelado. ~ u n ~ elu e
Modelos funcionales. El software transforma la infor- mktodo de modelado empleado es a menudo cuestion
rnaci6n y, para hacerlo, debe realizar a1 rnenos tres funcio- de preferencias personales (o de la organization), la acti-
nes genkricas: entrada, procesarniento y salida. Cuando se vidad de modelado es fundamental para un buen traba-
crean rnodelos funcionales de una aplicacibn, el ingeniero
del software se concentra en funciones especificas del pro-
jo de analisis.
blema. El rnodelo funcional ernpieza con un sencillo rnode-
lo a nivel de contexto (por ejernplo, el nornbre del software
que se va a construir). DespuCs de una serie de iteraciones,
se consiguen mas y mas detalles funcionales, hasta que se
A menudo 10s problemas son demasiado grandes o com-
consigue representar una rninuciosa definici6n de toda la fun- plejos para entenderlos globalmente. Por este motivo,
cionalidad del sisterna. tendemos a hacer una partici6n (dividir) de estos pro-
blemas en partes que puedan entenderse facilmente y
Datos
Objeto(s)
establecer las interacciones entre las partes de manera
y control que se pueda conseguir la funci6n global. El cuarto prin-
'de salida
cipio operativo del anilisis sugiere que se pueden par-
tir 10s dominios de la informacion, funcional y de
comportamiento.
Alrnacen
Lo descomposici6nes un proceso que resulto
de lo elabaracion de dotas, funtiones o comportamientas.
Puede ser realizada horizontal a veriicalmente.
FIGURA 11.3. Flujo y transforrnacion de la inforrnacion.
En esencia, la particidn descompone un problema en
Modelos de comportamiento. La rnayoria del software sus partes constitutivas.Conceptualmente,establecemos
responde a 10s acontecirnientos del rnundo exterior. Esta
caracten'stica estirnulo-respuesta forma la base del rnodelo una representacion jerarquica de la informaci6n o de la
del cornportamiento. Un prograrna de cornputadora siernpre funcion y despuCs partimos el elemento de orden supe-
esta en un estado, un rnodo de cornportarniento observable rior (I) exponiendo mas detalles cada vez a1 movernos
exteriormente (por ejernplo, esperando, calculando, irnpri- verticalmente en la jerarquia o (2) descomponiendo el
rniendo, haciendo cola) que cambia so10 cuando ocurre algun problema si nos movemos horizontalmente en la jerar-
suceso. Por ejernplo, el software permanecera en el estado quia. Para ilustrar estos enfoques de particibn, reconsi-
de espera hasta que (1) un reloj interno le indique que ha
pasado cierto interval0 de tiernpo, (2) un suceso extemo (por deremos el sistema de seguridad HogarSeguro descrito
ejernplo, un rnovirniento del rat6n) provoca una intempci6n, en la Secci6n 11.2.2. La asignaci6n de software para
o (3) un sisterna externo seiiala a1 software que actue de algu- HogarSeguro (obtenido como consecuencia de las acti-
C A P ~ T U L OI 1 CONCEPTOS Y PRINCIPIOS DEL ANALISIS
vidades de ingenieria del sistema y de las reuniones en el Capitulo 12) proporcionara una vision mas profun-
TFEA) puede establecerse en 10s parrafos siguientes: da de 10s requisitos del sistema. A medida que se parte el
El software de HogarSeguro permite a1 propietario con- sistema, se obtienen las interfaces entre las funciones. Los
figurar el sisterna de seguridad cuando se instala, vigila todos datos y elementos de control que se mueven a travCs de
10s sensores conectados a1 sisterna de seguridad e interactkt una interfaz deberian restringirse a las entradas necesa-
con el propietario a travts de un teclado y t e c h funciona- rias para realizar la funcion en cuestion y a las salidas
les del panel de control de HogarSeguro rnostrado en la Figu- requeridas por otras funciones o elementos del sistema.
ra 11.2.
Durante la instalacidn, el panel de control de HogarSegu- Sotfware de HogarSeguro
ro se ernplea para aprogramx* y configurar el sisterna.A cada
sensor se le asigna un nhrnero y un tipo, se prograrna una con-
traseiia para activar y desactivar el sisterna y se introducen el
(10s) n6rnero(s) de telCfono que se rnarcarh(n) cuando un sen- Configurar Monitorizar lnteractuar
sor detecte un suceso que haga saltar la alarma. sistema sensores con el usuario
Cuando un sensor detecta un acontecirniento,el software Particion horizontal
invoca una alarma sonora asociada a1 sisterna. DespuCs de un
retardo especificado por el propietario durante la configuracidn FIGURA 11.4. Particion horizontal de una funcion
del sisterna, el software rnxca un nhrnero de telCfono de una de Hogar Seguro.
ernpresa de seguridad y proporciona informaci6n sobre la direc-
cion. informando de la naturalem del acontecirniento detecta- 1 1.3.4. Visiones esenciales y de implementaci6n7
do. El nlirnero se volverfi a rnarcar cada 20 segundos hasta que
se obtenga la conexidn telefdnica. Una visidn esencial de 10s requisitos del software presenta
las funciones a conseguir y la informacion a procesar sin
Toda la interacc~oncon HogarSeguro es rnanejada por un tener en cuenta 10s detalles de la implementacion. Por
subsisterna de interaccidn con el usuario que lee la entrada de
informacidn proporcionada a travCs del teclado y las teclas fun- ejemplo, la vision esencial de la funcion de HogarSegu-
cionales, las pantallas que presentan rnensajes y el estado del ro leer el estado del sensor no tiene nada que ver con
sisterna en la pantalla LCD. La interaccidn con el teclado torna la forma fisica de 10s datos o el tip0 de sensor que se
la siguiente forma... emplea. De hecho, se podria argumentar que leer esta-
Los requisitos del software de HogarSeguro pueden do seria un nombre mas apropiado para esta funcion, ya
analizarse partiendo 10s dominios de informaci6n, fun- que ignora totalmente 10s detalles del mecanismo de
cional y de comportamiento del producto. Para ilus- entrada. Igualmente, un modelo de datos esencial del
trarlo, partiremos el dominio funcional del problema. elemento datos numero de telefono (implicado en la
La Figura 11.4 ilustra una descomposicibn horizontal funci6n marcar numero de telkfono) puede represen-
del software HogarSeguro. El problema se parte median- tarse en esta fase independientemente de la estructura
te la representacion de las funciones constitutivas del de 10s datos (si es que hay alguna) usada para imple-
software HogarSeguro, movikndose horizontalmente en mentar el elemento datos. Enfocando nuestra atenci6n
la jerarquia funcional. En el primer nivel de la jerarquia en la esencia del problema en las primeras fases del an&
aparecen tres funciones principales. lisis de requisitos, dejamos abiertas nuestras opciones
para especificar 10s detalles de implementacion duran-
te fases posteriores de especificacion de requisitos y
disefio del software.
Evita lo tentotion de troslodorte directomenre ol punto

de vista de implementocidn, entendiendo que lo esencio
Las subfunciones asociadas con una funcion principal del problemo es obvio. El especificor demosiodo rbpido
de HogarSeguro pueden exarninarse mediante la exposi- lo implementacidn en detalle reduce /us olternotivos
cion vertical detallada en la jerarquia, tal y como se ilus- e increments el riesgo.
tra en la Figura 11.5. MoviCndose hacia abajo a lo largo
de un camino, por ejemplo la funcion sensores de vigi- La visidn de implementacidn de 10s requisitos del
lancia, la particion se hace vertical para mostrar mayores software introduce la manifestation en el mundo real
niveles de detalle funcional. El enfoque de partici6n que de las funciones de procesamiento y las estructuras
hemos aplicado a las funciones de HogarSeguro puede de la informacion. En algunos casos, se desarrolla una
aplicarse tambiCn a1 dominio de la informacion y a1 de representacion fisica en la primera fase del disefio del
comportamiento. De hecho, la particion del flujo de la software. Sin embargo, la mayoria de 10s sistemas
informacion y del comportamiento del sistema (tratados basados en computadora se especifican de manera que
'Mucha gente utiliza terrninos vision (ilogica~~

y .fisica>)para referirse
al rnismo concepto.
se acomode a ciertos detalles de implementacidn. Un propuesta de todos 10s elementos del sistema. El mode-
dispositivo de entrada de informacidn a HogarSegu- lo esencial (de funcion o datos) es genCrico en el senti-
ro podria ser un sensor de perimetro (no un perro guar- do de que la realizacidn de la funcidn no se indica
dihn, un guardia de seguridad o una trampa). El sensor explicitamente.
detecta una entrada no autorizada a1 detectar una rup-
Sotfware de HogarSeguro
tura en un circuit0 electr6nico. Las caracteristicas
generales del sensor deberian tenerse en cuenta como
parte de la especificaci6n de 10s requisitos del soft-
ware. El analista debe reconocer las restricciones Configurar Monitorizar lnteractuar
impuestas por elementos predefinidos del sistema (el sistema sensores con el usuario
sensor) y considerar la visi6n de implementacih de
la funcidn y de la informaci6n cuando tal visidn es
apropiada. Rastreo Activar
Ya hemos comentado anteriormente que el anhlisis de sucesos las funciones
de 10s requisitos del software deberia concentrarse en del sensor de la alarma
quC es lo que debe hacer el software, en vez de c6mo
se implementara el procesamiento. Sin embargo, la
visidn de implementaci6n no deberia interpretarse nece- Leer ldentificar Activarl Activar Marcar
el estado el tip0 desactivar la alarma el numero
sariamente como una representacidn del cdmo. Mhs del sensor de suceso el sensor sonora de telefono
bien, un modelo de implementacidn representa el mod0
actual de operacibn, es decir, la asignaci6n existente o FIGURA 11.5. Particion vertical de la funcion de HogarSeguro.
El anhlisis hay que hacerlo independientemente del para- do prototipo deseclzable. Este prototipo sirve linicarnente
digma de ingenieria del software que se aplique. Sin como una basta demostracidn de 10s requisitos. DespuCs
embargo, la forma que toma este anhlisis van'a. En algu- se desecha y se hace una ingenieria del software con un
nos casos es posible aplicar 10s principios operativos paradigma diferente. Un enfoque abierto, denominado
del anhlisis y obtener un modelo de software del que se prototipo evolutivo, emplea el prototipo como primera
pueda desarrollar un disefio. En otras situaciones, se rea- parte de una actividad de anhlisis a la que seguirh el dise-
lizan recopilaciones de requisitos (por TFEA, DFC u fio y la construcci6n. El prototipo del software es la pri-
otras tkcnicas de cctormenta de ideas>>[JOR89]), se apli- mera evolucidn del sistema terminado.
can 10s principios del anhlisis y se construye un mode-
lo del software a fabricar denominado prototipo para L Que debemos mirar para
que lo valore el cliente y el desarrollador. Finalmente, determinar si un prototipo
hay circunstancias que requieren la construccidn de un es o no una alternativa viable?
prototipo a1 comienzo del anhlisis, ya que el modelo es Antes de poder elegir un enfoque abierto o cerrado,
el tinico medio a travCs del cual se pueden obtener efi- es necesario determinar si se puede crear un prototipo
cazmente 10s requisitos. El modelo evoluciona despuCs del sistema a construir. Se pueden definir varios facto-
hacia la producci6n del software. res candidatos a la creacidn de prototipos [BOA84]: Area
de aplicacion, complejidad, caracten'sticas del cliente y
del proyecto8.
probar
En general, cualquier aplicacidn que Cree panta-
son 10s que llas visuales dinhmicas, interactiie intensamente con
rativa actual. el ser humano, o demande algoritmos o procesamiento
de combinaciones que deban crearse de manera pro-
gresiva, es un buen candidato para la creaci6n de un
prototipo. Sin embargo, estas Areas de aplicacidn
11.4.1. Seleccion del enfoque de creation de deben ponderarse con la complejidad de la aplica-
prototipos ci6n. Si una aplicacidn candidata (una con las carac-
El paradigma de creaci6n de prototipos puede ser cerra- teristicas reseiiadas anteriormente) va a requerir el
do o abierto. El enfoque cerrado se denomina a menu- desarrollo de decenas de miles de lineas de c6digo
Se puede encontrar otro util estudio sobre 10s factores candidatos

de ~cuandohacer un prototipop) en [DAV95b].
antes de poder realizar cualquier funcion demostra- ware existentes. La combinaci6n de prototipos con la reuti-
ble, es muy probable ue sea demasiado compleja lizacion de componentes de programa s610 funcionarfi si se
desarrolla un sistema bibliotecario de manera que 10s com-
para crear un prototipJ. Si se puede hacer una par-
ponentes existentes estCn catalogados y puedan recogerse.
ticion a su complejidad, puede ser posible crear pro- Deberia resaltarse que se puede usar un product0 software
totipos de porciones del software. existente como prototipo de un ccnuevo y mejoradon pro-
Como el cliente debe interactuar con el prototipo ducto competitivo. En cierta manera, tsta es una forma de
en fases posteriores, es esencial que (1) se destinen reutilizaci6n en la creacidn de prototipos software.
recursos del cliente a la evaluacion y refinamiento del Especificaciones formales y entornos para prototipos.
prototipo, y (2) el cliente sea capaz de tomar decisio- Durante las pasadas dos decadas, se han desarrollado varios
nes inmediatas sobre 10s requisitos. Finalmente, la lenguajes formales de especificaci6n y herramientas como
naturaleza del proyecto de desarrollo tendra una gran sustitutos de las tkcnicas de especificaci6n con lenguaje natu-
influencia en la capacidad de crear un prototipo. ~Desea ral. Hoy en dia, 10s desarrolladores de estos lenguajes for-
y es capaz la gestion del proyecto de trabajar con el males estan desarrollando entomos interactivos que (1)
permitan a1 analista crear interactivamente una especifica-
mktodo del prototipo? ~Tenemosdisponibles herra- cion basada en lenguaje de un sistema o software, (2) invo-
mientas para la creacion de prototipos? ti en en expe- quen herramientas automaticas que traducen la especificaci6n
riencia 10s desarrolladores con 10s mCtodos de creacion basada en el lenguaje en codigo ejecutable, y (3) permitan
de prototipos? Andriole [AND921 sugiere un conjun- a1 cliente usar el c6digo ejecutable del prototipo para refinar
to de seis preguntas (Fig. 11.6) e indica unos conjun- 10s requisitos formales.
tos basicos de respuestas con su correspondiente tip0
de prototipo sugerido. Trabajo
preliminar
Prototipo Prototipo adicional
1 1.4.2. M6todos y herramientas para el desarrollo Pregunta desechable evolutivo requerido
de prototipos
iSe entiende el dominio
Para que la creation del prototipo de software sea efec- de la aplicacion? Si Si No
tivo, debe desarrollarse rapidamente para que el clien- iSe puede modelar
te pueda valorar 10s resultados y recomendar 10s carnbios el problema? Si Si No
oportunos. Para poder crear prototipos rapidos, hay dis- iEsta el cliente
ponibles tres clases genkricas de mktodos y herramien- suficientemente seguro
tas (por ejemplo, [AND92], [TAN89]): de 10s requisitos
basicos del sistema? Si/No Si/N o No
Tkcnicas de Cuarta Generacion. Las te'cnicas de cuar-
ta generacidn (T4G) comprenden una amplia gama de iEstan establecidos
10s requisitos
lenguajes de consulta e informes de bases de datos, gene- y son estables? No Si Si
radores de programas y aplicaciones y de otros lenguajes
no procedimentales de muy alto nivel. Como las tCcnicas iHay requisitos
T4G permiten a1 ingeniero del software generar cddigo eje- ambiguos? Si No Si
cutable rapidamente, son ideales para la creaci6n rfipida hay contradicciones
de prototipos. en 10s requisitos? Si No Si
Componentes de software reutilizables. Otro enfoque
para crear prototipos rfipidos es ensamblar, mfis que cons- FIGURA 11.6. Selection del enfoque apropiado de creacion
truir, el prototipo mediante un conjunto de componentes soft- de prototipo.
No hav duda de aue el modo de es~ecificaciontiene mucho

que ver con la calidad de la solucibn. Los ingenieros del
software que se han visto forzados a trabajar con especi-
ficacione; incompletas, inconsistentes o engaiiosas han En muchos cosos, no es razonuble pluntearse
experimentado la frustracibn y confusi6n que invariable- que la especificocidn deberh controstorse con todo.
mente provocan. La calidad, la fecha de entrega y el alcan- Debemos coptvror lo esencio de lo que el cliente solicito.
ce del software son las que sufren las consecuencias.
En algunos casos, se pueden construir rapidamente prototipos extre-

-
madamente compleios usando tecnicas de cuarta generation o com-
ponentes softwaie reutilizables.
193
1 1.5.1. Principios de la especificacion La informacidn contenida dentro de la especifrcaci6n debe-

ria estar escalonada. Las representaciones deberian revelar
La especificaci611, independientemente del mod0 como capas de informacion de rnanera que el lector se pueda mover
la realicemos, puede verse como un proceso de repre- en el nivel de detalle requerido. La nurneraci6n de pirrafos y
sentaci6n. Los requisitos se representan de manera que diagramas deberia indicar el nivel de detalle que se rnuestra. A
como fin ultimo lleven a1 Cxito de la implementacion veces, rnerece la pena presentar la rnisrna informacion con dife-
del software. A continuaci6n, se proponen algunos prin- rentes niveles de abstraction para ayudar a su cornprension.
cipios de especificacion adaptados del trabajo de Bal- Los diagramas J orras formas de notacidn deberian res-
zer y Goldman [BAL86]: rringirse en nimero y ser consistetites en slr empleo. Las nota-
ciones confusas o inconsistentes, tanto grificas como
Separar la funcionalidad de la implementaci6n. sirnbolicas, degradan la cornprension y fornentan errores.
Desarrollar un modelo del comportamiento deseado Las representaciones deben permitir revisiones. Segura-
de un sistema que comprenda datos y las respuestas rnente el contenido de una especificacion carnbiari. Idealmente,
funcionales de un sistema a varios estimulos del deberia haber herrarnientas CASE disponibles para actualizar
entomo. todas las representaciones afectadas por cada carnbio.
Establecer el contexto en que opera el software espe- Los investigadores han llevado a cab0 numerosos
cificando la manera en que otros componentes del estudios (por ejemplo, [HOL95], [CUR85]) sobre 10s
sistema interactuan con 61. factores humanos asociados con la especificacion. Pare-
Definir el entomo en que va a operar el sistema e indice haber pocas dudas de que la simbologia y la distri-
car como a n a coleccion de agentes altamente entre- bucion afectan a la comprensi6n. Sin embargo, 10s
lazados reaccionan a estimulos del entorno (cambios ingenieros del software parecen tener preferencias indi-
de objetos) producidos por esos agentew [BAL86]. viduales por especificaciones simbblicas y diagramas
Crear un modelo intuitive en vez de un diseiio o especificos. La familiaridad es a menudo la raiz de las
modelo de implementaci6n. preferencias de una persona, per0 otros factores m8s
Reconocer que la especificaci6n debe ser tolerante tangibles tales como la disposici6n espacial, formas
a un posible crecimiento si no es completa>>.Una f8cilmente reconocibles y el grado de formalidad dic-
especificacih es siempre un modelo -una abs- tan normalmente la eleccion individual.
traccibn- de alguna situacion real (o prevista) que
normalmente suele ser compleja. De ahi que sera 11.5.3. L a especificacion de 10s requisitos del
incompleta y existira a muchos niveles de detalle. software
Establecer el contenido y la estructura de una espe- La especificaci6n de 10s requisitos del software se pro-
cificaci6n de manera que acepte cambios. duce en la culminaci6n de la tarea de anhlisis. La fun-
Esta lista de principios basicos proporciona la base cion y rendimiento asignados a1 software como parte de
para representar 10s requisitos del software. Sin embar- la ingenieria de sistemas se retinan estableciendo una
go, 10s principios deben traducirse en realidad. En la completa descripci6n de la informacion, una descrip-
siguiente seccion examinamos un conjunto de directri- cion detallada de la funcion y del comportamiento, una
ces para la creaci6n de una especificaci6n de requisitos. indicaci6n de 10s requisitos del rendimiento y restric-
ciones del diseiio, criterios de validacih apropiados y
otros datos pertinentes a 10s requisitos.
Ya hemos visto que 10s requisitos del software pue-
den especificarse de varias maneras. Sin embargo, si
10s requisitos se muestran en papel o en un medio elec-
t r o n i c ~de representation (iy deberia ser casi siempre
asi!), merece la pena seguir este sencillo grupo de
directrices: Espetifitotion de Requisitos Softwore
~Cualesson Ias directrices

La Introduccidn a la especificacih de 10s requisitos
basicas fundamentales para del software establece las metas y objetivos del software,
representar 10s requisitos? describiCndolo en el contexto del sistema basado en com-
putadora. De hecho, la Introducci6n puede no ser m8s que
El fornmto de la representacidn y el contenido deberian el alcance del software en el documento de planificaci6n.
estar relaciotiados con el problema. Se puede desarrollar un La Descripcidn de la informaci6n proporciona una
esbozo general del contenido de la especificacion de los requi- detallada descripcion del problema que el software va
sitos del software. Sin embargo. las formas de representaci6n a resolver. Se documentan el contenido de la informa-
contenidas en la especificacih es probable que varien con el
irea de aplicacion. Por ejemplo, la especificaci6n de un siste- ci6n y sus relaciones, flujo y estructura. Se describen
ma autornkico de fabricacion utilizaria diferente sirnbologia, las interfaces hardware, software y humanas para 10s
diagramas y lenguaje que la especificacion de un cornpilador elementos extemos del sistema y para las funciones
de un lenguaje de prograrnaci6n. intemas del software.
CAP~TULO
11 CONCEPTOS Y PRINCIPIOS DEL ANALISIS
En la Descripcidn funcional se describen todas las dacidn. iC6m0 reconocemos el Cxito de una imple-
funciones requeridas para solucionar el problema. Se mentacibn? ~ Q u Cclases de pruebas se deben llevar a
proporciona una descripci6n del proceso de cada fun- cab0 para validar la funcibn, el rendimiento y las res-
ci6n; se establecen y justifican las restricciones del dise- tricciones? Ignoramos esta seccion porque para com-
fio; se establecen las caracteristicas del rendimiento; y pletarla se necesita una profunda comprension de 10s
se incluyen uno o mas diagramas para representar gri- requisitos del software, algo que a menudo no posee-
ficamente la estructura global del software y las intemos en esta fase. Sin embargo, la especificacion de 10s
racciones entre las funciones software y otros elementos criterios de validaci6n act6a como una revision impli-
del sistema. La secci6n de las especificaciones Des- cita de todos 10s demas requisitos. Es esencial invertir
cripcidn del comportamiento examina la operativa del tiempo y prestar atenci6n a esta secci6n. Finalmente, la
software como consecuencia de acontecimientos exter- especificaci6n incluye una Bibliografia y un Ape'ndice.
nos y caracteristicas de control generadas intemamente. En muchos casos la Especificacidn de requisitos del
software puede estar acompafiada de un prototipo eje-
cutable (que en algunos casos puede sustituir a la espe-
cificaci6n), un prototipo en papel o un Manual de
luondo desorrolles criterios de volidocibn, responde
usuario preliminar. El Manual de usuario preliminar
o 10 siguiente cuestibn: ((lorno reconocer si un sistemo
es correct0 si no lo muevo de mi meso?))
presenta a1 software como una caja negra. Es decir, se
pone gran Cnfasis en las entradas del usuario y las sali-
Probablemente la mis importante, e ironicamente, das (resultados) obtenidas. El manual puede sewir como
la secci6n mas a menudo ignorada de una especifica- una valiosa herramienta para descubrir problemas en la
ci6n de requisitos del software son 10s Criterios de vali- interfaz hombre-miquina.
La revision de la Especificacihn de requisitos del soft- a veces, normalmente, corrientemente, mucho, o prin-
ware (y/o prototipo) es llevada a cab0 tanto por el desa- cipalmente), el revisor sefialari la sentencia para su
rrollador del software como por el cliente. Como la clarificaci6n.
especificaci6n f o m a el fundamento para el disefio y las Una vez que se ha completado la revisibn, se fir-
subsiguientes actividades de la ingenieria del software, ma la especificaci6n de requisitos del software por el
se deberia poner extremo cuidado a1 realizar la revisi6n. cliente y el desarrollador. La especificaci6n se con-
viene en un <<contrato>> para el desarrollo del softwa-
re. Las peticiones de cambios en 10s requisitos una
vez que se ha finalizado la especificaci6n no se eli-
minarin, per0 el cliente debe saber que cada cambio
a posteriori significa una ampliaci6n del imbito del
software, y por tanto pueden aumentar 10s costes y
Requisitos Software prolongar 10s plazos de la planificaci6n temporal del
Revision de lo Espetifitatih proyecto.
Incluso con 10s mejores procedimientos de revisibn,
Inicialmente la revisi6n sc lleva a cab0 a nivel siempre persisten algunos problemas comunes de espe-
macrosc6pico. A este nivel, 10s revisores intentan ase- cificaci6n. La especificaci6n es dificil de <<probar>>
de
gurarse de que la especificacion sea completa, con- manera significativa, por lo que pueden pasar inadver-
sistente y correcta cuando la informaci6n general, tidas ciertas inconsistencias y omisiones. Durante la
funcional y de 10s dominios del comportamiento son revisibn, se pueden recomendar cambios a la especifi-
considerados. Asimismo, una exploration completa de caci6n. Puede ser extremadamente dificil valorar el
cada uno de estos dominios, la revisi6n profundiza en impact0 global de un cambio; es decir, jc6m0 afecta el
el detalle, examinando no solo las descripciones super- cambio en una funci6n a 10s requisitos de las demas?
ficiales, sino la via en la que 10s requisitos son expre- Los modemos entomos de ingenieria del software (Capi-
sados. Por ejemplo, cuando una especificaci6n contiene tulo 3 1) incorporan herramientas CASE desarrolladas
un cctCrmino vago>>(por ejemplo, algo, algunas veces, para ayudar a resolver estos problemas.
lNGEN1EFlfA DEL SOFTWARE. UN ENFOQUE PRACTICO
El analisis de requisitos es la primera fase tkcnica del En muchos casos, no es posible especificar completa-
proceso de ingenieria del software. En este punto se refi- mente un problema en una etapa tan temprana. La crea-
na la declaracion general del ambito del software en una ci6n de prototipos ofrece un enfoque alternativo que
especificacion concreta que se convierte en el funda- produce un modelo ejecutable del software en el que
mento de todas las actividades siguientes de la inge- se pueden refinar 10s requisitos. Se necesitan herra-
nieria del software. mientas especiales para poder realizar adecuadamente
El analisis debe enfocarse en 10s dominios de la la creacion de prototipos.
informacion, funcional y de comportamiento del pro- Como resultado del analisis, se desarrolla la Especi-
blema. Para entender mejor lo que se requiere, se crean ficacidn de requisitos del sofmare. La revision es esen-
modelos, 10s problemas sufren una particion y se desa- cia1 para asegurarse que el cliente y el desarrollador
rrollan representaciones que muestran la esencia de 10s tienen el mismo concept0 del sistema. Desgraciada-
requisitos y posteriormente 10s detalles de la implemente, incluso con 10s mejores metodos, la cuestion es
mentacion. que el problema sigue cambiando.
[AKA901Akao, Y. (de.), Quality Function Dep1oyment:Inte- [HOL95] Holtzblatt, K., y E. Camel (eds.), <<Requirements
grating Customer Requirements in Product Design (tra- Gathering: The Human Factor,,, un resultado especial de
ducido por G. Mazur), Productivity Press, Cambridge MA, CACM, vol. 38, n." 5, Mayo 1995.
1990
[JAC92] Jacobson, I., Object-Oriented Software Engineering,
[BAL86] Balzer, R., y N. Goodman, ccPrinciples of Good Spe- Addison-Wesley, 1992.
cification and their Implications for Specification Lan-
[JOR89] Jordan, P.W. et al., <<SoftwareStorming: Combining
guages,,, in Software Specification Techniques (Gehani
Rapid Prototyping and Knowledge Engineering,,, IEEE
and McGetrick, eds.), Addison-Wesley, 1986, pp. 25-39.
Computer, vol. 22, n." 5, Mayo 1989, pp. 39-50.
[BOA841 Boar, B., Application Prototyping, Wiley-lnters-
cience, 1984. [RE1941 Reifer, D.J., <<RequirementsEngineering,,, in Ency-
clopedia of Sofh~areEngineering (J.J Marciniak, editor),
[BOS9 11 Bossert, J.L., Quality Function Deployment: A Prac- Wiley, 1994, pp. 1043-1054.
titioner's Approach, ASQC Press, 1991.
[TAN891 Tanik, M.M., y R.T. Yeh (eds.), <<RapidPrototyping
[CUR851 Curtis, B., Human Factors in Software Develop- in Software Development,, (resultado especial), IEEE
ment, IEEE Computer Society Press, 1985. Computer, vol. 22, n." 5, Mayo 1989.
[DAV93] Davis, A., Software requirements: Objetcs, Func- [WYD96] Wyder, T., <<CapturingRequirements with use-
tions and States, Prentice-Hall, 1993. cases,, Sofbjare Development, Febrero 1996, pp. 37-40.
[DAV95a] Davis, A., 201 Principles of Software Develop- [ZAH90] Zahniser, R.A., <<BuildingSoftware in Groups,>,
ment, McGraw-Hill, 1995. American Programmer, vol. 3, n."V/8. Julio-Agosto
[DAV95b] Davis, A., <<SoftwarePrototyping,,, in Advances 1990.
in Computers, vol. 40, Academic Press, 1995. [ZUL92] Zultner, R., <<QualityFunction Deployment for Soft-
[GAU89] Gause, D.C., y G. M. Weinberg, Exploring Requi- ware: Satisfying Customersn, American Programmer,
rements:Quality Before Design, Dorset House, 1989. Febrero 1992, pp. 28-41.
11.1. El anilisis de requisitos del software es indudablemente pueden llevar a cab0 las tareas de analisis de manera que se
la fase de comunicacidn mas intensa del proceso de ingenie- minimicen estas repercusiones politicas?
ria del software. i,Por quC suele romperse frecuentemente este
enlace de comunicacidn? 11.3. Estudie su percepcidn ideal de la formacidn y curricu-
lum de un analista de sistemas.
11.2. Suele haber serias repercusiones politicas cuando
comienza el anilisis de requisitos del software (y/o anilisis 11.4. A lo largo de todo el capitulo nos referimos a1 ccclien-
de un sistema). Por ejemplo, 10s trabajadores pueden creer te*. Describa el ccclienter desde el punto de vista de 10s
que la seguridad de su trabajo puede verse amenazada por un desarrolladores de sistemas de informacion. de 10s cons-
nuevo sistema automitico. iQuC origina tales problemas? iSe tructores de productos basados en computadora y cje 10s
C A P ~ T U L O1 1 CONCEPTOS Y PRINCIPIOS DEL ANALISIS
constructores de sistemas. iTenga cuidado, el problema pue- el contenido y cualquier estructura de la informacion que le
de ser miis complejo de lo que parece! parezca relevante.
11.5.Desarrolle un <<kit>> de tecnicas de especificacion de apli- 11.9. Haga una particidn del dominio funcional de HogarSe-
cacidn (TFEA). El kit debena incluir un conjunto de directri- guro. Inicialmente haga una particidn horizontal; despuCs haga
ces para llevar a cab0 una reunion TFEA, materiales para la particion vertical.
facilitar la creacidn de listas y otros elementos que pudieran 11.lo. Construya la representation esencial y de implemen-
ayudar en la definition de requisitos. tacion del sistema HogarSeguro.
11.6. Su profesor dividira la clase en grupos de cuatro a seis 11.11.Construya un prototipo en papel (o uno real) de Hogm-
estudiantes. La mitad del grupo hara el papel del departamento
Seguro. Asegdrese de mostrar la interaccion del propietario y
el funcionamiento global del sistema.
de marketing y la otra mitad el de la ingeniena del software.
Su trabajo consiste en definir 10s requisitos del sistema de segu- 11.12. Intente identificar componentes software de Hogar-
ridad HogurSeguro descrito en este capitulo. Celebre una reu- Seguro que podnan ser <<reutilizables>, en otros productos o
nion TFEA usando las directrices estudiadas en el capitulo. sistemas. Intente clasificar esos componentes.
11.13. Desarrolle una especificacion escrita de HogarSegu-
11.7. &3e puede decir que un Manual preliminar de usuario ro usando el esquema propuesto en la pagina web SEPA. (Nota:
es una forma de prototipo? Razone su respuesta. Su profesor le sugeriri quC secciones completar en este
11.8. Analice el dominio de informacion de HogurSeguro. momento.) Asegurese de aplicar las cuestiones descritas en la
Represente (usando la notacidn que crea apropiada) el flujo, revision de la especificacion.
Los libros que indicamos sobre la ingeniena de requisitos per- (Applying Use-cases: A Practical Guide, Addison-Wesley,
miten una buena base para el estudio de 10s conceptos y prin- 1998), y Texel y Williams (Use-Cases Combined With
cipios basicos del analisis. Thayer y Dorfman (Software BoochlOMTIUML. Prentice-Hall, 1997) facilitan una guia
Requirements Engineering, 2." ed., IEEE Computer Society detallada y muchos ejemplos utiles.
Press, 1997) presentan una amplia antologia sobre el tema. El analisis del dominio de la informaci6n es un principio
Graham y Graham (Requirements Engineering and Rapid fundamental del analisis de requisitos. Los libros de Matti-
Development, Addison-Wesley, 1989, destaca el d e s m l l o rapi- son (The Object-Oriented Enterprise. McGraw-Hill, 1993),
do y el uso de metodos orientados a objetos en su planteamiento y Modell (Data Anulysis, Datu Modelling and Classijcation,
sobre la ingenieria de requisitos, mientras MacCauley (Requi- McGraw-Hill, 1992) cubre distintos aspectos de este impor-
rements Engineering, Springer Verlag, 1996) presenta un bre- tante tema.
ve tratado acadCmico sobre el tema. Un reciente libro de Harrison (Prototyping and Sofkware
En 10s ultimos atios, la literatura hacia enfasis en el Development, Springer Verlag, 1999) facilita una moderna
modelo de requisitos y en 10s mktodos de especificacion. perspectiva sobre el prototipado del software. Dos libros de
pero hoy se hace igual Cnfasis en 10s metodos eficientes Connell y Shafer (Structl~edRapid Prototyping, Prentice-
para la obtencion de requisitos del software. Wood y Sil- Hall, 1989) y (Object-Oriented Rapid Prototyping, Yourdon
ver (Joint Application Development, segunda edicion, Wiley, Press, 1994) muestra como esta importante tecnica de aniili-
1995) han escrito un tratado definitivo para el desarrollo sis puede ser utilizada tanto para entornos convencionales
de apllcacione\ enlazadas. Cohen y Cohen (Quality Function como para entornos orientados a objetos.
Deployment, Addicon-Wesley, 1995), Terninko (Step-By- Otros libros como 10s de Pomberger et al. (Object Orien-
Step QFD: Customer-Driven Product Design, Saint Lucie tation und Prototyping in Software Engineering, Prentice-
Press, 1997), Gause y Weinberg [GAU89] y Zahniser Hall, 1996) y Krief et al. (Prototyping With Objects,
[ZAH90] estudia 10s mecanismos para tener reuniones efec- Prentice-Hall, 1996) examina el prototipado desde la pers-
tivas, mktodos de brainstorming y obtencion de requisitos pectiva de la orientacidn a objetos. La IEEE Proceedings ~f
que pueden usarse para clarificar resultados y una variedad Internationul Workshop on Rapid System Prototyping (publi-
de otras necesidades. Los casos de uso configuran una par- cado el pasado atio) presenta una vision actual en esta area.
te importante del analisis de requisitos orientado a objetos, Una amplia variedad de fuentes de informacion sobre el
que pueden usarse de forma independiente de la imple- analisis de requisitos y otros temas relacionados estan dispo-
mentacidn tecnologica que se seleccione. Rosenburg y Scott nibles en internet. Una lista actualizada de paginas web que
(Use-Case Driven Object Modelling with UML: A Pructi- son significativas sobre 10s conceptos y metodos de analisis
cul Approach. Addison-Wesley, 1999), Schneider et al. se encuentran en http://www.pressrnan5.corn
Palabras clave
ampliadones
para sistmas
m
en tiempo rml ...... .207
E
MODELADO DEL ANALMS
N un nivel tCcnico, la ingenieria del software empieza con una serie de tareas de mode-
lado que llevan a una especificaci6n completa de 10s requisitos y a una representaci6n
del diseiio general del software a construir. El modelo de uncilisis, realmente un conjunto
de modelos, es la primera representaci6n ticnica de un sistema. Con 10s aiios se han propuesto
anhlisis gramotical. ...215 muchos mitodos para el modelado del anrilisis. Sin embargo, ahora dos tendencias dominan el
DERi.. ............. .204 panorama del modelado del anhlisis. El primero, andlisis estr-uctirr-udu,es un mitodo de mode-
DFDs.. ..............206 lado clhsico y se describe en este capitulo. El otro enfoque, andlisis or-ientntfo( I objetos, se estu-
8cdodo de datos .215 . dia con detalle en el Capitulo 2 1. En la Seccion 12.8 se presenta una breve visi6n general de
ECs.. .............. .214 otros mCtodos de anilisis comlinmente usados.
IPS.. .............. .214 El anBlisis estructurado es una nctividad de construcci6n de modelos. Mediante una nota-
metanismos del d f i s i s cidn que satisfaga 10s principios de anhlisis operational estudiada en el Capitulo 11, creamos
estructwada.. ...... .210 modelos que representan el contenido y flujo de la inforniaci6n (datos y control); partimos el
-
modelada de dafos . .201 sistema funcionalmente, y seglin 10s distintos coniportaniientos establecemos la esencia de lo
modelado que se debe construir. El anilisis estructurado no es un mCtodo sencillo aplicado siempre de la
del comportamiento.. -209 misma forma por todos 10s que lo usan. Mris bien, es una amalgamn que ha evolucionado duran-
modelado funcional . .205 te 10s Liltimos 30 afios.
..
modelo de aJfisii. ,200 En su principal libro sobre este tema, Tom DeMarco [DEM79] describe el anrilisis estruc-
modelo de fluio turado de la siguiente forma:
de &tor ...........213
~ Q u e6s ? La palabra escrita e s un vehicu- vista. El anulisis representa 10s requi- especificacion incorporada e n el mode-
l o maravilloso para Ia comunicacion, sifos e n Ires wdimensionesn, por e s a lo e s creada y luego validada, tanto por
per0 no e s necesariamente e l mejor r a z h , se incrementa la probabilidad d e el ingenierodel software, corno por los
camlno para representar 10s requisitos encontrar errores, descubrir inconsis- clientes/usuarios.
del software. El analisis utiliza una corn- tencias y detectar omisiones. ~Cndrle s e l product0 obtenido? Las des-
binaci6n d e texto y d e diagramas, para cripciones d e 10s objetos d e datos, 10s
&Cu6lesson 10s pasos? Las requisitos d e
representar 10s requisitos de datos, fun- diagramas entidad-relacion, 10s dia-
datos, lunciones y comportamientos
ciones y comportamientos, que e s rela- g r a m a s d e flujo d e datos, 10s diagra-
son modelados utilizando diferentes
tivamente facil d e enlender y, mus m a s d e transition d e estados, l a s
diagramas. El modelado d e datos defi-
importanteah, sencillo p a reviscrr s u especificaciones d e l proceso y l a s
ne objetos d e datos, atributos y rela-
coneccion, completitud y consistencia. especificaciones d e control son crea-
ciones. El modelado d e funciones
~ Q u lo h hace? El ingenierodel software indica como 10s datos son transforma- d a s como resultado d e las actividades
(a veces llamado analista) construye e l d o s dentro d e l sistema. El modelado del andlisis.
modelo utilizando 10s requisitosdefini- del comportamiento representa e l ~ C d m opaedo estar seguro d e q u e lo he
dos por e l cliente. impacto d e 10s sucesos. Se crean unos hecho correctamente? El resultado del
LPor qu6 es importante? Para validar 10s modeIos preliminares q u e son anali- modelado del an6lisis debe ser revisa-
requisitos d e l software necesitarnos zados y refinados para valorar su cla- do para verificar s u correcci6n, comple-
examinarlos desde diferentes puntos d e ridad, completitud y consistencia. Una titud y consistencia,
Observando 10s problemas y fallos reconocidos para la fase de anilisis, se puede sugerir que necesita-
mos afiadir 10s siguientes objetivos a la fase de anrilisis.
Los productos del anilisis han de ser de mantenimiento muy Phcil. Esto concierne concretamente al
documento final [Especificaci6n de Requisites del Software].
Se deben tratar 10s problemas de gran tamaiio mediante alglin mCtodo efectivo de particicin. La espe-
cificaci6n mediante novelas victorianas ya no sirve.
Siempre que sea posible, se deben utilizar grhficos.
Tenemos que diferenciar las consideraciones 16gicas [esenciales] y las fisicas [de implementaci6nl. ..
Como minimo, necesitamos ....
Algo que nos ayude a hacer una partici6n de 10s requisitos y a documentar esas divisiones antes de
especificar ...
Algun mCtodo de seguimiento y evaluaci6n de interfaces ...
Nuevas herramientas para describir la 16gica y la tdctica, algo mejores que descripciones narrativas ...
I N G E N I E R I A DEL SOFTWARE. U N ENFOQUE PRACTICO
Es muy probable que ninglin otro mCtodo de ingenieria del software haya generado tanto interis, haya sido pro-
.bad0 (y a veces rechazado y vuelto a probar) por tanta gente, criticado y haya provocado tanta controversia. Pero
el mCtodo ha subsistido y ha alcanzado un importante seguimiento dentro de la comunidad de la ingenieria del
software.
, 12.1. BREVE -RIA

A1 igual que muchas de las contribuciones importan- El tCrmino ccanAlisis estructurado>>originalmente
tes a la ingenieria del software, el anrilisis estructurado acufiado por Douglas Ross, fue popularizado por
no fue introducido en un solo articulo o libro clave que DeMarco [DEM79]. En su libro sobre esta materia,
incluyera un tratamiento completo del tema. Los pri- DeMarco present6 y denominb 10s simbolos grfificos y
meros trabajos sobre modelos de anrilisis aparecieron a 10s modelos que 10s incorporan. En 10s afios siguientes,
h a l e s de 10s 6 0 y principios de 10s 70, pero la prime- Page-Jones [PAG80], Cane y Sarson [CAN821 y
ra aparici6n dcl enfoque de anrilisis estructurado fue muchos otros propusieron variaciones del enfoque del
como complernento de otro tema importante -el cdise- anrilisis estructurado. En todos 10s casos, el mCtodo se
fio estructurado>>-. Los investigadores (por ejemplo, centraba en aplicaciones de sisternas de informacibn y
[STE74], [YOU78], neccsitaban una notaci6n grrifica no proporcionaba una notacidn adecuada para 10s aspec-
para representar 10s datos y 10s procesos que 10s trans- tos de control y dc comportamiento de 10s problemas
forman. Esos procesos quedarian finalniente estableci- de ingenieria de tiernpo real.
dos cn una arquitectura de disefio. A rnediados de 10s 80, las <campliriciones>>para tiem-
po real fueron introducidas por Ward y Mellor [WAR851
y, m b tarde, por Hatley y Pirbhai [HAT87]. Con esas
ampliaciones, se consiguio un mitodo de anrilisis mris
,blemas. robusto que podia ser aplicado de forma efectiva a pro-
El probl( ~ny pensor blemas de ingenieria. En la actualidad, se est6 inten-
que el tener proolemas es un problems. tando desarrollar una notaci6n consistente [BRU88] y
Theodore Rubin se estrin publicando tratamientos modernos que permi-
tan acomodar el uso de he~ramientasCASE [YOU89].
12.2. L O S ELEMENTOS DEL M O D E L 0 DE ANALISIS

El modelo de anrilisis dcbe lograr tres objetivos pri-
rnarios: (1) describir lo que requiere el cliente. (2) esta-
blccer una base para la creaci6n de un diseiio de
software, y (3) definir un con.junto de requisitos que
se pucda validar una vez que se construye el softwa-
rc. Para lograr estos objetivos, el nlodelo de anilisis
extraido durante el aniilisis estructurado toma la for-
ma ilustrada en la Figura 12.1.
En el centro ciel modelo se encuentra el cliccio~rn-
rio d c clcrros -un almacin que contiene definiciones
de todos 10s objetos de datos consumidos y produci-
dos por el software-. Tres cliagramas diferentes ro-
dean el nucleo. El diugt.w~uCIC ~ n f i ~ l u ~ l - ~ ~ (DER)
~~lu(~ici~z
represent2 las relaciones entre 10s objetos cle dnros. El
DER es la notaci6n que se usa para realizar la activi-
dad de modelado de datos. Los atributos dc cada obje-
to de d a ~ o ssefialados en el DER se p ~ ~ e ddescribir
e
niediante una descripci6n de objetos de datos.
El dicrgrun~trdo flr~joclc doros ( D F D ) sirve para rIGURA 12.1. La estructura del de
tlos propbsitos: ( I) proporcionar una indicaci6n de
cbmo se transforman 10s datos a niedida cluc se avan- subfunciones) que transforman el flujo de d a ~ o s El
.
za en el sistema, y (2) representar las funciones (y DFD proporciona information adicionai que se usa
C A P ~ T U L O12 M O D E L A D O DEL A N A L I S I S
durante el analisis del dominio de informaci6n y sir- siciones de estado a estado. El DTE sime como la base
ve como base para el modelado de funci6n. En una del modelado de comportamiento. Dentro de la especi-
especijiicacibn de proceso ( E P ) se encuentra una des- ficacibn de control (EC) se encuentra miis informaci6n
cripcion de cada funci6n presentada en el DFD. sobre 10s aspectos de control del software.
El diagrama de transicibn de estados (DTE) indica El modelo de analisis acornpaha a cada diagrama,
como se comporta el sistema como consecuencia de especificacion y descripcion, y a1 diccionario sefialado
sucesos externos. Para lograr esto, el DTE representa en la Figura 12.1. Un estudio miis detallado de estos ele-
10s diferentes modos de comportamiento (llamados esta- mentos del modelo de analisis se presenta en las sec-
dos) del sistema y la manera en que se hacen las tran- ciones siguientes.
El modelado de datos responde a una serie de pregun- Objetos: Atributos: Relaciones:

tas especificas importantes para cualquier aplicaci6n de
procesamiento de datos. iCu6les son 10s objetos de datos Nornbre
primarios que va a procesar el sistema? iCu6l es la com-
posici6n de cada objeto de datos y quC atributos des-
cribe el objeto? ~Donderesiden actualmente 10s objetos?
- Direccion
Edad
Licencia
de conducir
iCuii1 es la relacion entre 10s objetos y 10s procesos que
Nurnero
10s transforinan?
posee
Fabricante
i A que preguntas Modelo
da respuesta el modelo
de datos?
carroceria
Para responder estas preguntas, 10s mCtodos de mode- Color
lado de datos hacen uso del diagrama de entidad-rela-
cion (DER). El DER, descrito con detalle posteriormente FIGURA 12.2. Objetos de datos, atributos y relaciones.
en esta seccion, permite que un ingeniero del software
identifique objetos de datos y sus relaciones mediante 12.3.1. Objetos de datos. atributos y relaciones
una notacion grafica. En el context0 del analisis estruc- El modelo de datos se compone de tres piezas de infor-
turado, el DER define todos 10s datos que se introdu- maci6n interrelacionadas: el objeto de datos, 10s atri-
cen, se almacenan, se transforman y se producen dentro butos que describen el objeto de datos y la relacion que
de una aplicaci6n. conecta objetos de datos entre si.
Objetos de datos. Un objeto de datos es una repre-
sentacion de cualquier composicion de informacion com-
puesta que deba comprender el software. Por composicion
to en la habilidad
de informacion, entendemos todo aquello que tiene un
del munda real y
numero de propiedades o atributos diferentes. Por tanto,
el ccancho>>(un valor sencillo) no seria un objeto de datos
vhlido, per0 las c<dimensiones>> (incorporando altura,
ancho y profundidad) se podria definir como objeto.
El diagrama entidad-relacion se centra solo en 10s

datos (y por consiguiente satisface el primer principio
operacional de aniilisis), representando una <<redde Un objeto de dotos es uno representocion
datosu que existe para un sistema dado. El DER es espe- de cuolquier configurocion de informocibn
cificamente util para aplicaciones en donde 10s datos y que es procesodo por el sohore.
las relaciones que gobiernan 10s datos son complejos.
A diferencia del diagrama de flujo de datos (estudiado Un objeto de datos puede ser una entidad externa
en la Seccion 12.4 y usado para representar como se (por ejemplo, cualquier cosa que produce o consume
transforman 10s datos), el modelado de datos estudia informaci6n), una cosa (por ejemplo, un informe o una
10s datos independientemente del procesamiento que pantalla), una ocurrencia (por ejemplo, una llamada tele-
10s transforma. fonica) o suceso (por ejemplo, una alarma), un puesto
(por ejemplo, un vendedor), una unidad de la organiza- como un identificador --es decir, el atributo identifi-
.ci6n (por ejemplo, departamento de contabilidad), o una cador supone una ccclave>>cuando queramos encontrar
estructura (por ejemplo, un archivo). Por ejemplo, una una instancia del objeto de dato-. En algunos casos,
persona o un coche (Fig. 12.2) se pueden ver como un 10s valores para 10s identificadores son linicos, aun-
objeto de datos en el sentido en que cualquiera se pue- que esto no es un requisito. Haciendo referencia a1
de definir segun un conjunto de atributos. La descrip- objeto de datos coche, un identificador razonable
cibn de objeto de datos incorpora el objeto de datos y podria ser el n6mero de bastidor.
todos sus atributos.
3
Referencia Web
Informaci6n htil sobre el madelo de datos puede
encontrarse en www.datamodel.org
10s atributos definen un obieto de datos,
describen sus caracteristicas, y en algunos ocasiones,
estoblecen referencias a otros obietos.
El conjunto de atributos apropiado para un objeto de

Los objetos de datos se relacionan con otros. Por datos dado se determina mediante el entendimiento del
ejemplo, persona puede poseer coche, donde la rela- contexto del problema. Los atributos para coche des-
ci6n poseer implica una ccconexi6nn especifica entre critos anteriormente podrian servir para una aplicacion
persona y coche. Las relaciones siempre se definen por que usara un Departamento de Vehiculos de Motor, per0
el contexto del problema que se estB analizando. estos atributos serian menos utiles para una compaiiia
Un objeto de datos solamente encapsula datos -no de autom6viles que necesite fabricar software de con-
hay referencia dentro de un objeto de datos a operacio- trol. En este ultimo caso, 10s atributos de coche podrian
nes que actuan en el dato1--. Por consiguiente, el obje- incluir tambikn n6mero de bastidor, tip0 de carroceria,
to de datos se puede representar como una tabla de la y color, pero muchos atributos adicionales (Por ejem-
forma en que se muestra en la Figura 12.3. Los enca- plo: c6digo interior, tipo de direccibn, selector de equi-
bezamientos de la tabla reflejan atributos del objeto. En pamiento interior, tipo de transmisi6n) se tendrian que
este caso, se define un coche en tkrminos de fabrican- afiadir para que coche sea un objeto significativo en el
te, modelo, ndmero de bastidor, tipo de carrocen'a, color contexto del control de fabricaci6n.
y propietario. El cuerpo de la tabla representa ocurren-
cias del objeto de datos. Por ejemplo, un Honda CRV
es una ocurrencia del objeto de datos coche.
'.
Atributos Ata un objeto de datos a otro, 10s relaciones indican la monera en que 10s obietos
identificativos en este caso, el propietario de datos estan ccconectadosr entre si.
* ldentificador
Atributos
descriptivos
Atributos
Relaciones. Los objetos de datos se conectan entre
de referencia
-A,-"-, si de muchas formas diferentes. Considere dos objetos
N'de Tipo de de datos, libro y libreria. Estos objetos se pueden repre-
sentar mediante la notacibn simple sefialada en la Figu-
Lexus LS400 ABl23 ... Sedan Blanco RSP ra 12.4a. Se establece una conexion entre libro y libreria
Ocurrencia Honda CRV X456... terrene Rojo CCD porque 10s dos objetos se relacionan. Pero, iquk son
relaciones? Para determinar la respuesta, debemos com-
BMW 750iL X n 6 5 ... Coupe Blanco LJL
Ford Taurus Q12A45.. Sedan Azul BLF
prender el papel de libro y libreria dentro del contexto
del software que se va construir. Podemos definir un
FIGURA 12.3. R e p r e s e n t a c i o n t a b u l a r del objeto de d a t o s . conjunto de parejas objeto-relaci6n que definen las rela-
ciones relevantes. Por ejemplo,
Atributos. Los atributos definen las propiedades una libreria pide libros
de un objeto de datos y toman una de las tres caracte- una libreria muestra libros
risticas diferentes. Se pueden usar para (1) nombrar
una ocurrencia del objeto de datos, (2) describir la ocu- una libreria almacena libros
rrencia, o (3) hacer referencias a otra ocurrencia en una libreria vende libros
otra tabla. AdemBs. uno o varios atributos se definen una libreria devuelve libros
Esta distincion separa el objeto de datos de la clase u objeto defini-

dos corno parte del paradigma orientado a objetos que se estudia en
la Parte Cuarta de este libro.
CAPfTULO 12 M O D E L A D O DEL ANALISIS
Uno a uno (1: 1)-Una ocurrencia [de un objeto] <<A>>

se puede relacionar a una y s610 una ocurrencia del
objeto c<B>>,y una ocurrencia de KB>> se puede rela-
(a) Una conexion basica entre objetos cionar solo con una ocurrencia de <<A>>.
Pide Uno a muchos (1:N)-Una ocurrencia del objeto <<A>>
se puede relacionar a una o muchas ocurrencias del
objeto c<B>>,per0 una de c<B>> se puede relacionar solo
Vende a una ocurrencia de <<A>>. Por ejemplo, una madre
puede tener muchos hijos, per0 un hijo solo puede
tener una madre.
(b) Relaciones entre objetos Muchos a muchos (M:N)-Una ocurrencia del objeto
<<A>>puede relacionarse con una o mas ocurrencias
FIGURA 12.4. Relaciones. de KBB,mientras que una de <<BB se puede relacio-
nar con una o mas de <<A>>. Por ejemplo, un tio puede
Las relacionespide, muestra, alrnacena y devuelve defi- tener muchos sobrinos, mientras que un sobrino
ne las conexiones relevantes entre libro y libreria. La Figu- puede tener muchos tios.
ra 12.4b ilustra estas parejas objeto-relaciongraficamente. La cardinalidad define <<elnumero mhximo de rela-
Es importante destacar que las parejas objeto-relaciones de objetos que pueden participar en una relacion>>
ci6n tienen dos direcciones; esto es, se pueden leer en [TIL93]. Sin embargo, no proporciona una indicacidn de
cualquier direction. Una libreria pide libros o 10s libros si un objeto de datos en particular debe o no participar
son pedidos por una libreria2. en la relacion. Para especificar esta informaci6n, el mode-
10 de datos afiade modalidad a la pareja objeto-relacion.
12.3.2. Cardinalidad y modalidad Modalidad. La modalidad de una relacion es cero
Los elementos basicos del modelado de datos -objetos si no hay una necesidad explicita de que ocurra una rela-
de datos, atributos, y relaciones- proporcionan la base cion, o que sea optional. La modalidad es 1 si una ocu-
del entendimiento del dominio de informaci6n de un pro- rrencia de la relacion es obligatoria. Para ilustrarlo,
blema. Sin embargo, tambiCn se debe comprender la infor- consideremos el software que utiliza una compafiia tele-
macion adicional relacionada con estos elementos bhsicos. fonica local para procesar peticiones de reparacion. Un
Hemos definido un conjunto de objetos y represen- cliente indica que hay un problema. Si se diagnostica
tad0 las parejas objeto-relacion que 10s limitan. Una que un problema es relativamente simple, solo ocurre
simple referencia: el objeto X que se relaciona con el una unica acci6n de reparacion. Sin embargo, si el pro-
objeto Y no proporciona informacion suficiente para blema es complejo, se pueden requerir multiples accio-
propositos de ingenieria del software. Debemos com- nes de reparacion. La Figura 12.5 ilustra la relacion,
prender la cantidad de ocurrencias del objeto X que cardinalidad y modalidad entre 10s objetos de datos
estan relacionadas con ocurrencias del objeto Y. Esto cliente y accion de reparacion.
nos conduce a1 concept0 del modelado de datos llama-
do cardinalidad. Cardinalidad: Cardinalidad:
Cardinalidad. El modelo de datos debe ser capaz lrnplica q u e u n solo lrnplica q u e puede haber
de representar el numero de ocurrencias de objetos que cliente espere accion(es) rnuchas acciones
d e reparacion d e reparacion
se dan en una relacion. Tillman [TIL93] define la car-
dinalidad de una pareja objeto-relacion de la forma
siguiente: Se proporciona con & c o n de
La cardinalidad es la especificacion del numero de Cliente
reparacion
ocurrencias [de un objeto] que se relaciona con ocu-
rrencias de otro [objeto]. La cardinalidad normalmente
se expresa simplemente como ccuno>>o ctmuchos>>.
ejemplo, un marido puede tener solo una esposa (en la
Por
-
1
Modalidad: obligatoria
lrnplica que para tener
1 -
~ o d a l i d e d Opcional
:
lrnplica q u e puede haber
mayoria de las culturas), mientras que un padre puede accion(es) d e reparacion, una situacion e n la q u e
tener muchos hijos. Teniendo en consideration todas las debernos tener una accion d e reparacion
u n cliente n o sea necesaria
combinaciones de ccuno>>y ccmuchos>>, dos [objetos] se
pueden relacionar como: FIGURA 12.5. Cardinalidad y modalidad.
Para evitar cualquier ambigiiedad, se debe considerar la manera en

que se etiqueta una relacion. Por ejemplo, si n o se considera el con-
texto para una relacion bidireccional, la Figura 12.4b podria inter-
pretarse erroneamente como libros piden librerias. En tales casos, se
necesita volver a escribir la frase.
C A P ~ T U L O12 M O D E L A D O DEL ANALISIS
Desorrolle el DER de formo iterotivo poro ir refinondo

10s objetos de dotos y 10s relociones que 10s conecton. P Coche
La notacion del DER tambiCn proporciona un meca-

nismo que representa la asociabilidad entre objetos. Un
objeto de datos asociutivo se representa como se mues-
tra en la Figura 12.9. En la figura, 10s objetos de datos
1 1
ropeo o m s t i c o 1 1
Asihtico
que modelan 10s subsistemas individuales se asocian

con el objeto de datos coche.
El modelado de datos y el diagrama entidad relaci6n
proporcionan a1 analista una notaci6n concisa para exa-
minar datos dentro del context0 de una aplicacion de
procesamiento de datos. En la mayoria de 10s casos, el
enfoque del modelado de datos se utiliza para crear una
parte del modelo de analisis, per0 tambih se puede uti-
lizar para el disefio de bases de datos y para soportar
cualquier otro mCtodo de anilisis de requisitos.
066666 Alemhn ' ltaliano
FIGURA 12.8. Jerarquia tipo de objetos de datos.

Japonbs Coreano
La infonnaci6n se transforma a medida queJuye por un

sistema basado en computadora. El sistema acepta entra-
das en una gran variedad de formas; aplica elementos de
hardware, software y humanos para transformar la entra-
da en salida, y produce salida en una gran variedad de
formas. La entrada puede ser una seiial de control trans-
mitida por un controlador, una serie de numeros escri-
tos por un enlace de una red o un archivo voluminoso
de datos recuperado de un almacenamiento secundario.
La transformacion puede ser, desde una sencilla com-
paracion logics, hasta un complejo algoritmo num6ico
o un mecanismo de reglas de inferencia de un sistema
experto. La salida puede ser el encendido de un diodo
FIGURA 12.10. Modelo del flujo de informacion.
de emision de luz (LED) o un informe de 200 paginas.
Efectivamente, podemos crear un modelo de Jujo para El anilisis estructurado es una tCcnica del modela-
cualquier sistema de computadora, independientemen- do del flujo y del contenido de la infontlacion. Tal como
te del tamafio y de la complejidad. muestra la Figura 12.10, el sistema basado en compu-
tadora se representa como una transformaci6n de infor-
macion. Se utiliza un rectingulo para representar una
entidud externa, esto es, un elemento del sistema (por
ejemplo, un elemento hardware, una persona, otro pro-
grama) u otro sistema que produce informacion para ser
transformada por el software, o recibe informacion pro-
ducida por el software. Un circulo (tambien llamado
burbuja) representa un proreso o transformacidn que
es aplicado a 10s datos (o a1 control) y 10s modifica. Una
fl echa representa uno o m8s elementos de datos (obje-
tos de dato). Toda flecha en un diagrama de flujos de
datos debe estar etiquetada. Las lineas en paralelo repre-
sentan un almacenamiento -information almacenada
que es utilizada por el software-. La simplicidad de la
notation del DFD es una raz6n por la que las tCcnicas
FIGURA 12.9. Asociacion de objetos de datos. del analisis estructurado son ampliamente utilizadas.
Como ya indicamos anteriormente, se puede refinar

cada una de las burbujas en distintos niveles para mos-
El DFD no es procedimental. No permite representor trar un mayor detalle. La Figura 12.11 ilustra este con-
con su notacion grofico tratomientos condicionoles cepto. El modelo fundamental del sistema F muestra la
ni bucles. Simplemente muestro el fluja de dotos. entrada principal A y la salida final B. Refinamos el
modelo F en las transformaciones fl u p . Observe que
Es conveniente hacer notar que el diagrama no pro- se debe mantener la continuidad del Jlujo de informa-
porciona ninguna indicacidn explicita de la secuencia cidn, es decir, que la entrada y la salida de cada refina-
de procesamiento o de una condici6n lbgica. El proce- miento debe ser la misma. Este concepto, a veces
dimiento o secuencia puede estar implicitamente en el denominado balanceo, es esencial para el desarrollo de
diagrama, pues 10s detalles lbgicos son generalmente modelos consistentes. Un mayor refinamiento de f4
retrasados hasta el diseiio del software. Es importante muestra mas detalle en la forma de las transformacio-
no confundir un DFD con el diagrama de flujo. nes f41 a f45. De nuevo, la entrada (X, Y) y la salida
(Z) permanecen inalteradas.
12.4.1. Diagramas de flujo d e datos
A medida que la informaci6n se mueve a travCs del soft-
ware, es modificada por una serie de transformaciones.
El diagrama deJlujo de datos (DFD) es una tCcnica que
representa el flujo de la informaci6n y las transforma-
ciones que se aplican a 10s datos a1 moverse desde la
entrada hasta la salida. En la Figura 12.10 se muestra
la forma basica de un diagrama de flujo de datos. El
DFD es tambiCn conocido como grafo deJlujo de datos
o como diagrama de burbujas.
El DFD focilito un meconismo porn modelizor el fluio

de informoci6ny modelizor 10s funciones.
Se puede usar el diagrama de flujo de datos para
representar un sistema o un software a cualquier nivel FIGURA 12.11. Refinamiento del flujo de informacibn.
de abstracci6n. De hecho, 10s DFDs pueden ser dividi-
dos en niveles que representen un mayor flujo de infor- La notaci6n basica que se usa para desarrollar un DFD
maci6n y un mayor detalle funcional. Por consiguiente, no es en si misma suficiente para describir 10s requisi-
el DFD proporciona un mecanismo para el modelado tos del software. Por ejemplo, una flecha de un DFD
funcional, asi como el modelado del flujo de informa- representa un objeto de datos que entra o sale de un pro-
ci6n. A1 hacer esto, se cumple el segundo principio de ceso. Un almacCn de datos representa alguna colecci6n
analisis operacional (esto es, crear un modelo funcio- organizada de datos. Pero jcual es el contenido de 10s
nal) estudiado en el Capitulo 11. datos implicados en las flechas o en el almacCn? Si la
Un DFD de nivel 0, tambiCn denominado modelo flecha (o el almacCn) representan una colecci6n de obje-
fundamental del sistema o modelo de contexto, repre- tos, icuiles son? Para responder a estas preguntas, apli-
senta a1 elemento de software completo como una sola carnos otro componente de la notacibn basica del analisis
burbuja con datos de entrada y de salida representados estructurado - e l diccionario de datos-. El formato y
por flechas de entrada y de salida, respectivamente. A1 el uso del diccionario de datos se explica mas adelante.
dividir el DFD de nivel 0 para mostrar mas detalles, apa-
recen representados procesos (burbujas) y caminos de
flujo de informacibn adicionales. Por ejemplo, un DFD
de nivel 1 puede contener cinco o seis burbujas con fle- Si bien la continuidad del flujo de informorion debe
chas interconectadas. Cada uno de 10s procesos repre- ser mantenido, reconocemos que un elemento de dotos
representodo en un nivel puede ser refinada en sus portes
sentados en el nivel 1 es una subfunci6n del sistema
canstimyentes en el siguiente nivel.
general en el modelo del contexto.
La notacidn grafica debe ser ampliada con texto des-
criptivo. Se puede usar una especijicacidn de proceso
La desrampasicibn de un nivel de DFD en su siguiente
(EP) para especificar 10s detalles de procesamiento que
deberia seguir una aproximacian a1 ratio 15,reduciendo implica una burbuja del DFD. La especificaci6n de pro-
10s fumms descamposiciones ceso describe la entrada a la funcibn, el algoritmo que
CAP~TULO
12 M O D E L A D O DEL A N A L I S I S
se aplica para transformar la entrada y la salida que se vise la velocidad de la turbina, la temperatura del
produce. Ademas, el EP indica las restricciones y limi- combustible y varias sondas de presion, todo ello de
taciones impuestas a1 proceso (funcion), las caracteris- forma continua. La notaci6n del flujo de datos con-
ticas de rendimiento que son relevantes a1 proceso y las vencional no hace distinciones entre datos discretos
restricciones de disefio que puedan tener influencia en y datos continuos en el tiempo. Una ampliacion de la
la forma de implementar el proceso. notaci6n bisica del analisis estructurado que se mues-
tra en la Figura 12.12 proporciona un mecanismo para
12.4.2. Ampliaciones para sistemas de tiempo real representar el flujo de datos continuo en el tiempo.
Para representar el flujo continuo en el tiempo se usa
Muchas aplicaciones de software son dependientes del la flecha de dos cabezas, mientras que el flujo de
tiempo y procesan mas informacion orientada a1 con- datos discreto se representa con una flecha de una
trol de datos. Un sistema de tiempo real debe inter- sola cabeza. En la figura, se mide continuamente la
actuar con el mundo real en marcos temporales que temperatura supervisada, mientras que so10 se pro-
vienen dados por el mundo real. El control de naves o porciona un valor para el ajuste de temperatura. El
de procesos de fabricacih, 10s productos de consumo proceso de la figura produce una salida continua,
y la instrumentacion industrial son algunas de entre valor corregido.
cientos de aplicaciones del software de tiempo real.
Para que resulte adecuado el analisis del software de
tiempo real, se han propuesto varias ampliaciones para
la notacion basica del analisis estructurado.
Poro odecuor el rnodelo o un sisterno en tiernpo real,
lo notocibn del onolisis estructurodo debe perrnitir
12.4.3. Ampliaciones d e Ward y Mellor procesor eventos y lo llegodo de continuos datos.
Ward y Mellor [WAR851 amplian la notacion basica La distincion entre flujo de datos discreto y con-
del analisis estructurado para que se adapte a las tinuo en el tiempo tiene implicaciones importantes,
siguientes demandas impuestas por 10s sistemas de tanto para el ingeniero de sistemas como para el dise-
tiempo real: Aador del software. Durante la creacion del modelo
Flujo de informacion que es recogido o producido del sistema, podra aislar 10s procesos que pueden ser
de forma continua en el tiempo. criticos para el rendimiento (es muy usual que la
Informaci6n de control que pasa por el sistema y el entrada y salida de datos continuos en el tiempo
procesamiento de control asociado. dependan del rendimiento). A1 crear el modelo fisi-
Ocurrencias multiples de la misma transformaci6n co o de implernentacion, el disefiador debe estable-
que se encuentran a menudo en situaciones de mul- cer un mecanismo para la recoleccion de datos
titarea. continuos en el tiempo. Obviamente, el sistema digi-
tal recolecta datos en una forma casi continua utili-
Estados del sistema y mecanismos que producen tran- zando tkcnicas de muestreo de alta velocidad. La
sicion de estados en el sistema. notacion indica ddnde se necesita hardware de con-
version anal6gica a digital y quk transformaciones
requerirhn, con mayor probabilidad, un software de
Entrada alto rendimiento.
([continua))
Tem~eratura / Salida En 10s diagramas de flujo de datos convenciona-
supervisada (continua)) les no se representa explicitamente el control o f l u -
jos de sucesos. De hecho, a1 analista se le advierte
de que ha de excluir especificamente la representa-
y ajustar Valor ci6n del flujo de control del diagrama de flujo de
el nivel de corregido
datos. Esta exclusi6n es demasiado restrictiva cuan-
do se trata de aplicaciones de tiempo real y, por este
motivo, se ha desarrollado una notaci6n especiali-
Ajuste
de temperatura zada para la representacidn del flujo de sucesos y del
procesamiento de control. Siguiendo con 10s conve-
FIGURA 12.12. Flujo de datos continuo en el tiempo. nios establecidos para 10s diagramas de flujo de
datos, el flujo de datos se representa mediante fle-
En un porcentaje significative de aplicaciones de chas con trazo continuo. Sin embargo, el flujo de
tiempo real, el sistema debe controlar la informacidn control se representa mediante flechas de trazo dis-
continua en el tiempo generada por a l g h proceso del continuo o sombreadas. Un proceso que so10 mane-
mundo real. Por ejemplo, puede que se haga necesa- ja flujos de control de,nominadoproceso de control,
rio un sistema de control de pruebas en tiempo real se representa analdgicamente mediante una burbuja
para maquinas de turbina de gas, para que se super- con trazo discontinuo.
I N G E N I E R ~DEL
A SOFTWARE. UN ENFOQUE PRhCTICO
Por ejemplo, puede que haya que supervisar varios

Movimiento
de alarma buffers de estado de piezas para que puedan activarse
\ Estado de
\, cada elemento
H diferentes robots en 10s momentos oportunos. Ademis,
- - -\- - - - - puede que cada robot tenga su propio sistema de control.
Buffer del estado La notaci6n de Ward y Mellor se usa para representar
multiples ocurrencias equivalentes del mismo proceso.
Cadena de bits'
12.4.4. Ampliaciones de Hatley y Pirbhai
Activar
I proceso Las ampliaciones de Hatley y Pirbhai [HAT871 a la
I notacion bisica del analisis estructurado se centra menos
0rdenes en la creacidn de simbolos grificos adicionales y mis en
del operador la representacion y especificaci6n de 10s aspectos del soft-
ware orientados al control. La flecha de trazo discontinuo
del robot se utiliza para representar el flujo de control o de sucesos.
A diferencia de Ward y Mellor, Hatley y Pirbhai sugieren
que se represente por separado la notacion de trazo conti-
Archivo de ordenes
del robot I nuo de la de trazo discontinuo. Asi, se define un diagra-
ma dejujo de control (DFC).El DFC contiene 10s mismos
FIGURA 12.13. Flujos de datos y de control utilizando procesos que el DFD, per0 muestra el flujo de control en
la notacion de Ward y Mellor [WAR85]. lugar de datos. En lugar de representar directamente 10s
procesos de control dentro del modelo de flujo, se usa una
El flujo de control puede ser una entrada directa de referencia de notacidn (una barra solida) a una especijica-
un proceso convencional o de un proceso de control. La cibn de control (EC). En esencia, se puede considerar la
Figura 12.13 ilustra el flujo de control y su procesa- barra como una <<ventma>> hacia un <<director>>(la EC) que
miento, utilizando la notacion de Ward y Mellor. La controla 10s procesos (las burbujas) representadas en el
figura ilustra el planteamiento de mayor nivel de un flu- DFD, de acuerdo con 10s sucesos que pasan a travCs de la
jo de datos y de control de una cClula de fabricacibn. A ventana. Se usa la EC, que se describe en detalle en la Sec-
medida que se van colocando en las fijaciones 10s com- cion 12.6.4, para indicar: (1) c6mo se comporta el software
ponentes a ser ensamblados por un robot, se ajusta un cuando se detecta un suceso o una seiial de control, y (2)
bit de un buffer de estado de las piezas (un almacCn quC procesos se invocan como consecuencia de la ocu-
de control) que indica la presencia o ausencia de cada rrencia del suceso. Se usa una especijicacidn de proceso
componente. La informacion de sucesos contenida en (EP)para describir el procesamiento intemo de 10s proce-
el buffer de estado de las piezas se pasa como una sos representados en el diagrama de flujo.
cadena de bits a un proceso, interj'az del monitor de
jijacidn y operador. El proceso leeri ordenes del ope-
rador solo cuando la informacion de control, cadena
de bits, indique que todas las fijaciones contienen com- El DFC rnuestro torno 10s eventos se mueven
ponentes. Se envia un indicador de suceso, indicador en el sistemo. Uno EC muestro el tomportomiento
de comienzo/parada, a control de activacidn del robot, del software torno uno tonsetuentio de 10s eventos
un proceso de control que permite un posterior proce- y o qui! procesos les corresponde intervenir
samiento de ordenes. Como consecuencia del suceso en lo rnonipuloci6n de 10s eventos.
activar proceso se producen otros flujos de datos que
son enviados a procesar drdenes del robot. Usando la notacidn descrita en las Figuras 12.12 y
12.13,junto con la informacion adicional contenida en
EPs y ECs, Hatley y Pirbhai crean un modelo de siste-
ma de tiempo real. Para representar 10s datos y 10s pro-
ema en tiempo real a veces cesos que 10s manejan se usan 10s diagramas de flujo de
que atthan como 10s 5 sentidos datos. Los diagramas de flujo de control muestran cdmo
fluyen 10s sucesos entre 10s distintos procesos e ilustran
ellor cdmo 10s sucesos extemos hacen que se activen 10s pro-
cesos. Las interrelaciones entre 10s modelos de proce-
En algunas situaciones, en un sistema de tiempo real so de control se muestran esquemhticamenteen la Figura
puede haber ocurrencias multiples del mismo proceso 12.14. El modelo de procesamiento esti ccconectadoxon
de control o de transformacidn de datos. Se puede dar el modelo de control a travCs de condiciones de datos.
este caso en un entorno multitarea en el que se activan El modelo de control esti ccconectado>>con el modelo
las tareas como resultado de alg6n procesamiento inter- de procesos mediante la informaci6n de activacidn de
no o de sucesos extemos. procesos contenida en la EC.
CAPfTULO 12 M O D E L A D O DEL ANALISIS
Para determinar quC es lo que ocurre cuando se pro-

duce este suceso, debemos comprobar la EC.
La especificaci6n de control (EC) contiene varias
Lo especificocibndel sistemo en tiempo real plonteodo herramientas importantes del modelado. Para indicar
por Hotley y Pirbhoi es descrito en www.univ-porisl.fr quC procesos se activan por un suceso dado que flu-
/CRINFO/dmrg/MEE98/misop032/ ye por la barra vertical, se usa una tabla de activa-
ci6.n de procesos (descrita en la Seccion 12.6.4). Por
Una condicion de datos se produce cuando 10s datos ejemplo, una tabla de activaci6n de procesos (TAP)
de entrada de un proceso hacen que se produzca una sali- para la Figura 12.14 podria indicar que el suceso pre-
da de control. La Figura 12.14 ilustra esta situaci6n en una sion aka haria que se invocara un proceso reducir
parte del modelo de flujo para un sistema de supervision presidn del tanque (que no se muestra). Ademas de
y control automatizado de valvulas de presion de una refi- la TAP, la EC puede contener un diagrama de tran-
neria de petroleo. El proceso comprobar y com~ertirpre- sicidn de estados (DTE). El DTE es un modelo de
sidn implementa el algoritmo descrito en el pseudocodigo comportamiento que se basa en la definicion de un
EP que se muestra. Cuando la presi6n absoluta del tanque conjunto de estados del sistema y se describe en la
es mayor que el maximo permitido, se genera un suceso seccion siguiente.
presion alta. Observe que cuando se usa la notation de
Hatley y Pirbhai, el flujo de datos de muestra como par- Estado
te de un DFD, mientras que el flujo de control se encuen- de alimentacion
tra a parte en un diagrama de flujo de control. del papel
(atascado, vacio)
Alarma
Diagrama
de flujo de datos
Diagrama
de flujo de control
\
\kl ./
Presion absoluta
maxima
if presion absoluta del tanque > presion maxima

then
poner presion aka a werdadero))
else
poner presion alta a (cfalsow;
begin algoritmo de conversion x-Ola;
calcular presion convertida;
end
endif
de reproduccion
FIGURA 12.14. La relacion entre 10s modelos de datos FIGURA 12.15. DFC de nivel 1 para el software de una foto-
y 10s de control lHAT871. copiadora.
El modelado del comportamiento es uno de 10s prin- ~ C O modelizar

~ O la reaction
cipios fundamentales de todos 10s mCtodos de anali- del software ante un evento
sis de requisitos. Sin embargo, solo algunas versiones externo?
ampliadas del analisis estructurado ([WARS],
[HAT87]) proporcionan una notacion para este tipo Un estado es un mod0 observable de comportamiento.
de modelado. El diagrama de transicion de estados Por ejemplo, estados para un sistema de supervision y de
representa el comportamiento de un sistema que control para que las vflvulas de presi6n descritas en la Sec-
muestra 10s estados y 10s sucesos que hacen que el cion 12.4.4. puedan estar en: estado de supervisidn, esta-
sistema cambie de estado. Ademas, el DTE indica do de alarma, estado de liberacidn de presidn y otros. Cada
quC acciones (por ejemplo, activation de procesos) uno de estos estados representa un mod0 de comporta-
se llevan a cab0 como consecuencia de un suceso miento del sistema. Un diagrama de transicion de estados
determinado. indica como se mueve el sistema de un estado a otro.
~ N G E N ~ E RDEL
~ A SOFTWARE. U N ENFOQUE PRACTICO
Para ilustrar el uso de las ampliaciones de compor- zolparada para activarldesactivar el proceso de ges-
tamiento y de control de Hatley y Pirbhai, consideremos ti6n de copiado. De forma similar, el suceso atasca-
el software ernpotrado en una miquina fotocopiadora de da (parte del estado de alimentacion del papel)
oficina. En la Figura 12.15 se muestra un flujo de con- activaria realizar diagnbstico del problema. Se debe-
trol para el software de fotocopiadora. Las flechas del ria destacar que todas las barras verticales dentro del
flujo de datos se han sombreado ligeramente con pro- DFC se refieren a la misrna EC. Un flujo de suceso
positos ilustrativos, per0 en realidad se muestran como se puede introducir directamente en el proceso como
parte de un diagrama de flujo de control. muestra fallo de reproduccion. Sin embargo, este flu-
Los flujos de control se muestran de cada proceso jo no activa el proceso, sino que proporciona infor-
individual y las barras verticales representan las even- maci6n de control para el algoritmo de proceso.
tanas>>EC. Por ejemplo, 10s sucesos estado de ali- Un diagrama de transicion de estados simplificado
mentacion del papel y de comienzolparada fluyen para el software de fotocopiadora descrito anterior-
dentro de la barra de EC. Esto implica que cada uno mente se muestra en la Figura 12.16. Los rectangulos
de estos sucesos hara que se active algun proceso representan estados del sistema y las flechas repre-
representado en el DFC. Si se fueran a exarninar las sentan transiciones entre estados. Cada flecha esti eti-
interioridades del EC, se mostraria el suceso cornien- quetada con una expresion en forma de fraccion. La
parte superior indica el suceso (o sucesos) que hace(n)
que se produzca la transicion. La parte inferior indica
la accion que se produce como consecuencia del suce-
so. Asi, cuando la bandeja de papel esta llena, y el
b o t h de comienzo ha sido pulsado, el sistema pasa
del estado leyendo brdenes a1 estado realizando copias.
iI Copias hechas
invocar leer-op-ent
I ~l&a
invocar leer-op-ent
I
Observe que 10s estados no se corresponden necesa-
riamente con 10s procesos de forma biunivoca. Por
ejemplo, el estado realizando copius englobaria tanto
el proceso gesti6n de copiado como el proceso pro-
ducir visualizacibn de usuario que aparecen en la Figu-
~taScada
ra 12.15.
invocar realizar diagnostic0 del problema
FIGURA 12.16. Diagramas de transicion de estados simplifi-

cad0 para el software de una fotocopiadora.
En la seccion anterior, hernos visto las notaciones 10s completos y precisos mediante el analisis estruc-
basica y ampliada del analisis estructurado. Para turado. A lo largo de este estudio, se usarh la notacion
poder utilizarlas eficienternente en el analisis de presentada en la Seccion 12.4 y se presentarhn, con
requisitos del software, se ha de combinar esa nota- algun detalle, otras formas de notacion ya aludidas
ci6n con un conjunto de heuristicas que permitan a1 anteriormente.
ingeniero del software derivar un buen rnodelo de
analisis. Para ilustrar el uso de esas heuristicas, en el 12.6.1. Creaci6n de un diagrama Entidad-Relaci6n
resto de este capitulo utilizarernos una version adap-
tada de las arnpliaciones de Hatley y Pirbhai [HAT871 El diagrama de entidad-relacion permite que un ingeniero
a la notacion basica del analisis estructurado. del software especifique 10s objetos de datos que entran y
salen de un sistema, 10s atributos que definen las propie-
dades de estos objetos y las relaciones entre 10s objetos. A1
igual que la mayoria de 10s elernentos del modelo de ana-
El modelo de onblisis permite on eximen critito lisis y las relaciones entre objetos, el DER se construye de
de 10s requisitos del sohare desde tres puntos una forma iterativa. Se toma el enfoque siguiente:
diferentes de visto. Asegurondo lo utilidod de 10s DERs,
DFDs y DT€s cuondo constroyes el modelo
$uales son 10s pasos
En las secciones siguientes, se examina cada uno requeridos para construir
de 10s pasos que se debe seguir para desarrollar mode- un DER?
CAPfTULO 12 MODELADO DEL ANALISIS
1. Durante la recopilacion de requisitos, se pide que 10s ta entre el propietario y panel de control, sistema de
clientes listen las <<cosasnque afronta el proceso de seguridad y servicio de vigilancia. Existe una cone-
la aplicacion o del negocio. Estas mosasn evolu- xion unica entre el sensor y el sistema de seguridad, y
cionan en una lista de objetos de datos de entrada y asi sucesivamente.
de salida, asi como entidades extemas que producen Una vez que se han definido todas las conexiones,
o consumen informacion. se identifican una o varias parejas objeto-relacion para
2. Tomando objetos uno cada vez, el analista y el cliente cada conexion. Por ejemplo, se determina la conexion
definen si existe una conexion (sin nombrar en ese entre sensor y sistema de seguridad para que tenga las
punto) o no entre el objeto de datos y otros objetos. parejas objeto-relacion siguientes:
el sistema de seguridad supervisa el sensor
3. Siempre que existe una conexion, el analista y el
el sistema de seguridad activaldesactiva el sensor
cliente crean una o varias parejas de objeto-relacion.
el sistema de seguridad prueba el sensor
4. Para cada pareja objeto-relacion se explora la cardi- el sistema de seguridad programa el sensor
nalidad y la modalidad. Cada una de las parejas objeto-relacion anteriores se
5. Interactivamente se continuan 10s pasos del 2 a1 4 analizan para determinar la cardinalidad y la modali-
hasta que se hayan definido todas las parejas objeto- dad. Por ejemplo, en la pareja objeto-relacion el siste-
relacion. Es normal descubrir omisiones a medida ma de seguridad supervisa el sensor, la cardinalidad
que el proceso continua. Objetos y relaciones nue- entre sistema de seguridad y sensor es una a muchos.
vos se afiadirin invariablemente a medida que crezca La modalidad es una incidencia de sistema de seguri-
el numero de interacciones. dad (obligatoria) y a1 menos una incidencia de sensor
6. Se definen 10s atributos de cada entidad. (obligatorio).Mediante la notacion DER introducida en
7. Se formaliza y se revisa el diagrama entidad-relacion. la Seccion 12.3, la linea de conexion entre sistema de
8. Se repiten 10s pasos del 1 a1 7 hasta que se termina seguridad y sensor se modificaria, como se muestra en
el modelado de datos. la Figura 12.18. Se aplicaria un analisis similar a1 res-
to de 10s objetos de datos.
Para ilustrar el uso de estas directrices basicas, usa-
remos el ejemplo del sistema de seguridad HogarSe-
Supervisa
guro tratado en el Capitulo 11. A continuaci6n,
reproducimos la narrativa de procesamiento para Hogar-
Seguro (Seccion 11.3.3), la siguiente lista (parcial) de
<<cosas>>son importantes para el problema:
propietario
panel de control
sensores
sistema de seguridad I Prograrna I
servicio de vigilancia
FIGURA 12.18. Desarrollo de relaciones y cardinalidad1
rnodalidad.
-LI Propietario Se estudia cada objeto para determinar sus atributos.

Como se esta considerando el software que debe sopor-
tar HogarSeguro, 10s atributos se deberian centrar en
Q
datos que deban almacenarse para permitir que opere el
Panel
de control Sensor sistema. Por ejemplo, el objeto sensor podria tener 10s
atributos siguientes: tipo de sensor, numero de identifi-
caci6n intema, localizaci6n de zona, y nivel de alarma.
Sisterna Servicio 12.6.2. Creacion de un modelo de flujo de datos

de seguridad de vigilancia
El diagrama d e j u j o de datos (DFD) permite a1 inge-
niero del software desarrollar 10s modelos del ambit0
de informaci6n y del ambito funcional a1 mismo tiem-
FIGURA 12.17. Establecirniento de conexiones. po. A medida que se refina el DFD en mayores niveles
de detalle, el analista lleva a cab0 implicitamente una
Tomando estas <<cosas>> una a una, se exploran las descomposicion funcional del sistema. A1 mismo tiem-
conexiones. Para realizar esto, se dibuja cada objeto y po, el refinamiento del DFD produce un refinamiento
se sefialan las lineas que conectan objetos. Por ejemplo, de 10s datos a medida que se mueven a travCs de 10s pro-
la Figura 12.17 muestra que existe una conexion direc- cesos que componen la aplicaci6n.
~ N G E N ~ E RDEL
~Existealguna guia util para nombres y 10s verbos que son sinonimos y no se apoyan
trear DFD's? directamente en el proceso de model ad^)^.
Unas pocas directrices sencillas pueden ayudar de

forma considerable durante la derivacion de un diagra-
ma de flujo de datos; (1) el diagrama de flujo de datos N on6lisis gromoticul no es seguro, per0 focilita
de nivel 0 debe reflejar el software/sistema como una uno excelente platoforma si estas empezondo
o definir objetos de datos y su trunsformacian.
sola burbuja; (2) se deben anotar cuidadosamente la
entrada y la salida principales; (3) el refinamiento debe
comenzar aislando 10s procesos, 10s objetos de datos y El software HogarSe~uropermite a1 propietario de la
vivienda configurar el sistema de sewridad a1 instalarlo;
10s almacenes de datos que Sean candidatos a ser repre- supervisa todos 10s sensores conectados a1 sisterna de segu-
sentados en el siguiente nivel; (4) todas las flechas y las ridad e interactha con el propietario a travCs de un teclado
burbujas deben ser rotuladas con nombres significati- numkrico y unas teclas de funcidn que se enclientran en el
vos; ( 5 ) entre sucesivos niveles se debe mantener la con- panel de control de HogarSeguro que se rnuestra en la Figu-
tinuidad deljujo de informacion; (6) se deben refinar ra 11.2.
las burbujas de una en una. Hay una tendencia natural Durante la instalacidn. se usa el panel de control de Hogar-
a complicar en exceso el diagrama de flujo de datos. Seguro para <<progranzar>> y configurar el sistema. Cada sen-
Esto ocurre cuando el analista intenta reflejar demasia- sor tiene asignado un ndrnero y un,&t existe una contraseiia
maestra para acti~lary desactivar el sistema, y se introdu-
dos detalles demasiado pronto o representa aspectos ce(n)un(os) telCfono(s) con 10s que contactar cuando se pro-
procedimentales en detriment0 del flujo de informacion. duce un suceso detectado por un sensor.
En la Figura 12.19 se muestra el DFD de nivel 0 para Cuando el software detecta un suceso, invoca una &
HogarSeguro. Las entidades externas principales (cua- ma audible que esti incorporada en el sistema. Tras un retar-
dros) producen informaci6n para ser usada por el siste- do, especificado por el propietario durante la configuration
-
ma y consumen informaci6n generada por el sistema. del sistema, el prograrna marca un numero de teltfono de un
Las flechas etiquetadas representan objetos de datos u semicio de monitorizacidn, proporciona informaci6n sobre
objetos de datos de tip0 jerirquico. Por ejemplo, orde- la situation e informa sobre la naturaleza del suceso detec-
tado. Cada 20 segundos se volvera a marcar el numero de
nes y datos de usuario engloba todas las 6rdenes de teltfono hasta que se consiga estahlecer la comunicacion.
configuraci61-1,todas las drdenes de activaci6n/desacti-
Toda la interaccion con HogarSeguro esti gestionada por
vacibn, todas las variadas interacciones y todos 10s datos un subsistema de interaccidn con el usuario que lee la
que se introducen para cualificar o ampliar una orden. macidn introducida a travCs del teclado numCrico y de las
teclas de funcidn, muestra mensaies de peticion en un &
drdenes tor LCD y muestra informacidn sobre el estado del sistema
decontrol y, datos de usuario en el monitor LCD. La interaccih por teclado toma la
siguiente forma.. .
€I
De acuerdo con el ccanilisis gramaticab, comienza
Alarrna a aparecer un patron. Todos 10s verbos son procesos
de HogarSeguro, es decir, deben estar en liltima ins-
tancia representados como burbujas en el consiguien-
0-
Sensores
del sensor
del nhero
de telefono
FIGURA 12.19. DFD de nivel contextual para HogarSeguro.

telefonica
te DFD. Todos 10s nombres son, o bien entidades
externas (cuadrados), objetos de datos o de control
(flechas) o almacenes de datos (lineas dobles). Ade-
mis 10s nombres y 10s verbos estin relacionados entre
si (por ejemplo, cada sensor tiene asignado un nume-
Ahora tenemos que expandir el DFD de nivel 0 o de ro y un &). Por tanto, con el anilisis gramatical de
-
nivel a un modelo de nivel 1. Pero, jc6m0 lo hacemos? la narrativa de procesamiento de una burbuja de cual-
Una sencilla, per0 efectiva, tkcnica consiste en realizar un quier nivel de DFD, podemos generar mucha infor-
<<andisisgramatical,, de la narrativa de procesamiento que macion util sobre cdmo proceder en el refinamiento
describe la burbuja de nivel contextual. Es decir, aislar del siguiente nivel. Usando esa informaci611, obtene-
todos 10s nombres (y sentencias nominales) y todos 10s mos el DFD de nivel 1 que se muestra en la Figura
verbos (y sentencias verbales) de la narrativa presentada 12.20. El proceso de nivel contextual de la Figura 12.19
aniba. Para ilustrarlo, reproducimos de nuevo la narrati- se ha expandido en siete procesos, derivados de un
va de procesamiento, subrayando las primeras ocurren- examen del analisis gramatical. De forma similar se
cias de 10s nombres y con las primeras ocurrencias de 10s ha derivado el flujo de informaci6n entre 10s procesos
verbos en cursiva. (Se debena seiialar que se omiten 10s del nivel 1.
Se debe tener en cuenta que seran ornitidos 10s nornbres y verbos
que Sean sinonimos o no tengan una relacion directa con el rnodelo
de procesos.
C A P ~ T U L O12 M O D E L A D O DEL ANALISIS
12.6.3. Creacion de un modelo de flujo de control

Para muchos tipos de aplicaciones de procesamiento de
Datos de datos, todo lo que se necesita para obtener una represen-
taci6n significativa de 10s requisitos del software es el
modelo de flujo de datos. Sin embargo, como ya hemos
mencionado anteriormente, existe una clase de numero-
sas aplicaciones que esth <<dirigidampor sucesos en lugar
de por 10s datos, que producen information de control m k
que informes o visualizaciones, que procesan informa-
ci6n con fuertes limitaciones de tiempo y rendimiento.
Tales aplicaciones requieren un modelado del flujo de con-
trol ademas del modelado del flujo de informaci6n.
La notaci6n grhfica que se requiere para crear un dia-
grama de.pujo de control (DFC) ya ha sido presentada
en la Secci6n 12.4.4. Recordando la forma en que se
crea un DFC, lo primer0 es <<eliminar>> del modelo de
flujo de datos todas las flechas de flujo de datos. Lue-
go, se aiiaden a1 diagrama 10s sucesos y 10s elementos
FIGURA 12.20. DFD de nivel 1 para HogarSeguro. de control (flechas con linea discontinua), asi como
Se debe tener en cuenta que entre 10s niveles 0 y 1 <<ventanas>> (barras verticales) a las especificaciones de
se ha mantenido la continuidad del flujo de informa- control. Pero, jc6m0 se seleccionan 10s sucesos?
ci6n. Se pospone hasta la Secci6n 12.7 la elaboracion
de 10s contenidos de las entradas y las salidas de 10s decontrol
DFD de niveles 0 y 1.
--.
Es cierto que el proceso norrotivo pretende onolizor
lo escrito siempre con el mismo nivel de obstroccibn.
I /
I /
Se pueden refinar en posteriores niveles 10s proce-
sos representados en el DFD de nivel 1. Por ejemplo,
se puede refinar el proceso monitorizar sensores a1 DFD ."
de nivel2 que se muestra en la Figura 12.21. Podemos =co,~~ 1 / I mensaies E
observar de nuevo que se mantiene la continuidad del
flujo de informaci6n entre 10s niveles. Suceso Senal
El refinamiento de 10s DFDs contin6a hasta que cada
burbuja representa una funci6n sencilla.
lnformacion del sensor
// -,/
Dar formato \
-I- I- Tipo FIGURA 12.22. DFD de nivel I para HogarSeguro.
lnformacion de configuracion I Ya hemos seiialado que 10s sucesos o 10s elementos
de control se implementan como valores 16gicos (por
del tip0 serial ejemplo, verdadero o falso, si o no, 1 6 0) o como una
y ubicacion de alarma
lista discreta de condiciones (vacia, atascada, llena).
Datos Para seleccionar posibles candidatos a sucesos, se pue-
den sugerir las siguientes directrices:
con 10s valores
Listar todos 10s sensores que son <deidos>>por el soft-
ware.
Listar todas las condiciones de interrupci6n.
Listar todos 10s <<interruptores>>que son accionados
por el operador.
Listar todas las condiciones de datos.
De acuerdo con el analisis de nombres y verbos que
se aplic6 a la narrativa de procesamiento, revisar
FIGURA 12.21. DFD de nivel 2 que refina el proceso todos 10s ccelementos de control>>como posibles
monitorizar sensores. entradaslsalidas de ECs.
~ N G E N ~ E RDEL
Describir el comportamiento del sistema identifi- La Figura 12.23 refleja un diagrama de transicibn de
cando sus estados; identificar como se alcanza cada estados para el modelo de flujo de nivel 1 de HogarSegu-
estado y definir las transiciones entre 10s estados. ro. Las flechas de transicion etiquetadas indican c6mo res-
Centrarse en las posibles omisiones -un error muy ponde el sistema a 10s sucesos a medida que pasa por 10s
comlin en la especificaci6n del control (por ejemplo, cuatro estados definidos en este nivel. Estudiando el DTE,
preguntarse si existe alguna otra forma en la que se un ingeniero del software puede determinar el comporta-
puede llegar a un estado o salir de 61)-. miento del sistema y, lo que es mas importante, compro-
bar si hay <<lagunas>> en el comportamiento especificado.
~ C O seleccionas
~ O eventos Una representaci6n algo diferente del mod0 de com-
potenciales para DFC, DTE y EC? portamiento es la tabla de activaci6n de procesos (TAP).
La TAP representa la informaci6n contenida en el DTE
En la Figura 12.22 se ilustra un DFC de nivel 1 para el dentro del context0 de 10s procesos, no de 10s estados.
software HogarSeguro. Entre 10s sucesos y 10s elementos Es decir, la tabla indica 10s procesos (burbujas) del
de control que aparecen e s t h suceso de sensor (por ejem- modelo de flujo que seran invocados cuando se pro-
plo, un sensor ha detectado una anomalia), indicador de duzca un suceso. Se puede usar la TAP como una guia
parpadeo (una seiial para que el monitor LCD parpadee), para el diseiiador que tenga que construir un controla-
e interruptor de comienzolparada (una seiial para encen- dor que controle 10s procesos representados en ese nivel.
der y apagar el sistema). Un suceso fluye a una ventana En la Figura 12.24 se muestra una TAP para el modelo
EC desde el mundo exterior, ello implica la activaci6n por de flujo de nivel 1 de HogarSeguro.
la EC de uno o mas procesos de 10s que aparecen en el La EC describe el comportamiento del sistema, pero no
DFC. Cuando un elemento de control emana de un pro- nos proporciona informaci6n sobre el funcionamiento inter-
ceso y fluye a una ventana EC, ello implica el control y la no de 10s procesos que son activados como resultado de ese
activaci6n de algun proceso o de una entidad extema. comportamiento. En la siguiente secci6n se estudia la nota-
ci6n del modelado que proporciona esa informaci6n.
lnterruptor de cornienzolparada
lnvocar monitory control
del sistema Leyendo 12.6.5. La especificaci6n del proceso
- entrada
del usuario
.
I
Se usa la especificaci6n de proceso (EP) para describir

todos 10s procesos del modelo de flujo que aparecen en
Exceso de tiempo
Suceso de sensor
lnvocar interactuar el nivel final de refinamiento. El contenido de la espe-
lnvocar monitorizarcon el usuario cificaci6n de procesamiento puede incluir una narrati-
t 'I y controlar el sistema I va textual, una descripci6n en lenguaje de disefio de
Monitorizacion - Actuando
del estado sobre un suceso
programas (LDP) del algoritmo del proceso, ecuacio-
Suceso de sensor * nes matemiticas, tablas, diagramas o graficos. A1 pro-
- del sistema
lnvocar visualizar mensaje -
de sensor
porcionar una EP que acompaiie cada burbuja del
Suceso de sensor
T y estado
modelo de flujo, el ingeniero del software crea una
Suceso de sensor <<mini-especificacibque sirve como primer paso para
mensaje y estado la creaci6n de la Especificacibn de Requisitos del Soft-
I ware y constituye una guia para el diseiio de la compo-
Estado de la accion nente de programa que implementara el proceso.
x d de visualization
lnvocar visualizar lnvocar interactuar Sucesos de entrada
mensaje y estado con el usuario
Suceso de sensor 0 0 0 0 1 0
FIGURA 12.23. Diagrama de transicibn de estados para lndicador de parpadeo 0 0 1 1 0 0
HogarSeguro. lnterruptor de cornienzolparada 0 1 0 0 0 0
Estado de la accion de visualizacion
Terminada 0 0 0 1 0 0
12.6.4. La especificaci6n de control En marcha 0 0 1 0 0 1
Exceso de tiempo 0 0 0 0 0 1
La especificaci6n de control (EC) representa el com-
portamiento del sistema (a1 nivel a1 que se ha hecho Salida
referencia) de dos formas diferentes. La EC contiene Sehal de alarma
un diagrama de transicibn de estados (DTE) que es
Activacion de procesos
una especificacibn secuencial del comportamiento.
TambiCn puede contener una tabla de activacidn de Monitorizar y controlar el sistema o 1 0 0 1 1
Activarldesactivar el sistema 0 1 0 0 0 0
procesos (TAP)-una especificacidn combinatoria del Visualizar mensaies y estado 1 0 1 1 1 1
comportamiente. En la Secci6n 12.4.4. se presenta- lnteractuar con el usuario 1 0 0 1 0 1
ron 10s atributos inherentes de la EC. Ahora es el
momento de examinar un ejemplo de esta importante FIGURA 12.24. Tabla de activacion de procesos para
notaci6n del modelado del analisis estructurado. HogarSeguro.
CAPfTULO 1 2 MODELADO DEL ANALISIS
Para ilustrar el uso de la EP consideremos el proce- ta secundaria de contraseiias (estas pueden asignarse a
so que representa la transformaci6n del modelo de flu- invitados o trabajadores que necesitan entrar en la casa
jo de Hogarseguro (Figura 12.20). La EP para esta cuando el propietario no esti presente). Si la contraseiia
coincide con alguna de las de la lista, aontraseiia vali-
funci6n puede tomar la siguiente forma: dada = true> es pasada a la funcion visualizar mensajes
EP: proceso y estado. Si no existe coincidencia, <contraseiia valida-
da = false> se pasa a la funcion visualizar mensajes y
Procesar la contraseiia lleva a cab0 la validation de
estado.
todas las contraseiias del sistema HogarSeguro. Proce-
sar la contraseiia recibe una contraseiia de 4 digitos des- Si en esta etapa se desea incluir detalles algorit-
de la funcion interactuar con el usuario. La contraseiia micos adicionales, se puede incluir como parte de la
primer0 se compara con la contraseiia maestra almace-
nada en el sistema. Si a1 contrastar con la contraseiia
EP su representation en lenguaje de descripci6n de
maestra, <contraseiia validada = true> se pasa a la fun- programa. Sin embargo, muchos piensan que se debe
ci6n visualizar mensajes y estado. Si la comparacion no posponer la versi6n en LDP hasta que comience el
es correcta, 10s cuatro digitos se comparan con una lis- diseiio.
El modelo de analisis acompaiia representaciones de c6mo lo usan (por ejemplo, como entrada a1 proceso,
objetos de datos, funciones y control. En cada repre- como salida del proceso, como almacCn de datos,
sentaci6n 10s objetos de datos y/o elementos de control como entidad extema).
juegan un papel importante. Por consiguiente, es nece- Descripcibn del contenido+l contenido represen-
sario proporcionar un enfoque organizado para repre- tad0 mediante una notation.
sentar las caracteristicas de cada objeto de datos y
Inforrnacidn adicional--otra informaci6n sobre 10s
elemento de control. Esto se realiza con el diccionario
de datos. tipos de datos, 10s valores implicitos (si se conocen),
Se ha propuesto el diccionario de datos como gra- las restricciones o limitaciones, etc.
mhtica casi formal para describir el contenido de 10s Una vez que se introducen en el diccionario de
objetos definidos durante el anhlisis estructurado. Esta datos un nombre y sus alias, se debe revisar la con-
importante notaci6n de modelado ha sido definida de la sistencia de las denominaciones. Es decir, si un equi-
siguiente forma [YOU89]: po de anhlisis decide denominar un elemento de datos
El diccionario de datos es un listado organizado de todos reciCn derivado como xyz, per0 en el diccionario ya
10s elementos de datos que son pertinentes para el sistema, con existe otro llamado xyz, la herramienta CASE que
definiciones precisas y rigurosas que permiten que el usuario soporta el diccionario muestra un mensaje de alerta
y el analista del sistema tengan una misma comprensi6n de las sobre la duplicidad de nombres. Esto mejora la con-
entradas, salidas, de las componentes de 10s almacenes y [tam- sistencia del modelo de analisis y ayuda a reducir
biCn] de 10s cdculos intermedios.
errores.
La informacion de ~ d 6 n d ese usa/c6mo se usa>>se
~ C O representar
~ O
el contenido de 10s objetos
registra automhticamente a partir de 10s modelos de
de datos que han sido
flujo. Cuando se crea una entrada del diccionario, la
identificados?
herramienta CASE inspecciona 10s DFD y 10s DFC
para determinar 10s procesos que usan el dato o la
Actualmente, casi siempre se implementa el dic- informacion de control y como lo usan. Aunque esto
cionario de datos como parte de una <<herramienta pueda no parecer importante, realmente es una de las
CASE de analisis y diseiio estructurados>>.Aunque mayores ventajas del diccionario. Durante el anhli-
el formato del diccionario varia entre las distintas sis, hay una corriente casi continua de cambios. Para
herramientas, la mayoria contiene la siguiente infor- proyectos grandes, a menudo es bastante dificil deter-
maci6n: minar el impact0 de un cambio. Algunas de las pre-
nornbre+l nombre principal del elemento de datos guntas que se plantea el ingeniero del software son
cridonde se usa este elemento de datos? iquC mas hay
o de control, del almacCn de datos, o de una entidad
externa. que cambiar si lo modificamos? j c d l sera el impac-
to general del cambia?,,. A1 poder tratar el dicciona-
alias-otros nombres usados para la primera rio de datos como una base de datos, el analista puede
entrada. hacer preguntas basadas en ~ d 6 n d ese usa/c6mo se
ddnde se usalcdrno se usa-un listado de 10s proce- usa>>y obtener respuestas a peticiones similares a las
sos que usan el elemento de datos o de control y anteriores.
lNGENlERfA DEL SOFTWARE. UN ENFOQUE PRACTICO
Para ilustrar el uso del diccionario de datos, volva-

mos a1 DFD de nivel2 y del proceso monitorizar el sis-
tema de HogarSeguro, mostrado en la Figura 12.2 1.
RefiriCndonos a la figura, especificamos el elemento de
Herrarnientas CASE datos numero de telefono. ~ Q u Ces exactamente un
Andlisis Estructurado ndmero de telkfono? Puede ser un ndmero local de sie-
te digitos, una extension de 4 digitos, o una secuencia
La notaci6n utilizada para desarrollar una descrip- de 25 digitos para llamadas de larga distancia. El dic-
ci6n de contenido se indica en la siguiente tabla: cionario de datos nos proporciona una definici6n pre-
- -- -- - -- -
cisa de numero de telefono para el DFD en cuestion.

Construccion Notacion Significado Ademhs, indica d6nde y c6mo se usa este elemento de
de datos datos y cualquier informaci6n adicional que le sea rele-
Agregacion - esti compuesto de vante. La entrada del diccionario de datos comienza de
la siguiente forma:
Secuencia + Y
Seleccion [11 uno u otro nombre: numero de telCfono
alias: ninguno
Repeticion ( 1" n repeticiones de
dbnde se usaic6mo se usa: comprobar con ajustes inicia-
( > datos opcionales les (salida)
* ...* delimitadores marcar numero (entrada)
de comentarios descripcidn:
numero de telCfono = prefijo + numero de acceso
La notacion permite a1 ingeniero del software repre- prefijo = [ * un numero de cuatro digitos que comience en
sentar una composici6n de datos en una de las tres alter- 0 6 un n h e r o de cinco digitos que comience por 01
nativas fundamentales que pueden ser construidas n h e r o de acceso = *secuencia nurnkrica de cualquier tarna-
1. Como una secuencia de elementos de datos. fio*
2. Como una seleccidn de entre un conjunto de ele- Un ndmero como el 01327 546381 queda descrito
mentos de datos. de esta forma.
3. Como una agrupacibn repetitiva de elementos de datos. Para grandes sistemas basados en computadora el
Cada entrada de elemento de datos que aparezca como diccionario de datos crece rhpidamente en tamafio y en
parte de una secuencia, una selecci6n o una repetition complejidad. De hecho, es extremadamente dificil man-
puede a su vez ser otro elemento de datos compuestos tener manualmente el diccionario. Por esta razon, se
que necesite un mayor refinamiento en el diccionario. deben usar herramientas CASE.
Durante 10s dltimos afios se han utilizado otros mCto- Te'cnicas de analisis y disefio estructurado (TADE)
dos valiosos de analisis de requisitos del software en la [ROS77, ROS851
industria. Mientras que todos siguen 10s principios del son presentadas dentro del sitio web SEPA para 10s lecto-
anilisis operational tratados en el Capitulol 1,cada uno res interesados en profundizar en el modelado del an6lisis.
introduce una notacidn y heunstica diferentes para cons-
truir el modelo de anhlisis. Una revision de tres irnpor-
tantes mCtodos de anhlisis:
Desarrollo de sistemas estructurados de datos
(DSED) [WAR81,ORR811
Desarrollo de sistemas Jackson (DSJ) [SAC831 DSSD, JSD, y SADT
El anhlisis estructurado es el mCtodo mhs usado para el de todos 10s objetos de datos que son importantes para
modelado de requisitos, utiliza el modelo de datos y el el sistema. Los sistemas de datos y flujo de control son
modelo de flujos para crear la base de un adecuado la base de representation de la transformaci61-1de datos
modelo de anhlisis. Utilizando el diagrama entidad-rela- y control. A1 mismo tiempo, estos mCtodos son usados
cion, el ingeniero del software crea una representacitin para crear un modelo funcional del software y proveer-
CAPiTULO 12 M O D E L A D O DEL ANALISIS
se de un mecanismo para dividir funciones. DespuCs, de datos convencionales, per0 ahora hay ampliacio-
. crea un modelo de comportamiento usando el diagra- nes que permiten aplicar el mCtodo a 10s sistemas de
ma de transici6n de estados y un modelo de contenido tiempo real.
de 10s datos con un diccionario de datos. Las especifi- El analisis estructurado esta soportado por una
caciones de 10s procesos y del control proporcionan una larga lista de herramientas CASE que ayudan en la
elaboration adicional de 10s detalles. creacion de cada elemento del modelo y tambiCn
La notacion original para el andisis estructurado en el mantenimiento de la consistencia y de la
fue desarrollada para aplicaciones de procesamiento correccion.
[BRU88] Bruyn, W. et al., ((ESML: An Extended Systems [ROS77] Ross, D., y K. Schoman, ((StructuredAnalysis for
Modeling Language Based on the Data Flow Diagram,,, Requirements Definitions)),IEEE Trans. Software Engi-
ACM Software Engineering Notes, vol. 13, n." 1, Enero neering, vol. 3, n." 1 , Enero 1977, pp. 6-15.
1988, pp. 58-67. [ROS84] Ross, D., ((Applications and Extensions of SADTD,
[CHE77] Chen, P., The Entity-Relationship Approach to Logi- IEEE Computer, vol. 18, n." 4, Abril 1984, pp. 25-35.
cal Database Design, QED Information systems, 1977. [STE74] Stevens, W.P., G.J. Myers y L.L. Constantine,
[DEM79] DeMarco, T., Structured Analysis and System Spe- ccstructured Design,,, IBM Systems Journal, vol. 13, n." 2,
rrfirartion, Prentice-Hall, 1979. 1974, pp. 115-139.
[GAN82] Gane, T., y C. Sarson, Structured Systems Analy- [TIL93] Tillman, G.A., A Practical Guide to Logical Data
sis, McDonnell Douglas, 1982. Modeling, McGraw-Hill, 1993.
[HAT871 Hatley, D.J., e LA. Pirbhai, Strategies,for Real- [WAR811 Wamier, J.D., Logical Construction of Programs,
Time System Specification, Dorset House, 1987. Van Nostrand Reinhold, I98 1.
[JAC83] Jackson, M.A., System Development, Prentice-Hall, [WAR851 Ward, P.T., y S.J. Mellor, Structured Development
1983. for Real-Time Systems, tres volumenes, Yourdon Press, 1985.
[ORR8 11 Orr, K.T., Structured Requirements Definition, Ken [YOU781 Yourdon, E.N., y L.L. Constantine, Structured
Orr & Associates, Inc., Topeka, KS, 1981. Design, Yourdon Press, 1978.
[PAC801 Page-Jones, M., The Practical Guide to Structured [YOU891 Yourdon, E.N., Modern StructuredAnalysis, Pren-
Systems Design, Yourdon Press, 1980. tice Hall, 1990.
12.1. Obtenga al menos tres de las diferencias que se men- 12.4. Dibuje un modelo de nivel de contexto (DFD de nivel
cionan en la secci6n 12.1 y escriba un breve articulo que 0) para uno de 10s cinco sistemas que se listan en el problema
refleje el cambio a lo largo del tiempo de la concepci6n 12.2. Escriba una descripcidn de procesamiento a nivel de con-
del aniilisis estructurado. En una secci6n de conclusiones, texto para el sistema.
sugiera formas en las que crea que cambiarh el mCtodo en 12.5. Mediante el DFD de nivel de contexto desarrollado en
el futuro. el problema 12.4, desarrolle diagramas de flujo de datos de
12.2. Se le pide que construya uno de 10s sistemas siguientes: nivel 1 y nivel2. Utilice un ccanalizador gramaticaln en la des-
un sistema de registro en cursos basado en red para su uni- cripcidn de procesamiento a nivel de contexto para que se ini-
versidad cie en ese tema. Recuerde especificar todo el flujo de
informacidn etiquetando todas las flechas entre burbujas. Uti-
un sistema procesamiento de transacciones basado en inter-
lice nombres significativos para cada transformaci6n.
net para un almacCn de computadoras
un sistema simple de facturas para una empresa pequeiia 12.6. Desarrolle DFC, EC, EP y un diccionario de datos para
el sistema que seleccion6 en el problema 12.2. Intente cons-
un producto de software que sustituya a rolodex construi- truir su modelo tan completo como sea posible.
do en un telCfono inaliimbrico
12.7. ~Significael concept0 de continuidad del flujo de infor-
un producto de libro de cocina automatizado construido en
macidn que si una flecha de flujo aparece como entrada en el
una cocina elkctrica o en un microondas
nivel 0, entonces en 10s subsiguientes niveles debe aparecer
Seleccione el sistema que le sea de inter& y desarrolle un una flecha de flujo como entrada? Explique su respuesta.
diagrama entidad-relacid; que describa 10s objetos de datos,
relaciones y atributos. 12.8. Usando las arnpliaciones de Ward y Mellor descritas en
las figuras 12.13. iC6m0 encaja la EC que se indica en la figu-
12.3. ~ Q u C
diferencia hay entre cardinalidad y modalidad? ra 12.13? Ward y Mellor no usan esa notacidn.
INGENIER~A
12.9. Usando las ampliaciones de Hatley y Pirbhai, rehaga el (determinada a partir de su tamafio). A cada bache se le
modelo de flujo contenido en la Figura 12.13. iC6mo encaja asocian datos de-petici6n de obra, incluyendo la ubicaci6n
el modelo de control que se indica en la Figura 12.13? Hatley y el tamaiio, la brigada, el equipamiento asignado, las horas
y Pirbhai no usan esa notaci6n. de reparacibn, el estado del bache (obra en curso, repara-
12.10. Describa con sus propias palabras un flujo de sucesos. do, reparaci6n temporal, no reparado), la cantidad de mate-
rial de relleno usado y el coste de la reparacidn (calculado
12.11. Desarrolle un modelo de flujo completo para el soft- con las horas dedicadas, el numero de trabajadores, el mate-
ware de fotocopiadora discutido en la secci6n 12.5. Puede uti- rial y el equipamiento usados). Finalmente, se crea un archi-
lizar las ampliaciones de Ward y Mellor o las de Hatley y vo de dafios para mantener la informaci6n sobre 10s dafios
Pirbhai. Aseglirese de desarrollar para el sistema un diagrama reportados debidos a la existencia del bache, incluyendo
de transicion de estados detallado. el nombre del ciudadano, su direccion, su numero de tele-
12.12. Complete la description de procesamiento para el soft- fono, el tipo de dafio y el coste de subsanamiento del dafio.
ware HogarSeguro que se ha presentado en la Figura 12.20, El sistema SSRB es un sistema interactive.
describiendo 10s mecanismo de interaccion entre el usuario y Utilice el anilisis estructurado para modelar SSRB.
el sistema. ~ C a m b i a rsu
i informacidn adicional 10s modelos
de flujo de HogarSeguro que aparecen en este capitulo? Si es 12.14. Se va a desarrollar un sistema de procesamiento de tex-
asi, jcomo? tos basados en computadoras personales. Investigue durante algu-
nas horas sobre el area de aplicacion y lleve a cab0 una reunion
12.13. El departamento de obras publicas de un gran ciudad TFEA (Capitulo 11) con sus compaiierosde clase para un mode-
ha decidido desarrollar un sistema de seguimiento y repara- lode requisitos del sistema utilizando el anilisis estructurado (su
cicin de baches (SSRB)basado en pagina web. Con 10s siguien- profesor le ayudar5a coordinarlo). Construya un modelo de requi-
tes requisitos: sitos del sistema mediante el anilisis estructurado.
Los ciudadanos pueden conectarse a la pagina e infor-
12.15. Se va a desarrollar el software para un videojuego. Pro-
mar sobre la situacidn y la importancia del bache. A medi-
ceda como en el problema 12.14.
da que se informa sobre cada bache, se le asigna un numero
de identificacion y se guarda con la calle en la que se 12.16. Contacte con cuatro o cinco vendedores de herramien-
encuentra, su tamafio (en una escala de 1 a lo), su posi- tas CASE para anilisis estructurado. Revise sus folletos y escri-
cidn (en el medio, a un lado, etc.), su distrito (determina- ba un breve articulo que resuma las caracteristicas generales
do a partir de la calle) y una prioridad de reparacidn y las que se distingan a unas herramientas de las otras.
Existen literalmente docenas de libros publicados sobre el ani- Analysis and Design Methodology, Van Nostrand Reinhlod,
lisis estructurado. Todos cubren el tema de forma adecuada, 1990) y Hares (SSADMfor the Advanced Practitioner, Wiley,
per0 solo unos pocos constituyen magnificos trabajos. El libro 1990) describe SSADM como una variacion del anilisis
de DeMarco [DEM79] sigue siendo una buena introduccion estructurado que se utiliza enormemente por toda Europa y
de la notacidn basica. Los libros de Hoffer et al. (Modern Sys- Estados Unidos.
tems Anulysis and Design, Addison-Wesley, 2.aed., 1998),Ken- Flynn et al. (Information Modelling: An International Pers-
dall y Kendall (Systems Analysis and Design, 2." ed., Prentice pective, Prentice Hall, 1996), Reingruber y Gregory (Data
Hall, 1998), Davis y Yen (The Information System Consultant's Modeling Handbook, Wiley, 1995) y Tillman [TIL93] pre-
Handbook: Systems Analysis and Design, CRCPress,1998), sentan manuales detallados para crear modelos de datos de
Modell (A Professional's Guide to Systems Analysis, 2." ed., calidad de industria. Kim y Salvatores (&omparing Data
McGraw-Hill, 1996),Robertson and Robertson (Complete Sys- Modeling Formalisms)), Communications of the ACM, June
tems Analysis, 2 vols., Dorset House, 1994), y Page-Jones (The 1995) han escrito una comparacion excelente de mCtodos de
Practical Guide to Structured Systems Design, 2." ed., Prenti- modelado de datos. Un libro interesante de Hay (Data Mode-
ce Hall, 1988) son referencias muy valiosas. El libro de Your- ling Patterns, Dorset House, 1995) presenta 10s qatronesx
don sobre este tema [YOU891 sigue siendo el tratado m i s comunes de modelos de datos que se encuentran en muchas
extenso publicado hasta la fecha. empresas diferentes. En Kowal (Behaviour Models: Speci-
Para mayor Cnfasis en la ingenieria, [WAR851 y [HAT871 fying User's E.xpectations, Prentice-Hall, 1992) se puede
son 10s libros preferidos. En cualquier caso, Edwards (Real- encontrar un tratamiento detallado del modelado de compor-
Time Structured Methods: Systems Analysis, Wiley, 1993) tratamiento.
ta el anilisis de sistemas en tiempo real con gran profundidad, Una amplia variedad de fuentes de information sobre
presentando diagramas de ejemplos litiles sobre aplicaciones el anilisis estructurado estin disponibles en internet. Una
reales. lista actualizada de paginas web que son interesantes sobre
Se han desarrollado muchas variaciones sobre el analisis el concept0 y mCtodos d e anilisis se encuentran en
estructuradodurante la ultima dkada. Cutts (StructuredSystems
CONCEPTOS Y PRlNClPlOS
DE DISENO
Palabras c l a v e
abstracci6n
atoplamiento
arquitedura
223
231
226
E L objetivo de 10s disefiadores es producir un modelo o representaci6n de una entidad que
se sera construida a posteriori. Belady describe el proceso mediante el cual se desarro-
Ila el modelo de disefio [BEL8 11:
En coalquier proceso de disefio existen dos fases importantes: la diversificacicin y la convergencia. La
cohesi6n 230 diversificacidn es la adqrrisicidrr de un repertorio de alternativas, de un material primitivo de diseiio: com-
conceptos de diseiio 223 ponentes, soluciones de componentes y conocimiento, todo dentro de cattilogos, de libros de texto y en la
mente. Durante la convergencia, el diseiiador elige y combina 10s elementos adecuados y extraidos de este
criterios de calidad 221
repertorio para aatisfacer 10s objetivos del diseiio, de la misma manera a como se establece en el documento
cstructura de datos 228 de 10s requisites, y de la manera en que se acordd con el cliente. La segunda fase es la elitnirruc,idt~gradual
heuristica de diseiio 231 de cualquier configuracicin de componentes except0 de una en particular. y de aqui la creacicin del product0
independencia final.
funtional . 229 La diversificaci6n y la convergencia combinan intuicidn y juicio en funci6n de la experien-
modularidad 224 cia en construir entidades similares; un conjunto de principios y/o heuristics que proporcionan
ocultackn la forma de guiar la evoluci6n del modelo; un conjunto de criterios que posibilitan la calidad
de informacih 229 que se va a juzgar, y un proceso de iteracidn que por liltimo conduce a una representacidn final
particion 227 de disefio.
principios de diseiio 222
refinamiento 224
~QuiCn
lo hacc? El ingeniero del soft-
ware e s quien diseiia 10s sistemas ~CBrnopuedo edar seguro de que lo
basados en computadora, pero 10s he hecho correctamente?En cada
conocimientos que se requieren en LCuLles sen 10s pasos? El diseiio etapa se revison 10sproductos del dise-
cadu nivel de diseiio Iuncionan de dife- camienza con el modelo de 10s requi- iio del software en cuanto a claridad,
rentes maneras. En el nivel de datos y sites. Se trabaja por transformar este canecci6n. fiializaci6n y consistencia,
de arquitectura, el diseiio se centra en mode10 y abtener cuatro niveles de y se comparan con 10s requisitos y unos
10s p ~ t r o n e sde la misma manera a detalles de diseiio: la estructura de con otros.
El disefio del software, a1 igual que 10s enfoques de disefio de ingenieria en otras discipli-
nas, va cambiando continuamente a medida que se desarrollan mCtodos nuevos, anilisis mejo-
res y se amplia el conocimiento. Las metodologias de disefio del software carecen de la
profundidad, flexibilidad y naturaleza cuantitativa que se asocian normalmente a las discipli-
nas de diseiio de ingenieria mAs cliisicas. Sin embargo, si existen mdtodos para el diseiio del
software; tambidn se dispone de calidad de disefio y se pueden aplicar notaciones de diseiio.
En este capitulo se explorariln los conceptos y principios fundamentales que se pueden aplicar
a todo diseiio de software. En los Capitulos 14, 15, 16 y 22 se examinan diversos mCtodos de
disefio de software en cuanto a la manera en que se aplican a1 disefio arquitect6nic0, de inter-
faz y a nivel de componentes.
--- - - -----
, 13.1 .DISERO DEL SOFTWARE E I N G E N I E R ~ ADEL SOFTWARE __
El disefio del sof~warese encuentra en el nucleo tCcni-

co de la ingenieria del software y se aplica indepen-
dientemente del modelo de diseiio de software que se
utilice. Una vez que se analizan y especifican 10s requi-
sitos del software, el disefio del software es la primera
de las tres actividades tCcnicas --disefio, generaci6n de
c6digo y pruebas- que se requieren para construir y
verifi car el software. Cada actividad transforma la infor-
maci6n de manera que de lugar por ultimo a un soft-
ware de computadora validado.
10s milagros rnbs tomunes de la ingenieria

del sohare son las transiciones desde el anblisis
hash el diseiio, y desde el diilio 01 cCdigo.
Richard Due
Cada uno de 10s elementos del niodelo de andli-

sis (Capitulo 12) proporciona la informaci6n nece-
saria para crear 10s cuatro modelos de disefio que se FIGURA 13.1. Conversion del modelo de analisis
requieren para una especificaci6n completa de dise- en un diseiio de software.
iio. El flujo de informaci6n durante el diseiio del soft-
ware se muestra en la Figura 13.1. Los requisitos del El disefio d e la inrerfaz describe la manera de
software, manifestados por 10s modelos de datos fun- comunicarse el software dentro de s i mismo, con sis-
cionales y de comportamiento, alimentan la tarea del temas que interoperan dentro de CI y con las personas
disefio. Mediante uno de 10s muchos mktodos de dise- que lo utilizan. Una interfaz implica un flujo de infor-
fio (que se abarcarin en capitulos posteriores) la tarea maci6n (por ejeniplo, datos y/o control) y un tip0 espe-
de diseiio produce un disefio de datos, un diseiio cifico de comportamiento. Por tanto, 10s diagramas
arquitecthico, un disefio de interfaz y un disefio de de flujo de control y de datos proporcionan gran par-
componentes. te de la informaci6n que se requiere para el disefio de
El diseiio de daros transforma el modelo del domi- la interfaz.
nio de informaci6n que se crea durante el andlisis en las El disefio a nivel de componentes transforma 10s ele-
estructuras de datos que se necesitarin para implemen- mentos estructurales de la arquitectura del software en
tar el software. Los objetos de datos y las relaciones una descripci6n procedimental de 10s componentes del
definidas en el diagrama relacion entidad y el conteni- software. La informaci6n que se obtiene de EP, EC y
do de datos detallado que se representa en el dicciona- de DTE sirve como base para el diseiio de 10s compo-
rio de datos proporcionan la base de la actividad del nentes.
diseiio de datos. Es posible que parte del disefio de datos La importancia del disefio del software se puede
tenga lugar junto con el diseiio de la arquitectura del describir con una sola palabra -calidad-. El dise-
software. A medida que se van diseiiando cada uno de fio es el lugar en donde se fomentari la calidad en la
10s componentes del software, van apareciendo mhs ingenieria del software. El disefio proporciona las
detalles de diseiio. representaciones del software que se pueden evaluar
El diseiio nrqliirectdnico define la relaci6n entre en cuanto a calidad. El disefio es la linica forma de
10s elementos estructurales principales del software, convertir exactamente 10s requisitos de un cliente en
10s patrones de disefio que se pueden utilizar para un producto o sistema de software finalizado. El dise-
lograr 10s requisitos que se han definido para el sis- fio del software sirve como fundamento para todos 10s
tema, y las restricciones que afectan a la manera en pasos siguientes del soporte del software y de la inge-
que se pueden aplicar 10s patrones de diseiio arqui- nieria del software. Sin un diseiio, corremos el ries-
tect6nicos [SHA96]. La representaci6n del disefio go de construir un sistema inestable -un sistema que
arquitectonico -el marco de trabajo de un sistema fallari cuando se lleven a cab0 cambios; un sistema
basado en computadora- puede derivarse de la espe- que puede resultar dificil de comprobar; y un sistema
cificaci6n del sistema, del modelo de andlisis y de la cuya calidad no puede evaluarse hasta muy avanzado
interaction del subsistema definido dentro del mode- el proceso, sin tiempo suficiente y con mucho dinero
lo de anhlisis. gastado en 61-.
C A P ~ T U L O13 CONCEPTOS Y PRINCIPIOS DE DISENO
El disefio del software es un proceso iterativo mediante iExisten directrices

el cud 10s requisitos se traducen en un ccplano~para cons- generales que lleven
truir el software. Inicialmente, el plano representa una a un buen diseiio?
visi6n holistica del software. Esto es, el disefio se repre-
senta a un nivel alto de abstracci6n -un nivel que puede 3. Un disefio deberh contener distintas representacio-
rastrearse directamente hash conseguir el objetivo del sis- nes de datos, arquitectura, interfaces y componentes
tema especifico y segun unos requisitos rnhs detallados (m6dulos).
de comportamiento, funcionales y de datos-. A medida 4. Un disefio deberh conducir a estructuras de datos ade-
que ocurren las iteraciones del disefio, el refinamiento cuadas para 10s objetos que se van a implementar y
subsiguiente conduce a representacionesde disefio a nive- que procedan de patrones de datos reconocibles.
les de abstracci6n mucho rnhs bajos. Estos niveles se 5. Un disefio deberh conducir a componentes que pre-
podrh raswear aun seglin 10s requisitos, per0 la conexi6n senten caracteristicas funcionales independientes.
es rnhs sutil. 6. Un disefio deberh conducir a interfaces que reduz-
can la complejidad de las conexiones entre 10s m6du-
13.2.1. Diseiio y calidad del software 10s y con el entomo externo.
A lo largo de todo el proceso del disefio, la calidad de 7. Un diseiio deberh derivarse mediante un mktodo repe-
la evoluci6n del disefio se eval\ia con una serie de revi- titivo y controlado por la informaci6n obtenida
siones tkcnicas fonnales o con las revisiones de disefio durante el anhlisis de 10s requisitos del software.
abordadas en el Capitulo 8. McGlaughlin [MCG91] Estos criterios no se consiguen por casualidad. El pro-
sugiere tres caracteristicas que sirven como guia para ceso de disefio del software fomenta el buen disefio a tra-
la evaluaci6n de un buen disefio: vCs de la aplicaci6n de principios de disefio fundamentales,
el disefio deberh implementar todos 10s requisitos de metodologia sistemhtica y de una revisi6n cuidadosa.
explicitos del modelo de anhlisis, y deberhn ajustarse
a todos 10s requisitos implicitos que desea el cliente;
el disefio deberh ser una guia legible y comprensible
para aquellos que generan c6digo y para aquellos que
comprueban y consecuentemente,dan soporte a1 soft-
ware;
el disefio deberh proporcionar una imagen completa
del software, enfrenthndose a 10s dominios de com-
portamiento, funcionales y de datos desde una pers-
pectiva de implementaci6n.
13.2.2. La e v o l u c i h del diseiio del software
La evolution del disefio del software es un proceso con-
tinuo que ha abarcado las liltimas cuatro dCcadas. El pri-
mer trabajo de disefio se concentraba en criterios para el
desarrollo de programas modulares [DEN731 y mCtodos
para refinar las estructuras del software de manera des-
cendente [WIR71]. Los aspectos procedimentales de la
Con el fin de evaluar la calidad de una representaci6n definici6n de disefio evolucionaron en una filosofia deno-
de disefio, deberhn establecerse 10s criterios tkcnicos para minada programacibn estructurada [DAH71, MIL721.
un buen disefio. Mhs adelante en este mismo capitulo, se Un trabajo posterior propuso m6todos para la conversi6n
abordarh rnhs detalladarnente 10s criterios de calidad del del flujo de datos [STE74] o estructura de datos [JAC75,
disefio. Por ahora se presentah las siguientes directrices: WAR741 en una definici6n de disefio. Enfoques de dise-
1. Un disefio deberh presentar una estructura arquitecto- fio rnhs recientes hacia la derivaci6n de disefio proponen
nica que (1) se haya creado mediante patrones de disefio un mCtodo orientado a objetos. Hoy en dia, se ha hecho
reconocibles, (2) que estC formada por componentes hincapik en un disefio de software basado en la arquitec-
que exhiban caracteristicas de buen disefio (aquellas tura del software [GAM95, BUS96, BR0981.
que se abordarh m b adelante en este mismo capitulo), Independientemente del modelo de disefio que se uti-
y (3) que se puedan implementar de manera evolutiva, lice, un ingeniero del software deberh aplicar un con-
facilitando asi la implementaci6n y la comprobaci6n. junto de principios fundamentales y conceptos bhsicos
2. Un disefio deberh ser modular; esto es, el software para el disefio a nivel de componentes, de interfaz, arqui-
deberh dividirse 16gicamenteen elementos que rea- tectonic0 y de datos. Estos principios y conceptos se
licen funciones y subfunciones especificas. estudian en la secci6n siguiente.
El disefio de software es tanto un proceso como un El disefio deberci presentar uniformidad e integracibn.
modelo. El proceso de diseiio es una secuencia de pasos Un disefio es uniforme si parece que fue una persona
que hacen posible que el disefiador describa todas 10s la que lo desarroll6 por completo. Las reglas de estilo
aspectos del software que se va construir. Sin embargo, y de formato deberin definirse para un equipo de
es importante destacar que el proceso de diseiio sim- disefio antes de comenzar el trabajo sobre el disefio.
plemente no es un recetario. Un conocimiento creativo, Un disefio se integra si se tiene cuidado a la hora de
experiencia en el tema, un sentido de lo que hace que definir interfaces entre 10s componentes del disefio.
un software sea bueno, y un compromiso general con El diseiio deberci estructurarse para admitir cam-
la calidad son factores criticos de Cxito para un disefio bios. Los conceptos de disefio estudiados en la sec-
competente. ci6n siguiente hacen posible un disefio que logra este
El modelo de disefio es el equivalente a 10s planes principio.
de un arquitecto para una casa. Comienza representan- El disefio deberci estructurarse para degradarse poco
do la totalidad de todo lo que se va a construir (por ejem- a poco, incluso cuando se enfrenta con datos, suce-
plo, una representaci6n en tres dimensiones de la casa) sos o condiciones de operacibn aberrantes. Un soft-
y refina lentamente lo que va a proporcionar la guia para ware bien disefiado no deberi nunca explotar como
construir cada detalle (por ejemplo, el disefio de fonta- una <<bombs>>. Deberi disefiarse para adaptarse a cir-
neria). De manera similar, el modelo de disefio que se cunstancias inusuales, y si debe terminar de funcio-
crea para el software proporciona diversas visiones dife- nar, que lo haga de forma suave.
rentes de software de computadora.
Los principios bisicos de disefio hacen posible que
el ingeniero del software navegue por el proceso de dise-
fio. Davis [DAV95] sugiere un conjunto' de principios
para el disefio del software, 10s cuales han sido adapta- l o consistencio del diseiio y lo uniformidod es crucial
dos y ampliados en la lista siguiente: cuondo se von o construir sistemus grondes. Se deber6
En el proceso de disefio no deberci utilizarse <<ore- estoblecer un coniunto de reglos de diseiio poro el equipo
jerasu. Un buen disefiador deberi tener en cuenta del sohore ontes de comenzor o troboior.
enfoques alternativos, juzgando todos 10s que se El disefio no es escribir cbdigo y escribir cbdigo no
basan en 10s requisitos del problema, 10s recursos es disefiar. Incluso cuando se crean disefios proce-
disponibles para realizar el trabajo y 10s conceptos dimentales para componentes de programas, el nivel
de disefio presentados en la Secci6n 13.4. de abstracci6n del modelo de disefio es mayor que
El disefio deberci poderse rastrear hasta el modelo el c6digo fuente. Las dnicas decisiones de disefio
de ancilisis. Dado que un solo elemento del modelo realizadas a nivel de codificaci6n se enfrentan con
de disefio suele hacer un seguimiento de 10s mdlti- pequefios datos de implementaci6n que posibilitan
ples requisitos, es necesario tener un medio de ras- codificar el disefio procedimental.
trear como se han satisfecho 10s requisitos por el El disefio deberci evaluarse enfuncibn de la calidad
modelo de disefio. mientras se va creando, no despuks de terminarlo.
El diseiio no deberci inventar nada que ya este' Para ayudar a1 disefiador en la evaluaci6n de la cali-
inventado. Los sistemas se construyen utilizando dad se dispone de conceptos de disefio (Secci6n 13.4)
un conjunto de patrones de disefio, muchos de 10s y de medidas de disefio (Capitulos 19 y 24).
cuales probablemente ya se han encontrado antes. El diseiio deberci revisarse para minimizar 10s errores
Estos patrones deberin elegirse siempre como una conceptuales (semcinticos).A veces existe la tenden-
alternativa para reinventar. Hay poco tiempo y 10s cia de centrarse en minucias cuando se revisa el disefio,
recursos son limitados. El tiempo de disefio se olvid5ndose del bosque por culpa de 10s irboles. Un
debera invertir en la representaci6n verdadera de equipo de disefiadores deberi asegurarse de haber
ideas nuevas y en la integraci6n de esos patrones afrontado 10s elementos conceptuales principales antes
que ya existen. de preocuparse por la sintaxis del modelo del disefio.
El diseho deberci ccminimizar la distancia intelec-
tualu [DAV95] entre el software y el problema como
si de la misma vida real se tratara. Es decir, la estruc-
tura del disefio del software (siempre que sea posi- En el Capitulo 8 se presenton Im direchices porn llevar
o cabo revisiines de diiao deaivas.
ble) imita la estructura del dominio del problema.
Aqui solo s e destaca un pequeiio subconjunto de 10s principios

de diseiio de Davis. Para mas informacion, vkase [DAV95].
CAPfTULO 13 CONCEPTOS Y PRINCIPIOS DE DISENO
Cuando 10s principios de diseiio descritos anterior- ejemplo, velocidad, fiabilidad, grado de correcci611, usa-
. mente se aplican adecuadamente, el ingeniero del soft- bilidad)2. Losfactores de calidad internos tienen impor-
ware crea un diseiio que muestra 10s factores de calidad tancia para 10s ingenieros del software. Desde una
tanto intemos como extemos [MEY88]. Losfactores de perspectiva tCcnica conducen a un disefio de calidad alta.
calidad externos son esas propiedades del software que Para lograr 10s factores de calidad intemos, el disefiador
pueden ser observadas fhcilmente por 10s usuarios (por deberh comprender 10s conceptos de diseiio bhsicos.
Durante las 6ltimas cuatro dCcadas se ha experimenta- mentarse directamente. Wasserman [WAS831 propor-
do la evoluci6n de un conjunto de conceptos funda- ciona una definici6n 6til:
mentales de diseiio de software. Aunque el grado de La noci6n psicol6gica de ccabstracci6n~permite concen-
inter& en cada concept0 ha variado con 10s aiios, todos trarse en un problema a algbn nivel de generalizaci6n sin tener
han experimentado el paso del tiempo. Cada uno de ellos en consideraci6n 10s datos irrelevantes de bajo nivel; la utili-
proporcionarhn la base de donde el diseiiador podra apli- zaci6n de la abstracci6n tambikn permite trabajar con concep
car 10s mCtodos de diseiio rnhs sofisticados. Cada uno tos y t6rminos que son familiares en el entorno del problema
sin tener que transformarlos en una eshuctura no familiar.. .
ayudarh a1 ingeniero del software a responder las pre-
guntas siguientes: Cada paso del proceso del software es un refina-
~ Q u Ccriterios se podrhn utilizar para la partici6n del miento en el nivel de abstracci6n de la soluci6n del soft-
software en componentes individuales? ware. Durante la ingenieria del sistema, el software se
iC6m0 se puede separar la funci6n y la estructura de asigna como un elemento de un sistema basado en com-
putadora. Durante el anhlisis de 10s requisitos del soft-
datos de una representacibn conceptual del software?
ware, la soluci6n del software se establece en estos
existe en criterios uniformes que definen la calidad tkrminos: ccaquellos que son familiares en el entomo del
tCcnica de un diseiio de software? problema~.A medida que nos adentramos en el proce-
M.A. Jackson una vez dijo: <<Elcomienzo de la sabi- so de diseiio, se reduce el nivel de abstracci6n. Final-
dun'a para un ingeniero del software es reconocer la dife- mente el nivel de abstracci6n rnhs bajo se alcanza cuando
rencia entre hacer que un programa funcione y conseguir se genera el c6digo fuente.
que lo haga correctamente,,. [JAC875] Los conceptos de A medida que vamos entrando en diferentes niveles
diseiio de software fundamentales proporcionan el mar- de abstracci6n, trabajarnos para crear abstracciones pro-
co de trabajo necesario para conseguir ccque lo haga cedimentales y de datos. Una abstraccidn procedimen-
correctamenten. tales una secuencia nombrada de instrucciones que tiene
una funci6n especifica y limitada. Un ejemplo de abs-
tracci6n procedimental seria la palabra ccabrir~para una
puerta. ccAbrir* implica una secuencia larga de pasos
procedimentales (por ejemplo, llegar a la puerta; alcan-
zar y agarrar el pomo de la puerta; girar el pomo y tirar
de la puerta; separarse a1 mover la puerta, etc.).
13.4.1. Abstraccion
Cuando se tiene en consideracion una soluci6n modu- Como diseiodor, troboje mucho y duro poro derivor
lar a cualquier problema, se pueden exponer muchos obstmcciones tonto procedimentales coma de dotos
niveles de abstraccidn. En el nivel rnhs alto de abstrac- que sirvon poro el problemo que tenyo en ese momento,
ci6n, la soluci6n se pone como una medida extensa pero que tombiin se puedon volver o utilizor en oms
empleando el lenguaje del entorno del problema. En situociones.
niveles inferiores de abstracci6n, se toma una orienta-
ci6n rnhs procedimental. La terminologia orientada a Una abstraccidn de datos es una colecci6n nombra-
problemas va emparejada con la terminologia orientada de datos que describe un objeto de datos (Capitulo
. da a la implementaci6n en un esfuerzo por solucionar 12). En el context0 de la abstracci6n procedimental
el problema. Finalmente, en el nivel rnhs bajo de abs- abrir, podemos definir una abstracci6n de datos llama-
traccibn, se establece la soluci6n para poder imple- da puerta. A1 igual que cualquier objeto de datos, la
En el Capitulo 19 se presenta un estudio mas detallado sobre

10s factores de calidad.
abstracci6n de datos para puerta acompaiiaria a un con- (0 description de informaci6n) que se define a un nivel
.junto de atributos que describen esta puerta (por ejem- alto de abstracci6n. Esto es, la sentencia describe la fun-
plo, tip0 de puerta, direcci6n de apertura, mecanismo ci6n o informaci6n conceptualmente, per0 no propor-
de apertura, peso, dimensiones). Se puede seguir dicien- ciona informaci6n sobre el funcionamiento intemo de
do que la abstracci6n procedimental abrir hace uso de la informaci6n. El refinamiento hace que el diseiiador
la informaci6n contenida en 10s atributos de la abstrac- trabaje sobre la sentencia original, proporcionando cada
ci6n de datos puerta. vez mhs detalles a medida que van teniendo lugar suce-
La abstracci6n de control es la tercera forma de sivamente todos y cada uno de 10s refinamientos (ela-
abstracci6n que se utiliza en el diseiio del software. A1 boraci6n).
igual que las abstracciones procedimentales y de datos,
este tipo de abstracci6n implica un mecanismo de con- 13.4.3. Modularidad
trol de programa sin especificar 10s datos intemos. Un
ejemplo de abstracci6n de control es el semaforo de El concepto de modularidad se ha ido exponiendo des-
sincronizaci6n [KAI83] que se utiliza para coordinar de hace casi cinco dCcadas en el software de computa-
las actividades en un sistema operativo. El concepto dora. La arquitectura de computadora (descrita en la
de abstraccidn de control se estudia brevemente en el Secci6n 13.4.4) expresa la modularidad; es decir, el
Capitulo 14. software se divide en componentes nombrados y abor-
dados por separado, llamados frecuentemente mbdu-
los, que se integran para satisfacer 10s requisitos del
13.4.2. Refinamiento problema.
El refinamiento paso a paso es una estrategia de diseiio Se ha afirmado que <<lamodularidad es el 6nico atri-
descendente propuesta originalmente por Niklaus Wirth buto del software que permite gestionar un programa
[WIR7 11. El desarrollo de un programa se realiza refi- intelectualmente>> [MYE78]. El software monolitico (es
nando sucesivamente 10s niveles de detalle procedimen- decir, un programa grande formado por un unico m6du-
tales. Una jerarquia se desarrolla descomponiendo una lo) no puede ser entendido fhcilmente por el lector. La
sentencia macrosc6pica de funci6n (una abstracci6n pro- cantidad de rutas de control, la amplitud de referencias,
cedimental) paso a paso hasta alcanzar las sentencias del la cantidad de variables y la complejidad global harh
lenguaje de programacion. Wirth [WR7 11 proporciona que el entendimiento est6 muy cerca de ser imposible.
una visi6n general de este concepto: Para ilustrar este punto, tomemos en consideraci6n el
siguiente argument0 basado en obsemaciones humanas
En cada paso (del refinamiento), se descomponeuna o varias
instrucciones del programa dado en instrucciones m b detalla-
sobre la resoluci6n de problemas.
das. Esta descomposicion sucesiva o refinamientode especifi- Pensemos que C(x)es una funci6n que define la com-
caciones termina cuando todas las instrucciones se expresan plejidad percibida de un problema x, y que E(x) es una
en funcion de cualquier computadora subyacente o de cual- funci6n que define el esfuerzo (oportuno) que se requie-
quier lenguaje de programaci6n... De la misma manera que se re para resolver un problema x. Para dos problemas pl
refinan las tareas, 10s datos tambikn se tienen que refinar, des-
componer o estructurar, y es natural refinar el programa y las Y P23 si
especificacionesde 10s datos en paralelo. C ( P ] )> C(P2) (13.la)
Todos 10s pasos del refinamiento implican decisiones de implica que
disefio. Es importante que.. . el programador conozca 10s cri-
terios subyacentes (para decisiones de disefio) y la existencia
de soluciones altemativas...
El proceso de refinamiento de programas propuesto
por Wirth es anhlogo a1 proceso de refinamiento y de
partici6n que se utiliza durante el anhlisis de requisitos.
La diferencia se encuentra en el nivel de detalle de
implementaci6n que se haya tomado en consideraci61-1,
no en el enfoque.
En general, este resultado es por intuici6n obvio. Se

tarda mhs en resolver un proble'ma dificil.
Existe lo tendencio de entror en detolle inmediotomente, Mediante la experimentaci6n humana en la resolu-
soltandose los posos de refinomiento. Esto conduce o ci6n de problemas se ha averiguado otra caracteristica
errores y omisiones y hoce que el diserio seo mis dificil interesante. Esta es,
de revisor. Reolice el refinomiento poso o pmo.
El refinamiento verdaderamente es un proceso de La ecuaci6n (13.2) implica que la complejidad per-

elaboracibn. Se comienza con una sentencia de funci6n cibida de un problema que combina pl y p2 es mayor
que la complejidad percibida cuando se considera cada iComo se puede evaluar un metodo
problema por separado. Teniendo en cuenta la ecuacion de diseiio para determinar si va a
(13.2) y la condicion implicada por la ecuacion (13. l), tondutir a una modularidad efettiva?
se establece que
Capacidad de descomposicion modular. Si
un mCtodo de disefio proporciona un mecanismo
Esto lleva a una conclusion: <<divide
y vencerasn --es
sistematico para descomponer el problema en sub-
mas fhcil resolver un problema complejo cuando se rom-
problemas, reducira la complejidad de todo el pro-
pe en piezas manejables-. El resultado expresado en la
blema, consiguiendo de esta manera una solution
ecuacion (13.3) tiene implicaciones importantes en lo que
modular efectiva.
respecta a la modularidad y a1 software. Es, de hecho, un
argument0 para la modularidad. Capacidad de empleo de componentes modu-
lares. Si un mCtodo de disefio permite ensamblar 10s
componentes de disefio (reusables) existentes en un
sistema nuevo, producira una solucion modular que
No modulorice de mbs. lo simplicidod de coda modulo no inventa nada ya inventado.
se eclipsorb con lo complejidod de lo integrocion. Capacidad de comprension modular. Si un
modulo se puede comprender como una unidad auto-
Es posible concluir de la ecuacion (13.3) que si sub- noma (sin referencias a otros modulos) sera mas facil
dividimos el software indefinidamente, el esfuerzo que de construir y de cambia.
se requiere para desarrollarlo sena minimo. Desgracia-
damente, intervienen otras fuerzas, que hacen que esta Caste total
I del software
conclusion sea (tristemente) falsa. Como muestra la
Figura 13.2, el esfuerzo (coste) para desarrollar un modu-
lo de software individual disminuye a medida que
aumenta el numero total de modulos. Dado el mismo
conjunto de requisitos, tener mas modulos conduce a un
tamafio menor de modulo. Sin embargo, a medida que
aumenta el numero de modulos, tambiCn crece el esfuer-
zo (coste) asociado con la integracion de modulos. Estas
caractensticas conducen tambiCn a la curva total del cos- I II
t
te o esfuerzo que se muestra en la figura. Existe un nume- Nurnero de rnodulos
ro M de modules que daria como resultado un coste FIGURA 13.2. Modularidad y costes de software.
minimo de desarrollo, aunque no tenemos la sofistica-
ci6n necesaria para predecir M con seguridad. Continuidad modular. Si pequefios cambios en
Las curvas que se muestran en la Figura 13.2 pro- 10s requisitos del sistema provocan cambios en 10s
porcionan en efecto una guia util cuando se tiene en modulos individuales, en vez de cambios generali-
consideracion la modularidad. La modularidad debe- zados en el sistema, se minimizara el impacto de 10s
ra aplicarse, per0 teniendo cuidado de estar proximo efectos secundarios de 10s cambios.
a M. Se debera evitar modularizar de mas o de menos.
Proteccion modular. Si dentro de un modulo se
Pero, jc6m0 conocemos el entorno de M? ~ C u a n t ose
produce una condicion aberrante y sus efectos se
debera modularizar el software? Para responder a estas
limitan a ese modulo, se minimizara el impacto de
preguntas se deberan comprender 10s conceptos de
10s efectos secundarios inducidos por 10s errores.
disefio que se estudiaran mas adelante dentro de este
capitulo. Finalmente, es importante destacar que un sistema
se puede disefiar modularmente, incluso aunque su
implernentacion deba ser ccmonolitica>>. Existen situa-
Los rnbtodos de diseiio se estudion en 10s CopVulos 14, ciones (por ejemplo, software en tiempo real, software
15,16y22. empotrado) en donde no es admisible que 10s subpro-
gramas introduzcan sobrecargas de memoria y de velo-
Cuando se tiene en consideracion la modularidad cidad por minimos que Sean (por ejemplo, subrutinas,
surge otra pregunta importante. jC6mo se define un procedimientos). En tales situaciones el software podra
modulo con un tamafio adecuado? La respuesta se y debera disefiarse con modularidad como filosofia pre-
eilcuentra en 10s mCtodos utilizados para definir 10s dominante. El c6digo se puede desarrollar <<enlines,,.
m6dulos dentro de un sistema. Meyer [MEY88] define Aunque el c6digo fuente del programa puede no tener
cinco criterios que nos permitirh evaluar un mCtodo de un aspect0 modular a primera vista, se ha mantenido la
disefio en relacion con la habilidad de definir un siste- filosofia y el programa proporcionaa 10s beneficios de
ma modular efectivo: un sistema modular.
13.4.4. Arquitectura d e l software Familias de sistemas relacionados. El disefio arquitecthi-

co deberi dibujarse sobre patrones repetibles que se basen
La arquitectura del sofmare alude a la ccestructura glo- comunrnente en el diseiio de familias de sistemas similares. En
bal del software y a las formas en que la estructura pro- esencia, el diseiio debera tener la habilidad de volver a utilizar
porciona la integridad conceptual de un sistemau 10s bloques de construcci6n arquitect6nicos.
[SHA95a]. En su forma rnhs simple, la arquitectura es
Dada la especificaci6n de estas propiedades, el
la estructura jerhrquica de 10s componentes del pro-
diseiio arquitect6nico se puede representar median-
grama (mbdulos), la manera en que 10s componentes
te uno o rnhs modelos diferentes [GAR95]. Los
interactuan y la estructura de datos que van a utilizar
modelos estructurales representan la arquitectura
10s componentes. Sin embargo, en un sentido rnhs
como una colecci6n organizada de componentes de
amplio, 10s cccomponentes>>se pueden generalizar para
programa. Los modelos del marco de trabajo aumen-
representar 10s elementos principales del sistema y sus
interacciones3. tan el nivel de abstracci6n del disefio en un intento
de identificar 10s marcos de trabajo (patrones) repe-
tibles del diseiio arquitect6nico que se encuentran en
3
Referencia Web
La STARS Software Architecture Technology Guide
proporciono mas informocion y recursos en la direction
tipos similares de aplicaciones. Los modelos dink-
micos tratan 10s aspectos de comportamiento de la
arquitectura del programa, indicando c6mo puede
cambiar la estructura o la configuraci6n del sistema
en funci6n de 10s acontecimientos externos. Los
www-ast.tds-gn.lmco.com/arch/guide.html
modelos de proceso se centran en el diseiio del pro-
ceso tCcnico de negocios que tiene que adaptar el sis-
Un objetivo del diseiio del software es derivar una
tema. Finalmente 10s modelos funcionales se pueden
representaci6n arquitect6nica de un sistema. Esta repre-
utilizar para representar la jerarquia funcional de un
sentaci6n sime como marco de trabajo desde donde se
sistema.
llevan a cabo actividades de disefio mhs detalladas. Un
conjunto de patrones arquitect6nicos permiten que el
ingeniero del software reutilice 10s conceptos a nivel de
disefio.
Para representar el diseiio arquitecthnicose utilizon
cinco fipos diferentes de modelos.
Se ha desarrollado un conjunto de lenguajes de des-

cripci6n arquitectbnica (LDAs) para representar 10s
modelos destacados anteriormente [SHA95b]. Aunque
se han propuesto muchos LDAs diferentes, la mayoria
proporcionan mecanismos para describir 10s compo-
nentes del sistema y la manera en que se conectan unos
con otros.
Shaw y Garlan [SHA95a] describen un conjunto de
propiedades que deberhn especificarse como parte de 13.4.5. Jerarquia d e control
un diseiio arquitect6nico:
Propiedudes estructurales. Este aspect0 de la representa- La jerarquia de control, denominada tambiCn estructu-
ci6n del disefio arquitect6nico define 10s componentes de un ra de programa, representa la organizaci6n de 10s com-
sistema (por ejemplo, m6dulos, objetos, filtros) y la manera ponentes de programa (m6dulos) e implica una jerarquia
en que esos componentes se empaquetan e interactuan unos de control. No representa 10s aspectos procedimentales
con otros. Por ejemplo, 10s objetos se empaquetan para encap del software, ni se puede aplicar necesariamente a todos
sular tanto 10s datos como el procesamiento que manipula 10s
10s estilos arquitect6nicos.
datos e interactuan mediante la invocaci6n de mktodos (Capi-
tulo 20).
Propiedades extra-funcionales.La descripci6n del diseiio
arquitect6nico debera ocuparse de c6mo la arquitectura de dise-
iio consigue 10s requisites para el rendimiento, capacidad, fia- En el Copltulo 14 se presenm un estudio demllado
bilidad, segundad,capacidad de adaptaci6n y otras caracteristicas
de estitos y potrones orquitett6nicos. fi
del sistema.
Por ejemplo, 10s componentes arquitectonicos de un sistema

cliente/servidor se representan en un nivel de abstraccion diferente.
Para mas detalles vease el Capitulo 28.
226
Para representar la jerarquia control de aquellos esti- La jerarquia de control tambien representa dos carac-
10s arquitect6nicos que se avienen a la representation se tensticas sutiles diferentes de la arquitectura del soft-
utiliza un conjunto de notaciones diferentes. El diagra- ware: visibilidad y conectividad. La visibilidad indica
ma mas corntin es el de forrna de arb01 (Fig. 13.3) que el conjunto de componentes de programa que un com-
representa el control jerirquico para las arquitecturas de ponente dado puede invocar o utilizar como datos, inclu-
llamada y de retorno4. Sin embargo, otras notaciones, so cuando se lleva a cab0 indirectamente. Por ejemplo,
tales como 10s diagramas de Warnier-Orr [ORR77] y un modulo en un sistema orientado a objetos puede acce-
Jackson [JAC83] tambien se pueden utilizar con igual der a1 amplio abanico de objetos de datos que haya here-
efectividad. Con objeto de facilitar estudios postenores dado, ahora bien solo utiliza una pequefia cantidad de
de estructura, definiremos una sene de medidas y terrni- estos objetos de datos. Todos 10s objetos son visibles
nos simples. Segun la Figura 13.3, la profundidad y la para el modulo. La conectividad indica el conjunto de
anchura proporcionan una indicacion de la cantidad de componentes que un componente dado invoca o utiliza
niveles de control y el cimbito de control global, respec- directamente como datos. Por ejemplo, un modulo que
tivamente. El grado de salida es una medida del nume- hace directamente que otro modulo empiece la ejecu-
ro de modulos que se controlan directamente con otro cion esta conectado a el5.
modulo. El grado de entrada indica la cantidad de modu-
10s que controlan directamente un modulo dado.
13.4.6. Divisi6n estructural
Si el estilo arquitectonico de un sistema es jerarquico,
Grado de salida la estructura del programa se puede dividir tanto hori-
zontal como verticalmente. En la Figura 13.4.a la par-
ticion horizontal define ramas separadas de la jerarquia
Profundidad
modular para cada funcion principal del programa. Lo
mddulos de control, representados con un sombreado
mis oscuro se utilizan para coordinar la comunicaci6n
entre ellos y la ejecucion de las funciones. El enfoque
mas simple de la division horizontal define tres parti-
ciones --entrada, transformation de datos (frecuente-
mente llamado procesamiento) y salida-. La division
horizontal de la arquitectura proporciona diferentes
ventajas:
FIGURA 13.3.Terminologias de estructura para un estilo proporciona software mas facil de probar
arquitectonico de llarnada y retorno.
conduce a un software mas facil de mantener
La relacion de control entre 10s modulos se expresa propaga menos efectos secundarios
de la manera siguiente: se dice que un mbdulo que con-
trola otro modulo es superior a 61, e inversamente, se proporciona software mas facil de ampliar
dice que un modulo controlado por otro modulo es
subordinado del controlador [YOU79]. Por ejemplo, en
iCubles son las ventajas
la Figura 13.3 el modulo M es superior a 10s modulos
de la partition horizontal?
a , b y c. El modulo h esta subordinado a1 modulo e y
por ultimo esta subordinado a1 modulo M. Las relacio-
nes en anchura (por ejemplo, entre 10s modulos d y e), Como las funciones principales se desacoplan las
aunque en la practica se puedan expresar, no tienen que unas de las otras, el cambio tiende a ser menos com-
definirse con terrninologia explicita. plejo y las extensiones del sistema (algo muy comun)
tienden a ser mas faciles de llevar a cab0 sin efectos
secundarios. En la parte negativa la division horizontal
Si desorrollomos un sofhvore orientodo o objetos,
suele hacer que 10s datos pasen a traves de interfaces de
no se oplicoron 10s medidos estruchrroles destocodos modulos y que puedan complicar el control global del
oqui Sin embargo, se oplicoron otros (10s que se flujo del programa (si se requiere un movimiento ripi-
obordon en lo Porte Cuorto). do de una funcion a otra).
Una arquitectura de llamada y de retomo (Capitulo 14) es una estruc- En el Capitulo 20, exploraremos el concept0 de herencia para el
tura de programa clasica que descornpone la funcion en una jerar- software orientado a objetos. Un cornponente de prograrna puede
quia de control en donde el prograrna *principal))invoca un nurnero heredar una Iogica de control y/o datos de otro componente sin refe-
de componentes de prograrna que a su vez pueden invocar aun a rencia explicita en el codigo fuente. Los componentes de este tip0
otros cornponentes. seran visibles, pero no estaran conectados directamente. Un dia-
grama de estructuras (Capitulo 14) indica la conectividad.
CAP~TULO
13 CONCEPTOS Y PRINCIPIOS DE DISENO
tienlazadas que contienen elementos escalares, vecto- 13.4.9. Ocultacidn de informacion

res y posiblemente espacios n-dimensionales. Una El concepto de modularidad conduce a todos 10s dise-
estructura jerkquica se encuentra comunmente en apli- iiadores de software a formularse una pregunta impor-
caciones que requieren categorizacion y capacidad de tante: q C o m o se puede descomponer una soluci6n de
asociaci61-1. software para obtener el mejor conjunto de modulos?n
El principio de ocultaci6.n de inforrnacidn [PAR721
sugiere que 10s modulos se caracterizan por las deci-
siones de diseiio que (cada uno) oculta a1 otro. En otras
lnvierto por lo menos todo el tiempo que necesite palabras, 10s modulos deberin especificarse y diseiiar-
diseriando estructuros de dotos, el mismo que pretende se de manera que la informacion (procedimiento y datos)
invertir diseiondo olgoritn~ospara monipulorlos. que esti dentro de un modulo sea inaccesible a otros
Si es osi, se ohorrora much0 tiempo.
modulos que no necesiten esa informacion.
Ocultaci6n significa que se puede conseguir una
Es importante destacar que las estructuras de datos, a1 modularidad efectiva definiendo un conjunto de m6du-
igual que las estructuras de programas, se pueden repre- 10s independientes que se comunican entre si inter-
sentar a diferentes niveles de abstraccion. Por ejemplo, cambiando solo la informacion necesaria para lograr la
una pila es un modelo conceptual de una estructura de funcion del software. La abstraccion ayuda a definir las
datos que se puede implementar como un vector o una lis- entidades (o informacion).
ta enlazada. Dependiendo del nivel de detalle del diseiio,
10s procesos intemos de la pila pueden especificarse o no.
13.4.8. Procedimiento de software

La estructura de programa define la jerarquia de con-
trol sin tener en consideracion la secuencia de proceso Procedimiento
para el modulo
y de decisiones. El procedimiento de software se centra superior
en el procesamiento de cada modulo individualmente.
El procedimiento debe proporcionar una especificacion
precisa de procesamiento, incluyendo la secuencia de Procedimiento
sucesos, 10s puntos de decision exactos, las operaciones para el modulo
repetitivas e incluso la estructura/organizaci6nde datos. subordinado
Existe, por supuesto, una relacion entre la estructura
y el procedimiento. El procesamiento indicado para cada
Procedimiento
modulo debe incluir una referencia a todos 10s modulos para el ~ j l t i m omodulo
subordinados a1 modulo que se esti describiendo. Es . subordinado
decir, una representation procedimental del software se
distribuye en capas como muestra la Figura 13.56. FIGURA 13.5. El procedimiento se distribuye en capas.
Los conceptos fundamentales de diseiio descritos en la tacion de informaci6n. En referencias obligadas sobre
seccion anterior sirven para incentivar diseiios modula- el diseiio del software, Parnas [PAR721y Wirth [WR7 11
res. De hecho, la modularidad se ha convertido en un aluden a las tCcnicas de refinamiento que mejoran la
enfoque aceptado en todas las disciplinas de ingenieria. independencia de modulos. Trabajos posteriores de Ste-
Un diseiio modular reduce la complejidad (vCase la Sec- vens, Wyers y Constantine [STE74] consolidaron el con-
cion 13.4.3), facilita 10s cambios (un aspect0 critico de cepto.
la capacidad de mantenimiento del software), y da como
resultado una implementaci6n mas ficil a1 fomentar el
desarrollo paralelo de las diferentes partes de un sistema.
Un cbdigo es (&terminante)) si se describe con
13.5.1. Independencia funcional uno solo orocibn -sujeto, verbo y predicodo-.
El concepto de independencia funcional es la suma de La independencia funcional se consigue desarrollan-

la modularidad y de 10s conceptos de abstraccion y ocul- do m6dulos con una funci6n <<determinanteny una ccaver-
Esto no es verdad para todas las estructuras arquitectonicas. Por

ejemplo, la estratificacionjerarquica de procedimientosno se encuen-
tra en arquitecturas orientadas a objetos.
INGENlERfA DEL SOFTWARE. UN ENFOQUE PRhCTlCO
s i 6 n ~a una interacci6n excesiva con otros m6dulos. tiene tareas que est6n relacionadas entre si por el hecho
Dicho de otra manera, queremos diseiiar el software de de que todas deben ser ejecutadas en el mismo interva-
manera que cada m6dulo trate una subfunci6n de requi- lo de tiempo, el m6dulo muestra cohesidn temporal.
sitos y tenga una interfaz sencilla cuando se observa des- Como ejemplo de baja cohesi611, tomemos en con-
de otras partes de la estructura del programa. Es justo sideraci6n un m6dulo que lleva a cab0 un procesamiento
preguntarse por quC es importante la independencia. El de errores de un paquete de analisis de ingenieria. El
software con una modularidad efectiva, es decir, m6du- m6dulo es invocado cuando 10s datos calculados exce-
10s independientes, es mas f a d de desarrollar porque la den 10s limites preestablecidos. Se realizan las tareas
funci6n se puede compartimentary las interfaces se sim- siguientes: (1) calcula 10s datos complernentarios basa-
plifican (tengarnos en consideraci6n las ramificaciones dos en 10s datos calculados originalmente; (2) produce
cuando el desarrollo se hace en equipo). Los m6dulos un informe de errores (con contenido grafico) en la esta-
independientes son mas faciles de mantener (y probar) ci6n de trabajo del usuario; (3) realiza 10s cilculos de
porque se limitan 10s efectos secundarios originados por seguimiento que haya pedido el usuario; (4) actualiza
modificaciones de disefio/c6digo; porque se reduce la una base de datos, y ( 5 ) activa un menu de selecci6n
propagaci6n de errores; y porque es posible utilizar para el siguiente procesamiento. Aunque las tareas ante-
m6dulos usables. En resumen, la independencia fun- riores estin poco relacionadas, cada una es una entidad
cional es la clave para un buen diseiio y el diseiio es la funcional independiente que podra realizarse mejor
clave para la calidad del software. como un m6dulo separado. La combinaci6n de funcio-
La independencia se mide mediante dos criterios cua- nes en un solo m6dulo puede servir s610 para incre-
litativos: la cohesi6n y el acoplamiento. La cohesidn es mentar la probabilidad de propagaci6n de errores cuando
una medida de la fuerza relativa funcional de un m6du- se hace una modificaci6n a alguna de las tareas proce-
lo. El uc.oplumiento es una medida de la independencia dimentales anteriormente mencionadas.
relativa entre 10s mbdulos.
La cohesion es una extensidn natural del concepto de

ocultaci6n de informaci6n descrito en la Seccion 13.4.8.
Un m6dulo cohesivo lleva a cabo una sola tarea dentro
de un procedimiento de software, lo cual requiere poca
interacci6n con 10s procedimientos que se llevan a cab0
en otras partes de un programa. Dicho de manera sen-
cilla, un m6dulo cohesivo deber6 (idealmente) hacer
una sola cosa.
FlGURA 13.6. Tipos de acoplamiento.
Lo cohesion es uno indicationtuolitotivo del grodo Los niveles moderados de cohesi6n estan relativa-
que tiene un modulo para centrone en uno solo coso. mente cerca unos de otros en la escala de independen-
cia modular. Cuando 10s elementos de procesamiento
La cohesidn se puede representar como un ccespectro,,.
de un m6dulo estan relacionados, y deben ejecutarse en
Siempre debemos buscar la cohesidn mis alta, aunque la
un orden especifico, existe cohesidn procedimental.
parte media del espectro suele ser aceptable. La escala de
Cuando todos 10s elementos de procesamiento se cen-
cohesidn no es lineal. Es decir, la parte baja de la cohe-
tran en un Area de una estructura de datos, tenemos pre-
si6n es mucho <<peon> que el rango medio, que es casi tan
sente una cohesidn de comunicacidn. Una cohesi6n alta
crbueno>>como la pate alta de la escala. En la prhctica, un
se caracteriza por un m6dulo que realiza una unica tarea.
diseiiador no tiene que preocuparse de categorizar la cohe-
si6n en un m6dulo especifico. Mas bien, se debera enten-
der el concepto global, y asi se deberan evitar 10s niveles
bajos de cohesi6n a1 diseiiar 10s cbdigos. Si nos concentromos en uno solo coso duronte el disefio
En la parte inferior (y no deseable) del espectro, o nivel de componentes, hoy que reolizorlo con cohesibn.
encontraremos un m6dulo que lleva a cab0 un conjunto
de tareas que se relacionan con otras dCbilmente, si es Como ya se ha mencionado anteriormente, no es
que tienen algo que ver. Tales m6dulos se denominan necesario determinar el nivel precis0 de cohesibn. Mas
coincidentalmente cohesivos. Un m6dulo que realiza bien, es importante intentar conseguir una cohesi6n alta
tareas relacionadas ldgicamente (por ejemplo, un m6du- y reconocer cuando hay poca cohesi6n para modificar
lo que produce todas las salidas independientementedel el diseiio del software y conseguir una mayor indepen-
tipo) es ldgicamente cohesivo. Cuando un m6dulo con- dencia funcional.
13.5.3. Acoplamiento En niveles moderados el acoplamiento se caracte-

El acoplamiento es una medida de interconexion entre riza por el paso de control entre modulos. El acopla-
m6dulos dentro de una estructura de software. El aco- miento de control es muy comun en la mayoria de 10s
plamiento depende de la complejidad de interconexion disefios de software y se muestra en la Figura 13.6 en
entre 10s modulos, el punto donde se realiza una entra- donde un 4ndicador de control>>(una variable que
da o referencia a un modulo, y 10s datos que pasan a tra- controla las decisiones en un modulo superior o subor-
vCs de la interfaz. dinado) se pasa entre 10s m6dulos d y e.
En el diseiio del software, intentamos conseguir el Cuando 10s m6dulos estin atados a un entorno
acoplamiento mas bajo posible. Una conectividad sen- externo a1 software se dan niveles relativamente altos
cilla entre 10s modulos da como resultado un software de acoplamiento. Por ejemplo, la E/S acopla un modu-
mis fhcil de entender y menos propenso a tener un <<efec- lo a dispositivos, formatos y protocolos de comuni-
to ola>>[STE75] causado cuando ocurren errores en un caci6n. El acoplamiento externo es esencial, per0
lugar y se propagan por el sistema. debera limitarse a unos pocos modulos en una estruc-
tura. TambiCn aparece un acoplamiento alto cuando
varios modules hacen referencia a un Brea global de
datos. El acoplamiento comun, tal y como se deno-
mina este caso, se muestra en la Figura 13.8. Los
El acoplomiento es una indicacibn cualitativa mddulos c, g y k acceden a elementos de datos en un
del grado de conexion de un modulo con otros area de datos global (por ejemplo, un archivo de dis-
y con el mundo exterior. co o un area de memoria totalmente accesible). El
La Figura 13.6 proporciona ejemplos de diferentes modulo c inicializa el elemento. M i s tarde el modu-
tipos de acoplamiento de modulos. Los modulos a y d lo g vuelve a calcular el elemento y lo actualiza.
son subordinados a modulos diferentes. Ninguno esti Supongamos que se produce un error y que g actua-
relacionado y por tanto no ocurre un acoplamiento direc- liza el elemento incorrectamente. Mucho m6s adelante
to. El modulo c es subordinado a1 modulo a y se acce- en el procesamiento, el modulo k lee el elemento,
de a 61 mediante una lista de argumentos por la que pasan intenta procesarlo y falla, haciendo que se interrum-
10s datos. Siempre que tengamos una lista convencio- pa el sistema. El diagnostic0 de problemas en estruc-
nal simple de argumentos (es decir, el paso de datos; la turas con acoplamiento comun es costoso en tiempo
existencia de correspondencia uno a uno entre elemen- y es dificil. Sin embargo, esto no significa necesaria-
tos), se presenta un acoplamiento bajo (Ilamado aco- mente que el uso de datos globales sea <<malo>>. Sig-
plamiento de datos) en esta parte de la estructura. Una nifica que el diseiiador del software debera ser
variation del acoplamiento de datos, llamado acopla- consciente de las consecuencias posibles del acopla-
miento de marca (stamp),se da cuando una parte de la miento comun y tener especial cuidado de prevenir-
estructura de datos (en vez de argumentos simples) se se de ellos.
pasa a traves de la interfaz. Esto ocurre entre 10s modu- El grado mas alto de acoplamiento, acoplamiento
10s h y a. de contenido, se da cuando un modulo hace uso de
datos o de informacion de control mantenidos dentro
de 10s limites de otro modulo. En segundo lugar, el
acoplamiento de contenido ocurre cuando se realizan
Sisternos oltomente ocoplodos conducen o depuror bifurcaciones a mitad de modulo. Este mod0 de aco-
verdoderos pesodillos. Evitelos. plamiento puede y deberi evitarse.
Una vez que se ha desarrollado una estructura de pro- nado se convierte en dos m6dulos o m& en la
grama, se puede conseguir una modularidad efectiva estructura final de programa. Un mddulo implosio-
aplicando 10s conceptos de disefio que se introdujeron nado es el resultado de combinar el proceso impli-
a1 principio de este capitulo. La estructura de programa cad0 en dos o mas m6dulos.
se puede manipular de acuerdo con el siguiente con-
jun t o de heuristicas:
I. Evaluar la ccprimera iteracidnw de la estructura de
programa para reducir a1 acoplamiento y mejorar
la cohesibn. Una vez que se ha desarrollado la
estructura del programa, se pueden explosionar o
implosionar 10s modules con vistas a mejorar la
independencia del modulo. Un mddulo explosio-
231
Un modulo explosionado se suele dar cuando modulo r, tenemos una violation de la heuristica
existe un proceso comdn en dos o mas m6dulos 111, porque el modulo r se encuentra fuera del h b i t o
y puede redefinirse como un modulo de cohesion de control del modulo e.
separado. Cuando se espera un acoplamiento alto, IV. Evaluar las interfaces de 10s mddulos para reducir
algunas veces se pueden implosionar 10s m6du- la complejidad y la redundancia, y mejorar la con-
10s para reducir el paso de control, hacer refe- sistencia. La complejidad de la interfaz de un
rencia a 10s datos globales y a la complejidad de modulo es la primera causa de 10s errores del soft-
la interfaz. ware. Las interfaces deberan disefiarse para pasar
infonnacion de manera sencilla y deberan ser con-
secuentes con la funcion de un modulo. La incon-
sistencia de interfaces (es decir, datos aparentemente
sin relacionar pasados a travks de una lista de argu-
mentos u otra tkcnica) es una indication de poca
cohesion. El modulo en cuestion debera volverse a
evaluar.
V. Definir m6dulos cuya funcidn se pueda predecir,
pero evirar mddulos que sean demasiado restric-
tivos. Un modulo es predecible cuando se puede
tratar como una caja negra; es decir, 10s mismos
datos externos se produciran independientemente
de 10s datos internos de procesamiento7. Los
modulos que pueden tener <<memoria>> interna no
podran predecirse a menos que se tenga mucho
cuidado en su empleo.
Un m6dulo que restringe el procesamiento a una
Evitar estructuras planas
sola subfuncidn exhibe una gran cohesion y es
bien visto por el disefiador. Sin embargo, un
modulo que restringe arbitrariamente el tamafio
FIGURA 13.7. Estructuras de programa. de una estructura de datos local, las opciones den-
tro del flujo de control o 10s modos de interfaz
II. Intentar minimizar las estructuras con un alto externa requerira invariablemente mantenimiento
grado de salida; esforzarse por la entrada a para quitar esas restricciones.
medida que aumenta la profundidad. La estruc-
tura que se muestra dentro de la nube en la Figura
13.7 no hace un uso eficaz de la factorization.
Todos 10s m6dulos estin ccplanos>>, a1 mismo nivel
y por debajo de un solo modulo de control. En En lo direction de Internet www.dats.dtic.mil/teths/
general, una distribucion mas razonable de con- design/Design.ToC.html se puede encontror un inforrne
trol se muestra en la estructura de la derecha. La detollodo sobre 10s rnetodos de diseiio de software entre 10s
estructura toma una forma oval, indicando la can- que se incluyen el esiudio de todos 10s conceptos
tidad de capas de control y m6dulos de aka utili- y principios de diseiio que se oborcon en este copitulo.
dad a niveles inferiores.
III. Mantener el a'mhito del efecto de un mddulo denrro VI. Intentar conseguir mddulos de ccentrada controladaw,
del a'mhito de control de ese mddulo. El a'mhito del evitando ((conexionespatoldgicasw. Esta heuristica
efecto de un modulo e se define como todos lo otros de disefio advierte contra el acoplamiento de conte-
modules que se ven afectados por la decision nido. El software es mas facil de entender y por tanto
tomada en el modulo e. El ambito de control del mas facil de mantener cuando 10s modulos que se
modulo e se compone de todos 10s modulos subor- interaccionan estin restringidos y controlados. Las
dinados y superiores a1 modulo e. En la Figura 13.7, conexiones patoMgicas hacen referencia a bifurca-
si el modulo e toma una decision que afecta a1 ciones o referencias en medio de un modulo.
Un modulo de ((cajanegra. e s una abstraccion procedimental.
232
Los principios y conceptos de diseiio abordados en este nosotros queremos crear un disefio de software que sea
capitulo establecen las bases para la creacion del mode- estable. Crearemos un modelo de disefio que se tam-
lo de diseiio que comprende representaciones de datos, balee facilmente con vientos de cambio a1 establecer
arquitectura, interfaces y componentes. A1 igual que en una base amplia en el diseiio de datos, mediante una
el modelo de analisis anterior a1 modelo, cada una de region media estable en el disefio arquitectonico y de
estas representaciones de diseiio se encuentran unidas interfaz, y una parte superior aplicando el diseiio a
unas a otras y podran sufrir un seguimiento hasta 10s nivel de componentes.
requisitos del software. Los mCtodos que conducen a la creacion del mode-
En la Figura 13.1, el modelo de disefio se repre- lo de diseiio se presentan en 10s Capitulos 14, 15, 16 y
sento como una piramide. El simbolismo de esta for- 22 (para sistemas orientados a objetos). Cada mCtodo
ma es importante. Una piramide es un objeto permite que el disefiador Cree un disefio estable que se
extremadamente estable con una base amplia y con un ajuste a 10s conceptos fundamentales que conducen a
centro de gravedad bajo. A1 igual que la piramide, un software de alta calidad.
La Especificacidn dcl disefio aborda diferentes aspec- de diseiio procedimental para convertir esa estructu-
tos del modelo de diseiio y se completa a medida que ra en una description estructural.
el disefiador refina su propia representacion del soft- La Especificacibn del diseiio contiene una refe-
ware. En primer lugar, se describe el ambit0 global rencia cmzada de requisitos. El proposito de esta refe-
del esfuerzo realizado en el diseiio. La mayor parte rencia cruzada (normalmente representada como una
de la informacion que se presenta aqui se deriva de matriz simple) es: (1) establecer que todos 10s requi-
la Especificacibn del sistema y del modelo de ana- sitos se satisfagan mediante el diseiio del software, y
lisis (Especificacidn de 10s requisitos del software). (2) indicar cuales son 10s componentes criticos para
A continuacion, se especifica el diseiio de datos. la implementacion de requisitos especificos.
Se definen tambiCn las estructuras de las bases de El primer paso en el desarrollo de la documenta-
datos, cualquier estructura externa de archivos, cidn de pruebas tambiCn se encuentra dentro del docu-
estructuras internas de datos y una referencia cruza- mento del disefio. Una vez que se han establecido las
da que conecta objetos de datos con archivos espe- interfaces y la estructura de programa podremos desa-
cificos. rrollar las lineas generales para comprobar 10s modu-
El diseiio arquitectonico indica como se ha deri- 10s individuales y la integracion de todo el paquete.
vado la arquitectura del programa del modelo de an& En algunos casos, esta section se podra borrar de la
lisis. Ademas, para representar la jerarquia del modulo Especificacidn del disefio.
se utilizan graficos de estructuras. Las restricciones de disefio, tales como limitacio-
nes fisicas de memoria o la necesidad de una interfaz
externa especializada, podran dictar requisitos espe-
ciales para ensamblar o empaquetar el software. Con-
sideraciones especiales originadas por la necesidad
de superposition de programas, gestion de memoria
virtual, procesamiento de alta velocidad u otros fac-
Especificacibndel diseio del software tores podran originar modificaciones en disefio deri-
vadas del flujo o estructura de la informacion. Ademas,
Se representa el disefio de interfaces intemas y exter- esta section describe el enfoque que se utilizara para
nas de programas y se describe un diseiio detallado de transferir software a1 cliente.
la interfaz hombre-maquina. En algunos casos, se podra La ultima seccion de la Especificacidn del disefio
representar un prototipo detallado del IGU. contiene datos cornplementarios. Tambien se presen-
Los componentes -elementos de software que se tan descripciones de algoritmos, procedimientos alter-
pueden tratar por separado tales como subrutinas, fun- nativos, datos tabulares, extractos de otros documentos
ciones o procedimientos- se describen inicialmente y otro tip0 de informacion relevante, todos mediante
con una narrativa de procesamiento en cualquier idio- notas especiales o apCndices separados. Sera aconse-
ma (Castellano, InglCs). La narrativa de procesamiento jable desarrollar un Manual preliminar de Operacio-
explica la funci6n procedimental de un componente nesllnstalacidn e incluirlo como apCndice para la
(modulo). Posteriormente, se utiliza una herramienta documentaci6n del disefio.
INGENIERfA DEL SOFTWARE. U N E N F O Q U E PRACTICO
El disefio es el nucleo tCcnico de la ingenieria del soft- vision global de la arquitectura del software, mientras
ware. Durante el disefio se desarrollan, revisan y docu- que el procedimiento proporciona el detalle necesario
mentan 10s refinamientos progresivos de la estructura para la implementaci6n de 10s algoritmos. La oculta-
de datos, arquitectura, interfaces y datos procedimen- ci6n de informaci6n y la independencia funcional pro-
tales d e 10s componentes del software. El disefio d a porcionan la heun'stica para conseguir una modularidad
como resultado representaciones del software para eva- efectiva.
luar la calidad. Concluiremos nuestro estudio de 10s fundamentos del
Durante las cuatro 6ltimas dCcadas se han propuesto diseiio con las palabras de Glendord Myers [MYE78]:
diferentes principios y conceptos fundamentales del
diseiio del software. Los principios del disefio sirven Intentamos resolver el problema dhdonos prisa en el pro-
ceso de diseiio de forma que quede el tiempo suficiente hash
d e guia a1 ingeniero del software a medida que avan- el final del proyecto como para descubrir 10s errores que se
za el proceso d e disefio. Los conceptos d e diseiio pro- cometieron por comer en el proceso de diseiio.. .
porcionan 10s criterios biisicos para la calidad del
disefio. La moraleja es: NO te precipites durante el diseiio!
L a modularidad (tanto en el programa como en 10s Merece la pena esforzarse por un buen disefio.
datos) y el concept0 de abstraccidn permiten que el dise- N o hemos terminado nuestro estudio sobre el dise-
iiador simplifique y reutilice 10s componentes del soft- fio. En 10s capitulos siguientes, se abordan 10s mCtodos
ware. El refinamiento proporciona un mecanismo para de diseiio. Estos mCtodos combinados con 10s funda-
representar sucesivas capas, de datos funcionales. El pro- mentos de este capitulo, forman la base de una visi6n
grama y la estructura de datos contribuyen a tener una completa del disefio del software.
[AH0831 Aho, A.V.J., Hopcroft, y J. Ullmann, Data Struc- [JAC92] Jacobson, I., Object-Oriented Software Engineering,
tures and Algorithms, Addison-Wesley, 1983. Addison-Wesley, 1992.
[BAS891 Bass, L., P. Clements y R. Kazman, SofnYare Archi- [KRU84] Kruse R.L., Data Structures and Program Design,
tecture in Practice, Addison-Wesley, 1998. Prentice-Hall, 1984.
[BEL8 11 Belady, L., Foreword to Software Design: Methods [MCG91] McGlaughlin, R., <<SomeNotes on Program
and Techniques (L.J. Peters, autor), Yourdon Press, 1981. Design,,, Software Engineering Notes, vol. 16, n." 4, Octu-
[BR098] Brown, W.J. et a]., Anti-Patterns, Wiley, 1998. bre 1991, pp. 53-54.
[BUS961 Buschmann, F. et al., Pattern-Oriented Software [MYE78] Myers, G., Composite Structured Design, Van Nos-
Architecture, Wiley, 1996. trand, 1978.
[DAV95] Davis, A., 201 Principles of Software Development, [MEY88] Meyer, B., Object-Oriented Software Construction,
McGraw-Hill, 1995. Prentice-Hall, 1988.
[MIL721 Mills, H.D., <<MathematicalFoundations for Struc-
[DEN731 Dennis, J., <<Modularity>>, in Advanced Course on
tured Programming,>,Technical Report FSC7 1-6012, IBM
Software Engineering, F.L. Bauer, ed., Springer-Verlag,
Corp., Federal Systems Division, Gaithersburg,Maryland,
Nueva York, 1973, pp. 128-182.
1972.
[GAM95] Gamma, E., et al, Design Patterns, Addison-Wes-
[NAS73] Nassi, I., y B. Shneiderman, <<FlowchartTechni-
ley, 1995.
ques for Structured Programming>>,SIGPLAN Notices,
[GAN89] Gannet, G., Handbook of Algorithms and Data ACM, Agosto 1973.
Structures, 2." ed, Addison-Wesley, 1989.
[ORR77] Orr, K.T., Structured Systems Development, Your-
[GAR951 Garlan, D., y M. Shaw, <<AnIntroduction to Soft- don Press, Nueva York, 1977.
ware Architecturer, Advances in Software Engineering [PAR721 Parnas, D.L.,<cOnCriteria to be used in Decompo-
and Knowledge Engineering, vol. 1, V. Ambriola y G. Tor-
sing Systems into Modules,,, CACM, vol. 14, n." 1, Abril
tora (eds.), World Scientific Publishing Company, 1995. 1972, pp. 221-227.
[JAC75] Jackson, MA., Principles of Program Design, Aca- [ROS75] Ross, D., J. Goodenough y C. Irvine, <<Software
demic Press, 1975. Engineering: Process, Principles and Goals,,, IEEE Com-
[JAC83] Jackson, M.A., System Development, Prentice-Hall, puter, vol. 8, n." 5, Mayo 1975.
1983. [SHA95a] Shaw, M., y D. Garlan, <<Formulationsand For-
[KAI83] Kaiser, S.H., The Design of Operating Systems for Small malisms in Software Architecture,,, Volume 1000-Lectu-
Computer Systems, Wiley-herscience, 1983, pp. 594 ss. re Notes in Computer Science, Springer Verlag, 1995.
[SHA95b] Shaw, M. et al., ccAbstractions for Software Archi- [WAR741 Warnier, J., Logical Construction of Programs, Van
tecture and Tools to Support Them,,, IEEE Trans. Software Nostrand-Reinhold, 1974.
Engineering, vol. 21, n.' 4, Abril 1995, pp. 314-335. [WAS831 Wasserman, A., ceInformation System Design
[SHA96] Shaw, M., y D. Garlan, Software Architecture, Methodology,,, in Software Design Techniques (P. Free-
Prentice-Hall, 1996. man y A. Wasserman, eds.), 4.= ed., IEEE Computer
[SOM96] Sommerville, I., Software Engineering, 3." ed., Society Press, 1983, p. 43.
Addison-Wesley, 1989. [WIR71] Wirth, N., <<ProgramDevelopment by Stepwise
[STE74] Stevens, W., G. Myers y L. Constantine, ccstructu- Refinement,,, CACM, vol. 14, n.' 4, 1971, pp. 221-227.
red Design,,, IBM Systems Journal, vol. 13, n.' 2, 1974, [YOU791 Yourdon, E., y L. Constantine, Structured Design,
pp. 115-139. Prentice-Hall, 1979.
P R O W Y PUNTOS KCONSIDERAR
13.1. Cuando se ccescriben un programa, jse esta disefian- e. cualquier problema que hayan acordado usted y su pro-
do software? i E n quC se diferencia el disefio del software fesor.
de la codificacibn?
Conforme disminuye el grado de abstraccion, su foco de
13.2. Desarrolle tres principios de disefio adicionales que atencion puede disminuir de manera que en la ultima abs-
afiadir a 10s destacados en la Seccion 13.3. traction (codigo fuente) solo se necesite describir una uni-
ca tarea.
13.3. Proporcione ejemplos de tres abstracciones de datos
y las abstracciones procedimentales que se pueden utilizar 13.8. Obtenga el trabajo original de Parnas [PAR721 y resu-
para manipularlos. ma el ejemplo de software que utiliza el autor para ilustrar
la descomposici6n en m6dulos de un sistema. iC6m0 se
13.4. Aplique un ccenfoque de refinamiento paso a pason
utiliza la ocultacion de informacion para conseguir la des-
para desarrollar tres niveles diferentes de abstraccion pro-
composicibn?
cedimental para uno o m i s de 10s programas que se mues-
tran a continuation: 13.9. Estudie la relacion entre el concepto de ocultacion de
a. Desarrolle un dispositivo para rellenar 10s cheques que, informacion como atributo de modularidad eficaz y el con-
dada la cantidad numCrica en pesetas, imprima la canti- cepto de independencia del modulo.
dad en letra tal y como se requiere normalmente. 13.10. Revise algunos de 10s esfuerzos que haya realiza-
b. Resuelva iterativamente las raices de una ecuacidn trans- do recientemente en desarrollar un software y realice un
cendental. analisis de 10s grados de cada modulo (con una escala
ascendente del 1 a1 7). Obtenga 10s mejores y 10s peores
c. Desarrolle un simple algoritmo de planificacion round- ejemplos.
robin para un sistema operativo
13.11. Un grupo de lenguajes de programacion de alto nivel
13.5. ~ E posible
s que haya algiin caso en que la ecuacidn soporta el procedimiento interno como construccion modu-
(13.2) no sea verdad? iC6m0 podria afectar este caso a la lar. iC6m0 afecta esta construccion a1 acoplamiento y a la
modularidad? ocultaci6n de informaci6n?
13.6. ~ C u a n d odeberi implementarse un diseiio modular 13.12. ~ Q u Crelacion tienen 10s conceptos de acoplamien-
como un software monolitico? iC6m0 se puede llevar a to y de movilidad del software? Proporcione ejemplos que
cabo? ~ E els rendimiento la unica justification para la apoyen esta relacion.
implementacion de software monolitico?
13.13. Haga un estudio de la manera en que ayuda la par-
13.7. Desarrolle a1 menos cinco niveles de abstraccion para ticion estructural para ayudar a mantener el software.
uno de 10s problemas de software siguientes:
13.14. iCuil es el proposito de desarrollar una estructura
a. un video-juego de su eleccion. de programa descompuesta en factores?
b. un software de transformacion en tres dimensiones para 13.15. Describa el concepto de ocultacion de informacion
aplicaciones graficas de computador. con sus propias palabras.
c. un intCrprete de lenguajes de programacion.
13.16. iPor quC es una buena idea mantener el efecto de
d. un controlador de un robot con dos grados de libertad. alcance de un modulo dentro de su alcance de control?
lNGENIERfA DEL SOFTWARE. UN ENFOQUE PRhCTlCO
Donald Norman ha escrito dos libros (The Design of Every- Dentro de una antologia editada por Freeman y Wasser-
day Things, Doubleday, 1990, y The Psychology of Everyday man (Software Design Techniques, 4."d., IEEE, 1983) se
Things, Harpercollins, 1988) que se han convertido en cla- encuentra un estudio hist6rico excelente de trabajos impor-
sicos de literatura de disefio y es una lectura ccobligadan para tantes sobre disefio del software. Este trabaio de ensefianza
todos 10s que disefian cualquier cosa que el ser humano va reimprime muchos de 10s trabajos clasicos que han formado
utilizar. Adams (Conceptual Blockbusting, 3." ed. Addison- la base de las tendencias actuales en el disefio del software.
Wesley, 1986) ha escrito un libro que es una lectura esencial Buenos estudios sobre 10s fundamentos del disefio de soft-
para 10s disefiadores que quieren ampliar su forma de pen- ware se pueden encontrar en 10s libros de Myers [MYE78],
sar. Finalmente un texto clasico de Polya (How to Solve It, Peters (Soft~l~are Design: Methods and Techniques, Yourdon
2." ed., Princeton University Press, 1988) proporciona un Press, Nueva York, 1981), Macro (Software Engineering:
proceso genkrico de resolver problemas que puede servir de Concepts and Management, Prentice-Hall, 1990) y Som-
ayuda a 10s disefiadores cuando se enfrentan con problemas merville (Software Engineering, Addison-Wesley, 5.%d.,
complejos. 1995).
Siguiendo la misma tradition, Winograd et al. (Bringing Tratamientos matematicamente rigurosos del software de
to Software, Addison-Wesley, 1996) aborda 10s disefios del computadora se pueden encontrar en 10s libros de Jones (Soft-
software que funcionan, 10s que no funcionan y las razones. ware Development: A Rigourous Approach, Prentice-Hall,
Un libro fascinante editado por Wixon y Ramsey (Field 1980), Wulf (Fundamental Structures of Computer Science,
Methods Casebook for Software Design, Wiley, 1996) sugie- Addison-Wesley, 1981) y Brassard y Bratley (Fundamental
re 10s ccmktodos de investigaci6n de campos,> (muy similares of Algorithmics, Prentice-Hall, 1995).
a 10s que utilizan 10s antrop6logos) para entender como rea- Todos estos libros ayudan a proporcionar el fundarnento te6-
lizan 10s usuarios el trabajo que realizan y entonces disefiar rico necesario para comprender el software de computadora.
el software que cubra sus necesidades. Beyer y Holtzblatt Kruse (Data Structures and Program Design, Prentice-Hall,
(Contextlial Design: A Customer-Centrered Approach to Sys- 1994) y Tucker et al. (Fundamental of Computing II: Abstrac-
tems, Academic Press, 1997) ofrecen otra visi6n del diseiio tion, Data Structures, and Large Sojhvare Systems, McGraw-
de software que integra a1 cliente/usuario en todos 10s aspec- Hill, 1995) presentan una information valiosa sobre estructuras
tos del proceso de diseiio del software. de datos. Las medidas de calidad de diseiio presentadas desde
McConnell (Code Complete, Microsoft Press, 1993) pre- una perspectiva tkcnica y de gestidn son abordadas por Card y
senta un estudio excelente de 10s aspectos practicos para el Glass (Measuring Design Quality, Prentice-Hall, 1990).
disefio de software de computadora de alta calidad. Robert- Una amplia variedad de fuentes de informaci6n sobre el
son (Simple Program Design, 3.%d., Boyd & Fraser Publis- disefio del software y otros temas relacionados estan dispo-
hing) presenta un estudio introductorio de disefio del software nibles en Internet. Una lista actualizada de referencias rele-
que es util para aquellos que empiezan a estudiar sobre el vantes para 10s conceptos y mktodos de disefio se puede
tema. encontrar en http://www.pressman5.com
transacctnes .......252
analisis de far
transformationes.. . -247
~ Q u es?
6 El disefio arquitecthico repre- sites derivados durante el a n d i s i s d e el fin d e obtener la estructura que
senta la estructura d e 10s datos y 10s la ingenieria del sistema y d e 10s mejor s e ajusta a 10s requisitos del
componentes del programa que s e requisitos del software. cliente y a las normas de calidad. Una
requieren para construir un sistema ~ P o qu6
r es impartante? En la secci6n vez que e s seleccionada una d s las
basado e n computadora. Constituye Vistazo rapido del capitulo anterior pre- alternativas, la arquitectura s e elabo-
e l estilo arquitectonico que tendra el guntamos: -No serias capaz de inten- ra utilizando el mbtodo d e disefio
sistema, la estructura y l a s propie- tar construir una casa sin un plano. arquitectbnico.
d a d e s de 10s componentes que e s e ~ v e r d a d ?Tu~ tampoco comenzarias el tCu&l e s el product0 abtenida?
sistema comprende, y l a s Interrela- esbozo del plano por 10s bosquejos del Durante el diseiio urquitect6nico s e
ciones que tienen lugar entre todos diseiio de tuberlas d e la casa. Necesi- crea un modelo d e arquitectura que
10s componentes arquitect6nicos del tarias ver la foto completa-la casa en abarca la arquitectura d e datos y la
sistema. si misma- antes de preocuparte por estructura del programa. Ademas. se
tQui6n lo hace? Aunque 10s ingenie- 10sdetalles. Esto es lo que el disefio describen las propiedudes de 10scom-
ros del software pueden disefiar tan- arquitectbnico hace -proprciona la ponentes y s u s relaciones (inlerac-
to 10s datos como la arquitectura, foto completa y asegura que lo estds ciones).
cuanda se trata de constmir sistemas haciendo bien-. LCirno puedo estar seguro de pus
grandes y complejos, el trabajo es, a &u&lessari 10s pasas? El diseiioarqui- lo he hecho correctamente? En
menudo, asignado a especialistas. El tect6nico comienza con el disefio d e cada etapa, 10s productos tesultantes
diseiiador de una base d e datos o un datos y despubs procede a la deriva- del diseiio del software son revisados
almacbn d e dafos crea la arquitectu- ci6n d e una o mas represexitaciones de para clarificar, corregir, completar y
ra de datos para el sistema. El narqui- la estructura arquitecthica del siste- dar consistencia acorde a 10s requi-
tecto del sisteman selecciona un estilo ma. Los estilos arquitectdnicos alter- sites establecidos, y entre unos y
arquitect6nico apropiado a 10s requi- nativos o patrones son analizados con otros.
~ N G E N ~ E RDEL
Shaw y Garlan [SHA96], en su libro de referencia sobre altemativas arquitect6nicas en una etapa en la cud hacer
la materia, tratan la arquitectura del software de la cambios en el disefio es relativamente f6ci1, y (3) reducir
siguiente forma: 10s riesgos asociados a la construcci6n del software.
lncluso desde que el primer prograrna fue dividido en mMu-
los, 10s sistemas de software han tenido arquitecturas, y 10s pro-
gramadoreshan sido responsables de sus interaccionesa travCs
de m6dulos y de las propiedades globales de ensamblaje. His-
tbricamente, las arquitecturas han estado implicitas -bien
como accidentes en la implementation, bien como sistemas
legados del pasad*. Los buenos desarrolladoresde softwa-
re han adoptado, a menudo, uno o varios patrones arquitect6-
nicos como estrategias de organizaci6n del sistema, pero
utilizaban estos patrones de modo informal y no tenian ningun La definition presentada anteriormente enfatiza el
inter& en hacerlos explicitos en el sistema resultante. papel de 10s cccomponentes del software>>en cualquier
Hoy, la arquitectura de software operativa y su repre- representaci6n arquitect6nica. En el context0 del dise-
sentaci6n y diseiio explicitos se han convertido en temas iio arquitect6nic0, un componente del software puede
dominantes de la ingenieria de software. ser tan simple como un m6dulo de programa, per0 tam-
biCn puede ser algo tan complicado como incluir bases
de datos y software intermedio (<<middleware>>) que per-
14.1.1. ~ Q u e s urquitecturu?
miten la configuraci6n de una red de clientes y servi-
Cuando hablamos de la ccarquitecturau de un edificio, dores. Las propiedades de 10s componentes son aquellas
nos vienen a la cabeza diferentes atributos. A nivel mis caracteristicas necesarias para entender c6mo 10s com-
bisico, pensamos en la forma global de la estructura ponentes interactuan con otros componentes. A nivel
fisica. Pero, en realidad, la arquitectura es mucho mis. arquitect6nic0, no se especifican las propiedades inter-
Es la forma en la que 10s diferentes componentes del nas (por ejemplo, detalles de un algoritmo). Las rela-
edificio se integran para formar un todo unido. Es la for- ciones entre 10s componentes pueden ser tan sencillas
ma en la que el edificio encaja en su entorno y con 10s como una llamada de procedimiento de un m6dulo a
otros edificios de su vecindad. Es el grado en el que el otro, o tan complicadas como el protocolo de acceso a
edificio consigue su proposito fijado y satisface las nece- bases de datos.
sidades de sus propietarios. Es el sentido estCtico de la En este libro, el diseiio de la arquitectura de software
estructura 1- impacto visual del edificio- y el mod0 tiene en cuenta dos niveles de la pirimide del disefio
en el que las texturas, 10s colores y 10s materiales son (Fig. 13.1) -1 diseiio de datos y arquitect6nice. En
combinados para crear la fachada extema y el ccentor- este sentido, el diseiio de datos nos facilita la represen-
no vivou intemo. Son 10s pequeiios detalles -1 dise- tacion de 10s componentes de datos de la arquitectura.
fio de las instalaciones electricas, del tip0 de suelo, de El diseiio arquitectonico se centra en la representation
la colocacidn de tapices y una lista casi interminable-. de la estructura de 10s componentes del software, sus
Y, finalmente, es arte. propiedades e interacciones.
14.1.2. ~ P o rque e s importunte la urquitecturu?

Referencia web L / En su libro dedicado a la arquitectura de software, Bass
Se puede encontrar una listo util de recursos de y sus colegas [BAS981 identifican tres razones clave por
arquitectura de software en www2.umassd.edu/ las que la arquitectura de software es importante:
SECenter/SAResources.html
las representaciones de la arquitectura de software
Pero, iquC pasa con la arquitectura de software? Bass facilitan la'comunicaci~nentre todas las partes (par-
y sus colegas [BAS981 definen este esquivo tCrmino de ticipes) interesadas en el desarrollo de un sistema
la siguiente forma: basado en computadora;
La arquitectura de software de un sistema de programa o la arquitectura destaca decisiones tempranas de
computaci6n es la estructura de las estructuras del sistema, la disefio que tendrin un profundo impacto en todo el
cual comprende 10s componentes del software, las propieda- trabajo de ingenieria del software que sigue, y es tan
des de esos componentes visibles extemamente,y las relacio- importante en el Cxito final del sistema como una
nes entre ellos. entidad operacional;
La arquitectura noes el software operacional. MASbien, la arquitectura ccconstituye un modelo relativamente
es la representaci6n que capacita a1 ingeniero del softwa- pequeiio e intelectualmente comprensible de c6mo
re para: (1) analizar la efectividad del disefio para la con- esti estructurado el sistema y de c6mo trabajan jun-
secuci6n de 10s requisitos fijados, (2) considerar las tos sus componentes>>[BAS98].
CAPfTULO 14 DISENO ARQUITECT6NICO
El modelo de disefio arquitect6nico y 10s patrones

arquitect6nicos contenidos dentro son transferibles. Esto
es, 10s estilos y patrones de arquitectura (Secci6n 14.3.1)
pueden ser aplicados en el disefio de otros sistemas y
El modelo orquitectbnico proporciono uno visi6n ((Gestalt))
representados a travCs de un conjunto de abstracciones
del sistemo, permihendo ol ingeniero del softwore
exominorlo como un todo.
que facilitan a 10s ingenieros del software la descrip-
ci6n de la arquitectura de un mod0 predecible.
A1 igual que otras actividades de la ingenieria del soft- Durante muchos afios, la arquitectura de datos estu-
ware, el diserio de datos (a veces llamado arquitectura vo limitada, generalmente, a las estructuras de datos a
de datos) crea un modelo de datos y/o informaci6n que nivel del programa y a las bases de datos a nivel de apli-
se representa con un alto nivel de abstracci6n (la visi6n caci6n. Pero hoy, las empresas grandes y pequefias esthn
de datos del cliente/usuario). Este modelo de datos, es inundadas de datos. No es inusual, incluso para una
entonces refinado en progresivas representaciones espe- mediana empresa, tener docenas de bases de datos sir-
cificas de la irnplementaci611, que pueden ser procesa- viendo diferentes aplicaciones de cientos de gigabytes
das por un sistema basado en computadora. En muchas de datos. El desafio de las empresas ha sido extraer
aplicaciones de software, la arquitectura de datos ten- informaci6n litil de su entorno de datos, particularmen-
dr8 una gran influencia sobre la arquitectura del soft- te cuando la informaci6n deseada esth funcionalmente
ware que debe procesarlo. interrelacionada (por ejemplo, informaci6n que s610
La estructura de datos ha sido siempre una parte puede obtenerse si 10s datos de marketing especificos
importante del disefio de software. A1 nivel de 10s com- se cruzan con 10s datos de la ingenieria del producto).
ponentes del programa, el disefio de las estructuras de Para resolver este desafio, la comunidad de empre-
datos y de 10s algoritmos asociados requeridos para su sas de TI ha desarrollado las tCcnicas de mineria de
manipulaci6n, son la parte esencial en la creaci6n de dutos, tambiCn llamadas descubrimiento de conoci-
aplicaciones de alta calidad. A nivel de aplicacibn, la miento en bases de datos (DCBC),que navegan a tra-
traducci6n de un modelo de datos (derivado como par- vCs de las bases de datos en un intento por extraer el
te de la ingenieria de requisitos) en una base de datos nivel de informaci6n de negocio apropiado. Sin embar-
es el punto clave para alcanzar 10s objetivos de nego- go, la existencia de mliltiples bases de datos, sus dife-
cio del sistema. A nivel de negocios, el conjunto de rentes estructuras, el grado de detalle contenido en las
informaci6n almacenada en las diferentes bases de bases de datos, y muchos otros factores hacen dificil la
datos y reorganizada en el almacCn de datos facilita la mineria de datos dentro de un entorno con bases de
mineria de datos o el descubrimiento de conocimien- datos existentes. Una soluci6n alternativa, llamada
to que puede influir en el propio Cxito del negocio. De almacCn de datos, afiade una capa adicional a la arqui-
cualquier modo, el disefio de datos juega un papel muy tectura de datos.
importante.
14.2.1. Modelado de datos. estructuras de datos.

bases de datos y almacen de datos Referencia web/ '
Poro obtener informocibn octuolizodo sobre tecnologios
Los objetos de datos definidos durante el analisis de
de olmocen de dotos visitor:
requisitos del software son modelados utilizando dia- www.datawarehouse.com
gramas de entidad-relaci6n y el diccionario de datos
(Capitulo 12). La actividad de disefio de datos traduce
esos elementos del modelo de requisitos en estructuras Un almace'n de datos es un entorno de datos sepa-
de datos a nivel de 10s componentes del software y, cuan- rado, que no esta directamente integrado con las apli-
do es necesario, a arquitectura de base de datos a nivel caciones del dia a dia, per0 que abarca todos 10s datos
de aplicaci6n. utilizados por una empresa [MAT96]. En cierto senti-
do, un almacCn de datos es una gran base de datos inde-
pendiente, que contiene algunos, per0 no todos 10s
datos almacenados en las bases de datos que sirven a1
conjunto de aplicaciones requeridas en un negocio. Sin
embargo, hay muchas caracten'sticas diferenciales entre
un almacCn de datos y una base de datos tipica
[INM95]:
Orientacion por materia. Un almacCn de datos y revisarse, las de objetos de datos deberian identifi-
. esta organizado por las materias importantes del carse, se deberian estudiar las organizaciones alter-
negocio, mas que por 10s procesos o funciones del nativas de datos y deberia evaluarse el impact0 del
negocio. Esto nos lleva a una exclusi6n de datos que modelado de datos sobre el disefio del software. Por
podrian ser necesarios para una funci6n particular ejemplo, la especificaci6n de una lista enlazada con
del negocio, per0 que generalmente no son necesa- multiples anillos puede satisfacer 10s requisitos de 10s
rios para la mineria de datos. datos per0 puede llevar a un diseiio del software poco
Integracion. Sin tener en cuenta la fuente de datos, flexible. Una organizaci6n de datos altemativa nos
da consistencia nombrar convenciones, unidades y podria llevar a obtener mejores resultados.
medidas, estructuras de codificaci6n y atributos fisi-
cos incluso cuando la inconsistencia existe a travCs de iQue printipios son aplitables
las diferentes bases de datos orientadas a aplicaciones. para el diseiio de datos?
Restricciones de tiempo. Para un entomo de apli-
caci6n orientado a transacci6n, 10s datos son precisos 2. Todas las estructuras de datos y las operaciones a lle-
en el momento del acceso y por un period0 de tiempo var a caho en cada una de ellas deberian estar clara-
relativamente pequefio (normalmente de 60 a 90 dias) mente identificadas. El disefio de una estructura de
antes del acceso. Sin embargo, en un almacCn de datos, datos eficaz debe tener en cuenta las operaciones que
se accede a 10s datos en un momento especifico del se van a llevar a cab0 sobre dicha estructura de datos
tiempo (por ejemplo, 10s clientes con 10s que se ha (vea [AH083]). Por ejemplo, imaginese una estruc-
contactado el mismo dia que el nuevo product0 ha sido tura de datos hecha con un conjunto de elementos de
anunciado en la prensa comercial). El horizonte tipico datos diversos. La estructura de datos se va a manipu-
de tiempo de un almacCn de datos es de 5 a 10 afios. lar con varias funciones principales del software. Des-
No volatilidad. A diferencia de las tipicas bases puCs de la evaluaci6n de la operacion realizada sobre
de datos de aplicaciones de negocios que atraviesan la estructura de datos, se define un tipo de datos abs-
una continua corriente de cambios (insertar, borrar, tracto para usarlo en el disefio del software subsiguiente.
actualizar), en el almacCn de datos 10s datos se car- La especificacion de 10s tipos de datos abstractos puede
gan, pero despuCs de la primera transferencia, 10s simplificar considerablemente el disefio del software.
datos no cambian. 3. Se deberia establecer un diccionario de datos y
usarlo para definir el disefio de 10s datos y del pro-
grama. El concepto de diccionario de datos se intro-
dujo en el Capitulo 12. Un diccionario de datos
Un almocen de datos contiene todos 10s dotos utilizados
representa explicitamente las relaciones entre 10s
en una empresa. Su obietivo es facilitar el acceso objetos de datos y las restricciones de 10s elementos
a ccconocimiento)) que de otro mado no se dispondrio. de una estructura de datos. Los algoritmos que deben
aprovecharse de estas relaciones especificas pueden
Estas caracteristicas presentan un cuadro unico de definirse mas facilmente si existe una especificaci6n
desafios de disefio para el arquitecto de datos. de datos tip0 diccionario.
4. Las decisiones de disefio de datos de bajo nivel debe-
14.2.2. Disefio de datos a nivel de componentes rian dejarse para el final del proceso de disefia. Se
El diseiio de datos a nivel de componentes se centra puede usar un proceso de refinarnientopaso a paso para
en la representacidn de estructuras de datos a las que se el disefio de datos. Es decir, la organization general de
accede directamente a travCs de uno o mas componen- datos puede definirse durante el analisis de requisitos;
tes del software. Wasserman [WASSO] ha propuesto un refinarse durante 10s trabajos de diseiio de datos y espe-
conjunto de principios que pueden emplearse para especificarse en detalle durante el disefio a nivel de com-
cificar y diseiiar dicha estructura de datos. En realidad, ponentes. El enfoque descendente del diseiio de datos
el diseiio de datos empieza durante la creaci6n del mode- proporciona ventajas analogas al enfoque descendente
lo de analisis. Recordando que el analisis de requisitos del diseiio de software: se diseiian y evallian primera-
y el diseiio a menudo se solapan, consideramos el mente 10s atributos estructurales principales de manera
siguiente conjunto de principios [WASSO] para la espe- que se pueda establecer la arquitectura de 10s datos.
cificacion de datos: 5. La representacibn de las estructuras de datos debe-
rian conocerla ~ 6 1 0aquellos mbdulos que deban
1. Los principios del analisis sistematico aplicados a la hacer uso directo de 10s datos contenidos dentro de
funcibn y a1 comportamiento deberian aplicarse tam- la estructura. El concepto de ocultaci6n de infor-
bie'n a 10s datos. Invertimos mucho tiempo y esfuerzo macion y el concepto relacionado de acoplamiento
en obtener, revisar y especificar 10s requisitos fun- (Capitulo 13) proporciona una importante vision de
cionales y el diseiio preliminar. Las representaciones la calidad del disefio del software. Este principio
de flujo de datos y contenido deberian desarrollarse alude a la importancia de estos conceptos asi como
a ccla importancia de separar la vision 16gica de un Un disefio del software y un lenguaje de programu-
objeto de datos de su vision fisica>>[WAS80]. cidn deberia soportar la especificaci6n y realizacidn
Deberia desarrollarse una biblioteca de estructuras de 10s tipos abstractos de datos. La implementacion
de datos litiles y de las operuciones que se les puede una estructura de datos sofisticada puede hacerse
den aplicar. Las estructuras de datos y las operacio- excesivamente dificil si no existen 10s medios de espe-
nes deberian considerarse como recursos para el cificacion cllrecta de la estructura en el lenguaje de pro-
diseiio del software. Las estructuras de datos pueden gramacion escogido para dicha implementacion.
diseiiarse para que se puedan reutilizar. Una biblio- Los principios descritos anteriormente forman una
teca de plantillas de estructuras de datos (tipos abs- base para un enfoque de diseiio de datos a nivel de com-
tractos de datos) puede reducir el esfuerzo del diseiio ponentes que puede integrarse en las fases de analisis y
y de la especificacion de datos. diseiio.
Cuando un constructor utiliza el tCrmino cccentre hall colo- i Q ~ es

b un estilo
nial>> para describir una casa, la mayoria de la gente fami- arquitectonito
liarizada con las casas en 10s Estados Unidos sena capaz
de recrear una imagen general de corn0 seria esa casa y de
como sena su diseiio de plantas. El constructor ha utiliza- 14.3.1. Una breve taxonomia de estilos y patrones
do un estilo arquitectdnico a mod0 de mecanismo des- Aunque durante 10s pasados 50 afios se han creado cien-
criptivo para diferenciar esa casa de otros estilos (por tos de miles de sistemas basados en computadora, la gran
ejemplo, A-frame, raised ranch, Cape Cod).Pero, lo mis mayona pueden ser clasificados (ver [SHA96], [BAS98],
importante, es que el estilo arquitectonico es tambiCn un [BUS98]) dentro de uno de 10s estilos arquitectonicos:
patron de construccion. Mas adelante se deberh definir
Arquitecturas centradas de datos. En el cenho de esta
10s detalles de la casa, se especificarh sus dimensiones arquitectura se encuentra un almacCn de datos (por ejemplo.
finales, se le aiiadirin caractensticas personalizadas y se un documento o una base de datos) a1 que otros componentes
d e t e r m i n d 10s materiales de construcci6n, per0 el patron acceden con frecuencia para actualizar. aiiadir, borrar o bien
-+<centre hall colonial>+ guia al constructor en su tra- modificar 10s datos del almacCn. La figura 14.1 representa un
bajo. estilo tipico basada en 10s datos. El software de cliente accede
a un almacCn central. En algunos casos, el almacCn de datos es
3
Referencia Web
El proyectoABLE de la CMU cuenta con trabaios y
ejemplos rnuy biiles sobre estilos orquitectbnicos:
pasivo. Esto significa que el software de cliente accede a 10s
datos independientemente de cualquier cambio en 10s datos o
de las acciones de otro software de cliente. Una variacih en
este acceso hansforma el almackn en una ccpizarra,, que envia
notificaciones a1 software de cliente cuando 10s datos de inte-
rCs del cliente cambian.
tom.ts.tmu.edu/oble/
Software Software
El software construido para sistemas basados en com- del del
putadoras tambiCn cuenta con diversos estilos arquitec- cliente cliente Software
t6nicos1.Cada estilo describe una categoria del sistema Software
-
del
cliente
que contiene: (1) un conjunto de componentes (por ejem- del
plo, una base de datos, mddulos computacionales) que cliente
realizan una funcion requerida por el sistema; (2) un con-
junto de conectores que posibilitan la cccomunicaci6n,la Almacen de datos
coordination y la cooperaci6n~entre 10s componentes; Software Software
(3) restricciones que definen como se pueden integrar
10s componentes que forman el sistema; y (4) modelos cliente cliente
semanticos que permiten a1 diseiiador entender las pro-
piedades globales de un sistema para analizar las pro- Software Software
piedades conocidas de sus partes constituyentes [BAS98]. cliente cliente
En la siguiente seccion, abordamos 10s patrones arqui-
tectonicos comunmente utilizados para el software. FIGURA 14.1. Arquitectura basada en 10s datos.
' Los terminos estilos y patrones se utilizan indistintamente en este

capitulo.
Los estilos arquitectonicos citados anteriormente son cual es el papel de 10s componentes dentro de esa jerarquia de
solo una pequefia parte de 10s que dispone el disefiador control? iC6mo transfieren el control 10s componentes den-
tro del sistema? iC6m0 se comparte el control entre compo-
de software-. Una vez que la ingenieria de requisitos
nentes? iCual es la topologia de control (por ejemplo, la forma
define las caracteristicas y las restricciones del sistema geomttrica3 que adopta el control)?, iEstl el control sincro-
que ha de ser construido, se escoge el patron arquitec- nizado o 10s componentes achian asincr6nicamente?
tonico (estilo) o la combinacion de patrones (estilos)
que mejor encajan con las caracteristicas y restriccio- ~ C O se~ evalua
O un estilo
nes. En muchos casos, puede ser apropiado mas de un arquitectonico que se ha derivado?
patron y se podrian diseiiar y evaluar estilos arquitec-
tonicos alternativos. Daros. iC6m0 se comunican 10s datos entre componen-
tes? LEIflujo de datos es continuo o son objetos de datos que
pasan de un componente a otro, o 10s datos estin disponibles
14.3.2.Organizaci6ny refinamiento globalmente para ser compartidos entre 10s componentes del
sistema? existe en 10s componentes de datos (por ejemplo.
Puesto que el proceso de disefio deja a menudo a1 inge- una pizarra o almactn), y si es asi, cual es su papel? iC6mo
niero con un numero de alternativas arquitectonicas, es interactuan 10s componentes funcionales con 10s compo-
importante establecer un conjunto de criterios de dise- nentes de datos? ~ L Ocomponentes
S de datos son activos o
fio que puedan ser utilizados para evaluar un disefio pasivos (por ejemplo, 10s componentes de datos interactuan
arquitectonico derivado. Las siguientes cuestiones activamente con otros componentes del sistema)?iComo
interactuan 10s datos y el control dentro del sistema?
[BAS981 proporcionan una idea del estilo arquitecto-
nico que ha sido derivado: Estas preguntas proporcionan a1 disefiador una eva-
Control. iC6m0 se gestiona el control dentro de la arqui- luaci6n temprana de la calidad del diseiio y sientan las
tectura? ~Existeuna jerarquia de control diferente, y si es asi, bases para un analisis mas detallado de la arquitectura.
Las preguntas citadas en la section anterior proporcio- 2. Elicitacidn de requisitos. Esta informaci6n es reque-
nan una evaluacion preliminar del estilo arquitectonico rida como parte de 10s requisitos de ingenieria y se
escogido para un sistema concreto. Sin embargo, para utiliza para asegurarse de que todos 10s clientes, usua-
la consecucion efectiva del disefio, se necesita un mito- rios y participes implicados han sido atendidos.
do de evaluacion de la calidad de la arquitectura m6s
completo. En las siguientes secciones, consideramos
dos enfoques diferentes para el analisis de disefios arqui-
tectonicos alternativos. El primer enfoque utiliza un
mktodo iterativo para evaluar el disefio de 10s compro-
misos. El segundo enfoque aplica una pseudotkcnica
3
Referencia Web
Se puede entonhor informotion detollodo sobre onalisis
de tompromiso de softwore arquitettbniro en:
cuantitativa para evaluar la calidad del diseiio. www.sei.cmu.edu/ata/ataIImethod.html
3. Describir 10s patroneslestilos arquitectdnicos escogi-

dos para derivar 10s escenarios y requisitos. El(1os)
estilo(s) deberia describirse utilizando vistas arqui-
tect6nicas como:
vista de mddulo: para analizar el trabajo asignado
14.4.1. Un metodo de analisis de compromiso
por componente y el grado de ocultacion de infor-
para la arquitectura maci6n que se ha alcanzado
El Instituto de Ingenieria de Software (SEI) ha desa- vista de proceso: para analizar la actuation del
rrollado un Me'todo de andisis de compromiso para la sistema
arquitectura (MACA)[KAZ98] que establece un pro- vista dejujo de datos: para analizar el grado en
ceso de evaluacion iterativo para las arquitecturas de el que la arquitectura cumple 10s requisitos fun-
software. Las actividades de analisis de diseiio men- cionales
cionadas abajo se realizan iterativamente:
1. Recopilacidn de escenarios. En el Capitulo 11 se
recogen un grupo de casos de uso para representar
el sistema desde el punto de vista del usuario.
Ver [SHA97],(BAS981y [BUS981 para un estudio detallado de esti- Una jerarquia es una forma geometrica, pero tambien podemos
10sy patrones arquitectonicos. encontrar mecanismos de control semejantes en un sistema
cliente/Se~idor.
Evaluar 10s atributos de calidad considerando cada Asada [SHA96] propone varios modelos simples para
atributo de forma aislada. El numero de atributos ayudar a1 disefiador a determinar el grado a1 cual una
de calidad escogidos para el anilisis depende del arquitectura particular alcanza 10s criterios de <<bondad>>
tiempo disponible para la revision y del grado de predefinidos. Estos criterios, a veces llamados dimen-
relevancia de dichos atributos para el sistema actual. siones del disefio, a menudo abarcan 10s atributos de
Los atributos de calidad para la evaluaci6n del disefio calidad definidos en la seccion anterior: fiabilidad, ren-
arquitectbnico incluyen: fiabilidad, rendimiento, dimiento, seguridad, facilidad de mantenimiento, flexi-
seguridad, facilidad de mantenimiento, flexibilidad, bilidad, capacidad de prueba, movilidad, reutilizaci6n
capacidad de prueba, movilidad, reutilizacion e inte- e interoperatibilidad, entre otros.
roperatibilidad. El primer modelo, denominado ancilisis del espectro,
evalua un diseiio arquitect6nico en un espectro de iibon-
ldentijicar la sensihilidad de 10s atrihutos de calidadn desde el mejor disefio posible hasta el peor. Una vez
dad con 10s diferentes atrib~itosarquitectdnicos en que la arquitectura del software ha sido propuesta, se ana-
un estilo arquitectdnico espec$ico Esto se puede liza asignando una ccpuntuaci6n~a cada una de las
conseguir realizando pequefios cambios en la arqui- dimensiones del diseiio. Estas notas de las dimensiones
tectura y determinando cu5n sensibles a1 carnbio son se suman para determinar la calificaci6n total, S, del
10s atributos de calidad, como el rendimiento. Aque- disefio como un todo. Los casos de notas mis bajas%on
110s atributos afectados significativamente por un asignados a un disefio hipotCtico, y se computa la suma
carnbio en la arquitectura son denominados puntos de notas de la peor arquitectura, S,. La mejor nota, Sh,
sensihles. se computa para un disefio bptimo5. Entonces calcu-
Analisis de las arquitecturas candidatas (desarro- lamos el indice del espectro. I,, ,mediante la ecuaci6n:
lladas en el paso 3 ) utilizando el andisis de sensi-
bilidad del paso 5. El SEI describe este enfoque de 1, = [ ( s- S,)/( Sb - S,)] )X 100
la siguiente forma [KAZ98]: El indice del espectro indica el grado a1 cual la arqui-
Una vez determinados 10s puntos sensibles de la arquitec- tectura propuesta se aproxima a1 sistema 6ptimo dentro
tura, encontrar 10s puntos de compromiso consiste sirnplemente del espectro de altemativas razonables para el disefio.
en la identificacih de 10s elementos arquitect6nicos en 10s cua-
les varios atributos son sensibles. Por ejemplo, el rendimiento
de una arquitectura cliente/servidor seria muy sensible al nume-
ro de servidores (el rendimiento aumenta, dentro de un grado,
aumentando en n6mero de servidores). La disponibilidad de
esa arquitectura tambiCn variaria directamente con el numero
de servidores. Sin embargo, la seguridad del sistema varim'a
inversamente a1 numero de servidores (porque el sistema con-
tiene mas puntos de ataque potenciales). El numero de servi-
dores, entonces, es un punto de compromiso con respecto a la Si se realizan modificaciones del disefio propuesto
arquitectura. Este es un elemento, potencialmente uno de
muchos, donde se h a r h 10s compromisos arquitecthicos, cons-
o si se propone un nuevo disefio entero, 10s indices de
ciente o inconscientemente. espectro de ambos deben ser comparados y se compu-
Estos seis pasos representan la primera iteraci6n tar6 un indice de mejora, I,,:
MACA. Tras 10s resultados de 10s pasos 5 y 6 algunas Is1 - Is2
'me=
arquitecturas altemativas se eliminarian, una o varias
Esto proporciona a1 diseiiador una indicaci6n relati-
de las arquitecturas restantes serian modificadas y pre-
va a la mejora asociada con 10s cambios arquitect6ni-
sentadas con mayor detalle, y despuCs 10s pasos MACA
cos realizados o con la nueva arquitectura propuesta. Si
se aplicarian de nuevo.
I,,, es positivo, entonces podemos concluir que el sis-
tema 1 ha sido mejorado en relacidn al sistema 2.
14.4.2. Guia cuantitativa para el diseiio arqui- El an6lisis de seleccibn del disefio es otro modelo
tectonic0 que requiere un cuadro de dimensiones de disefio para
Uno de 10s muchos problemas con 10s que se enfrentan ser definido. La arquitectura propuesta es entonces eva-
10s ingenieros del software durante el proceso de dise- luada para determinar el n6mero de dimensiones del
fio es la carencia general de mCtodos cuantitativos para disefio que se logran cuando se compara con un siste-
la evaluaci6n de la calidad de 10s diseiios propuestos. ma ideal (el mejor caso). Por ejemplo, si una arquitec-
El enfoque MACA recogido en la Secci6n 14.4.1 repre- tura propuesta alcanzara una reutilizacidn de
senta un enfoque innegablemente cualitativo y util para componentes excelente, y esta dimension es requerida
el anilisis del disefio. para el sistema ideal, la dimensi6n de reutilizaci6n ha
El diseiio debe ser todavia aplicable a1 problema actual, incluso si El diseno seria optimo, pero las restricciones,10s costes u otros fac-
la solucion no es particularmente buena. tores no permitiran su construccion.
sido lograda. Si la arquitectura propuesta tiene poca El EDC es bastante fhcil de implementar como un
. seguridad, y se necesita una gran seguridad, no se ha modelo de hoja de chlculo y puede ser utilizado para
alcanzado la dimensi6n del disefio. aislar porquC un cuadro de alternativas de disefio obtie-
Calculamos el indice de seleccidn del disefio, d , ne unas notas menores que otro.
como:
d=(N,lN,)x100 14.4.3. Complejidad arquitecthica
donde N, es el nlimero de dimensiones de disefio logra- Para evaluar la complejidad total de una arquitectura
das en la arquitectura propuesta y Noes el nlimero total dada, una tCcnica litil consiste en considerar las rela-
de dimensiones en el espacio de disefio. A mayor indi- ciones de dependencia entre 10s componentes de la
ce de selecci6n del disefio, mhs cerca estamos de que la arquitectura. Estas relaciones de dependencia son con-
arquitectura propuesta alcance el sistema ideal. ducidas a travCs de 10s flujos de informacibnlcontrol
dentro del sistema.
El andisis de contribucidn 4dentifica las razones por Zhao [ZHA98] propone tres tipos de dependencia:
las que un grupo de alternativas de disefio obtiene unas
Dependencias de compartimiento, representan las relacio-
notas menores que otro>>.[SHA96] Retomando el estu-
nes de dependencia entre 10s consumidores que utilizan 10s
dio del despliegue de la funcidn de calidad (DFC) vis- mismos recursos o 10s productores que producen para 10s mis-
to en el Capitulo 11, el anhlisis de valor se realiza para mos consumidores. Por ejemplo, tenemos dos componentes u
determinar la prioridad relativa de 10s requisitos deter- y v, si u y v se refieren a 10s rnismos datos globales, entonces
minados durante el despliegue de funciones, el desplie- existe una dependencia de cornpartimiento entre ambos.
gue de informaci6n y el despliegue de tareas. Se identifica Dependencias deflujo, representan las relaciones de depen-
un conjunto de <<mecanismosde realizaci6nn (caracte- dencia entre 10s productores y 10s consumidores de recursos.
risticas de la arquitectura). Se crea un listado con todos Por ejemplo, entre dos componentes u y I,, si 11 debe comple-
10s requisitos del cliente (determinados a travCs del DFC) tarse antes de que el control fluya a v (prerrequisito), o si u y v
se comunican a travCs de parhehos, entonces existiri una rela-
y una matriz de referencias cruzadas. Las celdas de la ci6n de dependencia de flujo entre ambos.
matriz indican (en una escala del 1 a1 10) la fuerza rela-
tiva de la relaci6n entre un mecanismo de realization y Dependencias restrictivas,representan las reshicciones de
un relativo flujo de control entre un cuadro de actividades. Por
un requisito para cada arquitectura propuesta. A esto se ejemplo, dos componentes u y v, si u y v no se pueden ejecu-
le conoce como espacio de disefio cuantificado (EDC). tar a1 mismo tiempo (por exclusi6n mutua), entonces existiri
una dependencia restrictiva entre u y v.
Las dependencias de compartimiento y de flujo reco-
gidas por Zhao se parecen de alguna forma a1 concep-
to de acoplamiento visto en el Capitulo 13. En el
Capitulo 19 se explicarhn mediciones sencillas para la
Hojo de cblculo DFC evaluaci6n de las dependencias.
En el Capitulo 13 ya dijimos que 10s requisitos del soft- Para ilustrar un enfoque de conversi6n arquitectbni-
ware pueden ser convertidos en varias representaciones ca, consideraremos la arquitectura de llamada y retorno
del modelo de disefio. Los estilos arquitect6nicos vis- -una estructura muy comlin para diferentes tipos de sis-
tos en la Secci6n 14.3.1 representan arquitecturas radi- temas6-. La tkcnica de conversi6n que se presenta capa-
calmente diferentes, por lo cual no deberia sorprendernos cita a1 disefiador para derivar arquitecturas de llamada y
que no exista una unica conversion que logre una tran- retorno razonablemente complejas en diagramas de flu-
sici6n del modelo de requisitos a1 modelo de disefio. De jo de datos dentro del modelo de requisitos.
hecho, todavia no existe una conversi6n para algunos La tCcnica, a veces denominada diseiio estructura-
modelos arquitect6nicos, y el disefiador debe lograr la do, tiene sus origenes en antiguos conceptos de disefio
traducci6n de 10s requisitos del disefio para esos estilos que defendian la modularidad [DEN73], el disefio des-
de una forma ad hoc. cendente [WIR71] y la programaci6n estructurada
Tambien es importante mencionar que las arquitecturas de llamada

y retorno pueden residir dentro de otras arquitecturas mas sofistica-
das vistas anteriormente en este capitulo. Por ejemplo, la arquitec-
tura de uno o varios componentes de una arquitectura cliente/se~dor
podria ser de llamada y retorno.
[DAH72, LIN791. Stevens, Myers y Constantine

[STE74] propusieron el disefio del software basado en
el fluyo de datos a travCs de un sistema. Los primeros
trabajos se refinaron y se presentaron en libros de Myers
[MYE78], Yourdon y Constantine [YOU79].
14.5.2. Flujo de transacci6n
iCuiles son 10s pasos
a seguir en la evaluation El modelo fundamental de sistema implica un flujo de
del DFD en una arquitectura de transformacion; por tanto, es posible caracterizar todo
llamada y retorno? el flujo de datos en esta categoria. Sin embargo, el flu-
jo de informaci6n esta caracterizado a menudo por un
El disefio estructurado suele caracterizarse como un unico elemento de datos, denominado transacci6n, que
mCtodo de disefio orientado a1 flujo de datos porque per- desencadena otros flujos de informacion a lo largo de
mite una c6moda transici6n desde el diagrama depu- uno de 10s muchos caminos posibles. Cuando un DFD
jo de datos (DFD) a la arquitectura de software7. La toma la forma mostrada en la Figura 14.4, lo que tene-
transicion desde el flujo de informaci6n (representado mos es unpujo de transacci6n.
como un diagrama de flujo de datos) a una estructura
del programa se realiza en un proceso de seis pasos: (1)
se establece el tip0 de flujo de informaci6n; (2) se indi-
can 10s limites del flujo; (3) se convierte el DFD en la Transaccion
\
estructura del programa; (4) se define la jerarquia de
control; ( 5 ) se refina la estructura resultante usando
medidas y heuristicas de disefio, y (6) se refina y ela-
bora la description arquitectonica.
El tip0 de flujo de informacion es lo que determina
el mCtodo de conversi6n requerido en el paso 3. En las
siguientes secciones examinamos 10s dos tipos de flujo.
14.5.1. Flujo de transformaci6n

Retomando el modelo fundamental de sistema (nivel 0
del diagrama de flujo de datos), la informaci6n debe
introducirse y obtenerse del software en forma de ttmun-
Por ejemplo, 10s datos escritos con un tecla-
do exterior>>.
do, 10s tonos en una linea telefonica, y las imiigenes de
video en una aplicaci6n multimedia son todas formas de FIGURA 14.4. Flujo de transaccion.
informacion del mundo exterior. Tales datos internos
deben convertirse a un formato intemo para el procesa- El flujo de transaccion se caracteriza por datos que
miento. La informaci6n entra en el sistema a lo largo de se mueven a lo largo de un camino de entrada que con-
caminos que transforman 10s datos extemos a un for- vierte la informacih del mundo exterior en una tran-
mato intemo. Estos caminos se identifican comopujo de saccion. La transaccion se evalha y, basandose en ese
entrada. En el interior del software se produce una tran- valor, se inicia el flujo a lo largo de uno de muchos cami-
sicion. La informaci6n entrante se pasa a travCs de un nos de accibn. El centro del flujo de informaci6n del
centro de transformacibn y empieza a moverse a lo lar- que parten muchos de 10s caminos de acci6n se deno-
go de caminos que ahora conducen hacia afuera>>del mina centro de transacci6n.
software. Los datos que se mueven a lo largo de estos Deben'a recalcarse que dentro del DFD de un siste-
caminos se denominanflujo de salida. El flujo general ma grande, ambos flujos de transaccion y de transfor-
de datos ocurre de manera secuencial y sigue un, o unos maci6n pueden presentarse. Por ejemplo, en un flujo
pocos, caminos8 <<directow.Cuando un segment0 de un orientado a transaccion, el flujo de informacion a lo lar-
diagrama de flujo de datos presenta estas caracten'sticas, go de un camino de accion puede tener caracteristicas
lo que tenemos presente es unpujo de transformacidn. de flujo de transformaci6n.
' Debe recordarse que tambien durante el modelado de analisis se aUn analisis obvio de este tip0 de flujo de informacion lo encontra-
utilizan otros elernentos del metodo de analisis (por ejemplo; el mos en la Seccion 14.3.1 en la arquitectura de flujo de datos. Sin
diccionario de datos, EP, EC). embargo, hay muchos casos en 10s que la arquitectura de flujo de
datos no seria la mejor eleccion para un sistema cornplejo. Los ejem-
plos incluyen sisternas que sufririan carnbios sustanciales en el tiempo,
o sistemas en 10s cuales el procesamiento asociado con el flujo de
datos no es necesariamente secuencial.
CAPfTULO 14 DISENO ARQUITECT6NICO
El andisis de las transformaciones es un conjunto de de requisitos del software. Ambos documentos descri-
pasos de diseiio que permite convertir un DFD, con carac- ben el flujo y la estructura de la informaci6n en la inter-
tensticas de flujo de transformaci6n, en un estilo arqui- faz del software. Las Figuras 14.5 y 14.6 muestran el
tect6nico especifico. En esta secci6n se describe el andisis nivel 0 y 1 del flujo de datos del software HogarSeguro.
de las transformaciones aplicando 10s pasos de diseAo a Paso 2. Revisar y refinar 10s diagramas de flujo
un sistema de, por ejemplo, una parte del software de de datos del software. La informaci6n obtenida de 10s
HogarSeguro presentado en capitulos anteriores. modelos de anilisis contenidos en la Especijicacidn de
Requisitos del Software se refina para obtener mayor
14.6.1. Un ejemplo detalle. Por ejemplo, se examina el DFD del nivel2 de
El sistema de seguridad HogarSeguro, presentado ante- monitorizar sensores (Fig. 14.7) y se obtiene un dia-
riormente en este libro, es representativo de muchos grama de flujo de datos de nivel3 como se muestra en
productos y sistemas basados en computadora actual- la Figura 14.8. En el nivel 3, cada transformaci6n en
mente en uso. El product0 vigila el mundo real y reac- el diagrama de flujo de datos presenta una cohesi6n
ciona ante cambios que encuentra. TarnbiCn interacciona relativamente alta (Capitulo 13). Es decir, el proceso
con el usuario a travCs de una sene de entradas por tecla- implicado por una transformaci6n realiza una funci6n
do y visualizaciones alfanumCricas. El nivel 0 del dia- h i c a y distinta que puede implementarse como un
grama de flujo de datos de HogarSeguro, reproducido m6dulo9en el software HogarSeguro. Por tanto, el DFD
del Capitulo 12, se muestra en la Figura 14.5. de la Figura 14.8 contiene suficiente detalle para esta-
blecer un diseiio cciniciab de la arquitectura del sub-
sistema de monitorizar sensores y continuamos sin mis
refinamiento.
Qowuos
HogarSegum Si el DFD es refinodo mds de uno vez, se esforzord poi
Alarrna
derivor burbujos que presenton gron cohesion.
D
Tonos
Sensores del sensor Paso 3. Determinar si el DFD tiene caracteristicas
de flujo de transformacion o de transaccion. En gene-
ral, el flujo de informaci6n dentro de un sistema puede
FIGURA 14.5. DFD a nivel de context0 para HogarSeguro. representarse siempre como una transformaci6n. Sin
embargo, cuando se encuentra una caracteristica obvia
Durante el anhlisis de requisitos, se habrin creado de transacci6n (Fig. 14.4), se recomienda una estruc-
mis modelos detallados del flujo para HogarSeguro. tura de diseiio diferente. En este paso, el diseiiador selec-
Ademis, se crearhn las especificaciones de control y ciona la caracteristica general del flujo (de la amplitud
proceso, un diccionario de datos y varios modelos de del software) basindose en la propia naturaleza del DFD.
comportamiento. Ademis, se aislan regiones locales de flujo de transfor-
maci6n o de transacci6n. Estos subJEujospueden usarse
para refinar la estructura del programa obtenida por la
14.6.2. Pasos del diseiio caracteristica general que prevalece. Por ahora, con-
El ejemplo anterior se usari para il'ustrar cada paso en centraremos nuestra atenci6n solamente en el flujo de
el anilisis de las transformaciones. Los pasos empiezan datos del subsistema de monitorizaci6n de sensores mos-
con una reevaluaci6n del trabajo hecho durante el ani- trado en la Figura 14.7.
lisis de requisitos y despuCs evoluciona hacia el diseiio
de la arquitectura del software.
Paso 1. Revisar el modelo fundamental del sis-
tema. El modelo fundamental del sistema comprende A rnenudo se podran enconhar arnbos tipos de fluio de
el DFD de nivel 0 y la informaci6n que lo soporta. En datos denho del rnisrno modelo de anblisis. Los flujos se
realidad, el paso de diseiio empieza con una evaluaci6n dividen y la estructura del prograrna se deriva utilizando
de la especijicacidn del sistema y de la especificacidn el an6lisis adecuado.
9 La utilizacion del termino modulo en este capitulo equivale al ter-

mino componente usado anteriormente en el estudio de la arquitec-
tura de software.
Evaluando el DFD (Fig. 14.8), vemos que 10s datos dos limites sombreados que van de arriba abajo en el
, entran a1 software por un camino de entrada y salen por dibujo. Se podria argumentar alg6n cambio para rea-
tres caminos de salida. No se distingue ning6n centro justar 10s limites (por ejemplo, se podria proponer un
de transacci6n (aunque la transformaci6n establecer las limite del flujo de entrada que separe leer sensores, de
condiciones de alarma podria percibirse como tal). Por adquirir informacidn de respuesta). El Cnfasis en este
tanto, se asumirh una caracteristica general de transfor- paso del disefio deberia ponerse en seleccionar limites
maci6n para el flujo de informaci6n. razonables, en vez de largas disquisiciones sobre la colo-
caci6n de las separaciones.
Paso 5. Realizar una iidescomposicion de primer
decontrol
niveb. La estructura del programa representa una dis-
tribuci6n descendente del control. La descomposici6n
en partes provoca una estructura de programa en la que
Cofigurar 1
\ 10s m6dulos del nivel superior realizan la toma de deci-
el sistema \
siones y 10s m6dulos del nivel inferior realizan la mayo-
ria del trabajo de entrada, chlculos y salida. Los m6dulos
de nivel intermedio realizan alg6n control y cantidades
moderadas de trabajo.
nforrnacion
FIGURA 14.6. Nivel 1 del DFD del HogarSeguro.
Paso 4. Aislar el centro de transformacion especi-

ficando 10s limites de 10s flujos de entrada y salida.
En la secci6n precedente el flujo de entrada se describi6
de telefono
como un camino en el que la informaci6n se convierte
de formato externo en interno; el flujo de salida convierte FIGURA 14.7. Nivel2 del DFD que refina el proceso
de formato interno a externo. Los limites del flujo de de monitorizar sensores
entrada y el de salida son interpretables. Es decir, 10s
disefiadores pueden elegir puntos ligeramente diferen- Cuando encontramos un flujo de transformaci6n, un
tes como limites de flujo. De hecho, se pueden obtener DFD se organiza en una estructura especifica (una arqui-
soluciones de &efio alternativas variando la posici6n tectura de llamada y retorno) que proporciona control
de 10s limites de flujo. Aunque hay que tener cuidado para el procesamiento de informaci6n de entrada, trans-
cuando se seleccionan 10s limites, una variaci6n de una formaci6n y de la salida. Esta descomposici6n en fac-
burbuja a lo largo de un camino de flujo tendrh general- tores o primer nivel del subsistema de monitorizar
mente poco impact0 en la estructura final del programa. sensores se ilustra en la Figura 14.9. Un controlador
principal, denominado gestor de monitorizacion de
sensores, reside en la parte superior de la estructura del
programa y sime para coordinar las siguientes funcio-
Combio lo situocibn de 10s fronteras de fluio en un nes de control subordinadas:
esfuerzopor exploror 10s esiructuros de progromo un controlador de procesamiento de la informaci6n de
olternotivos. No llevo mucho tiempo y puede entrada denorninado controlador de la entrada del sen-
proporcionornos importantes ideas. sor, coordina la recepci6n de todos 10s datos de entrada;
un controlador del flujo de transfonnaci6n, denomi-
Los limites de flujo del ejemplo se ilustran como cur- nado controlador de las condiciones de alarma, super-
vas sombreadas que van verticales a travCs del flujo en visa todas las operaciones sobre 10s datos en su forma
la Figura 14.8. Las transformaciones (burbujas) que for- interna (por ejemplo; un m6dulo que invoca varios
man el centro de transformaci6n se encuentran entre 10s procedimientos de transformaci6n de datos);
FIGURA 14.8. Nivel 3 del DFD de rnonitorizar sensores con 10s limites de flujo.
un controlador de procesamiento de informacion de

salida, denominado controlador de la salida de alarma,
coordina la production de la informacion de salida.
No seas dogmatito en esto porte. Podrio ser necesorio

estoblecer dos o mas controlodores de procesomiento de
entrodo o computucibn, o couso de lo complejidod del
sistemo o construic Si el sentido comcin mite lo dicto, hozlo.
Aunque la Figura 14.9 implica una estructura con tres

ramas, en grandes sistemas la complejidad del flujo puede
hacer que existan dos o m8s m6dulos de control, uno para
cada una de las funciones genkricas descritas anteriormente.
El numero de m6dulos del primer nivel deberia limitarse
a1 minimo que pueda realizar las funciones de control de la monitorizacion
y mantener a1 mismo tiempo unas buenas caracteristi-
cas de acoplamiento y cohesi6n.
Paso 6. Realizar <<descomposicionde segundo
niveb. La descomposici6n de segundo nivel se realiza
mediante la conversi6n de las transformaciones indivi-
duales (burbujas) de un DFD en 10s m6dulos corres-
pondientes dentro de la arquitectura. Empezando desde IFIGURA 14.9. Descomposicion de primer nivel
el limite del cenuo de transformaci6n y movikndonos para la monitorizacion de sensores.
249
hacia fuera a lo largo de 10s caminos de entrada, y luego miento pueden llevar a cambios en la estructura, pero
de salida, las transformaciones se convierten en niveles puede servir como una primera iteraci6n del diseiio.
subordinados de la estructura del software. El enfoque
general del segundo nivel de descomposici6n del flujo
de datos HogarSegwu se ilustra en la Figura 14.10.
Monren bojos 10s controlodores de trobojo en lo esrructuro
Aunque la Figura 14.10 ilustra una correspondencia
del progromo. Asi, lo orquitecturo ser6 m6s f6cil de modificor.
una a uno entre las transformaciones del DFD y 10s
m6dulos del software, ocurren frecuentemente diferen-
tes conversiones. Se pueden combinar dos o incluso tres La descomposici6n de factores de segundo nivel del
burbujas y representarlas como un solo m6dulo flujo de entrada sigue de igual manera. La descompo-
(teniendo presente 10s problemas potenciales de la cohe- sici6n en factores se realiza de nuevo movihdose hacia
si6n), o una sola burbuja puede dividirse en dos o miis fuera desde el limite del centro de transformaci6n
m6dulos. Las consideraciones prkticas y las medidas correspondiente al flujo de entrada. El centro de trans-
de la calidad dictan el resultado de la descomposici6n formaci6n del software del subsistema de monitorizar
en factores de segundo nivel. La revisi6n y el refina- sensores se direcciona de manera algo diferente. Cada
de la monitorizacibn
Controlador
senal de alarma
visualizacidn
I Generar
visualizacidn
FIGURA 14.10. Descomposicion de factores de segundo nivel de monitorizacion de sensores.

CAP~TULO
14 DISENO AROUITECT6NICO
conversion de datos o transformaciones de cilculo de El texto explicative sime como una primera genera-
. la porci6n de transformacion del DFD se convierte en ci6n de la especificacion de disefio. Sin embargo, se dan
un modulo subordinado a1 controlador de transforma- mis refinamientos y adiciones regularmente durante este
cibn. En la Figura 14.11 se muestra una estructura de period0 de disefio.
programa completa de primera iteracion. Paso 7. Refinar la estructura inicial de la arquitec-
Los modulos direccionados de la manera descrita tura usando heuristicas para mejorar la calidad del
anteriormente y mostrados en la Figura 14.11 repre- software. Una primera estructura de arquitectura siempre
sentan un disefio inicial de la estructura del programa. puede refinarse aplicando 10s conceptos de independen-
Aunque 10s modulos se nombran de manera que indi- cia de modulos (Capitulo 13). Los modulos se incremen-
quen su funcion, se deberia escribir para cada uno un tan o reducen para producir una descomposici6n razonable,
breve texto que explique su procesamiento (adaptado buena cohesion, acoplamiento minimo y lo mis impor-
del EP creado durante la modelacion de anilisis). El tante, una estructura que se pueda implementar sin difi-
texto describe: cultad, probarse sin confusion y mantenerse sin problemas.
la informacion que entra y la que sale fuera del Los refinamientos se rigen por el analisis y 10s mCto-
m6dulo (una descripcion de la interfaz); dos de evaluacion descritos brevemente en la Seccion
la informacion que es retenida en el modulo, por 14.4, asi como por consideraciones practicas y por el
sentido comun. Hay veces, por ejemplo, que el contro-
ejemplo, datos almacenados en una estructura de
datos local; lador del flujo de datos de entrada es totalmente inne-
cesario, o se requiere cierto procesamiento de entrada
una descripcion procedimental que indique 10s prin- en un modulo subordinado a1 controlador de transfor-
cipales puntos de decision y las tareas; macion, o no se puede evitar un alto acoplamiento
un pequeiio estudio de las restricciones y caracteris- debido a datos generales, o no se pueden lograr las carac-
ticas especiales (por ejemplo, archivo 110, caracte- teristicas estructurales optimas (vea la Seccion 13.6).
risticas dependientes del hardware, requisitos Los requisitos del software junto con el buen juicio son
especiales de tiempo). 10s irbitros finales.
Elimino 10s rnodulos de control redundontes. Es decir, si Ontrese en lo independencio funcionol de 10s modulos
on m 6 d h de control no hoce o m coso que controlor que derive. Su objetivo debe ser uno cohesion alto
otro mhdolo, esto funcion de control deberh explotorse y un ocoplomiento dibil.
o moyor nivel.
de la monitorizacion
de sensores
Controlador Controlador Controlador

de la entrada de las cond~ciones de salida
del sensor de la alarma
informacion las condiciones el ntjmero la conexion

seAal de alarma
de la alarma de telefono visualization a la red telefonica
u sensores
FIGURA 14.11. Primera iteracion de la estructura del programa para monitorizarsensores.

Generar
pulsos
en la linea
251
Se pueden hacer muchas modificaciones a la primera En la Figura 14.12 se muestra la estructura del soft-
estructura desarrollada para el subsistema de monitori- ware refinada del subsistema de monitorizar sensores.
zar sensores de HogarSeguro. Algunas de ellas son: El objetivo de 10s siete puntos anteriores es desarro-
El controlador del flujo de entrada se puede elimi- llar una representaci6n general del software. Es decir,
nar porque es innecesario cuando s6lo hay que mane- una vez que se ha definido la estructura, podemos eva-
jar un solo camino de flujo de entrada. luar y refinar la arquitectura del software viCndola en
La subestructura generada del flujo de transforma- su conjunto. Las modificaciones hechas ahora requie-
ci6n puede reducirse en el m6dulo establecer las ren poco trabajo adicional, per0 pueden tener un gran
condiciones de alarma (que incluirh ahora el pro- impact0 en la calidad del software.
cesamiento implicado por seleccionar numero de El lector deberia reflexionar un momento y consi-
telefono). El controlador de transformaci6n no sera derar la diferencia entre el enfoque de diseiio descri-
necesario y la pequeiia disminuci6n en la cohesi6n to anteriormente y el proceso de ccescribir programas,,.
es tolerable. Si el c6digo es la 6nica representaci6n del software,
Los modulos dar formato de visualizacion y gene- el desarrollador tendrh grandes dificultades en eva-
rar la visualizacion pueden unirse (asumimos que dar luar o refinar a nivel general u holistico y, de hecho,
formato de visualizaci6n es bastante simple) en un tendrh dificultad para que cclos arboles dejen ver el
nuevo modulo denominado producir visualizacion. bosque,,.
En muchas aplicaciones software, un solo elemento de 14.6. Refinando el flujo, se desarrolla un nivel 2 del
datos inicia uno o varios de 10s flujos de informaci6n diagrama de flujo (tambiCn se crearian un diccionario
que llevan a cab0 una funci6n derivada por el elemento de datos correspondiente, EC y EP) que se muestra en
de datos iniciador. El elemento de datos, denominado la Figura 14.13.
transaccibn, y sus caracteristicas de flujo correspon- Como se muestra en la figura, ordenes y datos del
dientes se trataron en la Secci6n 14.5.2. En esta sec- usuario fluye a1 sistema y provoca un flujo de infor-
ci6n consideramos 10s pasos de diseiio usados para maci6n adicional a lo largo de uno de tres caminos de
tratar el flujo de transaccibn. acci6n. Un elemento de datos, tipo de orden, hace que
el flujo de datos se expanda del centro. Por tanto, la
Gestor caracteristica general del flujo de datos es de tipo tran-
de la monitorizacion
de sensores sacci6n.
Debena recalcarse que el flujo de informaci6n a lo
largo de dos de 10s tres caminos de acci6n acomodan
flujos de entrada adicionales (por ejemplo, parametros
~nformacion las condiciones de salida y datos del sistema son entradas en el camino de acci6n
de respuesta de la alarma a ccconfigurar>>).Todos 10s caminos de acci6n fluyen a
una sola transformaci611, mostrar mensajes y estado.
14.7.2. Pasos d e l diseiio

sensores
a la red telefonica Los pasos del diseiio para el anhlisis de las transaccio-
nes son sirnilares y en algunos casos idknticos a 10s pasos
para el anhlisis de las transformaciones (Secci6n 14.6).
Generar pulsos La principal diferencia estriba en la conversion del DFD
en la linea en la estructura del software.
Paso 1. Revisar el modelo fundamental del sis-
FIGURA 14.12. Estructura refinada del programa tema.
para monitorizar sensores. Paso 2. Revisar y refinar 10s diagramas de flujo de
datos para el software.
14.7.1. Un ejemplo Paso 3. Determinar si el DFD tiene caracteristicas
El analisis de las transacciones se ilustrari conside- de flujo de transformation o de transaccion. Los pasos
rando el subsistema de interaccidn con el usuario del 1, 2 y 3 son idCnticos a 10s correspondientes pasos del
software HogarSeguro. El nivel 1 del flujo de datos de anhlisis de las transformaciones. El DFD mostrado en la
este subsistema se muestra como parte de la Figura Figura 14.13 tiene la clfisica caracteristicade flujo de tran-
FIGURA 14.13. Nivel 2 de DFD para el subsisterna de interacion del usuario con lirnites del flujo.
sacci6n. Sin embargo, el flujo a lo largo de dos de 10s se desarrolla de la misma manera que para un anilisis
caminos de acci6n que emanan desde la burbuja invocar de transformaci6n. Empezando por el centro de tran-
elprocesamiento de la orden parece tener caracteristicas saccibn, las burbujas que hay a lo largo del camino de
de flujo de transformaci6n. Por tanto, se deben estable- entrada se convierten en m6dulos. La estructura de la
cer 10s limites de flujo para ambos tipos de flujos. rama de distribution contiene un m6dulo distribuidor
Paso 4. Identificar el centro de transaccion y las que controla todos 10s m6dulos de accion subordina-
caracteristicas de flujo a lo largo de cada camino de dos. Cada camino de flujo de acci6n del DFD se con-
accion. La posici6n transacci6n se puede discemir inme- vierte en una estructura que corresponde a sus
diatamente del DFD. El centro de transacci6n esti en el caracteristicas especificas de flujo. Este proceso se ilus-
origen de varios caminos de acci6n que fluyen radial- tra esquemiticamente en la Figura 14.14.
mente desde 61. Para el flujo mostrado en la Figura 14.13,
la burbuja invocar el procesamiento de la orden es el
centro de transacci6n.
El camino de entrada (por ejemplo el camino de flujo Lo descomposicibn de primer nivel tiene como resultodo
a lo largo del que se recibe una transacci6n) y todos 10s lo derivocibn de lo ierorquio de control puru el software.
caminos de acci6n deben aislarse. Los limites que definen Lo descomposicibn de segundo nivel distribuye 10s
modulos de troboio o 10s controlodores opropiudos.
un camino de recepci6n y 10s caminos de acci6n tambiCn
se muestran en la figura. Se debe evaluar las caracteristi- Considerando el flujo de datos del subsistema de inte-
cas individuales de flujo de cada camino de acci6n. Por raccidn del usuario, la descomposici6n de primer nivel
ejemplo, el camino ccde la contraseiia>>
(mostrado incluido del paso 5 se muestra en la Figura 14.15. Las burbujas
en un hrea sombreada en la Fig. 14.13) tiene caracteristi- leer 6rdenes del usuario y activarldesactivar el sistema
cas de transformaci6n. Los flujos de entrada, de transfor- se convierten directamente en la arquitectura, sin la nece-
maci6n y de salida se indican con limites. sidad de m6dulos intermedios de control. El centro de
Paso 5. Transformar el DFD en una estructura de transacch, invocar el procesamiento de la orden, se
programa adecuada al procesamiento de la tran- convierte directamente en un m6dulo distribuidor con
saccion. El flujo de transacci6n se convierte en una el mismo nombre. Los controladores de la configura-
arquitectura que contiene una rama de entrada y una ci6n del sistema y procesamiento de la contrasefia se
rama de distribuci6n. La estructura de la rarna de entrada obtienen como se indica en la Figura 14.16.
253
INGENIER~ADEL SOFTWARE. UN ENFOQUE PRACTICO
Gestor
3rr
Distribuidor de la interaccion
Camino
de recepcion con el usuario
del sisterna de la contraseha
FIGURA 14.15. Descomposicion en factores de primer nivel

del subsistema interaccion del usuario.
Gestor
de la interaccion
I Leer ordenes
del usuario
C
lnvocar
el procesamiento
Construir archivos
de la contraseha
Mostrar
un mensaje
mensaje
de contrasetia
y estado
FIGURA 14.16. Primera iteracion de la estructura del programa del subsistema interaccion del usuario.
254
Paso 6. Descomponer y refinar la estructura de y un mensaje de advertencia (flujo de salida) si no
. transaccion y la estructura de todos 10s caminos de coincide con ninguna.
accion. Cada camino de acci6n del diagrama de flujo El camino ccconfiguraru se dibuja similarmente
de datos tiene sus propias caracteristicas de flujo de usando el analisis de transformaci6n. La arquitectura de
informaci6n. Ya hemos dicho anteriormente que se software resultante se muestra en la Figura 14.16.
pueden encontrar flujos de transformaci6n o de tran-
sacci6n. La ccsubestructura>> relacionada con el camino Paso 7. Refinar la primera arquitectura del pro-
de acci6n se desarrolla usando 10s pasos estudiados grama usando heuristicas de diseno para mejorar la
en esta secci6n y en la anterior. calidad del software. Este paso del analisis de tran-
sacci6n es idCntico a1 correspondiente paso del analisis
Por ejemplo, considere el flujo de informacidn del
de transformaci6n.
procesamiento de contraseiia mostrado (dentro del
area sombreada) en la Figura 14.13. El flujo presenta En ambos mCtodos de disefio se deben considerar cui-
las caractensticas clasicas de transformaci6n. Se intro- dadosamente criterios tales como independencia del
duce una contrasefia (flujo de entrada) y se transmite m6dul0, conveniencia (eficacia de implementaci6n y
a un centro de transformaci6n donde se compara con prueba) y facilidad de mantenimiento a medida que se
las contrasefias almacenadas. Se produce una alarma proponen modificaciones estructurales.
El Cxito de la aplicaci6n del analisis de transformaci6n o memoria o de tiempo, la delimitaci6n de 10s valores o
de transacci6n se complernenta aiiadiendo la documenta- cantidades de las estructuras de datos, 10s casos espe-
ci6n adicional requerida como parte del diseiio arquitec- ciales no considerados y las caracteristicas especificas
tbnico. DespuCs de haber desarrollado y refinado la de un m6dulo individual. El propdsito de una secci6n
estructura, se deben completar las siguientes tareas: restricciones/limitaciones es reducir el numero de erro-
se debe desarrollar una descripci6n del procesamiento res debidos a caracteristicas funcionales asumidas.
para cada mbdulo. Una vez que se ha desarrollado la documentaci6n de
se aporta una descripci6n de la interfaz para cada diseiio para todos 10s m&lulos, se lleva a cab0 una revisidn
m6dulo. (vea las directrices de revisi6n en el Capitulo 8). La revi-
si6n hace hincapiC en el seguimiento de 10s requisitos del
se definen las estructuras de datos generales y locales.
software, la calidad de la arquitecturadel p r o p a , las des-
se anotan todas las limitaciones/restricciones del cripciones de las interfaces, las descripciones de las estruc-
diseiio. turas de datos, 10s datos prhcticos de la implementaci6n, la
se lleva a cab0 una revisi6n del disefio. capacidad de prueba y la facilidad de mantenimiento.
se considera un ccrefinamiento>>(si es necesario y esta
justificado).
iQub pasa una vez que

la arquitectura ha sido creada?
Documento del diseiio de software.
Un texto explicativo del procesamiento es (ideal- Debe fomentarse el refinamiento de la arquitectura

mente) una delimitada descripci6n sin ambigiiedades del software durante las primeras etapas del disefio.
del procesamiento que ocurre dentro de un m6dulo. La Como ya dijimos anteriormente en este capitulo, 10s
narrativa describe el procesamiento, las tareas, las deci- estilos arquitect6nicos altemativos deben ser derivados,
siones y la entradalsalida. La descripci6n de la interfaz refinados y evaluados para un ccmejor>>enfoque. Este
requiere el disefio de interfaces internas de m6dul0, enfoque de optimizaci6n es uno de 10s verdaderos bene-
interfaces externas del sistema y la interfaz hombre- ficios derivados del desarrollo de la representaci6n de
computadora (Capitulo 15). El disefio de estructuras de la arquitectura del software.
datos puede tener un profundo impact0 en la arquitec- Es importante anotar que la simplicidad estructural es,
tura y en 10s detalles procedimentales de cada compo- a menudo, reflejo de elegancia y eficiencia. El rehamiento
nente del software. TambiCn se documentan las del diseiio debena luchar por obtener un pequeiio nume-
restricciones/limitaciones de cada m6dulo. Algunos ro de mddulos consecuentes a la modularidad operativa
aspectos tipicos que pueden tratarse incluyen: la res- y la estructura de datos menos compleja que sirva ade-
tricci6n de tip0 o formato de datos, las limitaciones de cuadamente a 10s requisitos de informaci6n.
La arquitectura del software nos proporciona una vision la eficacia de cada arquitectura propuesta. Esto se con-
global del sistema a construir. Describe la estructura y sigue determinando la sensibilidad de 10s atributos de
la organizaci6n de 10s componentes del software, sus calidad seleccionados (tambiCn llamados dimensiones
propiedades y las conexiones entre ellos. Los compo- del disefio) con diferentes mecanismos de realizaci6n
nentes del software incluyen m6dulos de programas y que reflejan las propiedades de la arquitectura.
varias representaciones de datos que son manipulados El mCtodo de disefio arquitect6nico presentado en
por el programa. Ademas, el disefio de datos es una par- este capitulo utiliza las caractensticas del flujo de datos
te integral para la derivation de la arquitectura del soft- descritas en el modelo de anilisis que derivan de un esti-
ware. La arquitectura marca decisiones de disefio lo arquitect6nico utilizado comtinmente. El diagrama
tempranas y proporciona el mecanismo para evaluar 10s de flujo de datos se descompone dentro de la estructu-
beneficios de las estructuras de sistema altemativas. ra del sistema a travCs de dos enfoques de analisis -1
El disefio de datos traduce 10s objetos de datos defi- analisis de las transformaciones y/o el analisis de las
nidos en el modelo de anilisis, en estructuras de datos transacciones-. Se aplica el analisis de las transfor-
que residen dentro del software. Los atributos que des- maciones a un flujo de informaci6n que presenta dife-
cribe el objeto, las relaciones entre 10s objetos de datos rentes limites entre 10s datos de entrada y de salida. El
y su uso dentro del programa influyen en la elecci6n de DFD se organiza en una estructura que asigna 10s con-
la estructura de datos. A mayor nivel de abstraccibn, el troles de entrada, procesamiento y salida a travCs de tres
disefio de datos conducira a lo que se define como una jerarquias separadas de modules de descomposici6n en
arquitectura para una base de datos o un almacen de datos. factores. El analisis de las transformaciones se aplica
El ingeniero del software cuenta con diferentes esti- cuando un tinico item de information bifurca su flujo a
10s y patrones arquitect6nicos. Cada estilo describe una travCs de diferentes caminos. El DFD se organiza en
categoria de sistema que abarca un conjunto de com- una estructura que asigna el control a una subestructu-
ponentes que realizan una funcion requerida por el sis- ra que adquiere y evaltia la transacci6n. Otra subes-
tema, un conjunto de conectores que posibilitan la tructura controla todas las acciones potenciales de
comunicaci6n, la coordinaci6n y cooperacion entre 10s procesamiento basadas en la transacci6n. Una vez que
componentes, las restricciones que definen c6mo se inte- la arquitectura ha sido perfilada se elabora y se analiza
gran 10s componentes para conformar el sistema, y 10s contrastandola con 10s criterios de calidad.
modelos semanticos que facilitan a1 disefiador el enten- El disefio arquitectonico agrupa un grupo inicial de
dimiento de todas las partes del sistema. actividades de disefio que conducen a un modelo com-
Han sido propuestos uno o varios estilos arquitect6- pleto del disefio del software. En 10s siguientes capitu-
nicos por sistema, y el mCtodo de anilisis de compro- los, se estudiari el disefio de las interfaces y de 10s
misos para la arquitectura podna utilizarse para evaluar componentes.
[AH0831 Aho, A.V., J. Hopcroft y J.Ullmann, Data Structu- [KAZ98] Kazman, R. The Architectural Tradeoff Analysis
res and Algorithms, Addison-Wesley, 1983. Method, Software Engineering Institute, CMU/SEI-98-
[BAS981 Bass, L., P. Clements y R. Kazman, Sofhlare Archi- TR-008, Julio 1998.
tecture in Practice, Addison-Wesley, 1998. [KIM981 Kimball, R., L. Reeves, M. Ross y W. Thornthwai-
[DAH72] Dah, O., E. Dijkstra y C. Hoare, Structured Pro- te, The Data Warehouse Lifecycle Toolkit: Expert Methods
gramming, Academic Press, 1972. for Designing, Developing, and Deploying, Data Ware-
houses, Willey, 1998.
[DAT95] Date, C.J., An Introduction to Database Systems,
Sexta Edicion, Addison-Wesley, 1995. [LIN79] Linger, R.C., H.D. Mills y B.I. Witt, Structured Pro-
[DEN731 Dennis, J.B., <<Modularity)>,
en Advanced Course gramming, Addison-Wesley, 1979.
on Software Engineering, F.L. Bauer (ed.), Springer-Ver-
lag, Nueva York, 1973, pp. 128-182. [MAT961 Mattison, R., Data Warehousing: Strategies, Tech-
nologies and Techniques, McGraw-Hill, 1996.
[FRE80] Freeman, P., <<TheContext of Design,), in Software
Design Techniques (L.P. Freeman y A. Wasserman, eds.), [MOR80] Moms, J., ccprogramming by Successive Refine-
IEEE Computer Society Press, 3." ed., 1980, pp. 2-4. ment of Data Abstractions>>,Software-Practice and Expe-
rience, vol. 10, num. 4, abril 1980, pp. 249-263.
[INM95] Inmon, W.H., <<Whatis a Data Warehouse?>)Prism
Solutions, Inc. 1995, presentada en: [MYE78] Myers, G., Composite Structures Design, Van-
http://www.cait.wustl.edu/cait/papers/prism/voIlpol. Nostrand, 1978.
C A P ~ T U L O14 DISENO ARQUITECT~NICO
[PET811 Peters, L.J., Software Design: Methods and Techni- [WAS801 Wasserman, A., <<Principlesof Systematic Data
ques, Yourdon Press, Nueva York, 1981. Design and Implementationn, en Software Design Tech-
[PRE98] Preiss, B.R. Data Structures and Algorithms: With niques (P. Freeman y A. Wasserman, eds.), 3." ed., IEEE
Object-Oriented Design Patterns in C + + , Wiley, 1998. Computer Society Press, 1980, pp. 287-293.
[SHA96] Shaw, M., y D. Garlan, Sofnyare Arquitecture, Pren- [WIR71] Wirth, N., <<ProgramDevelopment by Stepwise Refi-
tice Hall, 1996. nement,,, CACM, vol. 14, n." 4, 1971, pp. 22 1-227.
[SHA97] Shaw, M., y P. Clements, <<AField Guide to Boxo- [YOU791 Yourdon, E., y L. Constantine, Structures Design,
logy: Preliminary Classification of Architectural Styles for Prentice-Hall, 1979.
Software Systems>>,Proc. COMPSAC, Washington DC,
Agosto 1997. [ZHA98] Zhao, J., <<OnAssessing the Complexity of Soft-
ware Architectures)>,Proc. Intl. Softw~areArchitecture
[STE74] Stevens, W., G. Myers y L. Constantine, c<Structu- Workshop, ACM, Orlando, Florida, 1998, pp. 163-167.
red Design>>,IBM System Journal, vo1.13, n." 2 , 1974,
pp. 115-139.
14.1. Usando la arquitectura de una casa o un edificio a mod0 Estudie como afectari esta opinion a la estructura del soft-
de metafora, dibuje comparaciones con la arquitectura del ware que se obtiene cuando un flujo orientado a transaccih
software. iEn quC se parecen la disciplina de la arquitectura es tratado como de transfonnaci6n. Utilice un flujo de ejem-
clasica y la de la arquitectura del software? iEn quC se dife- plo para ilustrar 10s puntos importantes.
rencian?
14.12. Si no lo ha hecho, complete el Problema 12.12. Utili-
14.2. Escriba un documento de tres a cinco paginas que con- ce 10s mCtodos de diseiio descritos en este capitulo para desa-
tenga directrices para la seleccion de estructuras de datos rrollar una estructura de programa para el SSRB.
basandose en la naturaleza del problema. Empiece delimi-
tando las clasicas estructuras de datos que se encuentran en 14.13. Mediante un diagrama de flujo de datos y una des-
el software y despuCs describiendo 10s criterios para la selec- cripcidn del procesamiento, describa un sistema basado en
ci6n de Cstos para tipos particulares de problemas. computadora que tenga unas caracteristicas de flujo de trans-
fonnaci6n singulares. Defina 10s limites del flujo y transfor-
14.3. Explique la diferencia entre una base de datos que sir- me el DFD en la estructura software usando una tCcnica de las
ve a una o mas aplicaciones de negocios convencionales y un descritas en la Secci6n 14.6.
almacCn de datos.
14.14. Mediante un diagrama de flujo de datos y una des-
14.4. Escriba un documento de tres a cinco p5gina que descripcion de procesamiento, describa un sistema basado en
criba cdmo se utilizan las tCcnicas de mineria de datos en computadora que tenga unas caracteristicas de flujo de tran-
un entorno de negocio y el estado actual de las tCcnicas saccion claras. Defina 10s limites del flujo y direcciones el
DCBC. DFD en una estructura software utilizando la tCcnica descri-
14.5. Presente dos o tres ejemplos de aplicaciones para cada ta en la Seccidn 14.7.
estilo arquitect6nico citado en la Seccion 14.3.1. 14.15. Usando 10s requisitos obtenidos en un estudio hecho
14.6. Algunos de 10s estilos arquitectonicos citados en la Sec- en clase, complete 10s DFD y el diseiio arquitecthico para el
cion 14.3.1. son jerarquicos por naturaleza y otros no. Haga ejemplo HogarSeguro presentado en las Secciones 14.6 y 14.7.
una lista de cada tipo. iC6mo se implementan 10s estilos arqui- Valore la independencia funcional de todos 10s m6dulos. Docu-
tect6nicos no jerarquicos? mente su diseiio.
14.7. Seleccione una aplicaci6n que le sea familiar. Contes- 14.16. Estudie las ventajas y dificultades relativas de aplicar
te cada una de las preguntas propuestas para el control y 10s un diseiio orientado a1 flujo de datos en las siguientes fireas:
datos de la Secci6n 14.3.2. (a) aplicaciones de microprocesador empotrado, (b) analisis
14.8. Estudie el MACA (utilizando el libro de [KAZ98]) y de ingenieria/cientifico,(c) graficos por computadora, (d) dise-
presente un estudio detallado de 10s seis pasos presentados iio de sistemas operativos, (e) aplicaciones de negocio, (f) dise-
en la Seccidn 14.4.1. iio de sistemas de gesti6n de bases de datos, (g) disefio de
software de comunicaciones, (h) diseiio de compiladores, (i)
14.9. Seleccione una aplicaci6n que le sea familiar. Utili- aplicaciones de control de proceso y (j)aplicaciones de inte-
zando, donde sea requerido, su mejor intuicibn, identifique ligencia artificial.
el conjunto de dimensiones del diseiio y despuCs realice el
analisis del espectro y el analisis de la selecci6n del diseiio. 14.17. Dado un conjunto de requisitos que le proporcione
su profesor (o un conjunto de requisitos de un problema en
14.10. Estudie el EDC (utilizando el libro de [SHA96]) y el que estC trabajando actualmente) desarrolle un diseiio
desarrolle un espacio de diseiio cuantificado para una aplica- arquitect6nico completo. Lleve a cab0 una revisidn del dise-
cidn que le sea familiar. fio (Capitulo 8) para valorar la calidad de su diseiio. Este pro-
14.11. Algunos disefiadores defienden que todo el flujo de blema debe asignarse a un equipo en vez de a un solo
datos debe ser tratado como orientado a transfonnaciones. individuo.
INGENIERfA DEL SOFTWARE. U N ENFOQUE P R A C T I C O
Durante la ultima dCcada han aparecido muchisimos libros Docenas de libros actuales, a menudo abordan el disefio
sobre arquitectura de software. Los libros de Shaw y Cannon de datos y el disefio de estructuras desde un context0 especi-
[SHA96], Bass, Clements y Kazman [BAS981 y Buschmann fico del lenguaje de programacidn. Algunos ejemplos tipicos
y colaboradores[BUS98], proporcionan un tratamiento en 10s encontramos en:
profundidad sobre la materia. El primer trabajo de Garlan (An Horowitz, E. Y S. Sahni,Fundamentals of Data Structures
Introduction to Software Architecture, Software Engineering in Pascal, 4."ed., W.H. Freeman & Co., 1999.
Institute, CMUJSEI-94-TR-021, 1994) proporciona una exce-
Kingston, J.H., Algorithms and Data Structures: Design,
lente introduccidn a1 tema.
Correctness, Analysis, 2." ed., Addison-Wesley, 1997.
Los libros especificos de implementacibn de arquitectu-
ra, situan el disefio arquitectdnico dentro de un entorno espe- Main, M., Data Strucrures & Other Objects Using Java,
cifico de desarrollo o tecnologia. Mowray (CORBA Design Addison-Wesley, 1998.
Patterns, Wiley, 1997) y Mark y colaboradores (Object Mana- Preiss, B.R., Dara Structures and Algorithms: With Object-
gement Architecture Guide, Wiley, 1996) proporcionan para- Oriented Design Patterns in C++, Wiley, 1998.
metros de disefio detallados para el marco de soporte de las Sedgewick,R., Algorithms in C++: Fundamentals, Data
aplicaciones distribuidas de CORBA. Shanley (Protected Structures, Sorting, Searching, Addison-Wesley, 1999.
Mode Software Architecture, Addison-Wesley, 1996) pro- Standish,T.A., Data Structures in Ja\,a, Addison-Wesley,
porciona una guia de diseiio arquitectdnico para aquellos que 1997.
diseiien sistemas operativos a tiempo real basados en com- Standish,T.A., Data Structures,Algorithms, and Software
putadora, sistemas operativos multitarea o controladores de Principles in C , Addison-Wesley, 1995.
dispositivos.
Las investigaciones actuales sobre arquitectura de soft- En la mayoria de 10s libros dedicados a la ingenieria de soft-
ware estan recogidas en el anuario Proceedings of the Inter- ware se puede encontrar un tratarniento general del diseiio del
national Workshop on Sofmare Architecture, patrocinado por software en discusibn con el disefio arquitectdnico y el disefio
la ACM y otras organizaciones de computadoras y en el Pro- de datos. Los libros de Pfleeger (Sofnvare Engineering: Theory
ceedings of the International Conference on Software Engi- and Practice, Prentice may, 1998) y Sommerville (Sofmare
neering. Engineering, 5." ed., Addison-Wesley, 1995) son representati-
El modelado de datos es un prerrequisito para un buen vos de 10s libros que cubren en detalle el tema del diseiio.
diseiio de datos. Los libros de Teory (Database Modeling Se puede encontrar un tratarniento m k riguroso de la mate-
& Design, Academic Press, 1998), Schimdt (Data Modeling ria en Feijs (Formalization of Design Methods, Prentice may,
for Information Professionals, Prentice Hall, 1998), Bobak, 1993),Witt y colaboradores (SofnvareArchitecture and Design
(Data Modeling and Design for Today's Architectures, Principles, Thomson Publishing, 1994) y Budgen (Software
Artech House, 1997), Silverston, Graziano e Inmon (The Design, Addison-Wesley, 1994).
Dara Model Resource Book, Wiley, 1997), Date [DAT95], Se pueden encontrar representaciones completas de dise-
Reingruber y Gregory (The Data Modeling Handbook: A iios orientados a flujos de datos en Myers [MYE78], Yourdon
Best-Practice Approach to Building Quality Data Models, y Constantine [YOU79], Buhr (SystemDesign with Ada, Pren-
Wiley, 1994), Hay (Data Model Patterns: Conventions of tice may, 1984), y Page-Jones (The Practical Guide to Struc-
Thought, Dorset House, 1994) contienen una presentacidn tured Systems Design, segunda edicibn, Prentice may, 1988).
detallada de la notacidn de modelado de datos, heuristicas, Estos libros estan dedicados solamente a1 diseiio y propor-
y enfoques de diseiio de bases de datos. En 10s ultimos aiios cionan unas completas tutorias en el enfoque de flujo de datos.
el diseiio de almacenes de datos ha ido cobrando importan- En Internet estan disponibles una gran variedad de fuen-
cia. Los libros de Humphreys, Hawkins y Dy (Data Ware- tes de informacidn sobre diseiio de software y temas relacio-
housing: Architecture and Implementation, Prentice Hall, nados. Una lista actualizada de referencias web sobre
1999), Kimball [KIM981 e Inmon [INM95] cubren con gran conceptos y mCtodos de diseiio relevantes se puede encon-
detalle la materia. trar en: http://www.pressman5.com.
proteso d d diseiio.. ..262
reglas de oro ....... .260
A
.. . A . A ?I7
especificacion y titulos d e las ventanas,

y l a especificacion d e los elementos
principales y secundarios del menu. Lus
herramientas se utilizan para generar
- - --.-A :--- -- -*- .,.la:-- :--I&---.-< -\
diseiia identifica 10s objetos y acciones

d e la Interfaz y crea entonces un brma-
tCu&ler son 16s pasos? El disefio d e la
to de pantalla que lormara la base del interfaz d e usuario comienza con la
-
----Ex-
-
...---.-
prototipo d e i n t e r f a d e usuario.
mT". . .
. . - .,.a ..I. - .
identificacibn d e 10s requisites del usua-
w i n .-la l" *".a" .t Anl an+nrn,-. TT.." .
.a- -
e s quien disefia la interfaz d e usuario el desarrollo y mcdificacion iterativode
mediante la aplicacion del prmeso ite- prototip.
. .. . ..
- -
definidos del disefio. nes d e la interfaz. Esto e s 10 que forma - he h&ho c o d - e n b ? G u s u a -
~ P o qu6
r es impodante? Si el software la base para Ia creacion del formato d e rios controlan el prototipo mediante
e s dificil d e utilizar, si obIiga a cometer la p t a l l a que representa el disefio gra- p~ebX y la respuesta obtenida del con-
#---,---:A" *--1 A-1 --
,-..'- ...:!:-- -..- 1., -:-.:--
I N G E N I E R ~ ADEL SOFTWARE. U N E N F O Q U E PRACTICO
Theo Mantel [MAN971 en su libro crea tres aeglas de interactuar a travCs de las 6rdenes del teclado, con el
oron para el disefio de la interfaz: movimiento del raton, con un lipiz digitalizador, medlante
1. Dar el control a1 usuario 6rdenes para el reconocimiento de voz. Sin embargo, no
toda accion responde a todo mecanismo de interaccion.
2. Reducir la carga de memoria del usuario Considere por ejemplo, la dificultad de utilizar 6rdenes
3. Construir una interfaz consecuente del teclado (o entrada de voz) para dibujar una forma
Estas reglas de oro forman en realidad la base para compleja.
10s principios del disefio de la interfaz de usuario que Permitir que la interaccidn del usuario se pueda
servirin de guia para esta actividad de disefio de soft- interrumpir y deshacer. Cuando un usuario se ve
ware tan importante. involucrado en una secuencia de acciones, deberi poder
interrumpir la secuencia para hacer cualquier otra cosa
15.1.1. Dar el control a1 usuario (sin perder el trabajo que se hubiera hecho anteriormente).
El usuario deberi tambikn tener la posibilidad de
Durante la sesion de recopilacion de 10s requisitos para
c<deshacer>> cualquier accion.
un nuevo sistema de informaci6n, un usuario clave fue
preguntado a cerca de 10s atributos de la interfaz grafi- Aligerar la interaccidn a medida que avanza el nivel
ca orientada a ventanas. de conocimiento y permitir personalizar la interaccidn.
El usuario respondi6 solemnemente, <<Loque me gus- El usuario a menudo se encuentra haciendo la misma
taria realmente es un sistema que lea mi mente. Que secuencia de interacciones de manera repetida. Merece
conozca lo que quiero hacer antes de necesitarlo y que la pena sefialar un mecanismo de <<macros>> que
me facilite hacerlo. Eso es todo. Simplemente eso.>> posibilite a1 usuario personalizar la interfaz y asi facilitar
Mi primera reaccion fue mover la cabeza y sonreir, la interaccion.
y hacer una pausa por unos instantes. No habia nada
malo en la solicitud del usuario. Lo que queria era que
un sistema reaccionara ante sus necesidades y que le
ayudara a hacer las cosas. Queria controlar la compu-
tadora, y no dejar que la computadora le controlara.
La mayor parte de las restricciones y limitaciones
impuestas por el diseiiador se han pensado para sim-
plificar el mod0 de interaccion. Pero, ipara quienes? En
muchos casos es posible que el disefiador introduzca Ocultar a1 usuario ocasional 10s entresijos te'cnicos.
limitaciones y restricciones para simplificar la imple- La interfaz de usuario deberi introducir a1 usuario en el
mentacion de la interfaz. Y el resultado puede ser una mundo virtual de la aplicacion. El usuario no tiene que
interfaz ficil de construir, per0 frustrante de utilizar. conocer el sistema operativo, las funciones de gestion
Mandel [MAN971 define una serie de principios de de archivos, o cualquier otro secret0 de la tecnologia
diseiio que permiten dar control a1 usuario: inforrnatica. Esencialmente, la interfaz no debera
Definir 10s modos de interaccidn de manera que no requerir nunca que el usuario interactue a un nivel
obligue a que el usuario realice acciones innecesarias <<interno>> de la miquina (por ejemplo, el usuario no
y no deseadas. Un mod0 de interaccion es el estado tendri que teclear nunca las 6rdenes del sistema
actual de la interfaz. Por ejemplo, si en el procesador operativo desde dentro del software de aplicacion).
de textos se selecciona el corrector ortogr$ico, el Diseiiar la interaccibn directa con 10s objetos que
software pasa a mod0 corrector ortogrifico. No hay aparecen en la pantalla. El usuario tiene un sentimiento
ninguna razon por la que obligar a que el usuario de control cuando manipula 10s objetos necesarios para
permanezca en este mod0 si el usuario desea continuar llevar a cab0 una tarea de forma similar a lo que ocurriria
editando una parte pequeiia de texto. El usuario deberi si el objeto fuera algo fisico. Como ejemplo de
tener la posibilidad de entrar y salir de este mod0 sin manipulaci6n directa puede ser una interfaz de aplicacion
mucho o ningun esfuerzo. que perrnita a1 usuario ccalargm un objeto (cambiar su
tamaiio).
~Comose diseiian interfaces
que den el control al usuario? 15.1.2. Reducir la carga de memoria del usuario
Cuanto mis tenga que recordar un usuario, mas propen-
Tener en consideraci6n una interaccibnflexible. Dado sa a errores sera su interaccion con el sistema. Esta es la
que diferentes usuarios tienen preferencias de interaccion razon por la que una interfaz de usuario bien disefiada no
diferentes, se deberh proporcionar diferentes selecciones. pondri a prueba la memoria del usuario. Siempre que sea
Por ejemplo, un software que pueda permitir a1 usuario posible, el sistema debera <<recordan> la informacion per-
CAPfTULO 15 DISENO DE LA INTERFAZ DE USUARIO
tinente y ayudar a que el usuario recuerde mediante un

escenario de interaccirin. Mandel [MAN971 define 10s
principios de disefio que hacen posible que una interfaz
reduzca la carga de memoria del usuario:
Reducir la demanda de memoria a corto plazo.
Cuando 10s usuarios se ven involucrados en tareas
complejas, exigir una memoria a corto plazo puede ser
significativo. La interfaz se deberh disefiar para reducir
10s requisitos y recordar acciones y resultados anteriores. disefio esthndar que se mantiene en todas las presen-
Esto se puede llevar a cab0 mediante claves visuales taciones de pantallas; (2) que todos 10s mecanismos
que posibiliten a1 usuario reconocer acciones anteriores de entrada se limiten a un conjunto limitado y que se
sin tenerlas que recordar. utilicen consecuentemente por toda la aplicaci6n, y
que (3) 10s mecanismos para ir de tarea a tarea se
Establecer valorespor defecto htiles. El conjunto inicial
hayan definido e implementado consecuentemente.
de valores por defecto tendrh que ser de utilidad para a1
Mandel [MAN971 define un conjunto de principios
usuario, pero un usuario tarnbiCn debera tener la capacidad
de disefio que ayudar a construir una interfaz conse-
de especificar sus propias preferencias. Sin embargo,
cuente:
deberh disponer de una opci6n de ccreinicializaci6n>> que
le permita volver a definir 10s valores por defecto. Permitir que el usuario realice una tarea en el
contexto adecuado. Muchas interfaces implementan
Definir las deficiencias que sean intuitivas. Cuando
capas complejas de interacciones con docenas de
para disefiar un sistema se utiliza la mnem6nica (por
imhgenes de pantallas. Es importante proporcionar
ejemplo, alt-P para invocar la funci6n de imprimir),
indicadores (por ejemplo, titulos de ventanas, iconos
Csta deberh ir unida a una acci6n que sea facil de
grhficos, codificaciones en colores consecuentes) que
recordar (por ejemplo, la primera letra de la tarea que
posibiliten a1 usuario conocer el contexto del trabajo
se invoca).
que esth llevando a cabo. Ademhs, el usuario deberh
ser capaz de determinar de d6nde procede y quC
~ C O se~ pueden
O diseiiar alternativas existen para la transici6n a una tarea
interfaces que reduztan nueva.
la carga de memoria del usuario?
El formato visual de la inte$az se deberci basar en una ~ C O se~ pueden

O tonstruir
metcifora del mundo real. Por ejemplo, en un sistema de interfaces tonsetuentes?
pago de facturas se deberi utilizar la methfora de la
chequera y el registro del cheque para conducir a1 usuario Mantener la consistencia en toda la familia de
por el proceso del pago de facturas. Esto hace posible que aplicaciones. Un conjunto de aplicaciones (o productos)
el usuario comprenda bien las pistas y que no tenga que deberh implementar las mismas reglas de disefio para
memorizar una secuencia secreta de interacciones.
mantener la consistencia en toda la interacci6n.
Desglosar la informacidn de forma progresiva. La Los modelos interactivos anteriores han esperanzado
interfaz deberh organizarse de forma jerkquica. Esto es, a1 usuario, no realicemos cambios a menos que exista
en cualquier informaci6n sobre una tarea se deberh alguna razdn convincente para hacerlo. Una vez que
presentar un objeto o algun comportamiento en primer una secuencia interactiva se ha convertido en un estitndar
lugar a un nivel alto de abstracci6n. Y solo despuCs de hecho (por ejemplo, la utilizaci6n de alt-S para grabar
que el usuario indique su preferencia realizando la un archivo), el usuario espera utilizar esta combinaci6n
selecci6n mediante el rat611 se presentarhn mhs detalles. en todas las aplicaciones que se encuentre. Un cambio
Un ejemplo muy comun en muchas aplicaciones de podria originar confusi6n (por ejemplo, la utilizaci6n
procesamiento de texto es la funci6n de subrayado dado de alt-S para invocar la funci6n cambiar de tamafio).
que es una funci6n que pertenece a1 menu de estilo de Los principios del disefio de interfaces tratados aqui
texto. Sin embargo no se muestran todas las posibilidades y en sesiones anteriores proporcionan una guia basica
de subrayado. El usuario es el que debe seleccionar el para la ingenieria del software. En la siguiente secci6n
subrayado, y asi se presentah entonces las opciones de examinaremos el proceso de disefio de la interfaz.
esta funci6n (por ejemplo, subrayado sencillo, subrayado
doble, subrayado de guiones).
15.1.3. Construcci6n de una interfaz consistente

La interfaz deberh adquirir y presentar la informaci6n
de forma consecuente. Esto implica (1) que toda la lineos Generoles paro el diseiio
informaci6n visual estC organizada de acuerdo con el de lo interfaces.
El proceso global para el disefio de la interfaz de usua- usuarios esporadicos y con conocimientos: poseen
rio comienza con la creaci6n de diferentes modelos de un conocimiento semintico razonable, per0 una
funcionamiento del sistema (la percepci6n desde fue- retenci6n baja de la informaci6n necesaria para uti-
ra). Es entonces cuando se determinan las tareas orien- lizar la interfaz;
tadas a1 hombre y a la miquina que se requieren para usuarios frecuentes y con conocimientos: poseen
lograr el funcionamiento del sistema; se tienen en con- el conocimiento sintictico y semintico suficiente
sideraci6n 10s temas de disefio que se aplican a todos como para llegar a1 ccsindrome del usuario avanzado>>,
10s disefios de interfaces; se utilizan herramientas para esto es, individuos que buscan intermpciones breves
generar prototipos y por 6ltimo para implementar el y modos abreviados de interacci6n.
modelo de disefio, y evaluar la calidad del resultado.
15.2.1. Modelos de diseiio de la interfaz

Cuando se va a disefiar la interfaz de usuario entran en
juego cuatro modelos diferentes. El ingeniero del soft-
ware crea un modelo de diserio; cualquier otro ingenie-
ro (o el mismo ingeniero del software) establece un
modelo de usuario, el usuario final desarrolla una ima- La percepci6n del sistema (el modelo de usuario) es
gen mental que se suele llamar modelo de usuario o per- la imagen del sistema que el usuario final tiene en su
cepcibn del usuario, y 10s que implementan el sistema mente. Por ejemplo, si se preguntara a un usuario de un
crean una imagen de sistema [RUB88]. Desgraciada- procesador de texto en particular que describiera su for-
mente, todos y cada uno de 10s modelos pueden diferir ma de manejar el programa, la respuesta vendna guia-
significativamente. El papel del disefiador de interfaz da por la percepci6n del sistema. La precisi6n de la
es reconciliar estas diferencias y derivar una represen- descripci6n dependera del perfil del usuario (por ejem-
tacion consecuente de la interfaz. plo, 10s principiantes harian lo posible por responder
con una respuesta muy elemental) y de la familiaridad
global con el software del dominio de la aplicacion. Un
usuario que comprenda por completo 10s procesadores
de texto, aunque puede que haya trabajado solo una vez
Una fuente excelente de directrices de diseiio y referencios con ese procesador especifico, es posible que propor-
se puede encontror en www.ibm.com/ibm/eosy/ cione de verdad una descripci6n mis completa de su
funcionamiento que el principiante que haya pasado
Un modelo de disefio de un sistema completo incor- unas cuantas semanas intentando aprender el funciona-
pora las representaciones del software en funci6n de 10s miento del sistema.
datos, arquitectura, interfaz y procedimiento. La espe- La imagen del sistema es una combinaci6n de facha-
cificaci6n de 10s requisitos puede que establezca cier- da externa del sistema basado en computadora (la apa-
tas limitaciones que ayudarin a definir a1 usuario del riencia del sistema) y la informaci6n de soporte (libros,
sistema, per0 el disefio de la interfaz suele ser un 6nico manuales, cintas de video, archivos de ayuda) todo lo
tema secundario de modelo de interfaz'. cual ayuda a describir la sintaxis y la semhtica del sis-
El modelo de usuario representa el perfil de 10s usua- tema. Cuando la imagen y la percepci6n del sistema
rios finales del sistema. Para construir una interfaz de coinciden, 10s usuarios generalmente se sienten a gus-
usuario efectiva, cctodo diseiio deberi comenzar por to con el software y con su funcionarniento. Para llevar
conocer 10s usuarios destino, asi como 10s perfiles de a cab0 esta ccmezclan de modelos, el modelo de disefio
edad, sexo, habilidades fisicas, educacibn, anteceden- deberi desarrollarse con el fin de acoplar la informa-
tes culturales o Ctnicos, motivacibn, objetivos y perso- ci6n del modelo de usuario, y la imagen del sistema
nalidadn [SCH87] Ademis de esto se pueden establecer deberi reflejar de forma precisa la informaci6n sintic-
las siguientes categon'as de usuarios: tica y sembtica de la interfaz.
principiantes: en general no tienen conocimientos Los modelos descritos anteriormente en esta secci6n
sintcictico? ni conocimientos semcinticod de la uti- son ccabstracciones de lo que el usuario esti haciendo o
lizaci6n de la aplicaci6n o del sistema; piensa que esti haciendo o de lo que cualquier otra per-
' Por supuesto esto no es como deberia ser. Para sistemas interactivos, El conocimiento semantic0 se reliere al sentido subsiguiente de apli-
el diseiio de la interfaz es tan importante como el disefio de 10s datos, cacion -una comprension de la realization de todas las funciones,
arquitectura o el de componentes. del significado de entrada y salida, de las metas y objetivos del sis-
En este context0 el conocimiento sintactico se refiere a la mecanica tema-.
de interaccion que se requiere para utilizar la interfaz de forma eficaz.
CAP~TULO
15 DISENO D E L A INTERFAZ D E U S U A R I O
sona piensa que deberia estar haciendo cuando utiliza Se registran el nivel de conocimiento, la comprensi6n
un sistema interactive,, [MON84]. Esencialmente, estos del negocio y la receptividad general del nuevo siste-
modelos permiten que el diseiiador de la interfaz satis- ma, y se definen diferentes categorias de usuarios. En
faga un elemento clave del principio mas importante cada categoria se lleva a cab0 la elicitaci6n de 10s requi-
del disefio de la interfaz de usuario: <<quienconoce a1 sitos. Esencialmente, el ingeniero del software intenta
usuario. conoce las tareas,,. comprender la percepci6n del sistema (Secci6n 15.2.1)
para cada clase de usuario.
Cuondo la imogen del sistemo y lo percepcion del sistemo

coinciden, el usuario puede utilizor lo oplicocion de formo
efectivo.
15.2.2. El proceso de diseiio de la interfaz Una vez definidos 10s requisitos generales, se lleva 'a
de usuario cab0 un analisis mas detallado de las tareas. Se identifi-
can, describen y elaboran las tareas que lleva a cab0 el
El proceso de disefio de las interfaces de usuario es ite- usuario para conseguir 10s objetivos (por encima de la can-
rativo y se puede representar mediante un modelo espi- tidad de pasos iterativos a travCs de la espiral). El anali-
ral similar al abordado en el Capitulo 2. En la Figura sis de tareas se estudia detalladamenteen la Seccion 15.3.
15.1 se puede observar que el proceso de disefio de la El analisis del entorno de usuario se centra en el
interfaz de usuario acompafia cuatro actividades distin- entorno del trabajo fisico. Entre las preguntas que se
tas de marco de trabajo [MAN97]: formulan se encuentran las siguientes:
1. Analisis y modelado de usuarios, tareas y entornos. iD6nde se ubicara fisicamente la interfaz?
2. Disefio de la interfaz iD6nde se situara el usuario? ~Llevaraa cab0 tareas
3. Implementaci6n de la interfaz no relacionadas con el interfaz?
4. Validaci6n de la interfaz iSe adapta bien el hardware a las limitaciones de luz,
Validacion
de la interfaz
4- Analisis de usuarios,
tareas v entornos
espacio o ruido?
Esta recopilaci6n de informaci6n que forma pate de
la actividad de anhlisis se utiliza para crear un modelo
de analisis para la interfaz. Mediante esta base de mode-
lo se comienza la actividad de disefio.
iCud es el obietivo
del diseiio de la interfaz
de usuario?
El objetivo del disefio de la interfaz es definir un con-

junto de objetos y acciones de interfaz (y sus represen-
taciones en la pantalla) que posibiliten a1 usuario llevar
a cab0 todas las tareas definidas de forma que cumplan
todos 10s objetivos de usabilidad definidos por el siste-
ma. El disefio de la interfaz se aborda mhs detallada-
mente en la Secci6n 15.4
La actividad de implementaci6n comienza normal-
FIGURA 15.1. El proceso de diseiio de la interfaz de usuario. mente con la creaci6n de un prototipo que permita eva-
l u x 10s escenarios de utilizaci6n. A medida que avanza
La espiral que se muestra en la Figura 15.1 implica el proceso de disefio iterativo, y para completar la cons-
que cada una de las tareas anteriores aparecerhn mas de trucci6n de la interfaz, se puede utilizar un kit de herra-
una vez, en donde a medida que se avanza por la espi- mientas de usuario (Secci6n 153.
ral se representari la elaboraci6n adicional de 10s requi- La validaci6n se centra en: (I) la habilidad de la inter-
sitos y el disefio resultante. En la mayoria de 10s casos, faz para implementar correctamente todas la tareas del
la actividad de implementaci6n implica la generaci6n usuario, para acoplar todas las variaciones de tareas, y
de prototipos -la 6nica forma prictica para validar lo para archivar todos 10s requisitos generales del usuario;
que se ha disefiad-. (2) el grado de facilidad de utilizaci6n de la interfaz y
La actividad de an6lisis inicial se concentra en el per- de aprendizaje, y (3) la aceptaci6n de la interfaz por par-
fil de 10s usuarios que van a interactuar con el sistema. te del usuario como una herramienta 6til en su trabajo.
En el Capitulo 13 se estudi6 la elaboraci6n paso a paso de una serie de actividades importantes: disefio del mobi-
(llamada tambikn refinamiento paso a paso y descompo- liario, selecci6n de tejidos y materiales, selecci6n de deco-
sici6n funcional) como mecanismo para refinar las tareas rados en paredes y ventanas, presentaci6n (a1 cliente),
de procesamiento necesarias para que el software lleve a costes y compras. Todas y cada una de estas tareas pue-
cab0 la funcion deseada. Mis adelante en este mismo libro den elaborarse en otras subtareas. Por ejemplo, el disefio
tendremos en consideraci6n el andisis orientado a obje- del mobiliario puede refinarse en las tareas siguientes: (1)
tos como enfoque de modelado para 10s sistemas basados dibujar el plano de la casa con las dimensiones de las habi-
en computadora. El andisis de tareas para el disefio de la taciones; (2) ubicar ventanas y puertas en 10s lugares ade-
interfaz o bien utiliza un enfoque elaborativo o bien orien- cuados; (3) utilizar plantillas de muebles para dibujar en
tad0 a objetos, per0 aplicando este enfoque a las activi- el plano un esbozo del mobiliario a escala; (3) mover el
dades humanas. esbozo del mobiliario para mejorar su colocacidn; (5) eti-
El andisis de tareas se puede aplicar de dos maneras. quetar el esbozo del mobiliario; (6) dibujar las dimensio-
Como ya hemos destacado anteriormente, un sistema nes para mostrar la colocaci6n; (7) realizar un dibujo en
interactivo basado en computadora se suele utilizar para perspectiva para el cliente. Para las otras tareas impor-
reemplazar una actividad manual o semi-manual. Para tantes del enfoque se puede utilizar un mktodo similar.
comprender las tareas que se han de llevar a cab0 para
lograr el objetivo de la actividad, un ingeniero4deberi
entender las tareas que realizan 10s hombres actualmente
(cuando se utiliza un enfoque manual) y hacer corres-
10s toreas humonos se definen y se closifican como porte
ponder esta tareas con un conjunto de tareas similar (aun-
del onolisis de 10s toreos. Poro refinor los toreos se utilizo
que no necesariamente idknticas) que se implementan en un proceso de eloborocion. De formo alternotivo,
el context0 de la interfaz de usuario. De forma altemati- se identificon y se refinon 10s obietos y 10s acciones.
va, el ingeniero puede estudiar la especificaci6n existen-
te para la soluci6n basada en computadora y extraer un Las subtareas (1)-(7) pueden recibir mis refinamien-
conjunto de tareas que se ajusten al modelo de usuario, a1 to. Las subtareas (1)-(6) se llevarhn a cab0 mediante la
modelo de disefio y a la percepci6n del sistema. manipulaci6n de informaci6n y mediante la realizaci6n
Independientementedel enfoque global utilizado para de acciones dentro de la interfaz de usuario. Por otro lado,
el an6lisis de tareas, el ingeniero deberi en primer lugar la subtarea (7) se podri llevar a cab0 automiticamente en
definirlas y clasificarlas. Ya se ha descrito anteriormente el software y dar5 como resultado muy poca interacci6n
que el enfoque es una elaboraci6n paso a paso. Por ejem- directa con el usuario. El modelo de disefio de la interfaz
plo, supongamos que una compaiiia pequefia quiere cons- deber6 adaptarse a cada una de estas tareas de forma con-
truir un sistema de disefio asistido por computadora secuente con el modelo del usuario (el perfil de un dise-
explicitamente para disefiadores de interiores. A1 obser- fiador cctipico>>de interiores) y con la percepci6n del
var a un disefiador de interiores en su trabajo, el ingenie- sistema (lo que el disefiador de interiores espera de un sis-
ro se da cuenta y notifica que el disefio interior se compone tema automatizado).
Una vez finalizado el anilisis de tareas, quedan defini- 2. Hacer corresponder cada objetivo/intenci6n con una
das detalladamente todas (u objetos y acciones) las que secuencia de acciones especificas
requiere el usuario final y comienza la actividad del dise- 3. Especificar la secuencia de acciones de tareas y sub-
fio de la interfaz. Mediante el enfoque que se muestra a tareas, tambikn llamado escenario del usuario, de la
continuacidn se podrin llevar a cab0 10s primeros pasos manera en que se ejecutarh a nivel de la interfaz.
del disefio de la interfaz [NOR86]: 4. Indicar el estado del sistema, esto es, el aspect0 que
1. Establecer 10s objetivos5e intenciones para cada tarea. tiene la interfaz cuando se esti llevando a cabo el
escenario del usuario.
~Cualesson 10s pasos Definir 10s mecanismo de control, esto es, 10s obje-
que hay que seguir para llevar tos y acciones disponibles para que el usuario altere
a cabo el diseiio de la interfaz? el estado del sistema.
En muchos casos las actividades descritas en esta seccion ion Ile- Entre 10s objetivos se pueden incluir la consideracion de la utilidad de
vadas a cabo por un ingeniero del software. Esperemos que el indi- las tareas, la efectividad al llevar a cabo el objetivo comercial primor-
vjduo tenga experiencia en ingenieria humana y en el diseRo de la dial, el grado de rapidez de aprendizaje de las tareas y el grado de satis-
interfaz de usuario. faccion de los usuarios con la irnplementacion final de la tarea.
CAPfTULO 15 DISENO DE LA INTERFAZ DE USUARIO
Mostrar la forma en que 10s mecanismos de control pantalla. A1 igual que otras actividades de disefio de la
afectan a1 estado del sistema. interfaz, el formato de pantalla es un proceso interactivo
Indicar la forma en que el usuario interpreta el estado en donde se lleva a cab0 el disefio grhfico y la colocaci6n
del sistema a partir de la informaci6n proporcionada de 10s iconos, la definici6n del texto descriptivo en pan-
gracias a la interfaz. talla, la especificaci6n y titulos para las ventanas, y la
Aunque el disefiador de la interfaz se guia por las definici6n de 10s elementos del menu principales y secun-
reglas de oro abordadas en la Secci6n 15.1,debeki con- darios. Si una metfifora con el mundo real es adecuada
siderar la forma en que se va a implementar la interfaz, para la aplicaci61-1,queda especificada en ese momento y
el entomo (por ejemplo, tecnologia de pantalla, sistema el formato se organiza para complementar esa metfifora.
operativo, herramientas de desarrollo) que se va a uti- Para mostrar la breve ilustracion de 10s pasos de dise-
lizar y otros elementos de la aplicacion que ccse encuen- fio descritos anteriormente, tomemos en consideration
tren por detras>>de la interfaz. un escenario de usuario para la version avanzada del
sistema HogarSeguro (descrito en capitulos anteriores).
En la versi6n avanzada, se puede acceder a HogarSe-
15.4.1. Definicidn de objetos y acciones guro mediante m6dem o Internet. Una aplicaci6n para
de la interfaz PC permite que un propietario compruebe el estado de
Un paso importante en el disefio de la interfaz es la defi- la casa desde una localizaci6n remota, reinicializar la
nici6n de 10s objetos y acciones que se van a aplicar. configuraci6n HogarSeguro, activar y desactivar el sis-
Para llevar a cab0 esta definici611, el escenario del usua- tema, (empleando una opci6n de video con un coste
rio se analiza sintficticamente de manera muy similar a extra6), y supervisar visualmente las habitaciones den-
como se analizaban 13s narrativas de procesamiento del tro de la casa. A continuaci61-1,se muestra un escenario
Capitulo 12. Esto es, se escribe la descripci6n del esce- preliminar de usuario para la interfaz:
nario de un usuario. Los sustantivos (objetos) y 10s ver-
bos (acciones) se aislan para crear una lista de objetos El escenoim descrito oqul es sirnilor o !us cosos
y de acciones. de estudio descritos en el CopCtulo 1 1.
En lo Seccidn 12.6.2 se puede encontror un estudio Escenario. El propietario de la casa desea acceder a1 sis-
cornpleto del on6lisis sernbntico grarnoticol. tema HogarSeguro instalado en su casa. Mediante el siste-
ma operativo de un PC remoto (por ejemplo, un portatil que
el propietario se lleve a1 trabajo o de viaje), el propietario
Una vez que se han definido y elaborado iterativa- determina el estado del sistema de alarma, arma o desarma
mente tanto 10s objetos como las acciones, se estable- el sistema, reconfigura las zonas de seguridad y obsema las
cen categorfas por tipos. Los objetos se identifican como diferentes habitaciones de la casa mediante la preinstalaci6n
objetos origen, destino y de aplicaci6n. Un objeto ori- de una camara de video.
gen (por ejemplo, un icono de informes) se arrastra y se Para acceder a HogarSeguro desde una localizaci6n remo-
coloca sobre otro objeto destino (por ejemplo, un icono ta, el propietario proporciona un identificador y una contrase-
de impresora). La implication de esta acci6n es crear iia. Con esto se definen 10s niveles de acceso (por ejemplo,
una copia impresa de un informe. Un objeto de aplica- todos 10s usuarios puede que no tengan la capacidad de recon-
figurar el sistema) y se proporciona seguridad. Una vez vali-
cibn representa 10s datos especificos de la aplicaci6n dados, el usuario (con 10s privilegios para el acceso) comprueba
que no se manipulan directamente como parte de la inte- el estado del sistema, y cambia el estado armando y desarmando
racci6n de la pantalla. Por ejemplo, una lista de correo HogarSeguro. El usuario reconfigura el sistema visualizando
postal se utiliza para almacenar 10s nombres que se uti- todas las zonas configuradas actualmente,modificando las zonas
lizarfin para un correo postal. Esta lista se puede orde- cuando se requiera. El usuario observa el interior de la casa
nar, fusionar o purgar (acciones basadas en men6) per0 mediante c h a r a s de video estratkgicamente ubicadas. El usua-
no puede utilizar las c h a r a s para recorrer todo el interior y
no se puede arrastrar y colocar mediante la interacci6n ampliarlo para ofrecer diferentes visiones del interior de la casa.
del usuario.
Tareas del propietario:
~ Q u es
e el formato
acceder a1 sistema HogarSeguro;
de pantalla y como se aplica?
introducir un ID y una contraseiia para permitir un acceso
remoto;
Una vez que el disefiador queda satisfecho con la defi-
nici6n de todos 10s objetos y acciones importantes (para cornprobar el estado del sistema;
una iteraci6n de disefio), se lleva a cab0 el formato de activar o desactivar el sistema HogarSeguro;
La opcion de video posibilita a1 usuario colocar una camara

de video en lugares clave por la casa y examinar la salida desde una
localization remota. iEl Gran Hermano?
vi.urtrlizur-el plano de la casa y las localimciones de los sen- seleccionar una visi6n desde otra cAmara, el usuario
sores; simplemente arrastra y coloca el icono de localization
vi.malizar zonas en el plano de la casa: de camara dentro del icono camara del ingulo supe-
c,arnhiu~-zonas en el plano de la casa; rior izquierdo de la pantalla.
visuulizur-las locali7aciones de las dmaras de video en el Esta muestra de esbozo de formato tendria que ir
plmo de la cam; complementado mediante una ampliacion de todos 10s
la climara de video para tener visi6n;
.selcc~ciorror. elementos del menu dentro de la barra de menli, indi-
ohser-~wr-las imligenes de video (cuatro encuadres por cando las acciones disponibles para el (estado) n~ockode
segundo); s~1pervisi6ndel video. Durante el disefio de la interfaz
IPCOI.IW y mlpliur la.habi~acionescon la dmara de video. se deberia crear un conjunto completo de esbozos para
todas y cada una de las tareas del propietario descritas
Los objetos (negrita) y las acciones (cursiva) se en el escenario del usuario.
extraen de la lisla de tareas del propietario descritas
anteriormente. La mayoria de 10s objetos anteriores son
objetos de aplicaciones. Sin cmbargo la localizaci6n de 15.4.2. Problemas del disefio
la cimara de video (un objeto origen) se arrastra y se A medida que la interfaz de usuario va evolucionando
coloca sobre la chmara de video (un objeto destino) para casi siempre afloran cuatro temas comunes de disefio:
crear una imagen de video (una ventana con la presen- el tiempo de respuesta del sistema, 10s servicios de ayu-
taci6n de un video). da a1 usuario, la manipulaci6n de infornmi6n de erro-
Para la supervisibn del video se crea un esbozo del res y el etiquetado de brdenes. Desgraciadamente,
formato de pantalla (Fig. 15.2). Para invocar la imagen muchos diseiiadores no abordan estos temas dentro del
de video, se selecciona Ln icono de localizaci6n de proceso de diseiio has& que es relativamente tarde (algu-
camara de video C, ubicado en el plano de la casa que nas veces no se siente la aparici6n de un error hasta que
se visualiza en la ventana de supervision. En este caso, se dispone del prototipo operativo). El resultado suele
la localizaci6n de una cimara en la sala de estar (SE), ser una iteraci6n innecesaria, denioras de proyecto y
se arrastra y se coloca sobre el icono de video de cdma- frustraci6n del usuario. Es infinitamente mejor estable-
ra en la pane superior izquierda de la pantalla. Enton- cer el tema de diseiio que se vaya a tener en cuenta a1
ces, mediante la visualizaci6n del recorrido realizado iniciar el diseiio del software, es decir cuando 10s cam-
por el video desde la c6mara localizada en la sala de bios son FAciles y 10s costes m6s reducidos.
cstar (SE), apaece la ventana de imagen de video. Las Para muchas aplicaciones interactivas el tiempo de
diapositivas de control del recorrido por las habitacio- respuesta del sistema es el principal motivo de queja.
nes y de las ampliaciones se utilizan para controlar la En general, el tiempo de respuesta del sistema se mide
amplitud y la direcci6n de la imagen de video. Para desde el punto de vista que el usuario realiza la acci6n
, Acceso Configurar Estado dd 4stema Ver Supervisidn
?I=.
Conexrdn
S Sensores puertahentana
M detector de movimiento
fmuestra de bar)
C localizacidn de cdmare de video
FIGURA 15.2. Formato preliminar de pantalla.

de control (por ejemplo, pulsar la tecla intro o pulsar el iSe necesitarh disponer de todas las funciones del
boton del rat6n) hasta que el software responde con la sistema en cualquier momento durante la interaccion
salida o acci6n deseada. del sistema? Opciones: ayuda solo para un subcon-
El tiempo de respuesta del sistema tiene dos carac- junto de todas las funciones y acciones; ayuda para
teristicas importantes: la duraci6n y la variabilidad. Si todas las funciones.
la duracibn de la respuesta del sistema es demasiado iDe quC forma solicitarh ayuda el usuario? Opcio-
larga, es inevitable obtener como resultado la frustra- nes: un menu de ayuda; una tecla de funci6n espe-
ci6n y el estrCs del usuario. Sin embargo, si la interfaz cial; una orden de AYUDA.
va marcando el ritmo del usuario una duraci6n breve
iC6mo se representarh la ayuda? Opciones: una ven-
del tiempo de respuesta puede ser tambiCn perjudicial.
tana separada; una referencia a un documento impreso
Un tiempo de respuesta rhpido puede obligar a que el
(no es lo ideal); una sugerencia de una o dos lineas
usuario se precipite y cometa errores.
que surge en una localizacidn fija en la pantalla.
iC6m0 regresarh el usuario a la interaccion normal?
Opciones: un boton de retomo visualizado en la pan-
talla; una tecla de funcion o una secuencia de control.
Si no se puede evitor uno respuesto variable, oseghese
de proporcionor olguno indicocion visual del progwso ~ C Ose~estructurarh
O la informaci6n sobre la panta-
porn que el usuorio sepo lo que esta ocurriendo. lla? Opciones: una estructura ccplana>> donde el acceso
a la informacion se realiia mediante una contraseiia;
La variabilidad se refiere a la desviacion del tiempo una jerarquia estratificada de informaci6n que va pro-
de respuesta promedio, y en muchos aspectos es la carac- porcionando rnhs datos a medida que el usuario va
teristica rnhs importante del tiempo de respuesta. Una entrando por la estructura; la utilizaci6n de hipertexto.
variabilidad baja posibilita a1 usuario establecer un rit-
mo de interaccion, aunque el tiempo de respuesta sea Cuando ha salido algo mal, 10s mensajes de error y
las sugerencias son ccmalas noticiaw para 10s usuarios
relativamente largo. Por ejemplo, es preferible obtener
una segunda respuesta de una orden a una respuesta que de sistemas interactivos. En el peor de 10s casos, estos
varie de 0,l a 2,5 segundos. El usuario siempre estarh mensajes imparten informacih sin utilizar o engaiiosa
y sirven solo para incrementar la frustracion del usua-
desconcertado y pregunthndose si ha ocunido algo ccdife-
rio. Existen muy pocos usuarios que puedan decir que
rente>>detrhs de la escena.
Casi todos 10s usuarios de un sistema interactivo basa- no se han encontrado con un error del tipo:
do en computadora requieren ayuda, ahora y siempre. Los FALL0 GRAVE DEL SISTEMA - - 14A
dos tipos de funciones de ayuda m b comunes son: inte-
En algun lugar debe existir una explicaci6n del error
gradas y complementarias (afiadibles). [RUB88]. Se dise-
14A, o sino ipor quC habrh incluido el diseiiador esta
iia una funcibn de ayuda integrada dentro del mismo
identificacion? A pesar de esto, el mensaje de error no
software desde el principio. Suele ser sensible a1 contex-
proporciona una indicacion verdadera de lo que va ma1
to, lo que posibilita a1 usuario seleccionarentre 10s temas
o de donde mirar para obtener rnhs informacion. Un
que Sean relevantes para las acciones que estC llevando a
mensaje de error como el que se ha presentado ante-
cab0 en ese momento. Obviamente esto reduce el tiempo
riormente no hace nada por aliviar la ansiedad del usua-
que requiere para obtener ayuda, e incrementa su <<fami-
rio o por ayudar a solucionar el problema.
liaridadn con la interfaz. Unafincibn de ayuda comple-
En general, todos 10s mensajes de error o sugeren-
mentaria se aiiade a1 software una vez construido el
cias de un sistema interactivo deberan tener las carac-
sistema. En muchos aspectos es muy similar a un manual
teristicas siguientes:
de usuario en linea con una capacidad limitada de con-
sulta. Es posible que el usuario tenga que buscar en una El mensaje deberh describir el problema en una jerga
lista de miles de temas para encontrar la guia adecuada, que el usuario pueda entender.
entrando normalmente en las ayudas incorrectas y reci- El mensaje deberh proporcionar consejos construc-
biendo mucha informacion irrelevante. No hay ninguna tivos para recuperarse de un error.
duda de que es preferible el enfoque de funciones de ayu- El mensaje deberh indicar cualquier consecuencia
da integradas a1 enfoque de funciones complementarias. negativa del error (por ejemplo, 10s archivos de datos
posiblemente deteriorados) para que el usuario pueda
iCuales son 10s temas de diseiio comprobar y garantizar que no hay ninguno (y corre-
que deberan tenerse en cuenta girlos si existen).
en la construccion de las funciones
de ayuda?
Cuando se va a considerar un servicio de ayuda hay

Duplique el eherzo y 10spolobras 01 solucionor errores
una serie de temas de disefio que deberkn abordarse cuondo piense que necesito uno hncion de oyudo y
[RUB88]: de esto formo, es probable que consigo un buen resultodo.
CAP~TULO
15 DISENO D E L A INTERFAZ D E U S U A R I O
fio, se crea un prototipo de primer nivel. Este prototipo 1. La duraci6n y la complejidad de la especificaci6n
es evaluado por el usuario, que es quien proporcionara que se haya escrito del sistema y de su interfaz pro-
a1 disefiador 10s comentarios directos sobre la eficacia porcionan una indicaci6n de la cantidad de aprendi-
de la interfaz. Ademas, si se utilizan tCcnicas formales zaje que requieren 10s usuarios del sistema.
de evaluaci6n (por ejemplo, cuestionarios, hojas de eva- 2. La cantidad de tareas especificadas y la cantidad media
luacion), es posible que el disefiador extraiga informa- de acciones por tarea proporcionan una indicacion del
cion de estos datos (por ejemplo, el 80 por 100 de 10s tiempo y de la eficacia global del sistema.
usuarios no mostro afinidad con el mecanismo para gra-
bar archivos de datos). Las modificaciones que se rea- 3. La cantidad de acciones, tareas y estados de sistemas
k e n sobre el disefio se basarhn en la entrada del usuario indicados con el modelo de disefio indican la carga de
y entonces se creara el prototipo de segundo nivel. El memoria que tienen 10s usuarios del sistema.
ciclo de evaluaci6n continua hasta que ya no Sean nece- 4. El estilo de la interfaz, las funciones de ayuda y el
sarias mhs modificaciones del diseiio de la interfaz. protocolo de solucion de errores proporcionan una
indicacion general de la complejidad de la interfaz
y el grado de aceptaci6n por parte del usuario.
Una vez construido el primer prototipo, el disefiador
puede recopilar una diversidad de datos cualitativos y
cualificativos que ayudaran a evaluar la interfaz. Para
recopilar 10s datos cualitativos, se pueden distribuir cues-
tionarios a 10s usuarios del prototipo. Las preguntas pue-
den ser (1) del tipo de respuesta si/no; (2) respuesta
numCrica; (3) respuesta con escala de valoraci6n (sub-
jetiva), o (4) respuesta por porcentajes (subjetiva). A
El enfoque de generaci6n de prototipos es eficaz, continuacion se muestran unos ejemplos:
ahora bien jes posible evaluar la calidad de la interfaz 1. ~ E r a nclaros 10s iconos? En caso negativo, ~ Q u C
de usuario antes de construir un prototipo? Si 10s pro- iconos no eran claros?
blemas se pueden descubrir y solucionar rapidamente,
2. ~ E r a nfaciles de recordar y de invocar las acciones?
el numero de bucles en el ciclo de evaluacion se redu-
cira y el tiempo de desarrollo se acortara. Si se ha crea- 3. ~Cuantasacciones diferentes ha utilizado?
do un modelo de disefio de la interfaz, durante las 4. ~Resultaronfaciles de aprender las operaciones bisi-
primeras revisiones del disefio se podran aplicar una cas del sistema? (valoraci6n de 1 a 5)
serie de criterios [MOR8 11 de evaluacion: 5. En comparacion con otras interfaces que haya utili-
zado, ~ C Oevaluaria
~ O Csta?
entre el 1 % mejores, 10% mejores, 25% mejores, 50%
Disetio mejores, 50% inferiores.
preliminar
Construccion
de la interfaz
lnterfoz de usuorio
de la interfaz
Si se desea obtener datos cuantitativos, se puede lle-
var a cabo una forma de anfilisis para el estudlo del tiempo.
u Realization
de las
modificaciones
del disetio
de la interfaz
es estudiada
El usuario
eva 11'1a
la interfaz
Los usuarios son observados durante la interacci6n;y para
tener una guia durante la modlficacion de la interaccion
se recopilan y utilizan datos tales como: grupo de tareas
finalizadas correctamente por encima del periodo de
tiempo estandar; frecuencia de acciones; secuencia de
acciones; tiempo transcurrido <<mirando>> la pantalla;
numero y tipo de errores, y tiempo de solucion de erro-
res; tiempo necesario para utilizar la ayuda; y cantidad de
referencias de ayuda por periodo de tiempo estiindar.
Un estudio completo de 10s mCtodos de evaluacion de
esta finalizada
la interfaz de usuario queda fuera del Ambito de este libro.
FIGURA 15.3. El ciclo de evaluacion de disetio de la interfaz. Para mas informaci6n, vCase [LEA881 y [MAN97].
Se puede argumentar que la interfaz de usuario es el ele- Una vez que se han definido las tareas, 10s escena-
mento miis importante de un sistema o product0 basa- nos del usuario se crean y analizan para definir un con-
do en computadora. Si la interfaz tiene un disefio pobre, junto de objetos y acciones de la interfaz. Esto es lo que
la capacidad que tiene el usuario de aprovecharse de la proporciona la base para la creaci6n del formato de la
potencia de proceso de una aplicacion se puede dificul- pantalla, el cual representa el disefio grafico y la colo-
tar gravemente. En efecto, una interfaz debil puede llevar cacion de iconos, la definicion de un texto descriptivo
a1 fracas0 de una aplicacion con una implementacion en pantalla, la especificacion y titulacion de ventanas y
solida y un buen disefio. la especificacion de 10s elementos importantes y secun-
Existen tres principios importantes que dirigen el dise- darios del menu. Cuando se va a refinar un modelo de
fio de interfaces de usuario eficaces: (1) poner el control disefio para el sistema se tienen en consideracion temas
en manos del usuario; (2) reducir la carga de la memoria de disefio tales como tiempo de respuesta, estructura de
del usuario; (3) construir una interfaz consecuente. Para ordenes y acciones, manipulacion de errores y funcio-
lograr que una interfaz se atenga a estos principios, se nes de ayuda. Para construir un prototipo que el usua-
debera desarrollar un proceso de disefio organizado. rio pueda evaluar se utilizan diversas herramientas de
El disefio de la interfaz de usuario comienza con implementacion.
la identificacion de 10s requisitos del usuario, de las La interfaz de usuario es la ventana del software. En
tareas y del entorno. El analisis de tareas es una acti- muchos casos, la interfaz modela la percepcion que tie-
vidad de disefio que define las tareas y acciones del ne un usuario de la calidad del sistema. Si la ventana se
usuario empleando un enfoque elaborativo u orienta- difumina, se ondula o se quiebra, el usuario puede recha-
do a objetos. zar un sistema potente basado en computadora.
[DUM88] Dumas, J.S., Designing User Interfaces for Soft- puter Systems,, Intl. Journal of Man-Machine Studies,
M1are,Prentice-Hall, 1988. vol. 15, pp. 3-50.
[LEA881 Lea, M., <<EvaluatingUser Interfaces Designs),, User [MYE89] Myers, B.A., ccUser Interface Tools: Introduction
Interface Design for Computer Systems, Halstead Press and Survey),, IEEE Software, Enero 1989, pp. 15-23.
(Wiley), 1988.
[NOR861 Norman, D.A., cccognitive Engineering)),User Cen-
[MAN971 Mandel, T., The Elements of User Interface Design, tered Systems Design, Lawrence Earlbaum Associates,
Wiley, 1997. Nueva Jersey, 1984.
[MON84] Monk, A. (ed), Fundamentals of Human-Compu- [RUB881 Rubin, T., User Interface Design for Computer Sys-
ter.lnteraction, Academic Press, 1984. tems, Haldstead Press (Wiley), 1988.
[MOR81] Moran, T.P., <<TheCommand Language Grammar: [SHN87] Shneiderman, B., Designing the User Interface,
A Representation for the User Interface of Interactive Com- Addison-Wesley, 1987.
15.1. Describa la peor interfaz con la que haya trabajado algu- a. un sistema de autoedicidn
na vez y critiquela en relaci6n con 10s conceptos que se han b. un sistema de diseiio asistido por computadora
presentado en este capitulo. Describa la mejor interfaz con la
c. un sistema de diseiio de interiores
que haya trabajado alguna vez y critiquela en relaci6n con 10s
conceptos presentados en este capitulo. d. un sistema de matriculacidn automatizado para la uni-
versidad
15.2. Desarrolle dos principios de diseiio m8s que ccden el
e. un sistema de gesti6n de biblioteca
control al usuario~.
f. un sistema de votaci6n basada en Internet para las elec-
15.3. Desarrolle dos principios de diseiio m8s que ccreduzcan ciones pfiblicas
la carga de memoria del usuario,,.
g. un sistema bancario en casa
15.4. Desarrolle dos principios de diseiio m8s que ccayuden h. una aplicaci6n interactiva asignada por su instructor
a construir una interfaz consecuente,,.
Desarrolle un modelo de diseiio, un modelo de usuario, una
15.5. Considere una de las aplicaciones interactivas siguien- imagen de sistema y una percepci6n de sistema para cual-
tes (o una aplicaci6n asignada por su profesor): quiera de 10s sistemas anteriores.
CAP~TULO
15 DISENO DE LA INTERFAZ DE U S U A R I O
15.6. Realice un anklisis detallado de tareas para cualquiera el analisis de tareas que haya llevado a cab0 desde el Proble-
de 10s sistemas que se relacionan en el Problema 15.5. Utili- ma 15.6 a1 15.8.
ce un enfoque elaborativo u orientado a objetos.
15.11. Proporcione unos cuantos ejemplos que muestren la
15.7. Como continuacidn a1 Problema 15.6, defina objetos y razdn de que la variabilidad del tiempo de respuesta pueda
acciones para la aplicacidn que acaba de seleccionar. Identi- considerarse un tema a tener en cuenta.
fique todos 10s tipos de objetos.
15.12. Desarrolle un enfoque que integre automaticamente 10s
15.8. Desarrolle un conjunto de formatos de pantalla con una mensajes de error y una funcidn de ayuda a1 usuario. Esto es,
definicidn de 10s elementos del menu principales y secunda- que el sistema reconozca automaticamente el tip0 de error y
rios para el sistema que haya elegido en el Problema 15.5. proporcione una ventana de ayuda con sugerencias para corre-
15.9. Desarrolle un conjunto de formatos de pantalla con una girlo. Realice un disefio de software razonablemente comple-
definicidn de 10s elementos principales y secundarios del menu to que tenga en consideracidn estmcturas de datos y algoritmos.
para el sistema estandar HogarSeguro de la Seccidn 15.4.1. 15.13. Desarrolle un cuestionario de evaluacidn de la interfaz
Puede optar por un enfoque diferente a1 mostrado en la Figu- que contenga 20 preguntas genCricas que se puedan aplicar a la
ra 15.2 sobre un formato de pantalla. mayona de las interfaces. Haga que 10 compai5eros de clase
15.10. Describa el enfoque utilizado en las funciones de ayu- rellenen el cuestionario del sistema de interfaz que vayan a uti-
da del usuario que haya utilizado para el modelo de diseiio en lizar todos. Resuma 10s resultados e informe de ellos a la clase.
Aunque el libro de Dondld Norman no trata especificamente usuario ha sido editado por Carroll (Scenario-Based Design:
interfaces hombre-maquina, mucho de lo que su libro (The Envisioning Work and Technology in System Development,
Design of Everyday Things, Reissue edition, CurrencyDou- Wiley, 1995). Horrocks (Constructing the User Interface with
bleday, 1990) tiene que decir sobre la psicologia de un dise- Statecharts, Addison-Wesley, 1998) ha desarrollado un mCto-
iio eficaz se aplicara a la interfaz de usuario. Es una lectura do formal para el diseiio de interfaces de usuario que se basa
recomendada para todos 10s que sean serios a la hora de cons- en el modelado del comportamiento basado en el estado.
truir un diseiio de interfaz de alta calidad. La actividad de evaluacidn se centra en la usabilidad. Los
Durante la dCcada pasada se han escrito docenas de libros libros de Rubin (Handbook of Usability Testing: How to Plan,
acerca del diseiio de interfaces. Sin embargo, 10s libros de Design, and Conduct Effective Tests, Wiley, 1994) y Nielson
Mandel [MAN971 y Shneiderman (Designing the User Inter- (Usability Inspection Methods, Wiley, 1994) aborda el tema
face: Strategies for Effective Human-Computer Interaction, de forma considerable y detallada.
3." ed., Addison-Wesley, 1990) continuan proporcionando el La computadora Apple de Macintosh popularizd las inter-
estudio mas extenso acerca de la materia. Donnelly (In Your faces de usuario con diseiios sdlidos y faciles de utilizar. El
Face: The Best of Interactive Design, Rockport Publications, personal de Apple (Macintosh Human Interface Guidelines,
1998), Fowler, Stanwick y Smith (GUI Design Handbook, Addison-Wesley, 1993) estudia la apariencia y utilizacidn del
McGraw-Hill, 1998), Weinschenk, Jamar, y Yeo (GUI Design ahora famoso Macintosh (y tan imitado). Uno de 10s prime-
Essentials, Wiley, 1997), Galitz (The Essential Guide to User ros libros que se han escrito acerca de la interfaz de Micro-
Interface Design: An Introduction to GUI Design Principles soft Windows fue elaborado por el personal de Microsoft (The
and Techniques, Wiley, 1996), Mullet y Sano (Designing Windows Guidelines for Software Design: An Application
Visual Interfaces: Communication Oriented Techniques, Pren- Design Guide, Microsoft Press, 1995).
tice Hall, 1995), y Cooper (About Face: The Essentials of En un libro de Murphy (Front Panel: Designing Software
User Inte$ace Design, IDG Books, 1995) han escrito estu- for Embedded User Interfaces, R&D Books, 1998), el cual
dios que proporcionan las lineas generales y principios de puede resultar de gran inter& para 10s diseiiadores del pro-
diseiio adicionales asi como las sugerencias para la elicita- d u c t ~se
, proporciona una guia detallada para el diseiio de
cidn de requisitos, modelado, implementacidn y comproba- interfaces de sistemas empotrados y aborda 10s peligros inhe-
cidn del diseiio. rentes en controles, en manipulacidn de maquinaria pesada e
El analisis y modelado de tareas son las actividades fun- interfaces para sistemas mCdicos y de transporte. El diseiio
damentales del diseiio de la interfaz. Hackos y Redish (User de la interfaz para productos empotrados tambiCn se estudia
and Task Analysis for Interface Design, Wiley, 1998) han en el libro de Garrett (Advanced Instrumentation and Com-
escrito un libro especializado en estos temas y proporcionan puter IIO Design: Real-Time System Computer Interface Engi-
un mCtodo detallado para abordar el analisis de tareas. Wood neering, IEEE, 1994).
(User Interface Design: Bridging the Gap from User Requi- Una amplia variedad de fuentes de informacidn sobre el
rements to Design, CRC Press, 1997) tiene en consideracidn diseiio de la interfaz de usuario y de temas relacionados e s t h
la actividad de analisis para interfaces y la transicidn hacia disponibles en Internet. Una lista actualizada de referencias
las tareas de diseiio. Uno de 10s primeros libros que presen- relevantes para la interfaz de usuario se puede encontrar en
tan el tema de 10s escenarios en el diseiio de la interfaz de http://www.pressman5.com
Palabrtrs clave 1 L diseiio a nivel de componentes, llamado tambiCn diseiioprocedimental, tiene lugar des-
construdn
de tomtidones.. ......274
constrw6h
1 puCs de haber establecido 10s diseiios de datos, de interfaces y de arquitectura. El obje-
J 1ivo es convertir el modelo de diseiio en un software operacional. No obstante, el nivel
de ,abstraction del modelo de disefio existente es relativamente alto y el nivel de abstracci6n del
& repetidones.. .....276 Prolgrama operacional es bajo. Esta conversion puede ser un desafio, abriendo las puertas a la
romtnrccims int~-0duccion de errores sutiles que Sean dificiles de detectar y corregir en etapas posteriores del
. .. ..
estruchrradas . . -275 Proceso del software. Edsgar Dijkstra, uno de 10s principales valedores para la comprension del
b i a m a de @as ....275 dis~6 0 , escribe lo siguiente [DIJ72]:
lengwle de diseiio El software parece ser diferente de muchos otros productos, donde como norma una calidad superior
de progronms ....27&277 implica un precio mis elevado. Aquellos que quieran realmente un software fiable descubrirrin que para
notadones de d i s h . 278 empezar deben encontrar un medio de evitar la mayoria de los errores y, como resultado, el proceso de pro-
gramaci6n seri menos costoso.. ..y los programadores que scan eficaceb no deberiin malgastar su tiempo
nofadelres
.
~ ~ o J s.........274-275
depurando los programas -no deberhn cometer errores desde el principic+-.
Aunque estas palabras ya se escribieron hace muchos aiios, hoy en dia siguen siendo ver-
p-l
.
estructwada ....... .274 dac1. Cuando el modelo de disefio se convierte en codigo fuente, deberhn seguirse una serie de
secuda.. ..........275 pri ncipios que no solo lleven a cabo la conversih, sino que ccno introduzcan errores desde el
pri ncipio>>.
t a b de decisiones ..-276
;Qu& es? Este diseiio clonsiste e n con- ponentes representa el software que notaciones grdrficas, tabulares y basa-
vertir el diseiio d e dat os, interfaces y permite revisar 10s datos del diseiio d a s en texto.
arquitectura e n un sofitware operacio- para s u correccidn y consistencia con €Cud1 es el produeto obtcnido? El
nal. Para poderlo llev a r a cabo. el las representaciones d e disefio ante- diseiio procedimental de cada compo-
disefio s e deberdr re1>resentar a un riores (esto es. Ios diseiio d e datos, de nente representado en forma d e nota-
nivel d e abstracci6n cercano a un interfaces y de arquitectura). Con este ci6n grdrfica, tabular o basada en texto
codigo. El diseiio a n ivel d e compa- diseiio se proporciona un medio de e s el primer producto de trabajo duran-
nentes establece 10s clatos algoritmi- evaluar e l funcionamiento d e l a s te el disefio a nivel de componentes.
cos que s e requieren Ix r a manipular estructuras d e datos, interfaces y
;C6mo puedo estar seguro de que
l a s estructuras d e d a tos, efectuar la algoritmos.
lo he hecho correctamente?
comunicaci6n entre lcIS componenk?~
g4hales son les pasorl Las represen- Mediante una revision estructurada y
del software por medi~ 3 d e las interfa-
taciones de 10s diseiios d e datos. uno inspeccion. El examen del diseiio
ces, e implementar 10s algoritmos
arquitectura e interlaces forman la s e realiza para determinar si las
asignedos a cada corn~ponente
base del diseiio a nivel d e componen- estmcturas de 10s datos, las secuencias
~Qulbn lo hace? Un insjeniero del soft- tes. La narrativa del proceso d e cada del proceso y las condiciones 16gicas
ware. componente s e convierte en un mode- son correctas, y para ver si producirdrn
LPor qmB es importa~nte?Se tiene l o d e diseiio procedimental emplean- la transformation d e datos y control
que tener la capacidac3 de determinar d o un conjunto d e construcciones d e adecuados que s e asign6 a1 compo-
s i e l programa funci~ m a r & antes d e programacion estructurada. Para nente durante 10s primeros pasos del
construirlo. El disefio a nivel d e com- representar este diseflo s e utilizan las disefio.
Mediante la utilizaci6n de un lenguaje de programacidn es posible representar el cliseAo a

nik/el cle componentes. En esencia, el programa se crea empleando coino giiia el modelo de dise-
iio . Un enfoque alternativo es representar el disefio procediinental mediante la utilizacidn de
a12m a representation interinedia (por ejemplo, grifica, tabular o basada en texto) que se pue-
da transformar ficilmente en c6digo fuente. Independientemente del mecanismo que se utilice
Pa'ra representar el diseiio a nivel de componentes, la definition de las estructuras de datos,
interfaces y algoritmos cleber6n ajustarse a la diversidad de lineas generales del diseiio proce-
dirnental establecidas como ayuda para evitar errores durante la evolucidn del mismo disefio.
En este capitulo, examinaremos estas lineas generales de diseiio.
Los f u n d a m e n t ~del
~ disefio a nivel de componentes na que 10s psic6logos denominan jkagmenfacidn (tro-
proceden de la dCcada de 10s afios sesenta, y tomaron ceado o ctztmkirrg).Para entender este proceso, consi-
cuerpo con el trabajo de Edsgar Dijkstra y sus colabo- deremos la manera de leer esta pigina. Las letras no se
radores [BOH66, DIJ65, DIJ761. A finales de 10s sesen- leen individualmente; mris bien, se reconocen formas o
ta, Dijkstra y otros propusieron la utilization de un trozos de letras que forman palabras o frases. Las cons-
conjunto de construcciones 16gicas restringidas de las trucciones estructuradas son fragmentos 16gicos que
que poder f o m a r cualquier programa. permiten a1 lector reconocer elenientos procedimenta-
les de un m6dulo en lugar de leer el disefio o el c6digo
linea a linea. La comprensi6n mejora cuando se encuen-
w tran patrones fhcilmente reconocibles.
Cuondo estoy hoboiando en un probk!ma nunca
pienso en lo bonito que es. Solo pienr;o en como
resolverlo. Per0 cuondo lo orobo, me doy cuento 16.1.1. Notaci6n grafica del diseiio
An -tA (inrn .nr..lmAn
GI ~ G ~ u I I U U u es bonito.
uG
nl.n nn
Ilu G,IU ulGll
C: nfi
((Unaimagen vale mris que mil palabras>,,pero es impor-
R. Buckminster Fuller tante saber quC imngen y qui 1.000 palabras. Es incues-
Las construcciones son secuenciales, condicionales tionable que herramientas gr2ificas, tales conio diagramas
y repetitivas. La construcci6n secuencial implements de flujo o diagranias de cajas, proporcionan formas gri-
10s pasos del proceso esenciales para la especificaci6n ficas excelentes que representan datos procedimentales
de cualquier algoritmo. La condiciorral proporciona las ficilmente.
funciones para procesos seleccionados a partir de una
condition 16gica y la repetitiva proporciona 10s bucles.
Las tres construcciones son fundamentales para la pro-
gr.anracicin estr~uc~t~~r-uda
-unit tCcnica importante de lo progromocion estructurodo proporciono
disefio a nivel de componentes-. 10s modelos 16gicos y fitiles para el diseiiodor.
Las construcciones estructuradas se propusieron para
restringir el disefio procedimental del software ij un El diagrama de flujo es una imagen bastante senci-
nlimero reducido de operaciones predecibles. La mCtri- Ila. Mediante la utilizaci6n de una caja se indica un paso
ca de la complejidad (Capitulo 19) indica que la utili- del proceso. Un rombo representa una condici6n 16gi-
zaci6n de construcciones estructuradas reduce la ca y las flechas indican el flujo de control. La Figura
complejidad del programa y, por tanto, rnejora la capa- 16.1 ilustra tres construcciones estructuradas. La secuen-
cidad de comprender, comprobar y niantener. La utili- cia se representa como dos cajas de procesamiento
zacidn de un nlimero limitado de construcciones 16gicas conectadas por una linea (flecha) de control. La condi-
tambiCn contribuye a un proceso de comprensi6n huma- ci6n, llamada tambiCn si-enfonc-e.r-si-tro,se representa
Primera
tarea
Siguiente
tarea
A Condicidn
Party si-no
Primer
tarea
Si-entonces
\
Siguiente
entonces
Secuencia Si entonces si-no
(if-then-else)
Condicion
del caso
Tarea
Parte de bucle
......................... -----------
i
f --I---'
Tarea
Mientras- de bucle de bucle
hacer Repetir-hasta
(do-while) (repeat-until) Condicidn
Segun-sea (selecion) Repeticion de bucle
FIGURA 16.1. Construcciones en diagrama de flujo. FIGURA 16.2. Construcciones anidadas.

CAPfTULO 16 D I S E N O A NIVEL D E C O M P O N E N T E S
mediante el simbolo del rombo de decision que, si es Chapin [CHA74], 10s diagramas (tambikn denomina-
cierto, provoca el procesamiento de la parte entonces, dos diagr-crmas Ncrssi-Schneiderrncrn, diagrwmas N-S o
y, si es falso, invoca el procesamiento de la par-te si-no. clicigrcrrnas Chcipin) tienen las caracteristicas siguien-
La repeticion se representa mediante dos formas lige- tes: ( I ) dominio funcional (es decir, el alcance de una
raniente diferentes. El rnientrus-hacw prueba una con- repeticidn o de un si-entonces-si-no) bien definido y
dicidn y ejecuta una tarea de bucle repetidamente claramente visible como representacion grlifica; (2) la
siempre que la condicidn siga siendo verdad. Un repe- transferencia arbitraria de control es imposible; (3) el
fir-hastri primer0 ejecuta la tarea de bucle, despuks prue- alcance de 10s datos locales y/o generales se puede deter-
ba la condicion y repite la tarea hasta que la condicion minar flicilmente y (4) la recursividad es f k i l de repre-
falla. La construcciBn de seleccidn (segiin sect) que se sentar.
muestra en la figura realmente es una ext;nsion de si-
entonces-si no. Un parlimetro se prueba por decisiones
Prirnera tarea
sucesivas h k a que ocurre una condicion verdadera y
se ejecuta el camino de procesamiento asociado.
Las construcciones estructuradas pueden anidarse
Siguienfe tarea
unas en otras como muestra la Figura 16.2. En esta Figu-
ra, un repetir-hasta forma la parte then dc un si-enton-
ces-si-no (mostrada dentro de la linea discontinua
Siguiente tarea +1
si-no
Pane I entonces
Pane
exterior). Otro if-then-else forma la parte si-no de la pri-

mera condici6n. Finalmente la condicion propiamente
dicha se convierte en un segundo bloque en una secuen- Secuencia
cia. Anidando construcciones de esta manera, se puede
desarrollar un esquema ldgico complejo. Se deberia des- Condicion de bucle
tacar que cualquiera de 10s bloques de la Figura 16.2 Parte
podria hacer referencia a otro modulo, logrando por tan- repetir hasta
..*
to la estratificaci6n procedimental que conlleva la estruc- (repeat unw)
Parte
tura del programa. hacer mientras
(do while)
10s mnstrucciones de progromocion estructumdo

deberan focilitor lo comprension del diseiio. Es carrecto
soltorlos, si uflzor/os sin ((soItor/os~)do como resultodo Repeticion
uno complejidod innecesorio
En general, la utilization dogmlitica de construccio- ondicion segun-sea (ca

nes estructuradas exclusivamente puede introducir ine-
Valor Valor ...
ficiencia cuando se requiere salir de un conjunto de
bucles anidados o condiciones anidadas. Lo que es mlis
importante, una complicacidn adicional de todas las Parte
pruebas 16gicas a lo largo del camino de salida puede ...
caso
oscurecer el flujo de control del software, aumentar la
posibilidad de error y tener un impact0 negativo en su
A
lectura y mantenimiento. iQu6 podemos hacer?
Seleccion
El diseiiador dispone de dos opciones: (1) la repre-
scntacidn procedimental se rediseiia de manera que la FIGURA 16.3. Construcciones de diagramas de capas.
ccrama de escape)) no sea necesaria en una posici6n ani-
dada en el flujo de control; o (2) las construcciones La representaci6n grlifica de construcciones estruc-
estructuradas se salten de una manera controlada; esto turadas mediante diagramas de cajas se ilustra en la
es, se diseiia una rama restringida fuera del flujo anida- Figura 16.3. El elemento fundamental del diagrama es
do. La opciBn 1 es obviamente el enfoque ideal, per0 la la caja. Para representar una secuencia, se conectan dos
opcidn 2 se puede implantar sin romper el espiritu de la cajas seguidas. Para representar un si-entonces-si-no,
programacion estructurada [KNU75]. la condici6n va seguida de una caja parte si-entonces y
Otra herramienta de diseiio grrifico, el diagrcrrncr tie una parte si-no. La repetici6n se dibuja con un limite
cajcrs, surgi6 del deseo de desarrollar una representa- que encierra el proceso (parte hacer-mientras o parte
cidn de diseiio procedimental que no permitiera la vio- repetir-hasta) que se va a repetir. Finalmente, la selec-
lacidn de las construcciones estructuradas. Desarrollada cidn se representa mediante la forma grhfica mostrada
por Nassi y Schneiderman [NAS73] y ampliada por en la parte inferior de la figura.
A SOFTWARE. UN ENFOQUE PRACTlCO
En la Figura 16.4 se ilustra la organizaci6n de la tabla

de decisi6n y se divide en cuatro secciones. El cuadrante
Tonto 10s diogromos de flujo como 10s diogromos superior izquierdo contiene una lista de todas las con-
de cojos yo no se utilizon tonto coma antes. En generol, diciones. El cuadrante inferior contiene una lista de todas
se deberion utilizor poro documentor o evoluor el disefio las acciones posibles basindose en combinaciones de
en casos especificos, no para representor todo un sistema. las condiciones. Los cuadrantes de la derecha forman
una matriz que indica las combinaciones de las condi-
A1 igual que 10s diagramas de flujo, un diagrama de ciones y las correspondientes acciones que se han de
cajas esth estratificado en multiples phginas a medida producir para cada combinaci6n especifica. Por tanto,
que se refinan 10s elementos de procesamiento de un cada columna de la matriz puede interpretarse como una
m6dulo. Una ccllamada>>a un m6dulo subordinado se regla de procesamiento.
puede representar mediante una caja con el nombre del Para desarrollar una tabla de decisi6n se aplican 10s
m6dulo encerrado en un 6valo. siguientes pasos:
Hacer una lista de todas las acciones que pueden aso-
16.1.2. Notacion tabular de diseiio
ciarse con un procesamiento especifico (o m6dulo).
En muchas aplicaciones de software, puede ser necesa-
rio un m6dulo que evalue una combinaci6n compleja Hacer una lista de todas las condiciones (o decisio-
nes) durante la ejecuci6n del procesamiento.
de condiciones y que seleccione las acciones basadas
en esas condiciones. Las tablas de decisi6n proporcio- Asociar conjuntos especificos de condiciones con
nan una notacion que convierte acciones y condiciones acciones especificas, eliminando combinaciones
(descritas en la narraci6n del procesamiento) en una for- imposibles de condiciones; altemativamente, desa-
ma tabular. Es dificil que la tabla se pueda interpretar rrollar cualquier permutaci6n posible de combina-
mal, e incluso es posible utilizarla como entrada legi- ciones.
ble por la mhquina para un algoritmo dirigido por una Definir reglas indicando quC accion o acciones ocu-
tabla. En un estudio completo de esta herramienta de rren para un conjunto de condiciones.
diseiio, Ned Chapin afirma [HUR83]:
tComo se puede construir
una tabla de decisiones?
Para ilustrar el empleo de una tabla de decision tome-

mos en consideration el siguiente extract0 de una des-
cripcion procedimental para un sistema de facturaci6n
de un servicio publico:
Si la cuenta del cliente se factura utilizando un mttodo de
tarifas fijo, se establece un cargo mensual minimo para con-
sumos menores de lOOkWh (kilovatios/hora). En 10s demas
casos, la facturacion por computadora aplica la tarifa A. Sin
embargo, si la cuenta se factura empleando un mttodo de fac-
turacidn variable, se aplicari la tarifa A para consumos por
debajo de lOOkWh, con un consumo adicional facturado de
acuerdo con la tarifa B.
La Figura 16.5 ilustra una representaci6n de tabla de
decisi6n de la descripci6n anterior. Todas y cada una de
las cinco reglas indican una condici6n de las cinco via-
b l e ~(esto es, en el context0 de este procedimiento una
FIGURA 16.4. Nomenclatura de la tabla de decision. ceVn (verdadera) no tiene sentido ni en la cuenta de tari-
fa fija ni en la variable, por tanto esta condici6n se omi-
Algunas herramientas de software antiguas se combinan te). Como regla general, la tabla de decisi6n puede
bien con otras herramientasnuevas y ttcnicas de ingenieria del utilizarse eficazmente para complementar otras nota-
software. Las tabla de decision son un ejemplo excelente.Fue- ciones de diseiio procedimental.
ron las que precedieron a la ingenieria del software hace casi
una dtcada, F r o encajaron tan bien con la ingenieria del soft-
ware que podrian haberse diseiiado con tal prop6sito. 16.1.3. Lenguaje de diseiio de programas
El lenguaje de diseiio de programas (LDP), tambiCn
denominado lenguaje estructurado o pseudocddigo, es
Utilice uno tabla de decisibn cuondo dentra ccun lenguaje rudimentario en el sentido de que utiliza
de un componente se combine un conjunto el vocabulario de un lenguaje (por ejemplo, el InglCs),
completo de condiciones y de occiones. y la sintaxis global de otro (esto es, un lenguaje estruc-
CAP~TULO
16 DISENO A NlVEL D E C O M P O N E N T E S
turado de programaci6n)~[CAI75]. En este capitulo se Hay que destacar que LDP se puede ampliar de
utiliza LDP como'referencia genCrica de un lenguaje de manera que incluya palabras clave para procesos mul-
diseiio. titarea ylo concurrentes, manipulation de interrupcio-
A primera vista LDP se parece a un lenguaje de pro- nes, sincronizaci6n entre procesos y muchas otras
gramaci6n moderno. La diferencia entre Cste y un ver- caracteristicas. Los diseiios de aplicaciones para 10s que
dadero lenguaje de programaci6n radica en el empleo se utiliza LDP deberin dictar la forma final que tendra
de texto descriptivo (por ejemplo, InglCs) insertado el lenguaje de diseiio.
directamente dentro de las sentencias de LDP. Dado que
se utiliza texto descriptivo insertado directamente en 16.1.4. Un ejemplo de LDP
una estructura sintactica, este lenguaje no se puede com-
pilar (a1 menos por ahora). Sin embargo, las herrarnientas Para ilustrar el empleo de LDP presentamos un ejem-
LDP que existen actualmente convierten LDP en un plo de diseiio procedimental para el software del siste-
ccesquema,, de lenguaje de programacion, y/o repre- ma de seguridad HogarSeguro comentado en capitulos
sentacion grafica (por ejemplo, un diagrama de flujo de anteriores. El sistema HogarSeguro en cuestion vigila
disefio). Estas herramientas tambiCn producen mapas las alarmas de deteccion de fuego, humo, ladrones, agua
anidados, un indice de operacibn de diseiio, tablas de y temperatura (por ejemplo, la ruptura del sistema de
referencias cruzadas, y mas diversidad de informaci6n. calefacci6n durante la ausencia del propietario en invier-
no); hace saltar el sonido de la alarma, y llama a1 ser-
vicio de vigilancia generando un mensaje de voz
sintetizada. En el LDP que se muestra a continuaci6n,
1 Condiciones se ilustran algunas de las construcciones importantes
I Cuenta de tarifa fija sefialadas en secciones anteriores.
Cuenta de tarifa variable
Hay que recordar que LDP no es un lenguaje de pro-
gramacion. El diseiiador hace una adaptaci6n cuando
Consurno < 100kWh lo requiere y sin preocuparse de errores de sintaxis. Sin
embargo, se debera revisar el diseiio del software de
vigilancia (jse observa alglin problema?) y refinarlo
antes de escribirse. El LDP siguiente define una elabo-
1 Acciones ration de diseiio procedimental para el ccmponente de
monitor de seguridad.
IFacturaci6n tarifa A PROCEDURE seguridad.monitor;
IFacturaci6n tarifa B INTERFACE RETURNS sistema.estado;

TYPE sefial I S STRUCTURE DEFINED
1 Otro tratarniento nombre I S STRING LENGTH VAR;
direcci6n I S HEX dispositivo localizacidn;
l h i te.valor I S superior l h i te SCALAR;
mensaje I S STRING LENGTH VAR;
FIGURA 16.5. Tabla de decision resultante.
END sefial TYPE;
TYPE sistema.estado I S B I T ( 4 ) ;
Un lenguaje de disefio de programas puede ser una TYPE alarma.tipo DEFINED;
simple transposition de un lenguaje tal como Ada o C. humo.alarma I S INSTANCE OF sefial;
Alternativamente, puede ser un product0 comprado fuego.alarma I S IN,STANCE OF sezal;
especificamente para el diseiio procedimental. agua.alarma I S INSTANCE OF sefial;
temp.alarma I S INSTANCE OF sefial;
ladr6n.alarma I S INSTANCE OF sefial;
TYPE tel&fono.ndmero I S are c6digo c 7 -digit0
Serio uno bueno idea uh'lizor on lenguoje nhero;
de progromocian como base para el LDF
Esto hora posible generor on esquemo de cadigo
h~ezclodocon textd o medido que se llevo
o cobo el diseio o nivel de componentes.
inicializar todos sistemas puertos y reinicializar
Una sintaxis basica LDP debera incluir construccio- todo hardware;
nes para la definicion de subprogramas, descripci6n de CASE OF control .panel.interruptores (cps);
la interfaz, declaraci6n de datos, tCcnicas para la estruc- WHEN cps = "test' SELECT
turaci6n de bloques, construcciones de condici6n, cons- CALL alarma PROCEDURE WITH "activado" para co
trucciones repetitivas y construcciones de EIS. El probaci dn . tiempo en segundos;
formato y la semhtica de estas construcciones LDP se WHEN cps = "alarma-desactivada" SELECT
presentan en la seccion siguiente. CALL a1arma PROCEDURE WITH "desactivada";
~ N G E N ~ E RDEL
WHEN cps = "nuevo.limite.temp" SELECT PARBEGIN

CALL teclado.entrada PROCEDURE; CALL alanna PROCEDURE WITH "activada",alar-
WHEN cps = "1adrdn.alarma.desactivada"SELECT ma.tiempo en segundos;
desactivar sefial iladr6n.alarma]; CALL telefono PROCEDURE WITH rnensaje [alar-
ma. tipol, telefono nhero;
ENDPAR
ELSE bifurcacidn
DEFAULT ninguno; ENDIF
ENDCASE ENDFOR
REPEAT U N T I L activar.interruptor es desactivado ENDREP
reinicializar todos sefial.valores e interruptores; END seguridad.monitor
DO FOR alarm.tip0 = humo, fuego, aqua, temp, Hay que destacar que el disefiador del procedimiento
ladrdn; del monitor de seguridad ha utilizado una construction
READ direcci6n[alarma.tipol sefial .valor;
nueva PARBEGIN ... ENDPAR la cual especifica un blo-
I F sefial.valor > limite [alarma.tipoj
THEN telefono.mensaje = mensajeialanna.tipol;
que paralelo. Todas las tareas especificadasdentro del blo-
establecer alarma.timbre en "activada" para
que PARBEGIN se ejecutan en paralelo. En este caso, no
a1anna.tiemposegundos; se toman en consideraci6n 10s detalles de implementaci6n.
En la secci6n anterior se han presentado varias tCcnicas con la que un disefio se puede editar ayudarh a sim-
diferentes para representar un disefio procedimental. Se plificar todas y cada una de las tareas de la ingenie-
puede establecer una comparaci6n teniendo la premisa ria del software.
de que cualquier notaci6n para el disefio procedimen- Legibilidad para la computadora. Una notaci6n
tal, si se utiliza correctamente, puede ser una ayuda que se puede introducir directamente en un sistema de
incalculable para el proceso de disefio; por el contrario, desarrollo basado en computadora ofrece ventajas sig-
aun con la mejor notacibn, si Csta se aplica mal, dismi- nificativas.
nuye su entendimiento. Teniendo en cuenta lo anterior,
es momento de examinar 10s criterios que se pueden Capacidad de mantenimiento. El mantenimiento
aplicar para comparar las notaciones de disefio. del software es la fase mhs costosa del ciclo de vida del
La notaci6n de disefio deberh llevarnos a una repre- software. El mantenimiento de la configuraci6n del soft-
sentaci6n procedimental fhcil de entender y de revisar. ware casi siempre lleva a1 mantenimiento de la repre-
Ademhs, la notaci6n deberh mejorar la habilidad de sentaci6n del disefio procedimental.
cccodificar en>>para que el c6digo se convierta de hecho Cumplimiento de las estructuras. Ya se han des-
en un subproducto natural de disefio. Finalmente, la crito las ventajas de un enfoque de disefio que utiliza
representaci6n de disefio debera ser fhcil de mantener conceptos de programacion estructurada. Una notacion
para que el disefio sea siempre una representaci6n de disefio que hace cumplir solo la utilizaci6n de cons-
correcta del programa. trucciones estructuradas conduce a la prhctica de un
buen disefio.
iCuales son 10s criterios que
se utilizan para evaluar Proceso automatico. Un disefio procedimental con-
notaciones de diseiio? tiene la informaci6n que se puede procesar para que el
disefiador pueda obsemar otra vez y mejorar la correc-
Dentro del context0 de las caracteristicas generales ci6n y calidad de un disefio. Dicha obsemaci6n puede
que se describieron anteriormente se han establecido mejorarse con informes que provengan de herramien-
10s siguientes atributos de notaciones de disefio: tas de disefio de software.
Modularidad. Una notaci6n de disefio deberh sopor- Representacion de datos. La habilidad de repre-
tar el desarrollo del software modular y proporcionar sentar datos locales y globales es un elemento esencial
un medio para la especificaci6n de la interfaz. del disefio detallado. Una notaci6n de disefio ideal seria
Simplicidad general. Una notaci6n de disefio debe- la representaci6n directa de 10s datos.
rh ser relativamente simple de aprender, relativamente Verificacion de la logica. La verificaci6n automhti-
fhcil de utilizar y en general fhcil de leer. ca de la 16gica del disefio es el objetivo primordial duran-
Facilidad de edicion. Es posible que el disefio te las pruebas del software. Una notaci6n que mejora la
procedimental requiera alguna modificaci6n a medi- habilidad de verificar la 16gica mejora enormemente lo
da que el proceso de software avanza. La facilidad aceptable de las pruebas.
CAPfTULO 16 DISENO A NIVEL D E C O M P O N E N T E S
Habilidad de acodificar en,,. La tarea de ingenie- ten, y el potencial de ccgenerar codigos automiticos>es
. ria del software que va a continuaci6n del disefio a nivel bueno.
de componentes es la generacion de codigos. Una nota- Sin embargo, no se puede decir que la notaci6n
ci6n que puede convertirse ficilmente en c6digo fuen- de disefios sea necesariamente inferior a LDP o que
te reduce esfuerzos y errores. ccsea buena>>en atributos especificos. Muchos dise-
Una pregunta que surge naturalmente de cualquier fiadores prefieren la naturaleza pictorica de 10s dia-
estudio de notaciones de disefio es: <<iCuiles realmen- gramas de flujo y de 10s diagramas de bloques dado
te la mejor notacion segun 10s atributos que se han esta- que proporcionan alguna perspectiva sobre el flujo
blecido anteriormente?u La respuesta seria totalmente de control. El contenido tabular preciso de las tablas
subjetiva y abierta a debate. Sin embargo, parece ser de decisi6n es una herramienta excelente para las
que el lenguaje de disefio de programas ofrece la mejor aplicaciones controladas por tablas. Y muchas otras
combinaci6n de caracteristicas. LDP puede insertarse representaciones de disefio (por ejemplo, vCase
directamente en listados de fuentes, en mejoras de docu- [PETgl], [SOM96]), que no se presentan en este
mentaci6n y a1 hacer que el mantenimiento del disefio libro, ofrecen sus propias ventajas. En el analisis
sea menos dificil. La edici6n se puede llevar a cab0 final, la selecci6n de una herramienta de disefio pue-
mediante cualquier editor de texto o sistema de procede depender mas de factores humanos [CUR851 que
samiento de texto; 10s procesadores automAticos ya exis- de atributos tCcnicos.
El proceso de disefio acompaiia a una secuencia de acti- las notaciones de disefio que representa 10s detalles a
vidades que reducen lentamente el nivel de abstracci6n nivel de componentes o bien en formatos grificos, tabu-
con el que se representa el software. El disefio a nivel lares o basados en texto.
de componentes representa el software a un nivel de La programacion estructurada es una filosofia de
abstracci6n muy cercano a1 c6digo fuente. disefio procedimental que restringe el numero y tip0 de
A un nivel de componentes, el ingeniero del software construcciones 16gicas que se utilizan para representar
debe representar estructuras de datos, interfaces y algo- el dato algoritmico. El objetivo de la programacion
ritmos con suficiente detalle como para servir de guia estructurada es ayudar a que el disefiador defina algo-
en la generacion de c6digos fuente de lenguajes de pro- ritmos menos complejos y por tanto mhs fhciles de leer,
gramaci6n. Para conseguirlo, el ingeniero utiliza una de comprobar y mantener.
[BOH66] Bohm, C., y G. Jacopini, <<FlowDiagramas, Turing [DIJ76] Dijkstra, E., <<StructureProgramming)), Software
Machines and Languages with only two Formation Rules)), Engineering, Concepts and Techniques (J. Buxton et al.,
CACM, vol. 9, n."5, Mayo 1966, pp. 366-371. eds.), Van Nostrand-Reinhold, 1976.
[CAI751 Caine, S., y K. Gordon, <tPDL-A Tool for Soft- [HUR83] Hurley, R.B., Decision Tables in Software Engi-
ware Design)), in Proc. National Computer Conference, neering, Van Nostrand Reinhold, 1983.
AFIPS Press, 1975, pp. 27 1-276.
[LIN79] Linger, R.C, H. D. Mills y B.I. Witt, Estrurtured
[CHA74] Chapin, N., <<A
New Format for Flowchartsu, Soft- Programming, Addison-Wesley, 1979
nrare-Practice and Experience, vol. 4, n:" 4, 1974, pp.
341-357. [NAS73] Nassi, I., y B. Shneiderman, <<FlowchartTechni-
ques for Structured Programming)), SIGPLAN Notices,
[DIJ65] Dijkstra, E., <<ProgrammingConsidered as a Human ACM, Agosto 1973.
Activity)), in Proc. 1965 IFIP Congress, North Holland
Publishing Co., 1965. [PET811 Peters, L.J., Software Design: Methods and Tech-
[DIJ72] Dijkstra, E., <<TheHumble Programmer)),1972 ACM niques, Yourdon Press, Nueva York, 1981.
Turing Award Lecture, CACM, vol. 15, n." 10, Octubre [SOM96] Sommerville, I., Software Engineering, 5.* ed.,
1972, pp. 859-866. Addison-Wesley, 1996.
. . . .
S
. . .
Y PUNTOS A CQKSIPEBBB
' " " _ I . .
.
16.1. Seleccione una parte pequeiia de un programa que ya suponga que todos 10s procesos sobre 10s impuestos son lle-
exista (aproximadamente de 50-75 lineas de c6digo). Aisle las vados a cab0 por otros m6dulos.
construcciones de programaci6n estructurada dibujando cajas 16.6. Desarrolle un diseiio procedimental para un programa
alrededor de ellas en el cddigo fuente. existe en construccio- que acepte un texto arbitrariamente largo como entrada y ela-
nes dentro del pasaje del programa que violen la filosofia de
bore una lista de palabras y de su frecuencia de aparicidn como
programacidn estructurada? Si fuera asi, vuelva a diseiiar el
salida.
cddigo para adaptarlo a las construcciones de programacidn
estructurada. Si no fuera asi, ~ Q u Cse puede destacar en las 16.7. Desarrolle un diseiio procedimental de un programa que
cajas que acaba de dibujar? integre numCricamente una funci6nf en 10s limites de a hacia b.
16.2. Todos 10s lenguajes de programacion modemos imple- 16.8. Desarrolle un diseiio procedimental para una maquina
mentan las construcciones de programacion estructurada. Pro- Turing generalizada que acepte un conjunto de cuadruples
porcione ejemplos de tres lenguajes de programaci6n. como entrada de programa y elabore una salida segun espe-
cificacibn.
16.3. PO^ quC es importante la ccfragmentaci6m durante el
proceso de revision de diseiio a nivel de componentes? 16.9. Desarrolle un diseiio procedimental para un programa
que solucione el problema de las Torres de Hanoi. Muchos
Los problemas 16.4-16.12 se pueden representar en una (o
libros de inteligencia artificial estudian este problema deta-
mas) notaciones de diseiio procedimentales presentadas en
lladamente.
este capitulo. Su profesor puede asignar notaciones de diseiio
especificas a problemas concretos. 16.10. Desarrolle un diseiio procedimental para todas las par-
tes o las partes fundamentales de un analizador sintactico para
16.4. Desarrolle un diseiio procedimental para 10s compo-
un compilador. Consulte uno o mas libros sobre diseiio de
nentes que implementan las ordenaciones siguientes: Shell-
Metzner; heapsort (ordenacibn del monticulo). Si no esta compiladores.
familiarizado con estas ordenaciones, consulte cualquier libro 16.11. Desarrolle un diseiio procedimental para el algoritmo
sobre estructuras de datos. de encriptacion/descriptaci6n que haya seleccionado.
16.5. Desarrolle un diseiio procedimental para una interfaz de 16.12. Escriba un argumento de una o dos paginas para la nota-
usuario interactiva que solicite informacion basica acerca de ci6n de diseiio procedimental que prefiera. Asegurese de que su
10s impuestos sobre la renta. Derive sus propios requisitos y argumento abarca 10s criterios presentados en la Secci6n 16.2.
El trabajo de Linger, Mills y Witt (Structured Programming- el diseiio procedimental en un contexto de lenguaje de pro-
Theory and Practice, Addison-Wesley, 1979) sigue siendo el gramaci6n:
estudio definitivo sobre esta materia. El texto contiene un Adamson, T.A., K.C. Mansfield y J.L. Antonakos, Struc-
buen LDP asi como estudios detallados de ramificaciones de tured Basic Applied to Technology, Prentice Hall, 2000.
la programacion estructurada. Entre otros libros que se cen- Antonakos, J.L., y K. Mansfield, Application Program-
tran en temas de diseiio procedimental se incluyen 10s libros ming in Structured C , Prentice Hall, 1996.
de Robertson (Simple Program Design, Boyd & Fraser Publis- Forouzan, B.A., y R. Gilberg, Computer Science: A Struc-
hing, 1994), Bentley (Programming Pearls, Addison-Wes- tured Programming Approach Using C+ +, Brooks/Cole
ley, 1986, y More Programming Pearls, Addison-Wesley, Publishing, 1999.
1988) y Dahl, Dijkstra y Hoare (Structured Progamming, Aca- O'Brien, S.K., y S. Nameroff, Turbo Pascal 7: The Com-
demic Press, 1972). plete Reference, Osbome McGraw-Hill, 1993.
Solo existe un numero relativamente pequeiio de libros Welbum, T., y W. Price, Structured Cobol: Fundamentals
actuales dedicado unicamente a1 diseiio a nivel de com- and Style, 4.%d., Mitchell Publishers, 1995.
ponentes. En general, 10s libros de lenguajes de progra- Una gran variedad de fuentes de informacion sobre dise-
macion abordan el diseiio procedimental con algun detalle, iio de software y temas relacionados estan disponibles en
per0 siempre en el contexto del lenguaje que se ha intro- Internet. Una lista actualizada de referencias a sitios (luga-
ducido en este libro. Los siguientes libros son representa- res) web que son relevantes para conceptos y mktodos de dise-
tivos de 10s cientos de titulos que tienen en consideraci6n iio se pueden encontrar en http://www.pressman5.com.
&Queer? Una vez generado el codigo - - - 'os del software se
fuente, el software debe ser probado el procesode prueba, 10s especialistas io tknicas de dise-
para descubrir (y corregir) el mdximo e n pruebas se van incorporando. iio de casos de prueba de ncaja negra*.
de errores posiblea antes de su entre- ;Par qu6 es imporlade? Las revisio- En ambos casos, se intenia encontrar el
ga a1 cliente. Nuestro objetivo e s dise- nes y otras actividades SQAdescubren mayor numero d e enores con la menot
fiar una serie d e casos de prueba que errores, pero no son suficientes. Cada cantidad de esfueno y tiempo.
tengan una alto probabilidad d e vez que el programa se ejecuta, el clien- &Cuo1es e l producto abtenido? Se
encontrar enores -per0 jc6mo conse- te lo esta probando. Por lo tanto, debe- define y documenta un conjunto de
guirlo?- Aqui e s donde aplicamos las mos hacer un intento especial por msos de prueba, diseiiados para com-
tknicas de pruebas del software. Estas encontrar y corregir todos 10s errores probar Ia 16gica intema y 10s requisites
t k n i c a s facilitan una guia sistembti- antes de entregar el prcgrama a1 clien- extemos. Se determinan 10sresultados
ca para disefiar pruebas que: (1)com- te. Con el objetivo de encontrarel mayor esperados y se guardan 10s resultados
prueben la 16gica interna d e 10s numero posible de errores, las pruebas realmente obtenidos.
componentes software. y (2) verifiquen deben conducisse sistemctticamente, y ~Cdmopuedo d w segrw de que la
10s dominios de entrada y saIida.de1 10s casas d e prueba deben diseiiarse he hecho correctamente? Cuan-
prcgrama para descubrir errores en la utilizando tknicas definidas. do comienzas la prueba, debes cambia
iuncionalidad, el comportamiento y
~CuQesson lol pcsos? El softwaredebe tu punto devista. Intenta wompern con
rendimiento
probarse desde dos perspectivas dife- firmeza el software. Diseiia casos d e
~Qui6n 10 hace? Durante las primems rentes: (1) la 16gica intema del progra- prueba d e una forma disciplinada y
etcrpas de la prueba, es el ingeniero del ma se comprueba utiliindo tknicas d e revisa q u e dichos casos d e prueba
software quien realiza todas las prue- disefio d e casos de prueba de ucaja abarcan todo lo desanollado,
En este capitulo, veremos 10s fundamentos de las pruebas del software y las tecnicas de dise-
fio de casos de prueba.
I N G E N ~ E R ~ A DEL SOFTWARE. UN ENFOQUE P R h C T I C 0
Las pruebas presentan una interesante anomalia para el 2. Un buen caso de prueba es aquel que tiene una alta
ingeniero del software. Durante las fases anteriores de probabilidad de mostrar un error no descubierto hasta
definici6n y de desarrollo, el ingeniero intenta construir entonces.
el software partiendo de un concept0 abstract0 y llegan- 3. Una prueba tiene Cxito si descubre un error no detec-
do a una implementaci6n tangible. A continuacion, llegan tad0 hasta entonces.
las pruebas. El ingeniero crea una serie de casos de prue-
ba que intentan ccdemoler>>el software construido. De ~CUOI
es nuestro primer
hecho, las pruebas son uno de 10s pasos de la ingenieria objetivo cuando probamos
del software que se puede ver (por lo menos, psicol6gi- el software?
camente) como destructivo en lugar de constructive.
Los objetivos anteriores suponen un cambio drama-
tico de punto de vista. Nos quitan la idea que, normal-
mente, tenemos de que una prueba tiene Cxito si no
descubre errores.
Nuestro objetivo es disefiar pruebas que sistemAtica-
mente saquen a la luz diferentes clases de errores, haciCn-
dolo con la menor cantidad de tiempo y de esfuerzo.
Los ingenieros del software son, por naturaleza, per- Si la prueba se lleva a cab0 con Cxito (de acuerdo con
sonas constructivas. Las pruebas requieren que se des- el objetivo anteriormente establecido),descubrira errores
carten ideas preconcebidas sobre la cccorrecci6nn del en el software. Como ventaja secundaria, la prueba
software que se acaba de desarrollar y se supere cual- demuestra hasta quC punto las funciones del software pare-
quier conflict0 de intereses que aparezcan cuando se cen funcionar de acuerdo con las especificaciones y pare-
cen alcanzarse 10s requisitos de rendimiento. Ademas, 10s
descubran errores. Beizer [BE1901 describe eficiente-
mente esta situaci6n cuando plantea: datos que se van recogiendo a medida que se lleva a cab0
la prueba proporcionan una buena indicaci6n de la fiabi-
Existe un rnito que dice que si fuCramos reahnente buenos lidad del software y, de alguna manera, indican la calidad
programando, no habria errores que buscar. Si tan solo fuCra-
rnos realrnente capaces de concentrarnos, si todo el rnundo del software como un todo. Pero, la prueba no puede ase-
ernpleara tkcnicas de codificaci6n estructuradas,el diseiio des- gurar la ausencia de defectos; s610 puede demostrar que
cendente, las tablas de decision, si 10s programas se escribieran existen defectos en el software.
en un lenguaje apropiado, si tuvi6ramos siernpre la soluci6n m b
adecuada, entonces no habria errores. Asi es el mito. Segtin el
rnito, existen errores porque somos malos en lo que hacemos,
y si sornos malos en lo que hacemos, deberiamos sentimoscul-
pable~por ello. Por tanto, las pruebas, con el diseiio de casos
de prueba, son un reconocirniento de nuestros fallos, lo que
irnplica una buena dosis de culpabilidad. Y lo tediosas que son
las pruebas son un justo castigo a nuestros errores. ~Castigados
por quC? LPor ser hurnanos? iCulpables por quC? LPor no con-
seguir una perfection inhumana? LPor no poder distinguir en*
lo que otro programador piensa y lo que dice? ~ P o no r tener
telepatia? ~ P o no
r resolver 10s problemas de cornunicacion 17.1.2. Principios de las pruebas
hurnana que han estado presentes...durante cuarenta siglos?
Antes de la aplicacih de mCtodos para el disefio de
debe en infundir culpabilidad las pruebas? $on real- casos de prueba efectivos, un ingeniero del software
mente destructivas? La respuesta a estas preguntas es: debera entender 10s principios basicos que guian las
NO! Sin embargo, 10s objetivos de las pruebas son algo pruebas del software. Davis [DAV95] sugiere un con-
diferentes de lo que podriamos esperar. junto' de principios de prueba que se han adaptado para
usarlos en este libro:
17.1.1. Objetivos de las pruebas A todas las pruebas se les deberia poder hacer un
En un excelente libro sobre las pruebas del software, seguimiento hasta 10s requisitos del cliente. Como
Glen Myers [MYE79] establece varias normas que pue- hemos visto, el objetivo de las pruebas del software
den servir acertadamente como objetivos de las pruebas: es descubrir errores. Se entiende que 10s defectos mas
1. La prueba es el proceso de ejecuci6n de un programa graves (desde el punto de vista del cliente) son aque-
con la intenci6n de descubrir un error. 110s que impiden a1 programa cumplir sus requisitos.
I Aqui se presenta solo un pequeAo subconjunto de 10s principios de

ingenieria de pruebas de Davis. Para obtener mas information, vea
[DAV96].
CAPfTULO 17 T e C N I C A S DE PRUEBA DEL S O F T W A R E
Las pruebas deberian planijicarse mucho antes de La facilidad de prueba del software es simplemente la
que empiecen. La planificaci6n de las pruebas (Capi- facilidad con la que se puede probar un programa de com-
tulo 18) pueden empezar tan pronto como estC computadora. Como la prueba es tan profundamente dificil,
pleto el modelo de requisitos. La definici6n detallada merece la pena saber quC se puede hacer para hacerlo rnis
de 10s casos de prueba puede empezar tan pronto sencillo. A veces 10s programadores estiin dispuestos a
como el modelo de disefio se ha consolidado. Por hacer cosas que faciliten el proceso de prueba y una lista
tanto, se pueden planificar y diseiiar todas las prue- de comprobaci6n de posibles puntos de disefio, caracte-
bas antes de generar ning6n c6digo. nsticas, etc., puede ser fitil a la hora de negociar con ellos.
El principio de Pareto es aplicable a la prueba del
software. Dicho de manera sencilla, el principio de
Pareto implica que a1 80 por 100 de todos 10s erro-
res descubiertos durante las pruebas se les puede
hacer un seguimiento hasta un 20 por 100 de todos Un util documento titulado ((Perfeccionondo la facilidad
10s m6dulos del programa. El problema, por de la pruebo del sohare)) puede enconharse en:
supuesto, es aislar estos m6dulos sospechosos y pro- www.s~bs.tom/newsletters/testnet/docs/testahT~htm.
barlos concienzudamente.
Las pruebas deberian empezar por <<lo pequefio>>y Existen, de hecho, metricas que podrian usarse para
progresar hacia <<lo grande>>.Las primeras pruebas medir la facilidad de prueba en la mayona de sus aspec-
tos. A veces, la facilidad de prueba se usa para indicar
planeadas y ejecutadas se centran generalmente en
m6dulos individuales del programa. A medida que lo adecuadamente que un conjunto particular de prue-
avanzan las pruebas, desplazan su punto de mira en bas va a cubrir un producto. TambiCn es empleada por
10s militares para indicar lo ficil que se puede compro-
un intento de encontrar errores en grupos integrados
de m6dulos y finalmente en el sistema entero (Capi- bar y reparar una herramienta en plenas maniobras. Esos
tulo 18). dos significados no son lo mismo que xfacilidad de prue-
ba del software>>.La siguiente lista de comprobaci6n
No son posibles las pruebas exhaustivas. El n6mero proporciona un conjunto de caracteristicas que llevan a
de permutaciones de caminos para incluso un pro- un software ficil de probar.
grama de tamafio moderado es excepcionalmente
grande (vea la Secci6n 17.2 para un estudio mis Operatividad. <<Cuantomejor funcione, rnis efi-
avanzado). Por este motivo, es imposible ejecutar cientemente se puede probar.>>
todas las combinaciones de caminos durante las prue- El sistema tiene pocos errores (10s errores afiaden
bas. Es posible, sin embargo, cubrir adecuadamente sobrecarga de anilisis y de generaci6n de informes
la 16gica del programa y asegurarse de que se han a1 proceso de prueba).
aplicado todas las condiciones en el disefio a nivel Ningun error bloquea la ejecuci6n de las pruebas
de componente.
El producto evoluciona en fases funcionales (per-
Para ser mas eficaces, las pruebas deberian ser rea-
mite simultanear el desarrollo y las pruebas).
lizadas por un equipo independiente. Por <<masefi-
caces>>queremos referimos a pruebas con la rnis alta Observabilidad. <<Loque ves es lo que pruebas.>>
probabilidad de encontrar errores (el objetivo princi- Se genera una salida distinta para cada entrada.
pal de las pruebas). Por las razones que se expusie-
ron anteriormente en este capitulo, y que se estudian Los estados y variables del sistema estin visibles o
con rnis detalle en el Capitulo 18, el ingeniero del se pueden consultar durante la ejecuci6n.
software que cre6 el sistema no es el rnis adecuado Los estados y variables anteriores del sistema estin
para llevar a cab0 las pruebas para el software. visibles o se pueden consultar (por ejemplo, regis-
tros de transacci6n).
17.1.3. Facilidad de prueba Todos 10s factores que afectan a 10s resultados estin
En circunstancias ideales, un ingeniero del software visibles.
disefia un programa de computadora, un sistema o un Un resultado incorrecto se identifica ficilmente.
producto con la <<fadidadde prueba>>en mente. Esto Los errores intemos se detectan automiticamente a
permite a 10s encargados de las pruebas diseiiar casos travCs de mecanismos de auto-comprobaci6n.
de prueba rnis ficilmente. Pero, iquC es la c~facilidad
de prueba>>James ~ a c h describe
' la facilidad de prue- Se informa automiticamente de 10s errores intemos.
ba de la siguiente manera: El c6digo fuente es accesible.
Los siguientes parrafos son copynght de James Bach, 1994,y se han

adaptado de una pagina de Internet que aparecio inicialmente en el
grupo de noticias comp.software-eng.Este material se ha usado con
permiso.
INGEN1ERfA DEL SOFTWARE. UN ENFOQUE PRACTICO
La documentaci6n tCcnica esth bien organizada.

La documentaci6n tCcnica es especifica y detallada.
La documentaci6n tCcnica es exacta.
((10facilidod de pruebo)) ocurre como el resultodo de
un buen diseiio. El diseiio de dotos, de lo orquitecturo, Los atributos sugeridos por Bach 10s puede emplear
de 10s interfaces y de 10s componentes de detolle pueden el ingeniero del software para desarrollar una configu-
focilitor la prueba o hacerlo m6s dificil. raci6n del software (por ejemplo, programas, datos y
documentos) que pueda probarse.
Controlabilidad. c<Cuantomejor podamos contro-
lar el software, mas se puede automatizar y optimizar.>> i C u 6 l e s s o n l a s caracteristicas
Todos 10s resultados posibles se pueden generar a d e una cbuenar prueba?
travCs de alguna combinacion de entrada. i Y quC pasa con las pruebas propias? Kaner, Falk y
Todo el c6digo es ejecutable a travCs de alguna com- Nguyen [KAN93] sugieren 10s siguientes atributos de
binaci6n de entrada. una c<buena>> prueba:
El ingeniero de pruebas puede controlar directamente 1. Una buena prueba tiene una alta probabilidad de
10s estados y las variables del hardware y del software. encontrar un error. Para alcanzar este objetivo, el res-
Los formatos de las entradas y 10s resultados son ponsable de la prueba debe entender el software e
consistentes y estructurados. intentar desarrollar una imagen mental de c6mo
podna fallar el software.
Las pruebas pueden especificarse, automatizarse y
2. Una buena prueba no debe ser redundante. El tiempo
reproducirse conveni"dtemente. y 10s recursos para las pruebas son limitados. No hay
Capacidad de descomposicion. <<Controlandoel motivo para realizar una prueba que tiene el mismo
hmbito de las pruebas, podemos aislar mas rhpidamente propdsito que otra. Todas las pruebas deberian tener
10s problemas y llevar a cab0 mejores pruebas de regre- un propdsito diferente (incluso si es sutilmente dife-
si6n.~ rente). Por ejemplo, un m6dulo del software de
El sistema software esth construido con m6dulos HogarSeguro (estudiado en antenores capitulos) esta
independientes. disefiado para reconocer una contrasefia de usuario
Los m6dulos del software se pueden probar inde- para activar o desactivar el sistema. En un esfuerzo
pendientemente por descubrir un error en la entrada de la contrasefia,
el responsable de la prueba disefia una sene de prue-
Simplicidad. cCuanto menos haya que probar, mas
bas que introducen una secuencia de contrasefias. Se
rhpidamente podremos probarlo.>>
introducen contrasefias validas y no validas (secuen-
Simplicidad funcional (por ejemplo, el conjunto de cias de cuatro numeros) en pruebas separadas. Sin
caracteristicas es el minimo necesario para cumplir embargo, cada contrasefia vhlida/no valida deberia
10s requisitos). analizar un mod0 diferente de fallo. Por ejemplo, la
Simplicidad estructural (por ejemplo, la arquitectura contrasefia no valida 1234 no deberia ser aceptada
es modularizada para limitar la propagacih de fallos). por un sistema programado para reconocer 8080 como
Simplicidad del c6digo (por ejemplo, se adopta un la contrasefia correcta. Si 1234 es aceptada, tenemos
estandar de c6digo para facilitar la inspecci6n y el presente un error. Otra prueba, digamos 1235, tendria
mantenimiento). el mismo propdsito que 1234 y es, por tanto, redun-
Estabilidad. c<Cuantomenos cambios, menos inte- dante. Sin embargo, la entrada no vhlida 808 1 u 8 180
rmpciones a las p r u e b a u tiene una sutil diferencia, intentando demostrar que
Los cambios del software son infrecuentes. existe un error para las contrasefias ccparecidasn per0
no idCnticas a la contrasefia correcta.
Los cambios del software esthn controlados.
3. Una buena prueba deberia ser <<lamejor de la cose-
Los cambios del software no invalidan las pruebas chan [KAN93]. En un grupo de pruebas que tienen
existentes. propdsito similar, las limitaciones de tiempo y recur-
El software se recupera bien de 10s fallos. sos pueden abogar por la ejecuci6n de s610 un sub-
Facilidad de comprension. <<Cuantamas informa- conjunto de estas pruebas. En tales casos, se deberia
ci6n tengamos, mas inteligentes serhn las pruebas.>> emplear la prueba que tenga la mas alta probabili-
El disefio se ha entendido perfectamente. dad de descubrir una clase entera de errores.
Las dependencias entre 10s componentes intemos, 4. Una buena prueba no deberia ser ni demasiado sen-
extemos y compartidos se han entendido perfectamente. cilla ni demasiado compleja. Aunque es posible a
veces combinar una sene de pruebas en un caso de
Se han comunicado 10s cambios del disefio. prueba, 10s posibles efectos secundarios de este enfo-
La documentaci6n tCcnica es instanthneamente que pueden enmascarar errores. En general, cada
accesible. prueba deberia realizarse separadamente.
La prueba de caja blanca, denominada a veces prueba cedimiento habitual tiende a hacerse m6s comprensi-
de caja de cristal es un mCtodo de disefio de casos de ble (y bien examinado), mientras que el procesamiento
prueba que usa la estructura de control del disefio pro- de cccasos especiales,, tiende a caer en el caos.
cedimental para obtener 10s casos de prueba. Mediante A menudo creemos que un camino 16gico tiene pocas
10s mktodos de prueba de caja blanca, el ingeniero del posibilidades de ejecutarse cuando, de hecho, se
software puede obtener casos de prueba que (1) garan- puede ejecutar de forma normal. El flujo 16gico de
ticen que se ejercita por lo menos una vez todos 10s cami- un programa a veces no es nada intuitivo, lo que sig-
nos independientes de cada m6dulo; (2) ejerciten todas nifica que nuestras suposiciones intuitivas sobre el
las decisiones 16gicas en sus vertientes verdadera y fal- flujo de control y 10s datos nos pueden llevar a tener
sa; (3) ejecuten todos 10s bucles en sus limites y con sus errores de diseiio que s610 se descubren cuando
limites operacionales; y (4) ejerciten las estructuras inter- comienza la prueba del camino.
nas de datos para asegurar su validez. Los errores tipogra&cos son aleatorios. Cuando se
En este momento, se puede plantear un pregunta traduce un programa a codigo fuente en un lenguaje
razonable: ~ P o quC
r emplear tiempo y energia preocu- de programaci6n, es muy probable que se den algu-
pandose de (y probando) las minuciosidades 16gicas nos errores de escritura. Muchos serin descubiertos
cuando podriamos emplear mejor el esfuerzo asegu- por 10s mecanismos de comprobaci6n de sintaxis,
rando que se han alcanzado 10s requisitos del progra- per0 otros permanecerin sin detectar hasta que
ma? 0, dicho de otra forma, ipor quC no empleamos comience la prueba. Es igual de probable que haya
todas nuestras energias en la prueba de caja negra? La un error tipogrifico en un oscuro camino 16gico que
respuesta se encuentra en la naturaleza misma de 10s en un camino principal.
defectos del software (por ejemplo, [JON81]):
Los errores 16gicos y las suposiciones incorrectas son
inversamente proporcionales a la probabilidad de que
se ejecute un camino del programa. Los errores tien-
den a introducirse en nuestro trabajo cuando. diseiia-
mos e implementamos funciones, condiciones o
controles que se encuentran fuera de lo normal. El pro-
La prueba del camino bcisico es una tCcnica de prueba 17.4.1. Notaci6n de grafo de flujo
de caja blanca propuesta inicialmente por Tom McCa- Antes de considerar el mCtodo del camino bisico se
be [MCC76]. El mCtodo del camino basic0 permite a1 debe introducir una sencilla notaci6n para la represen-
disefiador de casos de prueba obtener una medida de la taci6n del flujo de control, denominada grafo de Pujo
complejidad 16gica de un disefio procedimental y usar (o grafo del programa)3.El grafo de flujo representa el
esa medida corno guia para la definici6n de un conjun- flujo de control 16gico mediante la notaci6n ilustrada en
to bcisico de caminos de ejecuci6n. Los casos de prue- la Figura 17.1. Cada construcci6n estructurada (Capi-
ba obtenidos del conjunto bisico garantizan que durante tulo 16) tiene su correspondiente simbolo en el grafo
la prueba se ejecuta por lo menos una vez cada senten- del flujo.
cia del programa.
Construcciones estructurales en forma de grafo de flujo:
Segun-sea
(Case)
Secuencia Si-si-no Mientras Repetir-hasta- que
(If) (While) (Until)
Dibujo un grofo de flujo cuondo lo ldgico de lo estructoro
de control de un mddulo seo complejo. Elgrofo de flojo te
permite trozor mbs fdcilmente 10s cominos del progromo.
Donde cada circulo representa una o mas sentencias, sin bifurcaciones, Para ilustrar el uso de un grafo de flujo, considere-
en LDP o codigo fuente mos la representaci6n del disefio procedimental en la
FIGURA 17.1. Notacion de grafo de flujo. Figura 17.2a. En ella, se usa un diagrama de flujo para
3 Realmente, el rnetodo del carnino bgsico se puede llevar a cab0 sin
usar grafos de flujo. Sin embargo, sirve corno herrarnienta util para
ilustrar el metodo.
representar la estructura de control del programa. En la Cuando en un diseiio procedimental se encuentran
Figura 17.2b se muestra el grafo de flujo correspon- condiciones compuestas, la generation del grafo de flu-
diente a1 diagrama de flujo (suponiendo que no hay con- jo se hace un poco rnhs complicada. Una condici6n com-
diciones compuestas en 10s rombos de decisi6n del puesta se da cuando aparecen uno o rnhs operadores
diagrama de flujo). (OR, AND, NAND, NOR 16gicos)en una sentencia con-
En la Figura 17.2b, cada circulo, denominado nodo dicional. En la Figura 17.3 el segment0 en LDP se tra-
del grafo de flujo, representa una o rnhs sentencias produce en el grafo de flujo anexo. Se crea un nodo aparte
cedimentales. Un solo nodo puede corresponder a una por cada una de las condiciones a y b de la sentencia SI
secuencia de cuadros de proceso y a un rombo de deci- a 0 b. Cada nodo que contiene una condici6n se deno-
sion. Las flechas del grafo de flujo, denominadas aris- mina nodo predicado y esth caracterizado porque dos o
tas o enlaces, representan flujo de control y son mas aristas emergen de 61.
analogas a las flechas del diagrama de flujo. Una aris-
ta debe terminar en un nodo, incluso aunque el nodo
no represente ninguna sentencia procedimental (por
ejemplo, vCase el simbolo para la construction
Si-entonces-si-no). Las keas delimitadas por aristas
y nodos se denominan regiones. Cuando contabiliza- IF ab~
-
mos las regiones incluimos el Area exterior del grafo, Then
contando como otra regi6n mas4 Else procedirniento y
ENDlF
FIGURA 17.3. Logica cornpuesta.
17.4.2. Complejidad ciclomatica

La complejidad ciclomcitica es una mCtrica del softwa-
re que proporciona una medici6n cuantitativa de la com-
plejidad 16gica de un programa. Cuando se usa en el
context0 del mCtodo de prueba del camino bhsico, el
valor calculado como complejidad ciclomhtica define
el niimero de caminos independientes del conjunto bcisi-
co de un programa y nos da un limite superior para el
n6mero de pruebas que se deben realizar para asegurar
11 que se ejecuta cada sentencia a1 menos una vez.
a) Diagrarna de flujo
Un camino independiente es cualquier camino del
programa que introduce, por lo menos, un nuevo con-
junto de sentencias de proceso o una nueva condici6n.
En timinos del grafo de flujo, un camino independiente
esth constituido por lo menos por una arista que no haya
sido recomda anteriormente a la definici6n del camino.
Por ejemplo, para el grafo de flujo de la Figura 17.2b,
un conjunto de caminos independientes seria:
camino 1: 1-11
camino 2: 1-2-3-4-5-10-1-11
camino 3: 1-2-3-6-8-9-10-1-11
camino 4: 1-2-3-6-7-9-10-1-11
Fijese que cada nuevo camino introduce una nueva
arista. El camino
1-2-3-4-5-10-1-2-3-6-8-9-10-1-11
b) Grafo de flujo no se considera un camino independiente, ya que es sim-
plemente una combinaci6n de caminos ya especifica-
FIGURA 17.2. dos y no recorre ninguna nueva arista.
En la Seccion 17.6.1 viene un estudio mas detallado de 10s grafos

y su empleo en las pruebas.
Por tanto, la complejidad ciclomfitica del grafo de

flujo de la Figura 17.2b es 4.
lo complejidodciclom6ticaes uno mbtrico litilpara Es mfis, el valor de V(G) nos da un limite superior
predecir10s modulos que son mbs propensas a error. para el n6mero de caminos independientes que compo-
Puede ser usado tonto para plonificarpruebos mmo nen el conjunto bhsico y, consecuentemente, un valor
para dsedor cosos de prueba. limite superior para el n6mero de pruebas que se deben
disefiar y ejecutar para garantizar que se cubren todas
Los caminos 1,2,3 y 4 definidos anteriormente com- las sentencias del programa.
ponen un conjunto bdsico para el grafo de flujo de la
Figura 17.2b. Es decir, si se pueden diseiiar pruebas que 17.4.3. Obtencion de casos de prueba
fuercen la ejecuci6n de esos caminos (un conjunto bhsi-
co), se garantizarh que se habrh ejecutado a1 menos una El mCtodo de prueba de camino bhsico se puede apli-
car a un diseiio procedimental detallado o a un c6digo
vez cada sentencia del programa y que cada condici6n
se habrh ejecutado en sus vertientes verdadera y falsa. fuente. En esta seccion, presentaremos la prueba del
Se debe hacer hincapiC en que el conjunto bhsico camino bhsico como una serie de pasos. Usaremos el
procedimiento media, representado en LDP en la Figu-
no es 6nico. De hecho, de un mismo disefio procedi-
mental se pueden obtener varios conjuntos bhsicos ra 17.4, como ejemplo para ilustrar todos 10s pasos del
diferentes. mCtodo de diseiio de casos de prueba. Se puede ver que
media, aunque con un algoritmo extremadamente sim-
ple, contiene condiciones compuestas y bucles.
~ C O se~ cilcula
O
la complejidad ciclomitica?
iC6m0 sabemos cuhntos caminos hemos de buscar?

El chlculo de la complejidad ciclomhtica nos da la res-
puesta. La complejidad ciclomhtica esth basada en la
teoria de grafos y nos da una mCtrica del software extre-
madamente titil. La complejidad se puede calcular de
tres formas: 1. Usando el diseiio o el codigo como base, dibujamos
1. El n6mero de regiones del grafo de flujo coincide el correspondiente grafo de flujo. Creamos un grafo
con la complejidad ciclomhtica. usando 10s simbolos y las normas de construcci6n pre-
sentadas en la Secci6n 16.4.1. RefiriCndonos a1 LDP
2. La complejidad ciclomhtica, V(G), de un grafo de de media de la Figura 17.4, se crea un grafo de flujo
flujo G se define como. numerando las sentencias de LDP que aparecerhn en
V(G)=A-N+2 10s correspondientes nodos del grafo de flujo. El corres-
donde A es el n6mero de aristas del grafo de flujo y pondiente grafo de flujo aparece en la Figura 17.5.
N es el ntimero de nodos del mismo.
PROCEDURE media;
3. La complejidad ciclomhtica, V(G), de un grafo de 'Este procedimiento calcula la media de 100 o menos
numeros que se encuentren entre unos limites;
flujo G tambiCn se define como tambien calcula el total de entradas y el total
de numeros validos.
V(G) = P + 1
donde P es el n6mero de nodos predicado conteni- INFERFACE RETURNS media, total. entrada, total. valido;
INTERFACE ACEPTS valor, minimo, maximo;
dos en el grafo de flujo G.
TYPE valor [1:1001 IS SCALAR ARRAY;
TYPE media, total. entrada, total valido;
Minimo, maxlmo, suma IS SCALAR;
TYPE I IS INTEGER;
i=l;
total, entrada =total, valldo = 0
suma = 0;
Lo complejidod ciclomaiico determino el numero DO WHILE VALOR [il e > -999 and total entrada e 100 &-
*-lncrementar total.entrada en 1;
de cosos de pruebo que deben eiecutorse poro gorontizor
que todos las sentencios de un componente
hon sido eiecutodos al menos uno vez. " /IIF valor [i]> = minirno AND valor [i1< = rndxirno
@ [ THEN mcrementar total.vhlido en 1;
suma = suma +valor 111;
ELSE ionorar
'$,
RefiriCndonos de nuevo a1 grafo de flujo de la Figu-

ra 17.2b, la complejidad ciclomhtica se puede calcular
THEN medla = suma/total.val~do;
mediante cualquiera de 10s anteriores algoritmos: ELSE media = -999;
1. el grafo de flujo tiene cuatro regiones END media
2. V(G) = 11 aristas - 9 nodos + 2 = 4 FIGURA 17.4. LDP p a r a diserio d e p r u e b a s c o n n o d o s
3. V(G) = 3 nodos predicado + 1 = 4. n o identificados.
CAPfTULO 17 TECNICAS DE PRUEBA DEL SOFTWARE
Determinamos la complejidad ciclomatica del malmente merece la pena identificar 10s nodos pre-
grafo de flujo resultante. La complejidad ciclomi- dicado para que sea mis ficil obtener 10s casos de
tica, V(G), se determina aplicando uno de 10s algo- prueba. En este caso, 10s nodos 2, 3, 5, 6 y 10 son
ritmos descritos en la Secci6n 17.5.2.. Se debe tener nodos predicado.
en cuenta que se puede determinar V(G) sin desa- 4. Preparamos 10s casos de prueba que forzaran la
rrollar el grafo de flujo, contando todas las senten- ejecucion de cada camino del conjunto basico.
cias condicionales del LDP (para el procedimiento Debemos escoger 10s datos de forma que las condi-
media las condiciones compuestas cuentan como 2) ciones de 10s nodos predicado estCn adecuadamente
y afiadiendo 1. establecidas, con el fin de comprobar cada camino.
En la Figura 17.5, Los casos de prueba que satisfacen el conjunto bisico
V(G) = 6 regiones previamente descrito son:
V(G) = 17 aristas - 13 nodos +2 = 6
Caso de prueba del camino 1:
V(G) = 5 nodos predicado + 1 = 6
valor (k) = entrada vdida, donde k < i definida a con-
tinuaci6n
valor (i) = -999, donde 2 <= i <= 100
resultados esperados: media correcta sobre 10s k
valores y totales adecuados.
Nota: el camino 1 no se puede probar por si solo;
debe ser probado como parte de las pruebas de 10s
caminos 4 , 5 y 6.
man bastante
oro verificar

valor (1) = -999
resultados esperados: media = -999; otros totales
con sus valores iniciales
intento de procesar 101 o mis valores
FIGURA 17.5. Grafo de flujo del procedimiento media. 10s primeros 100 valores deben ser vilidos
resultados esperados: igual que en el caso
3. Determinamos un conjunto basico de caminos de prueba 1
linealmente independientes. El valor de V(G) nos Caso de prueba del camino 4:
da el nlimero de caminos linealmente independien-
tes de la estructura de control del programa. En el valor (i) = entrada vilida donde i < 100
caso del procedimiento media, hay que especificar valor (k) < minimo, para k < i
seis caminos: resultados esperados: media correcta sobre 10s k
camino 1: 1-2-10-11-13 valores y totales adecuados
camino 2: 1-2-10-12-13 Caso de prueba del camino 5:
valor (i) = entrada vdida donde i < 100
camino 3: 1-2-3-10-11-13
valor (k) > miximo, para k <= i
camino 4: 1-2-3-4-5-8-9-2-...
resultados esperados: media correcta sobre 10s n
camino 5: 1-2-3-4-5-6-8-9-2-... valores y totales adecuados
camino 6: 1-2-3-4-5-6-7-8-9-2-... Caso de prueba del camino 6:
Los puntos suspensivos (...) que siguen a 10s valor (i) = entrada vilida donde i < 100
caminos 4 , 5 y 6 indican que cualquier camino del resultados esperados: media correcta sobre 10s n
resto de la estructura de control es aceptable. Nor- valores y totales adecuados
Ejecutamos cada caso de prueba y comparamos 10s recursos requeridos durante el recorrido de un
10s resultados obtenidos con 10s esperados. Una vez enlace.
terminados todos 10s casos de prueba, el responsable Para ilustrarlo, usaremos la forma m6s simple de
de la prueba podra estar seguro de que todas las sen- peso, que indica la existencia de conexiones ( 0 6 1). La
tencias del programa se han ejecutado por lo menos matriz de grafo de la Figura 17.6 se rehace tal y como
una vez. se muestra en la Figura 17.7. Se ha reemplazado cada
Es importante darse cuenta de que algunos cami- letra por un 1, indicando la existencia de una conexi6n
nos independientes (por ejemplo, el camino 1 de (se han excluido 10s ceros por claridad). Cuando se
nuestro ejemplo) no se pueden probar de forma ais- representa de esta forma, la matriz se denomina matriz
lada. Es decir, la combinaci6n de datos requerida de conexiones.
para recorrer el camino no se puede conseguir con
el flujo normal del programa. En tales casos, estos
caminos se han de probar como parte de otra prue- Conectado
ba de camino. \ a l nodo
17.4.4. Matrices de grafos

El procedimiento para obtener el grafo de flujo, e
incluso la determinaci6n de un conjunto de caminos
basicos, es susceptible de ser mecanizado. Para desa-
rrollar una herramienta software que ayude en la prue-
ba del camino basico, puede ser bastante util una
estructura de datos denominada matriz de grafo.
Una matriz de grafo es una matriz cuadrada cuyo
tamaiio (es decir, el ndmero de filas y de columnas)
Grafo de flujo Matriz del grafo
es igual a1 ndmero de nodos del grafo de flujo. Cada
fila y cada columna corresponde a un nodo especifi- FIGURA 17.6. Matriz del grafo.
co y las entradas de la matriz corresponden a las cone-
xiones (aristas) entre 10s nodos. En la Figura 17.6 se
muestra un sencillo ejemplo de un grafo de flujo con En la Figura 17.7, cada fila con dos o m6s entra-
su correspondiente matriz de grafo [BEI90]. das representa un nodo predicado. Por tanto, 10s
En la figura, cada nodo del grafo de flujo esta iden- calculos aritmkticos que se muestran a la derecha de
tificado por un numero, mientras que cada arista lo la matriz de conexiones nos dan otro nuevo mktodo
est6 por su letra. Se sitda una entrada en la matriz por de determinaci6n de la complejidad ciclornatica (Sec-
cada conexi6n entre dos nodos. Por ejemplo, el nodo ci6n 17.4.2).
3 est6 conectado con el nodo 4 por la arista b. Beizer [BE1901 proporciona un tratamiento profun-
do de otros algoritmos matemhticos que se pueden apli-
car a las matrices de grafos. Mediante estas tkcnicas, el
iQue es una matriz analisis requerido para el diseiio de casos de prueba se
de grafos y dmo aplicarla puede automatizar parcial o totalmente.
en la prueba?
Conectado
Hasta aqui, la matriz de grafo no es nada mas que una \ al nodo
representaci6n tabular del grafo de flujo. Sin embargo,
aiiadiendo un peso de enlace a cada entrada de la matriz,
la matriz de grafo se puede convertir en una potente herra-
mienta para la evaluaci6n de la estructura de control del
programa durante la prueba. El peso de enlace nos da
informaci6n adicional sobre el flujo de control. En su for-
ma m6s sencilla, el peso de enlace es 1 (existe una cone-
xi6n) 6 0 (no existe conexibn). A 10s pesos de enlace se
les puede asignar otras propiedades mhs interesantes:
la probabilidad de que un enlace (arista) sea ejecutado; Matriz de grafo
el tiempo de procesamiento asociado a1 recorrido de
un enlace;
1
~orn~lejidad
la memoria requerida durante el recorrido de un ciclornatica
enlace; y FIGURA 17.7. Matriz de conexiones.
C A P ~ T U L O17 T t C N I C A S DE PRUEBA DEL SOFTWARE
La tkcnica de prueba del camino basic0 descrita en la El mktodo de laprueba de condiciones se centra en la
Seccion 17.4 es una de las muchas tkcnicas para la prue- prueba de cada una de las condiciones del programa. Las
ba de la estructura de control. Aunque la prueba del estrategias de prueba de condiciones (tratadas posterior-
camino basic0 es sencilla y altamente efectiva, no es mente en este capitulo) tienen, generalmente, dos venta-
suficiente por si sola. En esta secci6n se tratan otras jas. La primera, que la cobertura de la prueba de una
variantes de la prueba de estructura de control. Estas condicion es sencilla. La segunda, que la cobertura de la
variantes amplian la cobertura de la prueba y mejoran prueba de las condiciones de un programa da una orien-
la calidad de la prueba de caja blanca. tacion para generar pruebas adicionales del programa.
El proposito de la prueba de condiciones es detectar,
17.5.1. Prueba de condicion5 no solo 10s errores en las condiciones de un programa,
sino tarnbiCn otros errores en dicho programa. Si un con-
junto de pruebas de un programa P es efectivo para
detectar errores en las condiciones que se encuentran
en P, es probable que el conjunto de pruebas tambiCn sea
10s errores son mucho m6s comunes en el entorno efectivo para detectar otros errores en el programa P.
de los condiciones 16gicos que en 10s sentencios de Ademits, si una estrategia de prueba es efectiva para
proceso secuenciol. detectar errores en una condicion, entonces es probable
que dicha estrategia tambiCn sea efectiva para detectar
errores en el programa.
La pr-ueba de condicidn es un metodo de diseRo de Se propuesto una serie de estrategias de prueba
casos de prueba que ejercita las condiciones logicas de condiciones. La prueba de ram~cacioneses, posi-
contenidas en el modulo de un programs. Una condi- blemente, la estrategia de pmeba de condiciones mls
cion simple es una variable logica o una expresion sencilla. Para una condici6n compuesta C, es necesario
relacional. posiblemente precedida 'On un 'perador ejec-tar a1 menos una vez las ramas verdadera y falsa
NOT (<<in).Una expresi6n relacional toma la siguien- de cads condici6n simple de [MYE79].
te forma
El < operador-relational> E,
QoNsEIos
donde El y E, son expresiones aritmkticas y <opera-
dor-relacionab puede ser alguno de 10s siguientes: <<<>>, Coda vez que decides efectuor uno pruebo de condition,
<<<=>>,<<=>>,<<ZD(<<=>> desigualdad), K>D,o <<>=>>. Una deberos evoluor coda condicih en un intento
condicidn compuesta esta formada por dos o mas con- por descubrir errores. j Este es un escondrijo ideal
poro 10s errores!
diciones simples, operadores 16gicos y parentesis. Supo-
nemos que 10s operadores logicos permitidos en una
condici6n compuesta incluyen OR (<<I>>), AND (&D) y La prueba del dominio [WHISO] requiere la realiza-
NOT (KT>>). A una condicion sin expresiones relacio- ci6n de tres o cuatro pruebas para una expresi6n rela-
nales se la denomina Expresidn Idgica. cional. Para una expresi6n relacional de la forma
Por tanto, 10s tipos posibles de componentes en una
condicih pueden ser: un operador 16gic0, una variable
logics, un par de parkntesis 16gicos (que rodean a una se requieren tres pruebas, para comprobar que el valor
condicion simple o compuesta), un operador relacional de El es mayor, igual o menor que el valor de E,, res-
o una expresi6n aritmktica. pectivamente [HOW82]. Si el <operanor-relacionab
Si una condici6n es incorrecta, entonces es inco- es incorrect0 y El y E, son correctos, entonces estas tres
rrecto a1 menos un componente de la condici6n. Asi, pruebas garantizan la detecci6n de un error del opera-
10s tipos de errores de una condici6n pueden ser 10s dor relacional. Para detectar errores en El y E,, la prue-
siguientes: ba que haga el valor de El mayor o menor que el de E,
error en operador 16gico (existencia de operadores debe hacer que la diferencia entre estos dos valores sea
logicos incorrectos/desaparecidos/sobrantes) lo mas pequefia posible.
Para una expresi6n 16gica con n variables, habra que
error en variable 16gica
realizar las 2" pruebas posibles (n > 0). Esta estrategia
error en parkntesis logico puede detectar errores de un operador, de una variable
error en operador relacional y de un parCntesis 16gic0, per0 so10 es practica cuando
error en expresion aritmktica. el valor de n es pequeiio.
%as secciones 17.5.1. y 17.5.2. s e han adaptado de [TAI89] con per-

miso del profesor K.C. Tai.
INGENIERfA DEL SOFTWARE. UN ENFOOUE PRhCT1CO
TambiCn se pueden obtener pruebas sensibles a error cional, podemos construir un conjunto de restricciones
para expresiones ldgicas [FOS84, TAI871. Para una para C, mediante la modificaci6n del conjunto de res-
expresi6n 16gica singular (una expresi6n 16gica en la tricciones {(v,v), (f, v), (v, f)) definido para C,. ObsCr-
cual cada variable 16gica s610 aparece una vez) con n vese que ~ v >para> (E, = E,) implica <<=>> y que ~ f para
n
variables Mgicas (n > 0), podemos generar ficilmente (E, = E,) implica <<<DO <OD. A1 reemplazar (v, v) y (f,
un conjunto de pruebas con menos de 2" pruebas, de tal v) por (v, =) y (f, =), respectivamente y reemplazando
forma que ese grupo de pruebas garantice la detecci6n (v, f) por (v, <) y (v,>), el conjunto de restricciones resul-
de m6ltiples errores de operadores 16gicos y tambiCn tante para C, es {(v,=), (f, =), (v, <), (v, >)}.Lacobertura
sea efectivo para detectar otros errores. del conjunto de restricciones anterior garantimi la detec-
Tai [TAN91 sugiere una estrategia de prueba de ci6n de errores del operador relacional o 16gico en C,.
condiciones que se basa en las tCcnicas destacadas Como tercer ejemplo, consideremos una condici6n
anteriormente. La tkcnica, denominada BRO* @rue- de la forma
ba del operador relacional y de ramificaci6n garan-
tiza la detecci6n de errores de operadores relacionales
y de ramificaciones en una condici6n dada, en la que donde El, E,, E, y E, son expresiones aritmkticas. Una
todas las variables 16gicas y operadores relacionales restricci6n de condicidn para C, es de la forma (Dl,
de la condici6n aparecen s610 una vez y no tienen D,), donde todos 10s Dl y D, son >, = o <. Puesto que
variables en com6n. C, es igual que C, excepto en que la primera condi-
La estrategia BRO utiliza restricciones de condition ci6n simple de C, es una expresi6n relacional, pode-
para una condici6n C. Una restricci6n de condici6n para mos construir un conjunto de restricciones para C,
C con n condiciones simples se define como (Dl, mediante la modificaci6n del conjunto de restriccio-
D,,...,D,), donde Di (0 < i I n) es un simbolo que espe- nes para C,, obteniendo
cifica una restriction sobre el resultado de la i-Csima
condici6n simple de la condici6n C. Una restricci6n de
condici6n D para una condicibn C se cubre o se trata en La cobertura de este conjunto de restricciones garan-
una ejecucibn de C, si durante esta ejecuci6n de C, el tizari la detecci6n de errores de operador relacional
resultado de cada condici6n simple de C satisface la res- en C,.
tricci6n correspondiente de D.
Para una variable 16gica B, especificamos una res- 17.5.2. Prueba del flujo d e datos
tricci6n sobre el resultado de B, que consiste en que B El mCtodo deprueba deJlujo de datos selecciona cami-
tiene que ser verdadero (v) o falso (f). De forma simi-
nos de prueba de un programa de acuerdo con la ubi-
lar, para una expresi6n relacional, se utilizan 10s sim- caci6n de las definiciones y 10s usos de las variables del
bolos >, = y < para especificar restricciones sobre el programa. Se han estudiado y comparado varias estra-
resultado de la expresi6n.
tegias de prueba de flujo de datos (por ejemplo,
Como ejemplo, consideremos la condici6n
[FRA88], [NTA88], [FRA93]).
C, : B,& B2 Para ilustrar el enfoque de prueba de flujo de datos,
supongamos que a cada sentencia de un programa se le
donde B, y B, son variables 16gicas. La restricci6n de
condici6n para C, es de la forma (Dl, D,), donde Dl y asigna un n6mero 6nico de sentencia y que las funcio-
nes no modifican sus parimetros o las variables globa-
~ . valor (v, f) es una restricci6n de
D, son <<vno < < f El
les. Para una sentencia con S como numero de sentencia,
condici6n para C, y se cubre mediante la prueba que
hace que el valor de B, sea verdadero y el valor de B, DEF(S) = {XI la sentencia S contiene una definici6n
sea falso. La estrategia de prueba BRO requiere que el deX }
conjunto de restricciones {(v, v), (f, v), (v, f)} sea USO(S) = { XI la sentencia S contiene un uso de X )
cubierto mediante las ejecuciones de C,. Si C, es inco-
rrecta por uno o mis errores de operador 16gic0, por lo Si la sentencia S es una sentencia ifo de bucle, su con-
menos un par del conjunto de restricciones forzari el junto DEF estari vacio y su conjunto USE estari basa-
fa110 de C,. do en la condici6n de la sentencia S. La definicih de una
Como segundo ejemplo, consideremos una condi- variable X en una sentencia S se dice que esti viva en una
ci6n de la forma sentencia S' si existe un camino de la sentencia S a la sen-
tencia S' que no contenga otra definici6n de X.
C, : B , & (E, = E4)
donde B, es una expresi6n 16gica y E, y E, son expre-
siones aritmkticas. Una restricci6n de condici6n para C,
es de la forma (Dl, D,), donde Dl es ~ v >o >ccfn y D, es
Es poco reolisto osumir que lo pruebo del flujo de dotos
>, = o <. Puesto que C, es igual que C,, excepto en que
puede ser usodo ompliomente cuondi probomos grondes
la segunda condicih simple de C, es una expresi6n rela- sisternos. En cuolquier coso, puede ser utilizodo en oreos
' En ingles, Branch and Relational Operator. del s o h r x e que seon sospechosos.
CAPtTULO 17 T F C N I C A S DE PRUEBA DEL SOFTWARE
Una cadena de defrnicidn-uso (o cadena DU) de una otras cadenas DU se pueden cubrir haciendo que esos
variable X tiene la forma [X, S, S'], donde S y S' son cinco caminos contengan iteraciones del bucle.
numeros de sentencia, X esta en DEF(S) y en USO(S') Dado que las sentencias de un programa estAn rela-
y la definici6n de X en la sentencia S estA viva en la sen- cionadas entre side acuerdo con las definiciones de las
tencia S'. variables, el enfoque de prueba de flujo de datos es efec-
Una sencilla estrategia de prueba de flujo de datos tivo para la protecci6n contra errores. Sin embargo, 10s
se basa en requerir que se cubra a1 menos una vez cada problemas de medida de la cobertura de la prueba y de
cadena DU. Esta estrategia se conoce como estrategia selecci6n de caminos de prueba para la prueba de flujo
de prueba DU. Se ha demostrado que la prueba DU no de datos son mhs dificiles que 10s correspondientes pro-
garantiza que se cubran todas las ramificaciones de un blemas para la prueba de condiciones.
programa. Sin embargo, solamente no se garantiza el
cubrimiento de una ramificaci6n en situaciones raras 17.5.3. Prueba d e bucles
como las construcciones when-else en las que la par-
te then no tiene ninguna definici6n de variable y no exis- Los bucles son la piedra angular de la inmensa mayo-
te la parte else. En esta situacidn, la prueba DU no cubre ria de 10s algoritmos implementados en software. Y sin
necesariamente la rama else de la sentencia if superior. embargo, les prestamos normalmente poca atenci6n
Las estrategias de prueba de flujo de datos son 6ti- cuando llevamos a cab0 las pruebas del software.
les para seleccionar caminos de prueba de un programa
que contenga sentencias $ 0 de bucles anidados. Para
ilustrar esto, consideremos la aplicaci6n de la prueba
DU para seleccionar caminos de prueba para el LDP 10s estructuros de bucles complejos es otro lugor
que sigue: propenso o errores. Por tonto, es muy volioso reolizor
diseios de pruebos que ejerciten mmpletomente
proc x 10s estructuros bude.
B1:
d o w h i l e C1 La prueba de bucles es una tCcnica de prueba de caja
i f C2 blanca que se centra exclusivamente en la validez de las
then construcciones de bucles. Se pueden definir cuatro cla-
i f C4 ses diferentes de bucles [BEI90]: bucles simples, bucles
then B4;
concatenados, bucles anidados y bucles no estructura-
else B5;
dos (Fig. 17.8).
endif ; Bucles simples.A 10s bucles simples se les debe apli-
else car el siguiente conjunto de pruebas, donde n es el
i f C3 n6mero mhximo de pasos permitidos por el bucle:
then b2; 1. pasar por alto totalmente el bucle
else B3; 2. pasar una sola vez por el bucle
e n d i f; 3. pasar dos veces por el bucle
e n d i f; 4. hacer m pasos por el bucle con m < n
enddo; 5. hacer n - 1, n y n+l pasos por el bucle
B6;
end proc;
Para aplicar la estrategia de prueba DU para seleccio-

nar caminos de prueba del diagrama de flujo de control,
necesitamos conocer las definiciones y 10s usos de las
variables de cada condici6n o cada bloque del LDP. Asu-
mimos que la variable X es definida en la 6ltima sen-
tencia de 10s bloques B 1, B2, B3, B4 y B5, y que se usa
en la primera sentencia de 10s bloques B2, B3, B4, B5
y B6. La estrategia de prueba DU requiere una ejecu-
ci6n del camino m b corto de cada Bi, 0 < i 5 5, a cada Bucles Bucles
Bj, l<j I 6. (Tal prueba tambiCn cubre cualquier uso de simples anidados
la variablex en las condiciones C1, C2, C3 y C4). Aun- Bucles
que hay veinticinco cadenas DU de la variable X, s610 concatenados
necesitamos cinco caminos para cubrir la cadena DU. Bucles no
La raz6n es que se necesitan cinco caminos para cubrir estructurados
la cadena DU de X desde Bi, 0 < i I 5, hasta B6, y las FIGURA 17.8. Clases de bucles.
Bucles anidados. Si extendikramos el enfoque de prue- Bucles concatenados. Los bucles concatenados se
.bade 10s bucles simples a 10s bucles anidados, el numero pueden probar mediante el enfoque anteriormente defi-
de posibles pruebas aumentaria geomCtricarnentea medi- nido para 10s bucles simples, mientras cada uno de 10s
da que aumenta el nivel de anidarniento. Esto llevaria a bucles sea independiente del resto. Sin embargo, si
un numero impracticable de pruebas. Beizer BE1901 suge- hay dos bucles concatenados y se usa el controlador
re un enfoque que ayuda a reducir el numero de pruebas: del bucle 1 como valor inicial del bucle 2, entonces
1. Comenzar por el bucle mhs interior. Establecer o con- 10s bucles no son independientes. Cuando 10s bucles
figurar 10s demhs bucles con sus valores minimos. no son independientes, se recomienda usar el enfoque
2. Llevar a cab0 las pruebas de bucles simples para el aplicado para 10s bucles anidados.
bucle m6s interior, mientras se mantienen 10s p a r h e -
tros de iteration (por ejemplo, contador del bucle) de
10s bucles externos en sus valores minimos. Aiiadir QoNswos
otras pruebas para valores fuera de rango o excluidos. No debes probor 10s bucles no estructvrados. Rediseiolos.
3. Progresar hacia fuera, llevando a cab0 pruebas para
el siguiente bucle, per0 manteniendo todos 10s bucles Bucles no estructurados. Siempre que sea posi-
externos en sus valores minimos y 10s demhs bucles ble, esta clase de bucles se deben redisefiar para que
anidados en sus valores cctipicos>>. se ajusten a las construcciones de programacion
4. Continuar hash que se hayan probado todos 10s bucles. estructurada (Capitulo 16).
Las pruebas de caja negru, tambiCn denominada prue- ~ E els sistema particularmente sensible a ciertos valo-
ha de conlportamiento, se centran en 10s requisitos fun- res de entrada?
cionales del software. 0 sea, la prueba de caja negra iDe quC forma esthn aislados 10s limites de una clase
permite a1 ingeniero del software obtener conjuntos de de datos?
condiciones de entrada que ejerciten completamente ~ Q u Cvollimenes y niveles de datos tolerarh el sis-
todos 10s requisitos funcionales de un programa. La
prueba de caja negra no es una alternativa a las tecni- tema?
cas de prueba de caja blanca. Mhs bien se trata de un ~ Q u Cefectos sobre la operaci6n del sistema tendrhn
enfoque complementario que intenta descubrir diferen- combinaciones especificas de datos?
tes tipos de errores que 10s mktodos de caja blanca. Mediante las tecnicas de prueba de caja negra se
La prueba de caja negra intenta encontrar errores de obtiene un conjunto de casos de prueba que satisfa-
las siguientes categorias: (1) funciones incorrectas o cen 10s siguientes criterios [MYE79]: (1) casos de
ausentes, (2) errores de interfaz, (3) errores en estruc- prueba que reducen, en un coeficiente que es mayor
turas de datos o en accesos a bases de datos externas, que uno, el numero de casos de prueba adicionales
(4) errores de rendimiento y (5) errores de inicializa- que se deben disefiar para alcanzar una prueba razo-
cion y de termination. nable y (2) casos de prueba que nos dicen algo sobre
A diferencia de la prueba de caja blanca, que se Ile- la presencia o ausencia de clases de errores en lugar
va a cab0 previamente en el proceso de prueba, la prue- de errores asociados solamente con la prueba que esta-
ba de caja negra tiende a aplicarse durante fases mos realizando.
posteriores de la prueba (vCase el Capitulo 18).Ya que
ia prueba de caja negra ignora intekionadament; la 17.6.1. Metodos de prueba basados en grafos
estructura de control, centra su atenci6n en el campo de
la informacion. Las pruebas se diseiian para responder El primer paso en la prueba de caja negra es entender
a las siguientes preguntas: 10s objetos6 que se modelan en el software y las rela-
ciones que conectan a estos objetos. Una vez que se ha
iC6m0 se prueba la validez funcional?
llevado a cab0 esto, el siguiente paso es definir una serie
iC6m0 se prueba el rendimiento y el comportamiento de pruebas que verifiquen que ~ t o d o 10s
s objetos tienen
del sistema? entre ellos las relaciones esperadaw [BEI95]. Dicho de
~ Q u Cclases de entrada compondrh unos buenos otra manera, la prueba del software empieza creando un
casos de prueba? grafo de objetos importantes y sus relaciones, y despuCs
6 ~ este'contexto,
n el tkrmino ((objeto))comprende 10s objetos de datos
que se estudiaron en 10s Capitulos 1 1 y 12 asi como objetos de pro-
grama tales como modulos o colecciones de sentencias del lenguaje
de programacion.
CAPfTULO 17 T P C N I C A S DE PRUEBA DEL SOFTWARE
disefiando una serie de pruebas que cubran el grafo de Como se muestra en la figura, una seleccion del
manera que se ejerciten todos 10s objetos y sus relacio- menu en archivo nuevo genera una ventana del docu-
nes para descubrir 10s errores. mento. El peso del nodo de ventana del documento
proporciona una lista de 10s atributos de la ventana que
se esperan cuando se genera una ventana. El peso del
enlace indica que la ventana se tiene que generar en
menos de 1.0 segundos. Un enlace no dirigido esta-
Un grofo represento lo relocion entre obieto doto y objeto blece una relacion simCtrica entre seleccion en el menu
progromo, permitiendonos derivor cosos de pruebo
de archivo nuevo y texto del documento, y 10s enla-
que buscon errores osociodos con estos relociones.
ces paralelos indican las relaciones entre la ventana
del documento y el texto del documento. En reali-
dad, se deberia generar un grafo bastante mAs detalla-
do como precursor a1 disefio de casos de prueba. El
ingeniero del software obtiene entonces casos de prue-
ba atravesando el grafo y cubriendo cada una de las
relaciones mostradas. Estos casos de prueba estfin dise-
fiados para intentar encontrar errores en alguna de las
relaciones.
a) ~ o t a c i 6 d grafo
e Beizer [BE1951 describe un n6mero de mCtodos de
prueba de comportamiento que pueden hacer uso de 10s
Nuevo La selecclon ael menu genera de grafos:
archivo )(tiempo de gcndracibn r 1.0 seg.i$ocumen
Modelado del flujo de transaccidn. Los nodos
representan 10s pasos de alguna transaccion (por
Se representa como Dimensiones de inicio:
m ejemplo, 10s pasos necesarios para una reserva en una
o ~referencias linea aCrea usando un servicio en linea), y 10s enla-
w
b) Un sencillo eiemplo
Color
predeterminadas
de fondo: blanco
Color del texto:
ces representan las conexiones logicas entre 10s pasos
(por ejemplo, vuelo.informacidn.entradaes seguida
color o preferencias de validacidnldisponibilidad.procesamiento).El dia-
predeterminadas grama de flujo de datos (Capitulo 12) puede usarse
para ayudar en la creacion de grafos de este tipo.
Para llevar a cab0 estos pasos, el ingeniero del soft- Modelado de estadofinito. Los nodos representan
ware empieza creando un grafo -una coleccion de nodos diferentes estados del software observables por el
que representan objetos; enlaces que representan las rela- usuario (por ejemplo, cada una de las <<pantallas>>que
ciones entre 10s objetos; pesos de nodos que describen las aparecen cuando un telefonista coge una peticion por
propiedades de un nodo (por ejemplo, un valor especifi- telCfono), y 10s enlaces representan las transiciones
co de datos o comportamiento de estado) y pesos de enla- que ocurren para moverse de estado a estado (por
ces que describen alguna caracten'stica de un e n l a c e 7 . ejemplo, peticidn-informacibn se verifica durante
En la Figura 17.9a se muestra una representacion inventario-disponibilidad-bhqueday es seguido por
simbolica de un grafo. Los nodos se representan como cliente-factura-informacidn-entrada). El diagrama
circulos conectados por enlaces que toman diferentes for- estado-transition (Capitulo 12) puede usarse para
mas. Un enlace dirigido (representado por una flecha) ayudar en la creation de grafos de este tipo.
indica que una relacion se mueve so10 en una direccion. Modelado del flujo de datos. Los nodos son
Un enlace bidireccional, tambiCn denominado enlace objetos de datos y 10s enlaces son las transforma-
simktrico, implica que la relaci6n se aplica en ambos sen- ciones que ocurren para convertir un objeto de
tidos. Los enlaces paralelos se usan cuando se establecen datos en otro. Por ejemplo, el nodo FICA.impues-
diferentes relaciones entre 10s nodos del grafo. to.retenido (FIR) se calcula de brutos.sueldos
Como ejemplo sencillo, consideremos una parte de (BS) usando la relacion FIR = 0,62 X BS.
un grafo de una aplicacion de un procesador de texto Modelado de planificacidn. Los nodos son obje-
(Fig. 17.9b) donde: tos de programa y 10s enlaces son las conexiones
objeto n." 1 = seleccion en el menu de archivo nuevo secuenciales entre esos objetos. Los pesos de enla-
objeto n . 9 = ventana del documento ce se usan para especificar 10s tiempos de ejecucion
objeto n." 3 = texto del documento requeridos a1 ejecutarse el programa.
7Si10s conceptos anteriores suenan vagamente familiares, recordemos grama) caracterizadoscomo representacionesde diserio procedimen-
que 10s grafos se usaron tambien en la Secci6n 17.4.1 para crear un tal o como c6digo fuente y 10s enlaces dirigidos indicaban el tlujo de
grafo del programa para el metodo de la prueba del camino basico. Los control entre estos objetos del prograrna. Aqui se extiende el uso de 10s
nodos del grafo del programa contenian instrucciones (objetosde pro- grafos para incluir la prueba de caja negra.
Un estudio detallado de cada uno de estos mCtodos de no se puede usar UNDO) debenan apuntarse. Final-
de prueba basados en grafos esta mas alla del alcance mente, todos 10s nodos del grafo deberian tener una rela-
de este libro. El lector interesado deberia consultar ci6n que 10s lleve de vuelta a ellos mismos; en esencia,
[BE1951 para ver un estudio detallado. Merece la pena, un bucle de <<noacci6n>>o ocaccion nula>>.Estas relacio-
sin embargo, proporcionar un resumen genCrico del nes rejexivas debenan probarse tambiCn.
enfoque de pruebas basadas en grafos. Cuando empieza el disefio de casos de prueba, el pri-
mer objetivo es conseguir la cobertura de nodo. Esto sig-
tCuales son las actividades nifica que las pruebas debenan disefiarse para demostrar
generales requeridas que ningun nodo se ha omitido inadvertidamente y que
durante la prueba basada 10s pesos de nodos (atributos de objetos) son correctos.
en un grafo? A continuation, se trata la cobertura de enlaces. Todas
las relaciones se prueban basandose en sus propiedades.
Las pruebas basadas en grafos empiezan con la defi- Por ejemplo, una relacion simCtrica se prueba para
nici6n de todos 10s nodos y pesos de nodos. 0 sea, se demostrar que es, de hecho, bidireccional. Una relacidn
identifican 10s objetos y 10s atributos. El modelo de datos transitiva se prueba para demostrar que existe transiti-
(Capitulo 12) puede usarse como punto de partida, per0 vidad. Una relacion reflexiva se prueba para asegurarse
es importante tener en cuenta que muchos nodos puede que hay un bucle nulo presente. Cuando se han espe-
den ser objetos de programa (no representados explici- cificado 10s pesos de enlace, se disefian las pruebas para
tamente en el modelo de datos). Para proporcionar una demostrar que estos pesos son vilidos. Finalmente, se
indicacion de 10s puntos de inicio y final del grafo, es invocan las pruebas de bucles (Seccion 17.5.3).
util definir unos nodos de entrada y salida.
Una vez que se han identificado 10s nodos, se debe- 17.6.2. Partici6n equivalente
rian establecer 10s enlaces y 10s pesos de enlaces. En
general, conviene nombrar 10s enlaces, aunque 10s enla- Laparticidn equivalente es un mCtodo de prueba de caja
ces que representan el flujo de control entre 10s objetos negra que divide el campo de entrada de un programa
de programa no es necesario nombrarlos. en clases de datos de 10s que se pueden derivar casos
En muchos casos, el modelo de grafo puede tener de prueba. Un caso de prueba ideal descubre de forma
bucles (por ejemplo, un camino a travCs del grafo en el inmediata una clase de errores (por ejemplo, proceso
que se encuentran uno o mas nodos mas de una vez). La incorrect0 de todos 10s datos de caracter) que, de otro
prueba de bucle (Seccion 17.5.3) se puede aplicar tarn- modo, requerinan la ejecucion de muchos casos antes
biCn a nivel de comportamiento (de caja negra). El grafo de detectar el error genCrico. La particion equivalente
se dirige a la definici6n de casos de prueba que descu-
ayudara a identificar aquellos bucles que hay que probar.
Cada relacion es estudiada separadamente, de mane- bran clases de errores, reduciendo asi el numero total
ra que se puedan obtener casos de prueba. La transiti- de casos de prueba que hay que desarrollar.
vidad de relaciones secuenciales es estudiada para
determinar c6mo se propaga el impact0 de las relacio-
nes a travCs de objetos definidos en el grafo. La transi-
10s closes de entrodo son conocidos relotivomente
tividad puede ilustrarse considerando tres objetos X,Y
temprono en el proceso de sohare. for esio rozan,
y Z. Consideremos las siguientes relaciones: comenzomas pensondo en lo pom'ci6n equivolente
X es necesaria para calcular Y uno vez el disedo ha sido creodo.
Y es necesaria para calcular Z
Por tanto, se ha establecido una relacion transitiva El disefio de casos de prueba para la particion equi-
valente se basa en una evaluaci6n de las clases de equi-
entre X y Z:
valencia para una condicion de entrada. Mediante
X es necesaria para calcular Z conceptos introducidos en la seccidn anterior, si un con-
Basandose en esta relacion transitiva, las pruebas junto de objetos puede unirse por medio de relaciones
para encontrar errores en el calculo de Z deben consi- simCtricas, transitivas y reflexivas, entonces existe una
derar una variedad de valores para X e Y. clase de equivalencia [BEI95]. Una clase de equivalen-
La simetria de una relacidn (enlace de grafo) es tam- cia representa un conjunto de estados validos o no vali-
biCn una importante directriz para disefiar casos de prue- dos para condiciones de entrada. Tipicamente, una
ba. Si un enlace es bidireccional (simCtrico),es importante condici6n de entrada es un valor numCrico especifico, un
probar esta caracteristica. La caracteristica UNDO rango de valores, un conjunto de valores relacionados o
[BE1951 (deshacer) en muchas aplicaciones para orde- una condicih logica. Las clases de equivalencia se pue-
nadores personales implementa una limitada simetria. Es den definir de acuerdo con las siguientes directrices:
decir, UNDO permite deshacer una accion despuCs de 1. Si una condicion de entrada especifica un rango,
haberse completado. Esto debena probarse minuciosa- se define una clase de equivalencia valida y dos no
mente y todas las excepciones (por ejemplo, lugares don- validas.
CAPfTULO 17 TBCNICAS DE PRUEBA DEL SOFTWARE
Si una condici6n de entrada requiere un valor espe- prueba. El anhlisis de valores limite nos lleva a una
cifico, se define una clase de equivalencia vhlida y elecci6n de casos de prueba que ejerciten 10s valores
dos no validas. limite.
Si una condici6n de entrada especifica un miembro
de un conjunto, se define una clase de equivalencia
vhlida y una no vrilida.
Si una condici6n de entrada es ldgica, se define una AVL ornplio lo portici6n equivalente poro fijorse sobre
clase de equivalencia valida y una no vrilida. dotos en el ((lirnite)) de uno close de equivolencio.
Como ejemplo, consideremos 10s datos contenidos en
una aplicaci6n de automatizaci6n bancaria. El usuario El anhlisis de valores limite es una tCcnica de dise-
puede cdlamaru a1 banco usando su ordenador personal, fio de casos de prueba que complernenta a la partici6n
dar su contraseiia de seis digitos y continuar con una sene equivalente. En lugar de seleccionar cualquier elemen-
de 6rdenes tecleadas que desencadenarhn varias funcio- to de una clase de equivalencia, el AVL lleva a la elec-
nes bancarias. El software proporcionado por la aplica- ci6n de casos de prueba en 10s ccextremos>> de la clase.
ci6n bancaria acepta datos de la siguiente forma: En lugar de centrarse solamente en las condiciones de
C6digo de Area: en blanco o un numero de tres digitos entrada, el AVL obtiene casos de prueba tambiCn para
Prefijo: numero de tres digitos que no comience por el campo de salida [MYE79].
00 1
i Como se trean tasos
Sufijo: numero de cuatro digitos
de prueba para el AVL?
Contrasefia: valor alfanumCrico de seis digitos
0rdenes: cccomprobar>>, ccdepositar>>,ccpagar factu- Las directrices de AVL son similares en muchos
ra>>,etc. aspectos a las que proporciona la partici6n equivalente:
Las condiciones de entrada asociadas con cada elemento 1. Si una condici6n de entrada especifica un rango deli-
de la aplicacibn bancaria se pueden especificar como: mitado por 10s valores a y b, se deben diseiiar casos
de prueba para 10s valores a y b, y para 10s valores
C6digo de Area: condici6n de entrada, ldgica--el cMi-
justo por debajo y justo por encima de a y b, res-
go de Area puede estar o no presente
pectivamente.
condici6n de entrada, rango-valo-
res definidos entre 200 y 999, con 2. Si una condici6n de entrada especifica un numero de
excepciones especificas valores, se deben desarrollar casos de prueba que
ejerciten 10s valores mhximo y minimo. TambiCn se
Prefijo: condicidn de entrada, rango -valor
deben probar 10s valores justo por encima y justo por
especificado > 200 sin digitos 0
debajo del mhximo y del minimo.
Sufijo: condici6n de entrada, valor -lon- 3. Aplicar las directrices 1 y 2 a las condiciones de
gitud de cuatro digitos salida. Por ejemplo, supongamos que se requiere una
Contraseiia: condici6n de entrada, 16gica - tabla de cctemperatura 1 presi6n~como salida de un
la palabra clave puede estar o no programa de anhlisis de ingenieria. Se deben dise-
presente; iiar casos de prueba que creen un informe de salida
condici6n de entrada, valor -cade- que produzca el maxim0 (y el minimo) ndmero per-
na de seis caracteres mitido de entradas en la tabla.
Orden: condici6n de entrada, conjunto- 4. Si las estructuras de datos internas tienen limites
contenida en las 6rdenes listadas preestablecidos (por ejemplo, una matriz que tenga
anteriormente un limite definido de 100 entradas), hay que asegu-
Aplicando las directrices para la obtenci6n de clases rarse de diseiiar un caso de prueba que ejercite la
de equivalencia, se pueden desarrollar y ejecutar casos estructura de datos en sus limites.
de prueba para cada elemento de datos del campo de La mayoria de 10s ingenieros del software llevan a
entrada. Los casos de prueba se seleccionan de forma cab0 de forma intuitiva alguna forma de AVL. Apli-
que se ejercite el mayor numero de atributos de cada cando las directrices que se acaban de exponer, la prueba
clase de equivalencia a la vez. de limites sera mhs completa y, por tanto, tendra una
mayor probabilidad de detectar errores.
17.6.3. Analisis d e valores limite
Por razones que no esthn del todo claras, 10s errores 17.6.4. Prueba d e comparacion
tienden a darse mris en 10s limites del campo de entra- Hay situaciones (por ejemplo, avi6nica de aeronaves,
da que en el cccentro>>.Por ello, se ha desarrollado el control de planta nuclear) en las que la fiabilidad del
andlisis de valores lirnites (AVL) como tCcnica de software es algo absolutamente critico. En ese tipo de
( 3 , l ~ l )( l~7 2 , l 7 l ) ,(1,3,1,1), (1,1,2,1), (1,1,3,1), La prueba de la tabla ortogonal nos permite propor-
(1,1,1,2), y (1,1,1,3). Phadke [PEL4971valora estos casos cionar una buena cobertura de prueba con bastantes
de prueba de la siguiente manera: menos casos de prueba que en la estrategia exhaustiva.
Cada uno de estos casos de prueba son utiles, linicamente Una tabla ortogonal L9 para la funci6n de envio del fax
cuando estos parametros de prueba no se influyen mutuamen- se describe en la Figura 17.11.
te. Pueden detectar fallos 16gicos cuando el valor de un par& Phadke [PHA97] valora el resultado de las prue-
metro produce un ma1 funcionamiento del software. Estos fallos bas utilizando la tabla ortogonal de la siguiente
pueden llamarse fallos de modalidad simple. El metodo no pue-
de detectar fallos 16gicos que causen un ma1 funcionamiento manera:
cuando dos o mas parametros simultineamente toman deter- Detecta y aisla todos 10s fallos d e modalidad sim-
minados valores; es decir, no se pueden detectar interacciones. ple. Un fallo de modalidad simple es un problema que
Asi, esta habilidad para detectar fallos es limitada. afecta a un solo parametro. Por ejemplo, si todos 10s casos
Dados un ndmero relativamente pequeiio de parime- de prueba del factor P1 = 1 causan una condicion de error,
tros de entrada y valores dlferentes, es posible realizar una nos encontramos con el fallo de modalidad simple. En 10s
ejemplos de prueba 1, 2 y 3 [Fig. 17.11] se encontraran
prueba exhaustiva. El ndmero de pruebas requeridas es errores. Analizando la information en que las pruebas
3'=8 1 -grande per0 manejable-. Todos 10s fallos aso- muestran errores, se puede identificar que valores del para-
ciados con la permutacion de 10s datos s e r h encontrados, metro causan el error. En este ejemplo, anotamos que las
per0 el esfuerzo requerido es relativarnente alto. pruebas 1, 2 y 3 causan un error, lo que permite aislar [el
proceso logic0 asociado con ccenviar ahoraz (P1 = l)] la
fuente del error. El aislamiento del fallo es importante para
solucionar el error.
Detecta todos 10s fallos de modalidad doble. Si exis-

te un problema donde estan afectados dos parametros que
intervienen conjuntamente, se llama fallo de modalidad
doble. En efecto, un fallo de modalidad doble es una indi-
cacidn de incompatibilidad o de imposibilidad de interac-
ci6n entre dos parametros.
Fallos multimodales. Las tablas ortogonales [del tip0

indicado] pueden asegurar la deteccion unicamente de fallos
de modalidad simple o doble. Sin embargo, muchos fallos
en modalidad multiple pueden ser detectados a travCs de
estas pruebas.
Se puede encontrar un estudio detallado sobre la

FIGURA 17.11. Una tabla ortogonal L9. prueba de tabla ortogonal en [PHA89].
A medida que el software de computadora se ha hecho en menos costosa en tiempo y mas exacta. A1 mismo
mis complejo, ha crecido tambiCn la necesidad de enfo- tiempo, la complejidad de las IGUs ha aumentado,
ques de pruebas especializados. Los mCtodos de prue- originando mhs dificultad en el diseiio y ejecucidn de
ba de caja blanca y de caja negra tratados en las 10s casos de prueba.
Secciones 17.5 y 17.6 son aplicables a todos 10s entor-
nos, arquitecturas y aplicaciones per0 a veces se nece-
sitan unas directrices y enfoques dnicos para las pruebas.
En esta seccidn se estudian directrices de prueba para
entornos, arquitecturas y aplicaciones especializadas
que pueden encontrarse 10s ingenieros del software.
Dado que las IGUs modernas tienen la misma apa-
17.7.1. Prueba de interfaces graficas de usuario riencia y filosofia, se pueden obtener una serie de
pruebas esthndar. Los grafos de modelado de estado
(IGUs)
finito (Seccion 16.6.1) pueden ser utilizados para rea-
Las interfaces grificas de usuario (IGUs) presentan lizar pruebas que vayan dirigidas sobre datos especi-
interesantes desafios para 10s ingenieros del softwa- ficos y programas objeto que Sean relevantes para las
re. Debido a 10s componentes reutilizables provistos IGUs.
como parte de 10s entornos de desarrollo de las GUI, Considerando el gran ndmero de permutaciones aso-
la creaci6n de la interfaz de usuario se ha convertido ciadas con las operaciones IGU, seria necesario para
INGENIERIA DEL SOFTWARE. U N E N F O Q U E PRACTICO
probar el utilizar herramientas automiiticas. Una amplia claridad editorial. La segunda fase, la prueba en vivo,
lista de herramientas de prueba de IGU han aparecido utiliza la documentaci6njunto a1 uso del programa real.
en el mercado en 10s dltimos aiios. Para profundizar en Es sorprendente, per0 la prueba en vivo de la docu-
el tema, ver el Capitulo 3 1. mentaci6n se puede enfocar usando tCcnicas aniilogas
a muchos de 10s mCtodos de prueba de caja negra estu-
diados en la Secci6n 17.6. Se pueden emplear pruebas
basadas en grafos para describir el empleo del progra-
ma; se pueden emplear el aniilisis de la partici6n equi-
valente o de 10s valores limites para definir varias clases
de entradas e interacciones asociadas.
Prueba IGU.
17.7.4. Prueba de sistemas de tiempo-real
17.7.2. Prueba de arquitectura cliente/sewidor
La naturaleza asincrona y dependiente del tiempo de
La arquitectura clientelsemidor (CIS) representa un desa- muchas aplicaciones de tiempo real, afiade un nuevo y
fio significativo para 10s responsables de la pruebas del potencialmente dificil elemento a la complejidad de las
software. La naturaleza distribuida de 10s entomos clien- pruebas 4 1 tiemp-. El responsable del disefio de casos
telservidor, 10s aspectos de rendimiento asociados con de prueba no s610 tiene que considerar 10s casos de prue-
el proceso de transacciones, la presencia potencial de ba de caja blanca y de caja negra, sino tambiCn el trata-
diferentes plataformas hardware, las complejidades de miento de sucesos (por ejemplo, procesamiento de
las comunicaciones de red, la necesidad de semir a mdl- intermpciones), la temporizaci6n de 10s datos y el para-
tiples clientes desde una base de datos centralizada (o lelismo de las tareas (procesos) que manejan 10s datos. En
en algunos casos, distribuida) y 10s requisitos de coor- muchas situaciones, 10s datos de prueba proporcionados
dinaci6n impuestos a1 semidor se combinan todos para a1 sistema de tiempo real cuando se encuentra en un deter-
hacer las pruebas de la arquitectura CIS y el software minado estado darhn un proceso correcto, mientras que a1
residente en ellas, considerablemente miis dificiles que proporcionArselos en ouo estado llevarin a un error.
la prueba de aplicaciones individuales. De hecho, estu-
dios recientes sobre la industria indican un significati-
vo aumento en el tiempo invertido y 10s costes de las
pruebas cuando se desarrollan entornos CIS.
La ingenieria del software cliente/servidor se presenta Sistemas de tiempo real.

en el Capitulo 28.
Por ejemplo, un software de tiempo real que controla
una moderna fotocopiadora puede aceptar intermpcio-
nes del operador (por ejemplo, el operador de la miiqui-
17.7.3. Prueba de la documentaci6ny facilidades na pulsa teclas de control tales como ccinicializaci6n>> u
de ayuda ccoscurecimiento>>)sin error cuando la miiquina se
El tCrmino ccpruebas del software>>hace imaginarnos encuentra en el estado de hacer fotocopias (estado de
gran cantidad de casos de prueba preparados para eje- cccopia>>).Esas mismas interrupciones del operador,
cutar programas de computadora y 10s datos que mane- cuando se producen estando la miiquina en estado de
jan. Recordando la definici6n de software presentada eatascon, pueden producir un c6digo de diagnostic0 que
en el primer capitulo de este libro, es importante dar- indique la situaci6n del atasco (un error).
se cuenta de que la prueba debe extenderse a1 tercer Ademiis, la estrecha relaci6n que existe entre el soft-
elemento de la configuracidn del software -la docu- ware de tiempo.rea1y su entomo de hardware tambiCn
mentaci6n-. puede introducir problemas en la prueba. Las pruebas
Los errores en la documentaci6n pueden ser tan des- del software deben considerar el impact0 de 10s fallos
tmuctivos para la aceptaci6n del programa, como 10s erro- del hardware sobre el proceso del software. Puede ser
res en 10s datos o en el c6digo fuente. Nada es miis muy dificil simular de forma realista esos fallos.
frustrante que seguir fielmente el manual de usuario y Todavia han de evolucionar mucho 10s mCtodos gene-
obtener resultados o comportamientos que no coinciden rales de disefio de casos de prueba para sistemas de tiem-
con 10s anticipados por el documento. Por esta raz6n, la po real. Sin embargo, se puede proponer una estrategia
prueba de la documentaci6n deberia ser una parte impor- en cuatro pasos:
tante de cualquier plan de pruebas del software. Prueba de tareas. El primer paso de la prueba de
La prueba de la documentaci6n se puede enfocar en sistemas de tiempo real consiste en probar cada tarea
dos fases. La primera fase, la revision e inspeccibn independientemente. Es decir, se disefian pruebas de
(Capitulo 8), examina el documento para comprobar la caja blanca y de caja negra y se ejecutan para cada
CAPfTULO 17 T e C N I C A S DE PRUEBA DEL SOFTWARE
tarea. Durante estas pruebas, cada tarea se ejecuta inde- Prueba intertareas. Una vez que se han aislado
pendientemente. La prueba de la tarea ha de descubrir 10s errores en las tareas individuales y en el com-
errores en la 16gica y en el funcionamiento, per0 no portamiento del sistema, la prueba se dirige hacia
10s errores de temporizaci6n o de comportamiento. 10s errores relativos a1 tiempo. Se prueban las tare-
as asincronas que se sabe que comunican con otras,
con diferentes tasas de datos y cargas de proceso
Referencia web/ ' para determinar si se producen errores de sincronis-
mo entre las tareas. Ademis, se prueban las tareas
El Forum de Discusidn de la Ptueba del Sofiwore present0 temas que se comunican mediante colas de mensajes o
de interes a las profesionalesque efedan lo ptuebo: almacenes de datos, para detectar errores en el tama-
www.ondaweb.com /HyperNews/get.cgi/forums/sti.html. iio de esas Areas de almacenamiento de datos.
Prueba de comportamiento. Utilizando modelos Prueba del sistema. El software y el hardware e s t h
del sistema creados con herramientas CASE, es posi- integrados, por lo que se lleva a cabo una sene de prue-
ble simular el comportamiento del sistema en tiempo bas completas del sistema (Capitulo 18) para intentar
real y examinar su comportamiento como consecuen- descubrir errores en la interfaz softwarehardware.
cia de sucesos extemos. Estas actividades de anAlisis La mayoria de 10s sistemas de tiempo real procesan
pueden servir como base del diseiio de casos de prue- intermpciones. Por tanto, es esencial la prueba del mane-
ba que se llevan a cab0 cuando se ha construido el soft- jo de estos sucesos 16gicos. Usando el diagrama estado-
ware de tiempo real. Utilizando una tCcnica parecida transici6n y la especificaci6n de control (Capitulo 12), el
a la partici6n equivalente (Secci6n 17.6.I), se pueden responsable de la prueba desarrolla una lista de todas las
categorizar 10s sucesos (por ejemplo, intermpciones, posibles intermpciones y del proceso que ocurre como
seiiales de control, datos) para la prueba. Por ejemplo, consecuencia de la intermpci6n. Se diseiian despuCs prue-
10s sucesos para la fotocopiadora pueden ser inte- bas para valorar las siguientes caracteristicas del sistema:
rmpciones del usuario (por ejemplo, reinicializaci6n
del contador), intermpciones mecAnicas (por ejemplo, iSe han asignado y gestionado apropiadamente las
atasco del papel), intermpcionesdel sistema (por ejem- prioridades de interrupci6n?
plo, bajo nivel de tinta) y modos de fa110 (por ejem- iSe gestiona correctamente el procesamiento para
plo, rodillo excesivamente caliente). Se prueba cada todas las intermpciones?
uno de esos sucesos individualmente y se examina el iSe ajusta a 10s requisitos el rendimiento (por ejem-
comportamiento del sistema ejecutable para detectar plo, tiempo de proceso) de todos 10s procedimientos
errores que se produzcan como consecuencia del pro- de gestion de interrupciones?
ceso asociado a esos sucesos. Se puede comparar el
comportamiento del modelo del sistema (desarrolla- iCrea problemas de funcionamiento o rendimiento
la llegada de un gran volumen de intermpciones en
do durante el anAlisis) con el software ejecutable para
ver si existe concordancia. Una vez que se ha proba- momentos criticos?
do cada clase de sucesos, a1 sistema se le presentan AdemAs, se deberian probar las hreas de datos glo-
sucesos en un orden aleatorio y con una frecuencia ale- bales que se usan para transferir informaci6n como par-
atoria. Se examina el comportamiento del software te del proceso de una interrupci61-1para valorar el
para detectar errores de comportamiento. potencial de generaci6n de efectos colaterales.
El principal objetivo del diseiio de casos de prueba es pendientes que aseguren la total cobertura. La prueba
obtener un conjunto de pruebas que tengan la mayor de condiciones y del flujo de datos ejercita mis adn la
probabilidad de descubrir 10s defectos del software. Para 16gica del programa y la prueba de 10s bucles comple-
llevar a cab0 este objetivo, se usan dos categorias dife- menta a otras tCcnicas de caja blanca, proporcionando
rentes de tCcnicas de diseiio de casos de prueba: prue- un procedimiento para ejercitar bucles de distintos gra-
ba de caja blanca y prueba de caja negra. dos de complejidad.
Las pruebas de caja blanca se centran en la estruc- Heztel [HET84] describe la prueba de caja blanca
tura de control del programa. Se obtienen casos de prue- como ccprueba a pequeiia escalan. Esto se debe a que
ba que aseguren que durante la prueba se han ejecutado, las pruebas de caja blanca que hemos considerado en
por lo menos una vez, todas las sentencias del progra- este capitulo son tipicamente aplicadas a pequeiios
ma y que se ejercitan todas las condiciones 16gicas. La componentes de programas (po ejemplo; m6dulos o
prueba del camino bisico, una tCcnica de caja blanca, pequefios grupos de modules). Por otro lado, la prue-
hace uso de grafos de programa (o matrices de grafos) ba de caja negra amplia el enfoque y se puede deno-
para obtener el conjunto de pruebas linealmente inde- minar ccprueba a gran escala,,.
~ N G E N ~ E RDEL
Las pruebas de caja negra son diseiiadas para validar Los metodos de prueba especializados comprenden una
10s requisitos funcionales sin fijarse en el funcionamien- amplia gama de capacidades del software y rireas de apli-
to intemo de un programa. Las tkcnicas de prueba de caja caci6n. Las interfaces grif=icas de usuario, las arquitectu-
negra se centran en el imbito de informaci6n de un pro- ras cliente/servidor, la documentacion y facilidades de
grama, de forma que se proporcione una cobertura com- ayuda, y 10s sistemas de tiempo real requieren directrices
pleta de prueba. Los mCtodos de prueba basados en grafos y tknicas especializadas para la prueba del software.
exploran las relaciones entre 10s objetos del programa y A menudo, 10s desarrolladores de software experi-
su comportamiento. La particion equivalente divide el mentados dicen que ccla prueba nunca termina, simple-
campo de entrada en clases de datos que tienden a ejerci- mente se transfiere de usted (el ingeniero del software)
tar determinadas funciones del software. El analisis de a1 cliente. Cada vez que el cliente usa el programa, lle-
valores limite prueba la habihdad del prograrna para mane- va a cab0 una prueba.n Aplicando el disefio de casos de
jar datos que se encuentran en 10s limites aceptables. La prueba, el ingeniero del software puede conseguir una
prueba de la tabla ortogonal suministra un metodo siste- prueba mas completa y descubrir y corregir asi el mayor
mitico y eficiente para probar sistemas con un numero numero de errores antes de que comiencen las ccprue-
reducido de parametros de entrada. bas del cliente,,.
[BE1901 Beizer, B., Software Testing Techniques, 2.%d., Van [JON811 Jones, T.C., Programming Prodwtivity: Issues for
Nostrand Reinhold, 1990. the 80's, IEEE Computer Society Press, 1981.
[BE1951 Beizer, B., Black-Bos Testing, Wiley, 1995. [KAN93] Kaner, C., J. Falk y H.Q. Nguyen, Testing Compu-
[BRI87] Brilliant, S.S., J.C. Knight, y N.G. Levenson, <<The ter Software, 2.a ed., Van Nostrand Reinhold, 1993.
Consistent Comparison Problem in N-Version Software)), [KN189] Knight, J., y P. Ammann, <<TestingSoftware Using
ACM Software Engineering Notes, vol. 12, n." 1, enero Multiple Versions,,, Software Productivity Consortium,
1987, pp. 29-34. Report n." 89029N, Reston, VA, Junio 1989.
[DAV95] Davis, A,, 201 Principles of Software Development, [MCC76] McCabe, T., <<ASoftware Complexity Measure,,
McGraw-Hill, 1995. IEEE Trans. Software Engineering, vol. 2, Diciembre 1976,
[DEU79] Deutsch, M., <<Verificationand Validation,,, Soft- pp. 308-320.
ware Engineering, R. Jensen y C.Tonies (eds.), Prentice- [MYE79] Myers, G., The Art of Software Testing,Wiley, 1979.
Hall, 1979, pp. 329-408. [NTA88] Ntafos, S.C., ctA comparison of Some Structural Tes-
[FOS84] Foster, K.A., <<SensitiveTest Data for Boolean ting Strategies)),IEEE Trans. Software Engineering, vol. 14,
Expressions,,, ACM Software Engineering Notes, vol. 9, n." 6, Junio 1988, pp. 868-874.
n." 2, Abril 1984, pp. 120-125. [PHA89] Phadke, MS., Quality Engineering Using Robust
[FRA88] Frankl, P.G., y E.J. Weyuker, <<An Applicable Family Design, Prentice Hall, 1989.
of Data Flow Testing Criteria,,, IEEE Trans. Sofhrnre Engi- [PHA97] Phadke, M.S., <<PlanningEfficient Software Tests,,,
neering, vol. 14, n." 10, Octubre 1988, pp.1483-1498. Crosstalk, vol. 10, n." 10, Octubre 1997, pp. 278-283.
[FRA93] Frankl, P.G., y S. Weiss, <<AnExperimental Com- [TAI87] Tai, K.C., y H.K. Su, (<TestGeneration for Boolean
parison of the Effectiveness of Branch Testing and Data Expresionsn, Pror. COMPSAC'87, Octubre 1987, pp. 278-
Flow)>.IEEE Trans. Software Engineering, vol. 19, n." 8, 283.
Agosto 1993, pp. 770-787. [TAI89] Tai, K.C., <<Whatto Do Beyond Branch Testingr,
[HET84] Hetzel, W., The Complete Guide to Software Tes- ACM Software Engineering Notes, vol. 14, n." 2, Abril
ting, QED Information Sciences, Inc., WeIlesley, MA, 1984. 1989, pp. 58-61.
[HOW821 Howden, W.E., <<WeakMutation Testing and the [WHI80] White, L.J., y.E.1. Cohen, <<A Domain Strategie for
Completeness of Test Cases*, IEEE Trans. Software Engi- Program Testing,,, IEEE Trans. Software Engineering, vol.
neering, vol. SE-8, n." 4, julio 1982, pp. 371-379. SE-6, n." 5, Mayo 1980, pp. 247-257.
17.1. Myers [MYE79] usa el siguiente programa como auto- 17.2. Disefie e implemente el programa especificado en el Pro-
comprobaci6n de su capacidad para especificar una prueba blema 17.1 (con tratamiento de errores cuando sea necesario).
adecuada: un programa lee tres valores enteros. Los tres valo- Obtenga un grafo de flujo para el programa y aplique la prue-
res se interpretan como representaci6n de la longitud de 10s ba del camino bisico para desarrollar casos de prueba que
tres lados de un trihgulo. El programa irnprime un mensaje garanticen la comprobaci6n de todas las sentencias del pro-
indicando si el triangulo es escaleno, is6sceles o equilitero. grams. Ejecute 10s casos y muestre sus resultados.
Desarrolle un conjunto de casos de prueba que considere que 17.3. iSe le ocurren algunos objetivos de prueba adicionales
probari de forma adecuada este programa. que no se hayan mencionado en la Seccidn 17.1.1?
Las pruebas son un conjunto de actividades que se pue- ta a 10s requisitos del cliente. Bohem [BOE8 11 lo defi-
den planificar por adelantado y llevar a cab0 sistemati- ne de otra forma:
camente. Por esta raz6n, se debe definir en el proceso Verificaci6n: cciEstamos construyendo el producto correc-
de la ingenieria del software unaplantilla para las prue- tamente'?~
bas del software: un conjunto de pasos en 10s que poda- Validacidn:cciEstamosconstruyendo el producto correcto?n
mos situar 10s metodos especificos de diseiio de casos
de prueba. La definici6n de V&V comprende muchas de las acti-
Se han propuesto varias estrategias de prueba del vidades a las que nos hemos referido como garantia de
software en distintos libros. Todas proporcionan a1 inge- calidad del software (sQA*).
niero del software una plantilla para la prueba y todas La verification y la validation abarcan una amplia
tienen las siguientes caracteristicas generales: lista de actividades SQA que incluye: revisiones tCc-
nicas formales, auditorias de calidad y de configura-
Las pruebas comienzan a nivel de m6dulo2 y traba-
ci6n, monitorizacion de rendimientos, simulaci6n,
jan <<haciafueran, hacia la integration de todo el sis- estudios de factibilidad, revisi6n de la documenta-
tema basado en computadora. c i h , revisi6n de la base de datos, analisis algoritmi-
Seg6n el momento, son apropiadas diferentes tecnico, pruebas de desarrollo, pruebas de validaci6n y
cas de prueba. pruebas de instalacion [WAL89]. A pesar de que las
La prueba la lleva a cab0 el responsable del desa- actividades de prueba tienen un papel muy impor-
rrollo del software y (para grandes proyectos) un tante en V&V, muchas otras actividades son tambiCn
grupo independiente de pruebas. necesarias.
La prueba y la depuraci6n son actividades diferen-
tes, per0 la depuracion se debe incluir en cualquier
estrategia de prueba. Las octividodes SQA son estudiodos en detolle en el
Una estrategia de prueba del software debe incluir Capitulo 8.
pruebas de bajo nivel que verifiquen que todos 10s
pequeiios segmentos de c6digo fuente se han imple- Las pruebas constituyen el 6ltimo btsti6n desde el
mentado correctamente, asi como pruebas de alto nivel que se puede evaluar la calidad y, de forma mas prag-
que validen las principales funciones del sistema frente mAtica, descubrir 10s errores. Pero las pruebas no deben
a 10s requisitos del cliente. Una estrategia debe propor- ser vistas como una red de seguridad. Como se suele
cionar una guia a1 profesional y proporcionar un con- decir: <<Nose puede probar la calidad. Si no estA ahi
junto de hitos para el jefe de proyecto. Debido a que 10s antes de comenzar la prueba, no estara cuando se ter-
pasos de la estrategia de prueba se dan a la vez cuando mine.>>La calidad se incorpora en el software durante
aumenta la presi6n de 10s plazos fijados, se debe poder el proceso de ingenieria del software. La aplicacion ade-
medir el progreso y 10s problemas deben aparecer lo cuada de 10s mCtodos y de las herramientas, las revi-
antes posible. siones tCcnicas formales efectivas y una s6lida gesti6n
y medicibn, conducen a la calidad, que se confirma
durante las pruebas.
Referencia web/ '
Information Otil sobre 10s eshotegios de pruebo del software
es suminishado en el lnforme sobre lo Prueba del Software
en:www.ondaweb.com/sti/newsltr.htm
La prueba del software es un elemento de un tema m&

amplio que, a menudo, es conocido como verificaci6n Miller [MIL771 relaciona la prueba del software con
y validaci6n (V&V). La verifrcacidn se refiere a1 con- la garantia de calidad a1 establecer que <<lamotivation
junto de actividades que aseguran que el software imple- subyacente de la prueba de programas es confirmar la
menta correctamente una funci6n especifica. La calidad del software con mCtodos que se pueden apli-
validacidn se refiere a un conjunto diferente de activi- car de forma econ6mica y efectiva, tanto a grandes como
dades que aseguran que el software construido se ajus- a pequefios sistemaw.
2Para 10s sistemas orientados a objetos, las pruebas empiezan a nivel ' Por lo habitual de su utilization mantenernos el terrnino ingles SQA
de clase o de objeto. Vea mas detalles en el Capitulo 23. (Sofiware Quality Assurance).
CAPfTULO 18 ESTRATEGIAS DE PRUEBA DEL SOFTWARE
18.1.2.Orgcmizaci6npara las pruebas del software hecho de permitir a1 constructor que pruebe lo que ha
En cualquier proyecto de software existe un conflict0 construido. Una prueba independiente elimina el con-
de intereses inherente que aparece cuando comienzan f l i c t ~de intereses que, de otro modo, estaria presen-
las pruebas. Se pide a la gente que ha construido el soft- te. Desputs de todo, a1 personal del equipo que forma
ware que lo pruebe. Esto parece totalmente inofensivo: el grupo independiente se le paga para que encuentre
despuCs de todo, iquiCn puede conocer mejor un pro- errores.
grama que 10s que lo han desarrollado? Desgraciada- Sin embargo, el responsable del desarrollado del soft-
mente, esos mismos programadores tienen un gran ware no entrega simplemente el programa a1 GIP y se
inter& en demostrar que el programa esti libre de erro- desentiende. El responsable del desarrollado y el GIP
res, que funciona de acuerdo con las especificaciones trabajan estrechamente a lo largo del proyecto de soft-
del cliente y que estari listo de acuerdo con 10s plazos ware para asegurar que se realizan pruebas exhaustivas.
y el presupuesto. Cada uno de estos intereses se con- Mientras se realiza la prueba, el desarrollador debe estar
vierte en inconveniente a la hora de encontrar errores a disponible para corregir 10s errores que se van descu-
lo largo del proceso de prueba. briendo.
Desde un punto de vista psicol6gic0, el anilisis y el
diseAo del software (junto con la codificaci6n) son tareas
constructivas. El ingeniero del software crea un progra-
Si no existe un GIP en tu orgonizocibn,
made computadora, su documentaci6n y sus estructuras tendrbs que osumir su punto de vista.
de datos asociadas. Al igual que cualquier constructor,el Cuondo pruebes, intenta deshozor el software.
ingeniero del software est6 orgulloso del edificio que aca-
ba de construir y se enfrenta a cualquiera que intente
sacarle defectos. El GIP es parte del equipo del proyecto de desarro-
Cuando comienza la prueba, aparece una sutil, aun- 110 de software en el sentido de que se ve implicado
que firme intenci6n de <<romper>> lo que el ingeniero del durante el proceso de especificaci6n y sigue implicado
software ha construido. Desde el punto de vista del cons- (planificaci6n y especificaci6n de 10s procedimientos
tructor, la prueba se puede considerar (psicol6gicamente) de prueba) a lo largo de un gran proyecto. Sin embar-
destructiva. Por tanto, el constructor anda con cuidado, go, en muchos casos, el GIP informa a la organizacih
diseAando y ejecutando pruebas que demuestren que el de garantia de calidad del software, consiguiendo de
programa funciona, en lugar de detectar errores. Des- este mod0 un grado de independencia que no serfa posi-
graciadamente, 10s errores seguirh estando. Y si el inge- ble si fuera una parte de la organizaci6n de desarrollo
niero del software no 10s encuentra, jel cliente si lo hari! del software.
A menudo, existen ciertos malentendidos que se pue-
den deducir equivocadamente de la anterior discusi6n: 18.1.3. Una estrategia de prueba del software
(1) el responsable del desarrollo no deberia entrar en el El proceso de ingenieria del software se puede ver como
proceso de prueba; (2) el software debe ser apuesto a una espiral, como se ilustra en la Figura 18.1. Inicial-
salvo,, de extrafios que puedan probarlo de forma des- mente, la ingenieria de sistemas define el papel del soft-
piadada; (3) 10s encargados de la prueba s610 aparecen ware y conduce a1 andisis de 10s requisitos del software,
en el proyecto cuando comienzan las etapas de prueba. donde se establece el dominio de informaci6n, la fun-
Todas estas frases son incorrectas. c i h , el comportamiento, el rendimiento, las restriccio-
El responsable del desarrollo del software siempre nes y 10s criterios de validaci6n del software. A1
es responsable de probar las unidades individuales movemos hacia el interior de la espiral, llegamos a1 dise-
(m6dulos) del programa, asegurhdose de que cada una Ao y, por 6ltim0, a la codificaci6n. Para desarrollar soft-
lleva a cab0 la funci6n para la que fue disefiada. En ware de computadora, damos vueltas en espiral a travCs
muchos casos, tambiCn se encargar6 de la prueba de de una sene de flujos o lineas que disminuyen el nivel
integraci61-1,el paso de las pruebas que lleva a la cons- de abstracci6n en cada vuelta.
trucci6n (y prueba) de la estructura total del sistema.
S610 una vez que la arquitectura del software estC com- ~ Q u ees la estrategia global
pleta entra en juego un grupo independiente de prueba. para la prueba del software?
TambiCn se puede ver la estrategia para la prueba del

software en el context0 de la espiral (Fig. 18.1). Laprue-
ba de unidad comienza en el vCrtice de la espiral y se
Un grupo independiente de prueba no tiene el <conflitto
centra en cada unidad del software, tal como esti imple-
de intereses)) que tienen 10s desarrolladores del software
mentada en c6digo fuente. La prueba avanza, a1 mover-
nos hacia fuera de la espiral, hasta llegar a laprueba de
El papel del grupo independiente de prueba (GIP) integracidn, donde el foco de atenci6n es el disefio y la
es eliminar 10s inherentes problemas asociados con el construcci6n de la arquitectura del software. Dando otra
vuelta por la espiral hacia fuera, encontramos la prue- el m6s amplio contexto de la ingenieria de sistemas de
ha de validacidrt, donde se validan 10s requisitos esta- computadora.
blecidos como parte del analisis de requisitos del El software, una vez validado, se debe combinar con
software, comparandolos con el sistema que ha sido otros elementos del sistema (por ejemplo, hardware, gen-
construido. Finalmente, llegamos a la prueha del sisre- te, bases de datos). La pnleha del sisternu verifica que
ma, en la que se prueban como un todo el software y cada elemento encaja de forma adecuada y que se alcan-
otros elementos del sistema. Para probar software de za la funcionalidad y el rendimiento del sistema total.
computadora nos movemos hacia fuera por una espiral
que, a cada vuelta, aumenta el alcance de la prueba.
Prueba del sistema
Prueba de validacio Prueba de unidad
Requisitok 'lngenieria del sisterna FIGURA 18.2. Etapas en la prueba del software.
FIGURA 18.1. Estrategia de prueba.
18.1.4. Criterios para completar la prueba
Si consideramos el proceso desde el punto de vista pro- Cada vez que se tratan las pruebas del software surge
cedimental, la prueba, en el contexto de la ingenieria del una pregunta clhsica: ~ C u a n d ohemos terminado las
software, realmente es una serie de cuatro pasos que se pruebas?, jc6m0 sabemos que hemos probado lo sufi-
llevan a cabo secuencialmente. Esos pasos se muestran ciente? Desgraciadamente. no hay una respuesta defi-
en la Figura 18.2. Inicialmente, la prueba se centra en cada nitiva a esta pregunta, pero hay algunas respuestas
m6dulo individualmente, asegurando que funcionan ade- pricticas y nuevos intentos de base empirica.
cuadamente como una unidad. De ahi el nombre de prue-
ha de f mid ad. La prueba de unidad hace un uso intensivo
de las tCcnicas de prueba de caja blanca, ejercitando cami-
nos especificos de la estructura de control del mMulo para
asegurar un alcance completo y una detecci6n maxima de Una respuesta a la pregunta anterior es: <<Laprueba
errores. Acontinuaci6n, se deben ensamblar o integrar 10s nunca termina, ya que el responsable del desarrollo del
modulos para formar el paquete de software completo. La software carga o pasa el problema a1 cliente.,, Cada vez
prueha de irttegracidn se dirige a todos 10s aspectos aso- que el cliente/usuario ejecuta un programa de compu-
ciados con el doble problema de verificacion y de cons- tadora, dicho programa se esta probando con un nuevo
trucci6n del programa. Durante la integraci611, las tknicas conjunto ,de datos. Este importante hecho subraya la
que m6s prevalecen son las de diseiio de casos de prueba importancia de otras actividades de garantia de calidad
de caja negra, aunque se pueden llevar a cabo algunas del software. Otra respuesta (algo cinica, pero sin embar-
pruebas de caja blanca con el fin de asegurar que se cubren go cierta) es: xSe termina la prueba cuando se agota el
10s principales caminos de control. DespuCs de que el soft- tiempo o el dinero disponible para tal efect0.n
ware se ha integrado (construido), se dirigen un conjun- Aunque algunos profesionales se sirvan de estas res-
to de pruebas de alto nivel. Se deben comprobar 10s puestas como argumento, un ingeniero del software
criterios de validaci6n (establecidos durante el an6lisis de necesita un criterio mis riguroso para determinar cuan-
requisitos). La prueha de validacidn proporciona una segu- do se ha realizado la prueba suficiente. Musa y Acker-
ridad final de que el software satisface todos 10s requisi- man [MUS89] sugieren una respuesta basada en un
tos funcionales, de comportamiento y de rendimiento. criterio estadistico: <<No,no podemos tener la absoluta
Durante la validacih se usan exclusivamente tkcnicas de certeza de que el software nunca fallara, pero en base a
prueba de caja negra. un modelo estadistico de corte te6rico y validado expe-
rimentalmente, hemos realizado las pruebas suficientes
para decir, con un 95 por 100 de certeza, que la proba-
Las tknicas de pruebo de caia blanco y coio negm bilidad de funcionamiento libre de fallo de 1.000 horas
se estudion en el Copihrla 17. de CPU, en un entorno definido de forma probabilisti-
ca, es a1 menos 0 , 9 9 5 ,
El liltimo paso de prueba de alto nivel queda fuera Mediante el modelado estadistico y la teoria de fiabi-
de 10s limites de la ingenieria del software, entrando en lidad del software, se pueden desmollar modelos de fallos
del software (descubiertos durante las pruebas) como una ro de puntos de datos, el modelo se puede usar para pre-
funcion del tiempo de ejecucion. Una version del mode- decir el tiempo de prueba total requerido para alcanzar
lo de fallos, denominado modelo logaritmico de Poisson una intensidad de fallos aceptablemente baja.
de tiempo de ejecucidn, toma la siguiente forma:
(18.1) H Datos recogidos durante la prueba
f(t) = ( 1 1 ~In) K l o P + 111
donde
h lntensidad de fallos prevista, I( t )
f(t) ntimero acumulado de fallos que se espera que 01
u
se produzcan una vez que se ha probado el soft- e
ware durante una cierta cantidad de tiempo de 2 10
ejecucion t, bP
lo la intensidad de fallos inicial del software (fallos -k
por unidad de tiempo) a1 principio de la prueba m
LL
p la reduction exponencial de intensidad de fallo I I I I I I I *

a medida que se encuentran 10s errores y se van Tiempo de ejecucion, t
haciendo las correcciones. FIGURA 18.3. lntensidad de fallos en funcion del tiernpo
La intensidad de fallos instantAnea, l(t)sepuede obte- de ejecucion.
ner mediante la derivada de f(t):
Mediante la agrupacion de metricas durante la prue-
l(t)= lo/ (lopt + 1 ) (18.2) ba del software y haciendo uso de 10s modelos de fia-
Mediante la relacion de la ecuacion (18.2), 10s que bilidad del software existentes, es posible desarrollar
realizan las pruebas pueden predecir la disminucion de directrices importantes para responder a la pregunta:
errores a medida que estas avanzan. La intensidad de error icuhndo terminamos la prueba? No hay duda que toda-
real se puede trazar junto a la curva predecida (Fig. 18.3). via queda mucho trabajo por hacer antes de que se pue-
Si 10s datos reales recopilados durante la prueba y el dan establecer reglas cuantitativas para la prueba, per0
modelo logaritmico de Poisson de tiempo de ejecucion 10s enfoques empiricos que existen actualmente son con-
e s t h razonablemente cerca unos de otros, sobre un ndme- siderablemente mejores que la pura intuicion.
Mhs adelante, en este capitulo, exploramos una estrate- o frecuencia de ocurrencia, y horas de trabajo por
gia sistemhtica para la prueba del software. Pero inclu- prueba de regresion deberian establecerse dentro de
so la mejor estrategia fracasarh si no se tratan una serie la planificacion de la prueba [GIL95].
de aspectos invalidantes. Tom Gilb [GIL95] plantea que Comprender que' usuarios van a manejar el soft-
se deben abordar 10s siguientes puntos si se desea imple- ware y desarrollar un perjil para cada categoria de
mentar con Cxito una estrategia de prueba del software: usuario. Usar casos que describan el escenario de
iQue debemos hacer para
interaction para cada clase de usuario pudiendo redu-
definir una estrategia de cir el esfuerzo general de prueba concentrando la
prueba corrects? prueba en el empleo real del producto.
Especijicar 10s requisitos del producto de manera

cuantificable mucho antes de que comiencen las 10s cows de uso dexriben un escenario para uwr
pruebas. Aunque el objetivo principal de la prueba el software y se estudiin en el Capitulo 11.
es encontrar errores, una buena estrategia de prueba
tambien evalua otras caracteristicas de la calidad,
tales como la portabilidad, facilidad de manteni- Desarrollar un plan de prueba que haga hinca-
miento y facilidad de uso (Capitulo 19). Todo esto pie' en la ccprueba de ciclo rapido>>. Gilb [GIL95]
deben'a especificarse de manera que sea medible para recomienda que un equipo de ingenieria del software
que 10s resultados de la prueba no Sean ambiguos. ccaprenda a probar en ciclos rhpidos (2 por 100 del
Establecer 10s objetivos de la prueba de manera esfuerzo del proyecto) de incrementos de funciona-
explicita. Se deberian establecer en tCrminos medi- lidad y/o mejora de la calidad titiles para el cliente,
bles 10s objetivos especificos de la prueba. Por ejem- y que se puedan probar sobre el terrene,,. La reali-
plo, la efectividad de la prueba, la cobertura de la mentacion generada por estas pruebas de ciclo rhpido
prueba, tiempo medio de fallo, el coste para encon- puede usarse para controlar 10s niveles de calidad y
trar y arreglar errores, densidad de fallos remanente las correspondientes estrategias de prueba.
~ N G E N ~ E RDEL
nicas formales (Capitulo 8) pueden ser tan efecti-

vas como las pruebas en el descubrimiento de erro-
res. Por este motivo, las revisiones pueden reducir
la cantidad de esfuerzo de prueba necesaria para
producir software de alta calidad.
Llevar a cabo revisiones tkcnicas formales para
evaluar la estrategia de prueba y 10s propios casos
de prueba. Las revisiones tCcnicas formales pueden
Construir un software ((robusto,, diseiiado para descubrir inconsistencias, omisiones y errores cla-
probarse a si mismo. El software debena diseiiarse ros en el enfoque de la prueba. Esto ahorra tiempo
de manera que use tkcnicas de depuracion antierrores y tambiCn mejora la calidad del producto.
(Seccion 18.3.1). Es decir, el software deberia ser Desarrollar un enfoque de mejora continua a1
capaz de diagnosticar ciertas clases de errores. Ade- proceso de prueba. Deberia medirse la estrategia
mas, el diseiio deberia incluir pruebas automatizadas de prueba. Las mCtricas agrupadas durante la
y pruebas de regresion. prueba deberian usarse como parte de un enfoque
Usar revisiones tkcnicas formales efectivas estadistico de control del proceso para la prueba
comofiltro antes de la prueba. Las revisiones tCc- del software.
La prueba de unidad centra el proceso de verification

en la menor unidad del diseiio del software: el compo-
nente software o modulo.
L lnterfaz
18.3.1. Considemcionessobre la prueba de unidad Estructuras de datos locales
Las pruebas que se dan como parte de la prueba de uni- Condiciones lirnite
dad estAn esquematicarnente ilustradas en la Figura 18.4. Carninos independientes
Se prueba la interfaz del m6dulo para asegurar que la Carninos de rnanejo de errores
information fluye de forma adecuada hacia y desde la
unidad de programa que estd siendo probada. Se exa-
minan las estructuras de datos locales para asegurar que
10s datos que se mantienen temporalmente conservan
su integridad durante todos 10s pasos de ejecucion del
algoritmo. Se prueban las condiciones limite para ase-
gurar que el modulo funciona correctarnente en 10s limi-
tes establecidos como restricciones de procesamiento.
Se ejercitan todos 10s caminos independientes (cami-
nos bAsicos) de la estructura de control con el fin de ase-
gurar que todas las sentencias del m6dulo se ejecutan
por lo menos una vez. Y, finalmente, se prueban todos
FIGURA 18.4. Prueba de unidad.
10s caminos de manejo de errores.
Durante la prueba de unidad, la comprobaci6n selec-
tiva de 10s caminos de ejecucion es una tarea esencial.
Se deben diseiiar casos de prueba para detectar errores
debidos a cdculos incorrectos, comparaciones incorrectas
o flujos de control inapropiados. Las pruebas del cami-
Prueba de Unidad. no bAsico y de bucles son tCcnicas muy efectivas para
Antes de iniciar cualquier otra prueba es preciso pro- descubrir una gran cantidad de errores en 10s caminos.
bar el flujo de datos de la interfaz del modulo. Si 10s
datos no entran correctamente, todas las demhs pruebas ~ Q u eerrores son 10s mas comunes
no tienen sentido. AdemAs de las estructuras de datos durante la prueba de unidad?
locales, durante la prueba de unidad se debe comprobar
(en la medida de lo posible) el impact0 de 10s datos glo- Entre 10s errores m6s comunes en 10s cAlculos estih:
bales sobre el modulo. (1) precedencia aritmCtica incorrecta o ma1 interpretada;
(2) operaciones de mod0 mezcladas; (3) inicializaciones miximo o minimo permitidos. Los casos de prueba que
incorrectas; (4) falta de precisi6n; (5) incorrecta repre- ejerciten las estructuras de datos, el flujo de control y
sentaci6n simb6lica de una expresi6n. Las comparacio- 10s valores de 10s datos por debajo y por encima de 10s
nes y el flujo de control estin fuertemente emparejadas miximos y 10s minimos son muy apropiados para des-
(por ejemplo, el flujo de control cambia frecuentemente cubrir estos errores.
tras una comparaci6n). Los casos de prueba deben des-
cubrir errores como: (1) comparaciones ente tipos de
datos distintos; (2) operadores ldgicos o de precedencia lnterfaz
incorrectos; (3) igualdad esperada cuando 10s errores de Controlador
Estructuras de datos locales
precisi6n la hacen poco probable; (4) variables o com-
paraciones incorrectas; (5) terminaci6n de bucles ina- Condiciones limite
propiada o inexistente; (6) fa110 de salida cuando se Caminos independientes
encuentra una iteraci6n divergente, y (7) variables de
bucles modificadas de forma inapropiada. Caminos de maneio de errores
Un buen diseiio exige que las condiciones de error
sean previstas de antemano y que se dispongan unos
caminos de manejo de errores que redirijan o termi-
nen de una forma limpia el proceso cuando se dC un
error. Yourdon [YOU751 llama a este enfoque anti-
1
purgado. Desgraciadamente, existe una tendencia a
incorporar la manipulaci6n de errores en el software
y asi no probarlo nunca. Como ejemplo, sirve una his-
toria real: RESULl
Mediante un contrato se desarrollo un importante sistema
de diseiio interactivo. En un m d u l o de proceso de transaccie FlGURA 18.5. Entorno para la prueba de unidad.
nes, un bromista puso el siguiente mensaje de manipulaci6n de
error que aparecia tras una serie de pruebas condicionales que
invocaban varias rarnificaciones del flujo de control: iERROR! 18.3.2. Procedimientos de Prueba de Unidad
NO HAY FORMA DE QUE VD. LLEGUE HASTA AQUI. Debido a que un componente no es un programa inde-
iEste ccmensaje de error* fue descubierto por un cliente duran- pendiente, se debe desarrollar para cada prueba de uni-
te la fase de puesta a punto!
dad un software que controle y/o resguarde. En la Figura
18.5 se ilustra el entorno para la prueba de unidad. En
la mayoria de las aplicaciones, un controlador no es mis
Aseguro que tu diserio de pruebos ejecuto todos 10s cuminos que un ccprograma principal>>que acepta 10s datos del
puru encontror errores. Si no lo hoces, el cumino puede fullor caso de prueba, pasa estos datos a1 m6dulo (a ser pro-
olser invocodo, provucundu uno situocih incierto. bado) e imprime 10s resultados importantes. Los res-
guardos sirven para reemplazar mddulos que estin
subordinados (llamados por) el componente que hay
Entre 10s errores potenciales que se deben compro- que probar. Un resguardo o un ccsubprograma simula-
bar cuando se evalda la manipulaci6n de errores estin: do>>usa la interfaz del m6dulo subordinado, lleva a cab0
Descripcidn ininteligible del error. una minima manipulaci6n de datos, imprime una veri-
El error seiialado no se corresponde con el error ficaci6n de entrada y devuelve control a1 mddulo de
encontrado. prueba que lo invoc6.
La condici6n de error hace que intervenga el sistema
antes que el mecanismo de manejo de errores.
El procesamiento de la condicidn excepcional es Huy ocosiones en que no dispones de 10s recursos poro h e r
incorrecto. uno pruebo unitorio complete. En esto situocibn, selecciono
La descripci6n del error no proporciona suficiente 10s mddulos criticos y oquellos con ulto complejidod
informaci6n para ayudar en la localizaci6n de la ciclombticu y reolizu sobre ellos lo pruebo unitorio.
causa del error.
La prueba de limites es la dltima (y probablemente, Los controladores y 10s resguardos son una sobre-
la mas importante) tarea del paso de la prueba de uni- carga de trabajo. Es decir, ambos son software que debe
dad. El software falla frecuentemente en sus condicio- desarrollarse (normalmente no se aplica un disefio for-
nes limite. Es decir, con frecuencia aparece un error mal) pero que no se entrega con el product0 de soft-
cuando se procesa el elemento n-Csimo de un array n- ware final. Si 10s controladores y resguardos son
dimensional, cuando se hace la i-Csima repetici6n de un sencillos, el trabajo adicional es relativamente peque-
bucle de i pasos o cuando se encuentran 10s valores fio. Desgraciadamente, muchos componentes no pue-
den tener una adecuada prueba unitaria con un ccsenci- La prueba de unidad se simplifica cuando se disefia
l l o software
~ adicional. En tales casos, la prueba comun m6dulo con un alto grado de cohesion. Cuando un
pleta se pospone hasta que se llegue a1 paso de prueba m6dulo s610 realiza una funcibn, se reduce el nlimero
de integracicin (donde tambikn se usan controladores o de casos de prueba y 10s errores se pueden predecir y
resguardos). descubrir mas fhcilmente.
Un nedfito del mundo del software podria, una vez que se puedan probar completamente las interfaces y se pue-
se les ha hecho la prueba de unidad a todos 10s m6du- de aplicar un enfoque de prueba sistematica. En las
los, cuestionar de forma aparentemente legitima lo siguientes secciones se tratan varias estrategias de inte-
siguiente: ccSi todos funcionan bien por separado, ipor graci6n incremental diferentes.
quC dudar de que funcionen todos juntos?,, Por supues-
to, el problema es ccponerlos juntos>>(interacci6n). Los 18.4.1. Integracion descendente
datos se pueden perder en una interfaz; un m6dulo pue-
de tener un efecto adverso e inadvertido sobre otro; las La prueba de integracidn descendente es un plantea-
subfunciones, cuando se combinan, pueden no produ- miento incremental a la construcci6n de la estructura de
cir la funcidn principal deseada; la imprecisi6n acep- programas. Se integran 10s m6dulos movikndose hacia
tada individualmente puede crecer hasta niveles abajo por la jerarquia de control, comenzando por el
inaceptables; y las estructuras de datos globales pue- mddulo de control principal (programa principal). Los
den presentar problemas. Desgraciadamente, la lista m6dulos subordinados (subordinados de cualquier
sigue y sigue. modo) a1 m6dulo de control principal se van incorpo-
La prueba de integracion es una tkcnica sistematica rando en la estructura, bien de forma primero-en-pro-
para construir la estructura del programa mientras que, fundidad, o bien de forma primero-en-anchura.
a1 mismo tiempo, se llevan a cab0 pruebas para detec-
tar errores asociados con la interacci6n. El objetivo es
coger 10s modulos probados mediante la prueba de uni- Cuondo desorrollos uno plonificocibn detollodo del
dad y construir una estructura de programa que estC de proyecto debes consideror lo monero en que la
acuerdo con lo que dicta el disefio. integrocibn se vo o reolizor, de forma que 10s
componentes esth disponibles cuondo se necesiten
Efectuor uno inteyrocibn big bog es uno estroteyio vogo Como se muestra en la Figura 18.6, la integracion pri-
que estb condenodo ol fracoso. l o pruebo de inteyrocion mero-en-profundidad integra todos 10s modulos de un
deberi ser conducido incrementolmente. camino de control principal de la estructura. La selecci6n
del camino principal es, de alguna manera, arbitraria y
A menudo hay una tendencia a intentar una integra- dependera de las caractensticas especificas de la aplica-
ci6n no incremental; es decir, a construir el programa cibn. Por ejemplo, si se elige el camino de la izquierda,
mediante un enfoque de <<big bangw. Se combinan todos se integrarhn primer0 10s m6dulos M 1, M2 y M5. A con-
10s m6dulos por anticipado. Se prueba todo el progra- tinuacibn, se integrara M8 o M6 (si es necesario para un
ma en conjunto. iNormalmente se llega a1 caos! Se funcionamiento adecuado de M2). Acto seguido se cons-
encuentran un gran conjunto de errores. La correcci6n truyen 10s caminos de control central y derecho. La inte-
se hace dificil, puesto que es complicado aislar las cau- graci6n primero-en-anchura incorpora todos 10s modulos
sas a1 tener delante el programa entero en toda su exten- directamente subordinados a cada nivel, movikndose por
si6n. Una vez que se comgen esos errores aparecen otros la estructura de forma horizontal. Seglin la figura, 10s pri-
nuevos y el proceso continlia en lo que parece ser un meros m6dulos que se integran son M2, M3 y M4. A con-
ciclo sin fin. tinuaci6n, sigue el siguiente nivel de control, M5, M6, etc.
La integraci6n incremental es la antitesis del enfo- t Cuales son 10s pasos para una
que del ccbig bang>>.El programa se construye y se prue- integration top-down?
ba en pequefios segmentos en 10s que 10s errores son
mas faciles de aislar y de corregir, es mas probable que El proceso de integracidn se realiza en una serie de
cinco pasos:
Las estrategias de integracion para sistemas orientados a objetos

s e tratan en el Capitulo 23.
Se usa el m6dulo de control principal como contro- logisticos. El mis comun de estos problemas se da cuan-
lador de la prueba, disponiendo de resguardos para do se requiere un proceso de 10s niveles m8s bajos de
todos 10s m6dulos directamente subordinados a1 la jerarquia para poder probar adecuadamente 10s nive-
m6dulo de control principal. les superiores. A1 principio de la prueba descendente,
Dependiendo del enfoque de integraci6n elegido (es 10s m6dulos de bajo nivel se reemplazan por resguar-
decir, primero-en-profundidad o primero-en-anchura) dos; por tanto, no pueden fluir datos significativos hacia
se van sustiiuyendo uno a uno 10s resguardos subor- arriba por la estructura del prograrna. El responsable de
dinados por 10s m6dulos reales. la prueba tiene tres opciones: (1) retrasar muchas de las
Se llevan a cab0 pruebas cada vez que se integra un pruebas hasta que 10s resguardos Sean reemplazados por
nuevo m6dulo. 10s mbdulos reales; (2) desarrollar resguardos que rea-
licen funciones limitadas que simulen 10s m6dulos rea-
Tras terminar cada conjunto de pruebas, se reem- les; o (3) integrar el software desde el fondo de la
plaza otro resguardo con el m6dulo real. jerarquia hacia arriba.
Se hace la prueba de regresi6n (Secci6n 18.4.3)
para asegurarse de que no se han introducido erro- LQue problemas puedes encontrar
res nuevos. cuando ellas una estrategia
El proceso continua desde el paso 2 hasta que se haya de integration descendente?
construido la estructura del programa entero.
El primer enfoque (retrasar pruebas hasta reempla-
zar 10s resguardos por 10s m6dulos reales) hace que per-
damos cierto control sobre la correspondencia de ciertas
pruebas especificas con la incorporaci6n de determina-
dos m6dulos. Esto puede dificultar la determinaci6n de
las causas del error y tiende a violar la naturaleza alta-
mente restrictiva del enfoque descendente. El segundo
enfoque es factible per0 puede llevar a un significativo
increment0 del esfuerzo a medida que 10s resguardos se
hagan mis complejos. El tercer enfoque, denominado
n
FIGURA 18.6. Integracion descendente,
prueba ascendente, se estudia en la siguiente secci6n.
18.4.2. Integracih ascendente

La prueba de la integraci6n ascendente, como su nom-
La estrategia de integraci6n descendente verifica 10s
bre indica, empieza la construcci6n y la prueba con 10s
puntos de decision o de control principales a1 principio
mddulos at6micos (es decir, m6dulos de 10s niveles rnis
del proceso de prueba. En una estructura de prograrna bien
bajos de la estructura del programa). Dado que 10s
fabricada, la toma de decisiones se da en 10s niveles supe-
modulos se integran de abajo hacia arriba, el proceso
riores de la jerarquia y, por tanto, se encuentran antes. Si
requerido de 10s m6dulos subordinados siempre esti
existen problemas generales de control, es esencial reco-
disponible y se elimina la necesidad de resguardos.
nocerlos cuanto antes. Si se selecciona la integraci6n pri-
mero en profundidad, se puede ir implementando y iCu6les son 10s pasos para
demostrando las funciones completas del software. Por una integration ascendente?
ejemplo, considere una estructura clisica de uansacci6n
(Capitulo 14) en la que se requiere una compleja serie de Se puede implementar una estrategia de integraci6n
entradas interactivas, obtenidas y validadas por medio de ascendente mediante 10s siguientes pasos:
un camino de entrada. Ese carnino de enuada puede ser Se combinan 10s m6dulos de bajo nivel en grupos (a
integrado en forma descendente.Asi, se puede demostrar veces denominados construcciones) que realicen una
todo el proceso de entradas (para posteriores operaciones subfunci6n especifica del software.
de transacci6n) antes de que se integren otros elementos
Se escribe un controlador (un programa de control
de la estructura. La demostraci6n anticipada de las posi-
de la prueba) para coordinar la entrada y la salida de
bilidades funcionales es un generador de confianza tanto
10s casos de prueba.
para el desarrollador como para el cliente.
Se prueba el grupo.
Se eliminan 10s controladores y se combinan 10s gru-
pos movikndose hacia arriba por la estructura del
programa.
La integracibn sigue el esquema ilustrado en la Figu-
La estrategia descendente parece relativamente ficil, 18.7. Se combinan 10s m6dulos para formar 10s gru-
pero, en la prictica, pueden surgir algunos problemas pos 1 , 2 y 3. Cada uno de 10s grupos se somete a prueba
mediante un controlador (mostrado como un bloque o 10s datos que lo soportan). La prueba de regresi6n es
. punteado). Los mddulos de 10s grupos 1 y 2 son subor- la actividad que ayuda a asegurar que 10s cambios (debi-
dinados de Ma. Los controladores Dl y D2 se eliminan dos a las pruebas o por otros motivos) no introducen un
y 10s grupos interaccionan directamente con Ma. De for- comportamiento no deseado o errores adicionales.
ma similar, se elimina el controlador D, del grupo 3
antes de la integraci6n con el m6dulo Mb. Tanto Ma
como Mb se integrarh finalmente con el m6dulo M, y
asi sucesivamente. l o pruebo de regresibnes uno estrotegio importanteporo
reducir ~efectoscoloteroles)). Se deben ejecutor pruebas
de regresibn coda vez que se reolice un cambia
importante en el softwore (incluyendo lo integrocibn de
nuevos mbdulos).
lo integrocion ascendente elimino lo La prueba de regresidn se puede hacer manualmen-
necesidod de resguordos complejos. te, volviendo a realizar un subconjunto de todos 10s
casos de prueba o utilizando herramientas automiticas
A medida que la integraci6n progresa hacia arriba, de reproducci6n de captura. Las herrarnientas de repro-
disminuye la necesidad de controladores de prueba dife- ducci6n de captura permiten a1 ingeniero del softwa-
rentes. De hecho, si 10s dos niveles superiores de la re capturar casos de prueba y 10s resultados para la
estructura del programa se integran de forma descen- subsiguiente reproducci6n y comparaci6n. El conjun-
dente, se puede reducir sustancialmente el ndmero de to de pruebas de regresidn (el subconjunto de pruebas
controladores y se simplifica enormemente la integra- a realizar) contiene tres clases diferentes de casos de
cion de grupos. prueba:
una muestra representativa de pruebas que ejercite
18.4.3. Prueba de regresi6n todas las funciones del software;
Cada vez que se aiiade un nuevo m6dulo como parte de pruebas adicionales que se centran en las funciones
una prueba de integracibn, el software cambia. Se esta- del software que se van a ver probablemente afecta-
blecen nuevos caminos de flujo de datos, pueden ocu- das por el cambio;
rrir nuevas E/S y se invoca una nueva 16gica de control. pruebas que se centran en 10s componentes del soft-
Estos cambios pueden causar problemas con funciones
ware que han cambiado.
que antes trabajaban perfectamente. En el contexto de
A medida que progresa la prueba de integracibn, el
una estrategia de prueba de integracibn, la prueba de
numero de pruebas de regresi6n puede crecer demasia-
regresibn es volver a ejecutar un subconjunto de prue-
do. Por tanto, el conjunto de pruebas de regresidn debe-
bas que se han llevado a cab0 anteriormente para ase-
ria diseiiarse para incluir s610 aquellas pruebas que traten
gurarse de que 10s cambios no han propagado efectos
una o mis clases de errores en cada una de las funcio-
colaterales no deseados.
nes principales del programa. No es prhctico ni eficiente
volver a ejecutar cada prueba de cada funci6n del pro-
grama despuCs de un cambio.
18.4.4. Prueba de hum0

La prueba de hum0 es un mCtodo de prueba de inte-
graci6n que es comdnmente utilizada cuando se ha
desarrollado un producto software ccempaquetado,,.
Es diseiiado como un mecanismo para proyectos cri-
ticos por tiempo, permitiendo que el equipo de soft-
ware valore su proyecto sobre una base s6lida. En
esencia, la prueba de hum0 comprende las siguientes
dl 1'Grupo I
FIGURA 18.7. Integracion ascendente.

GrupO
actividades:
1. Los componentes software que han sido traducidos
a cbdigo se integran en una crconstrucci6n>>.Una
construcci6n incluye ficheros de datos, librerias,
m6dulos reutilizables y componentes de ingenieria
En un contexto mhs amplio, las pruebas con Cxito que se requieren para implementar una o mis fun-
(de cualquier tipo) dan como resultado el descubrimiento ciones del producto.
de errores, y 10s errores hay que corregirlos. Cuando se
corrige el software, se cambia algdn aspect0 de la con- 2. Se diseiia una serie de pruebas para descrubir erro-
figuraci6n del software (el programa, su documentacidn res que impiden a la construcci6n realizar su fun-
C A P ~ T U L O18 ESTRATEGIAS DE PRUEBA DEL SOFTWARE
cidn adecuadamente. El objetivo seri descubrir erro- integracidn, es probable que 10s errores sin descu-
res <<bloqueantes>>
que tengan la mayor probabili- brir durante la prueba de hum0 se asocien a <<nuevos
dad de impedir a1 proyecto de software el incrementos de softwarel, - e s t o es, el software que
cumplimiento de su planificacidn. se acaba de aiiadir a la construccidn es una posible
Es habitual en la prueba de hum0 que la construccidn causa de un error que se acaba de descubrir-.
se integre con otras construcciones y que se aplica una El progreso es fcicil de observar. Cada dia que pasa,
prueba de hum0 a1 producto completo (en su forma se integra m i s software y se demuestra que fun-
actual). La integracidn puede hacerse bien de forma ciona. Esto mejora la moral del equipo y da una
descendente (top-down)o ascendente (bottom-up). indicacidn a 10s gestores del progreso que se esti
realizando.
18.4.5. Comentarios sobre la prueba de inte-

Lo pruebo de humo se corocterizo por uno estrotegio de integroci6n graci6n
continuo. El softwore es reconfigurodo (con lo incorporoci6n de Ha habido muchos estudios (por ejemplo, [BEI84])
nuevos componentes) y utilizado continuomente. sobre las ventajas y desventajas de la prueba de inte-
gracidn ascendente frente a la descendente. En gene-
La frecuencia continua de la ~ r u e b ac o m ~ l e t adel ral, las ventaias de una estrategia
- tienden a convertirse
producto puede sorprender a algunos lectores. En cual- en desventajas para la otra estrategia. La principal des-
quier caso, las frecuentes pruebas dan a gestores y pro- ventaja del enfoque descendente es la necesidad de
fesionales una valoracidn realista de la evolucidn de las resguardos y las dificultades de prueba que pueden
pruebas de integracidn. McConnell [MC096] describe estar asociados con ellos. Los problemas asociados
la prueba de hum0 de la siguiente forma: con 10s resguardos pueden quedar compensados por
La prueba de hum0 ejercita el sistema entero de prin- la ventaja de poder probar de antemano las principa-
cipio a fin. No ha de ser exhaustiva, per0 serB capaz de les funciones de control. La principal desventaja de la
descubrir importantes problemas. La prueba de hum0 sera integracidn ascendente es que <<elprograma como enti-
suficiente si verificamos de forma completa la construc- dad no existe hasta que se ha afiadido el 6ltimo modu-
ci6n y podemos asumir que es suficientemente estable para
ser probado con mas profundidad.
l o [MYE79].
~ Este inconveniente se resuelve con la
mayor facilidad de disefio de casos de prueba y con la
La prueba de hum0 facilita una serie de beneficios falta de resguardos.
cuando se aplica sobre proyectos de ingenieria del soft-
ware complejos y cn'ticos por su duracidn:
iQu4 es un modulo critico y
Se minimizan 10s riesgos de integracidn. Dado que por qu4 debemos identificarlo?
las pruebas de hum0 son realizadas frecuentemente,
incompatibilidades y otros errores bloqueantes son La seleccidn de una estrategia de integracidn
descubiertos ripidamente, por eso se reduce la posi- depende de las caracteristicas del software y, a veces,
bilidad de impactos importantes en la planificacidn de la planificacidn del proyecto. En general, el mejor
por errores sin descubrir. compromiso puede ser un enfoque combinado (a veces
Se perfecciona la calidad del producto final. Dado denominado prueba sandwich) que use la descendente
que la prueba de hum0 es un mitodo orientado a la para 10s niveles superiores de la estructura del pro-
construccidn (integracidn), es probable que descu- grama, junto con la ascendente para 10s niveles subor-
bra errores funcionales, ademis de defectos de disefio dinados.
a nivel de componente y de arquitectura. Si estos A medida que progresa la prueba de integracidn,
defectos se comgen ripidamente, el resultado seri el responsable de las pruebas debe identificar 10s
un producto de gran calidad. mddulos criticos. Un mddulo critico es aquel que tie-
ne una o mis de las siguientes caracteristicas: (1) esti
dirigido a varios requisitos del software; (2) tiene un
mayor nivel de control (esti relativamente alto en la
estructura del programa); (3) es complejo o propen-
so a errores (se puede usar la complejidad ciclomiti-
ca como indicador); o (4) tiene unos requisitos de
rendimiento muy definidos. Los mddulos criticos
deben probarse lo antes posible. Ademis, las pruebas
Se simplifican el diagndstico y la correccidn de erro- de regresidn se deben centrar en el funcionamiento de
res. A1 igual que todos 10s enfoques de prueba de 10s mddulos criticos.
Tras la culminaci6n de la prueba de integration, el soft- 18.5.2. Revision de la configuracibn

ware esth completamente ensamblado como un paque- Un elemento importante del proceso de validacion es la
te, se han encontrado y corregido 10s errores de interfaz revisidn de la configuracidn. La intencion de la revision
y puede comenzar una serie final de pruebas del soft- es asegurarse de que todos 10s elementos de la confi-
ware: laprueba de validacidn. La validacion puede defi- guracion del software se han desarrollado apropiada-
nine de muchas formas, pero una simple (aunque vulgar) mente, se han catalogado y esthn suficientemente
definicion es que la validacion se consigue cuando el detallados para soportar la fase de mantenimiento duran-
software funciona de acuerdo con las expectativas razo- te el ciclo de vida del software. La revision de la confi-
nables del cliente. En este punto, un desarrollador de guracion, a veces denominada auditoria, se ha estudiado
software estricto podria protestar: cciQuC o quiCn es el con mhs detalle en el Capitulo 9.
6rbitro de las expectativas razonables?>>
18.5.3. Pruebas alfa y beta
Es virtualmente imposible que un desarrollador de soft-
ware pueda prever c6mo utilizara el usuario realmente
Como en otros etopos de lo pruebo, lo volidoci6n permite el programa. Se pueden malinterpretar las instruccio-
descubrir errores, pero su enfoque esta en el nivel de nes de uso, se pueden utilizar habitualmente extraiias
requisitos --sobre cosos que son necesorios para el combinaciones de datos, y una salida que puede pare-
usuorio finol-. cer clara para el responsable de las pruebas y puede ser
ininteligible para el usuario.
Las expectativas razonables esthn definidas en la Cuando se construye software a medida para un clien-
Especificacion de Requisitos del Software -un docu- te, se llevan a cab0 una serie de pruebas de aceptacidn
mento (Capitulo 12) que describe todos 10s atributos del para permitir que el cliente valide todos 10s requisitos.
software visibles para el usuario. La especificacion con- Las realiza el usuario final en lugar del responsable del
tiene una secci6n denominada-. cccriterios de valida- desarrollo del sistema, una prueba de aceptacion puede
cibn>>.La informacion contenida en esa secci6n forma ir desde un informal ccpaso de prueba>>hasta la ejecucion
la base del enfoque a la prueba de validacion. sistematica de una serie de pruebas bien planificadas. De
hecho, la prueba de aceptacion puede tener lugar a lo
largo de semanas o meses, descubriendo asi errores acu-
18.5.1. Criterios de l a prueba de v a l i d a c i h mulados que pueden ir degradando el sistema.
La validacion del software se consigue mediante una Si el software se desarrolla como un producto que
serie de pruebas de caja negra que demuestran la con- va a ser usado por muchos clientes, no es pr6ctico rea-
formidad con 10s requisitos. Un plan de prueba traza lizar pruebas de aceptacion formales para cada uno de
la clase de pruebas que se han de llevar a cabo, y un ellos. La mayorfa de 10s desarrolladores de productos
procedimiento de prueba define 10s casos de prueba de software llevan a cab0 un proceso denominado prue-
especificos en un intento por descubrir errores de ba alfa y beta para descubrir errores que parezca que
acuerdo con 10s requisitos. Tanto el plan como el pro- s610 el usuario final puede descubrir.
cedimiento estaran disefiados para asegurar que se La prueba alfa se lleva a cabo, por un cliente, en el
satisfacen todos 10s requisitos funcionales, que se lugar de desarrollo. Se usa el software de forma natu-
alcanzan todos 10s requisitos de rendimiento, que la ral con el desarrollador como obsemador del usuario y
documentation es correcta e inteligible y que se alcan- registrando 10s errores y 10s problemas de uso. Las prue-
zan otros requisitos (por ejemplo, portabilidad, com- bas alfa se llevan a cab0 en un entomo controlado.
patibilidad, recuperation de errores, facilidad de Laprueba beta se lleva a cab0 por 10s usuarios fina-
mantenimiento). les del software en 10s lugares de trabajo de 10s clien-
Una vez que se procede con cada caso de prueba de tes. A diferencia de la prueba alfa, el desarrollador no
validacion, puede darse una de las dos condiciones est6 presente normalmente. Asi, la prueba beta es una
siguientes: (1) las caracteristicas de funcionamiento o aplicacion ccen viva>> del software en un entomo que no
de rendimiento esthn de acuerdo con las especificacio- puede ser controlado por el desarrollador. El cliente
nes y son aceptables; o (2) se descubre una desviacion registra todos 10s problemas (reales o imaginaries) que
de las especificaciones y se crea una lista de deficien- encuentra durante la prueba beta e informa a intemalos
cias. Las desviaciones o errores descubiertos en esta regulares a1 desarrollador. Como resultado de 10s pro-
fase del proyecto raramente se pueden corregir antes blemas informados durante la prueba beta, el desarro-
de la terrninacion planificada. A menudo es necesario llador del software lleva a cab0 modificaciones y asi
negociar con el cliente un mCtodo para resolver las defi- prepara una version del producto de software para toda
ciencias. la clase de clientes.
C A P ~ T U L O18 ESTRATEGIAS DE PRUEBA DEL SOFTWARE
A1 comienzo de este libro, pusimos Cnfasis en el hecho

de que el software es solo un elemento de un sistema
mayor basado en computadora. Finalmente, el softwa-
re es incorporado a otros elementos del sistema (por Referencia web /'
ejemplo, nuevo hardware, informacion) y realizan una Amplio informocion sobre la prueba del software y su
serie de pruebas de integracion del sistema y de vali- relocion con 10s necesidades de calidad pueden obtenerse
dacion. Estas pruebas caen fuera del iimbito del proce- en www.stqe.net
so de ingenieria del software y no las realiza unicamente En otros casos, se debe corregir un fallo del sistema
el desarrollador del software. Sin embargo, 10s pasos en un determinado period0 de tiempo para que no se
dados durante el disefio del software y durante la prue- produzca un serio dafio economico.
ba pueden mejorar enormemente la probabilidad de kxi- La prueba de recuperacibn es una prueba del siste-
to en la integracion del software en el sistema. ma que fuerza el fallo del software de muchas formas
y verifica que la recuperacion se lleva a cab0 apropia-
damente. Si la recuperacion es automiitica (llevada a
erte y o los impuestos, la prueba cab0 por el propio sistema) hay que evaluar la correc-
evitable. cion de la inicializacion, de 10s mecanismos de recupe-
raci6n del estado del sistema, de la recuperacion de datos
y del proceso de rearranque. Si la recuperacion requie-
re la intervention humana, hay que evaluar 10s tiempos
Un problema tipico de la prueba del sistema es la medios de reparation (TMR) para determinar si estin
ccdelegacion de culpabilidad,,. Esto ocurre cuando se dentro de unos limites aceptables.
descubre un error y cada uno de 10s creadores de cada
elemento del sistema echa la culpa del problema a 10s
otros. En vez de verse envuelto en esta absurda situa- 18.6.2. Prueba d e seguridad
cion, el ingeniero del software debe anticiparse a 10s Cualquier sistema basado en computadora que maneje
posibles problemas de interaction y: (1) disefiar cami- informacion sensible o lleve a cab0 acciones que pue-
nos de manejo de errores que prueben toda la infor- dan perjudicar (o beneficiar) impropiamente a las per-
maci6n procedente de otros elementos del sistema; (2) sonas es un posible objetivo para entradas impropias o
llevar a cab0 una serie de pruebas que simulen la pre- ilegales a1 sistema. Este acceso a1 sistema incluye un
sencia de datos en ma1 estado o de otros posibles erro- amplio rango de actividades: ccpiratas inform6ticos~
res en la interfaz del software; (3) registrar 10s que intentan entrar en 10s sistemas por deporte, emplea-
resultados de las pruebas como ccevidencia,, en el caso dos disgustados que intentan penetrar por venganza e
de que se le seiiale con el dedo; (4) participar en la pla- individuos deshonestos que intentan penetrar para obte-
nificacion y el disefio de pruebas del sistema para ase- ner ganancias personales ilicitas.
gurarse de que el software se prueba de forma La prueba de seguridad intenta verificar que 10s
adecuada. mecanismos de proteccion incorporados en el sistema
La prueba del sistema, realmente, esti constituida lo protegeran, de hecho, de accesos impropios. Para citar
por una serie de pruebas diferentes cuyo proposito pri- a Beizer [BEI84]: ccPor supuesto, la seguridad del sis-
mordial es ejercitar profundamente el sistema basado tema debe ser probada en su invulnerabilidad frente a
en computadora. Aunque cada prueba tiene un propo- un ataque frontal, pero ta~nbiCndebe probarse en su
sito diferente, todas trabajan para verificar que se han invulnerabilidad a ataques por 10s flancos o por la reta-
integrado adecuadamente todos 10s elementos del sis- guardia.))
tema y que realizan las funciones apropiadas. En las Durante la prueba de seguridad, el responsable de la
siguientes secciones examinamos 10s tipos de pruebas prueba desempefia el papel de un individuo que desea
del sistema [BE1841 valiosos para sistemas basados en entrar en el sistema. ~ T o vale!
~ o Debe intentar conse-
software. guir las claves de acceso por cualquier medio, puede
atacar a1 sistema con software a medida, diseiiado para
romper cualquier defensa que se haya construido, debe
18.6.1. Prueba d e recuperacion bloquear el sistema, negando asi el servicio a otras per-
Muchos sistemas basados en computadora deben recu- sonas, debe producir a proposito errores del sistema,
perarse de 10s fallos y continuar el proceso en un tiem- intentando acceder durante la recuperacion o debe curio-
po previamente especificado. En algunos casos, un sear en 10s datos sin proteccion, intentando encontrar la
sistema debe ser tolerante con 10s fallos; es decir, 10s clave de acceso a1 sistema, etc.
fallos del proceso no deben hacer que cese el funcio- Con tiempo y recursos suficientes, una buena prue-
namiento de todo el sistema. ba de seguridad terminari por acceder a1 sistema. El
papel del diseiiador del sistema es hacer que el coste de situaciones (la mas com6n se da con algoritmos mate-
la entrada ilegal sea mayor que el valor de la informa- maticos), un rango de datos muy pequeiio dentro de
ci6n obtenida. 10s limites de una entrada vhlida para un prograrna pue-
de producir un proceso exagerado e incluso erroneo o
una profunda degradacidn del rendimiento. Esta situa-
ci6n es aniloga a una singularidad en una funci6n
matematica. La prueba de sensibilidad intenta descu-
brir combinaciones de datos dentro de una clase de
entrada vilida que pueda producir inestabilidad o un
proceso incorrecto.
18.6.4. Prueba d e rendimiento

18.6.3. Prueba d e resistencia (Stress) Para sistemas de tiempo real y sistemas empotrados,
Durante 10s pasos de prueba anteriores, las tCcnicas de es inaceptable el software que proporciona las fun-
caja blanca y de caja negra daban como resultado la eva- ciones requeridas per0 no se ajusta a 10s requisitos de
luaci6n del funcionamiento y del rendimiento norma- rendimiento. La prueba de rendimiento esta diseiiada
les del programa. Las pruebas de resistencia estan para probar el rendimiento del software en tiempo de
diseiiadas para enfrentar a 10s programas con situacio- ejecuci6n dentro del context0 de un sistema integra-
nes anormales. En esencia, el sujeto que realiza la prue- do. La prueba de rendimiento se da durante todos 10s
ba de resistencia se pregunta: <<LA quC potencia puedo pasos del proceso de la prueba. Incluso a1 nivel de uni-
ponerlo a funcionar antes de que falle?>> dad, se debe asegurar el rendimiento de 10s m6dulos
Laprueba de resistencia ejecuta un sistema de for- individuales a medida que se llevan a cab0 las prue-
ma que demande recursos en cantidad, frecuencia o bas de caja blanca. Sin embargo, hasta que no estin
vol6menes anormales. Por ejemplo: (1) diseiiar prue- completamente integrados todos 10s elementos del sis-
bas especiales que generen diez interrupciones por tema no se puede asegurar realmente el rendimiento
segundo, cuando las normales son una o dos; (2) incre- del sistema.
mentar las frecuencias de datos de entrada en un orden Las pruebas de rendimiento, a menudo, van empa-
de magnitud con el fin de comprobar c6mo respon- rejadas con las pruebas de resistencia y, frecuentemen-
den las funciones de entrada; (3) ejecutar casos de te, requieren instrumentacibn tanto de software como
prueba que requieran el maxim0 de memoria o de de hardware. Es decir, muchas veces es necesario medir
otros recursos; (4) diseiiar casos de prueba que pue- la utilizaci6n de recursos (por ejemplo, ciclos de pro-
dan dar problemas en un sistema operativo virtual o cesador), de un mod0 exacto. La instrumentaci6n exter-
(5) diseiiar casos de prueba que produzcan excesivas na puede monitorizar 10s intervalos de ejecucion, 10s
b6squedas de datos residentes en disco. Esencial- sucesos ocurridos (por ejemplo, intermpciones) y mues-
mente, el responsable de la prueba intenta romper el tras de 10s estados de la maquina en un funcionamien-
programa. to normal. Instrumentando un sistema, el encargado de
Una variante de la prueba de resistencia es una tCc- la prueba puede descubrir situaciones que lleven a d e w -
nica denominada prueba de sensibilidad. En algunas daciones y posibles fallos del sistema.
La prueba del software es un proceso que puede plani- ware. Es decir, la manifestaci6n extema de un error, y
ficarse y especificarse sistemiticamente. Se puede Ile- la causa interna del error pueden no estar relacionados
var a cab0 el diseiio de casos de prueba, se puede definir de una forma obvia. El proceso mental, apenas com-
una estrategia y se pueden evaluar 10s resultados en comprendido, que conecta un sintoma con una causa es la
paraci6n con las expectativas prescritas. depuraci6n.
La depuracibn ocurre como consecuencia de una
prueba efectiva. Es decir, cuando un caso de prueba des-
cubre un error, la depuraci6n es el proceso que provo-
ca la eliminaci6n del error. Aunque la depuraci6n puede Referencia web/ '
y debe ser un proceso ordenado, sigue teniendo mucho BugNet focilito informocibnsobre problemos de seguridad
de arte. Un ingeniero del software, a1 evaluar 10s resul- y follos en software bosodo en PC y proporciono una
tados de una prueba, se encuentra frecuentemente con informocibn ulil sobre temos de depurocih:
una indicaci6n c<sintomitica>> de un problema en el soft- www.bugnet.com
C A P ~ T U L O18 ESTRATEGIAS DE PRUEBA DEL S O F T W A R E
18.7.1. El Proceso de depuracion 7. El sintoma puede aparecer de forma intermitente.

La depuracion no es una prueba, per0 siempre ocurre Esto es particularmente corriente en sistemas empo-
como consecuencia de la prueba4. Como se muestra en trados que acoplan el hardware y el software de
la Figura 18.8, el proceso de depuracion comienza con manera confusa.
la ejecucion de un caso de prueba. Se evallian 10s resul- 8. El sintoma puede ser debido a causas que se distri-
tados y aparece una falta de correspondencia entre 10s buyen por una serie de tareas ejecutindose en dife-
esperados y 10s encontrados realmente. En muchos casos, rentes procesadores [CHE90].
10s datos que no concuerdan son un sintoma de una cau- Durante la depuracion encontramos errores que van
sa subyacente que todavia permanece oculta. El proce- desde lo ligeramente inesperado (por ejemplo, un for-
so de depuracion intenta hacer corresponder el sistema mato de salida incorrecto) hasta lo catastrofico (por
con una causa, llevando asi a la correcci6n del error. ejemplo, el sistema falla, producikndose serios dafios
El proceso de depuracion siempre tiene uno de 10s econ6micos o fisicos). A medida que las consecuencias
dos resultados siguientes: (1) se encuentra la causa, se de un error aumentan, crece la presion por encontrar su
conige y se elimina; o (2) no se encuentra la causa. En causa. A menudo la presion fuerza a un ingeniero del
este liltimo caso, la persona que realiza la depuracion software a corregir un error introduciendo dos mas.
debe sospechar la causa, disefiar un caso de prueba que
ayude a confirmar sus sospechas y el trabajo vuelve hacia
atris a la correction del error de una forma iterativa.
~ P o quC
r es tan dificil la depuracion'? Todo parece
indicar que la respuesta tiene mas que ver con la psico-
logia humana (vkase la siguiente section) que con la
tecnologia del software. Sin embargo, varias caracte-
risticas de 10s errores nos dan algunas pistas:
El sintoma y la causa pueden ser geograficamente
remotos entre si. Es decir, el sintoma puede apare-
cer en una parte del programa, mientras que la causa
esta localizada en otra parte muy alejada. Las estruc- ldentificadas
turas de programa fuertemente acopladas (Capitulo
13) resaltan esta situation. FIGURA 18.8. El proceso de depuracion.
El sintoma puede desaparecer (temporalmente) a1
corregir otro error. 18.7.2. Consideraciones psicoldgicas
El sintoma puede realmente estar producido por algo Desafortunadamente, todo parece indicar que la habili-
que no es un error (por ejemplo, inexactitud en 10s dad en la depuracion es un rasgo innato del ser huma-
redondeos). no. A ciertas personas se les da bien y a otras no. Aunque
las manifestaciones experimentales de la depuracion
El sintoma puede estar causado por un error humano estan abiertas a muchas interpretaciones, se han detec-
que no sea ficilmente detectado. tad0 grandes variaciones en la destreza para la depura-
El sintoma puede ser el resultado de problemas de cion de distintos programadores con el mismo bagaje
temporizaci6n en vez de problemas de proceso. de formaci6n y de experiencia.
Puede ser dificil reproducir exactamente las condi- Hablando de 10s aspectos humanos de la depuracion,
ciones de entrada (por ejemplo, una aplicacion de Shneiderman [SHN80] manifiesta:
tiempo real en la que el orden de la entrada no esti
La depuracidn es una de las partes m6s frustrantes de la pro-
determinado). gramacion. Contiene elementos de resolucidn de problemas o
de rompecabezas,junto con el desagradable reconocimiento de
que se ha cometido un error. La enorme ansiedad y la no incli-
nacidn a aceptar la posibilidad de cometer errores hace que la
tarea sea extremadamente dificil. Afortunadamente, tambiCn se
da un gran alivio y disminuye la tension cuando el error es final-
mente...corregido.
Aunque puede resultar dificil <caprender>>
a depurar,
se pueden proponer varios enfoques del problema. En
la siguiente section 10s examinamos.
A1 decir esta frase, tomarnos el punto de vista mas amplio que se

puede tener de la prueba. No solo ha de llevar a cab0 la prueba el
equipo de desarrollo antes de entregar el software, sin0 que el
cliente/usuario prueba el software cada vez que lo usa.
I N G E N I E R ~ ADEL S O F T W A R E . UN E N F O Q U E PRACTICO
18.7.3. Enfoques de la depuraci6n datos relacionados con la ocurrencia del error se orga-
'Independientemente del enfoque que se utilice, la depu- nizan para aislar las posibles causas. Se llega a una
racion tiene un objetivo primordial: encontrar y corre- cchip6tesis de causau y se usan 10s datos antenores para
gir la causa de un error en el software. El objetivo se probar o revocar la hipotesis. Altemativamente, se desa-
consigue mediante una combinaci6n de una evaluaci6n rrolla una lista de todas las posibles causas y se llevan
sistemhtica, de intuici6n y de suerte. Bradley [BRA851 a cab0 pruebas para eliminar cada una. Si alguna prue-
describe el enfoque de la depuraci6n de la siguiente ba inicial indica que determinada hip6tesis de causa en
forma: particular parece prometedora, se refinan 10s datos con
el fin de intentar aislar el error.
La depuracion es una aplicacion directa del mCtodo cienti-
tico desarrollado hace 2.500 aiios. La base de la depuraci6n es Cada uno de 10s enfoques anteriores puede comple-
la localization de la fuente del problema [la causa] mediante mentarse con herramientas de depuracih. Podemos usar
particion binaria, manejando hip6tesis que predigan nuevos una gran cantidad de compiladores de depuracion, ayu-
valores a examinar. das dinimicas para la depuraci6n (cctrazadoress), gene-
Tomemos un sencillo ejemplo que no tiene que ver con el radores autom5ticos de casos de prueba, volcados de
software: en mi casa no funciona una Iampara. Si no funciona memoria y mapas de referencias cruzadas. Sin embar-
nada en la casa, la causa debe estar en el circuito principal de go, las herramientas no son un sustituto de la evalua-
fusibles o fuera de la casa; miro fuera para ver si hay un apa- ci6n cuidadosa basada en un completo documento del
g6n en todo el vecindario. Conecto la sospechosa lampara a un
enchufe que funcione y un aparato que funcione en el circuito
diseiio del software y un c6digo fuente claro.
sospechoso.Asi se sigue la secuencia de hipotesis y de pruebas.
En general, existen tres enfoques que se pueden pro-
poner para la depuracion [MYE79]:
I. Fuerza bruta
2. Vuelta atras Herromientos CASE
3. Eliminacion de causas Prueba y Depurocibn.
La categoria de depuracion por lafiterza bruta es
probablemente la mis comun y menos eficiente a la hora Cualquier discusion sobre 10s enfoques para la depu-
de aislar la causa del error en el software. Aplicamos raci6n y sus herramientas no estaria completa sin men-
10s mCtodos de depuracion por fuerza bruta cuando todo cionar un poderoso aliado: jotras personas! Cualquiera
lo demas falla. Mediante una filosofia de ccdejar que la de nosotros podri recordar haber estado dando vueltas
computadora encuentre el error>>,se hacen volcados de en la cabeza durante horas o dias a un error persisten-
memoria, trazas de ejecuci6n y se cargan multitud de te. Desesperados, le explicamos el problema a un cole-
sentencias Mostrar en el programa. Esperamos que en ga con el que damos por casualidad y le mostramos el
algun lugar de la gran cantidad de informacion genera- listado. Instanthneamente (parece), se descubre la cau-
da encontremos alguna pista que nos lleve a la causa de sa del error. Nuestro colega se aleja sonriendo ladina-
un error. Aunque la gran cantidad de informaci6n pro- mente. Un punto de vista fresco, no embotado por horas
ducida nos puede llevar finalmente a1 Cxito, lo m& fre- de frustracion, puede hacer maravillas. Una maxima
cuente es que se desperdicie tiempo y esfuerzo. iPrimer0 final para la depuraci6n puede ser: cciCuando todo lo
se debe usar la inteligencia! demits falle, pide ayuda! u
Una vez que se ha encontrado un error, hay que corre-
girlo. Pero como ya hemos podido observar, la correc-
F@te un tiempo limitado, por ejemplo dos ham, cion de un error puede introducir otros errores y hacer
en relacion o lo contidod de tiempo que tu inviertes m8s ma1 que bien.
porn depuror un problemo de tu incumbencio.
Despub qu& jpide oyudo! Cuando torrijo un error,
iqu6 tuestiones deb0
La vuelta atrcis es un enfoque miis normal para la preguntarme a mi mismo?
depuraci611, que se puede usar con Cxito para pequeiios
programas. Partiendo del lugar donde se descubre el sin- Van Vleck [VAN891 sugiere tres preguntas sencillas
toma, se recorre hacia atris (manualmente) el c6digo que deben'a preguntarse todo ingeniero del software antes
fuente hasta que se llega a la posici6n de error. Des- de hacer la cccorreccion~>que elimine la causa del error:
graciadamente, a medida que aumenta el numero de iSe repite la causa del error en otra parte del pro-
lineas del c6dig0, el numero de posibles caminos de g r a m ~ ?En muchas situaciones, el defect0 de un pro-
vuelta se hace dificilmente manejable. grama esta producido por un patron de logica erroneo
El tercer enfoque para la depuraci6n -eliminacidn que se puede repetir en cualquier lugar. La conside-
de causas- se manifiesta mediante induceion o deduc- raci6n explicita del patron logico puede terminar en
ci6n e introduce el concept0 de partici6n binaria. Los el descubrimiento de otros errores.
i C u d es el aiguiente error))que se podra presentar a 3. iQu.6 podriamos haber hecho para prevenir este
raiz de la correccibn que hoy voy a realizar? Antes de error la primera vez? Esta pregunta es el primer paso
hacer la correcci6n, se debe evaluar el c6digo fuente (o para establecer un mCtodo estadistico de garantia de
mejor, el dserio) para determinar el emparejamientode calidad del software (Capitulo 8). Si corregimos tanto
la 16gica y las estructuras de datos. Si la correcci6n se el proceso como el producto, se eliminarh el error
realiza en una seccidn del programa altamente acoplada, del programa actual y se puede eliminar de todos 10s
se debe tener cuidado a1 realizar cualquier cambio. futuros programas.
La pmeba del software contabiliza el mayor porcenta- A diferencia de la prueba (una actividad sistemhtica
je del esfuerzo tCcnico del proceso de desarrollo de soft- y planificada), la depuraci6n se puede considerar un arte.
ware. Todavia estamos comenzando a comprender las A partir de una indicacidn sintomhtica de un problema,
sutilezas de la planificacidn sistemhtica de la pmeba, de la actividad de la depuracion debe rastrear la causa del
su ejecucion y de su control. error. De entre 10s recursos disponibles durante la depu-
El objetivo de la prueba de software es descubrir racidn, el mhs valioso puede ser el apoyo de otros inge-
errores. Para conseguir este objetivo, se planifica y se nieros de software.
ejecutan una serie de pasos; pmebas de unidad, de inte- El requisito de que el software sea cada vez de mayor
gracidn, de validacion y del sistema. Las pmebas de uni- calidad exige un planteamiento mhs sistemhtico de la
dad y de integraci6n se centran en la verificacidn prueba. Citando a Dunn y Ullman [DUN82]:
funcional de cada m6dulo y en la incorporaci6n de 10s
m6dulos en una estructura de programa. La pmeba de Lo que se requiere es una estrategia global, que se extienda
por el espacio eshatkgico de la prueba, tan deliberadaen su meto-
validaci6n demuestra el seguimiento de 10s requisitos dologia como lo fue el desarrollo sistematico en el que se basa-
del software y la prueba del sistema valida el software ron el milisis, el diseiio y la codificacibn.
una vez que se ha incorporado en un sistema superior.
Cada paso de pmeba se lleva a cab0 mediante una En este capitulo hemos examinado el espacio estra-
serie de tCcnicas sistemhticas de prueba que ayudan en tCgico de la pmeba, considermdo 10s pasos que tienen
el diseiio de casos de prueba. Con cada paso de prueba la mayor probabilidad de conseguir el fin ~ l t i m ode la
se amplia el nivel de abstracci6n con el que se consi- pmeba: encontrar y subsanar 10s defectos de una mane-
dera el software. ra ordenada y efectiva.
[BE1841 Beizer, B., Software System Testing and Quality Assu- [MILL771 Miller, E., <<ThePhilosophy of Testing*, Program
rance, Van Nostrand Reinhold, 1984. Testing Techniques, IEEE Computer Society Press, 1977,
pp. 1-3.
[BOE81] Boehm, B., Software Engineering Economics, Pren-
tice-Hall, 1981, p. 37. [MUS89] Musa, J. D., y Ackerman, A. F., <<QuantifyingSoft-
ware Validation: When to Stop Testing?,>,IEEE Softwa-
[BRA851 Bradley, J.H., <<Thescience and Art of Debugging,,, re, Mayo 1989, pp. 19-27.
Computerworld, 19 de Agosto de 1985, pp. 35-38.
[MYE79] Myers, G., The Art of Sofht'are Tests, Wiley, 1979.
[CHE90] Cheung, W. H., J. P. Black y E. Manning, <<AFra- [SH083] Shooman, M. L., Software Engineering, Mcgraw-
mework for Distributed Debugging,,, IEEE S o f i a r e , Ene- Hill, 1983.
ro 1990, pp. 106-115.
[SHN80] Shneiderman, B., Sofn~arePsychology, Winthrop
[DUN821 Durn, R., y R. Ullman, Quality Assurance for Com- Publishers, 1980, p. 28.
puter Sofhvare, McGraw-Hill, 1982, p. 158.
[VAN891 Van Bleck, T., <<ThreeQuestions About Each Bug
[GIL95] Gilb, T., <<WhatWe Fail To Do In Our Current Tes- You find)),ACM Sofn~areEngineering Notes, vol. 14, n."
ting Culture,,, Testing Techniques Newsletter, (edici6n en- 5, Julio 1989, pp. 62-63.
linea, [email protected]), Software Research, Inc, San [WAL89] Wallance, D. R., y R. U. Fuji, <<SoftwareVerifica-
Francisco, Enero 1995. IEEE Software, Mayo
tion and Validation: An Overview>>,
1989, pp. 10-17.
[MC096] McConnell, S., <<BestPractices: Daily Build and
Smoke Test>>,IEEE Software, vol. 13, n.", Julio 1996, [YOU751Yourdon, E., Techniques of Program Structure and
pp. 143-144. Design, Prentice-Hall, 1975.
18.1. Con sus propias palabras, describa las diferencias entre tifique el orden de integracion. Suponga que todos 10s modu-
verificacidn y validacion. ~Utilizanlas dos 10s mCtodos de 10s han sido probados en unidad y estan disponibles.[Nota:
disefio de casos de prueba y las estrategias de prueba? puede ser necesario comenzar trabajando un poco con el dise-
18.2. Haga una lista de algunos problemas que puedan estar fio inicialmente.]
asociados con la creaci6n de un grupo independiente de prue- 18.7. iC6m0 puede afectar la planificaci6n del proyecto a la
ba. ~ E s t a nformados por las mismas personas el GIP y el gru- prueba de integracion?
po SQA? 18.8. ~ E posible
s o incluso deseable la prueba de unidad en
18.3. ~ E siempre
s posible desarrollar una estrategia de prue- cualquier circunstancia? Ponga ejemplos que justifiquen su
ba de software que use la secuencia de pasos de prueba des- respuesta.
crita en la Seccion 18.1.3? ~ Q u Cposibles complicaciones 18.9. LQuiCn debe llevar a cab0 la prueba de validacion 1-
pueden surgir para sistemas empotrados? desarrolladordel software o el usuari-? Justifique su respuesta.
18.4. Si solo pudiera seleccionar tres metodos de disefio de 18.10. Desarrolle una estrategia de prueba completa para el
casos de prueba para aplicarlos durante la prueba de unidad, sistema HogarSeguro descrito anteriormente en este libro.
p B l e s serian y por quC? DocumCntela en una Especificacibn de Prueha.
18.5. PorquC es dificil de realizar la prueba unitaria a un mMu- 18.11. Como proyecto de clase, desarrolle una guia de depu-
lo con alto nivel de integracion. racion para su instalacion. La guia debe proporcionar conse-
18.6. Desarrolle una estrategia de prueba de integracion para jos orientados a1 lenguaje y a1 sistema que se hayan aprendido
cualquiera de 10s sistemas implementados en 10s problemas con las malas experiencias. Comience con un esbozo de 10s
16.4 a 16.11. Defina las fases de prueba, indique el orden de temas que se tengan que revisar por la clase y su profesor.
integracion, especifique el software de prueba adicional y jus- Publique la guia para otras personas de su entomo.
Libros orientados a las estrategias de prueba del software son al. (Testing Computer Software, 2.%d., Van Nostrand Rein-
10s de Black (Managing the Testing Process, Microsoft Press, hold, 1993) define 10s pasos para una estrategia efectiva, pro-
1999), Dustin, Rashka and Paul (Test Process Improvement: porciona un conjunto de tCcnicas y directrices y sugiere
Step-By-Step Guide to Structured Testing, Addison-Wesley, procedimientos para controlar y hacer un seguimiento a 10s
1999), Peny (Surviving the Top Ten Challenges of Software procesos de prueba. Hutcheson (Software Testing Methods
Testing: A People-Oriented Approach, Dorset House, 1997), and Metrics, McGraw-Hill, 1996) presenta unos mCtodos y
and Kit and Finzi (Software Testing in the Real World:Impro- estrategias de prueba per0 tambiCn proporciona un estudio
ving the Process, Addison-Wesley, 1995). detallado de corn0 se puede usar la medicion para conseguir
Kaner, Nguyen y Falk (Testing Computer Softwa-re, Wiley, una prueba efectiva.
1999), Hutcheson (Software Testing Methods and Metrics:
Un libro de Dunn (SoftwareDefect Removal, McGraw-Hill,
The Most Important Tests, McGraw Hill, 1997), Marick (The
1984) contiene unas directrices para la depuracion. Beizer
Craft of Software Testing: Subsystem Testing Including Ohject-
Based and Object-Oriented Testing, Prentice Hall, 1995), Jor- [BE1841 presenta una interesante cctaxonomia de erroress que
gensen (Software Testing: A Crafts-man 's Approach, CRC puede conducir a unos mCtodos efectivos para la planificacion
Press, 1995) presentan estudios sobre 10s mCtodos y estrate- de pruebas. McComell (Code Complete,Microsoft Press, 1993)
gias de prueba. presenta unos pragmaticos consejos sobre las pruebas de uni-
Ademas, antiguos libros de Evans (Productive Software dad y de integracion asi como sobre la depuracion.
Test Management, Wiley-Interscience, 1984), Hetzel (The Una amplia variedad de fuentes de informacion sobre prue-
Complete Guide to Software Testing, QED Information Scien- bas del software y elementos relacionados estan disponibles
ces, 1984), Beizer [BEI84], Ould y Unwin (Testing in Soft- en Internet. Una lista actualizada de paginas web sobre con-
ware Development, Cambridge University Press, 1986),Marks ceptos de prueba, mCtodos y estrategias pueden encontrarse
(Testing Very Big Systems, McGraw-Hill, 1992), y Kaner et en http://www.pressman5.com.
M~TRDCAS T~CNNCAS
DEL SOFTWARE
Palabras clave
fadores
de b calidad . . . . . 324
mbtricas a nivd
de componente .....333
u N elemento clave de cualquier proceso de ingenieria es la medicicin. Ernpleamos medi-
das para entender mejor 10s atributos de 10s modelos que crearnos. Pero, fundamental-
mente, empleamos las medidas para valorar la calidad de 10s productos de ingenieria o
de 10s sistemas que construimos.
A diferencia de otras disciplinas, la ingenieria del software no estri basada en leyes cuanti-
mCtrlcas tativas bdsicas de la Fisica. Las medidas absolutas, tales como el voltaje, la rnasa, la veloci-
de la mqvitectwa ...332 dad o la temperatura no son comunes en el mundo del software. En su lugar, intentamos obtener
mbt<~ls un conjunto de medidas indirectas que dan lugar a metricas que proporcionan una indicacicin
de la especificatihn. .33 1 de la calidad de algun tip0 de representacicin del software. Como las medidas y metricas del
mbtricas software no son absolutas, estdn abiertas a debate. Fenton [FEN9 11 trata este aspecto cuando
de 10s otributos.. ...328 dice:
mbtticas La medicidn es el proceso por el que se asignan nlimeros o simbolos a 10s atributos de las entidades en
del analisis.. .......328 el mundo real, de tal manera que las definan de acuerdo con unas reglas claramente definidas .... En las cien-
mbtricas del c6digo cias fisicas, medicina y, mis recientemente, en las ciencias sociales, somas ahora capaces de medir atribu-
fuente.. ...........336 tos que previamente penslibamos que no eran medibles... Por supuesto, tales mediciones no estiin tan refinadas
como las de las ciencias fisicas .... pero existen [y se toman importantes decisiones basadas en ellas]. Sen-
mitricos d d diseiio.. 332 timos que la obligation de intentar ccmedir lo no mediblw para mejorar nuestra comprensi6n de entidades
mCtricos del particulares es tan poderosa en la ingenieria del software como en cualquier disciplina.
mantenimimto .... .338
Pero algunos miembros de la cornunidad de software continfian argumentando que el software
dtricos
para pruebas.. .... .337
no es rnedible o que se deberian posponer 10s intentos de medicih hasta que comprendarnos mejor
el software y 10s atributos que habria que emplear para describirlo. Esto es un error.
vrincivios
iQu6 es? Por su naturaleza, la ingenie- necesita criterios objetivos para guiarse datos histbrims. M resultado del an&li-
ria e s una disciplina cuantitativa. LOS en el diseiio de d a t a , de la arquitectu- sis e s interpretado p a profundizar en
ingenieros usan numeros para ayu- ra, d e las interfaces y de l a mmponen- la calidad del software. y el resultado de
darse en eI diseao y c6lculo del pro- tea El verifidor necesita una referencia la interpretaci6n orienta las modifica-
ducto a construir. Hasta hace poco cucmtitcrtivaque leayude en la seleccitm ciones a originarse en 10s resultados
tiempo, los ingenieros del software dis- d e 10s casos de pmeba y d e sus objeti- obtenidos en el ancilisis, diseiio, d f i -
ponian d e pocas referencias cuantita- vrw. Las metricas tknicas facilitan una caci6n y p ~ e b a .
tivas e n s u trabajo -per0 esto estd base p a que el andisis, diseiio, codi- (Cucil es el product0 obtenido? Las
cambiand-. Las metricas tecnicas ficacidn y pmeba puedan ser conduci- metricas deI software s e r b calculadas
ayudan a 10s ingenieros del software das m&sobjetivamentey valoradas m&s sobre datos agregados del andlisis, de
a profundizar en el disefio y construc- cuanlitativamente. 10smodelos de diseiio, del c6digo fuen-
ci6n de 10sproductos que desarrollan. ~CUQH son 10s paws? La primera etu- te y d e 10s casos d e p ~ e b a .
dQui6nlo hace? Los ingenieros del soft- pa en el proceso de medida consiste en ~Cdmopucdo estar seguro de qne
ware usan las metricas tecnicas para extraer las medidas y m6tricas del soh- lo he hecho correctamente? Hay
ayudarse e n el desarrollo de software ware que son apropiadas para la repre- que establecer 10s objetivos y medidas
d e mayor calidad. sentacibn del software que estd siendo antes d e comenzar la acumulacion d e
@or q d es tnpoltante?Siempre h&rd considerado. A continuaci6n. s e requie- datos, definiendo sin ambigiiedad
elementos cualitativos para la creaci6n
del software. El problema estribo enque
,. . ...
ren d a t a p a extraer la formulacih de
1
metricasagregadas. Una vez calculadas,
.. cada metrica tbcnica. Define pocas
metricas y utilizalas para profundizar
la valoraci6n cualitcrtiva puede no ser las mbtricas apropiadas sonanalizadas en la calidad del resultado obtenido en
suficiente. Un ingeniero del software en base a direclrices preestablecidas y la ingenieria del software.
Aunque las mCtricas tCcnicas para el software de computadora no son absolutas, nos pro-
porcionan una manera sistemBtica de valorar la calidad basdndose en un conjunto de <<reglas
claramente definidasn. TambiCn le proporcionan a1 ingeniero del software una visi6n interna en
. . . .
el acto, en vez de a posteriori. Esto permite a1 ingeniero descubrir y corregir problemas poten-
. . P . . ,,.
I N G E N I E R I A DEL SOFTWARE. U N ENFOQUE PRhCTICO
En el Capitulo 4 estudi6bamos las mdtricas del software tal y como se aplican a nivel del proceso y del proyecto. En
este capitulo, nuestro punto de atenci6n se desplaza a las medidas que se pueden emplear para valorar la calidad del pro-
.duct0 segiln se va desarrollando. Estas medidas de atributos intemos del producto le proporcionan al desarrollador de soft-
ware una indicaci6n en tiempo real de la eficacia del anGIisis, del disefio y de la estructura del c6dig0, la efectividad de 10s
casos de prueba. y la calidad global del software a construir.
Incluso 10s desarrolladore~del software mis hastiados que se pueden medir directamente (por ejemplo, defec-
e~tar6nde acuerdo en que un software de alta calidad es tos por punto de funcibn) y (2) factores que se pueden
una de las metas mds importantes. Pero, i,cbmo definimos medir s61o indirectamente (por ejemplo, facilidad de
la calidad? En el Capitulo 8 propusimos diferentes mane- uso o de mantenimiento). En todos 10s casos debe apa-
ras de interpretar la calidad del software e introdujimos recer la medicion. Debemos comparar el software (docu-
una definicion que hacia hincapik en la concordancia con mentos, programas, datos) con una referencia y llegar
los reyuisitos funcionales y de rendimiento explicitamen- a una conclusi6n sobre la calidad.
te establecidos, 10s estindares de desarrollo explicitamente
documentados y las caracteristicas implicitas que se espe-
ran de todo \oftware desarrollatlo profesionalmente.
9
CuvE
Es i~lteresonteanotar que 10s factores de calidod
de McColl son tau vblidos hoy como cuaudo fueron
10s primeros propuestos en 10s oiios 70. Adembs,
~ o d Lo g r a m o hoce nlgo correctmente, es rozonoble indicor que 10s foctores que ofecton
que puede no ser lo que necesitomos que hogo. o lo colidad del sofhvare no cambian.
An6nimo
McCall y sus colegas [MCC77] propusieron una litil
N o cabe duda de clue la definicion anterior podria clasificacibnde factoresque afectan a la calidad del soft-
rnodificarse o ampliarse y discutirse eternamente. Para ware. Estos factores de software, mostrados
10s propcisitos de este libro, la definici6n sirve para hacer en la Figuri, 9. se concentran en tres aspectos impor-
Cnfasis en tres puntos importantes: tantes de un producto software: sus caracteristicas ope-
1. LOSrecluisitos del software son la base de medi- rativas, su capacidad de cambios y su adaptabilidad a
das de la calidad. La falta de concordancia con 10s nuevos el1tornos.
requisitos es una falta de calidad'.
2. Unos estindares especificos definen un conjunto de Facilidad de mantenimiento Portabilidad
criterios de desarrollo que guian la manera en que se Flexibilidad Reusabilidad
hace la ingenieria del software. Si no se siguen 10s Facilidad de prueba lnteroperatividad
criterios. h a b d seguramente poca calidad.
3. Esiste un conjunto de requisitos implicitos que a
menudo no se nombran (por ejemplo, facilidad de
mantenimiento). Si el software cumple con sus requi-
sites explicitos pero fillla en 10s implicitos. la cali-
dad del software no serA fiable.
La calitlad del software es una compleja mezcla de
factores que variarfin a trav6s de diferentes aplicacio-
6 Operation del producto
Correccion Fiabilidad Usabilidad
FIGURA 19.1. Factores de calidad de McCall

lntegridad Eficiencia
ncs y seglin 10s clientes que las pidan. En las siguien-

les hecciones, se identifican 10s factores de la calitlad RefiriCndose a 10s factores anotados en la Figura 19.1,
del software y se describen las actividades humanas McCall proporciona las siguientes descripciones:
necesarias para con$eguirlos. Hasta d6nde satisface un programa su especi-
Corret~c~idn.
ficaci6n y logra los objetivos propuestos por el cliente.
19.1.1. Factores de calidad de McCall Finhilidad.Hasta d6nde se puede esperar que un program
!leve a cabo au funci6n con la exactilud requerida. Hay que
LOSfactores que afectan a a la calidad del software se hacer n o t x que se han propueclo o t m definiciones de fiabili-
pueden categorizar en dos amplios grupos: (1) factores dad m i s completab (vea el CapituIo 8).
I Es importante resaltar que la calidad se extiende a 10s atributos lec-

nicos de los modelos de analisis, de disetio y de codificaci6n. Los
modelos que presentan una aka calidad (en el sentido lecnico) darhn
lugar a un soRware de una aka calidad desde el punto de vista del
cliente.
CAP~TULO
19 METRICAS T E C N I C A S DEL S O F T W A R E
Eficiencia. La cantidad de recursos informiticos y de c6di- Compleccidn. El grado con que se ha logrado la imple-
go necesarios para que un programa realice su funci6n. mentaci6n total de una funci6n.
Integridad. Hasta donde se puede controlar el acceso al soft- Concisidn.Lo compact0 que es el programa en tCrminos de
ware o a 10s datos por personas no autorizadas. lineas de c6digo.
Consistencia.El empleo de un diseiio uniforme y de tCcni-
cas de documentaci6na lo largo del proyecto de desarrollo del
software.
Estandarizacidn de datos. El empleo de estructuras y tipos
de datos estindares a lo largo del programa.
Tolerancia a1 error. El daiio causado cuando un programa
encuentra un error.
Usabilidud (facilidad de manejo). El esfuerzo necesario para
aprender a operar con el sistema, preparar 10s datos de entra- Eficiencia de ejecucidn. El rendimiento del funcionamien-
da e interpretar las salidas (resultados) de un programa. to de un programa.
Facilidad de mantenimiento. El esfuerzo necesario para Capacidad de expansidn. El grado con que se pueden
localizar y arreglar un error en un programa. (Esta es una defi- ampliar el diseiio arquitect6nic0, de datos o procedimental.
nici6n muy limitada). Generalidad. La amplitud de aplicaci6n potencial de 10s
componentes del programa.
Flexibilidad. El esfuerzo necesario para modificar un pro-
grama que ya esti en funcionamiento. Independencia del hardware. El grado con que se desaco-
pla el software del hardware donde opera.
Facilidad de prueba. El esfuerzo necesario para probar un
programa y asegurarse de que realiza correctamente su fun- Instrumentacidn. El grado con que el programa vigila su
ci6n. propio funcionamiento e identifica 10s errores que ocurren.
Portabilidad. El esfuerzo necesario para transferir el pro-

grama de un entomo hardware/software a otro entomo dife-
rente.
Reusabilidad (capacidad de reutilizacibn). Hasta d6nde se
puede volver a emplear un programa (o partes de un progra-
ma) en otras aplicaciones, en relaci6n a1 empaquetamiento y
alcance de las funciones que realiza el programa. Foctores de Calidad
Interoperatividud. El esfuerzo necesario para acoplar un sis- Modularidud. La independencia funcional (Capitulo 13) de
tema con otro. componentes de programa.
Es dificil, y en algunos casos imposible, desarrollar Operatividud. La facilidad de operaci6n de un programa.
medidas directas de 10s factores de calidad anteriores. Seguridad. La disponibilidad de mecanismos que contro-
Por tanto, se definen y emplean un conjunto de mCtri- lan o protegen 10s programas y 10s datos.
cas para desarrollar expresiones para todos 10s factores, Autodocumentacidn. El grado en que el c6digo fuente pro-
de acuerdo con la siguiente relaci6n: porciona documentaci6n significativa.
F 4 = cl x ml + c2 x m2 +....+ c, x m, Simplicidad. El grado de facilidad con que se puede enten-
der un programa.
donde Fq es un factor de calidad del software, c, son
Independencia del sistema sofrware. El grado de indepen-
coeficientes de regresi6n y m, son las mktricas que afec- dencia de programa respecto a las caracteristicas del lenguaje
tan a1 factor de calidad. Desgraciadamente, muchas de de programaci6n no esthdar, caracteristicas del sistema ope-
las mCtricas definidas por McCall pueden medirse sola- rativo y otras restricciones del entomo.
mente de manera subjetiva. Las mCtricas pueden ir en Trazabilidad.La capacidad de seguir una representation del
forma de lista de comprobaci6n que se emplea para diseiio o un componente real del programa hasta 10s requisites.
<<puntuar>> atributos especificos del software [CAV78]. Formacidn. El grado en que ayuda el software a manejar el
El esquema de puntuaci6n propuesto por McCall es una sistema a 10s nuevos usuarios.
escala del 0 (bajo) a1 10 (alto). Se emplean las siguien-
tes mCtricas en el esquema de puntuaci6n: La relaci6n entre 10s factores de calidad del software
y las mCtricas de la lista anterior se muestra en la Figura
19.2. Deberia decirse que el peso que se asigna a cada
mCtrica depende de 10s productos y negocios locales.
19.1.2. FURPS
Facilidad de auditoria. La facilidad con la que se puede Los factores de calidad descritos por McCall y sus cole-
comprobar el cumplirneinto de 10s esthdares. gas [MCC77] representan s610 una de las muchas listas
Exactitud. La exactitud de 10s ciilculos y del control. de comprobaci6n sugeridas para la calidad del softwa-
Estandarizacibn de comunicaciones. El grado de empleo re. Hewlett-Packard [GRA87] ha desarrollado un con-
de esthdares de interfaces, protocolos y anchos de banda. junto de factores de calidad del software a1 que se le ha
dado el acr6nimo de FURPS:frrnciot1aIi~Iad,fac~iliclacl subatributos: facilidad de instalaci6r1, facilidad de ajuste, faci-
de uso,~ahilidad,lvtdimiento y cayucidad de sopork. lidad de adaptacicin al carnbio.
'Los factores de calidad FURPS provienen de trabajos
anleriores, definiendo 10s siguientes atributos para cada
uno de 10s cinco factores principales: Cuolquier actividad crealiva requiere
Lafirtlcionulidad se valora evaluando el conjunto de un planteamientopara hacerlo bien, o perfecto
caracteristicas y capacidades del programa, la gene- John Updike
ralidad de las funciones entregadas y la seguridad
del sistema global. Del mismo mod0 que 10s factores de calidad estu-
La fir(-ilidtrdde rrso se valora considerando factores diados en las secciones 19.1.1. y 19.1.2., 10s factores
humanos (capitulo 15), la estCtica, la consistencia y I S 0 9 126 no necesariamente son utilizados para medi-
la documentaci6n general. das directas. En cualquier caso, facilitan una valiosa
Lafiabilidacl se evalua midiendo la frecuencia y gra- base para medidas indirectas y una excelente lista para
vedad de 10s fallos, la exactitud de las salidas (resul- determinar la calidad de un sistema.
tados), el tiempo de medio de fallos (TMDF), la
capacidad de recuperaci6n de un Fillo y la capaci-
dad de predicci6n del programa.
El r~ndirnientose mide por la velociclad de procesa-
miento, el tiempo de respuesta, consumo de recur-
sos, rendimiento efectivo total y eficacia.
La cupac,iclnd de sopo,.te combina la capacidad de
ampliar el programa (extensibilidad), adaptabilidad y
senicioa (estos tres atributos representan un tCrmino
nxis comun -mantenimiente-), asi como capacidad
de hacer pruebas, compatibilidad, capacidad de con-
figuraci6n (la capacidad de organizar y controlar ele-
mentos de la configuraci6n del software [Capitulo 91).
la facilidad de instalaci6n de un sisterna y la facilidad
con que se pueden localizar 10s problems.
Los factores de calidad FURPS y atributos descritos
anteriormente pueden usarse para kstab~ecermktricas
dc la calidad para todas las activiclades del proceso del
software.
19.1.3. Factores de calidad IS0 9126

El estdndar I S 0 9126 ha sido desarrollado en un intento
de identificar 10s atributos clave de calidad para el soft-
ware. El est6ndar identifica seis atributoa clave de calidad:
Frorcioirulirlrcl. El grado cn que cl software satisface las
nccesidadcs i~ldicadi~s por los siguientes subatributos: idonei-
dad. correcciBn, interoperalividad, confornlidad y seguridad.
Cot!fiohilirltrrl.Cantidnd de tiempo clue cl software estA dis-
poniblc para su so. Estii refcrido por 10s siguientes subatri- FIGURA 19.2. Factores y metricas de calidad.
butos: rnadurez, tolcri~nciaa fiillos y facilidad de rccuperacih
L'srrhilirlrirl. Grado en que el sol'tware cs f k i l de usar. Vie- 19.1.4. La transici6n a una vision cuantitativa
ne reflcjado por 10s siguientes subatributos: Sacilidad de com- En las secciones precedentes se estudiaron un con-jun-
prcnsi6n. hcilidnd de apsendizajc y opesatividad. to de factores cualitalivos para la <<medicion>>
de la cali-
Ejc.ictrc.icr.Grado en que el soflware hace 6ptinio el uso tie dad del software. Intentarnos desarrollar medidas exactas
los lecursos del sisiernil. Estri indicado pos 10s siguientes suba- de la calidad del software frustradas a veces por la natu-
tributes: ticrnpo de uso y rccursos utilizados. raleza subjetiva de la actividad. Cavano y McCall
Ftrc~iliilirtltic rrrutlteilittriorto, La facilidd con que unn modi- [CAV78j estudian esta situacicin:
ticaciBn p ~ ~ e dser e realizada. Estii indicada por 10s siguientes
subatributos: fi~cilidadde anilisis, facilidad de carnbio, estabi- La dcterrninacion de la calidad es on factor clave en 10s
lidad y fi~cilidaddc prueba. aconteciniientos diarios: concursos de cata de vinos, aconteci-
rnicnlos deportivos (por ejemplo, la gininasia), concursos de
Portcrhiliclt~d.La Facilidad con que el software puedc ser talento. etc. En estas situncioncs, la calidnd se j u z y de la rnnnc-
Ilcvado dc un entorno a otso. Est6 referido por 10s siguientes ra mis fundamental y dirccta: comparxion de objetos unos 211
C A P ~ T U L O 19 METRICAS TECNICAS DEL SOFTWARE
lado de 10s otros bajo condiciones idknticas y con conceptos te manera: ccAiio tras afio ingeniamos instrumentos m8s exac-
predeterminados. El vino puede ser juzgado de acuerdo con su tos con 10s que obsewar la naturaleza con mis exactitud. Y
claridad, color, bouquet, sabor, etc. Sin embargo, este tipo de cuando miramos las obsewaciones estamos desconcertados de
juicio es muy subjetivo; para que tenga algo de valor, debe ver que todavia son confusas, y tenemos la sensacion de que
hacerse por un experto. son tan inciertas corno siempre.,
La subjetividad y la especializaci6n tambikn influyen en la En las siguientes secciones examinamos un conjun-
determinaci6n de la calidad del software. Para resolver este to de mCtricas del software que pueden aplicarse a la
problema, se necesita una definici6n de calidad del software valoraci6n cuantitativa de la calidad del software. En
mis exacta, asi corno una manera de obtener medidas cuanti-
todos 10s casos, las mCtricas representan medidas indi-
tativas de la calidad del software para hacer un andisis objeti-
vo.... Como no existe el conocimiento absoluto, no deberiamos
rectas; es decir, realmente nunca medimos la calidad
esperar poder medir la calidad del software exactamente, ya sino alguna manifestaci6n de la calidad. El factor que
que cada rnedici6n es parcialmente imperfects. Jacob Bron- lo complica es la relaci6n exacta entre la variable que
kowski describi6 esta paradoja del conocimiento de la siguien- se mide y la calidad del software.
Como djimos en la introducci6n de este capitulo, la medi- Pero existe la necesidad de medir y controlar la com-
ci6n asigna numeros o simbolos a atributos de entidades plejidad del software. Y si es dificil de obtener un solo
en el mundo real. Para conseguirlo se necesita un mode- valor de esta ccmCtrica de calidadn, si deberia ser posi-
lo de medicion que comprenda un conjunto consistente ble desarrollar medidas de diferentes atributos intemos
de reglas. Aunque la teoria de la medici6n (por ejemplo, del prograrna (por ejemplo, modularidad efectiva, inde-
[KYB84]) y su aplicaci6n a1 software (por ejemplo, pendencia funcional y otros atributos tratados desde el
[DEM81], [BRI96]) son temas que estan m6s alli del Capitulo 13 a1 Capitulo 16). Estas medidas y las mktri-
alcance de este libro, merece la pena establecer una estruc- cas obtenidas de ellas pueden usarse corno indicadores
tura fundamental y un conjunto de principios basicos para independientes de la calidad de 10s modelos de andisis
la medici6n de metricas tkcnicas para el software. y diseiio. Pero tambiCn surgen problemas aqui. Fenton
[FEN941 lo advierte cuando dice:
El peligro de intentar encontrar rnedidas que caractericen
tantos atributos diferentes es que, inevitablemente, las medi-
das tienen que satisfacer objetivos incompatibles. Esto es con-
trario a la teona de representaci6n de la medicion.
Aunque la declaraci6n de Fenton es correcta, mucha
gente argumenta que la medicion tCcnica llevada a cab0
durante las primeras fases del proceso de software les
proporciona a 10s desarrolladores de software un con-
19.2.1. El reto de las metricas tecnicas sistente y objetivo mecanismo para valorar la calidad.
Conviene preguntarse, no obstante, quC validez tie-
Durante las pasadas tres dCcadas, muchos investigado- nen las mCtricas tkcnicas. Es decir, jc6m0 e s t h de pr6-
res han intentado desarrollar una sola mCtrica que proximas las metricas tecnicas y la fiabilidad y la calidad a
porcione una medida completa de la complejidad del largo plazo de un sistema basado en computadora? Fen-
software. Fenton [FEN941 caracteriza esta investiga- ton [FEN911 trata esta cuestion de la siguiente manera:
cion corno una busqueda del ccimposible santo grial>>.
A pear de las intuitivas conexiones entre la estructura inter-
Aunque se han propuesto docenas de medidas de com- na de 10s productos software (mktricas tknicas) y su produc-
plejidad [ZUS90], cada una tiene un punto de vista dife- to extemo, y 10s atributos del proceso, ha habido. de hecho,
rente de lo que es la complejidad y quk atributos de un rnuy pocos intentos cientificos para establecer relaciones espe-
sistema llevan a la complejidad. cificas. Hay varias razones para ello; la que se menciona rnis
a menudo es la imposibilidad de llevar a cab0 experimentos.
Todos 10s desafios mencionados anteriormente son
Referencia web/ ' motivo de precaucion, per0 no es motivo de desprecio
de las metricas tCcnicas2. La medicion es esencial si se
Voluminoso informocian sobre mehicos tecnicos hon sido desea conseguir calidad.
recopilados por Horst Zuse: irb.cs.tu-berlin.de/-zuse/
Se ha producido m a gran cantidad de literatura sobre las metricas del
soRware @orejemplo, vea FEN941, [ROC94], [ZUS97] para obtener unas
extensas bibliografias)yes comim la critica de metricas especificas (inck-
yendo algunas de las presentadas en este capitulo).Sin embargo,muchas
de las criticas se concentran en aspectos esotericos y pierden el obje-
tivo primario de la medicion en el mundo real: ayudar al ingeniero a
establecer una manera sistematica y objetiva de conseguir una vision
intema de su trabajo y mejorar la calidad del product0 corno resultado.
I N G E N I E R ~ ADEL SOFTWARE. UN ENFOQUE P R ~ C T I C O
19.2.2. Principios de medici6n Se deberian aplicar tCcnicas estadisticas validas para

Antes de introducir una serie de mCtricas tkcnicas que establecer las relaciones entre 10s atributos internos
(1) ayuden a la evaluaci6n de 10s modelos de anilisis y del producto y las caractensticas externas de la cali-
disefio, (2) proporcionen una indicaci6n de la complejidad (por ejemplo, jesth correlacionado el nivel de
dad de 10s disefios procedimentales y del c6digo fuente, complejidad arquitect6nico con el numero de defec-
y (3) ayuden en el disefio de pruebas mis efectivas, es tos descubiertos en la producci6n?).
importante entender 10s principios bisicos de la medi- Se deberian establecer una directrices de interpreta-
ci6n. Roche [ROC941 sugiere un proceso de medici6n ci6n y recomendaciones para todas las mCtricas.
que se puede caracterizar por cinco actividades: Ademas de 10s principios apuntados anteriormente,
formulacibn: la obtenci6n de medidas y mCtricas del el Cxito de una actividad de mC&a esti ligada a1 sopor-
software apropiadas para la representaci6n del soft- te de gesti6n. Se deben considerar 10s fondos, la for-
ware en cuesti6n. maci6n y la promoci6n si se quiere establecer y mantener
coleccidn: el mecanismo empleado para acumular datos un programa de medicidn tCcnica.
necesarios para obtener las mCtricas formuladas.
andisis: el cilculo de las mCtricas y la aplicaci6n de 19.2.3. Caracteristicas fundamentales de las
herramientas matemiticas. metricas del software
iCuiles son 10s pasos Se han propuesto cientos de mCtricas para el software,
para un proceso per0 no todas proporcionan un soporte prictico para el
de medicion torrecto? desarrollador de software. Algunas demandan medi-
ciones que son demasiado complejas, otras son tan eso-
interpretacidn: la evaluaci6n de 10s resultados de las tCricas que pocos profesionales tienen la esperanza de
metricas en un esfuerzo por conseguir una visi6n entenderlas y otras violan las nociones bisicas intuiti-
interna de la calidad de la representaci6n. vas de lo que realmente es el software de alta calidad.
realimentacidn (feedback):recomendaciones obte- Ejiogu - 1 ~ ~11
1 9define un conjunto de atributos que
nidas de la interpretaci6n de metricas tecnicas trans- deberian acompaiiar a las metricas efectivas del soft-
mitidas a1 equipo
- - que - construye el software. ware. La mCtrica obtenida y las medidas que conducen
Los principios que se pueden isociar con la formula- a deberian ser:
ci6n de las metricas tecnicas son 10s siguientes [ROC94]: simples y fciciles de calcular. Deberia ser relativa-
Los objetivos de la medici6n deberian establecerse mente ficil aprender a obtener la mttrica y su cil-
antes de emDezar la recoeida de datos. culo no debena demandar un esfuerzo o cantidad de
u
tiempo inusuales.
Todas las tCcnicas sobre metricas deberian definirse
sin ambigiiedades. ~ C O podemos
~ O valorar
la calidad de una metrica
~ Q u Breglas debemos del software propuesta?
observar cuando
establecemos medidas tecnicas? empi'rica e intuitivamente persuasivas. La mCtrica
deberia satisfacer las nociones intuitivas del inge-
Las mCtricas deberian obtenerse basindose en una niero sobre el atributo del producto en cuesti6n (por
teoria vhlida para el dominio de aplicaci6n (por ejem- ejemplo, una mCtrica que mide la cohesi6n de un
plo, las mCtricas para el diseiio han de dibujarse sobre mddulo deberia aumentar su valor a medida que crece
conceptos y principios bisicos de diseiio y deberian el nivel de cohesi6n).
intentar proporcionar una indicaci6n de la presencia consistentes y objetivas. La mCtrica debena siempre
de un atributo que se considera beneficioso). producir resultados sin ambigiiedad. Un tercer equipo
Hay que hacer las metricas a medida para acomodar deberia ser capaz de obtener el mismo valor de
mejor 10s productos y procesos especificos [BAS84]. mCtrica usando la misma informaci6n del software.
Aunque la formulaci6n es un punto de manque cri- consistentes en el empleo de unidades y tamaiios. El
tico, la recogida y analisis son lG actividades que diri- cilculo matemitico h e la mCtrica deberia emplear
gen el proceso de medici6n. Roche [ROC941 sugiere medidas que no conduzcan a extraiias combinacio-
10s siguientes principios para estas actividades: nes de unidades. Por ejemplo, multiplicando el
Siempre que sea posible, la recogida de datos y el numero de personas de un equipo por las variables
anilisis debe automatizarse. del lenguaje de programaci6n en el programa resulta
una sospechosa mezcla de unidades que no son intui-
tivamente persuasivas.
for encim~de todo, intento obtener medidos tknicm
independientes del lenguaje de programacibn. Las
simples. No te obsesiones por lo rnem'c~~
uperfefectos mCtricas deberian basarse en el modelo de anili-
porque no existe. sis, modelo de diseiio o en la propia estructura del
C A P ~ T U L O19 MPTRICAS T P C N I C A S DEL SOFTWARE
programa. No deberian depender de 10s caprichos Aunque la mayoria de las mCtricas de software
de la sintaxis o semantics del lenguaje de progra- satisfacen las caracteristicas anteriores, algunas de la
maci6n. mCtricas comunmente empleadas dejan de cumplir
un eficaz mecanismo para la realimentaci6n de cali- una o dos. Un ejemplo es el punto de funci6n (trata-
dad. La mCtrica deberia proporcionar, a1 desarrollado en el Capitulo 4 y en este capitulo). Se puede argu-
dor de software, informacih que le lleve a un mentar' que el atributo consistente y objetivo falla
product0 final de mayor calidad. porque un equipo ajeno independiente puede no ser
capaz de obtener el mismo valor del punto de funci6n
que otro equipo que use la misma informaci6n del
software. ~Deberiamosentonces rechazar la medida
Lo experiencio indico que uno metrico tecnico se uso PF? La respuesta es ccipor supuesto que no!>>.El PF
knicomente si es intuitive y facil de colculor. Si se requiere proporciona una util visi6n interna y por tanto pro-
docenos de ((contodores)) y se hon de utilizor compleios porciona un valor claro, incluso si no satisface un atri-
calculos, lo mbtrico no sera ompliomente utilizodo. but0 perfectamente.
El trabajo tCcnico en la ingenieria del software empie- 19.3.1. Metricas basadas en la funci6n
za con la creaci6n del modelo de analisis. En esta fase La mCtrica de punto de funcion (PF) (Capitulo 4) se pue-
se obtienen 10s requisitos y se establece el fundamento de usar como medio para predecir el tamaiio de un siste-
para el diseiio. Por tanto, son deseables las mCtricas tCc- ma que se va a obtener de un modelo de analisis. Para
nicas que proporcionan una visi6n interna a la calidad ilustrar el empleo de la mCtrica de PF en este contexto,
del modelo de analisis. consideramos una sencilla representacion del modelo de
analisis mostrada en la Figura 19.3. En la figura se repre-
senta un diagrama de flujo de datos (Capitulo 12) de una
10s modelos de datos, funcianes y comportamientos funci6n del sistema ~ogarSeguro~. La funci6n gestiona
son tratodos en los Coph~los11 y 12. la interacci6n con el usuario, aceptando una contraseiia
de usuario para activar/desactivar el sistema y permitien-
Aunque han aparecido en la literatura relativamen- do consultas sobre el estado de las zonas de seguridad y
te pocas mCtricas de analisis y especificacion, es posi- varios sensores de seguridad. La funci6n muestra una serie
ble adaptar mCtricas obtenidas para la aplicaci6n de un de mensajes de peticion y envia sefiales apropiadas de
proyecto (Capitulo 4) para emplearlas en este contex- control a varios componentes del sistema de seguridad.
to. Estas mCtricas examinan el modelo de anilisis con
la intention de predecir el cctamafion del sistema resul-
tante. Es probable que el tamafio y la complejidad del
Poro ser utilporo el tmbojo tecnico, 10s medidos ticnicos
disefio estCn directamente relacionadas. que opoyon lo tomo de decision (el: errores encantrodas
duronte lo pruebo de unidod) deben ser ogrupodos
y normolizodos utilizondo lo metrico PF:
El diagrama de flujo de datos se evalua para deter-
Sensores
Sensor de ~rueba minar las medidas clave necesarias para el c5lculo de
la mCtrica de punto de funci6n (Capitulo 4):
numero de entradas del usuario
Usuario numero de salidas del usuario
- numero de consultas de usuario

numero de archivos
numero de interfaces externas
I
Datos de configuracion del sistema I Tres entradas del usuario: contrasena, interruptor
de emergencia y activar/desactivar aparecen en la
FIGURA 19.3. Parte del modelo de analisis del software de figura junto con dos consultas: consulta de zona y con-
Hogar Seguro. sulta de sensor. Se muestra un archivo (archivo de
Fijese que se puede hacer un contra argument0 igualmente vigo- HogarSeguro e s un sistema de seguridad para el hogar que se ha
roso. Tal e s la naturaleza de las metricas del software usado como aplicacion de ejemplo en capitulos anteriores
I N G E N I E R ~ ADEL SOFTWARE. UN ENFOQUE P R ~ C T ~ C O
configuracion del sistema). Tambien estin presentes tor del proyecto una importante informaci6n de plani-
.dos salidas de usuarios (mensajes y estados del sen- ficacion basada en el modelo de andisis en lugar de en
sor) y cuatro interfaces externas (sensor de prueba, estimaciones preliminares.
configuracion d e zona, activarldesactivar y alerta d e Considerar que de 10s proyectos anteriores se han
alarma). Estos datos, junto con la complejidad apro- encontrado una media de 3 errores por punto de funci6n
piada, se muestran en la Figura 19.4. durante las revisiones de anilisis y disefio, y 4 errores
Factor de ponderacidn
por punto de funci6n durante las pruebas unitaria y de
- -
. -.-... -.
Parirncrtra ---
(luenta Simple Media Compleja integraci6n. Estos datos pueden ayudar a valorar a 10s
de rnedicidn ingenieros del software la completitud de sus revisio-
Nljrnero de entradas nes y las actividades de prueba.
del usuarii
.. . . .. . r- 19.3.2. L a MBtrica bang
N~imerode salidas
del usuario A1 igual que la mktrica de punto de funcion, la me'rrica
bang puede emplearse para desarrollar una indicaci6n
del usuario 6a del tamafio del software a implementar corno conse-
Nljrnero de archivoa ~XO'IO 1 5 - m
cuencia del modelo de anilisis.
Desarrollada por DeMarco [DEM82], la mCtrica bang
es <<unaindicacidn independiente de la implementacidn
del tamafio del sistema,,. Para calcular la mktrica hutzg,
externas el desarrollador de software debe evaluar primer0 un
Cuenta total k d conjunto de primitivas (elementos del modelo de an&
lisis que no se subdividen m i s en el nivel de anilisis).
Las primitivas [DEM82] se determinan evaluando el
FIGURA 19.4. Calculo de puntos de funcion modelo de andisis y desarrollando cuentas para 10s
para una funcion de Hogar Seguro.
siguientes elementos5:
La cuenta total mostrada en la Figura 19.4 debe ajus- Prirnitivas funcionales (PFu). Transformaciones (burbu-
jas) que aparecen en el nivel inferior de un diagmma de Hujo
tarse usando la ecuaci6n (4.1): de datos (Capftulo 12).
PF= cuenta-total x (0,65 + 0,01 x C[Fil) Elementos de datos (ED). Los atributos de un objeto de
Donde cuenta-total es la suma de todas las entradas PF datos, 10s elenientos de datos son datos no cornpuestos y apa-
obtenidas en la Figura 19.3 y Fi (i=l a 14) son 4 0 s valo- recen en el diccionario de datos.
res de ajuste de complejidad,,. Para el prop6sito de este Objetos (OB). Objetos de datos tal y corno se describen en
ejemp!~,asumimos que C[Fi] es 46 (un product0 mode- el Capitulo l I.
radamer~tecomplejo). Por tanto: Kelaciones (RE). Las conexiones entre objetos de datos tal
PF= 50 x [0,65 + (0,0 1 x 46)] = 56 y corno se describen en el Capftulo 12.
Estados (ES).El nGrnero de estados observables por el usua-
rio en el diagrama de transici6n de estados (Capitulo 12).
Transiciones (TK). El nljrnero de transiciones de estado en
el diagrama de transition de estados (Capftulo 12).
Uno introduction util al PF ho sido eloborodo

por Capers lones y puede ser locolizodo en:
An! muevo rn4trico~
del tarnos nosotros
Bashndose en el valor previsto de PF obtenido del con Im m4tritos.
modelo de anilisis, el equipo del proyecto puede esti- Michael #Idy lamy PU
mar el tamafio global de implementaci6n de las funcio-
nes de interaccidn de HogarSegul-o.Asuma que 10s datos Ademis de las seis primitivas apuntadas arriba, se
de 10s que se disponen indican que un PF supone 60 determinan las cuentas adicionales para:
lineas de codigo (se va a usar un lenguaje orientado a Primitivas modificadas de funci6n manual (PMFu). Fun-
objetos) y que en un esfuerzo de un mes-persona se pro- ciones que caen fuera del limite del sistema y que deben modi-
ducen 12 PF. Estos datos historicos proporcionan a1 ges- ficarse para acornodarse al nuevo sisterna.
El acronimo apuntado entre parentesis a continuacibn de la prim-

tiva se emplea para denolar la cuenla de la primitiva particular; por
ejemplo, PFu indica el nurnero de prirnitivas funcionales presente en
un modelo de anatisis.
CAPfTULO 19 M ~ T R I C AT
S~CNICAS
DEL SOFTWARE
Elementos de datos de entrada (EDE). Aquellos elementos

de datos que se introducen en el sistema. Tci IPFuC
Elementos de datos de salida (EDS). Aquellos elementos 2 1,o
de datos que se sacan del sistema. 5 538
Elementos de datos retenidos (EDR). Aquellos elemen- 10 16,6
tos de datos que son retenidos (almacenados) por el sistema. 15 29,3
Muestras (tokens) de datos (TCi). Las muestras de datos 20 43,2
(elementos de datos que no se subdividen dentro de una pri-
mitiva funcional) que existen en el limite de la i-tsima primi- La ponderacion valorada apuntada en el algoritmo
tiva funcional (evaluada para cada primitiva). anterior se calcula de diecisCis clases diferentes de pri-
Conexiones de relacion (REi). Las relaciones que conec- mitivas funcionales definidas por DeMarco. Se asigna
tan el iCsimo objeto en el modelo de datos con otros objetos. una ponderaci6n que va de 0,6 (encaminamiento sim-
DeMarco IDEM821 sugiere que la mayoria del soft- ple de datos) a 2,5 (funciones de gestion de datos) depen-
ware se puede asignar a uno de 10s dos dominios siguien- diendo de la clase de la primitiva.
tes, dominio defuncibn o dominio de datos, dependiendo Para aplicaciones de dominio de datos, se calcula la
de la relaci6n REIPFu. Las aplicaciones de dominio de mCtrica bang mediante el siguiente algoritmo:
funci6n (encontradas comunmente en aplicaciones de Asignar a bang el valor i n i c i a l = 0;
ingenieria y cientificas) hacen hincapiC en la transfor- Mientras queden objetos por evaluar en el modelo de
maci6n de datos y no poseen generalmente estructuras datos
de datos complejas. Las aplicaciones de dominio de Calcular la cuenta de relaciones del objeto i
datos (encontradas comunmente en aplicaciones de sis- Calcular el incremento de OB corregido (IOBC);
temas de informaci6n) tienden a tener modelos de datos bang = bang t IOBC;
complejos. FinMientras
RE/PFu < 0.7 implica una aplicacion de dominio de funciQ El IOBC corregido se determina tarnbiCn de una tabla
0,8 < RE/PFu < 1,4 indica una aplicacion hhibrida publicada por DeMarco. A continuaci6n se muestra una
RE/PFu > 1,5 implica una aplicaci6n de dominio de datos
versi6n abreviada:
Como diferentes modelos de analisis haran una par- REi IOBC
tici6n del modelo con mayor o menor grado de refina-
1 1,o
miento. DeMarco sugiere que se emplee una cuenta
media de muestra (token) por primitiva 3 430
6 9,o
TCaVg= mi
IPFu
para controlar la uniformidad de la partici6n a travCs de Una vez que se ha calculado la mCtrica bang, se pue-
muchos diferentes modelos dentro del dominio de una de emplear el historial anterior para asociarla con el
splicaci6n. esfuerzo y el tamaiio. DeMarco sugiere que las organi-
Para calcular la mCtrica bang para aplicaciones de zaciones se construyan sus propias versiones de tablas
dominio de funcibn, se emplea el siguiente algoritmo: IPFuC e IOBC para calibrar la informaci6n de proyec-
Asignar a bang un valor i n i c i a l = 0; tos completos de software.
Mientras queden primi t i vas funcional es por eval uar
Calcular cuenta-token alrededor del l i m i t e de l a 19.3.3. Metricas de la calidad de la especificacih
primi t i v a i ; Davis y sus colegas [DAV93] proponen una lista de carac-
Calcular e l incremento PFu corregido (IPFuC) tensticas que pueden emplearse para valorar la calidad del
Asignar l a primitiva a una clase modelo de analisis y la correspondiente especificaci6n de
Evaluar l a clase y anotar el peso valorado requisites: especificidad (ausencia de arnbigiiedad), com-
Multiplicar IPFuC por el peso valorado plecibn, correction, comprensi611, capacidad de verifica-
bang = bang t ponderaci6n IPFuC; ci6n, consistencia intema y extema, capacidad de logro,
FinMient ras concisibn, trazabilidad, capacidad de modificaci6n, exac-
La cuenta-token se calcula determinando cuantos titud y capacidad de reutilizaci6n. Ademas, 10s autores
simbolos lCxicos (tokens) diferentes son ccvisibles>> apuntan que las especificaciones de alta calidad deben
IDEM821 dentro de la primitiva. Es posible que el nume- estar almacenadas electrbnicamente, ser ejecutables o a1
ro de simbolos lCxicos (tokens) y el numero de elementos menos interpretables, anotadas por importancia y estabi-
de datos sea diferente, si 10s elementos de datos pueden lidad relativas, con su versi6n correspondiente, organiza-
moverse desde la entrada a la salida sin ninguna trans- das, con referencias cruzadas y especificadas a1 nivel
formaci6n intema. La IPFuC corregida se determina de correct0 de detalle.
una tabla publicada por DeMarco. A continuaci6n, se Aunque muchas de las caractensticas anteriores pare-
presenta una versi6n muy abreviada: cen ser de naturaleza cualitativa, Davis [DAV93] sugie-
I N G E N I E R ~ ADEL SOFTWARE. U N ENFOQUE P R ~ C T I C O
re que todas puedan representarse usando una o mas donde nUies el numero de requisitos para 10s que todos
mCtricas6. Por ejemplo, asumimos que hay nr requisi- 10s revisores tuvieron interpretaciones identicas. Cuan-
tos en una especificacion, tal como to mhs cerca de 1 estC el valor de Q, menor sera la ambi-
n,. = nf + n nf giiedad de la especificaci6n.
La compleci6n de 10s requisitos funcionales pueden
donde n es el numero de requisitos funcionales y nnf es determinarse calculando la relaci6n
f
el numero de requisitos no funcionales (por ejemplo,
rendimiento). = un / (ni x nJ
Q2
donde un es el numero de requisitos unicos de funcion,
ni es el numero de entradas (estimulos) definidos o
implicados por la especificaci6n y n, es el nCimero de
estados especificados. La relaci6n Q2 mide el porcen-
Para rnedir 10s corocteristicas de lo especificoci6n, es taje de funciones necesarias que se han especificado
necesorio conseguir profundizar cuantitativornente en lo para un sistema. Sin embargo, no trata 10s requisitos
especificidod y en la cornpletiiud. no funcionales. Para incorporarlos a una mCtrica glo-
bal completa, debemos considerar el grado de valida-
Para deterrninar la especificidad (ausencia de ambi- ci6n de 10s requisitos.
giiedad) de 10s requisitos. Davis sugiere una mCtrica Q3 = nc 1(n, + a,,,)
basada en la consistencia de la interpretaci6n de 10s revi- donde nc es el numero de requisitos que se han valida-
sores para cada requisito: do como correctos y nnvel ndmero de requisitos que no
se han validado todavia.
Es inconcebible que el diseiio de un nuevo avion, un En las siguientes secciones examinamos algunas de
nuevo chip de computadora o un nuevo edificio de ofi- las mCtricas de diseiio mhs comunes para el software de
cinas se realizara sin definir las medidas del diseiio, computadora. Aunque ninguna es perfecta, todas pue-
sin determinar las mCtricas para varios aspectos de la den proporcionar a1 diseiiador una mejor visi6n interna
calidad del diseiio y usarlas para guiar la evoluci6n del y ayudar a que el diseiio evolucione a un nivel superior
diseiio. Y sin embargo, el diseiio de sistemas comple- de calidad.
jos basados en computadora a menudo consigue pro-
seguir sin virtualmente ninguna medici6n. La ironia 19.4.1. Metricas del diseiio arquitectdnico
es que las mCtricas de diseiio para el software esthn
disponibles, pero la gran mayoria de 10s desarrollado- Las mCtricas de diseiio de alto nivel se concentran en
res dc software continuan sin saber que existen. las caracteristicas de la arquitectura del programa (Capi-
tulo 14) con especial Cnfasis en la estructura arquitec-
tonica y en la eficiencia de 10s m6dulos. Estas mktricas
son de caja negra en el sentido que no requieren ningun
conocimiento del trabajo intemo de un m6dulo en par-
ticular del sistema.
Card y Glass [CAR901 definen tres medidas de la
complejidad del disefio del software: complejidad
Las mCtricas de diseiio para el software, como otras estructural, complejidad de datos y complejidad del
mCtricas del software, no son perfectas. Continua el sistema.
debate sobre la eficacia y c6mo deberian aplicarse. La complejidad estructural, S(i), de un modulo i se
Muchos expertos argumentan que se necesita mhs expe- define de la siguiente manera:
rimentacion hasta que se puedan emplear las mCtricas
de disefio. Y sin embargo, el diseiio sin medicion es una s ( i ) =yOut(i) (19-1)
altemativa inaceptable. donde fou,(i) es la expansi6n7 del m6dulo i.
Un estudio completo de las metricas de calidad de especificacion Como s e dijo en el estudio introducido en el Capitulo 13, la expan-
esta mas alla del aicance de este capitulo. Vea [DAV93] para mas sion If,,) indica el numero de modulos inmediatamente subordina-
detalles. dos a1 modulo i, e s decir, el numero de modulos que son invocados
directamente por el modulo i.
CAP~TULO
19 M P T R I C A S T ~ C N I C A SDEL S O F T W A R E
donde n es el numero de nodos (modules) y a es el

n6mero de arcos (lineas de control). Para la arquitectu-
ra mostrada en la Figura 19.5,
Las mesitas pueden profundizar en la estruttura,
en 10s datos, y en la compleiidad del sistema asotiado
con el diseiio arquitett6nito.
La complejidad de datos, D(i), proporciona una indi- Profundidad
I
caci6n de la complejidad en la interfaz interna de un
modulo i y se define como:
donde v(i) es el ndmero de variables de entrada y sali-

da que entran y salen del m6dulo i.
Finalmente, la complejidad del sistema, C(i), se defi-
ne como la suma de las complejidades estructural y de
4 Anchura
datos, y se define como:
FIGURA 19.5. Metricas de morfologia
A medida que crecen 10s valores de complejidad, la tamaiio = 17 + 18 = 35

complejidad arquitCct6nica o global del sistema tam- profundidad= el camino m8s largo desde el nodo
bitn aumenta. Esto lleva a una mayor probabilidad de raiz (parte m6s alta) a un nodo hoja. Para la
que aumente el esfuerzo necesario para la integraci6n arquitectura mostrada en la Figura 19.5, la
y las pruebas. profundidad = 4.
hay un camino para anchura = maxim0 n6mero de nodos de cualquier
valorar la complejidad nivel de la arquitectura. Para la arquitectura mostra-
de ciertos modelos da en la Figura 19.5, la anchura = 6.
arquitectonicos? Relaci6n arco-a-nodo, r = a 1 n.
que mide la densidad de conectividad de la arquitectu-
Una mCtrica de disefio arquitect6nico de alto nivel, ra y puede proporcionar una sencilla indication del aco-
propuesta por Henry y Kafura [HEN81], tambitn emplea plamiento de la arquitectura. Para la arquitectura
la expansion y la concentraci6n. Los autores definen
mostrada en la Figura 19.5, r = 18 / 17 = 1,06.
una mttrica de complejidad de la forma:
MHK = longitud(i) x V;,,(i) + fOut(i)] (19.4)
donde la longitud(i) es el n6mero de sentencias en len-
guaje de programaci6n en el m6dulo i y fi,(i) es la con-
centraci6n del m6dulo i. Henry y Kafura amplian la
definici6n de concentraci6n y expansi6n presentadas
en este libro para incluir no s610 el n6mero de cone-
xiones de control del m6dulo (llamadas a1 mbdulo),
sin0 tambiCn el numero de estructuras de datos del que
el m6dulo i recoge (concentraci6n) o actualiza (expan- 19.4.2. Mdtricas d e diseiio a nivel de compo-
si6n) datos. Para calcular el MHK durante el diseiio nentes
puede emplearse el disefio procedimental para estimar Las mttricas de disefio a nivel de componentes se con-
el numero de sentencias del lenguaje de programaci6n centran en las caracteristicas internas de 10s compo-
del m6dulo i. Como en las mttricas de Card y Glass nentes del software e incluyen medidas de las cc3Cs>>
mencionadas anteriormente, un aumento en la mCtri- -la cohesibn, acoplamiento y complejidad del m6du-
ca de Henry-Kafura conduce a una mayor probabili- lo-. Estas tres medidas pueden ayudar a1 desarrolla-
dad de que tambitn aumente el esfuerzo de integraci6n dor de software a juzgar la calidad de un disefio a nivel
y pruebas del m6dulo. de 10s componentes.
Fenton [FEN9 11 sugiere varias mttricas de morfo- Las mCtricas presentadas en esta secci6n son de caja
logia simples (por ejemplo, forma) que permiten com- blanca en el sentido de que requieren conocimiento del
parar diferentes arquitecturas de programa mediante trabajo interno del m6dulo en cuesti6n. Las mttricas de
un conjunto de dimensiones directas. En la Figura 19.5, diseiio de 10s componentes se pueden aplicar una vez
se pueden definir las siguientes mCtricas: que se ha desarrollado un diseiio procedimental. Tam-
bitn se pueden retrasar hasta tener disponible el c6di-
go fuente.
porciones de datos de un m6dulo i). Como la relaci6n de
muestras de superuni6n con respecto a1 nlimero total de
muestras en un m6dulo i aumenta hasta un valor mixitno
Es posible colrular medidos de lo independencia de 1, la cohesi6n funcional del m6dulo tarnbiCn aumenta.
funcional, acoplamiento y cohesion de un componente Metricas de acoplamiento. El acoplamiento de
y usarlas para valorar lo calidad y el diseno. m6dulo proporciona una indicaci6n de la ccconectivi-
dad>>de un m6dulo con otros mbdulos, datos globales
Metricas de cohesion. Bieman y Ott [BIE94] defi- y el entorno exterior. En el Capitulo 13, el acoplamien-
nen una colecci6n de metricas que proporcionan una to se estudi6 en tCrminos cualitativos.
indicaci6n de la cohesi6n (Capitulo 13) de un m6dulo. Dhama [DHA95] ha propuesto una mktrica para el
Las metricas se definen con cinco conceptos y medidas: acoplamiento del m6dulo que combina el acoplamien-
Porcidn de datos. Dicho simplemente, una porcidn de datos to de flujo de datos y de control, acoplamiento global y
es una marcha atras a travCs de un modulo que busca valores acoplamiento de entorno. Las medidas necesarias para
de datos que afectan a la localizaci6nde mdulo en el que empe- calcular el acoplamiento de m6dulo se definen en tCr-
zo la marcha atrh. Deberia resaltarse que se pueden definir tan- minos de cada uno de 10s tres tipos de acoplamiento
to porciones de programas (que se centran en enunciados y apuntados anteriormente.
condiciones) como porciones de datos.
Para el acoplamiento de Jlujo de datos y de control:
Muestras (tokens) de daros. Las variables definidas para
di= numero de parimetros de datos de entrada
un modulo pueden definirse como muestras de datos para el
modulo. ci = numero de parhetros de control de entrada
Setiales de unidn. El conjunto de muestras de datos que se do = numero de parhetros de datos de salida
encuentran en una o mas porciones de datos. 5 = numero de parimetros de control de salida
Setiales de superunidn. La muestras de datos comunes a
todas las porciones de datos de un mhdulo.
Pegujosidad. La pegajosidad relativa de una muestra de
unidn es directamente proportional al numero de porciones de Referencia web/ '
datos que liga. El documento, ((Sisterno de rnehicas del saftware
Bieman y Ott desarrollan mCtricas para cohesiones para el acoplamiento de rnbdulosa podeis bajarlo de
funcionales fuertes (CFF), cohesionesfuncionales dtbi- www.isse.gmu.edu/faculty/ofut/rsrch/
les (CFD) y pegajosidad (el grado relativo con el que abstracts/mj-coupling.html
las sefiales de uni6n ligan juntas porciones de datos). Para el acoplamiento global:
Estas metricas se pueden interpretar de la siguiente
gd = numero de variables globales usadas como datos
manera [BIE94]:
g, = numero de variables globales usadas como control
Todas estas mCtricas de cohesion tienen valores que van de
0 a 1. Tienen un valor de 0 cuando un procedimiento tiene mis
de una salida y no muestra ningun atributo de cohesion indi- Para el acoplamiento de entorno:
cad0 por una mCtrica particular. Un procedimiento sin mues- w = numero de modulos llamados (expansion)
tras de superunion, sin muestm comunes a todas las porciones
r = numero de modulos que llaman a1 modulo en cuestion
de datos, no tiene una cohesion funcional fuerte (no hay sefia-
(concentration)
les de datos que contribuyan a todas las salidas). Un procedi-
miento sin muestras de union, es decir, sin muestras comunes Usando estas medidas, se define un indicador de aco-
a mas de una porcion de datos (en procedimientos con mis de plamiento de modulo, rn[, de la siguiente manera:
una porcion de datos). no muestra una cohesion funcional dCbil
y ninguna adhesividad (no hay seiiales de datos que contribu- m,= k 1 M
yan a m b de una salida). donde k=l es una constante de proporcionalidads.
La cohesion funcional fuerte y la pegajosidad se
obtienen cuando las mCtricas de Bieman y Ott toman
un valor maxim0 de 1. donde a=b=c=2.
Se deja un estudio m8s detallado de las metricas de Cuanto mayor es el valor de m,, menor es el aco-
Biemai ;I Ott para que Sean revisadas sus fuentes [BIE94]. plamiento de modulo. Por ejemplo, si un m6dulo tiene
Sin embargo, para ilustrar el car8cter de estas mCtricas, un solo par8metro de entrada y salida de datos, no acce-
considere la mktrica para la cohesi6n funcional fuerte: de a datos globales y es llamado por un solo m6dulo:
r n c = l / ( l + O + l + O + O + O + l +O)=l/3=0,33.
donde SU (SA(i)) denota muestra de superunion (el con- Deberiamos esperar que un m6dulo como Cste presentara
junto de sefiales de datos que se encuentran en todas las un acoplamiento bajo. De ahi que, un valor de m, = 0,33
El autor IDHA951 advierte que 10s valores de k y a, b y c (tratados

en la siguiente ecuacion) pueden ajustarse a medida que se van veri-
ficando experimentalmente.
CAPfTULO 19 M ~ T R I C A ST ~ C N I C A SDEL S O F T W A R E
implica un acoplamiento bajo. Por el contrario, si un m d u - modulo. Cuando la complejidad ciclomitica de 10s modu-
. lo tiene 5 parhetros de salida y 5 parhetros de entrada 10s excedian ese valor, resultaba extremadamente dificil
de datos, un numero igual de parhetros de control, acce- probar adecuadamente el modulo. Vea en el Capitulo 17
de a 10 elementos de datos globales y tiene una concen- un estudio sobre la complejidad ciclomatica como guia
tracion de 3 y una expansion de 4, para el disefio de casos de prueba de caja blanca.
mc= 1 / ( 5 + 2 x 5 + 5 + 2 ~ 5 + 10+0+3+4)=0,02
el acoplamiento implicado es grande. 19.4.3. Metricas de diseiio de interfaz
Para que aumente la mCtrica de acoplamiento a medi- Aunque existe una significativa cantidad de literatura
da que aumenta el grado de acoplamiento, se puede defi- sobre el disefio de interfaces hombre-inhquina (vea el
nir una mCtrica de acoplamiento revisada corno: Capitulo IS), se ha publicado relativamente poca infor-
macion sobre mktricas que proporcionen una vision inter-
na de la calidad y facilidad de empleo de la interfaz.
donde el grado de acoplamiento no aumenta linealmente Sears [SEA931 sugiere la conveniencia de la repre-
entre un valor minimo en el rango de 0,66 hasta un m k i - sentacibn (CR) como una valiosa mCtrica de disefio para
mo que se aproxima a 1,O. interfaces hombre-m8quina. Una IGU (Interfaz Grafi-
Metricas de complejidad. Se pueden calcular una ca de Usuario) tipica usa entidades de representacion
variedad de mCtricas del software para determinar la -iconos graficos, texto, menus, ventanas y otras- para
complejidad del flujo de control del programa. Muchas ayudar a1 usuario a completar tareas. Para realizar una
de Cstas se basan en una representacion denominada tarea dada usando una IGU, el usuario debe moverse de
grafo de flujo. Tal y como se dijo en el Capitulo 17, un una entidad de representacion a otra. Las posiciones
grafo es una representacion compuesta de nodos y enla- absolutas y relativas de cada entidad de representacion,
ces (tambiCn denominados aristas). Cuando se dirigen la frecuencia con que se utilizan y el cccoste>>
de la tran-
10s enlaces (aristas), el grafo de flujo es un grafo diri- sicion de una entidad de representacion a la siguiente
gido. contribuiran a la conveniencia de la interfaz.
McCabe [MCC94] identifica un numero importante
de usos para las metricas de complejidad:
Las metricas de cornplejidad pueden ernplearse para pre-
decir la inforrnacion critica sobre la fiabilidad y rnanteni-
rniento de sisternas software de analisis autornaticos de codigo
fuente (o inforrnacion de diseiio procedimental). Las rnetri-
cas de cornplejidad tarnbien realirnentan la inforrnacion
durante el proyecto de software para ayudar a controlar la
[actividad del disefio]. Durante las pruebas y el rnanteni- Para una representacion especifica (por ejemplo, un
rniento, proporcionan una detallada inforrnacidn sobre 10s
rn6dulos software para ayudar a resaltar las ireas de inesta- disefio de una IGU especifica), se pueden asignar cos-
bilidad potential. tes a cada secuencia de acciones de acuerdo con la
siguiente relacion:
La mCtrica de complejidad mhs ampliamente usada
(y debatida) para el software es la complejidad ciclomci- Costes = C [frecuencia de transicion (k) x
tica, originalmente desarrollada por Thomas McCabe x coste de transicion (k) ] (19.7)
[MCC76] y estudiando con detalle en la Secci6n 17.4.2. donde k es la transicion especifica de una entidad de
La mCtrica de McCabe proporciona una medida cuan- representacion a la siguiente cuando se realiza una tarea
titativa para probar la dificultad y una indicacion de la fia- especifica. Esta suma se da con todas las transiciones
bilidad 6ltima. Estudios experimentalesindican una fuerte de una tarea en particular o conjunto de tareas requeri-
correlaci6n entre la mCtrica de McCabe y el numero de das para conseguir alguna funcion de la aplicacion. El
errores que existen en el c6digo fuente, asi como el tiem- coste puede estar caracterizado en tCrminos de tiempo,
po requerido para encontrar y corregir dichos errores. retraso del proceso o cualquier otro valor razonable, tal
como la distancia que debe moverse el raton entre enti-
dades de la representacion.
La conveniencia de la representacion se define corno:
Lo mmplejidod drlomatico es solomente uno mbs CR = 100 x [(coste de la representacion optima CR) /
de 10s mochas meticas de complejidod. / (coste de la representacion propuesta)] (19.8)
McCabe tambiCn defiende que la complejidad ciclo- donde CR = 100 para una representacion 6ptima.
'
mhtica puede emplearse para proporcionar una indicacion Para calcular la representacion optima de una IGU,
cuantitativa del tamaiio maxim0 del modulo. Recogien- la superficie de la interfaz (el irea de la pantalla) se divi-
do datos de varios proyectos de programaci6n reales, ha de en una cuadricula. Cada cuadro de la cuadricula repre-
averiguado que una complejidad ciclomhtica de 10 pare- senta una posible posicion de una entidad de la
ce ser el limite prhctico superior para el tamafio de un representacion. Para una cuadricula con N posibles posi-
ciones y K diferentes entidades de representaci6n para La CR se emplea para valorar diferentes distribu-
. colocar, el numero posible de distribuciones se repre- ciones propuestas de IGU y la sensibilidad de una repre-
senta de la siguiente manera [SEA93]: sentaci6n en particular a 10s cambios en las descripciones
numero posible de distribuciones = de tareas (por ejemplo, cambios en la secuencia y/o fre-
= [ N ! / ( K ! x(N-K)!]xK! (19.9) cuencia de transiciones). El disefiador de interfaces pue-
de emplear el cambio en la conveniencia de la
A medida que crece el numero de posiciones de repre- representaci61-1,ACR, como guia en la elecci6n de la
sentaci61-1,el nfimero de distribuciones posibles se hace mejor representaci6n de IGU para una aplicaci6n en
muy grande. Para encontrar la representaci6n 6ptima particular.
(menor coste). Sears [SEA931 propone un algoritmo de Es importante apuntar que la selection de un disefio
busqueda en kbol. de IGU puede guiarse con mCtricas tales como CR, per0
el Pbitro final deberia ser la respuesta del usuario basa-
da en prototipos de IGU. Nielsen y Levy [NIE94] infor-
10s metricas del disefio de interface son vblidos, pero man que ccexiste una gran posibilidad de Cxito si se elige
sobre todo, son obsolutomente necesorios poro oseguror una interfaz bashdose solamente en la opinion del usua-
que o 10s usuorios finales les ogrodo lo intefoce y esten no. El rendimiento medio de tareas de usuario y su satis-
sotisfechos con 10s interocciones requeridos. faction con la IGU estan altamente relacionadas.>>
La teoria de Halstead de la ciencia del software [HAL771 Halstead usa las medidas primitivas para desarro-
es ccprobablemente la mejor conocida y mas minucio- llar expresiones para la longitud global del programa;
samente estudiada ... medidas compuestas de la com- volumen minimo potencial para un algoritmo; el volu-
plejidad (software)>>[CUR80]. La ciencia del software men real (numero de bits requeridos para especificar
propone las primeras eeleyes>> analiticas para el softwa- un programa); el nivel del programa (una medida de
re de computadora9. la complejidad del software); nivel del lenguaje (una
constante para un lenguaje dado); y otras caracteristi-
cas tales como esfuerzo de desarrollo, tiempo de desa-
rrollo e incluso el numero esperado de fallos en el
software.
Halstead expone que la longitud N se puede estimar
corno:
La ciencia del software asigna leyes cuantitativas a1

desarrollo del software de computadora, usando un con- y el volumen de programa se puede definir corno:
junto de medidas primitivas que pueden obtenerse una vez
que se ha generado o estirnado el codigo despuCs de com-
pletar el disefio. Estas medidas se listan a continuaci6n. Se deberia tener en cuenta que V variari con el len-
nl: el nlimero de operadores diferentes que aparecen en el guaje de programaci6n y representa el volumen de infor-
programa
maci6n (en bits) necesarios para especificar un
n2: el nlimero de operandos diferentes que aparecen en el programa.
programa
Te6ricamente, debe existir un volumen minimo para
Nl: el nlimero total de veces que aparece el operador un algoritmo. Halstead define una relacion de volumen
N2: el nlimero total de veces que aparece el operando L como la relaci6n de volumen de la forma mis com-
pacts de un programa con respecto a1 volumen real del
programa. Por tanto, L debe ser siempre menor de uno.
En tCrminos de medidas primitivas, la relaci6n de volu-
10s operodores incluyen todos 10s conshvciones del flu0 de men se puede expresar como
conto/, condiciones y operociones motemuiicos. Los operondos
ogmpan todos 10s voriobles y constontes del pmgromo.
9 Se deberia resaltar que las deyes~~ de Halstead han generado una

sustancial controversia y que no todo el mundo esta de acuerdo con
que la teoria subyacente sea corrects. Sin embargo, se han realizado
verificaciones experimentales de las averiguacionesde Halstead para
varios lenguajes de programacion (por ejemplo, [FEL89]).
CAPfTULO 19 METRICAS TECNICAS DEL SOFTWARE
El trabajo de Halstead se presta a la verification expe- per0 puede decirse que se ha llegado a un buen acuer-
rimental y de hecho se ha desarrollado una gran labor do entre lo previsto analiticamentey 10s resultados expe-
de investigation en la ciencia del software. Un estudio rimentales. Para rnhs informaci61-1, vea [ZUS90],
de este trabajo estaria fuera del alcance de este libro, [FEN911 y [ZUS97].
Aunque se ha escrito mucho sobre las mCtricas del soft- de disefio de casos de prueba presentado en el Capitu-
ware para pruebas (por ejemplo, [HET93]), la mayoria lo 17. Ademhs, la complejidad ciclomhtica puede usar-
de las metricas propuestas se concentran en el proceso se para elegir m6dulos como candidatos para pruebas
de prueba, no en las caracteristicas tCcnicas de las prue- rnhs profundas (Capitulo 18). Los m6dulos con gran
bas mismas. En general, 10s responsables de las prue- complejidad ciclomhtica tienen rnhs probabilidad de ten-
bas deben fiarse de las metricas de anhlisis, disefio y dencia a errores que 10s m6dulos con menor compleji-
c6digo para que les guien en el disefio y ejecucion de dad ciclomhtica.
10s casos de prueba. Por esta razon, el analista deben'a invertir un esfuerzo
extra para descubrir errores en el modulo antes de inte-
grarlo en un sistema. Es esfuerzo de las pruebas tambiCn
se puede estimar usando mCtricas obtenidas de medidas
de Halstead (Secci6n 19.5). Usando la definici6n del volu-
10s metricas de la prueba desembocan en las siguientes men de un programa, V, y nivel de programa, NP, el
categorias:(l) metric05 que ayudan a determinor esfuerzo de la ciencia del software, e, puede calcularse
el nirmero de pruebas requeridas en 10s distintos niveles como:
de la prueba; (2)metricas para cubrir la prueba
de un componente dado.
Las metricas basadas en la funci6n (Secci6n 19.3.1) e = VINP (19.13b)

pueden emplearse para predecir el esfuerzo global de El porcentaje del esfuerzo global de pruebas a asig-
las pruebas. Se pueden juntar y correlacionar varias nar a un modulo k se puede estimar usando la siguien-
caracteristicas a nivel de proyecto (por ejemplo, esfuer- te relacion:
zo y tiempo para las pruebas, errores descubiertos,
numero de casos de prueba producidos) de proyectos porcentaje de esfuerzo de pruebas (k) =
anteriores con el numero de PF producidos por un equi- e(k)lCe(i) (19.14)
po del proyecto. El equipo puede despuCs predecir 10s donde e(k) se calcula para el modulo k usando las
valores <<esperados>> de estas caracteristicasdel proyecto ecuaciones (19.13) y la suma en el denominador de
actual. la ecuacion (19.14) es la suma del esfuerzo de la cien-
La mCtrica bang puede proporcionar una indicacion cia del software a lo largo de todos 10s modulos del
del numero de casos de prueba necesarios para exami- sistema.
nar las medidas primitivas tratadas en la secci6n 19.3.2. A medida que se van haciendo las pruebas, tres medi-
El numero de primitivas funcionales (PFu), elementos das diferentes proporcionan una indicaci6n de la com-
de datos (DE), objetos (OB), relaciones (RE), estados pleci6n de las pruebas. Una medida de la amplitud de
(ES) y transiciones (TR) pueden emplearse para prede- las pruebas proporciona una indicacion de cuantos
cir el numero y tipos de prueba del software de caja requisitos (del numero total de ellos) se han probado.
negra y de caja blanca. Por ejemplo, el numero de prue- Esto proporciona una indicaci6n de la complecion del
bas asociadas con la interfaz hombre-maquina se pue- plan de pruebas. La profundidad de las pruebas es una
de estimar examinando: (1) el numero de transiciones medida del porcentaje de 10s caminos basicos indepen-
(TR) contenidas en la representacion estado-transici6n dientes probados en relacion a1 numero total de estos
del IHM y evaluando las pruebas requeridas para eje- caminos en el programa. Se puede calcular una estima-
cutar cada transici6n, (2) el numero de objetos de datos ci6n razonablemente exacta del numero de caminos bhsi-
(OB) que se mueven a travCs de la interfaz y (3) el nume- cos sumando la complejidad ciclomhtica de todos 10s
ro de elementos de datos que se introducen o salen. modulos del programa. Finalmente, a medida que se
Las mCtricas del disefio arquitectonico proporcionan van haciendo las pruebas y se recogen 10s datos de 10s
informaci6n sobre la facilidad o dificultad asociada con errores, se pueden emplear 10s perfiles de,fallos para dar
la prueba de integration (Capitulo 18) y la necesidad prioridad y categorizar 10s errores descubiertos. La prio-
de software especializado de prueba (por ejemplo, matri- ridad indica la severidad del problema. Las categorias
ces y controladores). La complejidad ciclomhtica (una de 10s fallos proporcionan una descripci6n de un error,
mCtrica de disefio de componentes) se encuentra en el de manera que se puedan llevar a cab0 anhlisis estadis-
nucleo de las pruebas de caminos bhsicos, un mCtodo ticos de errores.
~NGEN~ER ~ ASOFTWARE. UN ENFOQUE PRACTICO
DEL
Todas las mCtricas del software presentadas en este capi- Fa gumero de mdulos en la version actual que se han aiia-
tulo pueden usarse para el desarrollo de nuevo softwa- dido
Fd=numero de mdulos de la version anterior que se han
re y para el mantenimiento del existente. Sin embargo,
borrado en la version actual
se han propuesto mCtricas diseiiadas explicitamentepara
El indice de madurez del software se calcula de la
actividades de mantenimiento.
siguiente manera:
El esthdar IEEE 982.1- 1988 [IEE94] sugiere un indi-
IMS=[MT-(F,+Fc+Fd)]/MT (19.15)
ce de madurez del software (IMS) que proporciona una
indicacibn de la estabilidad de un producto software (basa- A medida que el IMS se aproxima a I ,O el producto
da en 10s cambiosque ocurren con cada versi6n del pro- se empieza a estabilizar. EL IMS puede emplearse tam-
duct~).Se determina la siguiente informacion: biCn como mCtrica para la planificaci6n de las activi-
dades de mantenimiento del software. El tiempo medio
MT= numero de mddulos en la version actual para producir una versi6n de un producto software pue-
F, = numero de modules en la version actual que se han de correlacionarse con el IMS desarrollandose mode-
cambiado 10s empiricos para el mantenimiento.
Las metricas del software proporcionan una manera de diseiio de alto nivel consideran 10s aspectos arqui-
cuantitativa de valorar la calidad de 10s atributos inter- tect6nicos y estructurales del modelo de disefio. Las
nos del producto, permitiendo por tanto a1 ingeniero mCtricas de diseiio de nivel de componentes propor-
valorar la calidad antes de construir el producto. Las cionan una indicaci6n de la calidad del m6dulo esta-
metricas proporcionan la vision interna necesaria para bleciendo medidas indirectas de la cohesion,
crear modelos efectivos de analisis y diseiio, un c6digo acoplamiento y complejidad. Las mCtricas de diseiio de
solido y pruebas minuciosas. interfaz proporcionan una indicaci6n de la convenien-
Para que sea util en el context0 del mundo real, una cia de la representaci6n de una IGU.
mCtrica del software debe ser simple y calculable, per- La ciencia del software proporciona un intrigante
suasiva, consistente y objetiva. Deberia ser indepen- conjunto de metricas a nivel de c6digo fuente. Usando
diente del lenguaje de programaci6n y proporcionar el numero de operadores y operandos presentes en el
una realimentacibn eficaz para el desarrollador de soft- c6dig0, la ciencia del software proporciona una varie-
ware. dad de mCtricas que pueden usarse para valorar la cali-
Las metricas del modelo de analisis se concentran dad del programa.
en la funcion, 10s datos y el comportamiento (10s tres Se han propuesto pocas mCtricas tCcnicas para un
componentes del modelo de analisis). El punto de fun- empleo direct0 en las pruebas y mantenimiento del soft-
ci6n y la mCtrica bang proporcionan medidas cuantita- ware. Sin embargo, se pueden emplear muchas otras
tivas para evaluar el modelo de analisis. Las metricas metricas tCcnicas para guiar el proceso de Las pruebas
del diseiio consideran aspectos de alto nivel, del nivel y como mecanismo para valorar la facilidad de mante-
de componentes y de diseiio de interfaz. Las metricas nimiento de un programa de computadora.
[BAS841 Basili, y V.R. D.M. Weiss, <<AMethodology for [CAV78] Cavano, J.P., y J.A. McCall, <<AFramework for the
Collecting Valid Software Engineering Data)),IEEE Trans. Measurement of Software Quality)),Proc. ACM Software
Software Engineering, vol. SE-10, 1984, pp. 728-738. Quality Assurance Wokshop, Noviembre 1978, pp. 133-
139.
[BIE94] Bieman, J.M., y L.M. Ott, <<MeasuringFunctional
Cohesion),, IEEE Trans. Software Engineering, vol. 20, [CHA89] Charette, R.N., Software Engineering RiskAnaly-
n." 8, Agosto 1994, pp. 308-320. sis and Management, McGraw-Hillbntertext, 1989.
[BRI96] Briand, L.C., S. Morasca, y V.R. Basili, c@roperty-Based [CUR801 Curtis, W., <<Managementand Experimentation in
Software Engineering Measurement,,, IEEE Trans. SofhYa- Software Engineering,,, Proc. IEEE, vol. 68, n." 9, Sep-
re Engineering, vol22, n." 1, Enero 1996, pp. 68-85. tiembre 1980.
[CAR901 Card, D., y N. R. L. Glass, Measuring Software [DAV93] Davis, A., et al., <<Identifyingand Measuring Qua-
Design Quality, Prentice-Hall, 1990. lity in a Software Requirements Specification>>,Proc. lSt
CAPiTULO 19 M e T R I C A S T E C N I C A S DEL S O F T W A R E
Intl. Software Metrics Symposium, IEEE, Baltimore, MD, [IEE94] Sofrware Engineering Standards, 1994, IEEE, 1994.
May 1993, pp. 141-152. [KYB84] Kyburg, H.E., Theory and Measurement, Cambridge
[DEM81] DeMillo, R.A., y R.J. Lipton, <<SoftwareProject University Press, 1984.
Forecasting,,, Software Metrics (A.J. Perlis, F.G. Sayward [MCC76] McCabe, T.J., aA Software Complexity Measure,,
y M. Shaw, ed.), MIT Press, 1981, pp. 77-89. IEEE Trans. Software Engineering, vol. 2, Diciembre 1976,
[DEM82] DeMarco, T., Controlling Software Projects, Your- pp. 308-320.
don Press, 1982. [MCC77] McCall, J., P. Richards, y G. Walters, <<Factorsin
[DHA95] Dhama, H., <<QuantitativeModels of Cohesion and Software Quality,,, 3 vols., NTIS AD-A049-014,015,055,
Coupling in Software,, Journal of Systems and Software, Noviembre 1977.
vol. 29, n." 4, Abril 1995. [MCC89] McCabe, T.J., y C.W. Butler, <<DesignComplexity
[En911 Ejiogu, L., Sofrware Engineering with Formal Metrics, Measurement and Testing,,, CACM, vol. 32, n." 12,
QED Publishing, 1991. Diciembre 1989, pp. 1415-1425.
[FEL89] Felican, L., y G. Zalateu, <<ValidatingHalstead's [MCC94] McCabe, T.J., y A.H. Watson, <<SoftwareComple-
Theory for Pascal Programs,,, IEEE Trans. Software Engi- xity,,, Crosstalk, vol. 7, n." 12, Diciembre 1994, pp. 5-9.
neering, vol. 15, n." 2, Diciembre 1989, pp. 1630-1632. [NIE94] Nielsen, J., y J. Levy, measuring Usability: Prefe-
[FEN911 Fenton, N., Software Metrics, Chapman & Hall, rence vs. Performance,,, CACM, vol. 37, n." 4, Abril1994,
1991. pp. 76-85.
[FEN941 Fenton, N., <<SoftwareMeasurement: A Necessary [ROC941 Roche, J.M., <<SoftwareMetrics and Measurement
Scientific Basis,,, IEEE Trans. Software Engineering, vol. Principles,, Software Engineering Notes, ACM, vol. 19,
20, n." 3, Marzo 1994, pp. 199-206. n." 1, Enero 1994, pp. 76-85.
[GRA87] Grady, R. B., y D.L. Caswell, Sofrware Metrics: Esta- [SEA931Sears,A., <<Layout Appropriateness: A Metric for Eva-
blishing a Company-Wide Program, Prentice-Hall, 1987. luating User Interface Widget Layout,,, IEEE Trans. Soft-
ware Engineering, vol. 19, n." 7, Julio 1993, pp. 707-7 19.
[HA771 Halstead, M., Elements of Software Science, N.%h
Holland, 1977. [USA871 Management Quality Insight, AFCSP 800-14 (U.S.
Air Force), 20 Enero, 1987.
[HEN811 Henry, S., y D. Kafura, <<SoftwareStructure Metrics
Based on information Flow,,, IEEE Trans. Software Engi- [ZUS90]Zuse, H., Software Complexity:Measures and Methods,
neering, vol. SE-7, n." 5, Septiembre 1981, pp. 510-518. DeGruyter, Nueva York, 1990.
[HET93] Hetzel, B., Making Software Measurement Work, [ZUS97] Zuse, H., A Framework of Software Measurement,
QED Publishing, 1993. DeGruyter, Nueva York, 1997.
19.1. La teoria de la medicidn es un tema avanzado que tie- 19.3.2., desarrolle cuentas primitivas para la mCtrica bang. jEl
ne una gran influencia en las mCtricas del software. Median- sistema SSRB es de dominio de funci6n o de datos?
te [FEN91], [ZUS90] y [KYB84] u otras fuentes, escriba una 19.6. Calcule el valor de la mCtrica bang usando las medidas
pequeiia redaccidn que recoja 10s principales principios de la que desarroll6 en el Problema 19.5.
teoria de la medici6n. Proyecto individual: Prepare una con-
ferencia sobre el tema y expdngala en clase. 19.7. Cree un modelo de diseiio completo para un sistema
propuesto por su profesor. Calcule la complejidad estructural
19.2. Los factores de calidad de McCall se desarrollaron y de datos usando las mCtricas descritas en la Secci6n 19.4.1.
durante 10s aiios setenta. Casi todos 10s aspectos de la infor- Calcule tambiCn las mCtricas de Henry-Kafura y de morfolo-
mktica han cambiado dramkticamente desde que se desarro- gia para el modelo de diseiio.
llaron, y sin embargo, 10s factores de McCall todavia se aplican
en el software modemo. jPuede sacar alguna conclusi6n basa- 19.8. Un sistema de informaci6n grande tiene 1.140 modu-
da en este hecho? 10s. Hay 96 modulos que realizan funciones de control y coor-
dinacibn, y 490 cuya funcidn depende de un proceso anterior.
19.3. Por quC no se puede desarrollar una unica mCtrica que El sistema procesa aproximadamente 220 objetos de datos con
lo abarque todo para la complejidad o calidad de un progra- una media de tres atributos por objeto de datos. Hay 140 ele-
ma? mentos de la base de datos dnicos y 90 segmentos de base de
19.4. Revise el modelo de anklisis que desarroll6 como par- datos diferentes. 600 m6dulos tienen un solo punto de entra-
te del Problema 12.13. Mediante las directrices de la Secci6n da y de salida. Calcule el ICDE del sistema.
19.3.1 ., desarrolle una estimacidn del ndmero de puntos fun- 19.9. Investigue el trabajo de Bieman y Ott PIE941 y desarro-
ci6n asociados con SSRB. lle un ejemplo completo que ilustre el cklculo de su mCtrica de
19.5. Revise el modelo de anklisis que desarroll6 como par- cohesi6n. Asegikse de indicar c6mo se determinan las porcio-
te del Problema 12.13. Mediante las directrices de la Secci6n nes de datos, seiiales de datos y sefiales de uni6n y ~upeIU~6n.
I N G E N ~ E R DEL
19.10. Seleccione cinco mddulos existentes de un progra- 19.13. Desarrolle una pequefia herramienta de software que
ma de computadora. Mediante la metrica de Dhama descrita realice un analisis Halstead de un cddigo fuente de un lenguaje
en la Secci6n 19.4.2., calcule el valor de acoplamiento de de programacion a su elecci6n.
cada modulo. 19.14. Haga una investigation y escriba un documento sobre
la relacion entre las mCtricas de la calidad del software de Hals-
19.11. Desarrolle una herramienta de software que calcule
tead y la de McCabe (con respecto a la cuenta de errores). [,Son
la complejidad ciclomitica de un modulo de lenguaje de pro-
convincentes 10s datos? Recomiende unas directrices para la
gramaci6n. Elija el lenguaje. aplicacidn de estas metricas.
19.12. Desarrolle una herramienta de software que calcule 19.15. Investigue documentos recientes en busca de mCtri-
la conveniencia de la representaci6n de una IGU. Esa herra- cas especificamente disefiadas para el disefio de casos de prue-
mienta deberia permitirle asignar el coste de transici6n entre ba. Exponga 10s resultados en clase.
las entidades de la representaci6n. (Nota: fijese en que el tama- 19.16. Un sistema heredado tiene 940 modulos. La liltima
fio potencial del nlimero de las alternativas de representacidn version requiere el cambio de 90 de estos mbdulos. Ademas,
crece mucho a medida que aumenta el nlimero de posibles se aiiaden 40 m6dulos nuevos y se quitaron 12 m6dulos anti-
posiciones de cuadricula.) guos. Calcule el indice de madurez del software del sistema.
Sorprendentemente hay un gran nlimero de libros dedicados La teoria de la medicion del software la presentan Den-
a las metricas del software, aunque la mayoria est6n enfoca- vir, Herman, y Whitty en una colecci6n de documentos
dos a mCtricas de proceso y proyecto excluyendo las mCtri- (Proceedings of the International BCS-FACS Workshop:
cas tCcnicas. Zuse [ZUS97] ha escrito el mas completo tratado Formal Aspects of Measurement, Springer-Verlag, 1992).
de mCtricas tCcnicas publicado hasta la fecha. Shepperd (Foundations of Software Measurement, Prenti-
Los libros de Card y Glass [CAR90], Zuse [ZUS90], Fen- ce Hall, 1996) tambiCn tratan la teoria de la medicion en
ton [FEN91], Ejiogu [EJI91], Moeller y Paulish (MCmcas del detalle.
Software, Chapman & Hall, 1993) y Hetzel [HET93] son refe- Una relaci6n de docenas de usos de las mCtricas del soft-
rencias sobre las mCtricas tCcnicas en detalle. Ademas, mere- ware estin presentadas en [IEE94]. En general, una discu-
ce la pena examinar 10s siguientes libros: si6n de cada mCtrica ha sido reducida a lo esencial cdas
Conte, S.D.,H.E. Dunsrnore, y V.Y. Shen, Sofhvare Engineering Metrics primitivasn (medidas) requeridas para calcular las mCtricas
and Models, Benjarnin/Cumrnings, 1984. y las adecuadas relaciones a efectos de 10s cilculos. Un apCn-
Fenton, N.E., y S.L. Pfleeger, Sofhare Metrics: A Rigorous and Prac- dice del libro suministra mis informaci6n y referencias sobre
~icalApproach, 2.%d., PWS Publishing Co., 1998. el tema.
Grady, R.B. Practical Sofhvare Metrics for Project Manyement and Pro- Una amplia variedad de fuentes de informacion sobre
cess Inzprovement, Prentice Hall, 1992. metricas tCcnicas y elementos relacionados estin disponi-
Perlis, A., et al., Software Metrics: An Analysis and Evalua- bles en Internet. Una lista actualizada de referencias de pigi-
tion, MIT Press, 1981. nas web sobre mCtricas tCcnicas la puedes encontrar en
Sheppard, M., Sofnyare Engineering Metrics, McGraw-Hill, 1992. http://www.pressman5.com.
PARLTE
Q DEL SOFTWARE
ORIENTADA A OBJETOS
E
N esta parte'de Ingenierin del so@are: un enfoque practko considera-
mos 10s conceptos tecnicos, metodos y medidas aplicables al analisis,
disefio y pruebas de software orientado a objetos. En 10s siguientes capi-
tulos responderemos las siguientes preguntas:
iCuales son 10s conceptos y principios bisicos aplicables a1 pensamiento

orientado a objetos?
iEn quk se diferencian el enfoque tradicional y el orientado a objetos?
~ C O deben
~ O gestionarse y planificarse 10sproyectos orientados objetos?
iQuk es el analisis orientado a objetos y como permiten sus distintos mode-
10s comprender las clases, sus relaciones y comportamiento al ingeniero
del software?
iCu&lesson 10selementos de un modelo de disefio orientado a objetos?
~Cualesson 10s conceptos y principios basicos aplicables a las pruebas de
software orientado a objetos?
iC6n10 cambian las estrategias de prueba y 10smetodos de disefio de casos
de prueba cuando se considera el software orientado a objetos?
~ Q u Cmetricas tkcnicas estan disponibles para evaluar la calidad del soft-
ware orientado a objetos?
Una vez contestadas estas preguntas, cornprendera como analizar, disefiar,
implementar y probar el software usando el paradigma de orientacion a objetos.
CONCEPTOS Y PRINCIPIOS
ORIENTADOS A OBJETOS
Palabras c l a v e
atributos.. ......... .347
closes ..............346
encapsubdh ........346
estimadh 00.. .... .357
v IVIMOS en un mundo de objetos. Estos objetos existen en la naturaleza, en entidades
hechas por el hombre, en 10s negocios y en 10s productos que usamos. Pueden ser cla-
sificados, descritos, organizados, combinados, manipulados y creados. Por esto no es
sorprendente que se proponga una visi6n orientada a objetos para la creacidn de software de
computadora, una abstraction que modela el mundo de forma tal que nos ayuda a entenderlo y
gobernarlo mejor.
herencia ........... .348
La primera vez que se propuso un enfoque orientado a objetos para el desarrollo de softwa-
iecarquia de Joses ...349 re fue a finales de 10s afios sesenta. Sin embargo, las tecnologias de objetos han necesitado casi
mensaip ........... .347 veinte aiios para llegar a ser ampliamente usadas. Durante 10s aiios 90, la ingenieria del soft-
mitricas 00.. ...... 356 ware orientada a ob-ietos se conv-irti6 en el paradigma de elecci6n para much& productores de
modelo software y para un creciente numero de siskmas de informacidn iprofesionales de la ingenie-
de procesos 00.. .34 4-345 ria. A medida que pasa el tiempo, las tecnologias de objetos esthn sustituyendo a 10s enfoques
MPC para 00.......-355 clhsicos de desarrollo de software. Una pregunta importante es: iPor quC?
objetos ............ -346 La respuesta (como muchas otras respuestas a interrogantes sobre ingenieria del software)
operodones .........347 no es sencilla. Algunas personas argumentarian que 10s profesionales del software scncilla-
mente aioraban un nuevo enfoque, per0 esta visi6n es muy simplista. Las tecnologias de obje-
proceso
recursivo/parolelo ...355
to llevan un numero de beneficios inherentes que proporcionan ventajas a 10s niveles de direction
y tCcnico.
~ Q u es?
d Hay muchas formas de enlocar Esta importante caracteristica permi- del problema, el diseiio proporciona
un problema utilizando una solucidn te constmir clases de objetos e inhe- detalles sobre la arquitectura, las inter-
basada en el software. Un enfoque muy rentemente construir bibliotecas d e faces y 10s componentes, la imple-
utilizado e s la visi6n orientada a ob&- objetos y clases reutilizables. El para- mentacibn (utilizando un lenguaje
tos. El dominio del problema se caracte- digma de wientaci6n a objetos e s tan orientado a objetos) transfoxma el dise-
riza mediante un conjuntode objetoscan atractivo para tantas organizaciones iio e n cirdigo, y las pruebas chequean
crtributm y mmportamientos especificos. d e desarrollo d e software debido a tanto la arquitectura como las interfa-
Los objetm son manipulados mediante que la reutilizaci6n e s un atributo ces y los componentes.
una coleccidn de funciones (Ilamadas importantisimo en l a ingenierfa del &Cub1es el producto obtenido? Se
metodos, operaciones o servicios) y s e software. Ademas, 10s componentes produce un conjunto d e modelos orien-
cmmunican entre ellm mediante un pro- d e software derivados mediante el tados a objetos. Estos modelos descri-
tocolode mensajes. Los objetos se clasi- paradigma de objetos muestran carac- ben 10s requisitos, el disefio, el c6digo
fican medicmte clases y subclases. teristicas (como la independencia fun- y 10s procesos de pruebas para un sis-
&Quit511lo hace? La defjnici6n d e objetos clonal, la ocultacidn d e inlormacidn. tema o producto.
implica la description de atributos, com- etc.) asociadas con el software d e a h a iC6mo puedo esfar seguro de que
porlamientos, operaciones y mensajes. calidad. lo he hecho correctamente? En
Esta actividad la realiza un ingeniero &uales son 10s pasos? La ingenieria d a etapa s e revisa la claridad d e 10s
del software. del software orientado a objetos sigue productos de trabajo orientados a obje-
&Potqui e s importante? Un objeto 10s mismos pasos que el enfoque con- tos, su correccibn, complecl6n y con-
encapsula tanto datos como 10s pro- vencional. El analisis identiiica las cla- sistencia con loa requisitos del cIlente
cesos q u e s e aplican a esos datos. ses y objetos relevantes en el dominio y entre ellos.
Las tecnologias de objetos llevan a reutilizar, y la reutilizaci6n (de componente de softwa-

re) lleva a un desarrollo de software mhs rhpido y a programas de mejor calidad. El software
orientado a objetos es mljls fhcil de mantener debido a que su estructura es inherentemente poco
acoplada. Esto lleva a menores efectos colaterales cuando se deben hacer cambios y provoca
menos frustraci6n en el ingeniero del software y en el cliente. AdemAs, 10s sistemas orientados
a objetos son mAs fhciles de adaptar y mas fhcilmente escalables (por ejemplo: pueden c r e m e
grandes sistemas ensamblando subsistemas reutilizables).
En este capitulo presentamos 10s principios y conceptos bAsicos que forman el fundamento
para la comprensi6n de tecnologias de objetos.
Durante muchos afios el tdrmino orientado a objetos
(00)se us0 para referirse a un enfoque de desarrollo
de software que usaba uno de 10s lenguajes orientados
a objetos (Ada 95. C++, Eiffel, Smalltalk, etc.). Hoy en 10s sistemas 00 utilizan un modelo de ingenieria
dia el paradigma 00 encierra una completa visi6n de mediante proceso evolutivo. M6s adelante, en este
la ingenieria del software. Edward Berard hace notar mismo capitulo, nos referiremos a el como el modelo
esto cuando declara [BER93]: retursivo poralelo.
Los bencficios de la tecnologia orientada o objetos se for-
talecen si se usa antcs y durirntc cl proceso de ingenieria del En el Capitulo 2, examinamos un numero de mode-
soAwnre. Esta tecnologh orientda a ob,jelosconsiderada debe 10s de procesos diferentes para la ingenieria del softwa-
hacer sentir su impacto en todo el proceso de ingenieria del
re. Aunque ninguno de estos modelos pudo ser adaptado
sotiware. Un simple uso de programacidn orientnda a objetos
(POO) no brindari 10s mejores resultatlos. Los ingenieros del para su uso con 00, la mejor selection reconoceria que
s o h a r e y sus directores deben consitlerar tales elernenlos el 10s sistemas 00 tienden a evolucionar con el tiempo.
anilisis de requisites oricntndo a objetos (AROO), el disefio Por esto, un modelo evolutivo de proceso acoplado con
orientado a objetos (DOO), el aniliais del dorninio orientado un enfoque que fomenta el ensa~nblaje(reutilizaci6n) de
a objetos (ADOO), siste~nasde gestidn de bases de dabs orien- componentes es el mejor paradigma para ingenieria del
tatlas a ob,jetos (SGBDOO) y la ingcnieria del software orien-
13da 3 objetos asistidi~por computadora (ISOOAC).
software 00.En la Figura 20.1 el modelo de proceso de
ensamblaje de componentes (Capitulo 2) ha sido adap-
tado a la ingenieria del software 00.
fkii construir
I que dedicurse a
lU ~ l U ~ l U l l 1 U L 1 UXLUGllCIUI.
ll
David Taylor Una de las listas mas tompletas de retursos 00

en lo web puede consultarse en
El lector i'amiliarizado con el enfoque conventional mini.net/cetus/softwore.htm).
de ingenieria del software (presentada en la tercera par-
te de este libro) puede reaccionnr ante esta declaraci6n El proceso 00 se mueve a travCs de una espiral evo-
con esta pregunta: <ciCuliles la gran ventaja? Usamos lutiva que comienza con la comunicaci6n con el usua-
el andisis. disefio. la programacion. las pruebas y otras rio. Es aqui clonde se define el dominio del problema y
tecnologias relacionadas cuando realizamos ingenieria se identifican las clases brisicas clel problema (tratadas
del software segrin mCtodos clkicos. iPor q d debe ser mris tarde en este capitulo). La planificaci6n y el anlili-
la 00 diferente'?>>Ciertamente, i,por q d debe ser la 00 sis de riesgos establecen una base para el plan del pro-
cliferente? En pocas palabras, in0 debiera! yecto 00. El trabajo tkcnico asociado con la ingenieria
del software 00 sigue el camino iterativo mostrado en
la caja sombreada. La ingenieria del software 00 hace
hincapik en la reutilizaci6n. Por lo tanto, las clases se
Clase: mobiliario El obj eto hereda todos

atributos de la clase
cost0
Dimensiones
Objeto: s i l l a
si no existen
Diseio 00
Programacion 00
. : .1 Dimensiones
Local izaci6n
I
FIGURA 20.1. E l m o d e l o d e p r o c e s o 00. FIGURA 20.2. H e r e n c i a d e c l a s e a o b j e t o .
C A P ~ T U L O20 CONCEPTOS Y PRINCIPIOS ORIENTADOS A OBlETOS
buscan en una biblioteca (de clases 00 existentes) antes La vision orientada a objetos demanda un enfoque
. de construirse. Cuando una clase no puede encontrarse evolutivo de la ingenieria del software. Como veremos
en la biblioteca, el desarrollador de software aplica an& a travCs de este y 10s pr6ximos capitulos, sera extrema-
lisis orientado a objetos (AOO), disefio orientado a obje- damente dificil definir las clases necesarias para un gran
tos (DOO), programaci6n orientada a objetos (POO) y sistema o product0 en una sola iteracci6n. A medida que
pruebas orientadas a objetos (PROO) para crear la cla- el analisis 00 y 10s modelos de disefio evolucionan, se
se y 10s objetos derivados de la clase. La nueva clase se hace patente la necesidad de clases adicionales. Es por
pone en la biblioteca de tal manera que pueda ser reu- esta raz6n por lo que el paradigma arriba descrito fun-
tilizada en el futuro. ciona mejor para la 0 0 .
Cualquier discusi6n sobre ingenieria del software

Clase: mobiliario El objeto hereda
orientada a objetos debe comenzar por el tCrmino todos 10s atributos
orientado a objetos. ~ Q u Ces un punto de vista orien- y operaciones de la clase
tad0 a objetos? ~ Q u Chace que un mCtodo sea consi- Dimensiones
derado como orientado a objetos? iQuC es un objeto? ~ocalizaci6n
Durante afios han existido muchas opiniones diferen-
tes (p. ej.: [BER93], [TAY90], [STR88], [BOO86]) Comprar Objetos: silla
sobre las respuestas correctas a estas preguntas. En 10s Vender
Pesar Dimensiones
parrafos siguientes trataremos de sintetizar las mas Mover
comunes de Cstas.
FIGURA 20.3. Herencia operaciones de clase a objeto.

Para entender la visibn orientada a objetos, conside-
remos un ejemplo de un objeto del mundo real -la cosa Hemos intentado definir una clase describiendo sus atri-
sobre la que usted esti sentado ahora m i s m e , una silla. butos, per0 algo falta. Todo objeto en la clase mobiliario
Silla es un miembro (el tCrmino instancia tambiCn se puede manipularse de varias maneras. Puede comprarse
usa) de una clase mucho mas grande de objetos que lla- y venderse, modificarse fisicamente (por ejemplo, usted
maremos Mobiliario. Un conjunto de atributos genCri- puede eliminar una pata o pintar el objeto de pdrpura) o
cos puede asociarse con cada objeto, en la clase moverse de un lugar a otro. Cada una de estas operacio-
Mobiliario. Por ejemplo, todo mueble tiene un costo, nes (otros tkrminos son servicios o me'todos) modificara
dimensiones, peso, localizaci6n y color, entre otros uno o mas atributos del objeto. Por ejemplo, si el atributo
muchos posibles atributos. ~ s t o son
s aplicables a cual- localizacion es un dato compuesto definido corno:
quier elemento sobre el que se hable, una'mesa o silla,
localizaci6n = edificio + piso + habitaci6n
un sofa o un armario. Como Silla es un miembro de la
clase Mobiliario, hereda todos 10s atributos definidos entonces una operaci6n denominada mover modificaria
para dicha clase. Este concept0 se ilustra en la Figura uno o mas de 10s elementos dato (edificio, piso o habi-
20.2 utilizando una notaci6n conocida como UML. En tacion) que conforman el atributo localizacion. Para
dicha figura, la caja con una esquina doblada represen- hacer esto, mover debe tener <<conocimiento>> sobre estos
ta un comentario en un lenguaje de programacion. elementos. La operaci6n mover puede usarse para una
Una vez definida la clase, 10s atributos pueden reu- silla o una mesa, debido a que ambas son instancias de
tilizarse a1 crear nuevas instancias de la clase. Por ejem- la clase Mobiliario. Todas las operaciones validas (por
plo, supongamos que debemos definir un nuevo objeto ejemplo, comprar, vender, pesar) de la clase Mobilia-
llamado Sillesa (un cruce entre una silla y una mesa) a la definition del objeto como
rio e s t h <<conectadas>>
que es un miembro de la clase Mobiliario. La Sillesa se muestra en la Figura 20.3 y son heredadas por todas
hereda todos 10s atributos de Mobiliario. las instancias de esta clase.
Las abstracciones de datos (atributos) que descri-

Se puede utilizer la notacidn de modelado de datos ben la clase esthn encerradas por una <<muralla>> de
del Copitulo 12. abstracciones procedimentales (Ilamadas operacio-
nes, mCtodos o servicios) capaces de manipular 10s
datos de alguna manera. La unica forma de alcanzar
10s atributos (y operar sobre ellos) e s ir a travCs de
El objeto silla (y todos 10s objetos en general) alguno de 10s mCtodos que forman la muralla. Por lo
encapsula datos (10s valores de 10s atributos que defi- tanto, la clase encapsula datos (dentro de la muralla)
nen la silla), operaciones (las acciones que se aplican y el proceso que manipula 10s datos (10s mCtodos que
para cambiar 10s atributos de la silla), otros objetos componen la muralla). Esto posibilita la ocultaci6n
(pueden definirse objetos compuestos [EVB89]), cons- de informaci6n y reduce el irnpacto de efectos cola-
tantes (para fijar valores) y otra informaci6n relacio- terales asociados a cambios. Como estos mCtodos
nada. El encapsulamiento significa que toda esta tienden a manipular un nlimero limitado de atributos,
informaci6n se encuentra empaquetada bajo un nom- esto es una alta cohesibn, y como la comunicaci6n
bre y puede reutilizarse como una especificacion o ocurre s61o a travCs de 10s mCtodos que encierra la
componente de programa. <<muralla>>, la clase tiende a un desacoplamiento con
otros elementos del sistema. Todas estas caracteris-
ticas del diseiio (Capitulo 13) conducen a software
de aha calidad.
Lo encopsuloci6nevita que un program sea tan

interdependienteque el m6s minimo combio
provoque efectos devastadores. Nornbre de clase
Jim RumbmgL et of.
Atributos:
Ahora que hemos introducido algunos conceptos

bkicos, resultar6 m i s significativa una definici6n m i s Operaciones:
formal de la ccorientaci6n a objetow. Coad y Yourdon
[COA9 11 definen el tCrmino de la siguiente forma:
orientaci6n a objetos =
+ herencia + comunicaci6n
= objetos + clasificaci6n
FIGURA 20.4. Representacion alternativa de una clase
Ya hemos intsoducido tres de estos conceptos. Pos- orientada a objetos.
pondremos el tratamiento sobre la comunicaci6n para
mris adelante. Puesto de otra manera, una clase es una descvipci6n
generalizada (por ejemplo, una plantilla, un patr6n o
20.2.1. Clases y objetos un prototipo) que describe una colecci6n de objetos
Los conceptos fundamentales que llevan a un diseiio de similares. Por definicibn, todos 10s objetos que existen
alta calidad (Capitulo 13) son igualmente aplicables a dentro de una clase heredan sus atributos y las opera-
sistemas desarrollados usando mCtodos convencionales ciones disponibles para la manipulacidn de 10s atribu-
y orientados a objetos. Por esta raz6n, un modelo 00 tos. Una su~~erclase es una colecci6n de clases y una
de software de computadora debe exhibir abstracciones subclase es una instancia de una clase.
de datos y procedimientos que conducen a una modu-
laridad eficaz. Una clase es un concept0 00 que encap-
sula las abstracciones de datos y procedimientos que se
requieren para describir el contenido y comportamien-
to de alguna entidad del mundo real. Taylor [TAY90] Uno de las pnmeros cosos a tener en cuenta o lo horo
usa la notacitin que se muestra a la derecha de la Figu- de conshir un sistemo 00 es camo chrsificor 10s objetos
ra 20.4 para describir una clase (y objetos derivados de o monipulor en dicho sistemo.
una clase).
Estas definiciones implican la existencia de una jerar-
quia de clases en la cual 10s atributos y operaciones de
la superclase son heredados por subclases que pueden
Un objeto encapsulo datos (atributos) y 10s metodos afiadir, cada una de ellas, atributos ccprivados>>y mCto-
(operaciones, metados o servicios) que manipulan dos. Una jerarquia de clases para la clase Mobiliario se
esos datos. ilustra en la Figura 20.5.
CAP~TULO
20 C O N C E P T O S Y PRINCIPIOS O R I E N T A D O S A OBIETOS
20.2.2. Atributos destacado antes, tiene el valor por defecto 16 valvulas

Ya hemos visto que 10s atributos estiin asociados a cla- opcion deportiva. Esto puede ser tambiCn 6til para
ses y objetos, y que describen la clase o el objeto de asociar una probabilidad con una caracteristica parti-
alguna manera. Un estudio de 10s atributos es presen- cular a travCs de pares (valor, probabilidad 1. Conside-
tado por de Champeaux y sus colegas [CHA93]: re el atributo color para Coche. En algunas aplicaciones
(por ejemplo, planificaci6n de la produccion) puede ser
Las entidades de la vida real estin a menudo descritas con
palabras que indican caracteristicasestables. La mayoria de 10s necesario asignar una probabilidad a cada uno de 10s
objetos fisicos tienen caracteristicas tales como forma, peso, colores (blanco y negro son mlis probables como colo-
color y tipo de material. Las personas tienen caracteristicas res de coches).
como fecha de nacimiento, padres, nombre y color de 10s ojos.
Una caracteristica puede verse conio una relaci6n binaria entre
una clase y cierto dominio. 20.2.3. Operaciones, mktodos y servicios
Un objeto encapsula datos (representados como una
Mobiliario (superclase) colecci6n de atributos) y 10s algoritmos que procesan
estos datos. Estos algoritmos son Ilamados operaciones,
mCtodos o servicios' y pueden ser vistos como m6du-
10s en un sentido convencional.
Mesa / Silla / \ ~scritorih(&illesaa %

CLAVE
Siernpre que un objeto es estimulado por un mensaje,
inicia algun comportamiento ejecutando una operation.
\
lnstancias d e silla
Subclases de la
superclase mobiliario
Cada una de las operaciones encapsuladas por un
objeto proporciona una representaci6n de uno de 10s
comportamientos del objeto. Por ejemplo, la opera-
FIGURA 20.5. Una jerarquia de clases. ci6n Dere~.rninu~Color para el objeto Coche extraerii
el color almacenado en el atributo color. La conse-
La ccrelaci6nn binaria anteriormente setialada impli- cuencia de la existencia de esta operaci6n e s que la
ca que un atributo puede tomar un valor definido por un clase Coche ha sido diseiiada para recibir un estimu-
dominio enumerado. En la mayoria de 10s casos, un lo [JAC92] (Ilamaremos a1 estimulo nzensuje) que
dominio es simplemente un conjunto de valores espe- requiere el color de una instancia particular de una cla-
cificos. Por ejemplo, suponga que una clase Coche tie- se. Cada vez que un objeto recibe un estimulo, kste ini-
ne un atributo color. El dominio de valores de color es cia un cierto comportamiento, que puede ser tan simple
(blanco, negro, plata, gris, azul, rojo, amarillo, ver- como determinar el color del coche o tan complejo
de). En situaciones miis complejas, el dominio puede como la iniciaci6n de una cadena de estimulos que se
ser un conjunto de clases. Continuando el ejemplo, la pasan entre una variedad de objetos diferentes. En este
clase Coche tambikn tiene un atributo motor que abar- ultimo caso, considere un ejemplo en el cual el esti-
ca 10s siguientes valores de dominio: { 16 valvulas mulo inicial recibido por el objeto n." da lugar a una
opci6n economica, 16 valvulas opcion deportiva, 24 generacion de otros dos estimulos que se envian a1
vhlvulas opcion deportiva, 32 valvulas opcion de objeto n." 2 y a1 objeto n.", Las operaciones encap-
lujo}. Cada una de las opciones indicadas tiene un con- suladas por el segundo y tercer objetos actljan sobre
junto de atributos especificos. el eslimulo devolviendo informaci6n necesaria para el
primer objeto. El objeto n." 1 usa entonces la infor-
maci6n devuelta para satisfacer el comportamiento
CLAVE demandado por el estimulo inicial.
10s valores asignados a 10s atributos de un obieto hacen
a ese objeto ser h i t o . 20.2.4. Mensajes
Los mensajes son el medio a travQ del cual interacttian
10s objetos. Usando la terminologia presentada en la sec-
Las caracteristicas (valores del dominio) pueden ci6n precedente, un mensaje estimula la ocurrencia de
aumentarse asignando un valor por defecto (caracte- cierto comportamiento en el objeto receptor. El compor-
ristica) a un atributo. Por ejemplo, el atributo motor tamiento se realiza cuando se ejecuta una operaci6n.
I Usaremos aqui el termino operaciones, pero mktodos y servicios
son igualmente populares.
lNGEN1EFtfA DEL SOFTWARE. UN ENFOQUE PRACTICO
En la Figura 20.6. se ilustra esquemiticamente la El paso de mensajes mantiene comunicado un sistema

.interacci6n entre objetos. Una operaci6n dentro de un orientado a objetos. Los mensajes proporcionan una
objeto emisor genera un mensaje de la forma: visi6n interna del comportarniento de objetos indivi-
destino.operaci6n (parhmetros) duales, y del sistema 00 como un todo.
donde destino define el objeto receptor el cual es esti-
mulado por el mensaje, operacibn se refiere a1 mCtodo
que recibe el mensaje y parcimetros proporciona infor-
maci6n requerida para el Cxito de la operacion.
(parametros)
valor
de retorno
Receptor.operacion
(parametros) Objeto
Valor
receptor de retorno
FIGURA 20.7. Paso de mensajes entre objetos.

FIGURA 20.6. Paso de mensaje entre objetos.
20.2.5. Encapsulamiento, herencia y polimorfismo
Como un ejemplo de paso de mensajes dentro de un
Aunque la estructura y terminologia introducida enwe las
sistema 0 0 , considere 10s objetos que se muestran en
Secciones 20.2.1 y 20.2.4 diferencian 10s sistemas 00 a
la Figura 20.7. Los cuawo objetos. A, B, C y D se comu-
partir de sus componentes convencionales,hay tres carac-
nican unos con otros a travCs del paso de mensajes. Por
tensticas de 10s sistemas orientados a objetos que 10s hacen
ejemplo, si el objeto B requiere el proceso asociado con
unicos. Como ya hemos observado, las clases y 10s obje-
la operacion oplO del objeto D, el primero enviaria a D
tos derivados de ella encapsulan 10s datos y las operacio-
un mensaje de la forma:
nes que trabajan sobre estos en un unico paquete. Esto
D.oplO(datos) proporciona un numero importante de beneficios:
Los detalles de implementaci6n interna de datos y

procedimientos est& ocultos al mundo exterior (ocul-
taci6n de la informaci6n). Esto reduce la propaga-
ci6n de efectos colaterales cuando ocurren cambios.
Como pate de la ejecucion de oplO, el objeto D pue- Las estructuras de datos y las operaciones que las
de enviar un mensaje a1 objeto C de la forma: manipulan estin mezcladas en una entidad sencilla:
la clase. Esto facilita la reutilizaci6n de componentes.
Las interfaces enwe objetos encapsulados estin sim-
C encuentra op8, la ejecuta, y entonces envia un valor plificadas. Un objeto que envia un mensaje no tiene
de retorno apropiado a D. La operacion oplO completa que preocuparse de 10s detalles de las estructuras de
su ejecuci6n y envia un valor de retorno a B. datos internas en el objeto receptor, lo que simpli-
Cox [COX861 describe el intercambio entre objetos fica la interaction y hace que el acoplamiento del sis-
de la siguiente manera: tema tienda a reducirse.
Se solicita de un objeto que ejecute una de sus operacio- La herencia es una de las diferencias clave entre sis-
nes envihdole un mensaje que le informa acerca de lo que
debe hacer. El [objeto] receptor responde a1 mensaje eli-
temas convencionales y sistemas 00. Una subclase Y
giendo primero la operaci6n que implementa el nombre del hereda todos 10s atributos y operaciones asociadas con
mensaje, ejecutando dicha operaci6n y desputs devolvien- su superclase X. Esto significa que todas las estructu-
do el control a1 objeto que origina la llamada. ras de datos y algoritmos originalmente diseiiados e
CAPiTULO ZO CONCEPTOS Y PRINCIPIOS ORIENTADOS A OBIETOS
implementados para X e s t h inmediatamente disponi- nueva clase. Como sefiala Jacobson, cuando se emplea la
bles para Y (no es necesario mas trabajo extra). La reu- anulacidn, <<laherencia no es transitiva,, [JAC92].
tilizacidn se realiza directamente. En algunos casos, es tentador heredar algunos atributos
Cualquier cambio en 10s datos u operaciones conte- y operaciones de una clase y otros de o m clase. Esta acci6n
nidas dentro de una superclase es heredado inmediata- se llama herencia mliltiple y es controvertida. En general,
mente por todas las subclases que se derivan de la la herencia multiple complica la jerarquia de clases y crea
superclase2.Debido a esto, la jerarquia de clases se con- problemas potenciales en el control de la configuration
vierte en un mecanismo a travCs del cual 10s cambios (Capitulo 9). Como las secuencias de herencia matiple son
(a altos niveles) pueden propagarse inmediatamente a m b dificiles de seguir, 10s cambios en la definici6n de una
travCs de todo el sistema. clase que reside en la parte superior de la jerarquia pueden
Es importante destacar que en cada nivel de la jerar- tener impactos no deseados originalrnente en las clases defi-
quia de clases, pueden aiiadirse nuevos atributos y ope- nidas en zonas inferiores de la arquitectura.
raciones a aquellos que han sido heredados de niveles
superiores de la jerarquia. De hecho, cada vez que se
debe crear una nueva clase, el ingeniero del software
tiene varias opciones:
La clase puede diseiiarse y construirse de la nada.
Esto es, no se usa la herencia.
La jerarquia de clases puede ser rastreada para deter-
minx si una clase ascendiente contiene la mayoria
de 10s atributos y operaciones requeridas. La nueva
clase hereda de su clase ascendiente, y pueden aiia-
dirse otros elementos si hacen falta.
La jerarquia de clases puede reestructurarse de tal
manera que 10s atributos y operaciones requeridos
puedan ser heredados por la nueva clase.
Las caracteristicas de una clase existente pueden
sobrescribirse y se pueden implementar versiones pri-
vadas de atributos u operaciones para la nueva clase.
FIGURA 20.8a. Jerarquia de clases original.
Para ilustrar cdmo la reestructuraci6n de la jerarquia

de clases puede conducir a la clase deseada, considere el
ejemplo mostrado en la Figura 20.8. La jerarquia de cla-
ses ilustradas en la Figura 20.8a nos permite derivar las
clases X3 y X4 con las caracteristicas 1 , 2 , 3 , 4 , 5 y 6, y
1,2, 3,4, 5 y 7, respectivamente3.Ahora, suponga que
se desea crear una nueva clase solamente con las carac- El poiimorfrsmo es una caracteristica que reduce en
teristicas 1,2, 3 , 4 y 8. Para derivar esta clase, llamada gran medida el esfuerzo necesario para extender un sis-
X2b en el ejemplo, la jerarquia debe reestructurarsecomo tema 00. Para entender el polimorfismo, considere una
se muestra en la Figura 20.8b. Es importante darse cuen- aplicaci6n convencional que debe dibujar cuatro tipos
ta de que la reestructuracidn de la jerarquia puede ser difi- diferentes de grrificos: grhficos de lineas, grificos de tar-
cil y, por esta raz6n, se usa a veces la anulacidn. ta, histogramas y diagramas de Kiviat. Idealmente, una
En esencia, la anulaci6n o c m cuando 10s atributos y vez que se han recogido 10s datos necesarios para un tipo
operaciones se heredan de manera normal, per0 despues particular de grifico, el grhfico debe dibujarse 61 mismo.
son modificados segdn las necesidades especificas de la Para realizar esto en una aplicacidn convencional (y man-
A veces se emplean 10sterminos descendiente y antecesor UAC92] En este ejemplo llamaremos caracteristica tanto a 10s atributos como
en lugar de subclase y superclase. a las operaciones.
tener la cohesidn entre m6dulos), seria necesario desa- dibujar. Pero no se requieren cambios dentro de un obje-
,rrollar m6dulos de dibujo para cada t i p de grhfico. Seg6n to que quiere dibujar un grhfico pues el mensaje
esto, dentro del disefio para cada tip0 de grifico, se debe- tipo-grafico dibujar no cambia. En resumen, el poli-
rh aiiadir una 16gica de control semejante a la siguiente: morfismo permite que un n6mero de operaciones dife-
case of tipo-grafico: rentes tengan el mismo nombre. Esto reduce el
if tipo-grafico = grafico-linea then acoplamiento entre objetos, haciendo a cada uno mhs
Dibu jarLinea (datos); independiente.
if tipo-grafico = grafico-tarta then
DibujarTarta(dat0s);
if tipo-grafico = grafico-histograma
then DibujarHisto(dat0s);
if tipo-grafico = grafico-kiviat then
DibujarKiviat (datos);
end case;
Aunque este disefio es razonablemente evidente, aiia-
dir nuevos tipos de grhficos puede ser complicado, pues
hay que crear un nuevo m6dulo de dibujo para cada tipo
de grhfico y actualizar la 16gica de control para cada
grhfico.
Para resolver este problema, cada uno de 10s grhfi-
cos mencionados anteriormente se convierte en una sub-
clase de una clase general llamada Grafico. Usando un
concept0 llamado sobrecarga [TAY90], cada subclase
define una operaci6n llamada dibujar. Un objeto pue-
de enviar un mensaje dibujar a cualquiera de 10s obje-
tos instanciados de cualquiera de las subclases. El objeto
que recibe el mensaje invocarh su propia operaci6n dibu-
jar para crear el grhfico apropiado. Por esto, el disefio
mostrado anteriormente se reduce a:
tipo-grafico dibujar
Cuando hay que aiiadir un nuevo tipo de grhfico a1
sistema, se crea una subclase con su propia operaci6n FIGURA 20.8b. Jerarquia de clases reestructurada.
Los elementos de un modelo de objetos -<lases y obje-

tos, atributos, operaciones y mensajes- heron definidos
y examinados en la secci6n precedente. Pero, jc6m0 pode-
mos hacer para identificar estos elementos en un proble-
ma real? Las secciones que siguen presentan una serie de
directrices informales que nos ayudarhn en la identifica-
ci6n de 10s elementos de un modelo de objetos.
Podemos empezar a identificar objetos4examinando
20.3.1. Identificacibn de clases y objetos el planteamiento del problema o (usando la terminolo-
Si usted observa a su alrededor en una habitaci611, exis- gia del Capitulo 12) realizando un ccanhlisis sintictico
ten un conjunto de objetos fisicos que pueden ser ficil- gramaticah en la narrativa del sistema que se va a cons-
mente identificados, clasificados y definidos (en tkrminos truir. Los objetos se determinan subrayando cada nom-
de atributos y operaciones). Pero cuando usted ccobserva>> bre o cliusula nominal e introducikndola en una tabla
el espacio de un problema en una aplicaci6n de software, simple. Los sindnimos deben destacarse. Si se requie-
10s objetos pueden ser mis dificiles de identificar. re del objeto que implemente una solution, entonces
I. En realidad, el Analisis 00 intenta identificar las clases a partir de

las cuales se instancian 10s objetos. Por tanto, cuando aislamos obje-
tos potenciales, tambien identificamos miembros de clases poten-
ciales.
350
C A P ~ T U L O20 CONCEPTOS Y PRiNCIPlOS ORlENTADOS A OBJETOS
Cste formara parte del espacio de soluci6n; en caso de La clasificaci6n mostrada anteriormente es una de
. que el objeto se necesite solamente para describir una las muchas que se han propuesto en la literatura.
soluci6n, Cste forma parte del espacio del problema. TambiCn es importante destacar quC no son 10s obje-
Pero, iquC debemos buscar una vez que se han aislado tos. En general, un objeto nunca debe tener un mom-
todos 10s nombres? bre procedimental imperativon [CAS89]. Por ejemplo,
si 10s desarrolladores de un software para un sistema
grafico mCdico definieron un objeto con el nombre
~ C i m oidentificar objetos inversion de imagen, estm'an cometiendo un sutil error.
cuando estudio cimo La imagen obtenida por el software pudiera ser, en efec-
resolver un problema? to, un objeto (es un elemento que forma parte del domi-
nio de informaci6n), per0 la inversi6n de la imagen es
Los objetos se manifiestan de alguna de las formas una operacidn que se aplica a dicho objeto. Inversidn
mostradas en la Figura 20.9. y pueden ser: debe definirse como una operaci6n del objeto imagen,
entidadcs externas (por ejemplo: otros sistemas, dis- per0 no como objeto separado que signifique <<inver-
positivos, personas) que producen o consumen infor- sion de imagenn. Como establece Cashman [CAS89],
macidn a usar por un sistemas computacional; <<...elobjetivo de la orientaci6n a objetos es encapsular,
cosas (por ejemplo: informes, presentaciones, car- per0 manteniendo separados 10s datos y las operacio-
tas, seiiales) que son parte del dominio de informa- nes sobre estos datow.
cion del problema; Para ilustrar c6mo pueden definirse 10s objetos duran-
te las primeras etapas del analisis, volvamos a1 ejemplo
ocurrencias o sucesos5 (por ejemplo: una transfe-
del sistema de seguridad HogarSeguro. En el Capitulo
rencia de propiedad o la terminaci6n de una serie de 12, realizamos un <<anAlisissintactico gramaticaln sobre
movimientos en un robot) que ocurren dentro del la narrativa de procesamiento para el sistema Hogar-
contexto de una operacidn del sistema; Seguro. La narrativa de procesamiento se reproduce a
papeles o roles (por ejemplo: director, ingeniero, ven- continuaci6n:
dedor) desempeiiados por personas que interacttian El software HogarSeguro le permite a1 propietario de la
con el sistema; casa configurar el sistema de seguridad una vez que este se
unidades organizacionales (por ejemplo: divisi611, instala, controla todos 10s sensores conectados a1 sistema de
grupo, equipo) que son relevantes en una aplicacibn; seguridad, e interactlia con el propietario a traves de un tecla-
do numerico y teclas de funci6n contenidas en el panel de
lugares (por ejemplo: planta de producci6n o mue- control de HogarSeguro mostrado en la Figura 11.2
lle de carga) que establecen el contexto del problema Durante la instalacih, el panel de control de HogarSe-
y la funcion general del sistema; guro se usa para ccprogramar, y configurar el sistema. A cada
estructuras (por ejemplo: sensores, vehiculos de cua- sensor se le asigna un nlimero y tipo, se programa una con-
tro ruedas o computadoras) que definen una clase de trasefia maestra para activar y desactivar el sistema, y se intro-
objetos o, en casos extremos, clases relacionadas de ducen nlimeros de telefono a marcar cuando un sensor detecte
un suceso.
objetos.
Cuando se reconoce un suceso de sensor, el software invo-
ca una alarma audible asociada a1 sistema. DespuCs de un
tiempo de espera especificado por el propietario durante las
actividades de configuracidn del sistema, el software marca
un nlimero de telefono de un servicio de control, proporcio-
na informacidn acerca de la localizaci6n, e informa de la
naturaleza del suceso detectado. El nhmero sera remarcado
cada 20 segundos hasta obtener una conexi6n telefhica.
Toda la interaccidn con HogarSeguro esta gestionada por
un subsistema de interaccidn con el usuario que toma la entra-
da a partir del teclado numerico y teclas de funcibn, y mues-
tra mensajes y el estado del sistema en la pantalla LCD. La
interacci6n con el teclado toma la siguiente forma ...
Hay que utilizor un onolizador sintbctico grornoticol

poro detector obietos potencioles hombres) y
FIGURA 20.9. C o m o se m a n i f i e s t a n 10s objetos. operociones (verbas).
En este ~ontexto,el termino suceso denota cualquier ocurrencia.

No necesariamente implica control, en el sentido del Capitulo 12.
351
DEL SOFTWARE.U N ENFOQUE PRACTICO
INGENIER~A
Extrayendo 10s nombres podemos proponer varios Atributos comunes: puede definirse un conjunto de
.objetos potenciales: atributos para el objeto potencial, 10s cuales son apli-
cables a todas las ocurrencias del objeto.
Clase / Clasificaci6n Operaciones comunes: puede definirse un conjunto
Objeto potencial general de operaciones para el objeto potencial, las cuales
propietario rol o
son aplicables a todas las ocurrencias del objeto;
entidad externa Requisitos esenciales: entidades externas que apa-
sensor entidad externa recen en el espacio del problema y producen o con-
sumen informaci6n esencial para la producci6n de
panel de control entidad externa
cualquier solucion para el sistema, seran casi siem-
instalaci6n ocurrencia pre definidas como objetos en el modelo de requi-
sistema cosa sitos.
(alias sistema
de seguridad)
numero, tipo no son objetos.
sin0 atributos de
sensor
cont raseiia Un obieto potenciol debe sotisfocer lo rnoyorio de estos
maestra cosa corocteristicos poro utilizorlo en el rnodelo de onolisis.
nfimero
de teldfono cosa
Para ser considerado un objeto valido a incluir en
suceso de sensor
ocurrencia
modelo de requisitos, un objeto potencial debe satis-
alarma audible facer todas (o casi todas) las caracteristicas anterio-
entidad externa res. La decision de incluir objetos potenciales en el
servicio
de control unidad organizacio- modelo de analisis es algo subjetivo, y una evalua-
nal o entidad ci6n posterior puede llegar a descartar un objeto o
reincluirlo. Sin embargo, el primer paso del A 0 0 debe
La lista anterior se continuara hasta que se hayan ser la definici6n de objetos, y la consiguiente toma de
considerado todos 10s nombres de la descripci6n del decisiones (incluso subjetivas). Teniendo esto en cuen-
proceso. Observe que hemos llamado a cada entrada en ta, aplicamos las caracteristicas selectivas a la lista de
la lista un objeto potencial. Debemos considerar cada objetos potenciales de HogarSeguro (vCase tabla a
uno de ellos antes de tomar una decision final.
Como saber si un objeto Clase / Caracteristicas

potencial es un buen Objeto potencial
candidato para utilizarlo
en un sistema 00. propietario Rechazado
(1, 2 fallan aunque
6 es aplicable)
Coad y Yourdon [COA91] sugieren seis caractens-
sensor Aceptado (se aplican
ticas de selecci6n a usar cada vez que un analista con- todas )
sidera si incluye o no un objeto potencial en el modelo
de anhlisis: panel de control Aceptado (se aplican
todas )
Informacibn retenida: el objeto potencial sera de
utilidad durante el anhlisis solamente si la infor- instalaci6n Rechazado
maci6n acerca de 61 debe recordarse para que el sis- sistema (alias sis- Aceptado (se aplican
tema funcione. tema de seguridad) todas )
Servicios necesarios: el objeto potencial debe nQmero, tip0 Rechazado (falla 3)
poseer un conjunto de operaciones identificables contrasefia maestra Rechazado (falla 3)
que pueden cambiar de alguna manera el valor de
sus atributos. n6mero de tel6fono Rechazado (falla 3)
Atributos mLltiples: durante el analisis de requisitos, suceso de sensor Aceptado (se aplican
se debe centrar la atenci6n en la informaci6n princi- todas)
pal (un objeto con un solo atributo puede, en efecto, alarma audible Aceptado (se aplican
ser 6til durante el diseiio, per0 seguramente sera 2, 3 , 4, 5 Y 6 )
mejor presentado como un atributo de otro objeto servicio de control Rechazado (fallan 1 y
durante la actividad de anhlisis); 2 aunaue 6 se awlica)
CAPfTULO 20 CONCEPTOS Y PRINCIPIOS ORIENTADOS A OBJETOS
Debe tenerse en cuenta que: (1) la lista anterior no informacih del sensor = tipo de sensor
incluye todo, hay que aiiadir objetos adicionales para com- + nfimero de sensor + umbra1 de alarma
pletar el modelo; (2) algunos de 10s objetos potenciales informacih de respuesta de la alarma =
rechazados s e r h atributos de 10s objetos aceptados (por tiempo de retardo + nfimero de tel6fono
ejemplo, ndmero y tip0 son atributos de sensor, y con- + tipo de alarma
trasefia maestra y ndmero de telCfono pueden convertir- informaci6n de activaci6n/desactivaci6n
se en atributos de sistema); y (3) diferentes descripciones = contraseiia maestra + cantidad de
del problema pueden provocar la toma de diferentes deci- intentos permitidos + contrasefia tempo-
ral
siones de <<aceptaci6no rechazo>>(por ejemplo, si cada
propietario tiene su propia contrasefia o fue identificado informaci6n de identificaci6n = ID del
sistema + verificaci6n de nfimero de tel6-
por impresiones de voz, el objeto Propietario cumplin'a fono + estado del sistema
las caracteristicas 1 y 2 y habria sido aceptado).
Cada uno de 10s elementos de datos a la derecha del
20.3.2. Especificaci6n d e atributos signo de igualdad puede volver a definirse en un nivel
elemental, per0 para nuestros prop6sitos, comprenden
Los atributos describen un objeto que ha sido seleccio- una lista razonable de atributos para el objeto sistema
nado para ser incluido en el modelo de anilisis. En esen- (porcibn sombreada de la Fig. 20.10).
cia, son 10s atributos 10s que definen a1 objeto, 10s que
clarifican lo que se representa el objeto en el contexto del
20.3.3. Definici6n d e operaciones
espacio del problema. Por ejemplo, si tratArarnos de cons-
truir un sistema de estadisticas para jugadores profesio- Las operaciones definen el comportarniento de un obje-
nales de bCisbol, 10s atributos del objeto Jugador serian to y cambian, de alguna manera, 10s atributos de dicho
muy diferentes de 10s atributos del mismo objeto cuando objeto. Mis concretamente, una operacidn cambia valo-
se use dentro del contexto de un sistema de pensiones para res de uno o mis atributos contenidos en el objeto. Por
jugadores profesionales. En el primero, atributos tales lo tanto, una operacidn debe tener ccconocimiento>> de
como nombre, posicibn, promedio de bateo, porcentaje la naturaleza de 10s atributos de 10s objetos y deben ser
de estancia en el campo de juego, aiios jugados y parti- implementadas de manera tal que le permita manipular
dos jugados pueden ser relevantes. En el segundo caso, las estructuras de datos derivadas de dichos atributos.
algunos de estos atributos serian relevantes pero otros seri- Aunque existen muchos tipos diferentes de opera-
an reemplazados (o potenciados) por atributos como sala- ciones, Cstas pueden clasificarse en tres grandes cate-
no medio, crCdito total, opciones elegidas para el plan de gorias: (1) operaciones que manipulan, de alguna
pensibn, direccidn postal, etc. manera, datos (p.e.: afiadiendo, eliminando, reforma-
Para desarrollar un conjunto significativo de atributos teando, seleccionando); (2) operaciones que realizan
para un objeto, el analista puede estudiar de nuevo la narra- alglin cilculo; y (3) operaciones que monitorizan un
tiva del proceso (o descripcidn del h b i t o del alcance) objeto frente a la ocurrencia de un suceso de control.
para el problema y seleccionar aquellos elementos que
razonablemente ccpertenecen,, a1 objeto. Ademis, para ~Existealguna forma
cada objeto debe responderse el siguiente interrogante: razonable de tategorizar
<<iQuC elementos (compuestos y/o simples) definen com- las operationes de un objeto?
pletamente a1 objeto en el contexto del problema actual?*
En una primera iteracidn para obtener un conjunto de
g operaciones para 10s objetos del modelo de andisis, el
analista puede estudiar de nuevo la narrativa del proce-
CLAVE so (o descripci6n del imbito) del problema y seleccio-
10s otributos se escogen exominondo el problemo, nar aquellas operaciones que razonablemente pertenecen
buscondo cosos que definon completomente 10s obietos a1 objeto. Para realizar esto, se estudia de nuevo el ani-
y que 10s hocen hicos. lisis gramatical y se aislan 10s verbos. Algunos de estos
verbos serin operaciones legitimas y pueden conectar-
Para ilustrar esto, consideremos el objeto Sistema se ficilmente a un objeto especifico. Por ejemplo, de la
definido para HogarSeguro. Anteriormente ya indica- narrativa de proceso de HogarSeguro, presentada ante-
mos que el propietario puede configurar el sistema de riormente en este capitulo, vemos que ccal sensor se le
seguridad para reflejar la informacidn acerca de 10s sen- asigna un ndmero y un tipo>>o que <<seprograma una
sores, sobre la respuesta de la alarma, sobre la activa- contraseha maestra para activar y desactivar el sistema,,.
ci6n/desactivaci6n, sobre identificacibn, etc. Usando la Estas dos frases indican varias cosas:
notaci6n de la descripci6n del contenido definida para que una operaci6n de asignaci6n es relevante para
el diccionario de datos y presentada en el Capitulo 12, el objeto Sensor;
podriamos representar estos elementos de datos com- que una operaci6n de programar se le aplicari a1
puestos de la siguiente manera: objeto Sistema;
que activar y desacrivar son operaciones aplicables 20.3.4. Fin de la definicion del objeto
a1 Sistema (o sea que el estado del sistema puede La definicion de operaciones es el ultimo paso para
en ultima instancia definirse usando notacion del dic- completar la especificacion del objeto. En la Seccion
cionario de datos) como 20.3.3. las operaciones se eligieron a partir de un exa-
estado del sistema = [activado I desacti- men gramatical de la narrativa de proceso del sistema.
vado I Las operaciones adicionales pueden determinarse con-
Tras una investigaci6n mas detallada, es probable siderando la <<historiade la vida>>[COA91] de un obje-
que haya que dividir la operacion programar en varias to y 10s mensajes que se pasan entre objetos definidos
suboperaciones mas especificas requeridas para con- por el sistema.
figurar el sistema. Por ejemplo, programar implica La historia de la vida genCrica de un objeto puede
especificar numeros de telCfonos, configurar carac- definirse reconociendo que dicho objeto debe ser crea-
teristicas del sistema (por ejemplo, crear la tabla de do, modificado, manipulado o leido de manera diferen-
sensores, introducir las caracteristicas de las alar- te, y posiblemente borrado. Para el objeto Sistema, esto
mas), e introducir la(s) contrasefia(s), per0 por aho- puede expandirse para reflejar actividades conocidas que
ra, especificaremos programar como una operacion ocurren durante su vida (en este caso, durante el tiempo
que HogarSeguro se mantiene operativo). Algunas de
las operaciones pueden determinarse a partir de comu-
nicaciones semejantes entre objetos. Por ejemplo, el
Sistema Suceso sensor enviara un mensaje a Sistema para mos-
trar en pantalla la localizacion y numero del suceso; el
ID del sistema Panel de control enviari un mensaje de reinicializacibn
N h e r o de tel6fono de verificacih para actualizar el estado del Sistema (un atributo); la
Estado del sistema
Tabla de sensores
Alarma audible enviara un mensaje de consults, el
Tipo de sensor Panel de control enviara un mensaje de rnodificacibn
Niunero de sensor para cambiar uno o mis atributos sin reconfigurar el obje-
Umbra1 de alarma to sistema por completo; el Suceso sensor enviara un
Contrasefia maestra
Contrasefia temporal
mensaje para llamar a1 numero(s) de telCfono(s) conte-
N h e r o de intentos nido(s) en el objeto. Podran considerarse otros mensa-
jes para derivar operaciones correspondientes. La
definicion del objeto resultante se muestra en la Figura
Programar ( ) 20.10.
Mostrar ( )
Reiniciar ( )
Se usaria un enfoque similar para cada uno de 10s
Consultar ( ) objetos definidos para HogarSeguro. Despds de haber
Modificar ( ) definido 10s atributos y operaciones para todos 10s obje-
Llamar ( ) tos especificados hasta este punto, se crearian 10s ini-
cios del modelo AOO. En el Capitulo 21 se presenta un
FIGURA 20.10. El objeto sistema con operaciones estudio mhs detallado del modelo de analisis creado
asociadas. como parte del AOO.
Como examinamos en la Parte Primera y Segunda de 6. Seguimiento, monitorizaci6n y control del progreso.
este libro, la moderna gesti6n de proyectos de softwa-
re puede subdividirse en las siguientes actividades:
1. Establecimiento de un marco de proceso comlin
para el proyecto. Los proyectos 00 requieren mucho mbs gestibn
de lo plonificocibn y seguimiento que 10s proyertos
2. Uso del marco y de mCtricas historicas para desa- de softwore convencionol. No supongo que lo 00
rrollar estimaciones de esfuerzo y tiempo. le relevo de esto octividod.
3. Especificaci6n de productos de trabajo e hitos que
permitiran medir el progreso. El director tCcnico que se enfrenta con un proyecto
de software orientado a objetos aplica estas seis activi-
4. Definici6n de puntos de comprobaci6n para la gesti6n dades. Pero debido a la naturaleza unica del software
de riesgos, aseguramiento de la calidad y control. orientado a objetos, cada una de estas actividades de
5. Gesti6n de 10s cambios que ocurren invariable- gesti6n tiene un matiz levemente diferente y debe ser
mente a1 progresar el proyecto. enfocado usando un modelo propio.
CAPITULO 20 CONCEPTOS Y PRINClPlOS ORIENTADOS A OBJETOS
En las secciones que siguen, exploramos el area de Ensamblar un nuevo prototipo usando objetos de la
gesti6n de proyectos orientados a objetos. Los princi- biblioteca y 10s objetos que se crearon nuevos.
pios de gesti6n fundamentales seran 10s mismos, per0 Realizar pruebas para descubrir errores en el proto-
para que un proyecto 00 sea dirigido correctamente tipo.
hay que adaptar la tCcnica.
Obtener realimentacidn del cliente sobre el proto-
tipo.
Este enfoque continua hasta que el prototipo evolu-
Referencia web/ ' ciona hacia una aplicacion en produccion.
Enconhoro un tutoriol muy completo sobre gestibn
de proyectos 00 y un buen coniunto de enloces en: ~ C O aplicar
~ O un modelo
mini.net/cetus/oogroject-mngt.html. recursivo/paralelo en la
ingenieria del software OO?
20.4.1. El marco de proceso comun para 00

El modelo recursivo/paralelo es muy similar a1 mode-
Un marco de proceso comun (MPC) define un enfoque
lo de proceso 00 presentado anteriormente en este capi-
organizativo para el desarrollo y mantenimiento de soft-
tulo. El progreso se produce iterativamente. Lo que hace
ware. El MPC identifica el paradigma de ingenieria del
diferente a1 modelo recursivo/paralelo es el reconoci-
software aplicado para construir y mantener el softwa-
miento de que (1) el modelo de analisis y disefio para
re, asi como las tareas, hitos y entregas requeridos. Esta-
sistemas 00 no puede realizarse a un nivel uniforme
blece el grado de rigor con el cual se enfocaran 10s
de abstraccion, y (2) el analisis y disefio pueden apli-
diferentes tipos de proyectos. El MPC siempre es adap-
carse a componentes independientes del sistema de
table, de tal manera que siempre cumpla con las nece-
manera concurrente. Berard [BER93] describe el mode-
sidades individuales del equipo del proyecto. ~ s t es a su
lo de la siguiente manera:
caracten'stica mas importante.
Descomponer sistematicamenteel problema en com-
ponentes altamente independientes.
Aplicar de nuevo el proceso de descomposicion a
El marto de proceu, comh define Im octividodes cada una de las componentes independientes para, a
k c o s de ingenierb det software. Se descn'be su vez, descomponerlas (la parte recursiva).
en el Capltulo 2. Conducir este proceso de reaplicar la descomposi-
ci6n de forma concurrente sobre todos 10s compo-
nentes (la parte paralela).
Ed Berard [BER93] y Grady Booch [B0091], entre Continuar este proceso hasta cumplir 10s criterios de
otros, sugieren el uso de un ccmodelo recursivo/parale- finalization.
lo>>para el desarrollo de software orientado a objetos.
En esencia, el modelo recursivo/paralelo funciona de la Es importante observar que el proceso de descom-
siguiente manera: posici6n mostrado anteriormente es discontinuo si el
Realizar 10s analisis suficientes para aislar las clases analistaldisefiador reconoce que el componente o sub-
del problema y las conexiones mas importantes. componente requerido esti disponible en una bibliote-
ca de reutilizacion.
Realizar un pequefio disefio para determinar si las
Para controlar el marco de proceso recursivolpara-
clases y conexiones pueden ser implementadas de
lelo, el director del proyecto tiene que reconocer que el
manera practica.
progreso esta planificado y medido de manera incre-
Extraer objetos reutilizables de una biblioteca para mental. Esto es, las tareas y la planificacion del proyecto
construir un prototipo previo. estan unidas a cada una de las cccomponentes altamen-
Conducir algunas pruebas para descubrir errores en te independientew, y el progreso se mide para cada una
el prototipo. de estas componentes individualmente.
Obtener realimentacion del cliente sobre el proto-
tipo.
Modificar el modelo de analisis basandose en lo que
se ha aprendido del prototipo, de la realization del
disefio y de la realimentacion obtenida del cliente. En muchos ospectos, lo orquitecturo de un sistemo 00
Refinar el disefio para acomodar sus cambios. hoce que el comenzor o trobojor en porolelo seo
mhs fkil. Sin emborgo, tombiin es cierto que codo
Construir objetos especiales (no disponibles en la toreo porolelo se define de formo que puedo colculorse
biblioteca). el progreso.
(r4
ll
Planificacion Analisis Disefio
Revision y refinamiento
Primeras iteraciones
en analisis/disefio
1 (Analisis Disefio +[Anilisis 1 Dismo ]

1 Revision y refinamiento
1 Revision y refinamiento
I
1 Revision y iefinamiento
FIGURA 20.11. Secuencia tipica de u n proceso para un proyecto 00.
Cada iteracion del proceso recursivo/paralelo requie- que el objetivo principal es la reutilizaci6n. Las estima-
re planificacih, ingenieria (analisis, disefio, extraccion ciones a partir de PF pueden usarse de manera efectiva,
de clases, prototipado y pruebas) y actividades de eva- pues 10s elementos del dominio de informaci6n requeri-
luaci6n (Fig. 20.11). Durante la planificaci6n, las activi- dos se pueden determinar a partir del planteamiento del
dades asociadas con cada una de las componentes problema. El analisis de PF puede aportar valores para
independientes del programa son incluidas en la planifi- estimaciones en proyectos 0 0 , per0 la medida de PF no
cacion. [Nota: Con cada iteracion se ajusta la agenda para provee una granularidad suficiente para ajustes de plani-
acomodar 10s carnbios asociados con la iteracidn prece- ficacion y esfueno a realizar, 10s cuales se requieren cuan-
dente]. Durante las primeras etapas del proceso de inge- do iteramos a travCs del paradigma recursivo/paralelo.
nieria, el anhlisis y el disefio se realizan iterativamente. Lorenz y Kidd [LOR941 sugieren el siguiente con-
La intenci6n es identificar todos 10s elementos importan- junto de mCtricas para proyectos6:
tes del analisis 00 y de 10s modelos de disefio. A1 conti-
nuar el trabajo de ingenieria, se producen versiones Numero de guiones de escenario. Un guibn de
escenario (como 10s casos de uso discutidos en el
incrementales del software. Durante la evaluaci6n se rea-
lizan, para cada incremento, revisiones, evaluaciones del Capitulo I 1) es una secuencia detallada de pasos que
describen la interacci6n entre el usuario y la aplica-
cliente y pruebas, las cuales producen una realimentacion
ci6n. Cada gui6n se organiza en tripletes de la forma:
que afecta a la siguiente actividad de planificaci6n y a1
subsiguiente incremento. (iniciador, accibn, participante)
donde iniciador es el objeto que solicita algun ser-
20.4.2. Metricas y estimacion en proyectos vicio (que inicia un mensaje); accibn es el resultado
orientados a objetos de la solicitud; y participante es el objeto servidor
Las tkcnicas de estimaci6n en proyectos de software con- que cumple la peticion (solicitud). El numero de guio-
vencionales requieren estimaciones de lineas de codigo nes de actuaci6n esth directamente relacionada a1
(LDC) o puntos de funci6n (PF) como controlador prin- tamafio de la aplicacion y a1 nhnero de casos de prue-
cipal de estimacion. Las estimaciones realizadas a partir ba que se deben desarrollar para ejercitar el sistema
de LDC tienen poco sentido en proyectos 00 debido a una vez construido.
Las tecnicas de medida de sistemas 00 se discuten con detalle en

el capitulo 24.
C A P ~ T U L O20 CONCEPTOS Y PRINCIPIOS ORIENTADOS A OBJETOS
rrollar estimaciones razonables es esencial el desarro-

110 de multiples puntos de datos. Esto significa que las
Estas metricas pueden utilizane para complementar 10s estimaciones deben derivarse usando diferentes tecni-
metricas FF Praporciananuna farma de ((medir))un cas. Las estimaciones respecto a1 esfuerzo y la duracion
proyecto 00. usadas en el desarrollo de software convencional (Capi-
tulo 5) son aplicables a1 mundo de la 0 0 , per0 la base
Numero de clases clave. Las clases clave son las de datos historica para proyectos 00 es relativamen-
<<componentesaltamente independientew [LOR941 te pequeiia en muchas organizaciones. Debido a esto,
definidas inicialmente en el AOO. Debido a que estas vale la pena sustituir la estimacion de costes para soft-
clases son centrales a1 dominio del problema, el ware convencional por un enfoque diseiiado explicita-
numero de dichas clases es una indicacion del esfuer- mente para software 00. Lorenz y Kidd [LOR941
zo necesario para desarrollar el software y de la can- sugieren el siguiente enfoque:
tidad potencial de reutilizacion a aplicar durante el 1. Desarrollo de estimaciones usando la descompo-
desarrollo del sistema. sicion de esfuerzos, analisis de PF y cualquier otro
Numero de clases de soporte.Las clases de sopor- mCtodo aplicable a aplicaciones convencionales.
te son necesarias para implementar el sistema, per0 no 2. Desarrollar guiones de escenario y determinar una
estan directamente relacionadas con el dominio del cuenta, usando A 0 0 (Capitulo 21). Reconocer que
problema. Como ejemplos podemos tomar las clases el numero de guiones de escenarios puede cambiar
de Interfaz Grafica de Usuario, el acceso a bases de con el progreso del proyecto.
datos y su manipulation y las clases de comunicacion.
Ademas las clases de soporte se definen iterativamen-
te a lo largo del proceso recursivo/paralelo.
En el Capitulo 5 se consideran diierentes thicos
El numero de clases de soporte es un indicador
de estimcibn de poyectos softwore
del esfuerzo necesario requerido para desarrollar
el software y de la cantidad potencial de reutiliza-
ci6n a aplicar durante el desarrollo del sistema.
3. Determinar la cantidad de clases clave usando
AOO.
4. Clasificar el tip0 de interfaz para la aplicacion y
desarrollar un multiplicador para las clases de
soporte:
Numero promedio de clases de soporte por cla-
se clave. En general las clases clave son conocidas Tipo de Interfaz Multiplicador
en las primeras etapas del proyecto. Las clases de Interfaz no grdfica
soporte se definen a lo largo de Cste. Si, dado un (No IGU) 2,o
dominio de problema, se conociera la cantidad pro-
Interfaz de usuario
medio de clases de soporte por clase clave, la esti- basada en texto 2,25
maci6n (basada en la cantidad total de clases) se
simplificaria mucho. Interfaz Gr6fica de Usario
(IGU) 2,5
Lorenz y Kidd sugieren que las aplicaciones con
IGU poseen entre dos y tres veces m b clases de sopor- Interfaz Grdfica de Usuario
te que clases clave. Las aplicaciones sin IGU poseen (IGU) cornpleja 3,O
a lo sumo dos veces mis de soporte que clave.
Numero de subsistemas.Un subsistema es m a age- Multiplicar el numero de clases clave (paso 3) por
gacion de clases que dan soporte a una funcion visible el multiplicador anterior para obtener una estima-
a1 usuario final del sistema. Una vez que se identifican ci6n del ndmero de clases de soporte.
10s subsistemas,resulta m b f a d realizar una planifica- 5. Multiplicar la cantidad total de clases (clave +
cion razonable en la cual el trabajo en 10s subsistemas soporte) por el numero medio de unidades de trabajo
esti reparticla entre 10s rniembros del proyecto. por clase. Lorenz y Kidd sugieren entre 15 y 20 dias-
-persona por clase.
20.4.3. Un enfoque 00 para estimaciones 6. Comprobar la estimacion respecto a clases multipli-
y planificaci6n cando el nlimero promedio de unidades de trabajo
por gui6n de acci6n.
La estimaci6n en proyectos de software es mis un arte
que una ciencia. Sin embargo, esto en mod0 alguno La planificaci6n de proyectos orientados a objetos
excluye el uso de un enfoque sistemitico. Para desa- es complicada por la naturaleza iterativa del marco de
trabajo del proceso. Lorenz y Kidd sugieren un conjunto Se ha creado y revisado un modelo de comporta-
de mCtricas que pueden ayudar durante esta planifica- miento (Capitulo 2 1).
ci6n del proyecto: Se han marcado clases reutilizables.
Numero de iteraciones principales. Recor-
dando el modelo en espiral (Capitulo 2), una ite- Hito tbcnico: diseiio 00 terminado
raci6n principal corresponderh a un recorrido de Se ha definido y revisado el conjunto de subsistemas
360 grados de la espiral. El modelo de proceso (Capitulo 22).
recursivo/paralelo engendrari un numero de mini- Las clases se han asignado a subsistemas y han sido
espirales (iteraciones localizadas) que suceden
durante el progreso de la iteraci6n principal. Lorenz revisadas.
y Kidd sugieren que las iteraciones de entre 2.5 y Se ha establecido y revisado la asignaci6n de tareas.
4 meses de duraci6n son m8s fhciles de seguir y Se han identificado responsabilidades y colabora-
gestionar. ciones (Capitulo 22).
Numero de contratos completos. Un contrato Se han disefiado y revisado 10s atributos y operaciones.
es <<ungrupo de responsabilidades publicas rela-
Se ha creado y revisado el modelo de paso de men-
cionadas que 10s subsistemas y las clases propor-
cionan a sus clientew [LOR94]. Un contrato es un sajes.
hito excelente, y deberia asociarse a1 menos un con- Hito tbcnico: programacidn 00 terminada
trato a cada iteracibn del proyecto. Un jefe de pro-
yecto puede usar contratos completos como un Cada nueva clase ha sido implementada en c6digo a
buen indicador del plogreso en un proyecto 00. partir del modelo de disefio.
Las clases extraidas (de una biblioteca de reutiliza-
ci6n) se han integrado.
20.4.4. Seguimiento del progreso e n un pro-
Se ha constmido un prototipo o incremento.
yecto orientado a objetos
Aunque el modelo de proceso recursivo/paralelo es el Hito tbcnico: prueba 00
mejor marco de trabajo para un proyecto 00, el para- Han sido revisadas la correcci6n y compleci6n del
lelismo de tareas dificulta el seguimiento del proyec-
anhlisis 00 y del modelo de disefio.
to. El jefe del proyecto puede tener dificultades
estableciendo hitos significativos en un proyecto 00 Se ha desarrollado y revisado una red de clases-
debido a que siempre hay un cierto numero de cosas responsabilidades+olaboraciones (Capitulo 23).
ocurriendo a la vez. En general, 10s siguientes hitos Se han disefiado casos de pmeba y ejecutado pme-
principales pueden considerarse <<completados>> a1 bas a1 nivel de clases para cada clase (Capitulo 23).
cumplirse 10s criterios mostrados: Se han disefiado casos de pmeba y completado pme-
bas de agmpamientos (Capitulo 23) y las clases se
Hito tbcnico: analisis 00 terminado han integrado.
Todas las clases, y la jerarquia de clases, estin defi- Se han terminado las pmebas del sistema.
nidas y revisadas.
Recordando el modelo de proceso recursivo/parale-
Se han definido y revisado 10s atributos de clase y
lo examinado anteriormente en este capitulo, es impor-
las operaciones asociadas a una clase. tante destacar que cada uno de estos hitos puede ser
Se han establecido y revisado las relaciones entre revisado nuevamente a1 entregar diferentes incremen-
clases (Capitulo 21). tos a1 usuario.
Las tecnologias de objetos reflejan una visi6n natu- sentados como objetos. Es importante destacar que
ral del mundo. Los objetos se clasifican en clases y 10s objetos (y las clases de las que se derivan) encap-
las clases se organizan en jerarquias. Cada clase con- sulan datos y procesos. Las operaciones de procesa-
tiene un conjunto de atributos que la describen y un miento son parte del objeto y se inician a1 pasarle un
conjunto de operaciones que define su comporta- mensaje a1 objeto. Una definici6n de clase, una vez
miento. Los objetos modelan casi todos 10s aspectos definida, constituye la base para la reutilizaci6n en
identificables del dominio del problema: entidades 10s niveles de modelado, disefio e implementaci6n.
externas, cosas, ocurrencias, roles, unidades organi- Los objetos nuevos pueden ser instaciados a partir
zacionales, lugares y estructuras pueden ser repre- de una clase.
C A P ~ T U L O20 C O N C E P T O S Y PRINCIPIOS ORIENTADOS A OBIETOS
Tres conceptos importantes diferencian el enfoque 00 de lineas de codigo necesarias para implementar un sis-
de la ingenieria del software convencional. El encapsu- tema y facilita 10s cambios en caso de que se produzcan.
lamiento empaqueta datos y las operaciones que mane- Los productos y sistemas orientados a objetos se pro-
jan esos datos. La herencia permite que 10s atributos y ducen usando un modelo evolutivo, a veces llamado
operaciones de una clase puedan ser heredados por todas recursivo/paralelo. El software orientado a objetos evo-
las clases y objetos que se instancian de ella. El poli- luciona iterativamente y debe dirigirse teniendo en cuen-
morfismo permite que una cantidad de operaciones dife- ta que el product0 final se desarrollara a partir de una
rentes posean el mismo nombre, reduciendo la cantidad serie de incrementos.
[BER93] Berard, E.V., ~ s s a on

~ sO b j e c t q r i e n t e d Softwa- [COX861 Cox, B.J., Object-Oriented Programming, Addi-
re Engineering, Addison-Wesley, 1993. son-Wesley, 1986.
[BOO861 Booch, G., <<Object-OrientedDevelopmentw, IEEE [EVB89] Object-Oriented Requirements Analysis (course
Trans. Software Engineering, Ibl. SE-12, Febrero 1986, notebook), EVB Software Engineering, Inc., Frederick,
pp. 21 1 y ss. MD. 1989.
[BOO911 Booch, G., Object-Oriented Design, Benjamin- [JAC92]Jacobson, I., Object-Oriented Software Engineering,
Cummings, 1991. Addison-Wesley, 1992.
[BUD961 Budd, T., An introduction to Object-Oriented Pro- [LOR941 Lorenz, M., y Kidd, J., Object-Oriented Software
gramming, 2.a ed., Addison-Wesley, 1996. Metrics, Prentice-Hall, 1994.
[CAS89] Cashman, M., <<Object-Oriented

Domain Andy siw , [STR88] Stroustrup, B., <<Whatis Object-Oriented Pro-
ACM SofhYare Engineering Notes, vol. 14, n." 6, Octubre gramming?,,, IEEE Software, vol. 5 , n." 3, Mayo 1988,
1989, pp 67. pp. 10-20.
[CHA93] Charnpeaux, D. de D. Lea, y P. Faure, Object-Orien- [TAY90]Taylor, D.A., Object-Oriented Technology:A Mana-
ted System Development, Addison-Wesley, 1993. ger S Guide, Addison-Wesley, 1990.
[COA91] Coad, P., y Yourdon, E., Object-OrientedAnalysis,

2." ed., Prentice-Hall, 1991.
20.1. La ingenieria del software orientada a objetos e s d reem- 20.6. Considere la tipica interfaz grifica de usuario (IGU).
plazando ripidamente a 10s enfoques de desarrollo de soft- Defina un conjunto de clases y subclases para las enti-
ware tradicionales. Como todas las tecnologias, la orientation dades de la interfaz que aparecen generalmente en una
a objetos tambiCn tiene sus fallos. Utilizando Internet y otras IGU. Asegurese de definir 10s atributos y operaciones
fuentes de bibliografia mis tradicionales, escriba un breve apropiadas.
articulo que resuma lo que 10s criticos dicen sobre la 00 y
por quC creen que hay que tener cuidado a1 aplicar el para- 20.7. Detalle 10s objetos que aparecerian en un sistema de
digma de objetos. reserva de aulas de lectura en una universidad o colegio.
~ C u i l e sserian sus atributos?
20.2. En este capitulo no hemos considerado el caso en el que
un nuevo objeto necesita un atributo u operacion que no esti 20.8. Le ha sido asignada la tarea de ingenieria de un nue-
contenido en la clase de la que hereda el resto de atributos y vo programa de procesamiento de textos. Se ha identifi-
operaciones. iC6m0 Cree que se manejaria esta situation? cad0 una clase llamada documento. Defina 10s atributos
y operaciones relevantes de dicha clase.
20.3. Detalle 10s objetos que participarian en un sistema
de reservas de vuelos. iCuiles serian sus atributos? 20.9. Investigue dos lenguajes de programacion 00 dife-
20.4. Utilizando sus propias palabras y algunos ejemplos defina rentes y muestre la implementation de 10s mensajes en la
10s tCrminos clase, encapsulamiento, herencia y polimorfismo. sintaxis de cada uno de ellos. Ponga ejemplos.
20.5. Revise 10s objetos definidos en el sistema HogarSe- 20.10. Ponga un ejemplo concreto de reestructuracidn de
guro. j,Cree que hay otros objetos que deban ser definidos jerarquia de clases tal y como aparece en la discusion de
como principio del modelado? la Figura 20.8.
INGENIERiA DEL SOFTWARE. UN ENFOQUE PRACTICO
20.11. Ponga un ejemplo de herencia multiple. Investigue la Secci6n 20.3.1 para determinar quC clases debenan estar
algunos articulos sobre el tema y extraiga 10s pros y 10s en el modelo de anilisis.
contras.
20.13. Describa con sus propias palabras por quC el mode-
20.12. Escriba un enunciado para un sistema que le pro- lo recursivo/paralelo es apropiado en 10s sistemas 00.
porcione su profesor. Utilice el analizador sintictico gra-
matical para identificar clases candidatas, atributos y 20.14- Ponga tres 0 cuatro ejem~losde clases clave y de
operaciones. Aplique el criterio de selecci6n discutido en SoPorte que se describieron en la Secci6n 20.4.2.
La explosi6n de inter& por las tecnologias 00 ha dado como La naturaleza 6nica del paradigma 00 supone especia-
resultado la publication de literalmente cientos de libros duran- les retos a 10s gestores de proyecto. Los libros de Cock-
te 10s hltimos 15 aiios. El tratarniento abreviado de Taylor Burn (Surviving Object-Oriented Projects: A Manager's
[TAY90]sigue siendo la rnejor intrcducci6n al tema. Ademk, Guide, Addison-Wesley, 1998), Booch (Object Solutions:
10s libros de Ambler (The Object Primer: The application Deve- Managing the Object Oriented Project, Addison-Wesley,
lopper's Guide to Object-Orientation,SIGS Books, 1998),Gos- 1995), Goldberg y Rubin (Succeding With Objects: Deci-
sain y Graham (Object Modeling and Design Strategies, SIGS sion Frameworks for Project Management, Addison-Wes-
Books, 1998), Bahar (Object Technology Made Simple, Simple ley, 1995) y Meyer (Object-Success:A Manager's Guide
Software Publishing, 1996) y Singer (Object TechnologyStra- to Object Orientation, Prentice-Hall, 1995) consideran las
tegies and Tactics,Cambridge University Press, 1996) son tam- estrategias de planificacion, seguimiento y control de pro-
biCn valiosas introducciones a 10s conceptos y mktcdos 00. yectos 00.
Zarnir (Handbookof Object Technology,CRC Press, 1998) Earles y Simms (Building Business Objects, Wiley,
ha editado un volurninoso tratado que cubre todos 10s aspec- 1998), Carmichael (Developing Business Objects, SIGS
tos de las tecnologias de objetos. Fayad y Laitnen (Transition Books, 1998), Fingar (The Blueprint for Business Objects,
to Object-Oriented Sofhvare Development, Wiley, 1998) uti- Cambridge University Press, 1996) y Taylor (BusinessEngi-
liza casos de estudio para identificar 10s retos tkcnicos, cul- neerin with Object Technology, Wiley, 1995) enfocan la
turales y de gesti6n a superar cuando una organizaci6n hace tecnologia de objetos tal y como se aplica en contextos de
una transition a la tecnologia de objetos. Gardner et al. (Cog- negocios. Sus libros muestran mCtodos para expresar 10s
nitive Patterns: Problems-solving Frameworks for Object conceptos y requisitos de negocio directamente como obje-
Technology, Cambride University Press, 1998) proporcionan tos y aplicaciones orientadas a objetos.
a1 lector una introduccibn bisica sobre conceptos de resolu- En Internet hay gran variedad de fuentes de informa-
ci6n de problemas y la tecnologia asociada a 10s patrones cog- ci6n sobre tecnologias de objetos y otros temas relaciona-
nitivos y al modelado cognitive tal y corno se aplican en 10s dos. En http://www.pressman5.com encontrari una lista
sistemas orientados a objetos. de referencias web actualizada sobre temas 00.
C
UANDO se tiene que construir un nuevo producto o sistema, jc6m0 lo caracterizamos de
forma tal que sea tratado por la ingenieria del software orientado a objetos? iHay pregun-
tas especiales que queramos hacer a1 cliente? iCuriles son 10s objetos relevantes? iC6m0
se relacionan entre sf? iC6m0 se comportan 10s objetos en el contexto del sistema? ~ C 6 m oespe-
cificamos o modelamos un problerna de forma tal que podamos crear un diseiio eficaz?
A cada una de estas interrogantes se responde dentro del contexto del analisis orientado a
objetos (AOO), primera actividad tkcnica que se desarrolla como parte de la ingenieria del soft-
ware 00. En lugar de examinar un problerna utilizando el modelo de information clrisico de
flujo de datos, el A 0 0 introduce varios conceptos nuevos. Coad y Yourdon [COA9 11 conside-
ran el tema cuando escriben:
El A 0 0 (Andisis Orientado a Objetos) se basa en conceptos que ya aprendimos en la guarderia: obje-
tos y atributos, clases y miembros, todos y panes. El porquC nos ha llevado tanto tiempo aplicar estos con-
ceptos al anlilisis y especificaci6n dc sistemas es algo que nadie sabe a ciencia cierta...
El A 0 0 se basa en un conjunto de principios brisicos que se introdujeron en el Capitulo 11.
Para construir un modelo de analisis se aplican cinco principios basicos: (I) se modela el domi-
nio de la informacih; (2) se describe la funcion; (3) se representa el comportamiento del mode-
lo; (4) 10s modelos de datos, funcional y de comportamiento se dividen para mostrar m6s detalles;
y (5) 10s modelos iniciales representan la esencia del problema mientras que 10s riltimos apor-
tan detalles de la implementation. Estos principios forman la base para el enfoque del A 0 0
presentado en ese capitulo.
&Qu&cs? Antes de que pueda construir un &Porqu6 es importcmte? No s e puede traslada la informacih de los casoa de
sistema orientado a objetos. tiene que mnstruir software (orientadoa objetos o usoa una representacionde lasclases y
definii lasclases (objetos)que represen- de otro t i p ) hasta pue se tiene un cone sus colaboraciones mn las otras clases.
tan el problema a resolver, la forma e n cimiento ramnable del sistema o pro- Las maderisticas estdrticasy d i n h i c a s
que las clases s e relacionan e interac- duct~.El AOOnos proporciona una foma de las clases se modelan entonces utili-
turn unas con otras, el funcionamiento mncretade representar el conmimiento m d o un lenguaje de modelado unifica-
interno (atributos y operaciones) de 10s de los requisitos y una forma de probar do o cualquier otro m6todo.
objetos y 10s meccmismosd e comunica- dichoconmimiento enfrentcindoloconla ea el producto obtenido? Se
ci6n (mensajes) que 10s permiten tratu- percepci6n que el cliente tiene del siste- crea un modelo d e an~ilisisorientado
jar juntos. Todas estas cosasse cumplen ma a construir. a objetos. Dicho modelo se cornpane de
en el analisis orientado a objetos. jWe~ son lor El A 0 0 comien- una representaci6n grgrdrfica. o basada
iQdh lo h? ladefinici6n de un mode za con ma descripci6n de casx de uso, en el lenguaje. que define 10s atributos
lo d e cm&lisislleva implicita una des- que e s una descripcih de escenarios d e la clase. las relaciones y comprta-
cripci6n d e las caracteristicaa de lag sobre c6mo i n t e r a c ~ a n10s adores (gen- mientos y l a s comunicaciones entre
clases que describen un sistema o p m te, mbquinas u otros sistemas) con el sis- clases, asi como una representaci6n
ducto. La nctividad la realim un inge- tema a mnstruir. El modelo de clases- del comportamiento d e l a clase en e l
niero del software. responsabilidad-colaboraci6n(CRC) tiempo.
El prop6sito del A 0 0 es definir todas las clases que son relevantes al problema que se va a
resolver, las operaciones y atributos asociados, las relaciones y comportamientos asociadas con
ellas. Para cumplirlo se deben ejecutar las siguientes tareas:
1. Los requisitos brisicos del usuario deben comunicarse entre el cliente y el ingeniero del
software.
2. Identificar las clases (es decir, definir atributos y mktodos).
3. Se debe especificar una jerarquia de clases.
4. Representan las relaciones objeto a objeto (conexiones de objetos).
5. Modelar el comportamiento del objeto.
6. Repetir iterativamente las tareas de la 1 a la 5 hasta completar el modelo.
INGENIERIA DEL SOFTWARE. U N ENFOQUE P R A C T l C O
Es importante observar que no existe un acuerdo universal sobre 10s ccconceptos>>que sirven de base para el AOO,
per0 un limitado numero de ideas clave se repten a menudo, y son Cstas las que consideraremos en este capitulo.
El objetivo del analisis orientado a objetos es desarro- El metodo de Booch. El mCtodo de Booch [BOO941
llar una serie de modelos que describan el software de abarca un ccmicroproceso de desarrollo>>y un ccmacro-
computadora a1 trabajar para satisfacer un conjunto de proceso de desarrollo>>. El nivel micro define un conjunto
requisitos definidos por el cliente. El AOO, como 10s de tareas de andisis que se reaplican en cada etapa en el
mCtodos de analisis convencional descritos en el Capi- macro proceso. Por esto se mantienen un enfoque evo-
tulo 12, forman un modelo de andisis multiparte para lutivo. El micro proceso de desarrollo identifica clases y
satisfacer este objetivo. El modelo de analisis ilustra objetos y la semiintica de dichas clases y objetos, define
informaci6n, funcionamiento y comportamiento dentro las relaciones entre clases y objetosy realiza una serie de
del context0 de 10s elementos del modelo de objetos refinamientos para elaborar el modelo del an8lisis.
descrito en el Capitulo 20.
21.1.1. Enfoques convencionales y enfoques 00

~ Eels analisis orientado a objetos realmente diferente del
enfoque del andisis estructurado presentado en el Capi-
tulo 12? Aunque el debate continua, Fichman y Keme-
rer [FIC92] responden a la pregunta directamente:
Concluimos que el enfoque del an6lisis orientado a obje- El metodo de Rumbaugh. Rumbaugh [RUM911 y
tos... representa un cambio radical sobre lar metodologias orien-
sus colegas desarrollaron la Te'cnica de Modelado de
tadas a procesos, tales como el analisis estructurado, pero solo
un cambio incremental respecto a las metodologias orientadas Objetos (OMT) para el analisis, disefio del sistema y
a datos, tales como la ingenieria de la informacion. Las meto- disefio a nivel de objetos. La actividad de anhlisis crea
dologias orientadas a procesos desvian la atenci6n de las prio- tres modelos: el modelo de objetos (una representaci6n
ridades inherentes a 10s objetos durante el proceso de modelado de objetos, clases, jerarquias y relaciones), el modelo
y conducen a un modelo del dominio del problema ortogonal dinamico (una representaci6n del comportamiento del
con 10s tres principios esenciales de la orientaci6n a objetos:
sistema y 10s objetos) y el modelo funcional (una repre-
encapsulamiento, clasificacion de objetos y herencia.
sentaci6n a alto nivel del flujo de informaci6n a travks
Dicho simplemente, el andisis estructurado toma una del sistema similar a1 DFD).
visi6n diferente de 10s requisitos del modelo entrada- El metodo de Jacobson. TambiCn llamado OOSE
proceso-salida. Los datos se consideran separadamente (en espaiiol Ingenieria del Software Orientada a Obje-
de 10s procesos que 10s transforman. El comportamientos), el mCtodo de Jacobson [JAC92] es una versi6n sim-
to del sistema, aunque importante, tiende a desempefiar plificada de Objectory, un mCtodo patentado, tambiCn
un papel secundario en el analisis estructurado. El an& desarrollado por Jacobson. Este mCtodo se diferencia de
lisis estructurado hace un fuerte uso de la descomposi- 10s otros por la importancia que da a1 caso de uso --ma
cion funcional (particidn del diagrarna de flujo de datos, descripci6n o escenario que describe c6mo el usuario
Capitulo 12). interactda con el producto o sistema-.
El metodo de Coad y Yourdon. El mCtodo de Coad
21.1.2. El panorama del A 0 0 y Yourdon [COA91] se considera, con frecuencia, como
La popularidad de las tecnologias de objetos ha gene- uno de 10s mCtodos del A 0 0 mhs sencillos de apren-
rado docenas de mCtodos de A 0 0 desde finales de 10s der. La notaci6n del modelado es relativamente simple
80 y durante 10s 90'. Cada uno de ellos introduce un y las reglas para desarrollar el modelo de analisis son
proceso para el analisis de un producto o sistema, un evidentes. A continuaci6n sigue una descripci6n resu-
conjunto de modelos que evoluciona fuera del proceso, mida del proceso de A 0 0 de Coad y Yourdon:
y una notaci6n que posibilita a1 ingeniero del software Identificar objetos usando el criterio de ccquC buscar~.
crear cada modelo de una manera consistente. Entre 10s Definir una estructura de generalizacibn-especifi-
mas ampliamente utilizados se encuentran2: caci6n.
' La discusion detallada de estos metodos y sus diferencias esta fuera En general, 10s metodos de A 0 0 se identifican usando el (o 10s)
del alcance en este libro. Ademas, la industria se mueve hacia una nombre(s) del desarrollador del metodo, incluso si al metodo se le
forma de modelado unificada en un linico metodo, lo que hace que ha dado un nombre o acronimo unico.
las discusiones sobre 10s antiguos metodos solo tengan sentido a
efectos historicos. El lector interesado puede consultar a Berard
[BER92]y Graham LGR.4941 para una comparacion mas detallada.
INGENIER~A
Vista del comportamiento: esta parte del modelo del Vista de implementacibn: 10s aspectos estructurales
anhlisis representa 10s aspectos dinhmicos o de com- y de comportamiento se representan aqui tal y como van
portamiento del sistema. TambiCn muestra las interac- a ser implementados.
ciones o colaboraciones entre 10s diversos elementos Vista del entorno: aspectos estructurales y de com-
estructurales descritos en las vistas anteriores. portamiento en el que el sistema a implementar se repre-
senta.
En general, el modelo de anhlisis de UML se centra
en las vistas del usuario y estructural. El modelo de dise-
En mini.net/cetus/oo-umI.html hoy un omplio iio de UML (tratado en el Capitulo 22) se dirige mas a
tutoriol y una listo de recursos UML que incluye las vistas del comportamiento y del entorno. En el Capi-
herromientos, ortirulos y ejemplos. tulo 22 describiremos UML con mas detalle.
El analisis en sistemas orientados a objetos puede ocu- la necesidad de 100 clases. Se le asigna a dos equipos
m r a muchos niveles diferentes de abstraction. A nivel la tarea de construir la aplicaci6n. Cada uno debe dise-
de negocios o empresas, las tCcnicas asociadas con el iiar y construir un producto final y, a su vez, esta com-
A 0 0 pueden acoplarse con un enfoque de ingenieria puesto de personas con el mismo nivel de habilidad y
de la informaci6n (Capitulo 10) en un esfuerzo por defi- experiencia.
nir clases, objetos, relaciones y comportamientos que
modelen el negocio por completo. A nivel de Areas de
negocios, puede definirse un modelo de objetos que des-
criba el trabajo de un Area especifica de negocios (o una
categoria de productos o sistemas). A nivel de las apli- Ohos beneficios derivodos de lo reutilizocibnson
caciones, el modelo de objetos se centra en 10s requisi- lo consistencia y lo fomilioridod. 10s pofrones denfro
del softwore serbn mbs consistentes, tendiendo
tos especificos del cliente, pues Cstos afectan a la
o focilitar el montenimiento del producto. Asegcrese de
aplicaci6n que se va a construir.
estoblecer un conjunto de reglos de reutilizocion
poro conseguir dichos objetivos.
El equipo A no tiene acceso a una biblioteca de cla-

N objetivo del onolisis del dominio es definir el conjunto ses, por lo que debe desarrollar las 100 clases desde
de closes (obietos) que se encuenfron en el dominio de
el principio. El equipo B usa una biblioteca de clases
lo oplicocion. Dichos closes podran reutilizonemurhos feces.
robusta y encuentra que ya existen 55 clases. Seguro
que:
El AOO, en su nivel de abstracci6n mas alto (el nivel
de empresa), esth mis all5 del alcance de este libro. Los 1. El equipo B finalizari el proyecto mucho antes que
el A.
lectores interesados deberian ver a [EEL98], [CAR98],
[FIN96], [MAT94], [SUL94] y [TAY95], 10s cuales 2. El coste del producto del equipo B sera significati-
hacen un analisis mas detallado. A nivel de abstracci6n vamente mas bajo que el coste del producto del
mhs bajo, el A 0 0 cae dentro del alcance general de la equipo A.
ingenieria del software orientado a objetos y es el cen- 3. La versidn que se distribuya del producto producido
tro de atenci6n del resto de las secciones de este capi- por el equipo B tendra menos defectos que la del pro-
tulo. En esta secci6n nos centraremos en el A 0 0 que ducto del equipo A.
se realiza a un nivel medio de abstracci6n. Esta activi- Aunque el margen por el cual el trabajo del equipo
dad, llamada andisis del dominio, tiene lugar cuando B exceder5 a1 del A esta abierto a debate, pocos argu-
una organizaci6n desea crear una biblioteca de clases mentarin que la reusabilidad aporta una ventaja subs-
reutilizables (componentes) ampliamente aplicables a tancial a1 equipo B.
una categoria completa de aplicaciones.
~ P e r ode d6nde vino la <<bibliotecade clases robus-
ta,,? iY c6mo se determin6 que las entradas de la biblio-
21.2.1. Andrlisis de reutilizacih y del dominio teca eran apropiadas para su uso en nuevas aplicaciones?
Las tecnologias de objetos estan influenciadas por la Para responder estas preguntas, la organizaci6n que cre6
reutilizaci6n. Considere un ejemplo simple. El anali- y mantuvo dicha biblioteca tuvo que aplicar el analisis
sis de 10s requisitos para nuevas aplicaciones indican del dominio.
CAPfTULO 2 1 ANALISIS ORIENTADO A O B J E T O S
21.2.2. El proceso de undrlisis del dominio

Firesmith [FIR931 describe el andisis del dominio del
software de la siguiente manera:
El analisis del dominio del software es la identificacibn,
analisis y especificaci6n de requisitos comunes de un domi-
nio de aplicaci6n especifico, normalmente para su reutili-
zacidn en multiples proyectos dentro del mismo dominio
de aplicaci6n ... (el analisis orientado a objetos del domi-
nio es la identificacion, analisis y especificaci6n de capa-
cidades comunes y reutilizables dentro de un dominio de
aplicaci6n especifico, en ttrminos de objetos, clases, sub- La Figura 21.1 [ARA89] ilustra las entradas y sali-
montajes y marcos de trabajo comunes ... das clave para el proceso de andisis del dominio. Se exa-
El ccdominio de aplicaciones especificon puede minan las fuentes del dominio de conocimiento en un
variar desde avi6nica hasta banca, desde juegos de intento de identificar objetos que se puedan reutilizar a
video multimedia hasta aplicaciones dentro de un esci- lo largo de todo el dominio. En esencia el analisis del
ner CAT. El objetivo del analisis del dominio es cla- dominio es muy similar a la ingenieria del conocimien-
ro: encontrar o crear aquellas clases ampliamente to. El ingeniero del conocimiento investiga un irea de
aplicadas, de tal manera que sean reutilizables. inter& especifica, intentando extraer hechos claves que
se puedan usar para la construcci6n de un sistema exper-
to o una red neuronal artificial. Durante el anilisis del
dominio ocurre la extracci6n de objetos (y clases).
l a reuti$odbn a b ptedm mgulm de la irtgmih Definir el dominio a investigar. Para llevar a cab0
del software bmdaen mnulonentes, tema sue se esta tarea, el analista debe primer0 aislar el irea de nego-
cio, tip0 de sistema o categoria del product0 de inter&.
A continuaci611, se deben extraer 10s ccelementosn tanto
00 como no 00.Los elementos 00 incluyen especifi-
Usando la terminologia introducida a1 inicio del caciones, diseiios y c6digo para clases de aplicaciones
libro, el analisis del dominio puede verse como la acti- 00 ya existentes; clases de soporte (p.e.: clases de Inter-
vidad de cobertura para el proceso del software. Con faz Grafica de Usuario o clases de acceso a bases de
esto queremos decir que el analisis del dominio es una datos); bibliotecas de componentes comerciales ya desa-
actividad en curso de la ingenieria del software no rrolladas (CYD) relevantes a1 dominio y casos de prueba.
ligada a ningun proyecto de software. En cierta for- Los elementos no 00 abarcan politicas, procedimien-
ma, el papel de un anilisis del dominio es similar a1 tos, planes, estindares y guias; partes de aplicaciones no
de un maestro tornero dentro de un entorno de fabri- 00 (incluyendoespecificaci61-1,diseiio e informacibn de
caci6n fuerte. El trabajo del maestro tornero es dise- prueba), mktricas y CYD del software no 00.
iiar y construir herramientas que pueden usarse por Clasificar 10s elementos extraidos del dominio. Los
varias personas que trabajan en aplicaciones simila- elementos se organizan en categorias y se establecen las
res, per0 no necesariamente idknticas. El papel del caracteristicas generales que definen la categoria. Se
analista del dominio es diseiiar y construir compo- propone un esquema de clasificaci6n para las catego-
nentes reutilizables que puedan ser utilizados por dife- rias y se definen convenciones para la nomenclatura de
rentes personas que trabajan en aplicaciones similares cada elemento. Se establecen jerarquias de clasificaci6n
per0 no necesariamente iguales. en caso de ser apropiado.
Literatura tecnica
Taxonomia de clases
I
Aplicaciones existentes b
Fuentes Estandar de reusabilidad Modelo
de Recursos del cliente
domimio Modelos funcionales del
Consejo de experto analisis
del
:onocimiento Lenguajes del dominio del
-
Requisitos actuales/futuros * dominio
FIGURA 21.1. Entrada y salida para analisis del dominio.
365
Ademhs, una vez que se han definido 10s objetos, el
analista debe estimar quC porcentaje de una aplicaci6n
tipica pudiera construirse usando 10s objetos reutilizables.
Desarrollar un modelo de analisis para 10s obje-
tos. El modelo de analisis serviri como base para el
diseiio y construccidn de 10s objetos del dominio.
Recolectar una muestra representativa de aplica- Adicionalmente a estas etapas, el analista del domi-
ciones en el dominio. Para realizar esta tarea, el ana- nio tambiCn debe crear un conjunto de lineas maestras
lista debe asegurar que la aplicacidn en cuestidn tiene para la reutilizacidn, y desarrollar un ejemplo que ilus-
elementos que caen dentro de las categorias ya defini- tre cdmo 10s objetos del dominio pudieran usarse para
das. Berard [BER93] observa que durante las primeras crear una aplicacidn nueva.
etapas de uso de las tecnologias de objetos, una orga- El andisis del dominio es la primera actividad tCc-
nizacidn del software tendr6 muy pocas, si hay alguna, nica en una amplia disciplina que algunos llaman inge-
aplicaciones 00.Debido a esto, el analista de dominio nieria del dominio. Cuando un negocio, sistema o
debe ccidentificar 10s objetos conceptuales (opuestos a product0 del dominio es definido como estrategico a
10s fisicos) en cada aplicacidn [no 001~. largo plazo, puede desarrollarse un esfuerzo continua-
do para crear una biblioteca reutilizable robusta. El obje-
Analizar cada aplicacion dentro de la muestra. El
tivo es ser capaz de crear software dentro del dominio
analista debe seguir las etapas siguientes [BER93]:
con un alto porcentaje de componentes reutilizables.
Identificar objetos candidatos reutilizables. Argumentos a favor de un esfuerzo dedicado a la inge-
Indicar las razones que hacen que el objeto haya sido nieria del dominio son: bajo coste, mayor calidad y
identificado como reutilizable. menor tiempo de comercializacidn.
Definir adaptaciones a1 objeto que tambiCn pueden
ser reutilizables.
Estimar el porcentaje de aplicaciones en el dominio
que pueden reutilizar el objeto.
Referencia web/ '
En www.sei.crnu.edu/str/descriptions/deda.htrnl
Identificar 10s objetos por nombre y usar tCcnicas de hay un tutorial sobre anblisis del dominio que merece lo peno.
gestidn de configuracidn para controlarlos (Capitulo 9).
El proceso de anfilisis orientado a objetos se adapta a componentes de representaci6n genCricos que apare-
conceptos y principios basicos de andisis discutidos en cen en todos 10s modelos de analisis 005.Los compo-
el Capitulo 11. Aunque la terminologia, notacidn y acti- nentes estciticos son estructurales por naturaleza, e
vidades difieren respecto de 10s usados en mCtodos con- indican caracten'sticas que se mantienen durante toda
vencionales, el A 0 0 (en su ndcleo) resuelve 10s mismos la vida operativa de una aplicacidn. Los componentes
objetivos subyacentes. Rumbaugh [RUM911 examina dincimicos se centran en el control, y son sensibles a1
esto cuando asegura que: tiempo y a1 tratamiento de sucesos. Estos liltimos defi-
El andisis ... se ocupa de proyectar un modelo preciso, con-
nen c6mo interactda un objeto con otros a lo largo del
ciso, comprensible y correcto del mundo real. ...El prop6sito tiempo. Pueden identificarse 10s siguientes componen-
de andisis orientado a objetos es modelar el mundo real de for- tes [MON92]:
ma tal que sea comprensible. Para esto se deben examinar 10s
requisitos, analizar las implicaciones que se deriven de ellos y Vista estcitica de clases sema'nticas. Una taxonomia de
r e a h a r l o s de manera rigurosa. Se deben abstraer primer0 las clases tipicas se mostrd en el Capitulo 20. Se irnponen 10s
caracteristicas del mundo real y dejar 10s pequeiios detalles requisitos y se extraen (y representan) las clases como
para m h tarde. parte del modelo de anilisis. Estas clases persisten a tra-
Para desarrollar un ccmodelo preciso, conciso, com- vCs de todo el period0 de vida de la aplicacidn y se deri-
prensible y correcto del mundo real>>,un ingeniero del van bashdose en la semhtica de 10s requisitos del cliente.
software debe seleccionar una notacidn que se sopor-
te a un conjunto de componentes genCricos de AOO. &ales son 10s tornponentes
Monarchi y Puhr [MON92] definen un conjunto de tlave de un modelo de AOO?
Los autores [MON92] aportan tambien un analisis de veintitres meto-

dos de A 0 0 e indican como representan estos dichas componentes.
C A P ~ T U L O21 ANALISIS ORIENTADO A O B J E T O S
portamientos que se adaptan a1 escenario utilizado (casos

de uso) del sistema. Estos comportarnientos se imple-
mentan a travCs de la definicion de una secuencia de
10s cornponentes estaticos no carnbian rnientras operaciones que 10s ejecutan.
la aplicacidn se estd eiecutando. 10s cornponentes Vista dincimica de la comunicaci6n. Los objetos
dindrnicos est6n influenciadospor el tiernpo y 10s sucesos. deben comunicarse unos con otros y hacerlo bashdose
en una serie de mensajes que provoquen transiciones de
Vista estcitica de 10s atributos. Toda clase debe des- un estado a otro del sistema.
cribirse explicitamente. Los atributos asociados con la Vista didmica del control y rnanejo del tiempo. Debe
clase aportan una descripcion de la clase, asi como una describirse la naturaleza y duration de 10s sucesos que
indicaci6n inicial de las operaciones relevantes a esta provocan transiciones de estados.
clase. De Champeaux y sus colegas [CHA93] definen una
Vista estcitica de las relaciones. Los objetos estan vista ligeramente diferente de las representaciones del
ccconectados>> unos a otros de varias formas. El modelo AOO. Las componentes estaticas y dinamicas se
de analisis debe representar las relaciones de manera tal identifican para el objeto internamente y para las
que puedan identificarse las operaciones (que afecten a representaciones entre objetos. Una vista dinamica e
estas conexiones) y que pueda desarrollarse un buen intema del objeto puede caracterizarse como la historia
diseiio de intercambio de mensajes. de vida del objeto, esto es, 10s estados que alcanza el
Vista estcitica de 10s comportamientos. Las relacio- objeto a lo largo del tiempo, a1 realizarse una serie de
nes indicadas anteriormente definen un conjunto de com- operaciones sobre sus atributos.
El proceso de A 0 0 no comienza con una preocupacion proporcionar una base para la validacion de las
por 10s objetos. Mas bien comienza con una compren- pruebas.
sion de la manera en la que se usara el sistema: por las
Durante el A 0 0 10s casos de uso sirven como base
personas, si el sistema es de interaccion con el hombre;
para 10s primeros elementos del modelo de anhlisis.
por otras maquinas, si el sistema esta envuelto en un Utilizando UML se puede crew una representaci6n
control de procesos; o por otros programas; si el siste- visual de 10s casos de uso llamada diagrama de casos
ma coordina y controla otras aplicaciones. Una vez que
de uso. Como otros elementos del anfilisis, 10s casos de
se ha definido el escenario, comienza el modelado del
uso pueden representarse a diferentes niveles de abs-
software.
traction. Los diagramas de casos de uso contienen casos
Las secciones que siguen definen una serie de tCcni-
de uso y actores, siendo estos ultimos las entidades que
cas que pueden usarse para recopilar requisitos basicos
interactuan con el sistema. Pueden ser humanos u otras
del usuario y despuCs definen un modelo de analisis para maquinas o sistemas que tengan definidas interfaces con
un sistema orientado a objetos. nuestro sistema.
21.4.1. Casos de uso
Como examinamos en el Capitulo 11,los casos de uso
modelan el sistema desde el punto de vista del usuario.
Creados durante la obtencion de requisitos, 10s casos de En www.univ-pan's1 .fr/CRINFO/aWg/MEE/miqOl4
uso deben cumplir 10s siguientes objetivos: existe un tutorial que aborda en profundidod 10s cams de IJSO.
definir 10s requisitos funcionales y operativos del sis-
tema (producto),diseiiando un escenario de uso acor- El sistema de seguridad HogarSeguro, discutido en
dado por el usuario final, y el equipo de desarrollo; capitulos anteriores, puede usarse para ilustrar como pue-
proporcionar una descripcion clara y sin ambigiie- den desarrollarse casos de uso. Recordando 10s requisi-
dades de como el usuario final interactua con el sis- tos basicos de HogarSeguro, podemos definir tres
tema y viceversa, y actores: e1,propietario (el usuario), 10s sensores (dis-
positivos adjuntos a1 sistema) y el subsistema de moni-
torizacion y respuesta (la estacion central que
monitoriza HogarSeguro). Para 10s prop6sitos de este
Los CONS de uu, son uno excelente hemmiento de
ejemplo, consideraremos solamente el actor propietario.
l i i t i n de r e q u i i , mdependiintementedel mbtodo de
onblisii uiihodo. VBm el coprtulo 11 porn rnb detolle.
La Figura 21.2.a muestra un diagrama de casos de
uso de alto nivel para el propietario. En dicha figura
se identifican dos casos de uso y se representan con elip- facer estas seis caracteristicas para poder ser conside-
ses. Cada caso de uso de alto nivel puede detallarse rado como posible miembro del modelo:
mediante diagramas de casos de uso de nivel inferior.
Por ejemplo, la Figura 2 1.2.b representa un diagrama I . retener informacibn: el objeto potencial sera util
de casos de uso para la funcion interactha. Se crea un durante el analisis si la informaci6n sobre el mismo
conjunto completo de diagramas de casos de uso para debe guardarse para que el sistema funcione
todos 10s actores. Pero para una detallada discusion sobre 2. Servicios necesarios: el potencial objeto debe tener
10s casos de uso usando UML es mejor consultar la un conjunto de operaciones identificables que per-
bibliografia sobre el tema (p.e. [ERI97] o [ALH98]). mitan cambiar 10s valores de sus atributos.
3. Multiples atributos: durante el analisis de requisitos
21.4.2. Modelado de clases-responsabilidades- nos centramos mas en la informacion mas impor-
colaboraciones tante. Un objeto con un solo atributo puede, en efecto,
ser litil durante el disefio, per0 probablemente sera
Una vez que se han desarrollado los escenarios de uso un atributo de otro objeto durante el analisis de acti-
basicos para el sistema, es el momento de identificar las vidades.
clases candidatas e indicar sus responsabilidades y cola-
boraciones. El modelado de clases-responsabilidades- 4. Atributos comunes: el conjunto de atributos definido
colaboraciones (CRC) [WIR90] aporta un medio sencillo para la clase debe ser aplicable a todas las ocurren-
de identificar y organizar las clases que resulten relevantes cias del objeto.
a1 sistema o requisitos del producto. Ambler [AMB95]
describe el modelado CRC de la siguiente manera:
Un modelo CRC es realmente una colecci6n de tarjetas
indice esthdar que representan clases. Las tarjetas e s t h divi-
didas en tres secciones. A lo largo de la cabecera de la tarjeta
usted escribe el nombre de la clase. En el cuerpo se listan las
responsabilidades de la clase a la izquierda y a la derecha 10s
colaboradores.
Referencia web/ '

En www.univ-parisl .fr/CRINFO/dmrg/MEE97/misopOl3
puede consultor uno discusi6n detollodo de la tecnico de 10s torietas CRC.
En realidad, el modelo CRC puede hacer uso de tar-

jetas indice virtuales o reales. El caso es desarrollar una
contraseria
representaci6n organizada de las clases. Las responsa-
bilidades son 10s atributos y operaciones relevantes para
la clase. Puesto de forma simple, una responsabilidad
es cccualquier cosa que conoce o hace la claseu / 1 el estado
[AMB95]. Los colaboradores son aquellas clases nece-
sarias para proveer a una clase con la informaci6n nece-
saria para completar una responsabilidad. En general,
una colaboraci6n implica una solicitud de informaci6n
o una solicitud de alguna action. sensor
Clases Propietario
\\ AzA
Las pautas basicas para identificar clases y objetos se
presentaron en el Capitulo 20. Resumiendo, 10s objetos
se manifiestan en una variedad de formas (Secci6n
20.3.1): entidades externas, cosas, ocurrencias o suce-
sos, roles, unidades organizativas, lugares, o estructu-
\u de panico
Activarl
desactivar
ras. Una tCcnica para identificarlos en el context0 de un sisterna
problema del software es realizar un analisis gramati-
cal con la narrativa de procesamiento para el sistema.
Todos 10s nombres se transforman en objetos potencia-
les. Sin embargo, no todo objeto potencial podri FIGURA 21.2. a) Diagrama de casos de uso de alto nivel.
incluirse en el modelo. Un objeto potencial debe satis- b) Diagrama de casos de uso detallado.
C A P ~ T U L O2 1 ANALISIS O R I E N T A D O A O B J E T O S
~Comodeterminar si merece la
Responsabilidades
pena incluir un objeto potencial Las pautas basicas para identificar responsabilidades
en una tarjeta indice CRC? (atributos y operaciones) tambiCn fueron presentadas
en el Capitulo 20. Para resumir, 10s atributos represen-
Operaciones comunes: el objeto potencial debe defi- tan caracteristicas estables de una clase, esto es, infor-
nir un conjunto de operaciones aplicables, a1 igual maci6n sobre la clase que debe retenerse para llevar a
que antes, a todos 10s objetos de la clase. cab0 10s objetivos del software especificados por el
Requisitos esenciales: las entidades extemas que apa- cliente. Los atributos pueden a menudo extraerse del
recen en el espacio del problema y producen infor- planteamiento de alcance o discernirse a partir de la
maci6n esencial para la operaci6n de una soluci6n comprensi6n de la naturaleza de la clase. Las opera-
para el sistema casi siempre se definen como objeciones pueden extraerse desarrollando un analisis gra-
tos en el modelo de requisitos. matical sobre la narrativa de procesamiento del sistema.
Una clase potencial debe satisfacer las seis caracte- Los verbos se transforman en candidatos a operaciones.
risticas de selecci6n anteriores si va a ser incluida en el Cada operaci6n elegida para una clase exhibe un com-
modelo CRC. portamiento de la clase.
Firesmith [FIR931 extiende las caracteristicas de cla-
sificaci6n sugiriendo, ademas de las existentes, las
siguientes:
Clases dispositivo. Modelan entidades extemas tales 1s responsabilidades de uno clase incluyen tonto o 10s
como sensores, motores y teclados. atributos como o los ooerociones.
Clases propiedad. Representan alguna propiedad
importante del entorno del problema (por ejemplo: esta-
blecimiento de crCditos dentro del context0 de una apli- Wirfs-Brock y sus colegas [WIR90] sugieren cinco
caci6n de prestamos hipotecarios). pautas para especificar responsabilidades para las clases:
Clases interaccion. Modelan interacciones que ocu- 1. La inteligencia del sistema debe distribuirse de
rren entre otros objetos (por ejemplo: una adquisici6n o manera igualitaria. Toda aplicaci6n encierra un cierto
una licencia). grado de inteligencia, por ejemplo, lo que sabe el sis-
tema y lo que puede hacer. Esta inteligencia puede
distribuirse ente las clases de varias maneras. Las
i H a y alyuna manera de clasificar
clases cctontas>>(aquellas con pocas responsabilida-
las clases? i Q u i caracteristicas
des) pueden modelarse de manera que actuen como
nos ayudan a hacerlo?
sirvientes de unas pocas clases <<listas>>
(aquellas con
Adicionalmente, 10s objetos y clases pueden clarifi- muchas responsabilidades). Aunque este enfoque
carse por un conjunto de caracteristicas: hace que el flujo de control dentro de un sistema sea
claro, posee algunas desventajas: (1) Concentra toda
Tangibilidad. ~Representala clase algo tangible o la inteligencia en pocas clases, haciendo 10s cambios
palpable (por ejemplo, un teclado o sensor), o repre- mas dificiles; (2) Tiende a necesitar mas clases y por
senta information mas abstracta (por ejemplo: una salida lo tanto el esfuerzo de desarrollo aumenta.
prevista)?
Inclusividad. ~ E la s clase atbmica (es decir, no iComo asignar responsabilidades
incluye otras clases) o es agregada (incluye a1 menos a una clase?
un objeto anidado)?
Secuencia. ~ E las clase concurrente (es decir posee Por esta raz6n, la inteligencia del sistema debe
su propio hilo de control) o secuencial (es controlada distribuirse de manera igualitaria entre las clases de
por recursos externos)? una aplicaci6n. Como cada objeto conoce y actua
Persistencia. La clase es temporal (se crea durante sobre algunos pocos elementos (generalmente bien
la ejecuci6n del programa y es eliminada una vez que definidos y claros), la cohesion del sistema se ve
Cste termina), o permanente (es almacenada en una base incrementada. Adicionalmente, 10s efectos colatera-
de datos)? les provocados por cambios tienden a amortiguarse
Integridad. iEs la clase corrompible (es decir, no pro- debido a que la inteligencia del sistema se ha des-
tege sus recursos de influencias externas) o es segura (la compuesto entre muchos objetos.
clase refuerza 10s controles de accesos a sus recursos)?
Usando estas categorias de clases, pueden ampliar-
se las cctarjetas indice>>creadas como parte del modelo Si una clase tiene m a lista excesivamente largo de
CRC para incluir el tip0 de la clase y sus caracteristi- respansabilidades, to1 vez debenb cansidera~esu divisibn
cas (Fig. 21.3). en varias clases menares.
Para determinar si la inteligencia del sistema esti sabilidad no debe compartirse, de manera general,
distribuida equitativamente, las responsabilidades entre varias clases. Si la informaci6n esti distri-
definidas en cada tarjeta indice del modelo CRC buida, el software se torna mis dificil de mantener
deben ser evaluadas para determinar si cada clase y probar.
posee una lista de responsabilidades extraordina- Compartir responsabilidades entre clases relacio-
riamente grande. Esto indica una concentraci6n de nadas cuando sea apropiado. Existen muchos casos
inteligencia. Ademas, las responsabilidades de cada en 10s cuales una gran variedad de objetos exhibe el
clase deben mostrar el mismo nivel de abstracci6n. mismo comportamiento a1 mismo tiempo. Como un
Por ejemplo, entre la lista de operaciones de una ejemplo, considere un videojuego que debe mostrar
clase agregada llamada Comprobacion de cuenta 10s siguientes objetos: jugador, cuerpo-del-juga-
existen dos responsabilidades: saldo-de-la-cuenta dor, brazos-del-jugador, cabeza-del-jugador. Cada
y verificar-talones-cobrados.La primera operaci6n uno de estos atributos tiene sus propios atributos (p.e.:
(responsabilidad) implica un complejo procedi- posicidn, orientacibn, color, velocidad), y todos
miento matemitico y 16gico. La segunda es una sim- deben actualizarse y visualizarse a1 mover el usua-
ple actividad para empleados. Debido a que estas rio el joystick. Las responsabilidades actualizar y
dos actividades no estan a1 mismo nivel de abs- visualizar deben, por lo tanto, compartirse por 10s
traccibn, verificar-talones-cobrados debe situarse objetos seiialados. El jugador sabe cuando algo ha
dentro de las responsabilidades de la clase Com- cambiado y se requiere actualizar; colabora con 10s
probacion de entradas, la cual esti contenida en otros objetos para alcanzar una nueva posici6n u
la clase agregada Comprobacion de cuenta. orientacibn, per0 cada objeto controla su propia
visualizacibn.
1 Nombre de la clase: L
Colaboradores
Las clases cumplen con sus responsabilidades de una
de las dos siguientes maneras: ( I ) una clase puede
usar sus propias operaciones para manipular sus pro-
pios atributos, cumpliendo por lo tanto con una res-
ponsabilidad particular, o (2) puede colaborar con
otras clases.
Wirfs-Brock [WIR90] y sus colegas definen las cola-
boraciones de la siguiente forma:
Las colaboraciones representan solicitudes de un cliente a
un servidor en el cumplimiento de una responsabilidad del
FIGURA 21.3. Un modelo CRC de tarjeta indice. cliente. Una colaboraci6n es la realizacih de un contrato entre
el cliente y el sewidor... Decimos que un objeto colabora con
otro, si para ejecutar una responsabilidad necesita enviar cual-
Cada responsabilidad debe establecerse lo mcis gene- quier mensaje al otro objeto. Una colaboraci6n simple flu ye en
ral posible. Esta directriz implica que las responsa- una direccion, representando una solicitud del cliente a1 sewi-
bilidades generales (tanto 10s atributos como las dor. Desde el punto de vista del cliente, cada una de sus cola-
boraciones esti asociada con una responsabilidad particular
operaciones)deben residir en la parte alta de la jerar- implementada por el sewidor.
quia de clases (puesto que son gedricas, se aplica-
ran a todas las subclases). Adicionalmente, debe
usarse el polimorfismo (Capitulo 20) para definir las
operaciones que generalmente se aplica a la super-
clase, per0 que se implementan de manera diferente
en cada una de las subclases. Un objeto s e ~ d ocoloboro
r con un objetos cliente
en un esfuerzo por llevor a cobo uno determinodo
La inforrnacibn y el comportamientoasociado a ella,
responsobilidad. lo coloborocion irnplico el paso de rnensaies.
debe encontrarse dentro de la misma clase. Esto
implementa el principio 00 de encapsulamiento
(Capitulo 20). Los datos y procesos que manipulan Las colaboraciones identifican relaciones entre cla-
estos datos deben empaquetarse como una unidad ses. Cuando todo un conjunto de clases colabora para
cohesionada. satisfacer alglin requisito, es posible organizarlas en un
La informacibn sobre un elemento debe estar loca- subsistema (un elemento del disefio).
lizada dentro de una clase, no distribuida a trave's Las colaboraciones se identifican determinando si
de varias clases. Una clase simple debe asumir la una clase puede satisfacer cada responsabilidad. Si no
responsabilidad de almacenarnientoy manipulation puede, entonces necesita interactuar con otra clase. De
de un tip0 especifico de informaci6n. Esta respon- aqui surge lo que hemos llamado una colaboracion.
CAP~TULO
21 ANALISIS ORIENTADO A O B J E T O S
Como un ejemplo, considere la aplicaci6n Hogar-

seguro6.Como una parte del procedimiento de activa- iQ& enfqw efectivo
exirte para revisar un
cion (vea el caso de uso para activaci6n en la secci6n
11.2.4), el objeto panel de control debe determinar si modelo CRC?
existen sensores abiertos. Se define una responsabili-
dad llamada deterrninar-estado-del-sensor.Si hay sen- 1. A todos 10s participantes de la revisi6n (del modelo
sores abiertos, el panel de control debe poner el atributo CRC) se les da un subconjunto de las tarjetas indice
estado a1 valor <<no preparado,,. La informaci6n del sen- del modelo CRC. Las tarjetas que colaboran deben
sor puede obtenerse del objeto sensor. Por lo tanto, la estar separadas (esto es, ningun revisor debe poseer
responsabilidad deterrninar-estado-del-sensorpuede dos tarjetas que colaboren).
ejecutarse solarnente si el panel de control trabaja en 2. Todos 10s escenarios (y sus correspondientes diagra-
colaboraci6n con el sensor. rnasde casos de uso) deben organizarse en categorias.
Para ayudar en la identificacibn de colaboradores, el 3. El director de la revision lee el caso de uso con aten-
analista puede examinar tres relaciones genkricas dife- cion. Cuando el director llega a un objeto identifi-
rentes entre clases [WIR90]: ( I ) la relaci6n es-parte-de, cado, se traspasa la seiial a la persona que posee la
(2) la relaci6n tiene-conocirniento-sobre,y (3) la rela- clase tarjeta indice correspondiente. Por ejemplo, el
ci6n depende-de. A travCs de la creaci6n de un diagra- caso de uso mencionado en la Seccion 20.4.1 con-
ma de relaci6n entre clases (Seccion 2 1.4.4), el analista tiene la siguiente narraci6n:
desarrolla las conexiones necesarias para identificar estas El propietario de la casa observa el panel de control de
relaciones. Cada una de las tres relaciones genericas se HogarSeguro para determinar si el sistema esd Listo para enha-
considera brevemente en 10s parrafos siguientes. da de datos. Si el sistema no esth listo,el propiehriodebe cenar,
Todas las clases que forman parte de una clase agre- fisicamente, las ventanas y puertas para que aparezca el indi-
gada eskh conectadas a Csta a travCs de una relaci6n es- cador de <disto*.[Un indicador no listo implica que un sensor
e s d abierto, esto es que una puerta o ventana esd abierta.]
parte-de. Considere las clases definidas para el juego de
video mencionado anteriormente, la clase cuerpo-del- Cuando el director de la revision llega a1 <<panelde
jugador es-parte-de, a1 igual que cuerpo-del-jugador, control>> en la narrativa del caso de uso, se pasa la
brazos-del-jugador y cabeza-del-jugador. seiial a la persona que posee la tarjeta panel de con-
Cuando una clase debe obtener informacion sobre trol. La frase ctimplica que un sensor esti abierto,,
otra, se establece la relaci6n tiene-conocirniento-sobre. requiere que la tarjeta indice contenga una respon-
La responsabilidad deterrninar-estado-del-sensores un sabilidad que validara esta implicacion (la respon-
ejemplo de la relacion tiene-conocirniento-sobre.La sabilidad deterrninar-estado-del-sensorrealiza esta
relacion depende-de implica que dos clases poseen una accion). A1 lado de la responsabilidad en la tarjeta
dependencia no realizable a travks de tiene-conoci- indice esta el colaborador sensor. La seiial se pasa
miento-sobre o es-parte-de.Por ejemplo, la cabeza-del- entonces a1 objeto sensor.
jugador debe estar siempre conectada a1 cuerpo- 4. Cuando se pasa la seiial, se le pide a1 que posee la
del-jugador (a menos que el videojuego en particular tarjeta de la clase que describa las responsabilidades
sea muy violento), aunque cada objeto puede existir sin mencionadas en la tarjeta. El grupo determina si una
conocimiento direct0 sobre el otro. Un atributo del obje- (o mas) de las responsabilidades satisface el requi-
to cabeza-del-jugador llamado posicibn-central se sito del caso de uso.
obtiene de la posicidn-central del objeto cuerpo-del- 5. Si las responsabilidades y colaboraciones mencio-
jugador. Esta informacion se obtiene a travCs de un ter- nadas en las tarjetas indice no pueden acomodarse
cer objeto, jugador, el cual la obtiene del a1 caso de uso, se hacen modificaciones a las tarje-
cuerpo-del-jugador. Por lo tanto, la cabeza-del-juga- tas. Esto puede incluir la definicion de nuevas cla-
dor depende-de cuerpo-del-jugador. ses (y sus correspondientes tarjetas indice CRC) o la
En todos 10s casos, el nombre de la clase colaborado- especificacion de responsabilidades y colaboracio-
ra se registra en la tarjeta indice del modelo CRC a1 lado nes nuevas o revisadas en tarjetas existentes.
de la responsabilidad que ha generado dicha colabora- Este rnodus operand continlia hash terminat-el caso
cion. Por lo tanto, la tarjeta indice contiene una lista de de uso. Cuando terminan todos 10s casos de uso, conti-
responsabilidades y de colaboraciones correspondientes nua el analisis 00.
que posibilitan se realicen las responsabilidades su rea-
lizaci6n (Fig. 21.3).
Cuando se ha desarrollado un modelo CRC por com- 21.4.3. Definicidn d e estructuras y jerarquias
pleto, 10s representantes del cliente y de las organiza- Una vez que se han identificado las clases y objetos usan-
ciones de ingenieria del software pueden recorrer el do el modelo CRC, el analista cornienza a centrarse en
modelo haciendo uso del siguiente enfoque. la estructura del modelo de clases y las jerarquias resul-
Vea una explicacion de las clases de HogarSeguro en la Seccion

20.3.
~ N G E N ~ E RDEL
tantes que surgen a1 emerger clases y subclases. Usan- menta uno o mas contratos [WIR90] con sus colabo-
do la notaci6n UML podemos crear gran variedad de radores externos. Un contrato es una lista especifica
diagramas. Debe crearse una estructura de generaliza- de solicitudes que 10s colaboradores pueden hacer a
cidn-especializacidn para las clases identificadas. un subsistema'.
Para ilustrarlo considere el objeto sensor definido
para HogarSeguro y mostrado en la Figura 21.4. Aqui,
la generalizacibn, sensor, se refina en un conjunto de
especializaciones: sensor de entrada, sensor de hum0
y sensor de movimiento. Los atributos y operaciones
identificados en el sensor son heredados por las espe-
cializaciones de la clase. Hemos creado una jerarquia
de clases simple.
En otros casos, un objeto representado seg6n el
modelo inicial puede estar compuesto realmente de un Sensor
n6mero de partes las cuales pueden definirse a su vez de entrada
como objetos. Estos objetos agregados pueden repre-
sentarse como una estructura componente-agregado
[ERI97] y se definen usando la notacibn representada FIGURA 21.4.a Diagrama de clases que ilustra la relacion
en la Figura 21.5. El rombo implica una relacibn de de generalizacion-especializacion.
ensamblaje. Debe notarse que las lineas de conexi6n
pueden aumentarse con simbolos adicionales (no mos-
trados) para representar cardinalidad, que se adaptan de Panel
la notacidn del modelo entidad-relacibn descrito en el de control
Capitulo 12. -
Las representaciones estructurales proveen a1 ana-
lista de 10s medios para particionar el modelo CRC y
para representar esta partici6n grhficamente. La expan-
si6n de cada clase aporta 10s detalles necesarios para
revisidn y para el subsiguiente diseiio.
Teclado Pantalla Luz
21.4.4. Definicidn de subsistemas
Un modelo de anAisis para una aplicacion compleja pue-
de tener cientos de clases y docenas de estructuras. Por FIGURA 21.5.a Diagrama de ~ l a s e sque ilustra la relacion
esta razbn, es necesario definir una representaci6n con- de agregacion.
cisa que sea un resumen de 10s modelos CRC y estruc-
tural descritos anteriormente.
Los subsistemas pueden representarse dentro del
context0 del modelo CRC creando una tarjeta indice
4 del subsistema. La tarjeta indice del subsistema indi-
ca el nombre del subsistema, 10s contratos que debe
CLAVE
cumplir y las clases u otros subsistemas que soportan
Un subsisterno (poquete de UML) incluye uno jerorquia el contrato.
de clases rnbs detalloda.
Los paquetes son idhticos a 10s subsistemas en
intenci6n y contenido, per0 se representan grafica-
Los subconjuntos de clases que colaboran entre si mente en UML. Por ejemplo, suponga que el panel de
para llevar a cab0 un conjunto de responsabilidades control de HogarSeguro es considerablemente mas
cohesionadas, se les llama normalmente subsistemas complejo que el representado por la Figura 21.5, con-
o paquetes (en terminologia UML). Los subsistemas teniendo mliltiples monitores, una sofisticada distri-
o paquetes son abstracciones que aportan una refe- buci6n de teclas y otras caracteristicas. ~ s t pudiera
e
rencia o punter0 a 10s detalles en el modelo de anali- modelarse como una estructura todo-partes mostrada
sis. Si se observa desde el exterior, un subsistema en la Figura 21.6. Si el modelo de requisitos contu-
puede tratarse como una caja negra que contiene un viera docenas de estas estructuras (HogarSeguro no
conjunto de responsabilidades y que posee sus pro- las tendra), seria dificil absorber la representaci6n
pios colaboradores (externos). Un subsistema imple- completa de una vez. Definiendo una referencia de
' Recuerde que las clases interactuan usando una filosofia cliente/ser-
vidor. En este caso el subsistema es el sewidor y 10s colaboradores
extemos 10s clientes.
C A P ~ T U L O2 1 ANALISIS ORIENTADO A O B J E T O S
temas, como se muestra en la figura, pudiera referen- sensor (Figs. 21.5 y 21.6); para el sistema, suceso sen-
ciarse toda la estructura a travCs de un simple icono sor y alarma audible se crearh tambiCn estructuras si
(la carpeta de ficheros). Las referencias de paquetes estos objetos necesitan objetos ensamblados.
se crean generalmente para cualquier estructura que Las flechas discontinuas mostradas en la parte supe-
posea multiples objetos. rior de la Figura 2 1.7 representan relaciones de depen-
A1 nivel mhs abstracto, el modelo de A 0 0 conten- dencia entre 10s paquetes que se muestran. Sensor
drh solamente referencias de paquetes tales como las depende del estado del paquete suceso sensor. Las fle-
que se ilustran a1 inicio de la Figura 21.7. Cada una de chas continuas representan composici6n. En el ejem-
las referencias se expandirh a una estructura. Se ilus- plo, el paquete sistema esth compuesto por 10s paquetes
tran las estructuras para 10s objetos panel de control y panel de control, sensor y alarma audible.
El enfoque del modelado CRC usada en secciones ante-

riores ha establecido 10s primeros elementos de las rela- IPanel de controd /Panel de control1
ciones de clases y objetos. El primer paso en el Referencia

establecimiento de las relaciones es comprender las res-
ponsabilidades de cada clase. La tarjeta indice del mode- subsistema
lo CRC contiene una lista de responsabilidades. El
siguiente paso es definir aquellas clases colaboradoras
que ayudan en la realizaci6n de cada responsabilidad.
Esto establece la ccconexi6nu entre las clases.
Entre dos clases cualesquiera que estCn conectadas
existe una relaci6ns. Debido a esto 10s colaboradores
siempre esthn relacionados de alguna manera. El tipo de
relaci6n mhs comtin es la binaria (existe una relaci6n
entre dos clases). Cuando se analiza dentro del context0
de un sistema 00,una relaci6n binaria posee una direc-
ci6n especifica9que se define a partir de quC clase desem- FIGURA 21.6. Referencia a paquete (subsistema).
pefia el papel del cliente y cuhl actua como servidor.
Rumbaugh y sus colegas [RUM911 sugieren que las
relaciones pueden derivarse a partir del examen de 10s
verbos o frases verbales en el establecimiento del alcan- El modelo objeto-relaci6n (corno el modelo entidad-
ce o casos de uso para el sistema. Usando un anhlisis relaci6n) puede obtenerse en tres pasos o etapas:
gramatical, el analista aisla verbos que indican locali- Usando las tarjetas indice CRC,puede dibujarse una
zaciones fisicas o emplazamientos (cerca de, parte de, red de objetos colaboradores. La Figura 21.8 repre-
contenido en), comunicaciones (transmite a, obtenido senta las conexiones de clase para 10s objetos de
de),propiedad (incorporadopor, se compone de) y cum- HogarSeguro. Primero se dibujan 10s objetos conec-
plimiento de una condici6n (dirige, coordina, contro- tados por lineas sin etiquetas (no se muestran en la
la). Estos aportan una indicaci6n de la relaci6n. figura) que indican la existencia de alguna relacidn
La notacidn del lenguaje unificado de modelado para entre 10s objetos conectados. Una altemativa es mos-
el modelo objeto-relacion utiliza una simbologia adap- trar 10s nombres de 10s roles de cada clase en la rela-
tada de las tCcnicas del modelo entidad-relaci6n exami- ci6n en lugar del nombre de la relacibn. Esto se
nadas en el Capitulo 12. En esencia, 10s objetos se describe en el Capitulo 22.
conectan con otros objetos utilizando relaciones con nom- Revisando el modelo CRC de tarjetas indices, se eva-
bres. Se especifica la cardinalidad de la conexi6n (ver l h n responsabilidades y colaboradores y cada linea
capitulo 12) y se establece toda una red de relaciones. de conexibn sin etiquetar recibe un nombre. Para evi-
tar ambigiiedades, una punta de flecha indica la
ccdireccibm de la relacion (Fig. 2 1.8).
tComo se obtiene un modelo Una vez que se han establecido y nombrado las rela-
objeto-relation? ciones, se evalda cada extremopara determinar la car-
Otros terminos para relacion son asociacion [RUM911 y conexion Es importante notar que esta e s una salida de la naturaleza bidi-
[COA911. reccional de las relaciones usadas en el modelado de datos (Capi-
tulo 12).
dinalidad (Fig. 2 1.8). Existen cuatro opciones: 0 a 1,

1 a 1 , 0 a muchos, 6 1 a muchos. Por ejemplo, el sis-
tema HogarSeguro contiene un unico panel de control
I Un panel decontrol controla uno o mas sensores
y cada sensor es controlado por un panel de control
(la cardinalidad 1 lo indica). A1 menos un sensor debe

estar presente para que el panel de control lo active.
Sin embargo, varios sensores pueden estar presentes
(la relacion 1..* lo indica). Un sensor puede reconocer
1o m b sucesos de sensor (p.e.: se detecta hum0 u ocu-
rre una caida, pues el simbolo 1..* lo indica).
Evento de sensor
Un sistema esta formado por cero 6 mas alarmas audibles

y una alarrna audible esta asociada con un unico sistema
FIGURA 21.8. Relaciones entre objetos.
Los pasos anteriormente mostrados continuan hasta
Yd! & Paneldecontrol

que se produzca un modelo objeto-relacion completo.
En el desarrollo de un modelo objeto-relacion, el ana-
lista aiiade aun alguna otra dimension a1 modelo de ana-
lisis general. No solamente se identifican las relaciones
entre objetos, sino que se definen todas las vias impor-
p n ~'.\h a s
e funcib Pantalla LC Gflficos Mensajes
tantes de mensajes (Capitulo 20). En nuestra descrip-
cion de la Figura 21.7, hicimos referencia a las flechas
que conectan simbolos de paquetes. TambiCn son vias
de mensajes. Cada flecha implica el intercambio de men-
FIGURA 21.7. Modelo de analisis con referencias a paquetes. sajes entre subsistemas en el modelo.
El modelo CRC y el de objeto-relacion representan ele- 5. Revisar el modelo objeto-comportamientopara veri-

mentos estiticos del modelo de anflisis 00.Ahora es el ficar exactitud y consistencia.
momento para hacer una transicion al comportamiento Cada uno de estos pasos se discute en las secciones
d i n h i c o del sistema o product0 00.Para ejecutar este siguientes.
paso debemos representar el comportarniento del siste-
ma como una funci6n de sucesos especificos y tiempo.
21.6.1. Identificacibn de sucesos con casos de uso
~ C W I S~OI Slos PSOS Como vimos en la Secci6n 21.4.1, el caso de uso
a seguir para construir un representa una secuencia de actividades que incluyen
modeb objptos-comportamiento? a actores y a1 sistema. En general, un suceso ocurre
cada vez que un sistema 00 y un actor (recuerde que
El modelo objeto-comportamientoindica c6mo res- un actor puede ser una persona, un dispositivo o inclu-
ponder5 un sistema 00 a sucesos extemos o estimulos. so un sistema externo) intercambian informacion.
Para crear el modelo, el analista debe ejecutar 10s Recordando la explication dada en el Capitulo 12, es
siguientes pasos: importante recordar que un suceso es Booleano. Esto
Evaluar todos 10s casos de uso (Secci6n 21.4.1 ) para es, un suceso no es la informacion que se intercam-
comprender totalmente la secuencia de interaction bia, es el hecho de que la informacih ha sido inter-
dentro del sistema. cambiada.
Identificar sucesos que dirigen la secuencia de inter- Un caso de uso se examina por puntos de intercam-
acci6n y comprender c6mo estos sucesos se relacionan bio de informacion. Para ilustrarlo, reconsidere el caso
con objetos especificos. de uso descrito en la Secci6n 11.2.4:
Crear una traza de sucesos [RUM9 11 para cada caso 1. E l propietario observa el Dane1de control de HoaarSeauro
(Figura 11.2) para determinar si el sistema esd listo para
de uso. recibir datos. Si el sistema no esd listo, el propietario debe
Construir un diagrama de transicion de estados para cerrar fisicarnente ventanas y puertas de tal manera que el
el sistema. indicador de disponibilidad estt presente. [Un indicador de
C A P ~ T U L O21 ANALISIS ORIENTADO A O B J E T O S
no preparado implica que el sensor esth abierto, por ejem- agregado jugador (en la aplicacion del videojuego exa-
plo, que m a puerta o ventana esth abierta.] minado anteriormente) incluira posicion y orientacion
2. El propietario usa el teclado para teclear una contraseiia de actual del jugador (atributos del objeto) asi como otras
cuatro digitos. La contraseiia se compara con la contraseiia caracteristicas de jugador que son relevantes a1 juego
valida almacenada en el sistema. Si la contraseiia es inco-
rrecta, el panel de control avisari una vez y se restaurara
(p.e.: un atributo que indique permanecen deseos mhgi-
por si mismo para recibir datos adicionales. Si la contrase- cos). El estado activo de un objeto indica el estado actual
iia es correcta, el panel de control espera por las acciones cuando Cste entra en una transformaci6n continua o pro-
siguientes. ceso. El objeto jugador poseera 10s siguientes estados
3. El propietario selecciona y teclea perrnanecer o continuar activos: en movimiento, en descanso, lesionado, en recu-
para activar el sistema. Permanecer activa solarnente10s sen- peracidn, atrapado, perdido entre otros. Para forzar la
sores del perimetro (10s sensores internos detectores de movi- transici6n de un objeto de un estado activo a otro debe
miento e s t h desactivados). Continuar activa todos 10s ocurrir un suceso (a veces, llamado disparador). Un com-
sensores.
ponente de un modelo objeto-comportamiento es una
4. Cuando ocurre la activacih, el propietario puede observar representacih simple de 10s estados activos de cada obje-
una luz roia de alarma.
to y 10s sucesos (disparadores) que producen 10s cambios
Las partes de texto subrayadas anteriormente indican entre estos estados activos. La Figura 21.9 ilustra una
sucesos. Debera identificarse un actor para cada suceso: representacibn simple de 10s estados activos para el obje-
la informaci6n que se intercambia debe anotarse. y debe- to panel de control en el sistema HogarSeguro.
rfin indicarse otras condiciones o restricciones.
Como ejemplo de un suceso tipico, considere la fra-
se subrayada del caso de uso propietario usa el teclado
para teclear una contrasefia de cuatro digitos. En el con- Cuondo se empiezon o identifcor estodos, lo otencibn
texto del modelo de analisis 00 el actor propietario se centro en 10s modos de romportomientoobse~obles
transmite un suceso a1 objeto panel de control. desde el exterior. Mbs torde, se pueden refinor estos
El suceso puede llamarse contrasefia introducida. estodos en comportomientosno evidentes cuondo
La informaci6n transferida son 10s cuatro digitos que se obse~oel sistemo desde el exterior.
forman la contraseiia, per0 Csta no es una parte esencial
del modelo de comportamiento. Es importante notar que Cada flecha en la Figura 2 1.9 representa una transi-
algunos sucesos tienen un impacto explicito en el flujo ci6n de un estado activo del objeto a otro. Las etique-
de control del caso de uso, mientras que otros no impac- tas mostradas en cada flecha representan 10s sucesos
tan directamente en este flujo de control. Por ejemplo. que disparan la transici6n. Aunque el modelo de esta-
el suceso contrasefia introducida no cambia explicita- do activo aporta una visi6n intema muy util de la <<his-
mente el flujo de control del caso de uso, per0 10s resul- toria de vidan de un objeto, es posible especificar
tados del suceso comparar contrasefia (derivada de la informaci6n adicional para aportar mas profundidad en
interacci6n contrasefia se compara con la contraseiia la comprensi6n del comportamiento de un objeto. Adi-
valida almacenada en el sistema) tendra un impacto cionalmente a especificar el suceso que provoca la ocu-
explicito en la informaci6n y flujo de control del soft- rrencia de la transicibn, el analisis puede tambiCn
ware HogarSeguro. especificar una guarda y una acci6n [CHAR93]. Una
Una vez que todos 10s sucesos han sido identifica- guarda es una condici6n Booleana, que debe satisfa-
dos, se asocian a 10s objetos incluidos. Los actores (enti- cerse para posibilitar la ocurrencia de una transici6n.
dades extemas) y objetos pueden responsabilizarse de Por ejemplo, la condici6n de guarda para la transici6n
la generaci6n de sucesos (p.e.: propietario genera el desde el estado <<endescanson a1 de <<cornparandonen
suceso contrasefia introducida) o reconociendo suce- la Figura 20.9 puede determinarse a travCs del examen
sos que han ocumdo en otra parte (p.e.: el panel de con- del caso de uso:
trol reconoce el resultado binario del suceso comparar if (entrada de contraseiia = 4 digitos)
contrasefia). then ejecutar transici6n al estado comparando;
En general, la guarda de una transici6n depende

21.6.2. Representaciones de estados
usualmente del valor de uno o mas atributos de un obje-
En el context0 de sistemas 00 deben considerarse dos to. En otras palabras, la condici6n de guarda depende
caracterizaciones de estados: (1) el estado de cada obje- del estado pasivo del objeto.
to cuando el sistema ejecuta su funcibn, y (2) el estado Una accibn ocurre concurrentemente con la transici6n
del sistema observado desde el exterior cuando Cste eje- o como una consecuenciade ella y generalmenteimplica
cuta su funci6n. una o m h operaciones (responsabilidades) del objeto. Por
El estado de un objeto adquiere en arnbos casos carac- ejemplo, la acci6n conectada con el suceso contraseiia
teristicas pasivas y activas [CHAR93]. Un estado pasi- introducida (Fig. 2 1.9) es una operaci6n que accede a un
vo es simplemente el estado actual de todos 10s atributos objeto contrasefia y realiza una comparaci6n digito a digi-
de un objeto. Por ejemplo, el estado pasivo del objeto to para validar la contrasefia introducida.
La Figura 21.10 ilustra una traza parcial de sucesos para

Cornparar contraseha
[contraseria incorrectal el sistema HogarSeguro. Cada una de las flechas repre-
senta un suceso (derivado de un caso de uso) e indica c6mo
el suceso sintoniza su comportarniento entre 10s objetos
reposo
Se introduce
lacontrase~a
*(Cornparando
-J [cont;aseria incorrecta] de HogarSeguro. El primer suceso, sistema listo, se deri-
va del entomo exterior y sintoniza el comportamiento al
Comgarar contraseria propietario. El propietario teclea una contrasefia. El suce-
I [coniiaseria correctal
so inicia aviso y aviso sonoro indican c6mo se canaliza el
Activacion comportamiento si la contraseiia no es valida. Una con-
correcta
traseiia v%da provoca un retomo al propietario. Los suce-
FIGURA 21.9. Representacion de la transicion de estados. sos restantes y sus trazas siguen el comportamiento como
cuando se activa o desactiva el sistema.
El segundo tipo de representaci6n de comportamiento UML utiliza diagramas de estado, de secuencia, de
para el A 0 0 considera una representaci6n de estados colaboraci6n y de actividades para representar el com-
para el product0 general o sistema. Esta representaci6n portamiento dinamico de 10s objetos y las clases iden-
abarca un modelo simple de traza de sucesos [RUM9 11 tificadas como parte del modelo del analisis.
que indica c6mo 10s sucesos causan las transiciones de
objeto a objeto y un diagrama de transicidn de estados
que ilustra el comportamiento de cada objeto durante el
procesamiento. Sistema- lntroducir
Una vez que han sido identificados 10s sucesos para
listo 1 contrasetia 1
lniciar sonido
un caso de uso, el analista crea una representacibn
acerca de c6mo 10s sucesos provocan el flujo desde
un objeto a otro. Esta representacibn, llamada traza
J+, act~vac~onldesact~vac~on
, Preparado para , PSonidoi
I Y
de sucesos o de sucesos, es una versi6n abreviada del

Activarldesactivar '
caso de uso que representa objetos clave y 10s suce- sensores *i
sos que provocan el comportamiento de pasar de obje- Sensores
to a objeto. i4 activadosldesactivados i
I Peticion de luz roja
' Luz roja encendida a
Preparado para
Uno tronsicibn de un estado o otro requiere un suceso que
lo produzca. 10s sucesos son booleonos por noiuroleza yo
menudo ocurren cuondo un objeto se comunico con otro. FIGURA 21.10. Traza de sucesos parcial para el sistema
HogarSeguro.
Los mCtodos de A 0 0 permiten a un ingeniero del soft- 10s requisitos especificados por el cliente tal y como
ware modelar un problema representando las caracte- Cstos afectan a la aplicaci6n a construir.
risticas tanto dinamicas como estaticas de las clases y El proceso de A 0 0 comienza con la definici6n de
sus relaciones como componentes principales del mode- casos de uso (escenarios que describen c6mo se va a
lado. Como 10s mCtodos precedentes, el lenguaje unifi- utilizar el sistema). La tkcnica de modelado de clases-
cad0 de modelado UML construye un modelo de analisis responsabilidades-colaboraciones(CRC) se aplica para
con las siguientes caractensticas: (I) representacidn de documentar las clases y sus atributos y operaciones.
las clases y jerarquias de clases, (2) creacidn de mode- TambiCn proporciona una vista inicial de las colabora-
10s objeto-relacibn, y (3) obtencidn de modelos objeto- ciones que ocurren entre 10s objetos. El siguiente paso
comportamiento. en el A 0 0 es la clasificaci6n de objetos y la creaci6n
El andisis de sistemas orientados a objetos se reali- de una jerarquia de clases. Los sistemas (paquetes) se
za a muchos niveles diferentes de abstracci6n. En 10s pueden utilizar para encapsular objetos relacionados.
niveles de empresa o de negocio las tkcnicas asociadas El modelo objeto-relaci6n proporciona informaci6n
con el analisis se pueden conjugar con el enfoque de sobre las conexiones entre las clases, mientras que el
ingenieria del proceso de negocio. A estas tCcnicas a modelo objeto-comportamiento representa el compor-
menudo se las llama de andisis del dominio. En el nivel tamiento de 10s objetos individualmente y el global de
de implementaci6n el modelo de objetos se centra en todo el sistema.
CAPfTULO 21 ANALISIS O R I E N T A D O A O B J E T O S
[ALH98] Alhir, S.S., UML in a Nutshell, O'Reilly & Asso- [FIC92] Fichman, R.G., y Kemerer, C.F., Object-Oriented
ciates, Inc. 1998. and Conventional Analysis and Design Methodologies,
[AMB95] Ambler, S., <<UsingUse-Cases,,, Software Deve- Computer, vol. 25, n." 10, Octubre 1992, pp. 22-39.
lopment, Julio 1995, pp. 53-61 [FIN961 Fingar, P., The Blueprintfor Business Objects, Cam-
[ARA89] Arango, G., y Prieto-Diaz, R., <<DomainAnalysis: bridge University Press, 1996.
Concepts and Research Directions,,, Domain Analysis: [FIR931 Firesmith, D.G., Object Oriented Requeriments
Acquisition of Reusable Information for Software Cons- Analysis and Logical Design, Wiley, 1993.
truction (G. Arango y Prieto-Diaz, eds.), IEEE Computer
Society Press, 1989. [JAC92] Jacobson, I., Object-Oriented Software Engineering,
Addison-Wesley, 1992.
[BER93] Berard, E.V., Essays on Object-Oriented Software
Engineering, Addison-Wesley, 1993. [JAC99] Jacobson, I., Booch, G., y Rumbaugh, J., Unified
Software Development Process, Addison-Wesley, 1999.
[BEN991 Beneth, S., S. McRobb y R. Farmer, Object-Orien-
ted System Analysis and Design Usign UNL, McGraw- [MAT941 Mattison, R., The Object-Oriented Enterprise,
Hill, 1999. McGraw Hill, 1994.
[BOO941 Booch, G., Object-Oriented Analysis and Design, [MON92] Monarchi, D.E., y Puhr, G.I., <<AResearch Typo-
2.%d., Benjamin Cummings, 1994. logy for Object-Oriented Analysis and Design,,, CACM,
[BOO991 Booch, G., Jacobson, I., y Rumbaugh, J., The Unified vol. 35, n." 9, Septiembre 1992, pp. 35-47.
Modeling Language User Guide, Addison-Wesley, 1999. [RUM911 Rumbaugh, J., et al., Object Oriented Modelling
[CAR981 Carmichael,A., Developing Business Objects, SIGS and Design, Prentice-Hall, 1991.
Books, 1998. [RUM991 Rumbaugh, J., Jacobson, I., y Booch, G., The Uni-
[CHA93] de Champeaux, D., D. Lea, y P. Faure, Object- fied Modelling Language Reference Manual, Addison-
Oriented System Development, Addison-Wesley, 1993. Wesley, 1999.
[COA91] Coad, P., y E. Yourdon, Object-OrientedAnalysis, [SUL94] Sullo, G.C., Object Engineering, Wiley, 1994.
2.%d., PrenticeHall, 1991 [TAY95] Taylor, D.A., Business Engineering with Object
[EEL981 Eeles, P,. y Simms, O., Building Business Objects, Technology, Wiley, 1995.
Wiley, 1998. [WIR90] Wirfs-Brock, R., Wikerson, B., y Weiner, L., Desig-
[EX1981 Eriksson, H.E., y Penker, M., UML Toolkit,Wdey, 1998. ning Object Oriented Software, Prentice-Hall, 1990.
21.1. Higase con uno o mis libros sobre UML y compirelo 21.5. Escriba un caso de uso para el sistema HogarSeguro. Los
con el andisis estructurado (Capitulo 12) utilizando las dimen- casos de uso deben tratar el escenario requerido para establecer
siones de modelado propuestas por Fichman y Kemerer una zona de seguridad. Una zona de seguridad lleva asociado un
[FIC92] en la Secci6n 2 1.1.1. conjunto de sensores que pueden ser accedidos, activados y desac-
tivados no individualrnente sino en conjunto. Debe ser posible
21.2. Desarrolle una clase-presentacion sobre un diagrama definir hasta diez zonas de seguridad. Sea creativo, pero intente
estitico o dinimico de UML. Presente el diagrama en el con- mantenerse dentro de lo definido para el panel de control del sis-
texto de un ejemplo sencillo, per0 intente mostrar el suficien- tema tal y como fue definido previamente en este libro.
te nivel de detalle como para demostrar 10s aspectos mis
importantes del t i p de diagrama elegido. 21.6. Desarrolle un conjunto de casos de uso para el sistema
SSRB del Problema 12.13.
213. Conduzca un andisis del dorninio para una de las siguien-
tes ireas: Tendri que hacer varias suposiciones sobre la forma de
interaccion del usuario con el sistema.
a) Un sistema para almacenar 10s expedientes de 10s alumnos
de una universidad. 21.7. Desarrolle un conjunto de casos de uso para alguna de
las siguientes aplicaciones:
b) Una aplicacion de comercio electronic0 (p.e. ropa, libros,
a) Software para un asistente personal electronic0 de propo-
equipos electr6nicos, etc.)
sito general.
c) Un servicio a1 cliente para un banco. b) Software para un videojuego de su election.
d) El desarrollo de un videojuego. c) Software para el sistema de climatizaci6n de un auto-
e) Un irea de aplicacion propuesta por su instructor. m6vil.
21.4. Describa con sus propias palabras la diferencia entre las d) Software para un sistema de navegacion de un automovil.
vistas est5tica y dinimica de un sistema. e) Un sistema propuesto por su instructor.
Lleve a cabo una pequeiia investigation (mas pocas horas) en 21.13. Desarrolle un modelo objeto-comportamiento para el
. el dominio de la aplicacion y conduzca una reunion TFEA producto o sistema elegido en el problema 21.7. Asegurese de
(Capitulo 11) con sus compaiieros para desarrollar unos requi- listar todos 10s sucesos, proporcionar la traza de sucesos, desa-
sitos bisicos (su instructor le ayudara a coordinarlo). rrollar un diagrama de flujo de sucesos y definir diagramas de
21.8. Desarrolle un conjunto completo de tarjetas CRC del estado para cada clase.
producto o sistema elegido en el problema anterior.
21.14. Describa con sus propias palabras la forma de deter-
21.9. Dirija una revision de las tarjetas CRC con sus colegas.
~ C u h t a clases,
s responsabilidades y colaboraciones adicio- minx 10s colaboradores de una clase.
nales ha aiiadido a consecuencia de la reunion? 21.15. ~ Q u C
estrategia propondria para definir subsisternasen
21.10. Desarrolle una jerarquia de clases para el producto o colecciones de clases?
sistema elegido en el Problema 21.7.
21.16. ~ Q u C
papel desempefia la cardinalidad en el desarrollo
21.11. Desarrolle un conjunto de subsistemas (paquetes) para
de un modelo objeto-relacion?
el producto o sistema elegido en el Problema 21.7.
21.12. Desarrolle un modelo objeto-relacion para el producto 21.17. iCu51 es la diferencia entre 10s estados pasivo y activo
o sistema elegido en el Problema 21.7. de un objeto?
Los casos de uso forman la base del aniiisis orientado a obje- Douglas, B., Real-Time UML: Developing EfSlcient Objects
tos, sin importar el mCtodo de A 0 0 elegido. Los libros de for Embedded Systems, Addison-Wesley, 1999.
Rosemberg y Scott (Use case driven Object modelling with Fowler, M., y Kendall Scott, UML Distilled, 2." ed., Addison-
UML: a practical approach, Addison-Wesley, 1999), Schnei- Wesley, 2000.
der, vinters y Jacobson (Applying Use Cases: A Practical Gui-
de, Addison-Wesley, 1999), y Texel y Williams (Use Cases Larman, C., Applying UML and Patterns: an Introduction to
Combined WithBoocWOMTIUML: Process and Products, Pren- Object Oriented Analysis, Prentice-Hall, 1997.
tice-Hall, 1997) proporciona una guia para la creacidn y uso Odell, J.J., y Fowler, M., Advanced Object Oriented Analy-
de esta importante herramienta de obtencion de requisitos y sis and Design Using UML, SIGS Books, 1998.
mecanismo de representacion. Ostereich, B., Developing SofhYare with UML: Object Orien-
Casi todos 10s libros publicados recientemente sobre ana- ted Analysis and Design in Practice, Addison-Wesley, 1999.
lisis y diseiio orientado a objetos ponderan UML. Todos 10s
que e s t h considerando en serio aplicar UML en su trabajo, Page-Jones, M., Fundamentals of Object-Oriented Design in
deberian comprar [B0099], [JAC99] y [RUM99]. Ademas UML, Addison-Wesley, 1999.
Stevens, P., y Pooley, R., Software Engineering with
de estos, 10s siguientes libros tambiCn son representativos de
Objects and Components, Addison-Wesley, 1999.
las docenas de ellos escritos sobre la tecnologia de UML:
En Internet hay gran cantidad de fuentes de informaci6n sobre
Douglas, B., y Booch, G., Doing Hard Time:Developing Real- andisis orientado a objetos y temas relacionados. Una lista actua-
Time Systems with UML, Objects, Frameworks and Pat- lizada sobre las referencias web relevantes de cara a1 analisis
terns, Addison-Wesley, 1999. orientado a objetos la encontm-5en http://www.pressman5.com
el principio, pero muchas otras pueden nenfes: la intetfaz de usucnia, la gestidn
ser reutilizadas, si se reconocen los de datos y 10s mecanisma da adminis-
palroues d e diseiio apropiados. El DOO ----- rle
tmrihn -- f.-m
- ~- --,-.-- -se
----- -- nhietnn
Elrdiseiinde -
especificacion de subsistemas que rea- establece un cmteproyectode disefio,que centra en 10s detalles intemos de cada
limn funciones necesarias y proveen pelmite a1 ingeniero de software definir clase, definici6n de atributos, operacie
soporte de infraestmctura, una descrip
.. . .. . , . . . .. la orquitectura 00, en iorma que maxi-
mice la reuumcmn: de esta manera, se ,
,
,
nes y detalles de 10s mensajes.
.&An , ,< , -
--I d . 4- u r l - * Cll.^-l-
, ,, ,
mejora la velocidad del desarrollo y la lo de diseiio 00ubarcu arquitedum de
calidad del producto terminado. software, descripcidn de la interfa de
~ e s s o n l o 6 ~ E l D O O s e d i v i d e usuario, componentes de gestidn de
yan entre las capas, subsistemas y en dos grandes actividades: dise60 del datcs, meccmismos de administracih de
objetos. El Diseiio Orientado a Objet- sistema y diseilo de objetos. El diseiio de tareasy desaipcianes detalladasde d a
(DOO), cumple todos estos requisitoa. sistema crea la arquitectura del pr& una de l a clases usadas en el sistema.
ingeniero d e software.
-
'or qnd es importante? Un sistema
-&e.=+-A- ~ h k . b - - .nb:l<-- 1-e .-la&-:&-
En el Capitulo 13 se introdujo el concept0 de una pirh- f o m a 10s cimientos sobre 10s que la pirhmide se sostie-
mide de disefio para el software convencional. Cuatro ne. La capa fundamental se centra en el disefio de 10s ohje-
capas de disefio -dates, arquitectura, interfaz y nivel tos del dvminio (Ilamadosputrorzes de diseiio). Los objetos
de componentes- fueron definidas y discutidas. Para del dominio juegan un papel clave, en la construcci6n de
sistemas orientados a objetos, podemos tambiCn definir la infraestructura del sistema 00 aportando soporte para
una pirimide, pero las capas son un poco diferentes. las actividades de interfaz hombre/miquina, administra-
RefiriCndose a la Figura 22.1, las cuatro capas de la pira- ci6n (gesti6n) de t a m s y gesti6n (administracibn)de datos.
mide de disefio 00 son: Los objetos del dominio se pueden usar, ademgs, para
La capa subsistema. Contiene una representaci6n desarrollar el disefio de la aplicaci6n en si misma.
de cada uno de 10s subsistemas, para permitir a1 soft-
ware conseguir sus requisites definidos por el cliente e 22.1.1. Enfoque convencional vs. 00
implementar la infraestructura que soporte 10s requeri- Los enfoques convencionales para el disefio de software
mientos del cliente. aplican distintas notaciones y conjunto de heuristicas,
para trazar el modelo de andisis en un modelo de dise-
fio. Recordando la Figura 13.1, cada elemento del mode-
lo convencional de analisis se corresponde con uno o
m6s capas del modelo de disefio. A1 igual que el dise-
iio convencional de software, el D O 0 aplica el disefio
de datos cuando 10s atributos son representados, el di-
La capa de clases y objetos. Contiene la jerarquia sefio de interfaz cuando se desarrolla un modelo de
de clases, que permiten al sistema ser creado usando mensajeria, y disefio a nivel de componentes (procedi-
generalizaciones y cada vez especializaciones m6s acer- mental), para operaciones de diseiio. Es importante notar
tadas. Esta capa tambiCn contiene representaciones. que la arquitectura de un disefio 00 tiene mLs que ver
La capa de mensajes. Contiene detalles de diseiio, con la colaboraci6n entre objetos que con el control de
que permite a cada objeto comunicarse con sus colabo- flujo entre componentes del sistema.
radores. Esta capa establece interfaces externas e inter- A pesar de que existen similitudes entre 10s disefios
nas para el sistema. convencionales y 00, se ha optado por renombrar las
La capa de responsabilidades. Contiene estructu- capas de la pirhmide de disefio, para reflejar con mayor
ras de datos y diseiios algoritmicos, para todos 10s atri- precisi6n la naturaleza de un disefio 00. La Figura 22.2
butos y operaciones de cada objeto. ilustra la relaci6n entre el modelo de analisis 00 (Capi-
tulo 2 1) y el modelo de disefio que se derivara de ah?.
Disefio
de mensajes
Disefto de clases y objetos
D i s e f i ~ aubislstemae
FIGURA 22.1. La piramide del Diseiio 00.
La pirzlmide de disefio se centra exclusivamente en el

disefio de un product0 o sistema especifico. Observe, sin FIGURA 22.2. Transforrnacion de un rnodelo de analisis 00
embargo, que existe otra capa de disefio, y que esta capa a un modelo de diseiio 00.
Es importante hacer notar q u e la derivacion n o e s siempre

evidente. Para prorundizar vkase [DAV95].
CAP~TULO
22 DISENO ORIENTADO A OBJETOS
El diseiio de subsistemas se deriva considerando 10s continuidad: la habilidad para hacer pequeiios cam-
requerimientos globales del cliente (representados por bios en un programa y que se revelen haciendo 10s
10s casos de uso) y 10s sucesos y estados que son exter- cambios pertinentes en uno o muy pocos m6dulos.
namente observables (el modelo de comportamiento de proteccidn: una caracteristica arquitectbnica, que
objetos). El diseiio de clases y objetos es trazado de la reduce la propagacidn de efectos colaterales, si ocu-
descripci6n de atributos, operaciones y colaboraciones rre un error en un mddulo dado.
contenidas en el modelo CRC. El diseiio de mensajes es
manejado por el modelo objeto-relacibn, y el diseiio de
responsabilidades es derivado del uso de atributos, ope-
raciones y colaboraciones descrito en el modelo CRC.
Fichman y Kemerer [FIC92] sugieren diez compo- Una referenda que responde a la preguntu iqu6 hace
nentes de diseiio modelado, que pueden usarse para com- que uo diseiio orientudo a obietos seo bueno?, puede
parar varios mCtodos convencionales y orientados a encontrarse en: www.linetica.com/ootips/ood-
objetos: principles.html
1. representach de la jerarquia de mbdulos.
2. especificacidn de las definiciones de datos. De estos criterios, Meyer [MEY90], sugiere cinco
3. especificaci6n de la 16gicaprocedimental. principios basicos de diseiio, que pueden ser deducidos
para arquitecturas modulares: (1) unidades linguisticas
4. indicaci6n de secuencias de proceso final-a-final modulares, (2) pocas interfaces, (3) pequeiias interfa-
(end-to-end) ces (acoplamiento dCbil), (4) interfaces explicitas y (5)
5. representaci6n de estados y transiciones de 10s ocultaci6n de informacidn.
objetos.
6. definition de clases y jerarquias.
7. asignacion de operaciones a las clases.
8. definici6n detallada de operaciones.
e iQue principios basicos
nos guian en el diseiio
de arquitecturas modulares?
9. especificaci6n de conexiones de mensajes.
10. identificacibn de semicios exclusivos. Los m6dulos se definen como unidades linguisticas
modulares, cuando cccorresponden a unidades sintacti-
e iQu6 criterio se puede usar

para comparar 10s mitodos
convencionales y 10s metodos
cas en el lenguaje usado>>[MEY90]. Es decir, el len-
guaje de programacidn que se usara debe ser capaz de
definir directamente la modularidad. Por ejemplo, si el
de DOO? diseiiador crea una subrutina, cualquiera de 10s lengua-
jes de programaci6n antiguos (FORTRAN, C, Pascal),
Ya que existen muchos enfoques de disefio conven- debe poder implementarlos como una unidad sintiicti-
cionales y orientados a objetos, es dificil desarrollar una ca. Pero si un paquete que contiene estructuras de datos
comparaci6n generalizada entre 10s dos mCtodos. Sin y procedimientos, y 10s identifica como una sola uni-
embargo, se puede asegurar que las componentes de dad definida, en un lenguaje como Ada (u otro lengua-
modelado 5 a1 10 no estan soportadas usando diseiio je orientado a objetos), sera necesario representar
estructurado (Capitulo 14) o sus derivados. directamente este tip0 de componente en la sintaxis del
lenguaje.
22.1.2. Aspectos del diseiio Para lograr el bajo acoplamiento (un concept0 de
diseiio introducido en el Capitulo 13), el numero de
Bertrand Meyer [MEY90] sugiere cinco criterios para
interfaces entre m6dulos debe minimizarse (ccpocas
juzgar la capacidad de mCtodos de diseiio para conse-
interfaces,), y la cantidad de informaci6n que se mue-
guir modularidad, y 10s relaciona a1 diseiio orientado a
ve a travCs de la interfaz tambiCn debe ser minimizada
objetos:
(ccpequeiias interfaces>>).Siempre que 10s componentes
descomponibilidad: la facilidad con que un mCtodo se comunican, deben hacerlo de manera obvia y direc-
de diseiio ayuda a1 diseiiador a descomponer un pro- ta (ccinterfaces explicitas>>).Por ejemplo, si el compo-
blema grande en problemas mas pequeiios, haciCn- nente X y el componente Y se comunican mediante el
dolos mas facil de resolver. area de datos global (a lo que se llama acoplamiento
componibilidad: el grado con el que un mCtodo de comun en el Capitulo 13), violan el principio de inter-
disefio asegura que 10s componentes del programa faces explicitas porque la comunicaci6n entre compo-
(mbdulos), una vez diseiiados y construidos, pueden nentes no es obvia a un obsemador extemo. Finalrnente,
ser reutilizados para crear otros sistemas. se logra el principio de ocultamiento de informaci6n,
comprensibilidad: la facilidad con la que el compo- cuando toda informacibn acerca de un componente se
nente de un programa puede ser entendido, sin hacer oculta a1 acceso extemo, a menos que esa informaci6n
referencia a otra informacidn o mddulos. sea especificamente definida como publica.
Los criterios y principios de diseiio presentados en tos enfatiza el esquema detallado de un objeto indivi-
esta secci6n pueden ser aplicados a cualquier mCtodo dual. Se seleccionan las operaciones del modelo de
de diseiio (asi como a1 diseiio estmcturado). Como se anilisis, y 10s algoritmos se definen para cada opera-
ver5, el mCtodo de diseiio orientado a objetos logra cada ci6n. Se representan las estructuras de datos apropia-
uno de 10s criterios mis eficientemente que otros enfo- das para atributos y algoritmos. Las clases y atributos
ques, y resulta en arquitecturas modulares, que cumplen de clase son diseiiados de manera que se optimice el
efectivarnente cada uno de 10s criterios. acceso a 10s datos, y se mejore la eficiencia computa-
cional. Se crea un modelo de mensajeria, para imple-
22.1.3. El Panorama de D O 0 mentar relaciones de objetos (asociaciones).
Como se vio en el Capitulo 21, una gran variedad de El metodo de Jacobson. El diseiio para ISOO
mCtodos de analisis y diseiio orientados a objetos fue (Ingenieria del software orientada a objetos) [JAC92]
propuesta y utilizada durante 10s ochenta y 10s noven- es una versi6n simplificada del mCtodo propietario
ta. Estos metodos establecieron 10s fundamentos para Objectory, tambiCn desarrollado por Jacobson. El
la notaci6n moderna de DOO, heuristicas de diseiio y modelo de diseiio enfatiza la planificacion para el
modeios. A continuaci6n, haremos una breve revisi6n modelo de anilisis ISOO. En principio, el modelo
global de 10s primeros mCtodos de DOO: idealizado de anilisis se adapta para acoplarse a1
ambiente del mundo real. DespuCs 10s objetos de
El metodo de Booch. Como se vio en el Capitulo diseiio primarios, llamados bloquesz, son creados y
21, el metodo Booch [BOO941 abarca un ccproceso de catalogados como bloques de interfaz, bloques de enti-
micro desarrollo>> y un ccproceso de macro desarrollon. dades y bloques de control. La comunicaci6n entre
En el context0 del diseiio, el macro desarrollo engloba bloques durante la ejecuci6n se define y 10s bloques
una actividad de planificaci6n arquitect6nica,que agrupa se organizan en subsistemas.
objetos similares en particiones arquitectonicas separa-
das, capas de objetos por nivel de abstracci6n, identi- El metodo de Coad y Yourdon. ~ s t metodo e para
fica situaciones relevantes, crea un prototipo de diseiio DO0 [COA911, se desarrollo estudiando ccc6mo es que
y valida el prototipo aplicA.ndolo a situaciones de uso. 10s diseiiadores orientados a objetos efectivos,, hacen
El micro desarrollo define un conjunto de <<reglam que su trabajo. La aproximaci6n de diseiio dirige no s610 la
regulan el uso de operaciones y atributos y las politicas aplicaci6n, sino tambiCn la infraestmctura de la aplica-
del dominio especifico para la administraci6n de la c i h , y se enfoca en la representacibn de cuatro com-
memoria, manejo de errores y otras funciones; desa- ponentes mayores de sistemas: la componente de
rrolla situaciones que describen la semintica de las dominio del problema, la componente de interacci6n
reglas y politicas; crea un prototipo para cada politica; humana, la componente de administraci6n de tareas y
instrumenta y refina el prototipo; y revisa cada politica la de administraci6n de datos.
para asi dransmitir su visi6n arquitect6nican [B0094]. El metodo de Wirfs-Brock. Wirfs-Brock, Wilker-
son y Weiner [WIR90] definen un conjunto de tareas
tknicas, en la cual el anilisis conduce sin duda a1 diseiio.
Los protocolos3 para cada clase se construyen refinando
contratos entre objetos. Cada operaci6n (responsabili-
dad) y protocolo (diseiio de interfaz) se diseiia hasta un
nivel de detalle que guiari la implementaci6n. Se desa-
rrollan las especificaciones para cada clase (definir res-
ponsabilidades privadas y detalles de operaciones) y
El metodo de Rumbaugh. La tCcnica de modelado cada subsistema (identificar las clases encapsuladas y
de objetos (TMO) [RUM911 engloba una actividad de la interaction entre subsistemas).
diseiio que alienta ai diseiio a ser conducido a dos dife-
rentes niveles de abstracci6n. El diseiio de sistema se
centra en el esquema de 10s componentes que se nece-
Aunque no es ton mbusto como UML, el mbtodo Wih-
sitan para constmir un sistema o product0 completo. Brock fiene uno elegonciosencillo, 9ue lo convierte
El modelo de andisis se divide en subsistemas, 10s en un enfogue ohernativo e interewnte ol D00.
cuales se asignan a procesadores y tareas. Se define
una estrategia para implementar la administraci6n de A pesar de que la terminologia y etapas de proceso
datos, y se identifican 10s recursos y mecanismos de para cada uno de estos rnCtodos de DO0 difieren, 10s
control requeridos para accesarlos. El diseiio de obje- procesos de DO0 global son bastante consistentes.
* Un bloque es la abstraccion de disefio, que permite la representa- W n protocolo es una descripcion formal de 10s mensajes, a 10s que
cion de un objeto agregado. la clase responde.
C A P ~ T U L O2 2 DISENO O R I E N T A D O A O B J E T O S
Para llevar a cab0 un disefio orientado a objetos, un Estas proporcionaron una vision intema a1 uso de las
ingeniero de software debe ejecutar las siguientes eta- situaciones para el sistema (facilitando guias para el
pas generales: modelado de comportamiento), y establecieron funda-
Describir cada subsistema y asignar a procesadores mentos para la implementacion y vistas del modelo
y tareas. ambiental, identificando y describiendo elementos
estructurales estaticos del sistema.
Elegir una estrategia para implementar la adminis-
UML se organiza en dos actividades mayores:
traci6n de datos, soporte de interfaz y administracion
disefio del sistema y disefio de objetos. El principal
de tareas.
objetivo de UML, disefio de sistema, es representar
Disefiar un mecanismo de control, para el sistema la arquitectura de software. Bennett, Mc Robb y Far-
apropiado. mer [BEN99], exponen este aspect0 de la siguiente
Disefiar objetos creando una representaci6n proce- manera:
dural para cada operacion, y estructuras de datos para En tkrminos de desarrollo orientado a objetos, la arqui-
10s atributos de clase. tectura conceptual esti relacionada con la estructura del
Disefiar mensajes, usando la colaboracion entre obje- modelo estatico de clase y las conexiones entre las com-
tos y relaciones. ponentes del modelo. El modelo arquitectura describe la
manera como el sistema se divide en subsistemas o m6du-
Crear el modelo de mensajeria. los, y como se comunican exportando e importando datos.
Revisar el modelo de disefio y renovarlo cada vez La arquitectura de codigo, define como es que el c6digo
del programa se encuentra organizado en archivos y direc-
que se requiera.
torios y agrupado en librerias. La arquitectura de ejecucion
se centra en 10s aspectos dinimicos del sistema y la comu-
nicaci6n entre componentes, mientras las tareas y opera-
ciones se ejecutan.
Un conjunto de etopos genkricos se oplico duronte La definicion de ccsubsistemas>>, nombrada por Ben-
el DOO, sin importor el rnktodo de diseiio que se escojo. nett et al., es una preocupacion principal durante el dise-
iio de sistema de UML.
Es importante hacer notar que las etapas de disefio
discutidas en esta section son 1terativas.-ESOsignifica
que deben ser ejecutadas incrementalmente, junto con
las actividades de AOO, hasta que se produzca el dise-
fio completo. El diseiio de sistemo se centra en orquitecturo
de softwore y definicion de subsistemos.
El diseiio de objetos describe objetos, hosto
22.1.4. Un enfoque unificado para el D O 0 un nivel en el cuol puedon ser irnplernentodos,
En el Capitulo 2 1, se menciono como Grady Booch, en un lenguoje de progrornocion.
James Rumbaugh e Ivar Jacobson, combinaron las
mejores cualidades de sus mCtodos personales de ana- El diseiio de objetos se centra en la description de
h i s y disefio orientado a objetos, en un metodo uni- objetos y sus interacciones con 10s otros. Una especifi-
ficado. El resultado, llamado el Lenguaje de Modelado cacion detallada de las estructuras de datos de 10s atri-
Unificado, se ha vuelto ampliamente usado en la butos y disefio procedural de todas las operaciones, se
industria4. crea durante el disefio de objetos. La visibilidad5 para
todos 10s atributos de clase se define, y las interfaces
entre objetos se elaboran para definir 10s detalles de un
modelo completo de mensajes.
Referencia web/ ' El disefio de sistemas y objetos en UML se extien-
de para considerar el diseiio de interfaces, adminis-
Un tutorial y listodo extenso de recunos de UML incluyendo
herrornientos, referencios y ejernplos, traci6n de datos con el sistema que se va a construir
se pueden enconhor en: mini.net/cetus/oo-umI.html y administraci6n de tareas para 10s subsistemas que
se han especificado. La interfaz de usuario en UML
Durante el modelo de analisis (Capitulo 21), se repre- utiliza 10s mismos conceptos y principios examina-
sentan las vistas del modelo de usuario y estructural. dos en el Capitulo 15. La vision del modelo de usua-
Booch, Rumbaugh y Jacobson han escrito tres libros muy impor- Visibilidad indica si el atributo es public0 (disponible a traves de
tantes sobre UML. El lector interesado debe consultar [B0099], todas las instancias de la clase),privado (disponiblesolo para la clase
[RUM991y UAC991. que lo especifica) o protegido (un atributo que puede ser usado por
la clase que lo especifica y por sus subclases).
INGENIER~A
rio maneja el proceso del diseiio de la interfaz de

. usuario, proporcionando una situaci6n que se elabo-
ra iterativamente, para volverse un conjunto de cla-
ses de interfaz6. La administraci6n de datos establece
un conjunto de clases y colaboraciones, que permi-
ten a1 sistema (producto) manejar datos persistentes
(por ejemplo, archivos y bases de datos). El diseiio
de la administraci6n de tareas establece la infraes-
tructura que organiza subsistemas en tareas, y admi-
nistra la concurrencia de tareas. El flujo de procesos
para el diseiio se ilustra en la Figura 22.3'.
A lo largo del proceso de disefio UML, la visi6n del
modelo de usuario y de estructura se elabora dentro del
diseiio de la representaci6n delimitada anteriormente.
Esta actividad de elaboraci6n se analiza en las seccio-
nes siguientes. FlGURA 22.3. Flujo de Proceso para DOO.
El disefio de sistema desarrolla el detalle arquitect6ni- particiona el modelo de analisis, para definir colecciones
co requerido para construir un sistema o producto. El y
congruentes de clases, relaciones comportamiento.Estos
proceso de diseiio del sistema abarca las siguientes acti- elementos de disefio se definen como subsistema.
vidades:
Partici6n del modelo de analisis en subsistemas.
Identificar la concurrencia dictada por el problema. 10s conceptos de cohesidn y ocoplorniento (Copitvlo 13)
Asignar subsistemas a procesadores y tareas. pueden oplicorse o nivel de subsisternos. Esfukrcese
Desarrollar un disefio para la interfaz de usuario. par olconzor uno bueno independencio funcionol,
cuondo diseie subsisternos
Elegir una estrategia basica para implementar la
administracidn (gesti6n) de datos. En general, todos 10s elementos de un subsistema
Identificar recursos globales y 10s mecanismos de comparten alguna propiedad en com6n. Y se integran
control requeridos para su acceso. para completar la misma funci6n; deben residir dentro
del mismo producto de hardware, o deben administrar
iCuiles son las etapas la misma clase de recursos. Los subsistemas se caracte-
del proceso de diseiio rizan por sus responsabilidades;eso significa que un sub-
de sistemas? sistema puede identificarse por 10s servicios que provee
[RUM91]. Cuando se usa en el context0 de un disefio de
Disefiar un mecanismo de control apropiado para el sistema 00, un servicio es una colecci6n de operacio-
sistema, incluyendo administraci6n de tareas. nes que llevan a cab0 una funci6n especifica (por ejem-
plo, administrar archivos de procesador de textos,
Considerar c6mo deben manejarse las condiciones
de frontera. producir un rendering tridimensional,traducir una seiial
de video anal6gica en una imagen digital comprimida).
Revisar y considerar trade-offs.
En las secciones siguientes, el disefio de actividades iQue criterios nos guian
relacionadas con cada una de estas etapas se conside- en el diseiio de subsistemas?
ran con mayor detalle.
Cuando se definen (y disefian) 10s subsistemas, se
deben seguir 10s siguientes criterios de disefio:
22.2.1. Particionar e l modelo d e analisis El subsistema debe tener una interfaz bien definida,
Uno de 10s principios fundamentales del andisis (Capi- a travCs de la cual se reduzcan todas las comunica-
tulo 11) es hacer particiones. En el diseiio de sistemas 00 ciones con el resto del sistema.
Hoy e n dia la mayoria de las clases de interfaz son parte de una 7 Recuerde que el A 0 0 e s una actividad iterativa. Es totalmente posi-
libreria de componentes de software reutilizables. Esto facilita el ble que el modelo de analisis sea revisado como consecuencia del
disefio e implementation de IGUs (Interfaz grafica de usuario). trabajo de disefio.
C A P ~ T U L O22 DISENO ORIENTADO A OBJETOS
Con la excepcion de un pequeiio numero de ccclases 6. Definir el modelo de mensajeria para la comunica-
de comunicacion>>,las clases incluidas dentro del cion entre capas.
subsistema deben colaborar solo con otras clases den- 7. Revisar el diseiio de capas, para asegurar que el aco-
tro del subsistema. plamiento entre capas se minimiza (un protocolo
El numero de subsistemas debe ser bajo. cliente/senidor puede ayudar a realizar esta tarea)
Un subsistema puede ser particionado internamente,
8. Iterar para refinar el diseiio de capas.
para ayudar a reducir la complejidad.
Cuando dos subsistemas se comunican entre si, pue-
den establecer un enlace clientelservidor o un enlace 22.2.2. Asignacih de concurrencia y subsistemas
punro-a-punto (peer-to-peer) [RUM91]. En un enlace El aspect0 dinamico del modelo objeto-comportamien-
cliente/senidor, cada uno de 10s subsistemas asume uno to provee una indicacion de concurrencia entre clases (o
de 10s papeles implicados, el de el cliente o el del ser- subsistemas). Si las clases (o subsistemas) no se activan
vidor. El servicio fluye del servidor a1 cliente en una a1 mismo tiempo, no hay necesidad para el procesamiento
sola direccion. En un enlace punto-a-punto, 10s servi- concurrente.Esto significa que las clases (o subsistemas)
cios pueden fluir en cualquier direccion. pueden ser implementadas en el mismo procesador de
Cuando un sistema es particionado en subsistemas, hardware. Por otro lado, si las clases (o subsistemas)
se lleva a cab0 otra actividad de diseiio, llamada estra- deben actuar en sucesos asincronicamente y a1 mismo
tificacion por capas. Cada capa [BUS961 de un sistema tiempo, se veran como concurrentes. Cuando 10s sub-
00, contiene uno o mas subsistemas y representa un sistemas son concurrentes, existen dos opciones de alo-
nivel diferente de abstraccion de la funcionalidad reque- jamiento: (1) alojar cada subsistema en procesadores
rida para completar las funciones del sistema. En la independientes 6 (2) alojar 10s subsistemas en el mismo
mayoria de 10s casos, 10s niveles de abstraccion se deter- procesador y proporcionar soporte de concurrencia, sobre
minan por el grado en que el procesamiento asociado las caracteristicas del sistema operativo.
con el subsistema es visible a1 usuario final.
Por ejemplo, una arquitectura de cuatro capas debe
incluir: (1) una capa de presentacion (el subsistema aso-
ciado con la interfaz de usuario), (2) una capa de apli- En lo moyorio de 10s cosos, uno implementocian
cacion (el subsistema que lleva a cab0 procesos asociados de multiproceso incremento lo complejidod y el riesgo
tecnico. Siempre que sea posible, escojo lo orquiteciura
con la aplicacion), (3) una capa de formato de datos (10s
de procesador mhs simple que buedo reolizor el trobojo
subsistemas que preparan 10s datos para ser procesados),
y (4) una capa de base de datos (el subsistema asociado Las tareas concurrentes se definen [RUM9 11 exa-
con la administration de datos). Cada capa se encuen- minando el diagrama de estado para cada objeto. Si el
tra mas profundamente dentro del sistema, representan- flujo de sucesos y transiciones indica que solo un obje-
do un procesarniento mas especifico a1 ambiente. to esta activo en el tiempo, un hilo de control se ha esta-
blecido. El hilo de control continua, aun cuando un
~ C O se~ tree
O un diseiio
objeto envia un mensaje a otro objeto, mientras que el
por capes?
primer objeto espera por la respuesta. Sin embargo, si
Buschmann y sus colegas [BUS961 sugieren el el primer objeto continua procesando despuCs de enviar
siguiente enfoque de diseiio para estratificacion por capas: un mensaje, el hilo de control se divide.
1. Establecer 10s criterios de estratificacion por capas. Las tareas en un sistema 00 se diserian generando
Esto significa decidir como se agruparan 10s subsis- hilos de control aislados. Por ejemplo, mientras que el
temas en una arquitectura de capas. sistema de seguridad HogarSeguro monitoriza sus sen-
2. Determinar el numero de capas. Muchas de ellas sores, puede tambikn marcar a la estacion central de
complican imecesariamente; muy pocas debilitan la monitorizacion para verificar la conexion. Ya que 10s
independencia funcional. objetos involucrados en ambos comportamientos estan
3. Nombrar las capas y asignar subsistemas (con sus activos a1 mismo tiempo, cada uno representa un hilo
clases encapsuladas) a una capa. Asegurarse de que de control y cada uno puede ser definido como una tarea
la comunicacion entre subsistemas (clases) en una distinta. Si la monitorizacion y marcado ocurrieran
capa8, y otros subsistemas (clases) en otra capa, secuencialmente, podna implementarse una sola tarea.
siguen la filosofia de diseiio de la arquitectura. Para determinar cual de las opciones de asignacion
4. Diseiiar interfaces para cada capa. de procesadores es apropiada, el diseiiador debe consi-
5. Refinar 10s subsistemas, para establecer la estructura derar 10s requisitos de desempeiio, costos y el encabe-
de clases para cada capa. zado impuesto por la comunicaci6n entre procesadores.
En una arquitectura cerrada, 10s mensajes procedentes de una

capa s e deberian haber enviado a la capa adyacente inferior. En
una arquitectura abierta, 10s mensajes deben enviarse a cual-
quiera de las capas inferiores.
22.2.3. Componente d e administracion d e tureas interfaz por si misma representa un subsistema de impor-
Coad y Yourdon [COA91] sugieren la estrategia siguien- tancia critica para la mayoria de las aplicaciones moder-
te, para el diseiio de objetos que manipulan tareas con- nas. El modelo de analisis 00 (Capitulo 21), contiene
currentes: 10s escenarios de uso (llamados casos de uso), y una
se determinan las caracteristicas de la tarea. descripcion de 10s roles que juegan 10s usuarios (lla-
mados actores) cuando interactdan con el sistema. Este
se define un coordinador de tarea y objetos asocia-
modelo sirve como entrada a1 proceso de diseiio de inter-
dos. faz de usuario.
se integra el coordinador y otras tareas.
Las caracteristicas de la tarea se determinan, com-
prendiendo c6mo es que se inicia la tarea. Las tareas
controladas por sucesos y manejadas por reloj son l o moyotfo de h s closes necesorios para treat
uno interfaz moderrm yo existen y e h n disponibles
las mas comunes. Ambas se activan por una inte-
poro el diseiiodor. Eldiseiio de interfoz obedece
rrupcion, per0 la primera recibe una interruption de ol enfoque definido en el Copitulo 15.
alguna fuente externa (por ejemplo, otro procesador,
un Sensor), mientras que la ultima es controlada por
el reloj. Una vez que el actor y su situacidn de uso se defi-
nen se identifica una jerarquia de comando. La jerar-
quia de 6rdenes define la mayoria de las categorias del
mend de sistema (la barra de mend o la paleta de herra-
mientas), y todas las subfunciones, que estarin dispo-
nibles en el contexto de una categoria importante de
menu de sistema (las ventanas de mend). La jerarquia
de ordenes se refina repetidamente, hasta que cada caso
Ademas de la manera en que una tarea es inicia- de uso pueda ser implementado navegando por la jerar-
da, tambiCn se deben determinar la prioridad y cri- quia de funciones.
ticidad de la tarea. Las tareas de alta prioridad deben Debido a que existe una amplia variedad de entor-
tener acceso inmediato a 10s recursos del sistema. nos de desarrollo de interfaces de usuario, el disefio de
Las tareas de alta criticidad deben continuar ope- 10s elementos de una IGU (Interfaz Grifica de Usuario)
rando aun cuando la disponibilidad de un recurso es no es necesario. Ya existen clases reutilizables (con atri-
reducida o el sistema operativo se encuentra en esta- butos y operaciones apropiadas) para ventanas, iconos,
do degradado. operaciones de ratdn y una amplia gama de otro tip0 de
Una vez que las caracteristicas de la tarea se han funciones de interaction. La persona que implementa
determinado, se definen 10s atributos y operaciones estas clases (el desarrollador), solo necesita instanciar
del objeto requerido, para alcanzar coordinaci6n y objetos, con las caracteristicas apropiadas para el domi-
comunicaci6n con otras tareas. La plantilla basica de nio del problema.
una tarea (para un objeto tarea), toma la forma de
[COA9 1] :
Nombre de l a tarea - el nonbre del objeto 22.2.5. Componente d e la administraci6n
Descripcidn - un r e l a t o que describe el propdsito d e datos
del objeto.
Prioridad - prioridad de la tarea (por ejemplo, a l t a , La administracion o gesti6n de datos engloba dos ire-
media, ba ja) . as distintas de inter&: (1) la administracih (gestion)
Servicios - l i s t a de operaciones que son responsa- de datos criticos para la propia aplicaci6n, y (2) la crea-
bilidad del objeto. ci6n de infraestructura para el almacenamiento y recu-
Coordinados por - la manera como se invoca el com- peraci6n de 10s objetos. En general, la administracion
portmiento del objeto. de datos se diseiia en forma de capas. La idea es aislar
Comunicados via - datos de entrada y salida r e l e - ~ 10s requisitos de bajo nivel que manipulan las estructu-
vantes a la tarea. ras de datos, de 10s requisitos de alto nivel para mane-
La descripcion de esta plantilla puede ser traducida jar 10s atributos del sistema.
en el modelo de diseiio esthdar (incorporando la repre- En el contexto del sistema, un sistema de manipula-
sentacion de atributos y operaciones), para 10s objetos ci6n de bases de datos, normalmente se usa como alma-
tarea. cCn de datos comlin para todos 10s subsistemas. Los
objetos requeridos para manipular la base de datos son
miembros de clases reutilizables que se identifican
22.2.4. Componente d e interfaz de usuario mediante el andisis del dominio (Capitulo 21), o que
Aunque la componente de interfaz de usuario se imple- se proporcionan directamente por el fabricante de la
menta dentro del contexto del dominio del problema, la base de datos. Una discusion detallada del diseiio de
C A P ~ T U L O22 DISENO ORIENTADO A O B J E T O S
bases de datos para sistemas 00 esta fuera del ambit0 debe diseiiar un mecanismo de control para ello. Rum-
de este libro9. baugh y sus colegas [RUM911 sugieren que cada recur-
El diseiio de la componente de administration de so deba ser poseido por un ccobjeto guardian,,. El objeto
datos incluye el diseiio de 10s atributos y operaciones guardian es el porter0 del recurso, controlando el acce-
requeridas para administrar objetos. Los atributos sig- so y moderando peticiones contradictorias para 61.
nificativos se aiiaden a cada objeto en el dominio del
problema, y proporcionan informacion que responde a 22.2.7. Comunicaciones entre subsistemas
la pregunta < < ~ C O me~almaceno?>>.
O Coad y Yourdon
[COA91] aconsejan la creaci6n de una clase objeto- Una vez que cada subsistema ha sido especificado, es
servidor, c o n 10s servicios de (a) indicar a1 objeto que necesario definir las colaboraciones que existen entre
se almacene a si mismo, y (b) recuperar objetos alma- subsistemas. El modelo que se usa para la colaboracion
cenados para su uso por otros componentes de disefio>>. objeto-objeto puede ser extendido en conjunto para 10s
Como un ejemplo de la gestion de 10s datos para el subsistemas. La Figura 22.4 ilustra un modelo de cola-
objeto Sensor, examinado como parte del sistema de boracion. Como se vio anteriormente en este capitulo,
seguridad HogarSeguro, el diseiio puede especificar un la comunicaci6n puede ocurrir estableciendo un enlace
archivo llamado <<Sensor>>. Cada registro deberia corres- cliente/servidoro punto-a-punto. RefiriCndose a la Figu-
ponder a una instancia denominada Sensor, y habria de ra, se debe especificar la interaction que existe entre
contener 10s valores de cada atributo de Sensor para una subsistemas. RecuCrdese que un contrato proporciona
instancia dada. Las operaciones dentro de la clase objeto- la indicacih de 10s modos como un subsistema puede
servidor deberian permitir a un objeto especifico ser interactuar con otro.
almacenado y recuperado, cuando sea requerido por el
sistema. Para objetos mas complejos, seria necesario iQuti etapas de diseiio
se requieren para especificar
especificar una base de datos relacional, o una base de
un ((contrato)) de un subsistema?
datos orientada a objetos para ejecutar la misma funci6n.
Las siguientes etapas de diseiio pueden aplicarse para
especificar un contrato para un subsistema [WIR90]:
I Subsistema
ciiente 1Solicitud
1 . Listar cada peticidn que puede ser realizada por 10s
colaboradores del subsistema. Organizar las peti-
ciones por subsistema y definirlas dentro de uno o
mas contratos apropiados. Asegurarse de anotar con-
tratos que se hereden de superclases.
2. Para cada contrato, anotar las operaciones (las here-
dadas y las privadas,) que se requieren para irnple-
Solicitud mentar las responsabilidades que implica el contrato.
Asegurarse de asociar las operaciones con las clases
especificas, que residen en el subsistema.
Solicitud
3. Considerar un contrato a la vez, crear una tabla con
la forma de la Figura 22.5. Para cada contrato, la
tabla debe incluir las siguientes columnas:
FIGURA 22.4. Modelo de colaboracion entre subsistemas. Tipo: el tipo de contrato (por ejemplo, clientel
servidor o punto-a-punto).
22.2.6. Componente de gesti6n de recursos Contrato Tipo Colaboradores Clasels) Operacion(es) Formato
del mensaje
Estan disponibles una variedad de recursos diferentes
para un sistema o product0 0 0 ; y, muchas veces, 10s
subsistemas compiten por estos recursos a1 mismo tiem-
po. Los recursos globales del sistema pueden ser enti-
dades externas (por ejemplo, una unidad de disco,
procesador o linea de comunicaciones) o abstracciones
(por ejemplo, una base de datos, un objeto). Sin impor-
tar la naturaleza del recurso, el ingeniero de software FIGURA 22.5. Tabla de colaboraciones del subsistema.
9 Los lectores interesados deben consultar [BR091],[TAY92]y

IR.40941.
1NGENIERfA DEL SOFTWARE. UN ENFOQUE PRPLCTICO
Colaboradores: 10s nombres de 10s subsiste- grafo de colaboraci6n es similar, en forma, a1 dia-
mas que son parte del contrato. grama de flujo de sucesos examinado en el Capi-
Clase: 10s nombres de las clases (contenidas en tulo 21. Cada subsistema se representa, junto con
el subsistema), que proporcionan servicios deno- sus interacciones con otros subsistemas. Los con-
tados por el contrato. tratos que se invocan durante interacci6n, se deta-
Operaciones: nombres de las operaciones (den- llan como se muestra en la Figura. Los detalles
tro de la clase), que implementan 10s servicios. de la interacci6n se determinan observando el con-
trato en la tabla de colaboraci6n del subsistema
Formato del mensaje: el formato del mensaje (Fig. 22.5).
requerido para implementar la interacci6n entre
colaboradores.
Esboce una descripci6n apropiada del mensaje,
para cada interacci6n entre 10s subsistemas.
4. Si 10s modos de interaccidn entre 10s subsisternas Cada contrato entre subsisterna se manifiesto por uno o
son complejos, dehe crear un diagrama subsis- mas rnensajes que se transporton entre 10s obietos dentro
tema-colaboracidn como el de la Figura 22.6. El de 10s subsisternas.
Retomando la metafora que se introdujo a1 inicio del objeto, y detalles de procedimientos, que describen las
libro, el diseiio de sistemas 00 se puede visualizar como operaciones.
el plano del suelo de una casa. El plano del suelo espe-
cifica el prop6sito de cada habitaci6n y sus caracteris-
ticas arquitect6nicas,que conectan las habitaciones unas
con otras y con el ambiente exterior. Ahora es el momen- kegcirese de que lo orquitecturo se ho dehido
ontes de comenzor el diseio de objetos. No deje
to de proporcionar 10s detalles que se requieren, para
que lo orquitechwa predomine.
construir cada habitaci6n. En el context0 del DOO, el
diseiio de objetos se centra en las <<habitaciones>>. La descripci6n del protocolo no es nada mas que un
Bennet y sus colegas [BEN991 examinan el diseiio conjunto de mensajes y un comentario correspondien-
de objetos de la siguiente manera: te para cada mensaje. Por ejemplo, una porci6n del pro-
El diseiio de objetos tiene que ver con el diseiio detallado t o c o l ~de descripci6n para el objeto sensor de
de 10s objetos y sus interacciones. Se completa dentro de la movimiento (descrito anteriormente), podria ser:
arquitecturaglobal, definida durante el diseiio del sistema y de
MENSAJE(sensor.movimiento) -> leer: DEWELVE sen-
acuerdo con las reglas y protocolos de diseiio aceptados. El
sor.ID, sensor.estado;
diseiio del objeto esta relacionado en particular con la especi-
ficacion de 10s tipos de atributos, corno funcionan las opera- Esto describe el mensaje requerido para leer el Sen-
ciones y corn0 10s objetos se enlazan con otros objetos. sor. Igualmente,
Es en esta fase cuando 10s principios y conceptos MENSAJE(sensor.movimiento) -> asigna: ENVIA sen-
bhsicos asociados con el diseiio a nivel de componen- sor.ID, sensor.es tado;
tes (Capitulo 16) entran en juego. Se definen las estruc-
turas de datos locales (para atributos), y se diseiian 10s Asigna (establece) o inicializa el estado del Sensor.
algoritmos (para operaciones).
I Subsistema1-'
para el panel
22.3.1. Descripcih de objetos
de estado para la zona
Una description del diseiio de un objeto (instancia de I de estado de prueba I
Solicltud de
clase o subclase) puede tomar una o dos formas especificacion
[GOL83]: (1) Una descripcidn de protocolo que esta- del tipo de
blece la interfaz de un objeto, definiendo cada mensaje chequeo Solicitud de notification
periodic0 periodica del chequeo
que el objeto puede recibir y las operaciones que el obje- de actualization de la
de estado
to lleva a cab0 cuando recibe un mensaje, o (2) Una desde la alarms 1 , configuraclon de alarrna
cripcidn de implementacibn que muestra detalles de del sisterna Subsistma
implementaci6n para cada operaci6n implicada por un central
de
mensaje pasado a un objeto. Los detalles de imple-
mentacion incluyen informaci6n acerca de la parte pri-
vada del objeto; esto significa, detalles intemos acerca FIGURA 22.6. Grafico abreviado del subsistema colaborado
de la estructura de datos, que describen 10s atributos del de HogarSeguro.
C A P ~ T U L O2 2 D I S E N O ORIENTADO A O B l E T O S
Para un sistema grande con muchos mensajes, gene-

ralmente es posible crear categorias de mensajes. Por Apomtemente, coda concepto que se present6
ejemplo, categorias de mensajes para el objeto Sistema en d Copitulo 13 es tombin oplible cqul.
de HogarSeguro deberian incluir mensajes de configu- Asegcrese de estor familion'mdo con 10s temos
raci6n del sistema, mensajes de monitorizaci6n (super- presentodos en el Copftdo 13.
visibn), mensajes de sucesos, etc.
Una descripci6n de la implementaci6n de un objeto, Se crea un algoritmo para implementar la especifi-
proporciona 10s detalles internos (ccocultos>>),que se caci6n para cada operacibn. En muchas ocasiones, el
requieren para la implementaci6n, per0 no son necesa- algoritmo es una simple secuencia computacional o pro-
rios para ser invocados. Esto significa que el diseiiador cedural, que puede ser implementada como un mddulo
del objeto debe proporcionar una descripci6n de imple- de software autocontenido. Sin embargo, si la especifi-
mentacibn, y debe por tanto crear 10s detalles internos caci6n de la operacibn es compleja, sera necesario
del objeto. Sin embargo, otro diseiiador o desarrollador modularizar la operacibn. Las tCcnicas convencionales
que utilice el objeto u otras instancias del objeto, requie- de disefio de componentes se pueden usar para resolver
re solo la descripci6n del protocolo, per0 no la descrip- esta tarea.
ci6n de la implementacibn. Las estructuras de datos se disefian a1 mismo tiem-
Una descripci6n de la implementacidn se compone de po que 10s algoritmos. Ya que las operaciones manipu-
la siguiente informacibn: (1) una especificaci6n del nom- lan 10s atributos de una clase, el disefio de estructuras
bre del objeto y referencia a la clase; (2) una especifica- de datos, que reflejan mejor 10s atributos, tendran un
cibn de las estructuras de datos privadas, con indicaci6n fuerte sentido en el diseiio algoritmico de las operacio-
de 10s datos y sus respectivos tipos; (3) una descripci6n nes correspondientes.
de procedimientos de cada operaci6n o, alternativamen-
te, indicadores a dichas descripciones de procedimien- ~Existealyuna manera
tos. La descripci6n de implementaci6n debe contener de clasificar las operaciones
informaci6n suficiente, para el manejo adecuado de todos (metodos)?
10s mensajes descritos en la descripci6n de protocolo.
Aunque existen muchos tipos diferentes de opera-
ciones, normalmente se pueden dividir en tres grandes
categorias: (1) operaciones que manipulan 10s datos de
alguna manera (por ejemplo, agregando, eliminando,
Poro olconzor 10s beneficios del ocultomiento
de informocibn (Copitulo 13), cuolquiero que intente
reformateando, seleccionando),(2) operaciones que eje-
usor un objeto solo necesito lo descripcibn cutan chlculos, y (3) operaciones que monitorizan (super-
del protocolo. Lo descripcibn de lo implementocibn visan) a1 objeto para la ocurrencia de un suceso controlado.
contiene detalles, que deberion ((ocultorse)) Por ejemplo, la descripci6n del proceso HogarSe-
de oquellos que no tienen necesidod de conocer. guro contiene 10s fragmentos de la oraci6n: ccal sensor
se asigna un ndmero y tipo>>y ccuna contrasefia (pass-
Cox [COX851 caracteriza la diferencia entre la infor- word) maestra programada para habilitar y deshabilitar
maci6n contenida en la descripci6n de protocolo y la el sistema>>.Estas dos frases indican varias cosas:
contenida en la descripci6n de implementacibn, en tkr- Que una operaci6n de asignaci6n es importante para
minos de ccusuarios>> y ccproveedores>>de semicios. Un el objeto Sensor.
ccusuario~del semicio provisto por un objeto debe ser Que una operaci6n programar se aplicarh a1 objeto
familiar con el protocolo de invocacibn del semicio: eso
Sistema.
significa especificar lo que se desea. El proveedor del
semicio (el propio objeto), debe ocuparse del mod0 en Que las operaciones habilitar y deshabilitar se apli-
que el semicio se suministrara a1 usuario; eso significa can a Sistema (finalmente se debe definir el estado
con detalles de implementaci6n. de sistema usando la notaci6n adecuada en un dic-
cionario de datos) como:
estado del sistema = [habilitado I
22.3.2. Disefio de algoritmos y estructuras deshabili tad01
de datos
Una variedad de representaciones contenidas en el mode-
lo de analisis y el disefio de sistema, proveen una espe-
cificacidn para todas las operaciones y atributos. Los Uno operocibn se define en gron porte de lo mismo
algoritmos y estructuras de datos se disefian utilizando monero en que se refino uno funcibn en el diserio
un enfoque, que difiere un poco de 10s enfoques del dise- convencionol. Escribo uno descripcibn del proceso,
iio de datos y del diseiio a nivel de componentes exa- hogo on onblisisgromoticol y oisle nuevos operociones
minadas para la ingenieria del software convencional. o un nivel de obstroccibn mbs bojo.
ChPfTULO 11 DISENO ORIENTADO A OBIETOS
//operacionl y operacion2. El rol de Memento es el de vigilar el estado o alma-

//C6digo para mktodos que implementen operaciones cenamiento de recuperacih del estado de un sistema,
de retorno cuando se requiera. La Figura 22.8 muestra el dia-
/ / e n e l objeto Singleton, debe i n c l u i r operacidnl grama de clase para el patrh. Existen tres elementos
//operacidn2 de este patrh. El primero es ClaseCreadora, el cual
1 es una clase que describe objetos cuyo estado debe
ser almacenado. Existen dos mCtodos asociados con
esta clase: fijarValorMemento y construirMemento.
El primero inicializa su estado, toma un argumento el
cual es un objeto definido por la clase Memento y
. ~ t e t i e . ~ h
reestablece su estado con el uso del argumento. El
Estado Singleton segundo crea un objeto de la clase ClaseMemento la
cual contiene su estado actual. En efecto, fijarMe-
mento actda como un recurso de restauraci611, mien-
tras que construirMemento lo hace como un recurso
de almacenamiento.
FIGURA 22.7. La estructura general del patron Singleton.
El patrdn Singleton se implementa por medio de

una variable de instancia estitica, descrita por el atri-
but0 de clase ObjetoSimple. La cual es inicializada
con null para la instanciaci6n.
El acceso a1 objeto Singleton se realiza mediante
el mCtodo instanciaUnica. Este comprueba primero
si ObjetoSimple es igual a null. En caso afirmativo,
significa entonces que no se ha creado un objeto de
tipo Singleton, y que el mCtodo llamarii a un cons-
tructor privado adecuado para establecer a1 objeto Sin-
gleton; en el c6digo anterior esto se realiza cuando el
argumento del constructor es cero. El constructor uti-
lizado se declarari como privado, ya que no se desea
que ningdn usuario pueda crear objetos de tip0 Sin-
gleton, except0 si es por medio de instanciaUnica, la
cual se ejecutarh, de una vez y por todas, en el momen-
FIGURA 22.8. El patron Memento.
to de la creaci6n. La clase tambiCn contendri mCto-
dos, que ejecutariin operaciones en un objeto de tipo
Singleton. La clase ClaseMemento define objetos que man-
De este modo, si el patr6n Singleton se utilizara en tendriin el estado de un objeto de la clase ClaseCrea-
un sistema de control de triifico adreo, y solo se nece- dora. Contiene dos mCtodos obtenerEstadoMemento
sitara un controlador de aeronaves, entonces el nom- y fijarEstadoMemento. La primera devuelve el esta-
bre de la clase anterior deberia ser ControladorAereo, do que se almacena, mientras que la segunda fija el
y deberia tener mCtodos tales como obtenercontro- estado a un valor pasado como argumento. El tercer
ladorAe'reo, que devuelve la 6nica instancia de un con- elemento del patr6n Memento es la clase cliente Care-
trolador de trifico adreo. taker, Csta no se muestra en la Figura 22.8. Repre-
senta una clase que implementa objetos que contienen
un objeto de la clase ClaseMemento. Tiene un con-
22.4.2. Otro ejemplo de un patr6n junto muy limitado de funciones ya que todo lo que
Se ha visto ya un ejemplo de un patrbn: Singleton. El realiza es almacenar un Memento, no altera ni exa-
objetivo de esta seccion es describir un patr6n mis mina 10s contenidos de un memento.
complicado, conocido como Memento.
22.4.3. Un ejemplo final de un patr6n
Frecuentemente, existe la necesidad de desarrollar
un cddigo que lleve a cab0 el procesamiento de
El pairbn de Memento se usa datos accedidos secuencialmente. Este acceso
para la recuperaci6n de sistemas. secuencial tendri usualmente la misma forma, y por
esto es adecuado para un patrdn. El objetivo de esta ciados con las clases FiltroFuenteConcreto, que
seccidn es describir tal patrdn; ello es debido a realizarin algdn tip0 de procesamiento con 10s
Grand [GRA99]. Algunos ejemplos de procesa- datos.
miento secuencial son:
Un programa de informes debe procesar un archivo 22.4.4. Descripci6n de un patr6n de disefio.
de datos de empleados, leyendo cada registro y dese- Las disciplinas maduras de ingenieria hacen un vas-
chando todos aquellos registros de empleados que to uso de patrones de diseiio. La ingenieria del soft-
ganen por encima de una cierta cantidad. ware solo se encuentra en su infancia, con el uso de
Un programa editor puede ser consultado por su usua- patrones. De cualquier manera, se esti procediendo
rio, para listar las lineas de texto de un archivo que ripidamente hacia el comienzo de una taxonomia.
coincidan con un cierto patrbn. En general, la descripcidn de un patrdn como parte
Un programa de anilisis de la Web debe leer el de una taxonomia debe proporcionar [GAM95]:
cbdigo fuente de un documento HTML, para descu- Nombre del patrbn. Por ejemplo Filtro.
brir cuantas referencias a otros sitios contiene el docu-
mento. Intencidn del patrdn. Por ejemplo, un patrdn debe
tener la intencidn de facilitar el mantenimiento,
pues puede acomodar un ndmero de diferentes tipos
iQue hace el Filtro? de objeto.
Los problemas de diseiio que motivan el patrdn.
Estas son formas diferentes de procesamiento; de Por ejemplo, un patron debe desarrollarse, para que
un ndmero de transformaciones diferentes de datos
cualquier manera, estan unidos el hecho de que
el procesamiento de datos es de manera secuencial. puedan ser aplicadas a un objeto, muchas de las
cuales son desconocidas, cuando el patrdn es desa-
Este procesamiento debe hacerse con base en pala-
bra por palabra, o con base en registro por registro; rrollado originalmente.
a pesar de ello, tambiCn se aplica a1 procesamiento
secuencial, y de aqui que sea una buena oportunidad iComo se describe un patron
de capturarse en un patrdn. Este patrdn, conocido de diseiio?
como Filtro, se muestra en la Figura 22.9. Consta de
varias clases: La solucidn que resuelve estos problemas.
FiltroFuente. Esta es la clase que actda como Las clases que se requieren para implementar la
superclase para otras clases concretas, que imple- solucibn. Por ejemplo, las cuatro clases descritas
mentan el procesamiento requerido. La clase no en la Figura 22.9.
lleva a cab0 la recuperacidn de 10s datos que se Las responsabilidades y colaboraciones entre las
procesaran, per0 delega eso a1 objeto Fuente, cuya clases de solucidn. Por ejemplo, una clase debe ser
clase sera descrita en la tercera viiieta siguiente. responsable de la construccidn de un objeto, cuyo
El objeto Fuente se pasa por medio del constuc- comportamiento varia a1 tiempo de ejecucion.
tor a la clase. La clase contiene un mitodo llamado
obtenerDatos, que recupera 10s datos que se pro- Lineamientos que conduzcan a una implementa-
cesaran. cibn efectiva. Generalmente, existiri un ndmero
de formas diferentes de programar un patrbn; por
FiltroFuenteConcreto. Esta es una subclase de la ejemplo, el procesamiento de errores debe ser tra-
clase FiltroFuente. Redefine el mCtodo obtenerDa- tad0 de diferentes formas.
tos, para realizar algunas operaciones extras en 10s
datos que han sido leidos, por ejemplo si el patrbn Ejemplos de cbdigo fuente.
se utiliza para contar las cadenas de caracteres que Referencias a otros patrones de diseiio, o patrones
coinciden con cierto patrbn, el codigo para realizar que puedan usarse en conjunto con el patrdn des-
este recuento se coloca aqui. Normalmente este crito.
mitodo utiliza el mitodo correspondiente obtener-
Datos, dentro de la super-clase. 22.4.5. El futuro de 10s patrones
Fuente. Esta clase se asocia con 10s objetos, que lle- En la actualidad, se ha desarrollado y catalogado un
van a cab0 el proceso de recuperar 10s datos que se ndmero relativamente pequeiio de patrones. De cual-
procesarh. Esto se logra por medio de un mCtodo quier manera, 10s dltimos cinco aiios han sido testi-
llamado obtenerDatos. gos de una tremenda explosidn, en tCrminos de
FuenteConcreta Esta clase es una subclase de interis industrial. Los patrones, junto con 10s com-
Fuente e implementa el mitodo obtenerDatos. Su ponentes, ofrecen la esperanza de que la ingenieria
funcidn es proporcionar datos a 10s objetos aso- de software, eventualmente, se parezca a otras dis-
C A P ~ T U L O22 DISENO O R I E N T A D O A O B J E T O S
ciplinas de ingenieria, con clases volviCndose el ani- FiltroFuente 1

logo en software de componentes electr6nicos, y 10s
patrones volviCndose el anilogo en software de Las clases FiltroFuente
pequeiios circuitos hechos de componentes. Antes v FiltroFuenteConcreto
contend& otros m&odos
de que esto suceda, existe adn una ingente cantidad pero no se rnuestran
de trabajo que llevar a cab0 a1 identificar patrones y
catalogarlos; tambiCn, se produciri esta situacibn,
ObtenerDatosO
I
cuando el numero de patrones existentes se vuelva Y
tan grande, que se necesite una forma de indexado
I Fuente b
automitica o semiautomitica.
(nabstractonObtener~atosOl
En lo octuolidod existe un buen grupo de potrones;

sin embargo, en 10s prbximos oiios deberio hober
uno verdodero expansidn en su uso. FIGURA 22.9. El patron Filtro.
El objetivo de esta secci6n es describir, con un grado de

mayor detalle, el conjunto de notaciones que componen
el lenguaje UML. Anteriormente, en el Capitulo 21, se
describen su origen y componentes principales; de hecho,
muchos de 10s diagramas presentados en el Capitulo 21
y en este capitulo han sido expresados en UML. Se ha
tomado la decisidn de utilizar esta notacibn, porque se ha
vuelto predominante muy ripidamente en aquellas com-
paiiias que utilizan ideas de ingenieria para desarrollar
software orientado a objetos. El primer componente que
se intenta describir es el modelo de clases.
UML se est6 convirtiendo en un estbndor de fact0

poro el analisis y diseiio orientodo o obietos.
22.5.1. El modelo de clases

Un modelo de clases es una descripcidn de las clases en FIGURA 22.10. Un ejemplo de una clase descrita en UML.
un sistema y sus relaciones. No describe el comporta-
miento dinimico del sistema, por ejemplo el compor- TambiCn en la Figura 22.10 se muestra una ver-
tamiento de objetos individuales. El primer elemento si6n grifica de 10s comentarios utilizados en el len-
de un diagrama de clases es una descripci6n de clases guaje de programaci6n. El cuadro, con una esquina
individuales. La Figura 22.10 muestra como se descri- superior derecha doblada, llama la atenci6n del lec-
be una clase. La clase describe a1 cliente de un banco. tor a algun aspect0 de un diagrama. En el caso de la
Esta figura es muy simple, ya que solo contiene una Figura 22.10, se llama la atenci6n del lector, a1
clase. Consta del nombre de la clase (Cliente), el nom- hecho de que muchos de 10s atributos y operaciones
bre de algunos de sus atributos, por ejemplo el atribu- asociados con la clase Cliente no se muestran; por
to direccidn, que contiene la direcci6n del cliente, y la ejemplo, la colecci6n de cuentas que posee el clien-
lista de operaciones; por ejemplo, la operaci6n obte- te no se muestran en la seccidn de atributos de la
nerNombre recupera el nombre de un cliente. Cada cua- clase.
dro que representa una clase contiene, por consiguiente, La Figura 22.10 es muy simple, en la prictica 10s
una secci6n que contiene el nombre de la clase, una sec- diagramas de clases en UML mostrarin la relaci6n
ci6n que enumera 10s atributos de 10s objetos definidos entre clases. Existe un gran numero de tipos diferen-
por la clase, y una secci6n que describe las operaciones tes de relaciones, que pueden ser expresadas. La pri-
asociadas con tales objetos. mera cosa que tratemos sera la generalizacibn.
22.5.2. Generalizacih 22.5.3. Agregacih y composici6n
Esta relaci6n es la que se mantiene entre una clase X y La seccidn anterior describi6 una relacion, que puede
otra clase Y, cuando la clase Yes el ejemplo m6s espe- ser representada en un diagrama de clases UML: gene-
cifico de la clase X. Por ejemplo, una relaci6n de gene- ralizaci6n; las otras relaciones importantes son la agre-
ralizacion existe entre una clase Cuenta, la cual gacion y la composicion. Existen dos relaciones que
representa una cuenta bancaria general, y una cuenta establecen que una clase genera objetos, que son parte
coniente, que es un ejemplo especifico de una cuenta. de un objeto definido por otra clase. Por ejemplo, un
La Figura 22.11 muestra como se representaria esta rela- sistema para un fabricante tendr6 la necesidad de man-
cion en un diagrama de clases UML. tener 10s datos acerca de 10s elementos que se estin
fabricando, y de aquellos que se est6n haciendo. Por
ejemplo, un ordenador se fabricaria a partir de una exten-
sa sene de componentes incluyendo su arrnazon, un dis-
No se muestran co duro, un conjunto de tarjetas de memoria, etc. El
todos 10s atributos
.- ordenador se construye, a partir de una serie de com-
I y operaclones
I ponentes y en un sistema orientado a objetos utilizado
para dar soporte a1 proceso de fabrication, existir6 una
relacion de agregacion entre la clase utilizada para des-
cribir el producto fabricado y cada uno de sus compo-
nentes. La Figura 22.12 muestra como se representa esta
relacion, en un diagrama de clases UML.
FIGURA 22.11. Un ejemplo de generalizacion en UML.
Aqui una clase Cuenta tiene una relaci6n de genera-

lizacion con las clases mhs especificas,como son Cuen-
tacorriente y Depcisito. Esta relacion se representa por Aqui la linea con un rombo hueco en un extremo
medio de una flecha, que apunta de la clase m6s espe- indica que la clase describe objetos que agregan otros
cifica hacia la clase mhs general. Una vez m6s, obser- objetos, la clase con el rombo unido a ella describe obje-
ve que, para prop6sitos ilustrativos, no se muestra tos, que contiene objetos definidos por la otra clase. En
UML las relaciones nomalmente se mezclan. Por ejem-
,
ninguna operaci6n o atributo.
plo, la Figura 22.12 habra un numero de componentes,
que posean una relaci6n de generalizacih con la clase
Producto Manufacturado
Componente.
7
Y
I-----,--
Componente
-
vado
represents
agregmh
FIGURA 22.12. Agregacion en UML.
FIGURA 22.14. Un diagrama UML de clases mostrando

composicion.
Esto se muestra en la Figura 22.13, donde Compo-

nente se asocia con un nlimero de clases m6s especifi-
cas, que describen 10s componentes con 10s que un
producto fabricado puede ser ensamblado.
Existe una forma especial de agregacibn, conocida

como composici6n. ~ s t se a usa cuando se tiene una
FIGURA 22.13. Un diagrama UML de clases mostrando situaci6n en la que un objeto contiene un nlimero de
generalizacion y agregacion. otros objetos, y cuando el objeto contenedor se elimi-
C A P ~ T U L O2 2 DISENO ORIENTADO A OBTETOS
na todas las instancias de 10s objetos que estin conte- mo de la linea determina que un administrador dirige a
nidos desaparecen. Por ejemplo, una clase Cliente que un coniunto de empleados.
representa clientes en un banco tendra una relaci6n de La asociaci6n entre clases puede nombrarse para
composici6n con las cuentas que el cliente posee; por- documentar explicitamente la relaci6n. Por ejemplo, la
que si el cliente se elimina, por ejemplo, se mueve a otro Figura 22.17 documenta el hecho de que un adminis-
banco, todas sus cuentas son eliminadas; esta forma de trador dirige a un grupo (colecci6n) de empleados.
w
relacion se indica de manera muy similar a la agrega-
cion, per0 en esta ocasi6n el rombo esta relleno en lugar Administrador
de hueco. Esto se muestra en la Figura 22.14.
22.5.4. Asociaciones
La agregaci6n y la composici6n son ejemplos especifi-
cos de una relaci6n entre dos clases. Una relaci6n ocu-
rre entre dos clases cuando existe alguna conexi6n entre
ellas, en UML esto se conoce como asociaci6n. Algu-
nos ejemplos de esto se describen a continuaci6n:
u Empleado
FIGURA 22.16. Multiplicidad en un diagrama de clases

Una clase Administrador se relaciona con la clase
Empleado en virtud de que un administrador dirige en UML.
a un n6mero de empleados.
Una clase Vuelo se asocia con la clase Avion en vir- Una alternativa para documentar la asociaci6n es
documentar 10s papeles (roles) que cada clase juega en
tud de que un avi6n emprende un vuelo particular.
una asociaci6n. Un ejemplo de esta situaci6n se mues-
Una clase Computadora se relaciona con una clase tra en la Figura 22.1 8. Aqui, la clase Universidad jue-
Mensaje en virtud del hecho de que una colecci6n ga el rol de hospedar una serie de estudiantes que, a su
de mensajes esth esperando el proceso de una com- vez, juegan el rol de ser estudiantes miembros de la uni-
putadora. versidad. Normalmente, cuando se documentan las aso-
Una clase InformeBancario se relaciona con la clase ciaciones, se elige el tipo de documentaci6n que se
Transaccion en virtud de que el informe contiene utilizarh: si la documentaci6n de asociaci6n o ladocu-
detalles de cada transacci6n. mentaci6n de roles de clases que participan en la aso-
De estas relaciones, s610 la 6ltima es de agregaci6n. ciaci6n. El realizar ambos, aunque perfectamente valido,
Todas las otras son asociaciones claras. Tales asocia- se considera como un exceso.
ciones se escriben en UML como una linea recta. Por
ejemplo, la Figura 22.15 muestra la primera asociaci6n
de las anteriores.
Las asociaciones entre clases se documentan en tkr-
minos de la multiplicidad de la asociacidn y del nom-
bre de la asociacibn. A continuation se observara la
multiplicidad, examinando el ejemplo de la Figura
22.15. En este ejemplo un simple administrador dirige
a uno o mas empleados, y un solo empleado sera diri-
gido por un solo administrador. Esta asociaci6n se mues-
tra en la Figura 22.16.
m Empleado
FIGURA 22.17. Documentando una Asociacion.
22.5.5. Casos de uso

Anteriormente, en el Capitulo 21, se examinaron 10s
casos de uso. En UML, un caso de uso se documenta
de manera muy simple, en tkrminos de actores y de un
caso de uso. Un actor es cualquier agente que interac-
t6a con el sistema que se construye, por ejemplo el pilo-
to de un avi6n, un prestatario de libros de una libreria
o el jefe de 10s empleados en una compaiiia. Un caso de
FlGURA 22.15. Un ejemplo de una relacion simple en UML. USO documents acci6n que ejecuta; por
ejemplo, el prkstamo de un libro, el cambio de direc-
cion de un avidn o la adicidn de un miembro a un equi-
Aqui el 1 que se encuentra a1 final de la linea de aso- po de programacibn. Un caso de uso simple se muestra
ciacidn indica que un empleado solo es dirigido por un en la Figura 22.19. Se muestra el usuario de una biblio-
administrador; y el 1..* que se encuentra en el otro extre- teca que pide prestado un libro.
1 Universidad I La existencia de un gran numero de casos de uso sig-

nifica que habra algunos casos de uso que seran utili-
zados por otros casos de uso. Cuando esto sucede, el
Hospedar
Estudiante Miembro ,,.*

I( I
diagrama de casos de uso UML va a incluir una etiqueta
conocida corno un estereotipo <<uses>>, sobre la fle-
cha que conduce a1 caso de uso. Se muestra un ejemplo
en la Figura 22.21, la cual muestra algunos casos de uso,
C---l
Estudiante involucrados con un sistema para la administracidn de
productos en un almacCn (Warehouse). Por ejemplo, el
administrador del almacCn puede hacer una petici6n a
nivel de existencias de un producto en particular. A1 lle-
FIGURA 22.18. Documentando roles.
var a cab0 estas funciones, el administrador del alma-
cCn genera un numero de casos de uso, cada uno de 10s
El actor en este caso es el prestatario, que utiliza la cuales hacen uso de otro caso de uso, que valida el nom-
biblioteca, y el circulo ovalado muestra el caso de uso bre del producto a1 que se hace referencia en el caso de
con el mismo nombre debajo. Los casos de uso repre- uso para revisar; por ejemplo, que el administrador haya
sentan una vision, a un alto nivel funcional, de un sis- escrito un nombre de producto valido.
tema en UML. En general, un sistema grande debe Aqui, el hecho de que un caso de uso se emplee por
contener centenares, si no millares de casos de uso. Un otros casos, se indica por medio de una flecha con pun-
fragment0 de un grupo de casos de uso relacionados con ta hueca.
el mismo actor se muestra en la Figura 22.20.
-
Consultar producto
/ \
Adrninistrador
del alrnacen,
- ccusesn
Prestatario Pedir prestado un libro 1 \ Consultar nivel

/v,
ccusesn
Validar
producto
FIGURA 22.19. U n caso de uso sencillo. de us0 asociados
con un administrador
del alrnacen Consultar detalles
Muestra algunas de las acciones que un administra-
dor de proyecto debe llevar a cabo, cuando interactua de orden
con un sistema de administracih de proyectos.
FIGURA 22.21. Un ejemplo de casos de uso utilizando otro
caso de uso.
22.5.6. Colaboraciones
Administrador \ Emitir informe de estado
Durante la ejecucidn de un sistema orientado a obje-
tos, 10s objetos interactuaran con cada uno de 10s otros.
Por ejemplo, en un sistema bancario, un objeto Cuen-
ta puede enviar un mensaje a un objeto transaccion
para crear una transaccion que ha ocumdo en una cuen-
ta, por ejemplo una cuenta de cargo. Este tipo de infor-
\ maci6n es importante para el diseiiador de un sistema
I Seleccionar plantilla
orientado a objetos, durante el proceso de la identifi-
cation y validacion de clases. Por esta razon, UML
tiene dos notaciones equivalentes para definir las inte-
racciones. En este libro nos centraremos so10 en uno:
el diagrama de secuencias; el otro diagrama se cono-
Terminar proyecto
ce corno diagrama de colaboracion, y es equivalente
a1 diagrama de secuencia; de hecho, son tan similares
lniciar Proyecto que las herramientas CASE pueden normalmente cre-
ar un diagrama, a partir de una instancia o de la otra.
La Figura 22.22 muestra un ejemplo simple de un dia-
FIGURA 22.20. Un conjunto de casos de uso. grama de secuencias.
C A P ~ T U L 2O2 DISENO ORIENTADO A OBIETOS
En este diagrama existen tres objetos, 10s cuales Aqui un actor, representado por un objeto an6nimo
se involucran en una interacci6n. El primer0 es el definido por la clase InformeBalance, envia un men-
objeto administrador descrito por la clase Emplea- saje a1 objeto cuenta, que consulta la cuenta.
do. Esto envia un mensaje actualizarlnforme a un Este objeto comprueba si es una cuenta vhlida, y lue-
objeto llamado informeventas, el cual envia un men- go envia un-mensaje generarlnformeBalance a un obje-
saje crearTransacci6n a un objeto transaccidn- to informeBalance, que contiene 10s datos requeridos
Ventas. por el cliente del banco.
[ZtEi
[G) )F]
adminisfrador: 22.5.7. Diagramas de estado
Otro componente importante de UML es el diagrama
de estado. Este muestra 10s diferentes estados en que un
actualizar lnforme ; objeto se encuentra, y c6mo se dan las transiciones de
F
u
n: crearTransaccion :
cada estado a otros estados. Tal diagrama contiene 10s
siguientes componentes:
Estados: se muestran dentro de cuadros, con esqui-
: cambiar Detalles : nas redondeadas.
U Transiciones entre estados mediante flechas.
FIGURA 22.22. U n diagrama d e secuencia sencillo. iQue es un diagrama

de estados?
En el diagrama de secuencia existen tres objetos Sucesos que provocan las transiciones entre estados.
involucrados, uno de ellos (administrador) tiene su
clase especifica (Empleado), 10s otros no. Los con- Marca de inicio, que muestra el estado inicial, en el
tenidos en 10s cuadros de un diagrama de secuen- que un objeto se encuentra cuando se crea.
cia pueden contener solo el nombre del objeto, el Marca de parada (fin), que indica que un objeto ha
nombre de un objeto junto con su clase separado alcanzado el-final de su existencia (vida).
por dos puntos, o solo el nombre de una clase pre-
cedida de dos puntos; en este dltimo caso, el obje-
to es an6nimo.
La Figura 22.22 tambiCn muestra el rol de un actor
dentro de una colaboraci6n: aqui el actor ClienteBan-
co y ViejoCliente, interactda con el administrador del
objeto Empleado, enviando un mensaje cambiarDe-
/
CerrarCuenta
tulles.
La Figura 22.23 muestra otro ejemplo de un diagra-
ma de secuencias.
Transaccion
u : comprobar-
CuentaValida ;
FIGURA 22.24. Ejemplo d e u n diagrama de estados.
Un ejemplo de diagrama de estados se muestra en la

Figura 22.24.
Aqui se muestra el ciclo de vida de una cuenta ban-
caria. Cuando la cuenta se crea, se visualiza como una
cuenta vacia. Hasta que una transacci6n se lleve a cab0
(10s fondos depositados o retirados de la cuenta se visua-
lizan como una cuenta activa). El diagrama de estado
tambiCn muestra que, cuando una cuenta se cierra, se
FIGURA 22.23. Otro ejemplo de diagrama d e secuencia. destruye.
INGENIERiA DEL SOFTWARE. U N ENFOQUE P R h C T I C O
El objetivo de esta secci6n es mostrar el uso de diagra- 6. El sitio web deberi interactuar con un sistema de
mas UML, descrito en la Secci6n 22.25, aplicado a un control de inventario, que tambiCn requiere desarro-
sistema real. Este sistema es un sistema de comercio 110. Este sistema de control de inventarios debe mane-
electr6nico (e-commerce). jar el proceso de recepcidn de libros de 10s inventatios
de las editoriales, retiro de libros cuando se ordenan
por parte de un cliente, y reordenaci6n de existencia
de un libro, cuando se encuentra por vaciarse, para
Libros-en-linea es una compaiiia creada reciente- encarar un problema de suministros, en un tiempo
mente, que es subsidiaria de otra gran compaiiia mul- de siete dias.
tinacional de comercio, conocida como Pollday 7. El control de inventarios por parte del administrador
Publishing. Los directores de Pollday Publishing se seri fijado en un tiempo de siete semanas. ~l o ella
decidieron a llevar a cab0 un gran crecimiento en ven- tendrin la responsabilidad de mantener las ventas, y
tas por internet entre sus clientes, y decidieron pre- la disponibilidad de existencias y, cuando las exis-
parar a Libros-en-Linea para ello. El concept0 que tencias de un libro se encuentren bajas, hacer un
Pollday tiene es el de un sitio Web de comercio elec- nuevo pedido. Para realizar esto, este sistema de con-
tr6nic0, que tenga catilogos detallados de cada libro trol de inventarios debe proporcionar informes de
que manejan, junto con recursos con 10s que el usua- ventas y existencias de inventario con regularidad.
rio del sitio Web puede ordenar libros, utilizando una 8. Un Administrador de Marketting intemendrii cada
forma incluida en una pigina Web. A continuaci6n, ocho semanas. El Jefe de Marketting tendri la fun-
se muestran algunos extractos, tornados del conjun- ci6n de determinar 10s precios a 10s que 10s libros
to de requisitos iniciales, detallados por el equipo tCc- serin vendidos. Se dari la situaci6n de que un libro
nico de Libros-en-linea: puede tener un numero diferente de precios durante
Libros-en-linea desea desarrollar la capacidad de su tiempo de vida; por ejemplo, se debe decidir si se
ventas en linea por medio de la Web. EL sitio web ofrece con un mayor descuento durante las primeras
que implementa esta capacidad debe permitir a1 semanas, y luego ajustar el precio a 10s precios reco-
cliente examinar 10s detalles del libro, ordenarlo y mendados por las editoriales.
registrar su direcci6n de correo electr6nico para reci- La cornpailia que desarroll6 el software para Libros-
bir ofertas especiales con detalles, publicaciones nue- en-linea, primer0 identific6 un numero de clases candi-
vas y revisiones. datas, que a continuaci6n se detallan:
Cuando un cliente accede al sitio Web, cada uno de RegistroCliente. Detalles de alguien que compra
10s recursos antes descritos se despliegan. libros, o que se registr6 para recibir correos electro-
Si el cliente registra su direcci6n de correo electronicos con informaci6n.
nico, se le preguntarin su informacion personal. Esto Libro. El articulo principal, quC Libros-en-linea
incluye su nombre, una direcci6n de correo electr6- vende.
nico, una direcci6n postal. Un miembro del equipo Orden. Una orden que un cliente realiza, para uno
conocido como el administrador de contratos sera el o mis libros. Esta orden debe ser para una simple
responsable de enviar informaci6n de oferta, etc., a copia de un libro, o para copias de un numero de
10s clientes. libros o incluso multiples copias de muchos libros.
El cliente podri comprar libros del catilogo en Una orden contendri un numero de lineas de orden
linea, examinando las piginas con detalles de 10s (vCase a continuaci6n), y una especificacion de envio.
libros y seleccionando el libro, que comprarii LineaDeOrden. Esta es una simple linea de orden.
mediante algun mecanismo como el de presionar Por ejemplo la orden de la copia de un libro. Una
un boton. El sistema deberii mantener un carrito de orden consistiri en una o mis lineas de orden. Una
compras virtual, en el que 10s detalles de cada libro linea de orden contendri informacion acerca de
se almacenan. Conforme el carrito se va llenando quC libro se ordena y la cantidad ordenada (usual-
de libros, se muestra a1 cliente el precio acumulado mente 1).
de todas sus compras. Carrito. Es un contenedor que existe durante la
Cuando el cliente ha terminado de comprar en el sitio exploration del sitio Web, por parte de un cliente que
Web, se le pediri informacion acerca de qut forma realiza una orden. Los contenidos del carrito serin
de envio se utilizari. Por omision se mostrara la lineas de orden. Cuando un cliente complete una
opcion de envio por correo estindar, y un servicio orden, las lineas de orden del carrito y la informa-
de envio expreso garantizado para entregar dentro cion de envio proporcionada por el usuario serin ane-
de 24 horas. xadas a una orden.
C A P ~ T U L O2 2 DISENO ORIENTADO A O B J E T O S
OrdenEspera. Esta es una parte de la orden, la cual Estas fueron, entonces, las clases identificadas princi-
no puede cumplirse por las existencias del almacCn. palmente. TambiCn se identificaron un nlimero de actores:
Si el cliente esti conforme, esperando por un libro Cliente. Este es el actor principal: la persona que
que no esti en existencia, entonces se realiza una lleva a cab0 las acciones, que resultan en 10s mayo-
orden de espera. Esta orden de espera se satisface, res cambios de estado del sistema.
cuando las existencias del libro se restauran por Administrador de marketting. Es un actor importante
Libros-en-linea. que ajusta muchos de 10s parimetros del sistema,
Almacen. Esta es una colecci6n de libros que se tales como el precio de 10s libros.
encuentran en existencia. Una orden de libro o de Administrador del control de inventarios. Alguien
colecci6n de libros se manda a1 almacCn y de ahi que controla 10s inventarios en un almacCn y toma
se retiran 10s libros de sus cajas del almacCn, se decisiones acerca de las 6rdenes.
empaquetan y se despachan a1 cliente. En ese Existen un gran nlimero de casos de uso asociados
momento, se ajustan 10s detalles de las existen- con estas acciones, muchas de ellas asociados con el
cias. actor cliente, se muestran en la Figura 22.25.
RegistroExistencias. Estos son 10s datos que des- La selecci6n de casos de uso asociados con el Cliente, y
criben 10s detalles de las existencias de un libro; las mostradas en la Figura 22.25 incluyen casos de uso para:
por ejemplo, cuintos hay en existencia, el nivel Registro. Aqui el cliente proporciona su nombre y
actual cuando se ha hecho una requisicidn a las edi- su clave. Una vez registrada, pueden examinar el
toriales, y la localizaci6n de 10s libros dentro del catilogo de libros.
almacCn. Ordenar.Aqui el cliente ordena una o mis copias de
NotaEmpaque. Esta es una nota enviada con una un libro.
colecci6n de libros a1 cliente. La nota de empaque Realizar. El cliente completa la orden y ordena a1 sis-
contiene informaci6n acerca de cuintos libros se tema iniciar el proceso en que la orden se despacha.
enviaron y la tarifa de envio aplicada. TambiCn puede Buscar un libro. El cliente busca, en el catilogo en
contener detalles de algunos libros, que no pudieron linea, un libro especifico.
ser enviados porque no se encontraban en las exis- Eliminar tarjeta de crkdito. Aqui el cliente puede eli-
tencias. minar una o mis de las tarjetas de crCdito registra-
TarjetaCredito. Un cliente pagari por sus libros das y asociadas con 61.
mediante una tarjeta de crCdito. El sistema permite Registrar tarjeta de crkdito. Aqui el cliente registra
a1 cliente pre-registrar su o sus tarjetas, para que una o mas de sus tarjetas de crCdito a1 sistema.
no tenga que reescribirlas cada vez que haga una
Una porcion de uno de estos diagramas de clase para
orden.
el sistema, se muestra en la Figura 22.26. Un nlimero
de roles asociados con el diagrama se ha omitido; regu-
larmente se incluyen. Algunas de las relaciones entre
clase, tambiCn se omitieron.
El diagrama muestra muchas de estas clases antes
Registro
d
/ descritas. Las linicas clases que se omitieron son:
OrdenSatisfecha y OrdenEspera. Estas dos clases son
especializaciones de la clase Orden, que representa una
orden de libros para un cliente.
A, Cornprobar pedido
u..
t \ Encontrar libro
Borrar tarjeta
de credito
de la tarjeta f
I a Libro
Registrar almacenado
tarjeta de credito
FIGURA 22.26. Una seccion de un diagrama de clases
FIGURA 22.25. Algunos casos de uso para el actor Cliente. para el caso de estudio.
399
C A P ~ T U L O22 DISENO ORIENTADO A OBIETOS
cliente y su direccion; ambos se expresan como cade- La palabra clave String especifica que esta operacion
nas de caracteres. Normalmente, en un sistema real exis- devolveri una cadena, y la palabra clavepublic descri-
ten muchos mis atributos asociados con la clase. La be el hecho de que cualquier c6digo de cualquier otra
descripcidn del atributo incluye su tip0 (String) y su clase puede hacer uso de esta operacion: public es el
visibilidad. En el ejemplo anterior, a 10s dos atributos opuesto de la palabra clave private, detallada en el p h a -
mostrados se les asigna la visibilidad de privados. Esto fo anterior.
significa que pueden ser accedidos por cualquier c6di- El codigo para esta operacion se encierra con llaves
go dentro de la clase per0 no por alguno fuera de ella; ( ( } ) de operaci6n.
por ejemplo, el c6digo que pertenece a otra clase. Esto La operacion modificarDireccidnCliente difiere en
significa que las variables de instancia se encapsulan dos cosas de la operaci6n obtenerNombreCliente. En
dentro de la clase. Existen otros modificadores de visi- primer lugar, le antecede la palabra void; esto indica que
bilidad en Java: Se encontrari con otro despuCs, cuan- no hay resultado que regresar de la operacion: la ope-
do se describan las operaciones de una clase. raci6n solo lleva a cab0 acciones que modifican 10s atri-
butos de la clase. En segundo, la operaci6n asociada con
[Gi)DeOrden [=I
[G) el argumento direccidn, que es una cadena que repre-
senta la nueva direccion de un cliente, que reemplaza-
r i a la anterior.
Esto, entonces, es la forma bisica de una clase en
Java; es muy similar en muchas formas a la estructura
de clases expresada para 10s lenguajes orientados a obje-
u-
AjustarNivelStock
tos, con excepcidn de SmallTalk. A continuacion, se
muestra el c6digo completo de una clase muy simple.
La clase representa un contador, que es un dispositivo
que sirve para registrar el nlimero de veces que una pagi-
na web ha sido accedida por visitantes de un sitio Web.
class Contador i
private int veces;
public Contador ( int valorInicio )
i
FIGURA 22.27. Un diagrarna de secuencia para el caso de veces = valorInicio;
estudio.
i
public void ajustaContador( int valor )
TambiCn se han mostrado dos operaciones dentro de i
la clase Cliente. La primera es la operaci6n obtener- veces = valor;
NombreCliente, que devuelve el nombre del cliente des- i
crito por la clase. public int obtenerCuenta ( )
i
return veces;
i
public void incrementacuenta ( )
i
vecestt;
i
i
La clase denominada Contador tiene un atributo
veces, que registra el nlimero de veces consultado por
Cancelar usuarios. La siguiente operaci6n tiene el mismo nom-
de libro Seleccionar
bre de la clase, y se conoce como constructor. Este es
Transporte
un fragment0 de c6digo ejecutable, que se ejecuta cuan-
do el objeto se crea, recibe un argumento entero que es
el valor inicial del contador. Cuando el usuario de la
clase desea crear un objeto contador, el c6digo es el
siguiente:
Contador cont = new Contador( 0 );
CancelarOrden La palabra clave new llama a1 constructor para crear

un objeto contador que tiene un solo atributo veces ini-
FIGURA 22.28. U n diagrarna de estados. cializado a cero.
I
INGENIER~A
La operaci6n obtenerCuenta regresa el valor actual del RecuCrdese que, en la herencia, las operaciones en
contador, la operaci6n ajustacontador ajusta el atributo la superclase (en nuestro clase Contador) se heredan por
veces a un valor dado por su argumento, y la operaci6n la superclase (en nuestro caso TiempoContador), a
incrementacuenta incrementa el atributo veces en uno (la menos que se sobrecarguen.
operaci6n ++ es la operaci6n de increment0 en uno). La primera operaci6n ajustacontador, sobrecarga a1
La sintaxis de Java para enviar mensajes a1 objeto es mCtodo correspondiente en la superclase. Primero ini-
la siguiente: cializa el atributo veces dentro de la superclase, hacien-
0bjeto.nombreOperacidni argumentos ) do una llarnada a su constructor (la palabra clave sdper
se utiliza para ello), y luego se construye un nuevo obje-
Por ejemplo para incrementar un objeto Contador to Time. Este objeto se define en cualquier otro lugar, y
cont el c6digo seria: no se debe mostrar el c6digo. La operaci6n ajustacon-
cont.incrementacuenta( j ; tador tambiCn sobrecarga la operacidn correspondiente
La clase anterior es muy simple; de cualquier modo, dentro de Contador. El c6digo dentro de la clase prime-
s i n e para ilustrar las caracteristicas estructurales prin- ro inicializa el atributo de la superclase,para que sea igual
cipales de c6mo se define una clase. Existen otras com- a valor. Luego envia un mensaje setNow a1 ambuto hora-
plicaciones, como el hecho de que pueden definirse varios Acceso, para ajustar su valor a la hora actual, el c6digo
niveles de visibilidad; de cualquier modo, esto queda para la operaci6n setNow forma parte de la clase Time y
fuera del alcance de un libro de ingenieria del software. no se muestra. El mCtodo obtenHora es simple: todo lo
Existen dos maneras de combinar clases: la primera que hace es regresar el valor de horaAcceso. La opera-
es la herencia y la segunda es la agregacion. Los lenguajes ci6n incrementaCuenta sobrecarga la operaci6n corres-
de programaci6n orientada a objetos contienen recursos pondiente en la clase Contador. Primero incrementa el
que permiten a ambas ser implementadas fzicilmente. valor de veces, llamando a la operaci6n incrementacuenta
En Java, la palabra clave extends se utiliza para deri- dentro de la superclase, luego ajdstale valor de horaAc-
var una clase de una ya existente por medio de la heren- ceso, enviando un mensaje setNow a1 objeto. El mCtodo
cia. Por ejemplo, asdmase que se necesita derivar una obtencuenta, heredado de la clase Contador, no necesi-
clase nueva, que se parece mucho a la clase Contador, ta ser sobrecargada, ya que todo lo que hace es regresar
per0 que ademhs registra la hora a la que la cuenta se el valor del ambuto veces, dentro de la superclase.
increment6 El esqueleto de la nueva clase, que hereda Esto es, como un lenguaje de programaci6n orienta-
la clase Contador, se muestra a continuaci6n: do a objetos implementa la herencia. La implementaci6n
class TiempoContador extends Contadori de la agregaci6n es m6s simple: todo lo que involucra
// Algunos atributos nuevos es la inclusidn de las partes agregadas como atributos de
// Algunas operaciones nuevas. clase. Por ejemplo, la clase siguiente Computadora,
I representa a una computadora; forma parte de un siste-
ma para planificar la fabricaci6n de computadoras. Una
La palabra clave extends especifica el hecho de que
computadora es agregada desde un monitor, un teclado,
la clase TiempoContador se hereda de la clase Conta-
una unidad de proceso y asi sucesivamente. Esto se mues-
dor. El c6digo para la clase se muestra a continuaci6n:
tra en la clase como una sene de atributos.
class TiempoContador extends Contadori
class Computer 1
Time horadcceso;
private Moni tor mon ;
pub1 ic TiempoContador( int valorInicio )
private KeyBoard kb;
private Processor proc;
super( valorInicio j; // dema's atributos
horaAcceso = new Time horaAcceso( ); //dehicidn de las operaciones asociadas con
la computadora.
public void ajustaContador( int valor j I
super.ajustaContador( int valor ); Como un ejemplo final de c6digo en Java, se ha
horaAcceso.setNow( j; reproducido mucho del c6digo para un cliente, del
I pequefio caso de estudio mostrado en la Secci6n 22.6.
public Time obtenHora ( j Un cliente es alguien que comprarh libros usando inter-
i net. El c6digo para muchos de 10s mktodos se encuen-
return horaAcceso; tra a continuacih:
I class Cliente
public void incrementacuenta( ) i
i String nombre, direccidn, tipoTarjetaCredito,
super.incrementacuenta( ) ; clave, infoseguridad;
horaAcceso.setNow( ); HistorialCompras Hc;
OrdenesActuales ordenesA;
Preferencias pref;
C A P ~ T U L O22 DISENO ORIENTADO A O B J E T O S
Public obtenPrefCliente( ) i
return Hc;
return pref; i
i public void inic0rdenesA ( )
public String obtenerNombre( ) i
//utiliza el metodo setclear de Ordenes-
return nombre; Actuales para
i //inicializar las ordenes actuales
publ ic String obtenDireccion( j ordenesA.setclear ( ) ;
i
return direccion; publ ic void agregaordeni Orden ord )
i i
publ ic String obtenTipoTajetaCredito ( ) //Utiliza el metodo addcurrentorders de
OrdenesActuales
return tipoTarjetaCredito; ordenesA.addCurrentOrders(ord );
i I
public String obtenClave( ) public void borraordeni Orden ord }
return clave; //Utiliza el metodo removecurrentorder de

i OrdenesActuales
public String obtenInfoSeguridadi ) OrdenesA.removeCurrent0rder i ord ) ;
1
return infoseguridad; publ ic int num0rdenesActuales ( )
i
public void poniiombre( String nom ) //Utiliza el metodo no de la clase Orde-
i nesActuales
nombre = nom; return OrdenesA.no( 1 ;
i
public void ponDireccion i String dir ) public OrdenesActuales obtenOrdenesActuales( )
i i
direccion = dir; return OrdenesA;
i
public void ponTipoTarjetaCredito ( String ttc )
i
tipoTarjetaCredito = ttc; Muchos de 10s mCtodos son muy simples: todo lo que
i hacen es o ajustar u obtener 10s valores de 10s atributos
public ponClave ( String clv )
que se encuentran en la clase Cliente. Estos atributos son:
clave = clv; nombre. Nombre del cliente.
i direccibn. Direccion del cliente.
public void ponInfoSeguridad i String isg ) tipoTarjetaCre'dito.Una cadena que describe el tipo
de tarjeta de crkdito usada por el cliente.
infoseguridad = isg; clave. La cadena usada por el cliente, para acceder
1 a1 sitio de venta de libros.
public void ponPreferencias( String prf )
i
infoseguridad. Esta es una cadena que se utiliza por
pref = prf; el cliente, para identificarse con el equipo de servicio
i del sitio, en caso de que se olvide su clave. Por ejem-
public void iniciaHistCompras( ) plo, puede contener el lugar de nacimiento del cliente.
i Hc. Es el historial de 10s libros que el cliente ha com-
//inicializa el historial de compras con prado.
el metodo setclear
ordenesA. Contiene 10s detalles de cada orden, que
Hc.setClear( );
i se lleva a cab0 en ese momento; por ejemplo, una
public void agregaTransCompra(TransCompra tc ) orden que no puede ser satisfecha completamente.
pref. Contiene una lista de preferencias de compra
//utiliza el metodo add definido en Histo- para el cliente. Por ejemplo, el hecho de que el cliente
rialCompras para normalmente compra novelas de terror.
//agregar un libro a la transacci6n de
compras a1 objeto Existe un grupo de mitodos, que pueden llamar a
//Cliente mitodos definidos en otras clases; por ejemplo, el mito-
Hc.add( tc I ; do borraorden, que elimina una orden de 10s detalles
i de cliente, y utiliza el mitodo removeCz4rrentOrder de
publ ic His tCompras obtenHistCompras ( ) la clase OrdenesActuales.
El disefio orientado a objetos traduce el modelo de Durante el diseiio del sistema, la arquitectura del sis-
A 0 0 del mundo real, a un modelo de implementaci6n tema orientado a objetos se desanolla. Ademas del desa-
especifica, que puede realizarse en software. El pro- rrollo de sistemas, de sus interacciones y de su colocaci6n
ceso de D O 0 puede describirse como una piramide dentro de las capas arquitectonicas, el disefio de sistemas
compuesta por cuatro capas. La capa fundamental se considera la componente de interaccion con el usuario,
centra en el disefio de subsistemas, que implementan una componente de administration de tareas y una com-
funciones principales de sistema. La capa de clases ponente de rnanejo de datos. Estas componentes de sub-
especifica la arquitectura de objetos global, y la jerar- sistemas proporcionan la infraestructura de disefio, que
quia de clases requerida para implernentar un sisterna. permite a la aplicacion operar efectivamente. El proceso
La capa de mensajes indica como debe ser realizada de diseiio de objetos se centra en la description de estruc-
la colaboracion entre objetos, y la capa de responsa- turas de datos, que usan 10s atributos de clase, 10s algo-
bilidades identifica las operaciones y atributos que ritmos que usan las operaciones y 10s mensajes que
caracterizan cada clase. permiten colaboraciones entre objetos relacionados.
A1 igual que el AOO, existen diferentes mCtodos de Los patrones de disefio permiten a1 disefiador crear
DOO. UML es un intento de proporcionar una aproxi- la arquitectura de disefio integrando componentes reu-
macion simple a1 DOO, que se aplica en 10s dominios sables. La prograrnacion 00 extiende el modelo de dise-
de aplicaciones. UML y otros mCtodos, aproximan el fio a un dorninio de ejecucion. Un lenguaje de
proceso de diseiio mediante dos niveles de abstraccion programacion 00 se usa para traducir las clases, atri-
4 i s e i i o de subsistemas (arquitectura) y diseiio de obje- butos, operaciones y mensajes, de manera que puedan
tos individuales-. ejecutarse por la maquina.
[BEN991 Bennett, S., S. McRobb y R. Farmer, Object [GAM95] Gamma, E., et al., Design Patterns, Addison-
Oriented System Analysis and Design Using U M L , Wesley, 1995.
McGraw Hill, 1999.
[GOL83] Goldberg, A., y D. Robson, Smalltalk-80: The
[BIH92] Bihari, T., y P. Gopinath, ((Object-Oriented Real- Language and Its Implementation, Addison-Wesley,
Time Systems: Concepts and Examples,>,Computer, vol. 1983.
25, n." 12, Diciembre 1992, pp. 25-32.
[JAC92] Jacobson, I., Object-Oriented Software Enginee-
[BOO941 Booch, G., Object-OrientedAnalysis and Design, ring, Addison-Wesley, 1992.
2.%d., Benjamin Cummings, 1994. [JAC99] Jacobson, I., G. Booch y J. Rumbaugh, Unified
[BOO991 Booch, G., I. Jacobson y J. Rumbaugh, The Uni- Software Development Process, Addison-Wesley, 1999.
fied Modelling Language User Guide. Addison-Wesley, [MEYBO] Meyer, B., Object-Oriented Software Construc-
1999. tion, 2.%d., Prentice-Hall, 1988.
[BR091] Brown, A.W., Object-Oriented Databases, [PRE95] Pree, W., Design Patterns for Object-Oriented
McGraw-Hill, 1991. Software Development, Addison-Wesley, 1995.
[BUS961 Buschmann, F., et al., A System of Patterns: Pat- [RUM911 Rumbaugh, J., et al., Object-Oriented Modelling
tern Oriented System Architecture, Wiley, 1996. and Design, Prentice-Hall, 1991.
[COA91] Coad, P., y E. Yourdon, Object-Oriented Design, [RUM991 Rumbaugh, J., I. Jacobson y G. Booch, The Uni-
Prentice-Hall, 1991. fied Modelling Language Reference Manual, Addison-
Wesley, 1999.
[COX851 Cox, B., ((Software Ics and Objective-C>>,Unix-
World, primavera de 1985. [RA094] Rao. B.A., Object-Oriented Databases: Tech-
nology, Applications and Products, McGraw-Hill,
[DAV95] Davis, A . , <<Object-OrientedRequirements to 1994.
Object-Oriented Design: An Easy Transition?,,, J.Sys-
tems Software, vol. 30, 1995, pp. 151-159. [TAY92] Taylor, D.A., Object-Oriented Information Sys-
tem, Wiley, 1992.
[DOU99] Douglass, B., Real-TimeUML: Developing Effi-
cient Objects for Embedded Systems, Addison-Wesley, [WIR90] Wirfs-Brock, R., B. Wilkerson y L.Weiner, Desig-
1999. ning Object-Oriented Software, Prentice-Hall, 1990.
CAPfTULO 2 2 D I S E N O ORIENTADO A O B J E T O S
21.1. La pirimide de diseiio para el D O 0 difiere, de alguna 21.12. Aplique el enfoque del D O 0 examinado anteriormen-
manera, de la descrita para el diseiio del software conven- te en este capitulo, para diseccionar el diseiio del sistema
cional (Capitulo 13). Vea las diferencias y semejanzas de HogarSeguro. Defina todos 10s subsistemas relevantes, y desa-
ellas dos. rrolle el diseiio de objetos para las clases importantes.
21.2. iC6m0 difieren el D O 0 y el estructurado? ~ Q u Caspec- 21.13. Aplique el enfoque del D O 0 examinado en este capi-
tos de estos dos mCtodos de diseiio son 10s mismos? tulo a1 sistema SSRB descrito en el problema 12.13.
21.3. Revise 10s cinco criterios para la modularidad eficaz exa- 21.14. Describa un juego de video y aplique el enfoque del
minados en la Seccidn 22.1.2. Usando el enfoque de diseiio D O 0 examinado en este capitulo, para representar su diseiio.
descrito posteriormente en el capitulo, demuestre cdmo se
logran estos cinco criterios. 21.15. Usted es responsable del desarrollo de un sistema de
correo electrdnico a implementarse sobre una red de PC. El
21.4. Seleccione uno de 10s mCtodos de D O 0 presentados en sistema de e-mail permitira a 10s usuarios escribir cartas diri-
la Seccidn 22.1.3, y prepare un tutorial de una hora para su gidas a otro usuario o a una lista de direcciones especifica.
clase. Aseg6rese de mostrar todas las convenciones graficas Las cartas pueden ser enviadas, copiadas, almacenadas, etc.
de modelado que sugiere el autor. El sistema de correo electrdnico hara uso de las capacidades
21.5. Seleccione un mCtodo de D O 0 no presentado en la Sec- de procesamiento de texto existentes para escribir las cartas.
cidn 22.1.3, (por ejemplo, HOOD), y prepare un tutorial de Usando esta descripcidn como punto de partida, derive un
una hora para su clase. Aseg6rese de mostrar todas las con- conjunto de requisitos, y aplique las tCcnicas de DOO, para
venciones graficas de modelado que sugiere el autor. crear un diseiio de alto nivel, para el sistema de correo elec-
trdnico.
21.6. Analice cdmo 10s casos de uso pueden servir como una
fuente importante de informacidn para el diseiio. 21.16. Una nacidn ubicada en una pequeiia isla ha decidido
21.7. Investigue un entomo de desarrollo IGU, y muestre cdmo construir un sistema de control de trafico akreo (CTA) para su
el componente de interaccidn hombre-mfiquina se implemen- dnico aeropuerto. El sistema se especifica como sigue:
ta en el mundo real. ~ Q u C
patrones de diseiio se ofrecen y cdmo Todos 10s aviones que aterrizan en el aeropuerto deben
se usan? tener un transmisor que transmita el tip0 de avion y 10s
datos del vuelo en un paquete, con formato de aka densi-
21.8. La gestidn de tareas en sistemas 00 puede ser muy com- dad, a la estaci6n de CTA de tierra. La estacidn de CTA de
pleja. Realice alguna investigacidn sobre mCtodos de DOO, tierra puede interrogar a un avibn, para solicitar informa-
para sistemas en tiempo real (por ejemplo, [BIH92] o ci6n especifica y almacenarla en una base de datos de avio-
[DOU99]) y determine cdmo la gestidn de tareas se realiza nes. Se crea un monitor de graficos por ordenador, a partir
dentro de este contexto. de la information almacenada, y se la muestra a un con-
21.9. Examine cdmo el componente de manejo de datos se trolador de trifico. El monitor se actualiza cada 10 segun-
implementa en un entomo de desarrollo 00 tipico. dos. Toda la informaci6n es analizada, para determinar si
existen ccsituaciones peligrosas~.El controlador de trifico
21.10. Escriba un articulo de dos o tres pagina sobre bases de akreo puede interrogar la base de datos, para buscar infor-
datos orientadas a objetos, y analice cdmo pueden usarse, para maci6n especifica acerca de cualquier avi6n que se mues-
desarrollar el componente de gestidn de datos. tre en pantalla.
21.11. iC6m0 reconoce un diseiiador las tareas que deben ser Usando el DOO, Cree un disefio para el sistema de CTA.
recurrentes? No intente implementarlo.
Ademas de las muchas referencias de este capitulo, 10s libros dos en la seccidn otras lecturas y fuentes de informacidn del
de Gossain y Graham (Object modelling and Design Strate- Capitulo 21 tambiCn se centran en el diseiio con un nivel de
gies, SIGS Books, 1998), Meyer (Object-Oriented Design detalle considerable.
Through Heuristics, Addison-Wesley, 1996), y Walden, Jean- El uso de patrones de diseiio para el desarrollo de soft-
Marc Nerson (Seamless Object-Oriented Software Architec- ware orientado a objetos tiene importantes implicaciones
ture: Analisis and Design of Reliable Systems, Prentice-Hall, para la ingenieria del software basada en componentes, la
1995) cubren con bastante detalle el DOO. Fowler (Refacto- reutilizacidn en general y la calidad global de 10s sistemas
ring: improving the Design of Existing Code, Addison-Wes- resultantes. Ademas de [BUS961 y [GAM95], muchos libros
ley, 1999) dirige el uso de tecnicas orientadas a objetos para recientes dedican sus paginas a1 mismo tema, como 10s
rediseiiar y reconstruir programas antiguos con el fin de mejo- siguientes:
rar su calidad de diseiio. Ambler, S.W., Process Patterns: Building Large-Scale
Muchos libros de diseiio orientado a objetos publicados Systems Using Object Technology, Cambridge University
recientemente enfatizan UML. El lector seriamente interesa- Press, 1999.
do en aplicar UML a su trabajo debe adquirir [B0099], Coplien, J.O., D.C. Schmidt, Pattern Languages of Pro-
[RUM991 y [JAC99]. Ademas, muchos de 10s libros referi- gram Design, Addison-Wesley, 1995.
INGENIERiA DEL SOFTWARE. U N ENFOQUE P R A C T I C O
Fowler, M., Analysis Patterns: Reusable Object Models, Eiffel: Thomas, P., y R. Weedon, Object-Oriented Pro-
Addison-Wesley, 1996. gramming in EzFeI, Addison-Wesley, 1997.
Grand, M., Patterns in Java, vol. 1, John Wiley, 1998. Jezequel, J.M., Object-Oriented Software Engineering
Langr, J., Essential Java Style: Patterns for Implementa- With Ezffel, Addison-Wesley, 1996.
tion, Prentice-Hall, 1999. Java: Coad, P., M. Mayfield y J. Kern, Java Design: Buil-
Larman, C., Applying Unl and Patterns: An Introduction ding Better Apps and Applets, 2.%d., Prentice-Hall, 1998.
to Object-Oriented Analysis and Design, Prentice-Hall, 1997. Lewis, J., y W. Loftus, Jal*aSoftware Solutions: Founda-
Martin, R.C., et al., Pattern Languages of Program Design tions of Program, Addison-Wesley, 1997.
3, Addison-Wesley, 1997. Smalltalk: Sharp, A., Smalltalk by Example: The Develo-
Rising, L., y J. Coplien (eds.), The Patterns Handbook: per's Guide, McGraw-Hill, 1997.
Techniques, Strategies, andApplications, SIGS Books, 1998. LaLonde, W.R., y J.R. Pugh, Programming in Smalltalk,
Pree, W., Design Patterns for Object-Oriented Software Prentice-Hall, 1995.
Development, Addison-Wesley, 1995. Los libros que cubren temas de DOO, mediante el uso de
Preiss, B., Data Structures and Algorithms with Object- dos o mas lenguajes de programacion, proporcionan una idea
Oriented Design Patterns in Java, John Wiley, 1999. y comparacion de las capacidades de 10s lenguajes. Algunos
Vlissides, J., Pattern Hatching: Design Patterns Applied, titulos son:
Addison-Wesley, 1998. Drake, C., Object-Oriented Programming With C++ and
Vlissides, J.M., J.O. Coplien y N. Kerth, Pattern Lan- Smalltalk, Prentice Hall, 1998.
guages of Program Design 2, Addison-Wesley, 1996. Joyner, I., Objects Unencapsulated: Java, Ezffel and C++,
Cientos de libros de programacion orientada a objetos Prentice Hall, 1999.
(POO) han sido publicados. Una muestra de libros especifi- Zeigler, B.P., Objects and Systems: Principled Design With
cos en lenguajes de POO: Implementations in C++ and Java, Springer Verlag, 1997.
C++: Cohoon, J.P., C++ Program Design: An Introduc- Una amplia variedad de fuentes de informaci6n sobre dise-
tion to Programming and Object-Oriented Design, McGraw- Ao orientado a objetos, asi como temas relacionados, estan
Hill, 1998. disponibles en internet. Una lista actualizada de referencias
Barclay, K., y J. Savage, Object-Oriented Design With a sitios (paginas) web, que pueden ser relevantes a1 DOO,
C++, Prentice-Hall, 1997. pueden encontrarse en http://www.pressrnanS.com
PRUEBAS ORIENTADAS
A OBJETOS
Palabras clave L objetivo de las pruebas, expresado de forma sencilla, es encontrar el mayor numero
diseiio de wsos posible de errores con una cantidad razonable de esfuerzo, aplicado sobre un lapso de
de pruebas.. ........412 tiempo realists. A pesar de que este objetivo fundamental permanece inalterado para el
integration. ........ .41 1 software orientado a objetos, la naturaleza de 10s programas 00 cambian las estrategias y las
pnebaaleatoria.....416 tkticas de prueba.
proebaunitatia ......410 Puede argumentarse que, conforme el A 0 0 y el D O 0 maduran, una mayor reutilizacion de
pmebas a nivel
patrones de diseiio mitigarin la necesidad de pruebas intensivas en 10s sistemas 00. La verdad
dedases.......... ..416 es justo lo contrario. Binder [BIN94b] lo analiza, cuando afirma que:
pruebas ksados Cada reutilizacidn cs un nuevo context0 de uso y es prudente repetir las pruebas. Pasece probable que
en escenatios........41 5 se necesitasin menos pruebas para obtener una aha fiabilidad cn sistemas oricntados a objetos.
pruebas basadas La prueba de 10s sistemas 00 presentan un nuevo conjunto de retos al ingeniero del soft-
en fallos. ........412-413 ware. La definition de pruebas debe ser ampliada para incluir ticnicas que descubran errores
proebas (revisiones ticnicas formales), aplicadas para 10s modelos de A 0 0 y DOO. La integridad, com-
de descomposicibn ...416 pleci6n y consistencia de las representaciones 00 deben ser evaluadas conforme se constru-
pruebas yen. Las pruebas de unidad pierden mucho de su significado, y las estrategias de integraci6n
de estructura ........415 cambian de mod0 significativo. En resumen, las estrategias y tilcticas de prueba deben tomar-
pmebas interdases.. .417 se en cuenta para las caracteristicas propias del software 00.
revis5n Am........408
revision
d e l d o C R C ......409
rwisi6n Dm........409
validadh.. ........ . 4 1 1
aQu6 es? La arquitectura d e software la fmstraci6n asociada con un produc- basado e n usos y pruebas de agrupa-
orientado P objetos se manifiesta e n tode baja calidad. Con el prop6sito d e miento, junto con 1- enfoques basados
una serie de subsistemas organizados encontrar el mayor n6mero posible d e e n fallos, se aplican para probar
por capos. que encapsulan clases que errores, las pmebas deben conducirse exhaustivamente las clases colabora-
colaboran entre si. Cada uno de estos sistem6ticamente. y los c a m s de prue- doras. Por ultimo, 10s casos d e uso
elementos del sistema (subsistemas y ba deben ser designados mediante t k - (desarrolladoscomo parte del mode10
clases). realizan funciones que cryudan nicas disciplinadas. de andlisis 00)se usan para descubrir
o akanzur requerimientos del sistema. errores e n el software a nivel d e vali-
&Cu6lesson 10s pas-? Las pruebas
Es necesario probar un sistema 00, en daci6n.
00 son estrat&gkamente similares a
una variedad d e niveles diferenies, e n ~ C u d es
l el product0 obtenido? Se
las pmebas d e sisternasconvenciona-
un e s f u e m para descubrir errores. que diseiian y documentan un conjunto d e
les, per0 tdcticamente diferentes. Ya
deben ocurrir cuando las clases cola- casos d e prueba, diseiiados para p r e
que 10s modelos d e anblisis y diseiio
boran con otras entre si,y 10s subsis- bar clases, sus colaboraciones y com-
00 son similares e n estmctura y con-
temas se comunican por medio d e las portamientos; se definen 10s resultados
tenido a1 prcgrama 00,las *pmebasn
capas arquitecthicas. esperados, y s e registran 10s resulta-
cornienzan con la revisi6n d e estos
iQui6n lo hace? Los pruebas orienta- mcdelos. Una vez que se ha generado dos reales.
d a s a objetos s e realizan por ingenie- el c6digo. las pmebas 00 comienzan & k opuedo edm seguro de que la
ros d e software y especialistas e n men lo pequeiio* con l a s pruebas d e he hecho corredamente? Cuando
pruebas. . - . - .. - .
clases. Existen pruebas diseiiadas comienzan las pmebas, se cambla su
;Por qu€ies importante? Se debe eje- para probar las operaciones de las cla- punto d e vista. ilntenta .romper. el
cutar el prcgrama antes d e que llegue s e s y examinar si 10s errores existen software! Diseiiar 10s casos d e pmeba
a1 cliente, con la intenci6n especifica cuando una clase colabora con otras. de m a fonna disciplinada y revisar 10s
d e descubrir todos 10s errores, d e Asi como Ias clases se integran para casos de pmeba qua se crean con meti-
manera que el cliente no experimente formar un subsistema basado en hilos, culosidad.
La construcci6n del software orientado a objetos 3. El comportamiento del sistema o sus clases pueden
comienza con la creaci6n de 10s modelos de anilisis caracterizarse inadecuadarnente, para alojar el atri-
y diseiio (Capitulos 21 y 22). Debido a la naturaleza but0 irrelevante.
evolutiva del paradigma de ingeniena de software 0 0 ,
estos modelos comienzan como representaciones, rela- Si el error no se descubre durante el anilisis y se pro-
tivamente informales, de 10s requisitos del sistema, y paga mis alli, 10s siguientes problemas pueden ocurrir
evolucionan en modelos detallados de clases, cone- (y tendrfin que evitarse con una nueva revisi6n) duran-
xiones y relaciones de clases, el diseiio del sistema y te el diseiio:
el diseiio de objetos (incorporando un modelo de 1. La localizaci6n impropia de la clase a un subsistema
conectividad de objetos por medio de mensajes). En ylo tareas puede ocurrir durante el diseiio del sis-
cada etapa, 10s modelos pueden probarse, en un inten- tema.
to de descubrir errores, antes de su propagaci6n a la
siguiente iteracibn. 2. El trabajo del diseiio innecesario tendri que ser recu-
perado, para crear el diseiio procedimental, para las
operaciones que afecten a1 atributo innecesario.
3. El modelo de mensajes (mensajeria) seri incorrect0
(debido a que deben diseiiarse mensajes para las ope-
raciones innecesarias).
Si el error permanece sin detectarse durante el diseiio

y pasa a la actividad de codificaci61-1, se gastari un
esfuerzo considerablepara generar el c6digo que imple-
menta un atributo innecesario, dos operaciones innece-
Puede argumentarse que la revisi6n de 10s mode- sarias, mensajes que controlan comunicaciones entre
10s de anilisis y disefio 00 son especialmente 6tiles, objetos, y muchos otros aspectos relacionados. Ademis,
ya que las mismas estructuras seminticas (por ejem- la prueba de la clase absorberi mis tiempo del necesa-
plo, clases, atributos, operaciones, mensajes), apare- rio. Una vez que se encuentra el problema en su totali-
cen en 10s niveles. de anilisis, disefio y codificaci6n. dad, debe llevarse a cab0 la modificaci6n del sistema,
Por consiguiente, un problema en la definicion de 10s teniendo siempre presentes 10s posibles efectos colate-
atributos de las clases que se descubren durante el rales producidos por el carnbio.
anilisis evitari efectos laterales que pueden ocurrir
si el problema no se descubriera hasta el diseiio o
implementaci6n (o incluso la siguiente iteraci6n del
anilisis).
Por ejemplo, considkrese una clase en la que el n6me- Existe un viejo dicho que dice (ccorhrpor lo sono)).
ro de atributos se definen durante la primera iteraci6n Si pierde tiempo revisondo 10s modelos de A00
del A 0 0 . Un atributo externo (extraiio), se agrega a la y DOO, d e s p a lo gonorb.
clase (debido a1 malentendido del dominio de proble-
ma). Se especifican dos operaciones para manipular el
atributo. Se realiza una revisi6n y un experto en el domi- Durante las etapas finales de su desarrollo, 10s mode-
nio seiiala el error. Eliminando el atributo irrelevante 10s de A 0 0 y de D O 0 proporcionan informaci6n subs-
en esta etapa, 10s problemas y esfuerzos innecesarios se tancial acerca de la estructura y comportamiento del
evitan durante el anilisis: sistema. Por esta raz6n, estos modelos deben estar some-
tidos a una revisi6n rigurosa, antes de la generaci6n de
1. Pueden haberse generado subclases especiales para c6digo.
adoptar (alojar) el atributo innecesario o excepcio- Todos 10s modelos orientados a objetos deben ser
nes a 61. El trabajo involucrado en la creaci6n de sub- probados (en este contexto, el tkrmino ccprueba,, se uti-
clases no necesarias se ha evitado. liza para incorporar revisiones tCcnicas formales), para
2. Una mala interpretaci6n de la definici6n de la clase asegurar la exactitud, compleci6n y consistencia
puede conducir a relaciones de clases incorrectas o [MGR94], dentro del contexto de la sintaxis, seminti-
irrelevantes. ca y pragmitica del modelo [LIN94].
C A P ~ T U L O23 PRUEBAS ORIENTADAS A OBJETOS
Los modelos de analisis y disefio no pueden probarse en grafica de las conexiones entre clases. Toda esta infor-
el sentido convencional,ya que no pueden ejecutarse. Sin macion se puede obtener del modelo de A 0 0 (Capitu-
embargo, se pueden utilizar las revisiones tkcnicas for- lo 21).
males (Capitulo 8) para examinar la exactitud y consis-
tencia de arnbos modelos de analisis y disefio.
23.2.1. Exactitud d e 10s modelos d e A 0 0 y D O 0

La notaci6n y sintaxis que se utiliza para representar 10s
modelos de analisis y disefio se correspondera con el
Modelos de A00
mCtodo especifico de analisis y disefio, elegido para el
proyecto. Por consiguiente, la exactitud sintictica se Para evaluar el modelo de clases, se recomiendan 10s
juzga en el uso apropiado de la simbologia; cada mode- siguientes pasos [MGR94]:
lo se revisa para asegurarse de que se han mantenido
las convenciones propias del modelado. 1. Revisar el modelo CRC y el modelo objeto-relacidn.
Durante el analisis y disefio, la exactitud semantics Realizar un control cruzado, para asegurarse de que
debe juzgarse basada en la conformidad del modelo con todas las colaboraciones implicadas en el modelo de
el dominio del problema en el mundo real. Si el mode- A 0 0 hayan sido representadas adecuadamente.
lo refleja con exactitud el mundo real (a1 nivel de deta-
Ile apropiado a la etapa de desarrollo en la que se revisa ~ Q u epasos deben seguirse
el modelo), entonces es semanticamente correcto. Para para revisar el modelo
determinar si el modelo en realidad refleja el mundo real, de clases?
debe presentarse a expertos en el dominio del problema,
2. Inspeccionar la descripcidn de cada tarjeta CRC,
quienes examinaran las definiciones de las clases y sus para determinar si alguna responsabilidad delegada
jerarquias, para detectar omisiones o ambigiiedades. Las es parte de la dejinicidn del colaborador. Por ejem-
relaciones entre clases (conexiones de instancia) se eva-
plo, considkrese una clase definida para un sistema
16an para determinar si reflejan con exactitud conexio- de control de punto de venta, llamada venta a crk-
nes del mundo real1. dito. Esta clase tiene una tarjeta CRC, que se ilustra
en la Figura 23.1.
23.2.2. Consistencia d e 10s modelos d e A 0 0 Para esta colecci6n de clases y colaboraciones, se
y DO0 pregunta si alguna responsabilidad (por ejemplo, leer
La consistencia de 10s modelos de A 0 0 y D O 0 debe la tarjeta de crkdito) se cumple si se delega a1 cola-
juzgarse <<considerandolas relaciones entre entidades borador nombrado (Tarjeta de crkdito). Esto signi-
dentro del modelo. Un modelo inconsistente tiene repre- fica que la clase Tarjeta de crkdito posee una
sentaciones en una parte, que no se reflejan correcta- operaci6n para ser leida. En este caso, la respuesta
mente en otras partes del modelon [MGR94]. es <<Si>>.El objeto-relaci6n se recorre, para asegu-
Para evaluar la consistencia, se debe examinar cada rarse de que todas las conexiones son validas.
clase y sus conexiones a otras clases. Un modelo clase-
responsabilidad-colaboraci6n (CRC), y un diagrama
objeto-relacion pueden utilizarse para facilitar esta acti- Sugwsncios adii~lolesporo canducir uno revisibn
vidad. Como se coment6 en el Capitulo 21, el modelo del modelo CRC se presentan en el Copltulo 21.
CRC se compone de una tarjeta indice CRC. Cada tar-
jeta CRC muestra el nombre de la clase, sus responsa- 3. Invertir la conexi6n para asegurarse de que cada cola-
bilidades (operaciones) y sus colaboradores (otras clases borador que solicita un servicio recibe las peticiones
a las que se envian mensajes y de las cuales depende de una fuente razonable. Por ejemplo, si la clase Tar-
para el cumplimiento de sus responsabilidades). Las jeta de crkdito recibe una petici6n de cantidad de
colaboraciones implican una serie de relaciones (por compra de la clase Venta a crkdito, existira un pro-
ejemplo, conexiones), entre clases del sistema 00. El blema. Tarjeta de crkdito no reconoce la canridad de
modelo objeto-relaci6n proporciona una representaci6n compra.
Los casos de uso poseen un valor incalculable, en el seguirniento

de 10s rnodelos de analisis y disefio, frente a 10s escenarios del rnundo
real para el sistema 00.
Una vez que se crea el modelo de DO0 (Capitulo 22),

deben llevarse a cab0 tambiCn las revisiones del diseiio
del sistema y del diseiio de objetos. El diseiio del siste-
ma describe el producto arquitect6nico global, 10s sub-
sistemas que componen el producto, la manera en que
10s subsistemas se asignan a 10s procesadores, la asig-
naci6n de clases a subsistemas y el disefio de la interfaz
de usuario. El disefio de objetos presenta 10s detalles de
cada clase, y las actividades de mensajena necesarias
Etiqueta de producto
para implementar las colaboraciones entre clases.
1 Modelos de DO0
FIGURA 23.1. Un ejemplo de tarjeta indice CRC usada para El diseiio de sistema se revisa examinando el mode-
revision. lo objeto-comportarniento desarrollado durante el A 0 0 ,
y la correspondencia necesaria del comportamiento del
Utilizando las conexiones invertidas, ya examina- sistema, frente a 10s subsistemas disefiados para lograr
das en el paso 3, determinar si otras clases se requie- este comportamiento.
ren y si las responsabilidades se han repartido La concurrencia y asignaci6n de tareas tambiCn se
adecuadamente entre las clases. revisan dentro del contexto del comportamiento del sis-
tema. Los estados de comportarnientodel sistema se eva-
Determine si las responsabilidades muy solicita- luan para determinar cuhles existen concurrentemente.
das, dehen combinarse en una sola responsabili- Los escenarios o situaciones de 10s casos de uso se uti-
dad. Por ejemplo, leer tarjeta de crtdito y obtener lizan para validar el diseAo de la interfaz de usuario.
autorizacibn ocurren en cada situaci6n. Por consi- El modelado de objetos debe probarse frente a la red
guiente, se pueden combinar en la responsabilidad objeto-relacion, para asegurarse de que todos 10s obje-
validar petici6n de crtdito, que incorpora obtener tos de diseiio contienen 10s atributos y operaciones nece-
el numero de tarjeta de crkdito, y conseguir la auto- sarias y para implementar las colaboraciones que se
rizacihn. definieron para cada tarjeta CRC. Ademhs, la especifi-
Se aplican iterativamente 10s pasos 1 a 5 para cada caci6n detallada de las operaciones (por ejemplo, 10s
clase, y durante cada evolucibn del modelo de algoritmos que implementan a las operaciones), se revi-
AOO. san usando tCcnicas de inspecci6n convencionales.
La estrategia clhsica para la prueba de software de orde- ultimo, el sistema se comprueba como un todo para ase-
nador, comienza con ccprobar lo pequeiion y funciona gurarse de que se descubren 10s errores en requisitos.
hacia fuera haciendo ccprobar lo grande>>.Siguiendo la
jerga de la prueba de software (Capitulo 18), se comien-
za con las pruebas de unidad, despuCs se progresa hacia
encuentro
las pruebas de integraci6n y se culmina con las pruebas
rneior
de validaci6n del sistema. En aplicaciones convencio-
ellos.
nales, las pruebas de unidad se centran en las unidades
de programa compilables m8s pequefias --el subpro-
grama (por ejemplo, m6dul0, subrutina, procedimiento,
componente)-. Una vez que cada una de estas unida- 23.3.1. Las pruebas de unidad en el contexto
des han sido mobadas individualmente. se inteaan en
una estructura de programa, mientras que se ejecutan
- de la 00
Cuando se considera el software orientado a objetos, el
una sene de pruebas de regresi6n para descubrir errores, concept0 de unidad cambia. La encapsulaci6n conduce
debidos a las interfaces entre 10s m6dulos y 10s efectos a la definici6n de clases y objetos. Esto significa que
colaterales producidos por aiiadir nuevas unidades. Por cada clase y cada instancia de una clase (objeto), envuel-
CAPfTULO 23 PRUEBAS ORIENTADAS A OBJETOS
ven atributos (datos) y operaciones (tambiCn conoci- ro, las pruebas basadas en hilos, integran el conjunto
. dos como mCtodos o servicios), que manipulan estos de clases requeridas, para responder una entrada o suce-
datos. En vez de probar un m6dulo individual, la uni- so a1 sistema. Cada hilo se integra y prueba individual-
dad mLs pequeiia comprobable es la clase u objeto mente. Las pruebas de regresi6n se aplican para asegurar
encapsulado. Ya que una clase puede contener un ntime- que no ocurran efectos laterales. La segunda aproxi-
ro de operaciones diferentes, y una operaci6n particu- maci6n de integracibn, la prueba basada en el uso,
lar debe existir como parte de un ntimero de clases comienza la construcci6n del sistema probando aque-
diferentes, el significado de la unidad de prueba cam- llas clases (llamadas clases independientes), que utili-
bia dristicamente. zan muy pocas (o ninguna) clases servidoras. DespuCs
No se puede probar mLs de una operaci6n a la vez de que las clases independientes se prueban, esta secuen-
(la visi6n convencional de la unidad de prueba), per0 si cia de pruebas por capas de clases dependientes conti-
como parte de una clase. Para ilustrar esto, considkre- nua hasta que se construye el sistema completo. A
se una jerarquia de clases, en la cual la operaci6n X se diferencia de la integraci6n convencional, el uso de dri-
define para la superclase y se hereda por algunas sub- vers y stubs como operaciones de reemplazo, debe evi-
clases. Cada subclase utiliza la operaci6n X, per0 se tarse siempre que sea posible.
aplica en el contexto de 10s atributos y operaciones pri-
vadas que han sido definidas para la subclase. Ya que el
contexto en el que la operaci6n X se utiliza varia de
manera sutil, es necesario para probar la operaci6n X
en el contexto de estas subclases. Esto significa que pro- Lo estrotegio de integrocibn de pruebos 00 se centro
bar la operaci6n X en vacio (la aproximacibn de la prue- en grupos de closes que coloboron o se comunicon
ba de unidades tradicionales) es inefectiva en el contexto de lo mismo monero.
orientado a objetos.
La prueba de agrupamiento [MGR94] es una fase
en las pruebas de integraci6n de software 00.Aqui, un
agrupamiento de clases colaboradoras (determinadas
por la revisidn de 10s modelos CRC y objeto-relacibn),
l o pruebo de softwore 00 es equivolente ol mbdulo se prueba diseiiando 10s casos de prueba, que intentan
de pruebos unitorias para el software convencionol. revelar errores en las colaboraciones.
No es recomendoble comprobor operociones por separodo.
23.3.3. Pruebas de validaci6n en un contexto 00
La prueba de clases para el software 00 es el equiva-
lente de las pruebas de unidad para el software conven- A1 nivel de sistema o de validacibn, 10s detalles de
ciona12.A diferencia de las pruebas de unidad del software conexiones de clases desaparecen. Asi como la vali-
convencional que tienden a centrarse en el detalle algo- daci6n convencional, la validaci6n del software 00
n'tmico de un m d u l o y de 10s datos que fluyen a travks se centra en las acciones visibles a1 usuario y salidas
de la interfaz del mdulo, la prueba de clases para el soft- reconocibles desde el sistema. Para ayudar en la cons-
ware 00 se conduce mediante las operaciones encapsu- trucci6n de las pruebas de validacibn, el probador debe
ladas por la clase y el comportamiento de la clase. utilizar 10s casos de uso (Capitulo 20), que son parte
del modelo de anhlisis. Los casos de uso proporcionan
un escenario, que tiene una gran similitud de errores
23.3.2. Las pruebas de integracibn con 10s revelados en 10s requisitos de interacci6n del
en e l contexto 00 usuario.
Ya que el software orientado a objetos no tiene una
estructura de control jerhrquico, las estrategias con-
vencionales de integraci6n descendente (top-down) y
ascendente (bottom-up) tienen muy poco significado.
En suma, la integraci6n de operaciones una por una en
una clase (la aproximacih de la integraci6n incremen-
tal convencional), a menudo es imposible por la ccinte- Los mktodos de prueba convencionales de caja negra
racci6n directa e indirecta de 10s componentes que pueden usarse para realizar pruebas de validaci6n. Ade-
conforman la clasen [BER93]. mas, 10s casos de prueba deben derivarse del modelo de
Existen dos estrategias diferentes para las pruebas comportamiento del objeto y del diagrama de flujo de
de integraci6n de 10s sistemas 00 [BIN94a]. El prime- sucesos, creado como parte del AOO.
Los metodos de diseiio para pmebas de caso, para las clases 00,
se discuten de las Secciones 23.4 a 23.6.
1NGENlERfA DEL SOFTWARE. UN ENFOQUE PRACTICO
Los mCtodos de disefio de casos de prueba para soft-

ware orientado a obietos continuan evolucionando. Sin
embargo, una aproximacion global a1 diseiio de casos
de vrueba 00 ha sido definida vor Bernard IBER931:
Uno coleccion excelente de publicociones, fuentes
Cada caso de prueba debe ser identificado separa- y bibliogrhs de pruebos 00 puede enconhone
damente, y explicitamente asociado con la clase a en www.rbsc.com
probar.
Debe declararse el proposito de la prueba. La herencia tarnbiCn conduce a retos adicionales para
Debe desarrollarse una lista de pasos a seguir, como el diseiiador de casos de prueba. Ya se ha dicho que cada
consecuencia de la prueba, per0 ademas debe con- nuevo contexto de uso requiere repetir la prueba, aun y
tener [BER93]: cuando se haya logrado la reutilizacion. Ademas, la
a. definicion de una lista de estados, especificos herencia mliltiple3 complica mucho mas las pruebas,
para el objeto a probar. incrementando el numero de contextos para 10s que se
b. una lista de mensajes y operaciones, que se ejer- requiere la prueba [BIN94a]. Si las subclases instan-
citariin como consecuencia de las pruebas. ciadas de una superclase se utilizan dentro del mismo
dominio de problema, es probable que el conjunto de
c. una lista de excepciones, que pueden ocumr con- casos de prueba derivados de la superclase puedan usar-
forme el objeto se comprueba. se para la prueba de las subclases. De cualquier mane-
d. una lista de condiciones externas (por ejemplo, ra, si la subclase se utiliza en un contexto enteramente
10s cambios en el ambiente externo a1 software, diferente, 10s casos prueba de la superclase seran esca-
que debe existir para conducir apropiadamente samente aplicables, y tendra que disefiar un nuevo con-
las pruebas). junto de pruebas.
e. information adicional, que ayudara a la com-
prension e implementaci6n de la prueba. 23.4.2. Aplicabilidad de 10s mktodos convencio-
A diferencia del diseiio de pruebas conventional, que nales de diseiio de casos de prueba
se conduce mediante una vision entrada-proceso-salida Los mCtodos de cccaja blanca>>descritos en el Capitulo 17
de software, o el detalle algoritmico de 10s mdulos indi- pueden aplicarse a las operaciones definidas para una cla-
viduales, la prueba orientada a objetos se enfoca en las se. TCcnicas como el camino bkico, pruebas de bucle o
secuencias de operaciones de disefio apropiadas para tkcnicas de flujo de datos pueden ayudar a asegurar que
probar 10s estados de una clase. se ha probado cada sentencia de la operation. De cual-
quier modo, la estructura concisa de muchas operaciones
23.4.1. Implicaciones de 10s conceptos de 00 de clase provoca que algunos defiendan que el esfuerzo
a1 diseiio de casos de prueba aplicado a la prueba de cccaja blanca,, debe ser redirigido
adecuadamente a las pruebas, a un nivel de clase.
Como ya se ha visto, la clase es el objetivo del diseiio
Los mCtodos de prueba de cccaja negra>>son tan apro-
de casos prueba. Debido a que 10s atributos y opera-
piados para 10s sistemas 00,como lo son para 10s siste-
ciones se encapsulan, las operaciones de prueba fuera
mas desarrollados utilizando 10s mCtodos convencionales
de la clase son generalmente improductivas. A pesar de
de ingenieria de software. Como se dijo a1 principio del
que la encapsulaci6n es un concept0 de disefio esen-
capitulo, 10s casos de uso pueden proporcionar datos 6ti-
cia1 para la 00, puede crear un obstaculo cuando se
les en el diseiio de pruebas de cccaja negra>>,y pruebas
hacen las pruebas. Corno menciona Binder [BIN94a],
basadas en estados [AMB95].
ccla prueba requiere informes del estado abstract0 y con-
creto del objeto>>.La encapsulaci6n puede dificultar un
poco la obtencion de esta informacion. A menos que se 23.4.3. Pruebas basadas en errores4
proporcionen operaciones incorporadas para conocer El objetivo de las pruebas basadas en errores dentro de
10s valores para 10s atributos de la clase, una imagen un sistema 00, es disefiar pruebas que tengan una alta
instantanea del estado del objeto puede ser dificil de probabilidad de revelar fallos. Ya que el product0 o sis-
adquirir. tema debe adaptarse a 10s requerimientos del cliente, la
Concepto de D O 0 que debe usarse con extrema precaution. Las Secciones 23.4.3 a 23.4.6 han sido adaptadas de un articulo
de Brian Marick, divulgado e n el grupo de noticias de internet
comp.testing.Esta adaptacion se ha incluido con el permiso del autor.
Para adentrarse mas en la discusion de este tema, vease [MAR94].
CAP~TULO
23 PRUEBAS ORIENTADAS A O B J E T O S
planificaci6n preliminar requerida para llevar a cab0 la perciben como ccimprobables>>,entonces esta aproxi-
prueba basada en fallos comienza con el modelo de an$ maci6n no es en realidad mejor que la tCcnica de prue-
h i s . El probador busca fallos posibles (por ejemplo, 10s bas aleatorias. De cualquier manera, si 10s modelos de
aspectos de implementaci6n del sistema que pueden anhlisis y disefio pueden proporcionar la visi6n de lo
manifestarse en defectos). Para determinar si existen que parece andar mal, entonces las pruebas basadas en
estos fallos, 10s casos de prueba se disefian para probar errores pueden encontrar un numero significativo de
el disefio o c6digo. errores con esfuerzos relativarnente pequeiios.
Las pruebas de integraci6n buscan fallos probables
en operaciones o mensajes de conexi6n. Tres tipos de
fallos se encuentran en este contexto: resultados ines-
perados, uso incorrecto de operaciones/mensajes, invo-
l o esrategia cansiste en hater hipbtesis de una serie caciones incorrectas. Para determinar fallos probables
de posibles fallos, y luego conducir 10s pruebas cuando las funciones (operaciones) se invocan, se debe
poro cornprobor las hipbtesis. examinar el comportamiento de la operaci6n.
ConsidCrese un ejemplo simple5. Los ingenieros de iQue tip0 de fallos
software generalmente cometen errores en 10s limites se encuentran en lamadas
del problema. Por ejemplo, cuando se prueba una ope- a operaciones y conexiones
raci6n SQRT que genera errores para numeros negati- de mensajes?
vos, se sabe probar 10s limites: un numero negativo
cercano a1 cero y el cero mismo. El cccero mismo>>com- Las pruebas de integraci6n se aplican tanto a atribu-
prueba si el programador ha cometido un error como: tos como a operaciones. Los cccomportarnientos>> de un
If ( x > 0 ) calcular-la-raiz-cuadrada ( ); objeto se definen por 10s valores que se asignan a sus
En lugar de lo correct0 atributos. Las pruebas deben verificar 10s atributos para
determinar si se obtienen valores apropiados para 10s
If ( x >= 0 ) calcular-la-raiz-cuadrada ( );
distintos tipos de comportamientos de 10s objetos.
Como otro ejemplo, considkrese la expresi6n booleana Es importante hacer notar que las pruebas de inte-
siguiente: graci6n intentan encontrar 10s errores en el objeto clien-
If (a && !b I I c ) te, no en el semidor. Dicho en tCrminos comunes, el
enfoque de las pruebas de integraci6n es determinar si
el error existe en el c6digo de invocacibn, no en el c6di-
go invocado. La invocaci6n a operaciones se utiliza como
una pista, una forma de encontrar 10s requerimientos de
Yo que lo pruebo bosodo en follos se do en un nivel la prueba que validen el c6digo de invocaci6n.
detollodo, se reservo mejor poro 10s operociones
y closes que son critcos o sospechosos.
23.4.4. El impacto de la programaci6n 00 en las
Las pruebas de multicondici6n y tCcnicas relaciona- pruebas
das examinan las faltas posibles con toda seguridad en Hay distintas maneras en que la programaci6n orienta-
esta expresibn, como, por ejemplo, da a objetos puede tener un impacto en las pruebas.
&& deberia de ser II Dependiendo del enfoque de la POO.
Algunos tipos de fallos se vuelven menos probables
! se ignor6 donde se necesitaba
(no vale la pena probar).
Y deberia haber un pakntesis alrededor de !b Ilc Algunos tipos de fallos se vuelven m8s probables
Para cada error probable, se diseiian casos de prue- (vale la pena probar).
ba, que forzar6n a la condici6n incorrecta a fallar. En la Aparecen algunos tipos nuevos de fallos.
expresi6n anterior, (a=O, b=O, c=O) forzarhn a que la
expresi6n se evalue falsa. Si el && hubiera sido II, el
c6digo hubiera dado el resultado incorrecto y el control
habna seguido la rama err6nea.
Desde luego que la efectividad de estas tkcnicas
depende de c6mo 10s probadores perciben el ccfallo pro-
bable>>.Si 10s fallos verdaderos en un sistema 00 se
El codigo presentado en esta y en las siguientes secciones utiliza la

sintaxis de C++. Para mayor informacion. vease cualquier buen libro
de C++.
INGENIER~A
Cuando se invoca una operaci6n es dificil decir exac- bada, porque representa un nuevo diseiio y nuevo
tamente quC c6digo se ejecuta. Esto es, la operaci6n c6digo. Pero, ila d e r i v a d a : : h e r e d a d d ( ) debe ser
debe pertenecer a una de muchas clases. Incluso, pue- recomprobada?
de ser dificil determinar el tip0 exacto o clase de un Si la d e r i v a d a :h e r e d a d a ( ) inv0ca a redefini-
parhetro. Cuando el c6digo lo acceda puede obtenerda y el comportamiento de redefinida cambia, d e r i -
se un valor inesperado. La diferencia puede entenderse v a d a : : h e r e d a d d ( ) podria manejar errdneamente
considerando la llamada a una funci6n convencional: el nuevo comportamiento. De este modo, se necesi-
tan nuevas pruebas aunque el diseiio y el c6digo no
hayan cambiado. Es importante hacer notar, sin
Para el software convencional, el probador debe con- embargo, que solo un subconjunto de todas las prue-
siderar todos 10s comportamientos atribuidos afunc y bas para d e r i v a d a : :h e r e d a d a ( ) deben rehacerse.
nada mhs. En un contexto 00,el probador debe consi- Si parte del diseiio y codificaci6n para heredada no
derar 10s comportamientos de base:func( ), de deriva- depende de redefinida (por ejemplo, no la llama ni
da:func(), y asi sucesivamente. Cada vez que func se llama ningun c6digo que indirectamente la llame),
invoca, el probador debe considerar la uni6n de todos ese c6digo no necesita ser recomprobado en la clase
10s comportamientos distintos. Esto es rnhs ficil si se derivada.
siguen prhcticas de disefio 00 adecuadas, y se limitan B a s e : r e d e f i n i d a ( ) y d e r i v a d a :z r e d e f i n i d a ( )
las diferencias entre superclases y subclases (en el len- son dos operaciones diferentes con especificaciones e
guaje de C++, estas se llaman clases base y clases deri- implementaciones diferentes. Cada una deberia tener
vadas). un conjunto de requisitos de prueba, derivadas de la
La aproximaci6n a las pruebas para clases derivadas especificaci6n e implementacibn. Aquellos requisitos
y base es esencialmente la misma. La diferencia es de prueban errores probables: fallos de integracibn, fallos
contabilidad. de condicibn, fallos de limites y asi sucesivamente. Pero
Probar las operaciones de clases es anhlogo a probar las operaciones es probable que Sean similares por lo
cddigo que toma un parhmetro de la funcidn y luego la que el conjunto de requisitos de pruebas se solapan.
invoca. La herencia es una manera conveniente de pro- Cuanto mejor sea el diseiio 00, el solapamiento sera
ducir operaciones polim6rlicas. En la Ilamada, lo que mayor. Es necesario desarrollar las nuevas pruebas, solo
importa no es la herencia, sino el polimorfismo. La para aquellos requisitos de d e r i v a d a ::r e d e f i n i d a ( I
herencia hace que la bdsqueda de 10s requisitos de prue- que no fueron satisfechas por pruebas de b a s e ::r e d e -
ba sea mis directa. finida( ) .
En virtud de la construccidn y arquitectura de soft- Para concluir, las pruebas de b a s e :r r e d e h i d a ( )
ware, jexisten algunos tipos de fallos mhs probables se aplican a 10s objetos de la clase derivada. Las entra-
para un sistema 00, y otros menos probables? la res- das de las pruebas deben ser apropiadas para las clases
puesta es <<sin.Por ejemplo, a causa de que las ope- base y derivada, per0 10s resultados esperados pueden
raciones 00 son generalmente m i s pequeiias, se diferir en la clase derivada.
tiende a gastar rnhs tiempo en la integraci6n ya que
existen m i s oportunidades de errores de integraci6n.
Asi que 10s errores de integraci6n se vuelven mis pro-
bable~. 23.4.6. Diseiio d e pruebas basadas
e n el escenario
Las pruebas basadas en 10s errores no localizan dos
23.4.5. Casos d e prueba y jerarquia d e clases tipos de errores: (1) especificaciones incorrectas y (2)
Como se explic6 previamente en este capitulo, la heren- interacci6n entre subsistemas. Cuando ocurren errores
cia no obvia la necesidad de probar todas las clases asociados con especificaciones err6neas, el producto
derivadas. De hecho, puede complicar el proceso de no realiza lo que el cliente desea. Puede que haga cosas
prueba. incorrectas, o puede omitir funcionalidad importante.
Pero en cualquier circunstancia, la calidad (cumpli-
miento de requisitos) se sacrifica. Los errores asocia-
dos con la interaccih de subsistemas ocurren cuando
el comportamiento de un subsistema crea circunstan-
Aunque se hoyo comprobado bostante uno close base, cias, (por ejemplo, sucesos, flujo de datos) que causan
tendra que comprobor 10s closes derivodos de ello.
que el otro subsistema falle.
Las pruebas basadas en el escenario se concentran
ConsidCrese la situaci6n siguiente. Una clase base en lo que el usuario hace, no en lo que el producto
contiene operaciones heredadas y redefinidas. Una hace. Esto significa capturar las tareas (por medio de
clase derivada redefine operaciones redefinidas para 10s casos de uso) que el usuario tiene que hacer,
funcionar en un contexto local. Existe la pequeiia duda despuCs aplicarlas a ellas y a sus variantes como
de que la d e r i v a d a :: r e d e i k i d a ( ) debe ser compro- pruebas.
C A P ~ T U L O23 PRUEBAS ORIENTADAS A O B J E T O S
cionar <<imprimir>>en el menli y presionando el b o t h

<<irnprimirnen la caja de dihlogo, se conseguir6 que la
ultima phgina corregida se imprima de nuevo. Asi que,
La prueba basada en el escenario descubrira errores de acuerdo con el editor, el escenario correct0 debena
que ocurren cuando cuolquier actor interactira ser como el siguiente:
con el software 00. Caso de uso: Imprimir una nueva copia.
I . Abrir el documento.
Los escenarios revelan errores de interacci6n. Pero
2. Seleccionar ccimprimirr en el menli.
para llevar a cab0 esto, 10s casos de prueba deben ser
mas complejos y realistas que las pruebas basadas en 3. Cornprobar si se imprime un rango de piginas; si es asi, pre-
10s errores. Las pruebas basadas en el escenario tienden sionar para ccimprimirr el documento entero.
a validar subsistemas en una prueba sencilla (10s usua- 4. Presionar en el bodn de impresibn.
rios no se limitan a1 uso de un subsistema a la vez). 5. Cerrar el documento.
A manera de ejemplo, considCrese el diseiio de prue- Pero este escenario indica una especificaci6n poten-
bas basadas en el escenario, para un editor de texto. Uti- cia1 de error. El editor no hace lo que el usuario razo-
license 10s siguientes casos:
nablemente espera. Los clientes generalmente pasarhn
Caso de uso: Prepara la versi6n final. por alto la opci6n de rango de paginas del paso 3 en el
Aspectos de fondo: No es inusual imprimir el borrador 4inab, ejemplo anterior. Se incomodaran cuando enciendan la
leerlo y descubrir algunos errores inc6modos que no eran tan impresora y encuentren una pagina cuando ellos que-
obvios en la imagen de la pantalla. Este caso de uso describe rian 100. Los clientes fastidiados significan errores de
la secuencia de pasos que ocurren cuando esto pasa.
especificaci6n.
1. Imprimir el documento entero. Un diseiiador de casos de prueba debe olvidar la depen-
2. Rondar dentro del documento, cambiar algunas paginas. dencia en un diseiio de pruebas, per0 es probable que el
3. A1 momento en que cada pigina se cambia, se imprime. problema aparezca durante las pruebas. El probador ten-
4. Algunas veces se imprime una sene de piginas.
dria entonces que lidiar con la respuesta probable, <<iEsa
es la forma como se supone que debe funcionar?>>.
Este escenario describe dos elementos: una prueba
y unas necesidades especificas del usuario. Las necesi-
dades del usuario son obvias: (1) un mCtodo para impri- 23.4.7. Las estructuras de pruebas superficiales
mir una sola phgina y (2) un mCtodo para imprimir un y profundas
rango de paginas. Hasta donde va la prueba, existe la La estructura superficial se refiere a la estructura visi-
necesidad de editar despuCs de imprimir (asi como lo ble a1 exterior de un programa 00. Esto es, la estruc-
contrario). El probador espera descubrir que la funci6n tura que es inmediatamente obvia a1 usuario final. En
de impresi6n causa errores en la funci6n de edicibn; esto vez de llevar a cab0 funciones, 10s usuarios de muchos
es, que las dos funciones de software sean totalmente sistemas 00 deben de proveerse de objetos para mani-
independientes. pular de alguna forma. Pero sin importar la interfaz, las
Caso de uso: Impresi6n de una nueva copia. pruebas aun se basan en las tareas de 10s usuarios. Cap-
turar estas tareas involucra comprensi6n, observaci6n,
Aspectos de fondo: Se pide una copia reciente. Debe ser
impresa: y conversar con usuanos representativos (y tantos usua-
rios no representativos como valga la pena considerar).
1. Abrir el documento
Debe haber alguna diferencia en detalle con seguri-
2. Imprimirlo. dad. Por ejemplo, en un sistema convencional con una
3. Cerrar el documento. interfaz orientada a comandos, el usuario debe usar la
lista de comandos como una lista de control de pruebas.
Si no existen escenarios de prueba para ejercitar un
comando, las pruebas probablemente pasaron por alto
Aunque lo pruebo bosodo en el escenorio tiene so rnirita, algunas tareas del usuario (o la interfaz contiene coman-
encontrord uno recornpenso rnoyor revisondo 10s cosos de dos inutiles). En una interfaz basada en objetos, el veri-
uso cuondo se desorrollon duronte el A00. ficador debe usar la lista de todos 10s objetos, como una
lista de control de pruebas.
Una vez mhs, la aproximaci6n de las pruebas es rela-
tivamente obvia. Excepto que el documento no apare-
ci6 fuera de ningun lugar. Fue creado en una tarea
anterior. iLa tarea anterior afecta a esta?
En 10s editores modernos, 10s documentos registran La esbuctura de pruebas se do en dos niveles:
como fueron impresos por ultima vez. Por omisi6n, se (1) pruebas que validan la estructura visible
impnmen de la misma forma la siguiente vez. DespuCs por el usuario final, (2) pruebos diseiiadas
del escenario preparar la versibn final, con solo selec- para validor la esbuctura interna del program.
Las mejores pruebas se dan cuando el disefiador Los modelos de andisis y disefio se utilizan como
.observa a1 sistema de una manera nueva o poco con- una base para la verificaci6n de la estructura profunda.
vencional. Por ejemplo, si el sistema o product0 tiene Por ejemplo, el diagrama objeto-relaci6n o el diagrama
una interfaz basada en comandos, pruebas mfis com- de colaboraci6n de subsistemas describe colaboracio-
pletas se darfin si el diseiiador de casos supone que las nes entre objetos y subsistemas, que no pueden ser visi-
operaciones son independientes de 10s objetos. Hacer b l e ~extemamente.
preguntas como cciQuerrii el usuario usar esta operaci6n El diseiio de casos de prueba entonces se pregunta:
--que se aplica s610 a1 objeto scanner- mientras tra- <<iSeha capturado (como una prueba) alguna tarea que
baja con la impresora?n. Cualquiera que sea el estilo de pruebe la colaboraci6n anotada en el diagrama objeto
la interfaz, el diseiio de casos de prueba que ejercita la relacibn, o en el diagrama de colaboraci6n de subsiste-
estructura superficial debe usar ambos objetos y opera- mas? Si no es asi, ipor quC no?>>
ciones, como pistas que conduzcan a las tareas desa- El diseiio de representaciones de jerarquias de clases
percibidas. proporciona una visi6n de la estructura de herencia. La
La estructura profunda se refiere a 10s detalles tCc- estructura jerkquica se utiliza en la verificaci6n basada
nicos de un programa 00. Esto es, la estructura que se en errores. ConsidCrese la situaci6n en la cud una ope-
comprende examinando el disefio y/o el cbdigo. La veri- raci6n llamada llamar a( ) tiene un solo argumento, y
ficaci6n de la estructura profunda estfi disefiada para ese argumento es unareferencia a la clase base. ~ Q u C
ejercitar dependencias, comportamientos y mecanismos ocurrirfi cuando llamar-a( ) pase a la clase derivada?
de comunicaci6n, que han sido establecidos como par- iCudes s e h las diferencias en comportamiento que pue-
te del disefio del objeto y del sistema (Capitulo 22) de dan afectar a tal funci6n? Las respuestas a estas pregun-
software 00. tas pueden conducir al disefio de pruebas especializadas.
En el Capitulo 17 se mencion6 que la prueba de soft- Esto representa la secuencia de verificaci6n minima
ware comienza <<enlo pequeiio>>y lentamente progresa para una cuenta. De cualquier modo, pueden existir una
hacia la prueba cca grande,,. La prueba <<enpequefio>>, amplia variedad de combinaciones de operaciones posi-
se enfoca en una sola clase y 10s mCtodos encapsulados bles, dentro de esta secuencia:
por ella. La verificaci6n y partici6n a1 azar son mCto- Abrir - configurar - depositar - [depositar I r e t i -
dos que pueden usarse para ejercitar a una clase duran- rar I consul tar saldo I resumen / Limi tecredi t o I" -
te la prueba 00 [KIR94]. retirar - cerrar
Pueden generarse una variedad de secuencias de ope-
raciones diferentes a1 azar. Por ejemplo,
23.5.1. La verificacion a1 azar para clases 00
Prueba rl: abrir - contigurar - deposi tar - consul tar
A manera de ilustraciones sencillas de estos mCtodos, saldo - resumen - retirar - cerrar.
considCrese una aplicacibn bancaria en la cual una cla- Prueba r 2 : abrir - contigurar - depositar - retirar -
se cuenta contiene las siguientes operaciones: abrir, depositar - consultar saldo - LimiteCr6-
configurar, depositar, retirar, consultar saldo, resumen, d i t o - retirar - cerrar.
LimiteCrkdito y cerrar [KIR94]. Cada una de estas ope- Estas y otras pruebas de orden aleatorio se realizan
raciones debe aplicarse a cuenta, per0 algunas limita- para probar diferentes registros de operaciones de ins-
ciones (por ejemplo, la cuenta debe ser abierta antes de tancias de clases.
que otras operaciones puedan aplicirsele, y cerrada des-
puCs de que todas las operaciones hayan sido comple- 23.5.2. Prueba de particion a1 nivel de clases
tadas) e s t b implicitas en la naturaleza del problema. La prueba de particidn reduce el niimero de casos de prue-
A6n con estas limitaciones, existen muchas combina- ba requeridos para validar la clase, de la misma forma que
ciones de operaciones. El registro de operaciones mini- la partici6n equivalente (Capitulo 17) para software con-
ma de una instancia de cuenta incluye las siguientes vencional. Las entradas y salidas se clasifican, y 10s casos
operaciones: de prueba se diseiian, para validar cada categoria. Pero
Abrir - contigurar - depositar - retirar - cerrar. jc6m0 se derivan las categorias de partici6n?
~ Q u eoptiones de pruebas
estan disponibles a nivel
El nlimero de combinocionesposibles para uno pruebo de tlases?
oleotorio puede crecer mucho. Uno estrategio similor
para lo pruebos de onoys ortogonoles (Copilvio 171, La particidn basada en estados clasifica las opera-
puede usone poro mejoror lo eficiencio de 10s pmebos. ciones de clase basada en su habilidad de cambiar el
CAPfTULO 23 PRUEBAS ORIENTADAS A O B J E T O S
estado de la clase. Una vez mas, considerando la clase La particion basada en atributos clasifica las opera-
cuenta, operaciones de estado incluyen a depositar y ciones de clase basada en 10s atributos que ellas usan.
retirar, y considerando que las operaciones de no-esta- Para la clase cuenta, 10s atributos saldo y LimiteCre-
do incluyen a consultar saldo, resumen y LimiteCre'di- dito pueden usarse para definir particiones. Las opera-
to, las pruebas se diseiian de manera que las operaciones ciones se dividen en tres particiones: (1) Operaciones
que cambian el estado, y aquellas que no lo cambian, que utilizan LimiteCredito, (2) operaciones que modi-
se ejerciten separadamente. Entonces: fican LimiteCredito, y (3) operaciones que no utilizan
o modifican LimiteCredito. Las secuencias de prueba
Prueba p, : abrir- configurar - depositar - deposi tar se disefian por cada particion.
- retirar - retirar cerrar.
-
Prueba p,: abrir - configurar - depositar - resumen -

La particion basada en categorias clasifica las opera-
LhiteCredito - retirar - cerrar. ciones de la clase basadas en la funcidn genkrica que cada
una lleva a cabo. Por ejemplo, las operaciones en la cla-
La prueba p, cambia el estado, mientras que la prue- se cuenta pueden clasificarse en operaciones de iniciali-
ba p2 ejercita las operaciones que no cambian el estado zacion (abrir, configurar), operaciones computacionales
(except0 por las necesarias de la secuencia minima de (depositar, retirar), consultas (saldo, resumen, Limite-
prueba). Credito) y operaciones de termination (cerrar).
El diseiio de casos de prueba se vuelve mas complica-

do cuando la integration del sistema 00 comienza. Es
en esta etapa en que la verificacion de colaboraciones
entre clases comienza. Para ilustrar <<lageneracion de Tarietalnsertada Verificar~uenta
Contrasena
casos de prueba interclasesn [KIR94], se expande el Deposito
VerificarPlN
ejemplo de la aplicacion bancaria introducida en la Sec- VerificarPolitica
cion 23.5, para incluir las clases y colaboraciones de la
Figura 23.2. La direccion de las flechas en la Figura
indica que se invocan como consecuencia de colabora-
ciones implicitas a 10s mensajes.
Asi como la verificacion de clases individuales, la
verificacion de colaboraciones de clases puede com-
pletarse aplicando mCtodos de particion y a1 azar, asi Deposito
I
como pruebas basadas en el escenario y pruebas de com-
portamiento.
23.6.1. Prueba de multiples clases

1
7'
lCerrar
mm de inforrnacion
FIGURA 23.2. Grafo de colaboraciones de clase

Kirani y Tsai [KIR94] sugieren la secuencia siguiente para una aplicacion bancaria IKIR941.
de pasos, para generar casos de prueba aleatorios para
multiples clases:
Un caso de prueba aleatorio para la clase banco
Para cada clase cliente, utilice la lista de operacio- podria ser:
nes de clase, para generar una serie de secuencias de
pruebas a1 azar. Las operaciones enviaran mensajes Prueba r3 = verifcuenta - verifNIP - reqDepositar
a las otras clases sewidoras. Con la finalidad de considerar a 10s colaboradores
Para cada mensaje que se genere, determine la clase involucrados en esta prueba, 10s mensajes asociados con
colaboradora y la operacion correspondiente en el cada una de las operaciones mencionadas en el caso de
objeto sewidor. prueba r, deben ser tornados en cuenta. Banco debe cola-
Para cada operacion en el objeto sewidor (invocada borar con infovalidacion para ejecutar verifCuenta y
por mensajes enviados por el objeto cliente), deter- verimIP. Banco debe colaborar con cuenta para ejecu-
mine 10s mensajes que transmite. tar reqDepositar. De aqui que un nuevo caso de prueba,
Para cada uno de 10s mensajes, determine el siguiente que ejercite estas colaboraciones, es:
nivel de operaciones que son invocadas, e incorpore Prueba r, = verifcuenta,,,, [validCuentalnfovalidac,6nJ
Cstas a la secuencia de pruebas. - VerifNIP,,,,, - ~ValiCWIPin,,,idaridnJ
- reqDepositar - [DepositarmentaJ
Para ilustrar [KIR94], considCrese una secuencia de
operaciones para la clase banco relativa a una clase La aproximacion para la prueba de particion de mdl-
ATM (Figura 23.2): tiples clases es similar a la aproximacion usada para la
I N G E N I E R ~ ADEL S O F T W A R E . U N E N F O Q U E P R A C T I C O
prueba de particion de clases individuales. La manera Prueba s l : abrir - PI-eparar-cuenta - deposi tar ( i n i -
como una sola clase se particiona se discuti6 en la Sec- cial) - r e t i r o (final) cerrar
-
ci6n 23.4.5. De cualquier modo, la secuencia de prue- N6tese que esta secuencia es idCntica a la secuencia
bas se extiende para incluir aquellas operaciones que se minima de pruebas, discutida en la Secci6n 23.5.1. Si
invocan por 10s mensajes a clases colaboradoras. Una se agregan secuencias de prueba adicionales a la secuen-
aproximacion alternativa basa las pruebas por partici6n cia minima:
en las interfaces de una clase en particular. Haciendo
Prueba s2: abrir preparar cuenta
- - deposita~~iini-
referencia a la Figura 23.2, la clase banco recibe men- cia1)- saldo - credit0 - r e t i r o (fmal) -
sajes de las clases ATM y Cajero. Los mCtodos inclui- cerrar .
dos en banco pueden probarse particionindolos en
Prueba s;: preparar cuentd deposita~.f i n i c i a l )
aquellos que sirven a ATM y aquellos que sirven a Caje- -
r e t i r o - infocuenta - retiroilinall cerrar.

-
ro. La particion basada en estados (Seccibn 23.4.9), pue-

de usarse para refinar adn mis las particiones. Se pueden derivar a h mas casos de prueba, para ase-
gurarse de que todos 10s comportamientos para la cla-
se han sido adecuadamente ejercitados. En situaciones
23.6.2. Prueba derivada de 10s modelos
en las que el comportamiento de la clases, resulte en
de comportamiento una colaboraci6n con una o mas clase se utilizan mdl-
En el Capitulo 21 se discutio el uso del diagrama de tran- tiples DTEs para registrar el flujo de comportamientos
sicion de estados, como el modelo que representa el com- del sistema.
portamiento dinimico de una clase. El DTE (Diagrama El modelo de estado puede ser recorrido ccprimero a
de transicion de estados) para una clase puede usarse lo anchon [MGR94]. En este contexto, primer0 a lo
para ayudar a derivar una secuencia de pruebas, que ejer- ancho implica que un caso de prueba valida una sola
citaran el comportamiento dinamico de la clase (y aque- transicion y despues, cuando se va a verificar una nue-
llas clases que colaboran con ella). La Figura 23.3 va transicion, se utilizan so10 las transiciones previa-
[KIR94] ilustra una DTE para la clase cuenta explica- mente verificadas.
da con anterioridad6.Con referencia a la Figura, las tran- ConsidCrese el objeto tarjeta-de-credit0 de la Sec-
siciones iniciales se mueven por 10s estados cuenta vacia ci6n 23.2.2. El estado inicial de tarjeta-de-credito
y configura cuenta. Un retiro final y cierre causan que es indefinido (es decir, no se ha proporcionado un
la clase cuenta haga transiciones a 10s estados nohace- ndmero de tarjeta de crCdito). Una vez leida la tarjeta
trabajo de cuenta y cuenta muerta, respectivamente. de crCdito durante una venta, el objeto asume un esta-
do definido; esto significa que 10s atributos numero
tarjeta y fecha expiracion, se definen junto con iden-
Cuenta Preparar tificadores especificos del banco. La tarjeta de crCdi-
vacia
to se envia, cuando se envia la autorizacion, y es
cuenta aprobada cuando la autorizacion se recibe. La transi-
Deposito (inicial)
cion de tarjeta de-credito de un estado a otro puede
Deposito probarse generando casos de prueba, que hagan que la
transicion ocurra. Un enfoque ccprimero a lo ancho>>
con la en este tipo de pruebas, puede no validar el envio antes
Balance cuenta
Credito
Retirar de que se ejercite indefinida y definida. Si lo hiciera,
haria uso de transiciones que no han sido verificadas
Retirar todo (final) con anterioridad, y violaria el criterio ccprimero a lo
ancho,,.
Cuenta
no operativa
FIGURA 23.3. Diagrama de transicion de estados

para la clase cuenta [KIR941.
Las pruebas a diseiiarse deben alcanzar una cober-

3
Referencia Web
Uno extenso coleccibn de ((consejos sobre
pruebas 00)) (incluyendo rnuchas referencios
tura de todos 10s estados [KIR94]. Eso significa que las
utiles) puede encontrarse en:
secuencias de operaciones deben causar que la clase
www.kineti~a.com/ootips/
cuenta haga transiciones por todos 10s estados:
La simbologia UMLse utiliza para el DTE que se ilustra en la Figura

23.3. Difiere ligeramente de la simbologia usada para 10s DTEs e n la
parte tres de este libro.
CAP~TULO
23 PRUEBAS ORIENTADAS A OBIETOS
El objetivo global de la verificacion orientada a objetos citen. El estado de la clase representada por 10s valo-
-encontrar el miximo numero de errores con un mini- res de sus atributos se examina, para determinar si
mo de esfuerz-, es idCntico a1 objetivo de prueba del persisten errores.
software convencional. Pero la estrategia y ticticas para La prueba de integracion puede llevarse a cab0 utili-
la prueba 00 difieren de mod0 significativo. La vision zando una estrategia basada en hilos o basada en el uso.
de verificacion se amplia, para incluir la revision de La estrategia basada en hilos integra el conjunto de cla-
ambos modelos de disefio y de anilisis. ses, que colaboran para responder a una entrada o suce-
En resumen, el enfoque de prueba se aleja del com- so. Las pruebas basadas en el uso construyen el sistema
ponente procedimental (el modulo) hacia la clase. Ya que en capas, comenzando con aquellas clases que no usan
10s modelos de analisis y disefio 00 y el c6digo fuente clases servidoras. Los mCtodos de disefio de integracion
resultante se acoplan seminticamente, la prueba (a mane- de casos de prueba pueden usar pruebas a1 azar y por par-
ra de revisiones tkcnicas formales) comienza en estas acti- ticion. En suma, las pruebas basadas en el escenario y las
vidades de ingenieria. Por esta razon, la revision de 10s pruebas derivadas de 10s modelos de comportamiento pue-
mCtodos CRC, objeto-relacion y objeto-comportamiento, den usarse para verificar una clase y sus colaboraciones.
pueden verse como una primera etapa de prueba. Una secuencia de pruebas registra el flujo de operacio-
Una vez que la P O 0 ha sido concluida, las prue- nes, a travCs de las colaboraciones de clases.
bas de unidad se aplican a cada clase. El disefio de La prueba de validacion de sistemas 00 esta orien-
pruebas para una clase utiliza una variedad de mCto- tada a caja negra y puede completarse aplicando 10s
dos: pruebas basadas en errores, las pruebas a1 azar mismos mCtodos de prueba de caja de negra discutidos
y las pruebas por particion. Cada uno de estos mCto- para el software convencional. Sin embargo, las prue-
dos ejercita las operaciones encapsuladas por la cla- bas basadas en el escenario dominan la validacion de
se. Las secuencias de pruebas se diseiian para sistemas 00, haciendo que el caso de uso sea el con-
asegurarse de que las operaciones relevantes se ejer- ductor primario para las pruebas de validacion.
[AMB95] Ambler, S., <<UsingUse Cases,,, Sofmare Deve- [KIR94] Kirani, S., y W.T. Tsai, <<Specificationand Verifica-
lopment, Julio de 1995, pp. 53-61. tion of Object-Oriented Programs,,, Technical Report TR
[BER93] Berard, E.V., Essays on Object-Oriented Software 94-96,Computer Science Department, University of Min-
Engineering, vol. 1, Addison-Wesley, 1993. nesota, Diciembre de 1994.
[BIN94a] Binder, R.V., {{TestingObject-Oriented Systems:
A Status Report,,, American Programmer, vol. 7, n." 4, [LIN94] Lindland, O.I., et al., dnderstanding Quality in Con-
Abril de 1994, pp. 23-28. ceptual Modeling,,, IEEE Software, vol. 11, n." 4, Julio de
1994, pp. 42-49.
[BIN94b] Binder, R.V., <<Object-OrientedSoftware Testing,,,
CACM, vol. 37, n." 9, Septiembre de 1994, p. 29. [MAR941 Marick, B., The Craft of Software Testing, Prenti-
[CHA93] DeChampeaux, D., D. Lea y P. Faure, Object-Orien- ce Hall, 1994.
ted System Development, Addison-Wesley, 1993.
[FIC92] Fichman, R., y C. Kemerer, {{Object-Orientedand [MGR94] McGregor, J.D., y T.D. Korson, <<IntegratedObject-
conceptual Design Methodologies,,, Computer, vol. 25, Oriented Testing and Development Processes,,, CACM,
n." 10, Octubre de 1992, pp. 22-39. vol. 37, n." 9, Septiembre de 1994, pp. 59-77.
PR- Y PUNTOS A CO- a '
23.1. Describa con sus propias palabras por quC la clase es 23.4. Derive un conjunto de tarjetas indice CRC para Hogar-
la mas pequeiia unidad razonable para las pruebas dentro de Seguro y ejecute 10s pasos seiialados en la Secci6n 23.2.2 para
un sistema 00. determinar si existen inconsistencias.
23.2. LPor quC debemos probar de nuevo las subclases ins- 23.5. cud es la diferencia entre las estrategias basadas en hilos
tanciadas de una clase existente si Csta ya ha sido probada por y aquellas estrategias basadas en uso para las pruebas de inte-
complete? ~Podemosusar 10s casos de prueba diseiiados para gracion? ~ C o m ocabe la prueba de appacion en ellas?
dicha clase? 23.6. Aplique la prueba aleatoria y la de particion a tres cla-
23.3. L P OquC
~ debe comenzar la ccprueba,, con las activida- ses definidas en el diseiio del sistema HogarSeguro produci-
des de A 0 0 y DOO? do por usted en el Problema 22.12.
Produzca casos de prueba que indiquen las secuencias de ope- 23.10. Obtenga pruebas usando 10s mCtodos sefialados en 10s
raciones que se invocaran. Problemas 23.6 y 23.7 para el sistema de e-mail considerado
.23.7.Aplique la prueba de multiples clases y las pruebas deri- en el Problema 22.15.
vadas del modelo de comportamiento a1 disefio de HogarSe-
guro. 23.11. Obtenga pruebas usando 10s mCtodos sefialados en 10s
Problemas 23.6 y 23.7 para el sistema ATC considerado en el
23.8. Obtenga pruebas usando 10s mCtodos sefialados en 10s Problema 22.16.
Problemas 23.6 y 23.7 para el sistema SSRB descrito en el
Problema 22.13. 23.12. Obtenga cuatro pruebas adicionales usando cada
23.9. Obtenga pruebas usando 10s mCtodos sefialados en 10s uno de 10s mCtodos sefialados en 10s Problemas 23.6 y 23.7
Problemas 23.6 y 23.7 para el juego de video considerado en para la aplicaci6n bancaria presentada en las Secciones 23.5
el Problema 22.14. y 23.6.
La literatura para la prueba 00 es relativamente escasa, aun- Jorgenesen (Software Testing: A Craftsman's Approach,
que se ha expandido algo en aiios recientes. Binder (Testing CRC Press, 1995) y McGregor y Sykes (Object-Oriented
Object-Oriented Systems: Models, Patterns, and Tools, Addi- Software Development, Van Nostrand Reinhold, 1992) pre-
son-Wesley, 2000) ha escrito el tratarniento mas extenso del senta capitulos dedicados a1 tema. Beizer (Black-Box Tes-
tema publicado hasta la fecha. Siege1 y Muller (Object Orien- ting, Wiley, 1995) analiza una variedad de mCtodos de
ted Software Testing: A Hierarchical Approach, Wiley, 1996) disefio de casos prueba 10s cuales son apropiados en un con-
propusieron una estrategia practica de prueba para sistemas texto 00.
00. Marick (The Craft of Software Testing: Subsystem Tes- Binder (Testing Object-Oriented Systems, Addison-Wes-
ting Including Object-Based and Object-Oriented Testing, ley, 1996) y Marick [MAR941 presenta tratamientos detalla-
Prentice Hall, 1995) cubre la prueba tanto para software con- dos de prueba 00. En resumen, muchas de las fuentes
vencional como para 0 0 . anotadas para el Capitulo 17 son en general aplicables a la
Antologias de publicaciones sobre prueba 00 han sido edi- prueba 00.
tadas por Kung et al. (Testing Object-Oriented Software, IEEE Una amplia variedad de fuentes de informaci6n de prue-
Computer Society, 1998) y Braude (Object Oriented Analysis, ba orientada a objetos y temas relacionados se encuentran dis-
Design and Testing: Selected Readings, IEEE Computer ponibles en internet. Una lista reciente a sitios (paginas) web
Society, 1998). Estos tutoriales de IEEE proporcionan una inte- que son relevantes a la prueba 00 puede encontrarse en
resante perspectiva hist6rica en el desarrollo de prueba 00. http://www.pressman5.com
INGENIER~A
Los objetivos primarios para las mCtricas orientadas a Cada uno de estos objetivos es importante, per0 para
objetos no son diferentes de aquellos de las mCtricas el ingeniero de software la calidad del producto debe
desarrolladas para el software convencional: ser lo m8s importante. Pero jc6m0 medir la calidad de
un sistema OO? ~QuCcaracteristicas del modelo de dise-
para entender mejor la calidad del producto. fio pueden y deben evaluarse para determinar si el sis-
para evaluar la efectividad del proceso. tema sera fhcil de implementar, facil de verificar, simple
de modificar y, lo mas importante, aceptable para 10s
Para mejorar la d i d a d del trabajo llevado a cab0 a1 usuarios finales? Estas preguntas serin contestadas en
nivel del proyecto. la p a t e restante del capitulo.
Las metricas para cualquier producto de ingenieria son Ya que el software convencional enfatiza la funcion
reguladas por las caracteristicas linicas del producto. como un mecanismo de localizacion, las mCtricas de
Por ejemplo, seria inlitil o sin sentido contar las millas software se han enfocado a la estructura interna o fun-
por galon de consumo para un automovil elCctrico. La ciones de complejidad (por ejemplo, longitud del modu-
mCtrica es firme para 10s automoviles convencionales lo, cohesion o complejidad ciclom~tica),o a la manera
(es decir, impulsados por sistemas de combustion inter- como las funciones se conectan entre si (acoplamiento
na a gasolina) per0 no se aplica cuando el mod0 de pro- de modulos).
pulsion cambia radicalmente. El software orientado a
objetos es fundamentalmente diferente del software
desarrollado con el uso de mCtodos convencionales. Por Mbtricas tbcnicos porn sohore convendonal
esta razon, las metricas para sistemas 00 deben ser afi- se describen en el Copltulo 19.
nadas a las caracteristicas que distinguen a1 software
00 del software convencional. Puesto que la clase es la unidad basica de un siste-
Berard [BER95] define cinco caracteristicas que ma 00, la localizaci6n se basa en 10s objetos. Por esta
regulan las mCtricas especializadas: Localizacion, razon, las mCtricas deben aplicarse a la clase (objeto),
encapsulacion, ocultamiento de informacion, herencia como a una entidad completa. En suma, la relacion entre
y tCcnicas de abstraccion de objetos. Cada una de estas operaciones (funciones) y clases no es necesariamente
caracteristicas se discute brevemente en las secciones uno a uno. Por lo tanto, las mCtricas que reflejan la mane-
siguientesl. ra en la que las clases colaboran deben ser capaces de
acomodarse a relaciones uno a muchos y muchos a uno.
Referencia web/ ' 24.2.2. Encapsulacidn

Berard [BER95] define la encapsulacion como el
Una extension de busquedo para rnitricas 00 lo puedes obtener
en: www.obienv.com /cetus / 00-metrics.html ccempaquetamiento (o ligamento) de una coleccion de
elementos. Ejemplos de bajo nivel de encapsulaci6n
[para software convencional] incluyen registros y matri-
24.2.1. Localizacion ces, [y] subprogramas (por ejemplo, procedimientos,
La localizaci6n es una caracteristica del software que funciones, subrutinas y phrrafos), son mecanismos de
indica la manera en que la informaci6n se concentra en nivel medio para la encapsulation.>>
un programa. Por ejemplo, 10s mCtodos convenciona-
les para la descomposicion funcional organizan la infor-
macion en torno a las funciones que son tipicamente las cmceptos bkicm de disaiio se dexriben
implementadas como modulos procedimentales. Los en el Copiiub 13. Su apliioci6n 01 sufiwore 00
mCtodos manejados por datos localizan la informacion se dixute en el Copfhrlo 20.
en torno a estructuras de datos especificas. En el con-
texto 00, la informacion se concentra por la encapsu- Para 10s sistemas 00, la encapsulacion engloba las
lacion de datos y procesos dentro de 10s limites de una responsabilidades de una clase, incluyendo sus atribu-
clase u objeto. tos (y otras clases para objetos agregados) y operacio-
' Este estudio ha sido adaptado de [BER95].

C A P ~ T U L O24 M ~ T R I C A ST ~ C N I C A SPARA SISTEMAS ORIENTADOS A OBIETOS
nes, y 10s estados de la clase, definidos por valores de una jerarquia de clases. En general, el software con-
atributos especificos. vencional no cumple esta caracteristica.
La encapsulacih influye en las metricas, cambian- Ya que la herencia es una caracteristica vital en
do el enfoque de las mediciones de un m6dulo simple, muchos sistemas 00, muchos mCtodos 00 se centran
a un paquete de datos (atributos) y m6dulos de proce- en ella. Los ejemplos (discutidos rnis adelante en este
so (operaciones). capitulo) incluyen mdltiples hijos (instancias inmedia-
En suma, la encapsulaci6n eleva la medici6n a un tas de una clase), mdltiples padres (generalizaciones
nivel de abstraccih mis alto. inmediatas), y jerarquias de clase a un nivel de anida-
Por ejemplo, rnis adelante en este capitulo se intro- miento (profundidad de una clase en la jerarquia de
ducirh las mCtricas asociadas con el nlimero de opera- herencia).
ciones por clase. Contrasta este nivel de abstraccih con
las metricas que se centran en contar condiciones boo-
leanas (complejidad ciclomitica) o en contar lineas de
c6digo. La abstraccih es un mecanismo que permite a1 dise-
iiador concentrarse en 10s detalles esenciales de un com-
ponente de programa (ya Sean datos o procesos),
prestando poca atenci6n a 10s detalles de bajo nivel.
La ocultacih de informacih suprime (u oculta) 10s Como Berard declara: <<laabstraccih es un concepto
detalles operacionales de un componente de programa. relativo. A medida que se mueve a niveles rnis altos de
Solo se proporciona la informacih necesaria para acce- abstraccih, se ignoran rnis y rnis detalles, es decir, se
der a1 componente a aquellos otros componentes que tiene una visi6n mis general de un concepto o elemen-
deseen acceder. to. A medida que se mueve a niveles de abstraccih rnis
Un sistema 00 bien diseiiado debe implementar bajos, se introducen rnis detalles, es decir, se tiene una
ocultacih de informaci6n. Por esta r a z h , las mCtricas visi6n rnis especifica de un concepto o elemento.,,
que proporcionan una indicacih del grado de oculta- Ya que una clase es una abstraccih, que puede visua-
ci6n logrado suministran un indicio de la calidad del lizarse a diferentes niveles de detalle de diferentes de
diseiio 00. maneras (por ejemplo, como una lista de operaciones,
como una secuencia de estados, como una serie de cola-
boraciones), las mCtricas 00 representan abstracciones
24.2.4. Herencia en tCrminos de mediciones de una clase (por ejemplo,
La herencia es un mecanismo que habilita las respon- numero de instancias por clase por aplicacih, ndmero
sabilidades de un objeto, para propagarse a otros obje- o clases parametrizadas por aplicacibn, y proporcih de
tos. La herencia ocurre a travCs de todos 10s niveles de clases parametrizadas con clases no parametrizadas).
Mucho acerca del diseiio orientado a objetos es sub- dad. La poblacidn se mide haciendo un recuento de las
jetivo -un diseiiador experimentado <csabe>> como entidades 00,como las clases u operaciones. Las medi-
caracterizar a un sistema 00, para que implemente das de volumen son idCnticas a las de poblaci6n, per0
efectivamente 10s requerimientos del cliente-. Pero, se realizan dinimicamente - e n un instante de tiempo
cuando un modelo de diseiio 00 crece en tamaiio y dado-. La longitudes la medida de una cadena de ele-
complejidad, una visi6n mis objetiva de las caracte- mentos de disefio interconectados (por ejemplo, la pro-
n'sticas del diseiio puede beneficiar a1 diseiiador expe- fundidad de un irbol de herencia es una medida de
rimentado (que adquiere vista adicional), y a1 novato longitud). Las mktricas defuncionalidad proporcionan
(que obtiene indicadores de calidad que de otra mane- una indicaci6n indirecta del valor entregado a1 cliente
ra no estm'an disponibles). por una aplicacih 00.
e ~ Q u ecaracteristicas pueden
rnedirse cuando se evalua
un diseiia OO?
Complejidad. Asi como el tamaiio, existen diferen-
tes enfoques de la complejidad del software [ZUS97].
Whitmire la define en tkrminos de caracteristicas estruc-
turales, examinando c6mo se interrelacionan las clases
Como parte de un tratamiento detallado de las mktri- de un diseiio 00 con otras.
cas de software para sistemas 00, Whitmire [WHI97] Acoplamiento. Las conexiones fisicas entre 10s ele-
describe nueve caracten'sticas distintas y medibles de mentos del diseiio 00 (por ejemplo, el numero de cola-
un diseiio 00: boraciones entre clases o el numero de mensajes
Tamaiio. El tamaiio se define en tkrminos de cuatro intercambiados entre objetos), representan el acopla-
enfoques: poblacih, volumen, longitud y funcionali- miento dentro de un sistema 00.
INGENIERfA DEL SOFTWARE. UN ENFOQUE P R ~ C T I C O
Suficiencia. Whitmire define la suficiencia como <<el

.grado en que una abstracci6n posee 10s rasgos minimos
necesarios, o el grado en que una componente de disefio
posee caractensticas en su abstracci611, desde el punto
Un informe tecnico de lo NASA, que obordo metricos de
de vista de la aplicaci6n actual,,. Dicho de otro modo,
colidod para sistemos 00, puede descorgarse del
se hace la pregunta: <<iquCpropiedades tiene que poseer
satc.gsfc.nasa.gov/suppart/index.html
esta abstracci6n (clase) para que sea util?n [WHI97].
En esencia, un componente de disefio (por ejemplo, una
clase) es suficiente si refleja completamente todas las Originalidad. Una caractenstica similar a la simpli-
propiedades del objeto dominio de la aplicaci6n que se cidad, la originalidad (aplicada tanto a operaciones como
modela; esto es lo que significa que la abstracci6n a clases) es el grado en que una operacion es at6mica;
(clase), posea 10s rasgos imprescindibles. esto significa que la operaci6n no puede ser construida
fuera de una secuencia de otras operaciones contenidas
dentro de una clase. Una clase que exhibe un alto grado
de originalidad encapsula solamente las operaciones pri-
mitivas.
Similitud. Esta mCtrica indica el grado en que dos o
m b clases son similares en tkrminos de estructura, com-
portamiento, funci6n o prop6sito.
Volatilidad. Como se menciono anteriormente en
Integridad. La 6nica diferencia entre integridad y sufi- este libro, pueden ocunir cambios en el disefio cuando
ciencia es <<elconjunto de caractensticas, contra las que se modifiquen 10s requisitos, o cuando ocurran modifi-
se comparan la abstracci6n o componente de disefio caciones en otras partes de la aplicacibn, resultando una
[WH197]~.La suficiencia compara la abstraccion, desde adaptation obligatoria del componente de disefio en
el punto de vista de la aplicaci6n en cuesti6n. La integri- cuesti6n. La volatilidad de un componente de disefio
dad considera muchos puntos de vista, preguntindose: 00 mide la probabilidad de que un carnbio ocurra.
<<~QuC propiedades se requieren para representar com- La descripci6n de mCtricas de Whitmire para estas
pletamente el objeto dominio del problema?n Ya que 10s caractensticas de disefio se encuentra fuera del 6mbito
criterios de integridad consideran diferentes puntos de de este libro. Los lectores interesados deben consultar
vista, hay una implicaci6n indirecta, acerca del grado en [WH197], para mhs detalles.
que la abstracci6n o componente de disefio puede ser reu- En realidad, las mktricas tCcnicas para sistemas
tilizada. 00 pueden aplicarse no s6l0 a1 modelo de disefio,
Cohesion. Asi como su correspondiente en el software sino tambiCn a1 modelo de anhlisis. En las secciones
convencional, un componente 00 debe disefiarse de siguientes, se exploran las metricas que proporcio-
manera que posea todas las operaciones trabajando con- nan un indicador de calidad, a1 nivel de las clases 00
juntamente para alcanzar un prop6sito 6nico y bien defi- y a1 nivel de operaci6n. En suma, las mCtricas apli-
nido. La cohesi6n de una clase se determina examinando cables a1 manejo de proyectos y pruebas tambiCn se
el grado en que <<elconjunto de propiedades que posee comentarhn.
sea parte del disefio o dominio del problems)> [WHI97]. La clase es la unidad fundamental de un sistema 00.
Por esta raz6n, las medidas y metricas para una clase Asi mismo, la clase <<padre>>es de las que heredan las
individual, la jerarquia de clases y las colaboraciones subclases (algunas veces llamadas hijas), sus atributos
de clases poseen un valor incalculable, para el ingenie- y operaciones. La clase, normalmente, colabora con
ro del software que ha de evaluar la calidad del diseiio. otras clases. Cada una de estas caracteristicas pueden
En capitulos anteriores se estudi6 que la clase encap- usarse como base de la medici6n2.
sula operaciones (procesamiento) y atributos (datos).
Z ~ 6 t e s eque la validez de algunas metricas, discutidas en este capi-

tulo, actualmente s e debate en la literatura tecnica. Aquellos que
abanderan la teoria de medicion requieren de un grado de forma-
lismo que algunas de las metricas 00 no proporcionan. De cualquier
manera, e s razonable declarar que todas las metricas proporcionan
una vision litil para el ingeniero de software.
C A P ~ T U L O24 MPTRICAS T P C N I C A S PARA SISTEMAS ORIENTADOS A O B J E T O S
24.4.1. La serie de metricas CK ejemplo, le falta un mCtodo correspondiente de si), entonces

pasari su mensaje a sus clases padres.
Uno de 10s conjuntos de mCtricas 00 mhs ampliamen-
te referenciados, ha sido el propuesto por Chidamber y En el otro extremo, el recuento podria incluir a todos aque-
110s mCtodos definidos en la clase en cuesti6n, junto con 10s
Kemerer [CHI94]. Normalmente conocidas como la mCtodos heredados. Este enfoque enfatiza la importancia del
serie de me'tricas C K , 10s autores han propuesto seis espacio de estados, en lugar del incremento de la clase, para la
mCtricas basadas en clases para sistemas 003. comprensih de la clase.
Metodos ponderados por clase (MPC). Asumen Entre estos extremes, existe cierto numero de posibilidades
que n mCtodos de complejidad c l , c2, ... cn se definen diferentes. Por ejemplo, una podria restringir el recuento a la
para la clase C. La mCtrica de complejidad especifica clase en cuesti6n y 10s miembros heredados directamente de
que se eligi6 (por ejemplo, complejidad ciclomAtica) sus padres. Este enfoque se basa en el argument0 de que la
especializacion de clases padres es lo m k directamente rele-
debe normalizarse de manera que la complejidad nomi- vante en el comportamiento de las clases descendientes.
nal para un mCtodo toma un valor de 10.
Asi como la mayoria de las convenciones de recuento
MPC = E i en mCtricas de software, cualquiera de 10s enfoques resu-
para cada i = 1 hasta n. midos con anterioridad es aceptable, siempre que el
El nlimero de mCtodos y su complejidad son indicado- enfoque de recuento sea aplicado consistentemente a1
res razonables de la cantidad de esfuerzo requerido para momento de recolectar mCtricas.
implementar y verificar una clase. En suma, cuanto ~ r b o de
l profundidad de herencia (APH). Esta
mayor sea el ntimero de mCtodos, mhs complejo es el mCtrica se define como ccla maxima longitud del nodo
hbol de herencia (todas las subclases heredan mCtodos a la raiz del hbol>>[CHI94]. Con referencia a la Figura
de sus padres). Finalmente, a medida que crece el 24.1, el valor del APH para la jerarquia de clases mos-
nlimero de mCtodos para una clase dada, mas probable trada es de 4.
es que se vuelvan mas y miis especificos de la aplica- A medida que el APH crece, es posible que clases de
ci6n, asi que se limita el potencial de reutilizaci6n. Por miis bajos niveles h e r e d a h muchos mCtodos. Esto con-
todas estas razones, el MPC debe mantenerse tan bajo lleva dificultades potenciales, cuando se intenta prede-
como sea razonable. cir el comportamiento de una clase. Una jerarquia de
clases profunda (el APH es largo) tambiCn conduce a
una complejidad de disefio mayor. Por el lado positivo,
10s valores APH grandes implican un gran nlimero de
mCtodos que se reutilizarin.
El nhnero de mbtodos y su compleiidod esta Numero de descendientes (NDD). Las subclases
directomente relocionodo con el esfuerzo requerido inmediatamente subordinadas a una clase en la jerar-
poro comprobor uno close.
quia de clases se denominan sus descendientes. Con
referencia a la Figura 24.1, la clase C2 tiene tres des-
Aunque podria parecer relativamente claro llevar la cendientes -subclases C21, C22 y C23-.
cuenta del nlimero de mCtodos en una clase, el pro-
blema es mas complejo de lo que parece, Churcher A medida que el ndmero de descendientes crece, la
y Shepperd [CHU95] discuten este aspect0 cuando reutilizaci6n se incrementa, per0 ademas es cierto que
escriben: cuando el NDD crece, la abstraccih representada por
la clase predecesora puede diluirse. Esto significa que
Para contar mCtodos, se debe contestar la pregunta funda- existe una posibilidad de que algunos descendientes no
mental: cc jpertenece un mCtodo hnicamente a la clase que lo
define, o pertenece a cada clase que la hereda directa o indi- Sean miembros, realmente apropiados, de la clase pre-
rectamente?~.Las preguntas como esta pueden parecer trivia- decesora. A medida que el NDD crece, la cantidad de
les, ya que el sistema de ejecuci6n las resolved finalmente. De pruebas (requeridas para ejercitar cada descendiente en
cualquier manera, las implicaciones para las mCtricas deben su context0 operativo) se incrementarh tambiCn.
ser significativas.
Una posibilidad es restringir el contador de la clase actual
ignorando 10s rniembros heredados. La motivation para esto
podria ser que 10s miembros heredados ya han sido contados l o herencio es una hobilidod extremodomente poderosa,
en las clases donde fueron dehidos, asi que el incremento de que puede meterlo en problemas, si no se usa con
la clase es la mejor medida de su funcionalidad, lo que refleja
cuidodo. Utilice el APH y otms mitn'cos relocionodos
su raz6n para existir. Para entender lo que la clase lleva a cabo,
la fuente de informaci6n m& importante son sus propias ope- poro done uno leci~rade lo compleiidodde lo jerorquia
raciones. Si una clase no puede responder a un mensaje (por de closes.
Chidamber, Darcy y Kemerer usan el termino metodos en vez de

operaciones.Su utilization del termino es reflejada en esta seccion.
secuencia de comprobacidn (Capitulo 23) se incrementa

tambiCn. Asi mismo, se dice que, asi como la RPC
aumenta, la complejidad del diseiio global de la clase
se incrementa.
Carencia de cohesion en 10s metodos (CCM). Cada
mCtodo dentro de una clase, C, accede a uno o mis atri-
butos (tambiCn llamados variables de instancia) CCM
es el nlimero de mCtodos que accede a uno o mis de 10s
mismos atributos4.Si no existen mCtodos que accedan
a 10s mismos atributos, entonces CCM = 0.
Para ilustrar el caso en el que CCM es diferente de 0,
considtrese una clase con 6 mCtodos. Cuatro de 10s mete
dos tienen uno o m8s atributos en comlin (es decir, acce-
den a atributos comunes). De esta manera, CCM = 4.
Si CCM es alto, 10s mttodos deben acoplarse a otro,
por medio de 10s atributos. Esto incrementa la comple-
jidad del disefio de clases. En general, 10s valores altos
para CCM implican que la clase debe disefiarse mejor
descomponiendo en dos o m8s clases distintas. Aunque
existan casos en 10s que un valor alto para CCM es jus-
tificable, es deseable mantener la cohesidn aka, es decir,
mantener CCM bajo.
FIGURA 24.1. Una jerarquia de clases.
Acoplamiento entre clases objeto (ACO). El

modelo CRC (Capitulo 21) debe utilizarse para deter-
minar el valor de ACO. En esencia, ACO es el nlimero
de colaboraciones listadas para una clase, en la tarjeta
indice CRC.
A medida que ACO se incrementa, es mis probable 24.4.2. MBtricas propuestas por Lorenz y Kidd
que el grado de reutilizacidn de una clase decrezca. Valo- En su libro sobre mCmcas 0 0 , Lorenz y Kidd [LOR941
res altos de ACO ademis complican las modificaciones separan las mCtricas basadas en clases en cuatro amplias
y las pruebas, que se producen cuando se realizan modi- categorias: tamailo, herencia, valores intemos y valores
ficaciones. En general, 10s valores de ACO para cada extemos. Las mttricas orientadas al t a m ~ parao las cla-
clase deben mantenerse tan bajos como sea razonable. ses 00 se centran en el recuento de atributos y operacio-
Esto es consistente con la regla general para reducir el nes para cada clase individual,y 10s valores promedio para
acoplamiento, para el software convencional. el sistema 00 como un todo. Las mCtricas basadas en la
herencia se centran en la forma en que las operaciones se
reutilizan en la jerarquia de clases. Las mCtricas para vale
res intemos de clase examinan la cohesih (Seccidn 24.4.1)
10s conceptm de ocoplomiento y cohesibn se ophcon tonto
ol softwore convencionol como 01 00.Montengo
y 10s aspectos orientados a1 caigo; las mCtricas orienta-
el acoplomiento de doses bolo y b cohesibn de opemu6n olto.
das a valores extemos, examinan el acoplamiento y la reu-
tilizacidn. A continuacidn, una muestra de mttricas
propuestas por Lorenz y Kidd ':
Respuesta para una clase (RPC). El conjunto de
respuesta de una clase es ccuna serie de mCtodos que Tamafio de clase (TC). El tamaiio general de una clase
pueden potencialmente ser ejecutados, en respuesta a puede medirse determinando las siguientes medidas:
un mensaje recibido por un objeto, en la clase>>
[CHI94]. el total de operaciones (operacionestanto heredadas
RPC se define como el nlimero de mCtodos en el con- como privadas de la instancia), que se encapsulan
junto de respuesta. dentro de la clase.
A medida que la RPC aumenta, el esfuerzo requerido el n h e r o de atributos (atributos tanto heredados como
para la comprobacidn tambiCn se incrementa, ya que la privados de la instancia), encapsulados por la clase.
La definicion formal e s un poco mas compleja. Vease [CHI941 para Para un tratamiento mas completo. vease [LOR94].
mas detalle.
CAPfTULO 2 4 M ~ T R I C A ST ~ C N I C A SPARA SISTEMAS ORIENTADOS A O B l E T O S
donde nivel corresponde a1 nivel en la jerarquia de cla-

ses en que reside la clase, y MtOmIes el numero total de
Duronte lo revision del modelo de AOO, 10s turjetos CRC mCtodos de la clase. Cuanto mas elevado sea el valor
proporcionon uno indicocion rozonoble de 10s volores de IE, mas probable sera que la jerarquia de clases tenga
esperodos porn TC. Si encuentro uno close con demosiodo clases que no se ajusten a la abstracci6n de la super-
responsobilidod duronte AOO, considere el porticionorlo. clase.
La mCtrica MPC propuesta por Chidamber y Keme- 24.4.3. L a coleccion de metricas MDOO
rer (Secci6n 24.4.1) es tambiCn una mttrica ponderada Harrison, Counseil y Nithi [HAR98] propusieron un
del tamaiio de clase. conjunto de mCtricas para el disefio orientado a objetos
Como se indic6 con anterioridad, valores grandes (MDOO), que proporcionan indicadores cuantitativos
para TC indican que la clase debe tener bastante res- para el diseiio de caracten'sticas 00. A continuation,
ponsabilidad. Esto reduciri la reutilizaci6n de la clase una muestra de mCtricas MDOO:
y complicari la implementaci6n y las pruebas. En gene-
ral, operaciones y atributos heredados o publicos deben
ser ponderados con mayor importancia, cuando se deter-
mina el tamaiio de clase. [LOR941 Operaciones y atri-
butos privados, permiten la especializacion y son mis
propios del disefio.
TambiCn se pueden calcular 10s promedios para el
numero de atributos y operaciones de clase. Cuanto
menor sea el valor promedio para el tamafio, seri mis
posible que las clases dentro del sistema puedan reuti- Factor de herencia de metodos (FHM). El grado
lizarse. en que la arquitectura de clases de un sistema 00 hace
uso de la herencia tanto para mttodos (operaciones)
Numero de operaciones redefinidas para una sub-
como atributos, se define corno:
clase (NOR). Existen casos en que una subclase reem-
plaza una operaci6n heredada de su superclase por una FHM = Z Mi(Cj)/ Z Ma(Cj)
versi6n especializada para su propio uso. A esto se le donde el sumatorio va desde i=l hasta TC. TC se defi-
llama redejnicidn. Los valores grandes para el NOR, ne como el numero total de clases en la arquitectura, Ci
generalmente indican un problema de diseiio. Tal como es una clase dentro de la arquitectura, y
indican Lorenz y Kidd:
Ma(Ci) = MAC,) + Mi(Ci)
Dado que una subclase debe ser la especializaci6n de sus
superclases, deben, sobre todo, extender 10s servicios (opera- donde
ciones) de las superclases. Esto debe resultar en nuevos nom- Ma(Cj)= al numero de mCtodos que pueden ser invo-
bres de mktodos unicos.
cados en relacion con C i
Si el NOR es grande, el disefiador ha violado la abs- MACi) = al nlimero de mCtodos declarados en la clase
tracci6n representada por la superclase. Esto provoca 0
Li
una dCbil jerarquia de clases y un software 0 0 , que
Mi(Ci)= a1 numero de mCtodos heredados (y no rede-
puede ser dificil de probar y modificar.
finidos) en C i
Numero de operaciones aiiadidas por una sub- El valor de FHM (el factor de herencia de atributo,
clase (NOA). Las subclases se especializan afiadiendo FHA, se define de manera aniloga), proporciona una
operaciones y atributos privados. A medida que el referencia sobre impact0 de la herencia en software 00.
valor NOA se incrementa, la subclase se aleja de la
abstracci6n representada por la superclase. En gene- Factor de acoplamiento (FA). Con anterioridad, en
ral, a medida que la profundidad de la jerarquia de este capitulo se indic6 que el acoplamiento es un indi-
clases incrementa (APH se vuelve grande), el valor cador de las conexiones entre 10s elementos del disefio
para NOA a niveles mas bajos en la jerarquia deberia 00. La coleccion de mCtricas MDOO define el factor
disminuir. de acoplamiento de la siguiente manera:
1ndice de especializacion (IES). El indice de espe- FA = [ Z i q es-cliente (C,, C,)] / ( T C ~- T C )
cializacion proporciona una indicacion aproximada del donde 10s sumatorios van desde i = 1 hasta TC y desde
grado de especializaci611, para cada una de las subcla- j = 1 hasta TC. La funci6n
ses en un sistema 00. La especializaci6n se puede alcan-
zar aiiadiendo o eliminando operaciones, pero tambiCn Es cliente = 1, si existe una relacion entre la clase
redefiniendo. cliinte, C , y la clase semidora C , y C , # C,.
IE = [NOR x nivel ] 1 MtOmI Es-cliente = 0, en cualquier otro caso.
A pesar de que muchos factores afectan la compleji- FP = ZiM,(Ci) I Zi [M,(Ci) x DC (Ci)]

dad, comprensidn y mantenimiento del software, es razo- donde 10s sumatorios van desde i = 1 hasta TC y
nable concluir que conforme el valor del FA crece, la
complejidad del software 00 tarnbiCn crece, y la com- Md(Ci) = M,(C,) + Mo(Ci)
prension, el mantenimiento y el potencial de reutiliza-
cion, pueden resentirse como resultado. Y
M,(Ci) = a1 numero de mCtodos nuevos.
Factor de polimorfismo (FP). Harrison, Counsell y
Nithi [HAR98] definen FP como ccel nlimero de mCto- Mo(Ci)= a1 nlimero de mktodos redefinidos.
dos que redefinen mCtodos heredados, dividida por el DC(Ci) = a1 nlimero de descendientes (el nlimero de
maxim0 nlimero de posibles situaciones polim6rficas clases descendientes de una clase base).
distintas ...; de esta manera, el FP es una medida indi- Harrison, Counsell y Nithi [HAR98] presentan un
recta de la cantidad relativa de ligadura dinamica en un analisis detallado de FHM, FA y FP en conjunto con
sistema>>.La coleccion de mCtricas MDOO define el FP otras metricas, y examinan su validez de uso, en la eva-
de la siguiente manera: luaci6n de la calidad del disefio.
Ya que la clase es la unidad dominante en 10s siste- enviados por una sola operaci6n se incrementan, es mas
mas 0 0 , se han propuesto menos mktricas para ope- probable que las responsabilidades no hayan sido correc-
raciones que las relacionadas con las clases. Churcher tamente asignadas dentro de la clase.
y Shepperd [CHU95] discuten lo anterior cuando
declaran que:
Resultados de estudios recientes indican que 10s mCtodos
tienden a ser pequeiios, tanto en t6rminos de nlimero de sen-
tencias como en complejidad logica [WIL93], sugiriendo que
la estructura de conectividadde un sistema debe ser m k impor-
tante que el contenido de 10s modulos individuales.
De cualquier modo, existen algunas ideas que pue- Complejidad de operacion (CO). La complejidad
den llegar a apreciarse, examinando las caracteristicas de una operaci6n puede ser calculada usando cualquiera
promedio para 10s mCtodos (operaciones). A continua- de las metricas de complejidad (Capitulo 19) propues-
cion se resumen tres simples metricas, propuestas por tas para el software convencional [ZUS90]. Ya que las
Lorenz y Kidd [LOR94]: operaciones deben limitarse a una responsabilidad espe-
Tamano medio de operacion (TOmedi,). Aunque cifica, el diseiiador deberia esforzarse por mantener la
las lineas de c6digo podrian ser usadas como un indi- CO tan baja como sea posible.
cador para el tamafio de operacibn, la medida LDC ado- Numero de parametros de media por operacion
lece de todos 10s problemas discutidos en el Capitulo 4. (NPmedi,). Tan largo como sea el numero de parime-
Por esta raz6n, el nlimero de mensajes enviados por la tros de operacibn, mas compleja sera la colaboraci6n
operaci6n proporciona una alternativa para el tamafio entre objetos. En general, NPmedi,debe mantenerse tan
de operaci6n. A medida que el numero de mensajes baja como sea posible.
Las metricas de disefio anotadas en las Secciones 24.4 organizan en categonas, que reflejan caracteristicas de
y 24.5 proporcionan una indicaci6n de la calidad de diseiio importantes.
diseiio. TambiCn proveen una indicacion general de la
cantidad de esfuerzo de pruebas requerido para probar Encapsulaci6n
un sistema 00. Carencia de cohesion en metodos (ccM)~. Cuanto
Binder [BIN941 sugiere que una amplia gama de mas alto sea el valor CCM sera necesario probar mas
metricas de disefio tienen una influencia directa en la estados para asegurar que 10s mttodos no generan efec-
cccomprobabilidadu de un sistema 00. Las mCtricas se tos colaterales.
Vease la Seccion 24.4.1 para una descripcih de CCM.

CAPfTULO 24 M ~ T R I C A ST ~ C N I C A SPARA S I S T E M A S O R I E N T A D O S A O B J E T O S
Porcentaje publico y protegido (PPP). Los atri-

butos p6blicos que se heredan de otras clases son visi-
b l e ~para esas clases. Los atributos protegidos son Lo comprobocian 00 puede ser un poco complejo.
una especializaci6n y son privados a subclases espe- Los mhtricos pueden oyudorle o lo osignocibn de recursos
cificas. Esta mCtrica indica el porcentaje de atribu- de pruebos o hilos, escenorios y grupos de closes,
tos de una clase que son p6blicos. Valores altos para que son wjetos)) bosodos en corocteristicos ponderodos.
PPP incrementan la probabilidad de efectos colate- Utilicelos.
rales entre clases. Las pruebas deben disefiarse para
asegurar que ese tipo de efectos colaterales sean des- Numero de Padres Directos (NPD). Cuando es uti-
cubiertos. lizado en el context0 0 0 , el NPD es una indicaci6n de
Acceso publico a datos miembros (APD). Esta herencia m6ltiple. NPD > 1 indica que la clase hereda
mCtrica indica el n6mero de clases (o mCtodos) que sus atributos y operaciones de mhs de una clase raiz. Se
pueden acceder a 10s atributos de otras clases, una debe evitar que NPD > 1 tanto como sea posible.
violaci6n de encapsulaci6n. Valores altos para APD Numero de descendientes (NDD) y arb01 de pro-
producen potencialmente efectos colaterales entre fundidad de herencia (APH)'. Tal como se explic6 en
clases. Las pruebas deben disefiarse para estar segu- el Capitulo 23,los mCtodos de la superclase tendrh que
ros de que ese tipo de efectos colaterales serhn des- ser probados nuevamente para cada subclase.
cubiertos.
Ademas de las mCtricas anteriores, Binder [BIN941
tambiCn define mCtricas para la complejidad y polimor-
fismo de las clases. Las mCtricas definidas para la com-
Numero de clases raiz (NCR). Esta mCtrica es un plejidad de clase, incluyen tres mCtricas CK (Secci6n
recuento de las distintas jerarquias de clases, que se des- 24.4.1): MCtodos ponderados por clase (MPC), el aco-
criben en el modelo de disefio. Se deben desarrollar las plamiento entre clases de objetos (ACO) y la respuesta
colecciones de pruebas para cada clase raiz, y la jerar- para una clase (RPC). En resumen, tambiCn se definen
quia de clases correspondiente. A medida que el NCR las mCtricas asociadas con el recuento de mktodos. Las
se incrementa, el esfuerzo de comprobaci6n tambiCn se mCtricas asociadas con el polirnorlkmo se especifican en
incrementa. detalle. Lo mejor es dejar su descripci6n a Binder.
Como se present6 en la Parte Dos de este libro, el tra- maci6n del tamafio de implementaci6n del software. El
bajo del jefe de proyecto es planear, coordinar, registrar tamafio es directamente proporcional a1 esfuerzo y la
y controlar un proyecto de software. En el Capitulo 20 duraci6n. Las siguientes mCtricas [LOR941 pueden pro-
se presentaron algunos de 10s aspectos especiales aso- porcionar una visi6n sobre el tamafio del software:
ciados con la gesti6n de proyecto para proyectos 00.
Pero iquC hay acerca de las mktricas? existe en mCtri-
cas 00 especializadas que puedan ser utilizadas por el l o oplitahilidad de un modelo de procesos evolutivos,
jefe de proyecto para proporcionar una visi6n interna llamodo el modelo retunivo/poralelo, se dixute en el
adicional sobre el progreso de su proyecto? 8. La res- Capitulo 20.
puesta, desde luego es ccsi~.
La primera actividad ejecutada por el jefe de pro-
Numero de escenario (NE). El n6mero de escena-
yecto es planificar, y una de las primeras tareas de pla- rios o casos uso (Capitulos 11 y 2 1) es directamente
nificaci6n es la estimation. Retomando el modelo proporcional a1 ndmero de clases requeridas para cubrir
evolutivo de procesos, la planificaci6n se vuelve a revi-
10s requisitos, el nlimero de estados para cada clase, el
sar despuCs de cada iteraci6n del software. De este n6mero de mCtodos, atributos y colaboraciones. El NE
modo, la planificaci6n (y sus estimaciones de proyec- es un importante indicador del tarnafio de un programa.
to) es revisada nuevamente despuCs de cada iteraci6n
de AOO, D O 0 e incluso POO. Numero de clases clave (NCC). Una clase clave se
Uno de 10s aspectos clave, a1 que debe hacer frente centra directamente en el dominio del negocio para el
un jefe de proyecto durante la planificaci61-1,es una esti- problema, y tendrh una menor probabilidad de ser imple-
' Vease la Seccion 24.4.1 para una descripcion de NCC y APM. Una descripcion interesante de la coleccion de metricas CK (Sec-
cion 24.4.1) para el uso en la administracion de la toma de decisio-
nes puede encontrarse en [CHI98].
INGENIERfA DEL SOFTWARE. UN ENFOQUE PRhCTICO
mentada por medio de la reutilizacion9. Por esta razon, Las mCtricas NE, NCC y NSUB pueden recolectar-
. valores altos para NCC indican gran trabajo de desa- se sobre proyectos 00 pasados, y e s t h relacionados con
rrollo substancial. Lorenz y Kidd [LOR941 sugieren que el esfuerzo invertido en el proyecto como un todo, y en
entre el 20 y el 40 por 100 de todas las clases en un sis- actividades de procesos individuales (por ejemplo, AOO,
tema 00 tipico corresponde a las clases clave. El resto DOO, PO0 y pruebas 0 0 ) . Estos datos pueden tambiCn
es infraestructura de soporte (GUI, comunicaciones, utilizarse junto con metricas de disefio discutidas con
bases de datos, etc.). anterioridad en este capitulo, para calcular ccmCtricas de
productividad>>, tales como el numero de clases prome-
Numero de subsistemas (NSUB). El numero de sub- dio por desarrollador o promedio de mktodos por per-
sistemas proporciona una vision sobre la asignacion de sona/mes. Colectivamente, estas metricas pueden usarse
recursos, la planificacion (con Cnfasis particular en el para estimar el esfuerzo, duration, personal y otra infor-
desarrollo paralelo) y el esfuerzo de integracion global. maci6n de proyecto para el proyecto actual.
El software orientado a objetos es fundamentalmente dife- Las metricas orientadas a operaciones se centran
rente a1 software desarrollado con el uso de mCtodos con- en el tamaiio y complejidad de las operaciones indi-
vencionales. Es por esto que las mCtricas para sistemas viduales. Sin embargo, es importante hacer notar que
00 se enfocan en la ponderacion que puede aplicarse a la primera para las metricas de disefio 00 es a nivel
las clases y a las caracteristicas del diseiio -1ocaliza- de clases.
cion, encapsulacion, ocultamiento de informacion,heren- Se ha propuesto una amplia variedad de metricas 00
cia y tkcnicas de abstraccion de objetos-, que definen para evaluar la comprobabilidadde un sistema 00.Estas
a la clase como unica. mCtricas se centran en la encapsulacion, herencia, com-
La colecci6n de mktricas CK define seis mCtricas de plejidad de las clases y polimorfismo. Muchas de estas
software orientadas a la clase que se centran en la cla- metricas han sido adaptadas de la coleccion CK y de las
se y en la jerarquia de clases. La coleccion de mCtricas mktricas propuestas por Lorenz y Kidd. Otras han sido
tambiCn incorpora mCtricas para evaluar las colabora- propuestas por Binder.
ciones entre clases y la cohesion de mCtodos que resi- Las caracteristicas ponderables del modelo de an&
den dentro de la clase. A1 nivel orientado a clases, la lisis y disefio pueden ayudar a1 jefe de proyecto de un
coleccion CK puede complementarse con las mCtricas sistema 00 en la planificacion y registro de las acti-
propuestas por Lorenz y Kidd y la coleccion de mCtri- vidades. El numero de escenarios (casos de uso), cla-
cas MDOO. Estas incluyen ponderaciones de cctamaiio>> ses clave y subsistemas proporcionan informacion
de clase, y otras metricas que proporcionan una vision acerca del nivel de esfuerzo requerido para implementar
acerca del grado de especializaci6n de las subclases. el sistema.
[BER95] Berard, E., Metrics for Object-Oriented Sojbare [HAR98] Harrison, R., S.J. Counseil y R.V. Nithi, <<An Eva-
Engineering, publicado en internet en comp.software- luation of the MOOD Set of Object-Oriented Software
eng, 28 de enero de 1995. Metrics,,, IEEE Trans. Sofrware Engineering, vol. 24, n." 6,
[CHI941 Chidamber, S.R., y C.F. Kemerer, <<A Metrics Sui- Junio de 1998, pp. 491-496.
te for Object-Oriented Design,,, IEEE Trans. Software [LOR941 Lorenz, M., y J. Kidd, Object-Oriented Software
Engineering, vol. 20, n." 6, Junio de 1994, pp. 476-493. Metric, Prentice-Hall, 1994.
[CHI981 Chidamber, S.R., D.P. y C.F. Kemerer, <<Manage-
ment Use of Metrics for Object-Oriented Software: An [WHI97] Whitmire, S., Object-Oriented Design Measure-
Exploratory Analysiw, IEEE Trans. Software Enginee- mente, Wiley, 1997.
ring, vol. 24, n." 8, Agosto de 1998, pp. 629-639.
[ZUS90] Zuse, H., Software Complexity: Measures and
[CHU95] Churcher, N.I., y M.J. Shepperd, <<Towards a Con- Methods, DeGruyter, Nueva York, 1990.
ceptual Framework for Object-Oriented Metricw, ACM
Software Engineering Notes, vol. 20, n." 2, Abril de 1995, [ZUS97] Zuse, H., A framework of Software Mesurement,
pp. 69-76. DeGruyter, Nueva York, 1997.
Esto solo es verdad hasta que una robusta libreria de componentes

reutilizables se desarrolla para un dominio particular.
CAP~TULO
24 METRICAS TECNICAS PARA SISTEMAS ORIENTADOS A OBJETOS
24.1. Revise las mCtricas presentadas en este capitulo y en el

Numero NGE NCC NSUB Esfuerzo
Capitulo 19. iC6m0 podia caracterizar las diferencias semin-
de proyecto (dias)
ticas y sintacticas entre las metricas para software conven-
cional y OO? 1 34 60 3 900
24.2. iC6m0 es que la localizacion afecta las mCtricas desa- 2 55 75 6 1.575
rrolladas para software convencional y OO?
3 122 260 8 4.420
r no se hace mas Cnfasis en las mCtricas 00 que
24.3. ~ P oquC
abordan las caractensticas especificas de las operaciones resi- 4 45 66 2 990
dentes dentro de una clase?
5 80 124 6 2.480
24.4. Revise las mCtricas descritas en este capitulo y sugiera
algunas que aborden directa o indirectamente el ocultarnien-
to de informacion. Se dispone de un nuevo proyecto que se encuentra
24.5. Revise las mCtricas descritas en este capitulo y sugiera en las primeras fases de AOO. Se estima que para este
algunas que aborden directa o indirectamente la abstraccion. proyecto se desarrollarin 95 casos practicos. Estimar:
24.6. Una clase x posee 12 operaciones. Se ha calculado la a. el n6mero total de clases que serhn necesarias para
complejidad ciclomitica para todas las operaciones del siste- implementar el sistema;
ma 00 y el valor promedio de la complejidad del m6dulo es b. la cantidad total de esfuerzo que sera necesaria para
4. Para la clase x la complejidad de las operaciones de la 1 a implementar el sistema.
la 12 es 5,4,3,6,8,2,2,5,5,4,4 respectivamente. Calcular MPC.
24.12. Su profesor le proporciona una lista de mCtricas 00
24.7. Con respecto a las Figuras 20.8a y b, calcule el valor procedente de este capitulo. Calcule 10s valores de estas mCtr-
APH para cada uno de 10s irboles de herencia. iCuil es el cas para uno o mas de 10s problemas que se indican a conti-
valor de NDD para la clase x2 de ambos irboles? nuaci6n:
24.8. Acuda a [CHI941 y presente una descripcion de una pigi- el modelo de diseiio para el diseiio HogarSeguro.
na referente a la definici6n formal de la metrica CCM.
el modelo de diseiio para el sistema SSRB descrito
24.9. En la Figura 20.8b, jcuil es el valor de NOA para las en el problema 12.13.
clases x3 y x4?
el modelo de diseiio para el juego de video conside-
24.10. Con respecto a la Figura 20.8b suponga que las cua- rado en el problema 22.14.
tro operaciones han sido invalidadas en el arb01 de herencia
(jerarquia de clases), jcual es el valor de IE para esa jerarquia? el modelo de diseiio para el correo electrhico con-
siderado en el problema 22.15.
24.11. Un equipo de software ha finalizado cinco proyec-
tos hasta la fecha. Los datos siguientes han sido recogidos para el modelo de diseiio para el problema CTA conside-
todos 10s tamaiios de 10s proyectos: rado en el problema 22.16.
Una variedad de libros de AOO, D O 0 y Comprobacion 00 (Object-Oriented Metrics: Measures of Complexity, Prentice-
(vCase Otras lecturas y fuentes de informacidn en 10s Capitu- Hall, 1996) ofrecen 10s linicos libros dedicados a metricas
10s 20, 21 y 22) que hacen referencia de paso a las metricas 00. Otros libros dedicados a las mCtricas de software con-
0 0 , pero hay pocos que abordan el tema con detalle. Los libros vencional (vCase otras lecturas y fuentes de informacidn en
escritos por Jacobson (Object-Oriented Sofiware Engineering, 10s Capitulos 4 y 19) contienen discusiones limitadas de
Addison-Wesley, 1994) y Graham (Objecto-Oriented Met- mCtricas 00.
hods, Addison-Wesley, segunda edicion, 1993). Proporcionan ' Una amplia variedad de fuentes de informacion para mCtri-
un tratamiento mas extenso que la mayoria. cas orientadas a objetos y temas relacionados se encuentra
Whitmire [WHI97] presenta el tratamiento matematica y disponible en internet. Una lista reciente de referencias a sitios
extensamente mas sofisticado de las mCtricas 00 publicadas (paginas) web relevantes a las mttricas 00 pueden encon-
a la fecha. Lorenz y Kidd [LOR941 y Hendersen-Sellers trarse en http://www. mhhe.pressman5.com
PARTE I
TEMAS AVANZADOS
E N INGENIERIA
DEL SOFTWARE
n esta parte de Ingenieno del Sofhn/ar-e:Un enfoqueprdc~icose han tenido
E en consideracibn varios temas avanzados de la ingenieria del software

que ayudaran a ampliar su entendimiento sobre la ingenieria del soft-
ware. En 10s capitulos siguientes se abarcan las cuestiones siguientes:
~ Q u enotaciones y preliminares rnatem2iticos (~mittodosformaless) se

requieren para especificar formalmente el software?
~Cualesson las actividades tkcnicas clave que se llevan a cabo durante el
proceso de ingenieria del software de la sala limpia?
~Comose utiliza la ingenieria del software basada en componentes para
crear sistemas a partir de componentes reutilizables?
iCu&l es el impacto de la arquitectura cllentelservidor sobre la forma en
que se disefia el software de comercio electrbnico?
iSe pueden aplicar 10sprincipios y conceptos de la ingenieria del software
en productos y aplicaciones basadas en Web?
iCu6les son las actividades tecnicas clave que se requieren para la inge-
nieria del software?
iCuAles son las opciones arquitectonicas para establecer un entorno de
herramientas CASE?
&ual es el futuro de la ingenieria del software?
Una vez que se hayan contestado estas preguntas, se comprenderan 10stemas
K V
que pueden tener un impacto profundo enI la ingenieria del software la proxima
dCcada.
operadores
I .. .......,442
de conjuntos..
..*
iQuQes? Estos m6todos permiten a1 inge- pueden perder vidas o incluso tener lee o escribe datos en un estado. Una
niero del software crear una especiii- graves consecuencias econdmicas. En operacidn s e asocia a dos condicio-
caci6n sin ambigiiedades que sea mas dichas situaciones es esencial descu- nes: una precondici6n y una postcon-
completa y conslante que las que s e brir 10s errores antes de poner en ope- dicion. La notaci6n y l a heuristica
utilizan e n 10s metcdos convenciona- raci6n la computadora. Los metodos asociados con 10s conjuntos y especi-
les u orientados a objetos. La teoria d e formales reducen drasticamente 10s ficaciones constructivas +peradores
conjuntos y las notaciones Itqicas s e errores d e especificacion. y conse- d e conjuntos. operadores lbgicos y
utilizan para crear una sentencia cla- cuentemente son la base del software sucesione- forman la base d e 10s
r a d e hechos (o d e requisitos). Esta que tiene pocos errores una vez que el metodos formales.
especificaci6n matematica entonces se cliente comienza a utilizarlo.
~Cu61es el producto obtenido?
puede para cornprobar que iCu&lesson lm El pimer paso
sea 'Orrecta y esta Cuando s e aplican metodos formales
e n la aplicacibn de los m&todos for- s e produce una especificacidn repre-
especificacion s e crea utilizando nota-
males e s definir el invarianie d e senlada en un lenguaje formal coma z
ciones matem&iicas,inherentemente
dates, el estado o VDM
es menosambiguaque Ios nodes para el Iuncionamiento de un sistema.
males d e presentacion.
El invariante de datos e s una condi- &Cdmopuedo edar saguro de que
iQli611lo hace? Un ingeniero del soft- ci6n que s e verifica mediante la eie- lo he hetho comectamente? Debi-
ware es~ecializadocrea una esFcifi- cuci6n d e una funcidn que contiene un do a que 10s mbtodos formales utilizan
caci6n formal. conjunto de datos. Los datos almace- la matemdtica discreta como meca-
aPor qu&es importante? En sistemas nados forman el estado e n donde una nismo d e especiiicaci6n. para demos-
criticos para la misidn y para la segu- funci6n puede acceder y alterar: y las trarque ma especificaci6n e s correcta,
ridad, un fall0 puede pagarse muy operaciones son las acciones que tie- s e pueden aplicar pruebas lbgicas a
caro. Cuando la computadora lalla se nen Iugar en un sistema a medida que cada funcidn del sistema.
La Encyclopedia of Software Engineering [MAR941 ros del software, hay otros (hay quien diria que la mayo-
define 10s mCtodos formales de la siguiente forma: ria) que no consideran especialmente agradable el pun-
Los metodos formales que se utilizan para desarrollar sis- to de vista matem6tico del desarrollo del software. Para
temas de computadoras son tecnicas de base matematica para entender por quC un enfoque formal tiene un cierto inte-
describir las propiedades del sistema. Estos metodos formales r&, es preciso considerar en primer lugar las deficien-
proporcionan marcos de referencia en el seno de 10s cuales las cias asociadas a 10s enfoques menos formales.
personas pueden especificar, desarrollar y verificar 10s siste-
mas de manera sistematica, en lugar de hacerlo ad hoc.
Se dice que un metodo es formal si posee una base mate- 25.1.1. Deficiencias de 10s enfoques menos
mitica estable, que normalmente vendra dada por un lengua- formales
je formal de especificacidn. Esta base proporciona una forma Los mCtodos descritos para el analisis y diseiio en las
de definir de manera precisa nociones tales como la consis-
tencia y completitud,y, lo que es aun m k relevante,la especi- Partes Tercera y Cuarta de este libro hacen un amplio
ficacion, la implementacidn y la correccion. uso del lenguaje natural y de toda una gama de nota-
ciones graficas. Aun cuando la aplicacion cuidadosa de
10s mCtodos de analisis y diseiio junto con una revision
detallada puede ciertamente llevar a un software de ele-
vada calidad, la torpeza en la aplicacion de estos mCto-
dos puede crear toda una gama de problemas. La
especificacion de un sistema puede contener contradic-
ciones, ambiguedades, vaguedades, sentencias incom-
pletas y niveles mezclados de abstraction.
Las propiedades deseadas de una especificacion for-

mal - c a r e n c i a de ambiguedad, consistencia y com- Aunque un buen indice de documento no puede eliminor
pletitud- son 10s objetivos de todos 10s mCtodos de 10s controdicciones, puede oyudor o descubrirlos.
especificacion. Sin embargo, la utilization de mCtodos Poro 10s especificociones y oms documentos hoy
formales da lugar a una probabilidad mucho mayor de que invertir tiempo en creor un indice cornpleto.
alcanzar estos objetivos ideales. La sintaxis formal de
un lenguaje de especificacibn (Seccion 25.4) hace posi- Las contradicciones son conjuntos de sentencias que
ble interpretar 10s requisitos o el diseiio de una forma difieren entre si. Por ejemplo, una parte de la especifi-
unica, eliminando esa ambiguedad que suele producir- caci6n de un sistema puede afirmar que el sistema debe
se cuando es cualquier lector quien interpreta un len- de monitorizar todas las temperaturas de un reactor qui-
guaje natural (por ejemplo, el espaiiol), o una notation mico mientras que otra parte, que quizas haya escrito
grifica. Las capacidades descriptivas de la teoria de con- otro miembro del personal, puede afirmar que solamente
juntos y de la notation grafica (Section 25.2) hacen sera preciso monitorizar las temperaturas que perte-
posible un enunciado claro de 10s hechos (10s requisi- nezcan a un determinado intemalo. Normalmente, las
tos). Para que 10s hechos sean consistentes puestos de contradicciones que se producen en la misma pagina de
manifiesto en un lugar de una especificacion, no debe- la especificacion del sistema se pueden detectar con faci-
ran verse contradichos a1 establecerse en otro lugar de lidad. Sin embargo, es frecuente que las contradiccio-
la misma. La consistencia se asegura mediante una nes estCn separadas por un elevado n6mero de paginas.
demostracion matematica de que 10s hechos iniciales se Las ambigiiedades son sentencias que se pueden
pueden hacer corresponder formalmente (mediante interpretar de muchas maneras. Por ejemplo, el enun-
reglas de inferencia) con sentencias posteriores exis- ciado siguiente es ambiguo:
tentes dentro de la especificaci6n. El operador de identidad consta del nombre y la contra-
La completitud es dificil de lograr, aun cuando se uti- sefia del operador; la contrasefia consta de seis digitos; debe
licen mCtodos formales. Cuando se esta creando la espe- de ser visualizada en la pantalla de seguridad, y se deposi-
tar&en el archivo de registro cuando el operador se conecte
cificacion se pueden dejar sin definir algunos aspectos con el sistema.
del sistema; quizas otras caracteristicas se omitan a pro-
pdsito para ofrecer a 10s diseiiadores una cierta libertad En este extracto, iLa palabra c<debe>>
alude a la con-
a la hora de seleccionar un enfoque de irnplementacion; traseiia o a la identidad del operador?
ademas es imposible considerar todos 10s escenarios
operacionales en un sistema grande y complejo. Por 61ti-
mo, las cosas pueden omitirse simplemente por error.
Aunque el formalismo proporcionado por las mate-
maticas tiene un cierto atractivo para algunos ingenie-
La vaguedad suele producirse porque la especifica- 25.1.2. Matematicas en el desarrollo del software
ci6n del sistema es un documento muy voluminoso. Las matematicas poseen muchas propiedades utiles para
Alcanzar un elevado nivel de precisi6n de forma con- quienes desarrollan grandes sistemas. Una de las pro-
sistente es una tarea casi imposible. Puede dar lugar a piedades mas utiles es que pueden describir de forma
sentencias tales corno <<lainterfaz con el sistema emplea- sucinta y exacta una situacion fisica, un objeto o el resul-
da por 10s operadores del radar debe ser amistosa para tad0 de una acci6n. La situacion ideal seria que un inge-
con el usuarion, o <<lainterfaz virtual se basari en sim- niero del software estuviera en la misma situaci6n que
ples conceptos globales que sean sencillos de entender un matemitico dedicado a la matemitica aplicada. Se
y utilizar, y, ademis, en escaso numero~.Una revisi6n deberia presentar una especificaci6n matematica de un
poco detallada de estas afirmaciones podria no detectar sistema, y elaborar la soluci6n en base a una arquitec-
la carencia de informaci6n util subyacente. tura de software que implemente la especificaci6n2.
La incomplecci6n1 es posiblemente uno de 10s pro- Otra de las ventajas de la utilizaci6n de las matemC
blemas que se producen mas frecuentemente en las espe- ticas en el proceso del software es que proporcionan una
cificaciones de sistemas. Por ejemplo, considCrese el transici6n suave entre las actividades de ingenieria del
siguiente requisito funcional: software. En matematicas no solo se pueden expresar
El sistema debe de mantener el nivel horario del dep6sito a especificaciones funcionales sino tambiCn disefios de sis-
partir de 10s sensores de profundidad situados en el dep6sito. tema, y, desde luego, el c6digo del programa es una nota-
Estos valores deben de ser almacenados para 10s Gltimos seis
meses.
ci6n matemAtica, aunque ciertamente sea algo verbosa.
La propiedad fundamental de las matematicas es que
Esto describe la parte principal del almacenamiento admite la abstracci6n y es un medio excelente para el
del sistema. Supongamos que una de las 6rdenes del sis- modelado. Dado que es un medio exacto, hay pocas
tema es: probabilidades de ambigiiedad, y las especificaciones
La funci6n de la orden PROMEDIO tiene que visualizar en se pueden verificar matemiticamente para descubrir
un PC el nivel medio de agua para un sensor concreto entre dos
contradicciones e incompletitud;y, por 6ltim0, la vague-
fechas dadas.
dad desaparece completarnente. Ademas, las matemi-
Suponiendo que no se ofreciese mas informaci6n ticas se pueden utiiizar para representar niveles de
acerca de esta orden, 10s detalles de la orden estarian abstracci6n en la especificaci6n de sistema de forma
gravemente incompletos. Por ejemplo, la descripci6n organizada.
de la orden no incluye lo que sucederia si un usuario de Las matematicas constituyen una herramienta ideal
sistema especificase una fecha que distase mas de seis para el modelado. Hacen posible exhibir el esquema
meses de la fecha actual. fundamental de la especificaci6n y ayudan a1 analista y
La mezcla de 10s niveles de abstracci6n se produce especificador del sistema a verificar una especificacibn
cuando sentencias abstractas se entremezclan aleato- para su funcionalidad, sin problemas tales corno el tiem-
riamente con sentencias que se encuentran en un nivel po de respuesta, las directrices de disefio, las directri-
muy inferior. Por ejemplo, sentencias tales corno: ces de implementaci6n y las restricciones del proyecto
El objetivo del sistema es hacer un seguimiento de stock de que siempre estorban. TambiCn ayuda a1 disefiador, por-
un almacCn que la especificaci6n de disefio del sistema muestra las
pueden verse mezcladas con la siguiente: propiedades del modelo, y ofrece tan s610 10s detalles
Cuando el encargado de la carga escribe la orden retirar suficientes para hacer posible llevar a cab0 la tarea que
sera preciso comunicar el numero de pedido, la identidad del tengamos entre manos.
articulo a r e t k y la cantidad retirada. El sistema respondera Por ultimo, las matemiticas proporcionan un eleva-
con una c o n h a c i d n de que la extracci6n es admisible. do nivel de verificaci6n cuando son usadas corno medio
Aun cuando dichas sentencias son importantes en la de desarrollo del software. Cuando es preciso demos-
especificaci6n de un sistema, quienes hacen la especi- trar que un disefio se ajusta a una especificacih y que
ficaci6n suelen arreglLselas para mezclarlas de tal mod0 algunos c6digos de programa son el reflejo exacto de
que resulta muy dificil ver toda la arquitectura funcio- un disefio, es posible utilizar una demostraci6n mate-
nal global del sistema. mitica. Actualmente es la practica preferida porque no
Todos estos problema son mas frecuentes que lo que hay que hacer un gran esfuerzo para la validaci6n ini-
uno desearia creer. Y cada uno de ellos representa una cial, y porque gran parte de la comprobaci6n del siste-
deficiencia potencial en 10s mCtodos convencionales y ma de software tiene lugar durante la prueba de
orientados a objetos de especificaci6n. aceptaci6n y del sistema.
I EZ rnuy extentida la traduccion del tkrrnino incompleteness por Una palabra de precaucion es apropiada en este punto. Las espe-
incompletitud,per0 este terrnino en espaiiol no esta aceptado por la cificaciones rnaternaticas de sisternas que se presentan en este capi-
RAE. (N. del Trad.) tulo no son tan sucintas corno una expresion rnaternatica simple. Los
sisternas de software son notoriarnente cornplejos, y no seria realista
esperar que pudieran especificarse en la rnisrna linea que las rnate-
rnaticas.
DEL SOFTWARE. U N ENFOQUE PRACTICO
INGENIER~A
I
25.1.3. Conceptos de 10s metodos formales
El objetivo de esta seccion es presentar 10s conceptos
fundamentales implicados en la especificacion mate-
matica de sistema de software, sin abrumar a1 lector con
un excesivo nivel de detalle matemitico. Para lograr
esto, se utilizaran unos pocos ejemplos sencillos:
Ejemplo 1. Una tabla de simbolos. Para mantener Maxlds
una tabla de simbolos se utiliza un programa. Esta tabla
se utiliza frecuentemente en muchos tipos distintos de
aplicaciones. Consta de una coleccion de elementos sin
duplicacion. En la Figura 25.1 se muestra un ejemplo
de tabla tipica de simbolos en donde se representa una
tabla que utiliza un sistema operativo para que contie-
ne almacenados 10s nombres de 10s usuarios de un sis-
tema. Otros ejemplos de tablas incluirian por ejemplo FIGURA 25.1. U n a t a b l a d e sirnbolos q u e s e e r n p l e a
la coleccion de nombres del personal en un sistema de p a r a un s i s t e r n a o p e r a t i v o .
nomina, la coleccion de nombres de computadoras en
un sistema de comunicaciones de red y la coleccion de Otro concepto importante es el de estado. En el con-
destinos de un sistema que elabora horarios de trenes. texto de mktodos formales3,un estado es el dato alma-
Suponga que la tabla presentada en este ejemplo no cenado a1 cual accede el sistema y que es alterado por
consta de mas de Maxlds miembros de personal. Esta Cste. En el ejemplo del programa de la tabla de simbo-
afirmacion, que impone una restnccion sobre la tabla, es los, el estado es la tabla de simbolos.
un componente de una condici6n conocida corno inva- El concepto final es el de operacidn. Se trata de una
riante de datos --una idea importante a la cual volve- accion que tiene lugar en un sistema y que lee o escri-
remos en repetidas ocasiones a lo largo del capitulo-. be datos en un estado. Si el programa de tabla de sim-
bolos se ocupa de afiadir y eliminar nombres de personal
de la tabla de simbolos, entonces estari asociado a dos
operaciones: una operacion para ariadir un nombre espe-
cificado en la tabla de simbolos, y otra operacion para
Un invorionte de dotos es un coniunto de condiciones que eliminar un nombre existente de la tabla. Si el progra-
son verdoderas durante lo ejecucion del sisterno que ma proporciona la capacidad de comprobar si existe o
contiene uno coleccion de dotos. no un nombre concreto en la tabla, quiere decir que sera
necesaria una operaci6n que proporcione alguna indi-
Un invariante de datos es una condition verdadera cation de la existencia del nombre en la tabla.
a lo largo de la ejecuci6n del sistema que contiene una
coleccion de datos. El invanante de datos, que es vali-
do para la tabla de simbolos descrita anteriormente,
posee dos componentes: (1) que la tabla no contendri
m b de Maxlds nombres y ( 2 )que no existiran nombres
Lo ccprecondicibn)) define 10s circunstoncios en 10s que uno
duplicados en la tabla. En el caso del programa de tablas
operocibn en porticulor es valido. La ((postcondician))define
de simbolos descrito anteriormente, esto significa que, que ocurre cuando uno operacion ho finolizodo su occi6n.
independientemente del momento en que se examine la
tabla de simbolos durante la ejecuci6n del sistema, siem-
pre contendrh un maximo de Maxlds identificadores de Una operacion esta asociada a dos condiciones: las
personal y no contendra duplicados. precondiciones y las postcondiciones. Una precondi-
cidn define las circunstancias en que una operacion en
particular es vhlida. Por ejemplo, la precondition para
una operacicin que afiada un nombre a la tabla de sim-
bolos de identificadores de personal es valida s610 si el
En 10s mitodos formoles, un ccestodo~es un coniunto nombre que hay que aiiadir no esta almacenado en la
de datos olrnocenados o 10s que el sistemo accede tabla y existen menos de Maxlds identificadores de per-
y modifico. Uno ccaperoci6nr es uno acci6n que lee sonal en la tabla. La postcondicidn de una operacion
o escribe datos en un estodo. define lo que ocurre cuando la operacion ha finalizado
Recuerdese que el terrnino estado se ha utilizado tarnbien en los

Capitulos 12 y 21 corno una representacion del comportarniento de
un sisterna o de objetos.
su acci6n. Esto se define mediante su efecto sobre el Bloaues sin usar
estado. En el ejemplo de la operaci6n que aiiade un iden- Bloques usados
tificador a la tabla de simbolos de identificadores de per-
sonal, la postcondici6n especificaria matemiticamente
que la tabla habri sido incrementada con el identifica-
dor nuevo.
Se liberan
Ejemplo 2. Un gestor de bloques. Una de las par- 10s bloques
tes mis importantes de 10s sistemas operativos es el sub- despues
sistema que mantiene archivos que hayan sido creados un articulo
por usuarios. Una parte del subsistema de archivos es
el gestor de hloques. Los archivos del almacCn de archi-
vos estan formados por bloques de espacio que se alma-
cenan en algun dispositivo de almacenamiento de Archivo n." 1 Archivo n." 2 Archivo n." 3
archivos. Durante el funcionamiento de la computadora,
Cola de bloques que contiene bloques de archivos borrados
10s archivos van siendo creados y borrados, lo cual
requiere la adquisici6n y liberaci6n de bloques de alma- FIGURA 25.2. Un gestor de bloques.
cenamiento. Para abordar este bloque, el subsistema de
archivo mantendri una reserva de bloques libres y En la colecci6n de bloques usados no existirAn nume-
seguira tambikn la pista de aquellos bloques que se estCn ros de bloques duplicados.
utilizando en ese momento. Cuando se liberen bloques
Entre las operaciones asociadas a este subsistema se
procedentes de un archivo borrado lo normal seri aiia-
encuentran las siguientes:
dirlos a una cola de bloques que estin a la espera de ser
aiiadidos a1 dep6sito de bloques que no se utilizan. En Una operaci6n que aiiade una colecci6n de bloques
la Figura 25.2 se muestra un cierto numero de compo- usados a1 final de la cola.
nentes: la reserva de bloques no utilizados, 10s bloques Una operaci6n que elimina una coleccidn de bloques
que en la actualidad forman parte de 10s archivos admi- usados de la parte anterior de la cola y 10s coloca en
nistrados por el sistema operativo y aquellos bloques la colecci6n de bloques sin usar.
que estCn esperando para ser aiiadidos a la reserva de Una operaci6n que comprueba si la cola de bloques
espacio. Los bloques que estan a la espera se mantie- esti o no vacia.
nen en una cola y cada elemento de la cola contiene un La precondici6n de la primera operaci6n es que 10s
conjunto de bloques procedentes de alglin archivo bloques que se vayan a aiiadir deben de encontrarse en la
borrado. coleccion de bloques usados. La postcondici6n es que
la colecci6n de bloques debe de aiiadirse al final de la cola.
La precondici6n de la segunda operaci6n es que la
l o tecnico de Tormento de ideos (Brainstorming) cola debe de tener a1 menos un elemento. La postcon-
puede funcionor bien cuondo se necesito desorrollo~ dici6n es que 10s bloques deben de aiiadirse a la colec-
un invorionte de dotos poro uno funcion ci6n de bloques sin usar.
rozonoblemente complejo. La operaci6n final -cornprobar si la cola de bloques
proporcionados esti o no v a c i e no posee precondi-
ci6n. Esto significa que la operaci6n siempre esti defi-
Para este subsistema, el estado es la colecci6n de blo- nida, independientemente del valor que tenga el estado.
ques libres, la colecci6n de bloques usados y la cola de Si la cola esti vacia, la postcondici6n manda un valor
bloques devueltos. El invariante de datos, expresado en verdadero, y falso si no lo esta.
lenguaje natural, es:
No habra ningun bloque que estC a la vez usado y sin Ejemplo 3. Un concentrador de impresion. En 10s
usar. sistemas operativos multitarea, existe un cierto ndmero
de tareas que hacen solicitudes para imprimir archivos.
Todos 10s conjuntos de bloques almacenados en la
cola serin subconjuntos de la colecci6n de bloques Con frecuencia, no se dispone de un numero suficiente
utilizados en ese momento: de dispositivos de impresidn para satisfacer simultine-
amente todas las solicitudes de impresidn en curso. Toda
No existir5.n elementos de la cola que contengan 10s solicitud de impresidn que no se pueda satisfacer de
mismos ndmeros de bloque. forrna inmediata se ubicari en una cola a la espera de
La colecci6n de bloques usados y bloques sin usar su impresibn. La parte del sistema operativo que abarca
sera la colecci6n total de bloques de que consten 10s la administracidn de estas colas se conoce con el nom-
archivos. bre de concentrador de impresidn.
En la colecci6n de bloques sin usar no existiran En este ejemplo se supone que el sistema operati-
n6meros de bloques duplicados. vo no puede emplear mis de DispMax dispositivos de
salida y que cada uno tiene asociada una cola. Tam- Todo archivo tiene asociado un tamaiio.
.biCn se supondri que cada uno de 10s dispositivos Toda cola asociada a un dispositivo de salida con-
esta asociado a un cierto limite de lineas por archi- tendri archivos que tengan un tamafio menor que el
vo que se pueden imprimir. Por ejemplo, un dispo- limite superior de este dispositivo de salida.
sitivo de salida que tenga un limite de 1.000 lineas No existiran mas de DispMax dispositivos de salida
de impresi6n estara asociado a una cola que conten- que sean administrados por este concentrador.
ga tan solo aquellos archivos que no posean mas de
1.000 lineas de texto. Los concentradores de impre-
si6n suelen imponer esta limitaci6n para evitar las
grandes tareas de impresibn, que podrian ocupar unos
dispositivos de impresi6n lentos durante periodos de 10s estodos y 10s operaciones en muchos ospectos
tiempo sumamente largos. En la Figura 25.3 se mues- son onblogos a lo definicibn de closes en 10s sistemos
tra una representaci6n esquemitica de un concen- orientados a obietos. 10s estados representon el dominio
trador de impresi6n. de 10s dotos (oributos) y 10s operaciones
son 10s procesas (mitodos) que manipulan 10s dotos.
Segun se muestra en la figura, el estado del concen-
trador consta de cuatro componentes: las colas de archi-
vos que esperan para ser impresos, en donde cada cola El concentrador puede tener asociado un cierto nume-
esta asociada a un dispositivo de salida en particular; la ro de operaciones. or
ejemplo:
colecci6n de dispositivos controlados por el concentra- Una operaci6n que afiada un dispositivo de salida
dor; la relaci6n entre dispositivos de salida y el tamafio nuevo a1 concentrador, junto con su limite de impre-
maxim0 de archivo que puede imprimir cada uno de si6n asociado.
ellos, y, por ultimo, la relaci6n entre 10s archivos que Una operaci6n que elimina un archivo de la cola aso-
esperan para ser impresos y su tamafio en lineas. Por ciada a un determinado dispositivo de salida.
ejemplo, en la Figura 25.3 se muestra el dispositivo de
Una operaci6n que afiada un archivo a la cola aso-
salida LP1, que con un limite de impresi6n de 750 lineas,
tiene dos archivos fimp y personas a la espera de impri- ciada a un dispositivo de salida en particular.
mirse, y con un tamaiio de 650 lineas y 700 lineas res- Una operaci6n que altere el limite superior de lineas
pectivamente. de impresi6n para un dispositivo de salida en par-
ticular.
Una operaci6n que traslade un archivo de una cola
Dispositivos de salida Colas
asociada a un dispositivo de salida a otra cola aso-
ciada a un segundo dispositivo de salida.
LP2 data nuevos Cada una de estas operaciones se corresponde con
una funci6n del concentrador. Por ejemplo, la primera
operaci6n se corresponderia con la notificaci6n a1 con-
centrador de un nuevo dispositivo conectado a1 orde-
nador que contiene el sistema operativo que a su vez
Limites Dimensiones administra a1 concentrador.
Tal como sucedia antes, cada operaci6n esti asocia-
da a una precondici6n y a una postcondici6n. Por ejem-
plo, la precondici6n para la primera operaci6n es que el
nombre del dispositivo de salida ya no existe y que exis-
tan en ese momento menos de DispMax dispositivos de
salida a efectos del concentrador. La postcondici6n es
que el nombre del dispositivo nuevo se aiiade a la colec-
FIGURA 25.3. Un c o n c e n t r a d o r d e i m p r e s i o n . ci6n de nombres de dispositivos ya existentes, form&
dose una nueva entrada para el dispositivo sin que esta
El estado del concentrador se representa mediante entrada tenga asociados archivos en su cola, y el dis-
10s cuatro componentes: colas, dispositivos de salida, positivo se asocia a su limite de impresi6n.
limites y dimensiones. El invariante de datos tiene cin- La precondici6n de la segunda operaci6n (la elimina-
co componentes: ci6n de un archivo de una cola asociada a un determina-
do dispositivo de sali&) es que el dispositivo sea conocido
Cada dispositivo de salida esta asociado a un limite para el concentrador y que exista al menos una entrada
superior de lineas de impresi6n. en la cola asociada a1 dispositivo. La postcondici6n es
Todo dispositivo de salida esta asociado a una cola que la cabeza de la cola asociada a1 dispositivo de salida
de archivos esperando impresibn, que posiblemente sea eliminada y se borre su entrada en la parte del con-
no esta vacia. centrador que siga la pista de 10s tamafios de archivos.
C A P ~ T U L 2O5 M ~ T O D O SF O R M A L E S
La precondici6n de la quinta operaci6n descrita ante- El tamaiio del archivo es menor o igual que el limite
. riormente (el traslado de un archivo de una cola aso- de impresi6n asociado a1 segundo dispositivo de salida.
ciada a un dispositivo de salida a la cola asociada a un
segundo dispositivo de salida) es: La postcondici6n es que el archivo sera eliminado
de una cola y afiadido a otra cola.
El primer dispositivo de salida es conocido para el
En cada uno de 10s ejemplos indicados en esta sec-
concentrador. ci6n, se han presentado 10s conceptos clave de la espe-
El segundo dispositivo de salida es conocido para el cificaci6n formal. Se ha hecho esto sin hacer hincapiC
concentrador. en las matematicas necesarias para hacer formal la espe-
La cola asociada a1 primer dispositivo contiene el cificacion. Consideraremos estas matematicas en la sec-
archivo que hay que trasladar. cion siguiente.
Para aplicar de forma eficiente 10s mCtodos formales, Las especificaciones constructivas de conjuntos resul-
el ingeniero del software debe de tener un conocimien- tan preferibles a las especificaciones enumeradas, por-
to razonable de la notaci6n matematica asociada a 10s que hacen posible definir de forma sucinta 10s conjuntos
conjuntos y a las sucesiones, y a la notaci6n logica que formados por muchos miembros. TambiCn se define
se emplea en el calculo de predicados. El objetivo de explicitamente la regla que se utiliza para construir el
esta secci6n es proporcionar una breve introducci6n a1 conjunto.
tema. Para una descripci6n mhs detallada del tema se Considere el siguiente ejemplo de especificacion
recomienda examinar 10s libros especializados en esta constructiva:
materia: por ejemplo, [WIL87], [GRI93] y [ROS95]. {n: N l n < 3 . n } ,
Esta especificaci6nposee tres componentes: una sig-
25.2.1. Conjuntos y especificacion constructiva natura, n : N , un predicado n < 3; y un tkrmino, n. La
Un conjunto es una colecci6n de objetos o elementos que signatura especifica el interval0 de valores que se con-
se utiliza como la piedra angular de 10s mCtodos forma- siderara cuando se forme el conjunto, el predicado (una
les. Los elementos de un conjunto son h i c o s (es decir, expresi6n Booleana) define la forma en que se debe de
no se permiten 10s duplicados). Forman un grupo peque- construir el conjunto y, por ultimo, el te'rmino ofrece la
iio de elementos dentro de llaves, separando mediante forma general del elemento del conjunto. En el ejem-
comas sus elementos. Por ejemplo, el conjunto plo anterior, N denota el conjunto de 10s numeros natu-
{C++,Pascal, Ada, Cobol, Java) rales; por tanto, es precis0 considerar 10s numeros
naturales, el predicado indica que solamente tienen que
contiene 10s nombres de cinco lenguajes de programa- incluir 10s numeros naturales menores que 3, y el tCr-
ci6n. mino especifica que todos 10s elementos del conjunto
El orden en que aparecen 10s elementos dentro de un sera de la forma n. Por tanto, la especificaci6n anterior
conjunto no es relevante. El numero de elementos del define un conjunto:
conjunto se conoce con el nombre de cardinalidad. El
operador # proporciona la cardinalidad de un conjunto. (0, 1721
Por ejemplo, la expresi6n Cuando la forma de 10s elementos del conjunto es
# { A , B, C, 0 )= 4 evidente, se puede omitir el tCrmino. Por ejemplo, el
indica que se ha aplicado el operador de cardinalidad a1 conjunto anterior se podria especificar en la forma:
conjunto mostrado, con un resultado que indica el nume-
ro de elementos que habia en el conjunto.
Los conjuntos que se han descrito anteriormente
iQue es una especificacion poseian todos ellos elementos que tienen objetos indi-
constructiva de coniuntos? viduales. TambiCn se pueden construir conjuntos for-
mados a partir de elementos que Sean pares, ternas, etc.
Por ejemplo, la especificaci6n de conjunto
Hay dos maneras de definir un conjunto. En primer
lugar, se puede definir por enumeraci6n de sus elemen- { x , y : N I x + y = l0.(x,y2) I
tos (esta es la forma en que se han definido 10s conjun- define el conjunto de parejas de numeros naturales con
tos indicados anteriormente). El segundo metodo la forma (x, y ~ y) en 10s cuales la suma de x e y es 10.
consiste en crear una especijicacidn constructiva de con- Se trata del conjunto
juntos. La forma general de 10s ndmeros de un conjun-
to se especifican empleando una expresi6n Booleana. {(1,81), (2,64), (3, 49),...I
Evidentemente, una especificacion constructiva de El operador G es similar a c . Sin embargo, si sus

conjuntos tal como la que se requiere para representar operandos son iguales posee el valor verdadero. Con-
algunos componentes del software de computadoras siguientemente, el valor del predicado
puede ser considerablemente m6s complicada que 10s {HDl,LP4, RC5] c (HDl, RC2, HD3, LP1, LP4, LP6)
indicados anteriormente. Sin embargo, la misma forma
y la estructura basica seguiran siendo las mismas. es falso, y el predicado
{HDl,LP4, RC5J c {HDl,LP4, RC51
25.2.2. Operadores de conjuntos
es verdadero.
Para representar las operaciones conjuntos y las opera- Un conjunto especial es el conjunto vacio 0.En mate-
ciones 16gicas se utiliza el mismo conjunto especiali- maticas normales este operador se corresponde con el
zado de simbolos. El ingeniero del software que pretenda cero. El conjunto vacio tiene la propiedad de que es un
aplicar 10s metodos formales debe de entender estos subconjunto de todos 10s conjuntos restantes. Dos iden-
simbolos. tidades 6tiles relacionadas con el conjunto vacio son
0 u A = A y 0 n A = 0
para todo conjunto A, en donde ues el operador unidn,
Cuondo se desorrollan especificociones formales
tambikn conocido como cctaza>>(dado su forma); y nes
es indispensable el conocimiento del conjunto
el operador interseccidn, conocido tambiCn como
de operaciones. Si se pretende oplicor metodos formoles
lo mejor es dedicor tiempo para fomiliorizom
ccgorra>>.
con 10s conjuntos de operaciones. El operador uni6n admite dos conjuntos y forma uno
con todos 10s elementos del conjunto despues de elimi-
nar 10s duplicados. Asi pues, el resultado de la expresi6n
El operador E se utiliza para indicar la pertenencia ( Archivo 1, Archivo2, Impuesto, Compilador ] u
de un conjunto. Por ejemplo la expresion { NuevoImpuesto, D2, D3, Archivo21
X E X es el conjunto
tiene el valor verdadero six es miembro del conjunto X ( Archivol , Archivo2, Impuesto, Compilador,
y el valor falso en caso contrario. Por ejemplo, el pre- NuevoImpuesto, D2, D3 ]
dicado
El operador de intersecci6n admite dos conjuntos y
12 E (6, 1, 12,221 forma un conjunto que consta de 10s elementos comu-
tiene el valor verdadero por cuanto 12 es un miembro nes a 10s dos anteriores. Por tanto, la expresi6n
del conjunto. {12,4,99, 11 n (1, 13, 12,771
El contrario del operador E es el operador E . La
expresi6n da lugar a un conjunto { 12, 1 J .
xE X
posee el valor verdadero six no es miembro de conjunto
X y falso en caso contrario. Por ejemplo, el predicado
13 6 (13, 1, 124,221
posee el valor falso.
Los operadores c y G tienen conjuntos como ope- El operador diferencia de conjuntos \ como el mis-
randos. El predicado mo nombre indica, forma un conjunto eliminando 10s
elementos del segundo operando de entre 10s elemen-
AcB tos del primer operando. Consiguientemente el valor de
la expresi6n
tiene el valor verdadero si 10s miembros del conjunto
A estan dentro del conjunto B, y tiene el valor falso en {Nuevo, Viejo, ArchivoImpuesto,
caso contrario. De esta forma el predicado ParamSistema]\{ Viejo, ParamSistema ]
{ l , 2 1 c 1493, 1,21 da lugar a1 conjunto { Nuevo, ArchivoImpuesto J .
El valor de la expresi6n
posee el valor verdadero. Sin embargo, el predicado
{a,b, c, d l n {x,Y I
{HDl,LP4, RC5] c (HDI,RC2, HD3, LPl, LP4, LP6)
sera el conjunto vacio 0. El operador siempre propor-
posee el valor falso porque el elemento RC5 no esth ciona un conjunto; sin embargo, en este caso no exis-
dentro del conjunto que se encuentra a la derecha del ten elementos comunes entre sus operandos, de manera
operador. que el conjunto resultante carecerh de elementos.
C A P ~ T U L O25 M~TODOS
FORMALES
El operador final es el producto cruzado x, conoci- 25.2.4. Sucesiones

do algunas veces tambiCn como producto cartesiano, Una sucesi6n es una estructura matemhtica que mode-
el cual posee dos operandos que son conjuntos de pare- la el hecho consistente en que sus elementos e s t h orde-
jas. El resultado es un conjunto de parejas en donde cada nados. Una sucesion s es un conjunto de parejas cuyos
una se compone de un elemento tomado del primer ope- elementos oscilan entre 1 y el elemento de mayor nume-
rando, combinado a su vez con un elemento del segun- ro. Por ejemplo,
do operando. La siguiente expresi6n es un ejemplo del
producto cruzado ((1, Jones), (2, Wilson), (3, Shapiro), (4, EstCvez)]
es una sucesi6n. Los objetos que forman 10s primeros
elementos de las parejas se conocen como dominio de
El resultado de esta expresion es una sucesibn, y la coleccidn de segundos elementos
como interval0 de la sucesi6n. En este libro, las
secuencias se indicarAn empleando corchetes angula-
res. Por ejemplo, la sucesi6n anterior se escribiria
Hay que tener en cuenta que todos 10s elementos del entonces como
primer operando se combinan con todos 10s elementos
del segundo. (Jones, Wilson, Shapiro, EstCvez)
Un concept0 importante en 10s mCtodos formales es A diferencia de 10s conjuntos, en una sucesi6n se per-
el operador conjunto potencia. Se trata de la colecci6n mite la duplicidad, aunque su orden es muy importan-
de subconjuntos de ese conjunto. El simbolo que se uti- te. Por tanto
liza para este operador de conjunto en este capitulo es
!? . Este es un operador unario que cuando se aplica a (Jones, Wilson, Shapiro) # (Jones, Shapiro, Wilson )
un conjunto devuelve el conjunto de subconjuntos del Una sucesi6n vacia se representa mediante la for-
operando. Por ejemplo, ma ( >.
En las especificaciones formales se utiliza un cierto
numero de operadores de sucesi6n. La concatenaci61-1,
A , es un operador binario que forma una sucesi6n que
ya que todos 10s conjuntos son subconjuntos de { 1,2,31. se construye afiadiendo el segundo operando a1 final de
su primer operando. Por ejemplo,
25.2.3. Operadores 16gicos

Otro componente importante de 10s mCtodos formada como resultado la sucesi6n (2, 3, 34, 1, 12, 33, 34,
les es la 16gica: el Algebra de las expresiones verda- 200).
deras y falsas. Cualquier ingeniero del software Otros operadores que pueden aplicarse a las suce-
entendera el significado de 10s operadores 16gicos siones son cabeza, cola, frente y liltimo. El operador
comunes. Sin embargo, 10s operadores 16gicos que cabeza extrae el primer elemento de una sucesi6n; el
estAn asociados a 10s lenguajes de programaci6n operador cola proporciona 10s 6ltimos n- 1 elemen-
comunes se escriben utilizando 10s simbolos disponi- tos finales de una sucesi6n de longitud n; por ultimo
bles en el teclado. Los operadores matemhticos equi- el operador liltimo extrae el elemento final de una
valentes son 10s siguientes: sucesi6n; y el operador frente proporciona 10s 61ti-
mos n- 1 elementos en una sucesi6n de longitud n. Por
ejemplo,
implica
La cuantificaci6n universal es una manera de con-

feccionar una afirmaci6n acerca de 10s elementos del Dado que una sucesi6n es un conjunto de parejas, se
conjunto que resulta ser verdadera para todos 10s miem- pueden aplicar todos 10s operadores de conjuntos des-
bros de ese conjunto. La cuantificaci6n universal utili- critos en la Secci6n 25.2.2. Cuando en un estado se uti-
za el simbolo V . Veamos un ejemplo de la utilizaci6n liza una sucesi61-1,se deberia designar utilizando la
de este simbolo palabra clave seq. Por ejemplo,
V i J : N.i>j*iz>j ListaArchivos: seq ARCHIVOS
NinglinUsuario: N
en donde se lee que toda pareja de valores del conjunto
de 10s numeros naturales, si i es mayor que j, entonces describen un estado con dos componentes: una suce-
i2 es mayor que j. si6n de archivos y un numero natural.
I
INGENIERIA DEL SOFTWARE. UN ENFOOUE PRACTICO
Para ilustrar la utilization de la notacidn matematica en

la especificaci6n formal de un componente de softwa-
re, estudiaremos de nuevo el ejemplo del Gestor de Blo-
ques de la Secci6n 25.1.3. Para recapitular, veremos que
se utiliza un componente importante del sistema ope- Para encontrar mas inforrnacion sobre rnitodos forrnales visite la p6gina
rativo de una computadora que mantiene archivos cre- archive.comlab.ox.ac.uk/formal-methods.htm1
ados por usuarios. El gestor de bloques mantiene una Los componentes matemAticos del invariante de datos
reserva de bloques sin utilizar y tambitn sigue la pista se corresponden con 10s cuatro componentes del len-
de aquellos bloques que se esttn utilizando en ese guaje natural marcados que se han descrito anterior-
momento. Cuando 10s bloques proceden de un archivo mente. En la primera linea del invariante de datos se
borrado, lo normal es afiadirlos a una cola de bloques establece que no habra bloques comunes en la colec-
en espera a ser afiadidos a la reserva de bloques no uti- ci6n de bloques usados y en la colecci6n de bloques
lizados. En la Figura 25.24 se muestra un esquema en libres. En la segunda linea se establece que la colecci6n
donde se representa este funcionamiento. de bloques usados y de bloques libres sera siempre igual
a la colecci6n completa de bloques del sistema. La ter-
iC6m0 se pueden representar
cera linea indica que el elemento i-ksimo de la cola de
10s estados y 10s invariantes
bloques sera siempre un subconjunto de 10s bloques usa-
de datos utilizando 10s operadores
dos. La dltima linea afirma que si dos elementos de la
logicos y de conjuntos presentados
cola de bloques no son iguales, entonces no existiran
anteriormente?
componentes comunes en estos dos elementos. Los dos
tiltimos componentes en lenguaje natural del invarian-
Existe un supuesto conjunto BLOQUES, que se com- te de datos se implementan como consecuencia del
pone de un conjunto formado por todos 10s ndmeros de hecho consistente en que usados y libres son conjuntos,
bloque, y un conjunto TodosLosBloques, que es un con- y por tanto no contendran duplicados.
junto de bloques entre 1 y BloquesMax. Su estado se La primera operaci6n que se va a definir es la que
modelara mediante dos conjuntos y una sucesi6n. Los elimina un elemento de la parte anterior de la cola de
dos conjuntos son usados y lihres. Ambos contienen bloques. La precondici6n es que debe de existir a1 menos
bloques, es decir, el conjunto usados contiene 10s que un elemento en la cola:
se e s t h utilizando actualmente en 10s archivos, y el con-
junto libres contiene 10s que esthn disponibles para 10s
archivos nuevos. La sucesi6n contendra 10s conjuntos La postcondici6n es que es preciso eliminar la cabe-
de bloques listos para ser liberados procedentes de archi- za de la cola y es preciso ubicarla en la colecci6n de
vos que se han borrado. bloques libres, y es preciso ajustar la cola para mostrar
El estado se puede describir de la siguiente forma esa eliminaci6n:
usados, lihres: P BLOQUES usados' = usados \ cabeza ColaBloques A
ColaBloques: seq P BLOQUES lihres' = libres u cabeza ColaBloques A
Esta descripci6n de estado se asemeja a la declara- ColaBloques' = cola ColaBloques
ci6n de variables de un programa. Afirma que usados y Una convenci6n que sc utiliza en muchos mCto-
libres seran 10s conjuntos de bloques y que ColaBlo- dos formales es que el valor de una variable desputs
ques sera una sucesion, cada uno de cuyos elementos de una cierta operaci6n lleva el signo prima. Por tan-
sera un conjunto de bloques. El invariante de datos se to, el primer componente de la expresi6n anterior afir-
escribira de la siguiente manera ma que el nuevo conjunto de bloques usados
(usados')sera igual a1 conjunto bloques usados ante-
usados n lihres = 0 A rior menos 10s bloques que hayan sido eliminados.
usados u libres = TodosBloques A El segundo componente afirma que el nuevo conjunto
V i: dom ColaBloques . ColaBloques i c usados A de bloques libres (libres') sera el conjunto viejo de
V i,,j:dom ColaBloques . i # j + ColaBloques i n bloques libres desputs de afiadir la cabeza de la cola
ColaBloques j = 0 de bloques. El tercer componente afirma que la cola
si no recuerda lo que ocurrio en la coleccion del gestor de bloques

consulte la Seccion 25.1.3 para revisar el invariante de datos, las pre-
condiciones de las operaciones y las postcondiciones asociadas a1
gestor.
C A P ~ T U L O25 MPTODOS FORMALES
nueva de bloques sera igual a la cola del viejo valor La postcondici6n es que el conjunto de bloques se
. de la cola de bloques, es decir, a todos 10s elementos aiiade a1 final de la cola de bloques y el conjunto de blo-
de la cola salvo el primero. Una segunda operaci6n ques libres y usados permanece invariable:
es la que se encarga de afiadir una cola de bloques ColaBloques' = ColaBloques A ( AB1ocks)A
BloquesA a la cola de bloques. La precondicih es usados' = usados A
que BloquesA sea en ese momento un conjunto de libres' = libres
bloques usados:
No cabe duda de que la especificacibn matemhtica
BloquesA c usados de la cola de bloques es considerablemente mhs rigu-
rosa que una narraci6n en lenguaje natural o un mode-
~ C O se~ pueden
O representar lo grhfico. Este rigor adicional requiere un cierto
las precondiciones y las esfuerzo, per0 10s beneficios ganados a partir de una
postcondiciones? mejora de la consistencia y de la completitud puedan
justificarse para muchos tipos de aplicaciones.
Un lenguaje de especificaci6n formal suele estar com- posible especificar el comportamiento del sistema. Por
puesto de tres componentes primarios: (1) una sinta- ejemplo, se puede desarrollar una sintaxis y una semhn-
xis que define la notacidn especifica con la cual se tica para especificar 10s estados y las transiciones entre
representa la especificaci6n; (2) una semhntica que estados, 10s sucesos y sus efectos en las transiciones de
ayuda a definir un a.miverso de objetosn [WIN901 que estados, o la sincronizacih y la temporizaci6n.
se utilizarh para describir el sistema; y (3) un conjun- Es posible utilizar distintas abstracciones semhnti-
to de relaciones que definen las reglas que indican cuh- cas para describir un mismo sistema de diferentes
les son 10s objetos que satisfacen correctamente la maneras. Eso se ha hecho de manera formal en 10s
especificaci6n. Capitulos 12 y 21. El flujo de datos y el procesamien-
El dominio sintcictico de un lenguaje de especifica- to correspondiente se describia utilizando el diagrama
ci6n formal suele estar basado en una sintaxis derivada de flujo de datos, y se representaba el comportamien-
de una notaci6n estindar de la teoria de conjuntos y del to del sistema mediante un diagrama de transici6n entre
chlculo de predicados. Por ejemplo, las variables tales estados. Se empleaba una notaci6n anhloga para des-
como x, y, y z describen un conjunto de objetos que estin cribir 10s sistemas orientados a objetos. Es posible uti-
relacionados a un problema (algunas a veces se deno- lizar una notaci6n de modelado diferente para
minan el dominio del discurso) y se utilizan junto con representar el mismo sistema. La semhntica de cada
10s operadores descritos en la Secci6n 25.2. Aunque la representacibn proporciona una visi6n complementa-
sintaxis suele ser simbblica, tambiCn se pueden utilizar ria del sistema. Para ilustrar este enfoque cuando se
iconos (simbolos grhficos como cuadros, flechas y cir- utilicen 10s mCtodos formales, sup6ngase que se utili-
culos) si no son ambiguos. za un lenguaje de especificaci6n formal para describir
El donzinio senzantico de un lenguaje de especifica- el conjunto de sucesos que dan lugar a que se produz-
ci6n indica la forma en que ese lenguaje representa 10s ca un cierto estado dentro de un sistema. Otra relaci6n
requisitos del sistema. Por ejemplo, un lenguaje de pro- formal representa todas aquellas funciones que se pro-
gramacidn posee un conjunto de semhnticas formales ducen dentro de un cierto estado. La intersecci6n de
que hace posible que el desarrollador de software espe- estas dos relaciones proporciona una indicacih de 10s
cifique algoritmos que transforman una entrada en una sucesos que darhn lugar que se produzcan funciones
salida. Una gramhtica formal (tal como BNF) se puede especificas.
utilizar para describir la sintaxis del lenguaje de pro- En la actualidad se utiliza toda una garna de lengua-
gramacibn. Sin embargo, un lenguaje de programaci6n jes formales de especificacibn: CSP [HIN95, HOR851,
no es un buen lenguaje de especificacih, porque sola- LARCH [GUT93], VDM [JON911 y Z [SPI88, SPI921
mente puede representar funciones computables. Un son lenguajes formales de especificacih representati-
lenguaje de especificacidn deberh poseer un dominio vos que muestran las caracteristicas indicadas anterior-
semhntico mhs amplio; esto es, el dominio semhntico mente. En este capitulo, se utiliza el lenguaje de
de un lenguaje de especificaci6n debe de ser capaz de especificacih Z a efectos de ilustracih. Z esth acom-
expresar ideas tales como <<Paratodo x de un conjunto pailado de una herramienta automatizada que almace-
infinito A, existe un y de un conjunto infinito B tal que na axiomas, reglas de inferencia y teoremas orientados
la propiedad P es vdida para x e yn [WIN90]. Otros len- a la aplicaci6n que dan lugar a pruebas de correcci6n
guajes de especificacih aplican una semintica que hace matem6ticas de la especificacidn.
Las especificaciones en Z se estructuran como un con- En esta seccibn, se utiliza el lenguaje de especifica-
junto de esquemas - s o n estructuras parecidas a cuadros ci6n Z para modelar el ejemplo del gestor de bloques
que presentan variables y que especifican larelaci6n exis- que se presentaba en la Secci6n 25.1.3 y se trataba pos-
tente entre las variables-. Un esquema es, en esencia, teriormente en la Secci6n 25.3. En la Tabla 25.1 se pre-
una especificacidn formal aniloga a la subrutina o el pro- senta un resumen de la notaci6n del lenguaje Z. El
cedimiento de un lenguaje de programaci6n. Del mismo siguiente ejemplo de esquema describe el estado del
mod0 que 10s procedimientos y las subrutinas se utilizan gestor de bloques y del invariante de datos:
para estructurar un sistema, 10s esquemas se utilizan para
estructurar una especificaci6n formal.
La notacion Z esta basada en la teoria de conjuntos con tipos y en la Iogica de primer orden. Z proporcio-
na una estructura denominada esquema, para describir el estado y las operaciones de una especificacion.
Los esquemas agrupan las declaraciones de variables con una lista de predicados que limitan 10s posibles
valores de las variables. En Z el esquema X se define en la forma
declaraciones
predicados
Las funciones constantes globales se definen en la forma

declaraciones
predecibles
La declaracion proporciona el tip0 de la funcion o constante, mientras que el predicado proporciona su
valor. En esta tabla solamente se presenta un conjunto abreviado de simbolos de Z.
Conjuntos:
s:N X S se declara como un conjunto de X.
X€ S x es miembro de S.
Xiz S x no es miembro de S
SG T S es un subconjunto de T: Todo miembro de S esta tambien en T.
SU T La union de S y T: Contiene todos 10s miembros de S o T o ambos.
S nT La insercion de S y T: Contiene todos 10s miembros tanto de S como de T.
S\ T La diferencia de S y T: Contiene todos 10s miembros de Ssalvo 10s que estan tambien en T.
0 Conjunto vacio: No contiene miembros.
{XI Conjunto unitario: Solamente contiene a x.
N El conjunto de 10s numeros naturales 0, 1,2 ....
S: F X Se declara S como un conjunto finito de X.
max (S) El maximo del conjunto no vacio de numeros S.
Funciones:
f:X* Y Se declara como una inyeccion parcial de X e Y.
dom f El dominio de f Dicese del conjunto de valores de x para 10s cuales esta definido Ax).
ran f El rango de f El conjunto de valores que toma Ax) cuando x recorre el dominio de f.
f O ( x - y) Una funcion que coincide con f salvo que x se hace corresponder con y.
(XI5l f Una funcion igual que f, salvo que x s e ha eliminado de su dominio.
Logica:
PAQ P y Q: Es verdadero si tanto P como Q son verdaderos.
P a Q P implica Q: Es verdadero tanto si Q es verdadero como si P es falso.
0s' = 0 s Ningun componente del esquema S cambia en una operacion.
TABLA 25.1. Resumen de la notacion Z.

446
CAPfTULO 25 M ~ T O D O FORMALES
S
-, Gestionar Bloques Eliminar Bloques
I usados, libres: P BLOQUES

ColaBloques: seq P BLOQUES
usados n libres = 0 A
AGestorBloques
#ColaBloques > 0,
usados' = usados \ cabeza ColaBloques A
usados n libres = TodosBloques libres' = libres u cabeza ColaBloques A
V i: dom ColaBloques ColaBloques i c usados A ColaBloques' = cola ColaBloques
'd i, j: dom ColaBloques . i # j *
ColaBloques i n ColaBloques j = 0 La inclusi6n de AGestorBloques da como resultado
todas las variables que componen el estado disponible
en el esquema EliminarBloques, y asegura que el inva-
riante de datos se mantendri antes y despuCs de que se
2
Referencia Web
Informocibn detollada sobre el lenguoie Z en donde
se incluye FAQ se puede encontrar en
ejecute la operaci6n.
La segunda operacibn, que aiiade una colecci6n de
bloques a1 final de la cola, se representa de la manera
siguiente:
archive.comlab. ox.ac.uk/z.html
Afiadir Bloques
AGestorBloques
El esquema se compone de dos partes. La primera
BloquesA? : BLOQUES
esti por encima de la linea central representando las
variables del estado, mientras que la que se encuentra BloquesA? G usados
por debajo de la linea central describe un invariante de ColaBloques' = ColaBloques (BloquesA?)
10s datos. Cuando el esquema que representa el inva-
riante y el estado se utiliza en otro esquema, va prece- usados' = usados A
dido por el simbolo A. Por tanto, si se utiliza el esquema libres' = libres
anterior en uno que describa, por ejemplo, una opera-
ci6n, se representm'a mediante AGestorBloques. Como Por convenci6n en Z, toda variable que se lea y que
la afirmacidn anterior establece, 10s esquemas se pue- no forme parte del estado iri terminada mediante un sig-
den utilizar para describir operaciones. El ejemplo no de interrogaci6n. Consiguientemente, BloquesA?,
siguiente describe la operaci6n que elimina un elemen- que actua como parhetro de entrada, acaba con un sig-
to de una cola de bloques: no de interrogaci6n.
El inter& creciente en la tecnologia de objetos ha

supuesto que 10s que trabajan en el irea de 10s mCto-
dos formales hayan comenzado a definir notaciones
matemiticas que reflejan las construcciones asocia-
das a la orientacidn a objetos, llamadas clases, heren- cola: seqT
cia e instanciaci6n. Se han propuesto diferentes #cola InumObjetosMax
variantes de las notaciones existentes, principalmen-
te las que se basan en Z -y el propdsito de esta sec-
1 INIT
cola = O
ci6n es examinar Object Z que desarrollaron en el
Centro de Verificacidn de Software de la Universidad
de Queensland-.
I ~MnumObjetosMan)
Aiiadir -
Object Z es muy similar a Z en detalle. Sin embar-

go, difiere en lo que se refiere a la estructuracidn de 10s
II 1Ielemento? : T
#cola < numObietosMax
cola' = cola < eiemento? >
esquemas y a la inclusidn de las funciones de herencia
e instanciaci6n. Extraer -
A continuacidn se muestra un ejemplo de especifi- elemento! : T
cacidn en Object Z. Aqui se representa la especificacidn cola # < >
de una clase que describe una cola genCrica que puede elemento! = cabeza cola
tener objetos de cualquier tipo. / I cola' = cola cola
lNGENlERfA DEL SOFTWARE. UN ENFOQUE PRACTICO
Se ha definido una clase que tiene una variable de

instancia cola, es decir, una secuencia que tiene obje-
tos del tip0 T , donde T puede ser de cualquier tipo; alta, baja :ColaProc
por ejemplo, puede ser un entero, una factura, un gru- alta + baja
po de elementos de configuraci6n o bloques de
memoria. Debajo de la definici6n de cola se leen unos
esquemas que definen la clase. La primera define una
constante que tendri un valor no mayor de 100. El
siguiente especifica la longitud mixima de la cola y
10s dos esquemas siguientes Ariadir y Extraer defi- Total Procesos -
nen 10s procesos de aiiadir y extraer un elemento de
la cola.
La precondici6n de Afiadir especifica que cuando se
aiiade a la cola un objeto elemento? no debe tener una
longitud mayor a la permitida; y la postcondici6n espe-
cifica lo que ocurre cuando se ha finalizado la adici6n La primera linea define el esquema. La segunda y
de elementos. La precondici6n de la operaci6n Extraer tercera definen el estado y el invariante del estado. En
especifica que para que esta operaci6n se haga con Cxi- este caso el estado se compone de dos colas de proce-
to la cola no debe estar vacia, y la postcondici6n debe so bien diferenciadas: alta y baja.
definir la extracci6n de la cabeza de la cola y su colo- A la definici6n del estado le sigue la definici6n de
caci6n en la variable elemento! cuatro operaciones. INIT se define como la aplicaci6n
Esto es, por tanto, la especificaci6n bisica de la cla- de la operaci6n heredada INIT en las colas alta y baja;
se de un objeto en Object Z. Si quisiCramos utilizar un afiadirAlta se define como la aplicaci6n de la opera-
objeto definido por dicha clase, seria relativamente sim- ci6n heredada afiadir en el componente del estado alta;
ple de hacer. Por ejemplo, supongamos que se esth defi- afiadirBaja se define como la aplicaci6n de la opera-
niendo parte de un sistema operativo que manipulaba ci6n heredada afiadir sobre el componente de estado
procesos que representan 10s programas en ejecuci6n y baja; y, finalmente, la operaci6n totalProcesos se defi-
que tomamos la decisi6n de que 10s procesos tenian que ne como la suma de tamafios de las colas individuales
estar en dos colas, una con 10s procesos de alta priori- alta y baja.
dad y la otra con aquellos de baja prioridad, y donde la Consecuentemente, esto es un ejemplo de instancia-
prioridad la utilice el planificador del sistema operati- ci6n en accibn, donde 10s objetos definidos por un esque-
vo con el prop6sito de decidir cual es el siguiente pro- ma Object Z se utilizan en otro esquema. Con esto se
ceso a ejecutar. La primera sentencia de Object Z puede definir la herencia.
necesaria instanciari la clase de cola general en una que Para poder llevar a cab0 la definici6n de herencia,
contenga procesos. examinemos otro ejemplo, el de una tabla de simbolos.
ColaProc == Cola[PROCESOS] Estas tablas se utilizan constantemente en aplicaciones
[procQ 1 cola, proc? 1 elemento? proc! 1 elemento!] que contienen 10s nombres de empleados en sistemas
de personal, nombres de impresoras en sistemas opera-
Se puede decir que todo lo que hace es reemplazar tivos, nombres de carreteras en sistemas de navegaci6n
el tipo T por PROCESOS en la definici6n de la clase, la para vehiculos, y otros. Para describir la herencia, pri-
cola general cola por la cola de 10s procesos procQ y mero definiremos una tabla genCrica de simbolos, a con-
10s parimetros generales de entrada y salida elemento? tinuaci6n la utilizaremos y mostraremos c6mo se puede
y elemento!, por aquellos parimetros de procesoproc?, heredar del esquema Z que la define. En primer lugar
y proc!. El simbolo / representa una forma de sustitu- se deben describir informalmente las operaciones y el
ci6n de texto. estado necesarios.
El siguiente paso, como se muestra a continuaci6n, El estado estari compuesto de un conjunto del tipo
es definir una clase que describe las dos colas. Esta cla- T. Suponemos que no habri mis de 100 objetos y defi-
se utiliza las operaciones definidas en la clase Cola. niremos una sene de operaciones que actuarhn sobre el
Supongamos que las siguientes operaciones son nece- estado:
sarias:
afiadirAlta, aiiade un proceso a la cola de 10s proce- INIT que inicializa la tabla de simbolos para que estC
sos de alta prioridad. vacia.
afiadirBaja, aiiade un proceso a la cola de 10s pro- ariadir que afiade un objeto a la tabla de simbolos.
cesos de baja prioridad. extraer que extrae un objeto de la tabla de simbolos.
INIT inicializa las colas de alta y baja prioridad. nimero que retorna con el n6mero de objetos de la
totalProcesos devuelve el n6mero total de procesos tabla de simbolos. A continuaci6n se muestra esta
que esthn en las colas. definici6n.
C A P ~ T U L 25
O METODOS F O R M A L E S
Ahora supongamos que se necesita utilizar la heren-

cia. Para mostrar este caso, supongamos una operaci6n
encontrar que devuelve un valor encontrado si se encuen-
I MaxElem I 100 tra un objeto en la tabla de simbolos, y un valor no encon-
tabla : T trado si no esth en la tabla. Vamos a suponer tambiCn una
#tabla I: MaxElem aplicaci6n en la que cuando se ejecuta la operaci6n encon-
trar se suele utilizar el mismo objeto que esth en la tabla.
Aseguraremos que, cuando se aplica antes esta opera-
c i h , antes de empezar se comprobarh que Cste es el obje-
Aiiadir - to, lo que podria suponer una b6squeda prolongada en la
C A(tab1a)
objeto? : T
#tabla < MaxElem
[ tabla' = tabla u { objeto? }
Extraer -
tabla. Antes de definir este esquema se debe de utilizar
el esquema original de tabla de simbolos para incluir esta
informaci6n. En primer lugar necesitamos un miembro
diferenciado de la tabla que se conoce como FrecElem.
Este es el elemento que se utiliza con mhs frecuencia. La
definition de la tabla nueva es:
objeto? : T
obieto?~tabla TablaSimbolos[T]
I
tabla' = tabla \ l obieto? 1 FrecElem : T
7 nhmero - Encontrar
A( FrecElem)
aSerEncontrado? : T
estado! : {encontrado,noencontrado)
aSerEncontrado? = FrecElem v aSerEncontrado?
E tabla-
-
Estas son operaciones muy simples que conllevan estado! = encontrado A FrecElem ' = aSerEncon-
operaciones esthndar de conjuntos como u, y que trado?
siguen el formato mostrado en el ejemplo de colas. La aSerEncontrado? # FrecElem A aSerEncontrado?
operaci6n afiadir se definirh solo si la tabla tiene espa- E tabla
cio para el objeto que se va a aiiadir, y la operation
estado! = noEncontrado
extraer solo se define si el objeto que se va a extraer
esth dentro de la tabla de simbolos. La operaci6n nhme- Aqui todas las operaciones definidas para Tabla-
ro no afecta a1 estado, y de aqui que incluya el ele- Simbolos se heredan sin cambios como esth la variable
mento E(tab1a). de instancia tabla. La nueva operacidn encontrar utili-
Si queremos instanciar la tabla como una tabla de za una variable FrecElem que forma parte del nuevo
nombres de empleados del tipo EMPLEADO, se requie- esquema TablaDifde Object Z.
re todo lo siguiente: Esta operaci6n comprueba si el parhmetro de entrada
TabEmpleado == TablaSimholos[EMPLEADO] de encontrar es el mismo que el elemento frecuente que
[empltabla,emp?lobjeto?,emp!lobjeto! ] se esti recuperando varias veces o est6 dentro de la tabla.
donde la tabla se convierte en una tabla con objetos Si es asi, entonces el estado correct0 encontrado se devuel-
EMPLEADO y donde 10s parhmetros de entrada defi- ve y el elemento frecuente se actualiza. Si el elemento no
nidos de forma genCrica han sido sustituidos por pari- es el elemento frecuente y no esth dentro de la tabla enton-
metros especificos emp? y emp! ces se devuelve el estado noEncontrado.
A continuacidn se muestra el esquema Object Z que Este esquema se puede utilizar entonces dentro de
describe la nueva tabla de empleados mediante la ins- una aplicaci6n de empleados especificando:
tanciaci6n; simplemente involucra la redefinici6n de 10s TabEmpleadoFrec == TablaDiflEMPLEADO]
operadores que se acaban de definir. [empsltabla,emp?lobjeto?,emp! ,Empfi-eclObjetofrec]
e :TabEmpleados
A AadirEmp 4 e.aiiadir e :TabEmpleadoFrec
AfiadirEmpFrec P ~.A~?ADIR
ExtraerEmp P e.extraer
ExtraerEmpFrec B e.EXTRAER
InitEmp P e.INIT . InitEmpFrec P e.INIT
NLimeroEmp P e.nhmero NhmeroEmpFrec P e.NUMER0
Esto es una introducci6n corta para mostrar la mane- ci6n anterior, para implementar las funciones para la ins-
ra de empezar a utilizar las notaciones formales para la tanciaci6n y la herencia. El trabajo en esta 6rea esti toda-
especificaci6n de sistemas orientados a objetos. La mayor via a nivel de investigacibn con pocas aplicaciones. Sin
parte del trabajo que se ha llevado a cab0 dentro de esta embargo, durante el penodo de vida de esta edici6n las
6rea ha empleado la noci6n Z y se ha intentado construir notaciones formales orientadas a objeto deberian expe-
basado en las ideas de estado, precondicibn, postcondi- rimentar el mismo nivel de penetraci6n industrial que
ci6n e invariante de datos, que se ha descrito en la sec- notaciones estindar tales como las notaciones Z.
Una de las caracteristicas principales de las dos tCcni- Nombre: colaparcia1

cas de especificaci6n descritas anteriormente, Z y Z++, Clases: cola(Z)
es el hecho de que estin basadas en la nocion de esta- Operadores:
do: una colecci6n de datos que se ven afectados por ope- colavacia: + cola(Z)
raciones definidas por expresiones escritas en el cilculo aiiadirElemento: Z x cola(Z) + cola(Z)
del predicado. extraerElemento: Z x cola(Z) + cola(Z)
Una tCcnica alternativa se conoce como especifica- primera: cola(Z) + Z
cion algebraica. Y consiste en escribir sentencias mate- 6ltima: cola(Z) + Z
miticas que narran el efecto de las operaciones estivacia?: cola(Z) + Booleana
admisibles en algunos datos. Esta tCcnica tiene la ven-
taja principal de apoyar el razonamiento de manera La primera linea es la que da el nombre a1 tip0 de
mucho mas ficil que 10s mCtodos basados en el estado. cola. La segunda linea afirma que la cola manejar6 cual-
El primer paso a1 escribir una especificacibn alge- quier tipo de entrada Z; por ejemplo, Z podna ser men-
braica es determinar las operaciones necesarias. Por sajes, procesos, empleados esperando entrar a un edificio
ejemplo, podria darse el caso de que un subsistema que o aeronaves esperando para aterrizar en un sistema de
implemente una cola de mensajes en un sistema de control del trifico aCreo.
comunicaci6n necesite operaciones que extraigan un El resto de la especificacibn describe las signaturas
objeto del comienzo de la cola, que devuelvan el n6me- de las operaciones: cuiles son 10s nombres y el tip0 de
ro de objetos de una cola y que comprueben si la cola elemento que procesan. La definici6n de colaVacia afir-
esti vacia. ma que no toma argumentos, y que da una cola que esti
Una vez que se han desarrollado estas operaciones, vacia; la definici6n de aiiadirElemento afirma que toma
se puede especificar la relaci6n que existe entre ellas. un objeto del tip0 Z y una cola con 10s objetos del tip0
Por ejemplo, el especificador podria describir el hecho Z y entonces da una cola de objetos del tip0 Z, y asi
de que cuando se aiiade un elemento a la cola el n6me- sucesivamente.
ro de elemento de esa cola aumenta en un elemento. Esto es solo la mitad de la especificaci6n - e l resto
Para mostrar una impresi6n del aspect0 de una especi- describe la semintica de cada operacion en funci6n de la
ficaci6n algebraica reproduciremos dos especificacio- relaci6n con otras operaciones-. A continuackh, se
nes. La primera es para una cola, y la segunda para una muestran algunos ejemplos de este tipo de especificaci6n.
tabla de simbolos. Asumimos que las operaciones La primera afirma que estaVacia? sera verdadera para
siguientes son necesarias para la cola: una cola vacia y falsa si existe a1 menos un objeto en la
ColaVaci'a. Devuelve un valor Booleano verdadero cola; cada una de estas propiedades se expresan en una
si la cola a la que se aplica esti vacia y falso si no lo sola linea
esti. estiVacia?(colaVacia) = verdadera
aiiadirobjeto. Aiiade un objeto a1 final de la cola. est6Vacia?(aiiadirObjeto(z,q))= falsa
extraerobjeto. Extrae un objeto del final de la cola.
primero. Devuelve el primer elemento de una cola,
y esta no se ve afectada por esta operaci6n. la cual establece que primero volveri con el primer ele-
hltimo. Devuelve el cltimo elemento de una cola, y mento de la cola.
esta no se ve afectada por esta operacion. Con esto se puede ver el estilo de especificaci6n.
Para concluir ofreceremos una especificaci6n com-
estciVacia? Devuelve un valor Booleano verdadero pleta de una tabla de simbolos. Esta es una estructu-
si la cola esti vacia, y falso si no lo esti. ra de datos que contiene una colecci6n de objetos sin
A continuaci6n se muestran las primeras lineas de la duplicados. Estas tablas se encuentran pricticamente
especificaci6n y las operaciones de esta cola: en todos 10s sistemas de computadoras: se utilizan
C A P ~ T U L O25 METODOS F O R M A L E S
para almacenar nombres en sistemas de empleados, La definicion del operador afiadirElemento es

identificadores de aeronaves en sistemas de control afiadirElemento(s2, afiadirElemento(s1,s)) =
del trafico aCreo, programas en sistemas operativos y si sl = s2 entonces afiadirElemento(s2,s)
otros. o si no afiadirElemento(s1,afiadirElemento(s2,s))
tablaVacia. Construye una tabla de simbolos vacia.
Esto establece que si se realizan dos sumas en la tabla
afiadirElemento. Afiade un simbolo a una tabla de de simbolos y se intenta afiadir el mismo elemento dos
simbolos que ya exista. veces, solo sera equivalente a la suma de uno de 10s dos
extraerElementu. Extrae un simbolo de una tabla de elementos. Sin embargo, si 10s elementos difieren, enton-
simbolos que ya exista. ces el efecto sera el de aiiadirlos en un orden diferente.
estaenirabla? Sera verdadero si un simbolo esti en La definicion de extraerElemento es
una tabla y falso si no esta. extraerElemento(s 1,tablavacia) = tablavacia
unir. Une el contenido de dos tablas de simbolos. extraerElemento (s 1, afiadirElemento (s2,s)) =
cwnun. Toma dos tablas de simbolos y retoma con si s l = s2 entonces extraerElemento (sl ,s)
10s elementos comunes de cada tabla. o si no aiiadirElemento (s2,extraerElemento (s 1,s))
esParteDe. Retoma verdadero si una tabla de sim- Esta definicion establece que si se intenta extraer un
bolos esti en otra tabla de simbolos. elemento de una tabla vacia se elaborara la construc-
cion de tabla vacia, y que cuando se extrae un elemen-
eslgual. Retorna verdadero si una tabla de simbolos
to s l de una tabla que contiene un objeto s2, entonces
es igual a otra tabla de simbolos.
si s l y s2 son idCnticos el efecto es el de extraer el obje-
estaVacia. Retoma verdadero si la tabla de simbolos to s l , y si no son iguales el efecto es el de dejar s2 y
esti vacia. extraer el objeto s 1.
A continuacion se muestra la definicion de las firmas La definicion de estcienirabla? es
de 10s operadores estaenTabla?(s1, tablavacia) = fdso
estAenTabla(s1, afiadirElemento(s2,s)) =
Tabla de nombres
si s 1 = s2 entonces es verdadero o si no esti
Clases: tablaSimbolos(Z)con = en Tabla? (s 1 ,s)
Operadores: En esta definicion se establece que un elemento no
tablavacia: + tablaSimbolos(Z) puede ser miembro de una tabla de simbolos vacia y
Z x tablasimbolos (Z) + que el resultado de aplicar estaenirabla? y s l a una tabla
tablasimbolos (Z) que estC fomada de s l y s2 devolveri un valor verda-
dero si s l es igual a s2; si no son iguales hay que apli-
extraerElemento: Z x tablasimbolos (Z) + car estcienirabla? a s 1.
tablasimbolos (Z) A continuacion se muestra la definicion de unir:
Z x tablasimbolos (Z) + unir(s, tablavacia) = s
Booleano unir(s, afiadirElemento(s1,t)) =
unir: tablasimbolos (Z) x afiadirElemento(s1,unir (s,t))
tablasimbolos (Z) + Aqui se establece que uniendo una tabla vacia y una
tablasimbolos (Z) tabla s da como resultado la construccion de una tabla
comun: tablasimbolos (Z) x vacia s, y que el efecto de unir dos tablas en donde una
tablasimbolos (Z) + de ellas tenga el simbolo s l es equivalente a afiadir s l
tablasimbolos Z) a1 resultado de unir dos tablas.
tablasimbolos (Z) x A continuaci6n se muestra la definicion de comun:
tablasimbolos (Z) + Booleano com6n(s, tablavacia) = tablavacia
com~n(s,afiadirElemento(s 1,t)) = si estAenTabla?(s1,s)
tablasimbolos (Z) x
entonces afiadirElemento(s1,
tablasimbolos (Z) + Booleano
com6n(s,t))
tablasimbolos (Z) + Booleano o sin0 com6n(s,t)
Esta definicion establece que la tabla compuesta de
Todas las definiciones se pueden entender a1 margen 10s elementos comunes de la tabla vacia y cualquier
de la linea siguiente otra tabla es siempre la tabla vacia. La segunda linea
afima que, si se unen dos tablas, entonces, si hay un
Clases: tablasimbolos (Z) con =
elemento com6n s l , este se aiiade a1 conjunto com6n,
la cual establece que 10s objetos del tipo Z se asociarAn o de lo contrario se forma el conjunto com6n de dos
con un operador de igualdad. conjuntos.
~ A SOFTWARE. U N E N F O Q U E PRACTICO
~ N G E N ~ E RDEL
La definicion de esParteDe? es la siguiente: esParteDe?: Z x tablasimbolos (Z) x

.esParteDe?(tablaVacia,s) = verdadero tablasimbolos (Z) -+ Booleana
esParteDe?(aiiadirElemento(s 1,s)) = esIgual?: Z x tablasimbolos (Z) x
si estaenTabla? (s 1,t) entonces esParteDe?(s,t) tablasimbolos (Z) -+ Booleana
o si no es falso
estivacia?: tablasimbolos (Z) -+ Booleana
Esta definici6n establece que la tabla de simbolos
vacia siempre es p a t e de cualquier tabla de simbolos. afiadirElemento(s2,aiiadirElemento(s1,s)) =
La segunda linea establece que si la tabla t contiene un si s 1 = s2 entonces afiadirElemento(s2,s)
elemento en s entonces se aplica esPar-tede? para ver si o si no afiadirElemento(s 1, aiiadirElemento(s2,s))
s es una subtabla de t. extraerElemento(s1, tablavacia) = tablavacia
A continuacion se presenta la definicion de eslgual?: extraerElemento(s 1, afiadirElemento(s2,s)) =
esIgual?(s,t) = esParteDe?(s,t) A esPartede?(t,s) si s 1 = s2 entonces extraerElemento(s1,s)
o si no afiadirElementos(s2,extraerElemento(s1,s))
Esta definici6n establece que las tablas de simbolos estienTabla?(sl , tablavacia) = falso
son iguales si estin dentro una de otra. La definici6n estienTabla?(sl , aiiadirElemento(s2,s)) =
final de estdvacia? es asi de sencilla: si s l = s2 entonces verdadero
estaVacia?(tablaVacia) = verdadero o si no estaenTabla?(sl ,s)
estaVacia(afiadirElemento(s1 ,t)) = falso
Aqui se establece simplemente que la tabla vacia esti
vacia y que una tabla que contiene por lo menos un obje-
to no estari vacia. comun(s, tablavacia) = tablavacia
Por tanto, la description completa de la tabla de sim- comun(s, afiadirElemento(s 1,t)) =
bolos es la siguiente: si estienTabla(s1 ,s)
entonces aiiadirElemento(s 1, comun(s,t))
Tabla de nombres o sino comun (s,t)
Clases: tablaSimbolos(Z) con =
esParteDe?(tablaVacia,s) = verdadero
Operadores: esParteDe?(afiadirElemento(s 1,s),t) =
tablavacia: -+tablaSimbolos(Z) si estienTabla?(sl ,t) entonces esParte De?(s,t)
o si no falso
afiadirTabla: Z x tablasimbolos (Z) -+
tablasimbolos (Z)
extraerElemento: Z x tablasimbolos (Z) -+ estiVacia?(tablaVacia) = verdadero
tablasimbolos (Z) estiVacia?(aiiadirElemento(s 1,s) = falso
estAenTabla?: Z x tablasimbolos (Z) -+
Booleana
Tales especificaciones son bastante dificiles de cons-
unir: tablasimbolos (Z) x truir, y el problema principal es que no se sabe cuindo
tablasimbolos (Z) -+ hay que parar de aiiadir sentencias que relaten opera-
tablasimbolos (Z) ciones y que tienden a ser mucho mis prolongadas que
comun: tablasimbolos (Z) x sus equivalentes basados en el estado. Sin embargo,
tablasimbolos (Z) -+ matemiticamente son mis puras y mas f a d e s para lle-
tablasimbolos (Z) var a cab0 el razonamiento.
Las dos secciones anteriores han descrito Z y la deri- tales como Z para acompafiar la concurrencia, no se
vacion orientada a objetos Object Z. El principal pro- ha hecho con mucho Cxito ya que nunca se diseiiaron
blema de estas especificaciones y de las notaciones realmente con esta idea en la cabeza. Donde si se ha
matematicas similares es que no tienen las funciones hecho con Cxito ha sido en el desarrollo de notacio-
para especificar 10s sistemas concurrentes: aquellos nes formales de prop6sito especial para concurrencia,
donde se ejecutan un serie de procesos a1 mismo tiem- y el prop6sito de esta secci6n es describir una de las
po -y frecuentemente con un grado elevado de comu- m i s conocidas: PSI (Procesos Secuenciales interco-
nicaci6n entre estos procesos-. Aunque se han municados) [CSP (Communicating Sequential Pro-
realizado muchos esfuerzos por modificar notaciones cesses)].
CAPfTULO 25 MeTODOS FORMALES
PSI fue desarrollado en Oxford por el cientifico toriamente. EJECUTAR es un proceso que puede encar-
informitico inglCs Tony Hoare. La idea principal que garse de cualquier suceso en su alfabeto. A1 igual que
respalda esta notaci6n es que se puede ver un siste- PARAR es un proceso no deseado e indica que ha habi-
ma como un conjunto de procesos secuenciales (pro- do un bloqueo.
gramas simples no concurrentes) que se ejecutan y Para poder hacernos una idea de la utilizaci6n de PSI
se comunican con otros procesos de manera aut6no- en la especificaci6n de procesos especificaremos algu-
ma. Hoare diseA6 PSI para describir tanto el desa- nos sistemas muy simples. El primer0 es un sistema que
rrollo de estas notaciones como la comunicaci6n que se compone de un proceso C. Una vez que se ha acti-
tiene lugar entre ellas. De la misma manera que desa- vado este proceso, la vilvula de un reactor quimico se
rroll6 esta notacibn, tambiCn desarroll6 una serie de cerrari y se parari.
leyes algebraicas que permiten llevar a cab0 un razo-
aC = { cerrar }
namiento: por ejemplo, sus leyes permiten a1 dise-
C= (cerrar + PARAR)
fiador demostrar que el proceso P,no se bloqueari
esperando la acci6n de otro proceso P,que esti a su La primera linea define el alfabeto del proceso como
vez esperando a que el proceso P, lleve a cab0 algu- un proceso que se compone de un suceso, y la segunda
na otra acci6n. linea establece que el proceso C se encargari de cerrar
La notaci6n PSI es muy simple en comparaci6n con y entonces parar.
una notaci6n Z u Object Z; depende del concept0 de un Esta es una especificaci6n muy simple y algo irreal.
suceso. Un suceso es algo que se puede observar, es at6- Definamos ahora otro proceso C, que abriri la vilvula,
mico e instantineo, lo que significa que un suceso, por la cerrari y que comenzh otra vez a comportarse enton-
ejemplo, no se puede intermmpir, sin0 que se comple- ces como C,.
tar& independientemente de lo que estC ocurriendo en aC, = { abrir, cerrar }
un sistema. La coleccih de sucesos asociados con alg6n
C,= (abrir + cerrar + C,)
proceso P se conoce como el alfabeto de P y se escribe
como aP. Ejemplos tipicos de sucesos son el encendi- Una definici6n alternativa donde se definan dos pro-
do de la vilvula de un controlador industrial, la actua- cesos seria
lizaci6n de una variable global de un programa o la aC, = { abrir }
transferencia de datos a otra computadora. Los proce- C, = (abrir + C,)
sos se definen recursivamente en funci6n de 10s suce-
sos. Por ejemplo
aC2= (cerrar)
C, = (cerrar + C,)
describe el hecho de que un proceso esti involucrado
en el suceso e dentro de a P y entonces se comporta Aqui, el primer proceso C, tiene el alfabeto {abrir},
como P. En PSI se pueden anidar definiciones de pro- se encarga de un solo suceso que aparece dentro del alfa-
cesos: por ejemplo, P se puede definir en funci6n de beto y que se comporta entonces como el proceso C,.
otro proceso P I como El C, tambiCn posee un alfabeto de un solo suceso, se
encarga de este suceso y se comporta entonces como
(e + (e, + PI)) C,. Un observador ajeno a1 tema que vea el sistema
en donde ocurre el suceso e, y el proceso se comporta expresado de esta forma veria la siguiente sucesi6n de
como el proceso P,. sucesos:
La funciones que se acaban de describir no son muy
abrir, cerrar, abrir, cerrar ....
6tiles, ya que no proporcionan ninguna opcibn, por ejem-
plo, para el hecho de que un proceso se pueda encargar Esta sucesi6n se conoce como rastreo del proceso.
de dos sucesos. El operador de opci6n I permite que las A continuaci61-1,se muestra otro ejemplo de especifica-
especificaciones PSI incluyan el elemento de determi- ci6n PSI. Esta representa un robot que se puede encar-
n i s m ~ Por
. ejemplo, la siguiente especificaci6n define gar de dos sucesos que se corresponden con un retroceso
un proceso P que permite una opci6n. o un avance en la linea. Se puede establecer la defini-
ci6n del camino infinito de un robot sin puntos finales
P = (el + P,I e,+ P,) en el recomdo de la siguiente manera
Aqui el proceso P se define como un proceso capaz
de encargarse de dos sucesos elo e,. Si se da el prime- aROBOT = { avance, retroceso }
ro, el proceso se comportari como P I , y si aparece el ROBOT = (avance +ROBOTI retroceso +ROB073
segundo, se comportari como P,. Aqui el robot se puede encargar de avanzar o retro-
En PSI existe una serie de procesos estindar. PARAR ceder y comportarse como un robot ,pudiendo avanzar
es el proceso que indica que el sistema ha terminado de y retroceder, y asi sucesivamente. Supongamos otra vez
manera anormal, en un estado no deseado como es el que la especificaci6n es real introduciendo algunas otras
bloqueo. SALTAR es un proceso que termina satisfac- funciones PSI. La complicaci6n es que la pista sobre la
que viaja el robot se compone de cientos de movimientos norma sobre la comunicaci6n y la sincronizaci6n es que
con avances y retrocesos que denotan este movimien- cuando dos procesos se e s t h ejecutando en paralelo, don-
to. Supongamos tambiCn que en esta pista el robot man- de tienen algunos sucesos en comun, deben de ejecutar
ca de la posici6n 1 . A continuacidn se muestra la ese suceso simultheamente. Tomemos como ejemplo un
definici6n de este ROBOT,: sistema bastante simple y real que enciende y apaga las
olROBOT, = ( avance,retroceso )
luces y que se basa en un ejemplo similar a1 de [HIN95].
ROBOT, = R, Las definiciones de 10s dos procesos de este sistema son:
Rl = (avance + R,) cLUZ, = { encendida, apagada )
R, = (avance + R,,, I retroceso + R,.,) LUZ, = (encendida -+encendida -+ PARAR
(i< 1 0 0 ~ i > 1) I apagada + apagada -+ PARAR)
RIm = (retroceso + h,) cLUZ, = ( encendida, apagada )
Aqui el robot representa un proceso con 10s mismos LUZ, = (encendida + apagada + LUZ,)
dos sucesos del alfabeto como el robot anterior. Sin Ambos procesos tienen el mismo alfabeto. El primer
embargo, la especificaci6n de su implicaci6n en estos proceso LUZ,, o bien enciende la luz y la vuelve a encen-
sucesos es mis compleja. La segunda linea establece que der de nuevo (hay que recordar que es posible que otros
el robot arrancarh en una posici6n inicial y se compor- procesos hayan apagado el sistema entre medias, y se
tar6 de la misma manera que con el proceso R , el cual ha averiado (PARAR es un estado no deseado), o bien
representa su posici6n en el primer recuadro. La terce- la apaga una vez, y una vez mis. El proceso LUZ,
ra linea establece que el proceso R, solo se puede encar- enciende la luz y la apaga, y a continuacion empieza a
gar del suceso de avance ya que se encuentra en el punto comportarse de nuevo como LUZ,. Los dos procesos en
final. La cuarta linea define la serie de procesos desde paralelo se denotan mediante:
R, a R,. Aqui se define el hecho de que en cualquier pun- LUZ, II LUZ,
to el robot se puede avanzar o retroceder. La linea final
especifica lo que sucede cuando el robot ha alcanzado iCuil es el efecto de ejecutar estos procesos en para-
el final del recorrido: solo puede retroceder. lelo? En una introduccidn como es esta no se puede
Esta es la manera en que funcionan 10s procesos en entrar en mucho detalle. Sin embargo, se puede dar una
PSI. En sistemas reales existiri una serie de procesos idea del razonamiento que se puede aplicar a dicha
ejecuthdose concurrentemente y comunicandose con expresi6n. Se recordara que cuando se introdujo PSI se
otros, como se muestra a continuacion mediante algu- afirm6 que no solo consiste en una notacion para espe-
nos ejemplos: cificar 10s procesos concurrentes, sino que tambikn con-
tiene una serie de normas que permiten razonar a cerca
En un sistema cliente/senidor, un solo senidor en de las expresiones de procesos complejos y, por ejem-
ejecuci6n como proceso estari en comunicaci6n con plo, determinar si cualquier suceso nefasto como un blo-
varios clientes que igualmente se ejecutarin como queo aparecera dentro del sistema especificado en PSI.
procesos. Para poder ver lo que ocurre merece la pena aplicar algu-
En sistemas de tiempo real, que controlan un reac- nas de las normas que desmoll6 Hoare para PSI. Recor-
tor quimico, existiran procesos de supervisi6n de la demos que se intenta averiguar c u d es el proceso que
temperatura de 10s reactores que se comunicarh con se ha definido mediante la ejecucidn en paralelo de 10s
10s procesos que abren y cierran las vhlvulas de estos procesos LUZ, y LUZ,. Esta expresi6n es equivalente a:
reactores. encendido + encendido + PARAR
En un sistema de control de trifico aereo, la funcio- apagado + apagado + PARAR)
nalidad del radar se podria implementar como pro-
cesos que se comunican con procesos que llevan a LUZ, = (encendidoj apagado + LUZ,)
cab0 las tareas de visualizar en pantalla las posicio- Una de las normas de Hoare establece que
nes de las aeronaves.
De aqui que exista la necesidad de representar en PSI Esto nos permite ampliar la expresi6n que involucra
la ejecuci6n en paralelo de 10s procesos. TambiCn exis- a LUZ, y LUZ, con
te la necesidad de algun medio con el que se produzca
la comunicaci6n y la sincronizaci6n entre estos proce- (encendido + ((encendido + PARAR) II (apagado +
sos. El operador que especifica la ejecuci6n en parale- LUZ,)))
lo en PSI es II. Por tanto, el proceso P que representa la Esta expresi6n se puede simplificar aun mas utili-
ejecuci6n en paralelo de 10s procesos de PI y P, se defi- zando otra de las normas de Hoare a la expresi6n
ne como (encendido + PARAR)
P = P , II P,
lo cual significa que la ejecuci6n en paralelo de 10s dos
La sincronizaci6nentre 10s procesos se logra median- procesos es equivalente a una luz que se enciende y
te procesos con algun solapamiento en sus alfabetos. La entonces se para en un estado de bloqueo no deseado.
CAP~TULO
25 M ~ T O D O SFORMALES
Hasta ahora, se han visto procesos que cooperan con ne el proceso PROD,, el cual equipara este proceso con
la sincronizaci6n mediante el hecho de que tienen alfa- A, sin entradas esperando. La segunda linea establece
betos similares o que se solapan. En 10s sistemas reales que cuando el proceso recibe un valor de entrada x se
tambiCn existiri la necesidad de que 10s procesos se comporta como el proceso con un valor x almacenado.
cornuniquen con datos. PSI es un mCtodo uniforme para La tercera linea establece que cuando un proceso con
la cornunicaci6n de datos: se trata simplemente como un valor almacenado recibe un valor y entonces se com-
un suceso en donde el suceso nomCanal.va1 indica que porta como un proceso con dos valores almacenados.
ha ocumdo un suceso que se corresponde con la comu- La liltima linea establece que un proceso con dos valo-
nicaci6n del valor val a travCs de un canal nomeanal. res almacenados emitiri el producto de estos valores,
PSI contiene un dispositivo notacional similar a1 de Z almacenarfi el lSlltimo valor y entonces se comportarfi
para distinguir entre la entrada y la salida; para distin- como A con ese valor almacenado, de manera que, por
guir la primera se introduce el signo de interrogacibn, ejemplo, si aparece otro valor se multiplicarfi por ese
mientras que para distinguir la segunda se utiliza el sig- valor y se emitirfi por el canal de salida. Asi pues, la
no de exclamaci6n. especificaci6n anterior se comporta como un proceso
A continuacih, se muestra un ejemplo basado en en donde se recibe una sucesi6n de enteros y lleva a
[HIN95], en donde se Eepresenta la especificaci6n de un cab0 la multiplicaci6n de 10s valores.
proceso que toma dos enteros y forma el producto. Se puede decir entonces que esta es una definici6n
breve de PSI -a1 igual que todos 10s mCtodos formales
PROD, = A. incluye tambiCn una notaci6n matemfitica y las normas
A. = (en? x + AJ
para el razonamiente. Aunque en las descripciones de
A ) = (en? Y + A(r.y,) Z y Object Z no se han examinado las normas y se ha
A+.y) = (fuera!(x * y) + A,,,) concentrado en el formalismo todavia contienen fun-
A primera vista esto parece muy complicado, por eso ciones sustanciales para razonar sobre las propiedades
merece la pena describirlo linea a linea. La primera defi- de un sistema.
La decisi6n de hacer uso de 10s mCtodos formales en el seguridad serfin nuestras primeras opciones, e irin
mundo real no debe de adoptarse a la ligera. Bowen y seguidos por aquellos componentes cuyo fa110 no
Hinchley [BOW951 han acuiiado 4 0 s diez manda- se pueda admitir (por razones de negocios).
mientos de 10s mCtodos formales>>,como guia para aque- IILEstimaras 10s costes. Los mCtodos formales tienen
110s que estCn a punto de embarcarse en este importante unos costes de arranque considerables. El entrena-
enfoque de la ingenieria del software5. miento del personal, la adquisici6n de herramien-
tas de apoyo y la utilizaci6n de asesores bajo
contrato dan lugar a unos costes elevados en la pri-
mera ocasi6n. Estos costes deben tenerse en cuenta
l o decisih de utilizor metodos formoles no deberh
cuando se estC considerando el beneficio obtenido
tomone o lo ligero. Sigo estos (cmondomientos)
y osegfirese de que todo el mundo hoya recibido
frente a esa inversi6n asociada a 10s mCtodos for-
lo formocibn odecuodo. males.
IV. Poseeras un experto en metodos formales a tu
I. Seleccionaras la notacion adecuada. Con objeto disposicion. El entrenarniento de expertos y la ase-
de seleccionar eficientemente dentro de la amplia soria continua son esenciales para el Cxito cuando
gama de lenguajes de especificaci6n formal exis- se utilizan 10s mCtodos formales por primera vez.
tente, el ingeniero del software deberfi considerar No abandonaras tus metodos formales de desa-
el vocabulario del lenguaje, el tip0 de aplicaci6n rrollo. Es posible, y en muchos casos resulta desea-
que haya que especificar y el grado de utilizaci6n ble, integrar 10s mCtodos formales con 10s mCtodos
del lenguaje. convencionales y/o con mCtodos orientados a obje-
11. Formalizaras, pero no de mas. En general, resulta tos (Capitulos 12 y 21). Cada uno de estos mttodos
necesario aplicar 10s mttodos formales a todos 10s posee sus ventajas y sus inconvenientes. Una com-
aspectos de 10s sistemas de cierta envergadura. binaci6n de ambos, aplicada de forma adecuada,
Aquellos componentes que Sean criticos para la puede producir excelentes resultados6.
Esta descripcion e s una version sumamente abreviada de [BOW95]. La ingenieria del software de la sala limpia (Capitulo 26) e s un ejem-
plo integrado que hace uso de 10s metodos formales y de una nota-
cion mas convencional para el desarrollo..
C A P ~ T U L O25 METODOS F O R M A L E S
diciones que son ciertas a lo largo de la ejecuci6n del Z, a1 igual que todos 10s lenguajes de especificacion
sistema que contiene una coleccion de datos-; (2) el formal, posee tanto un dominio semantic0 como un
estado -10s datos almacenados a 10s que accede el dominio sintiictico. El dominio sintactico utiliza una sim-
sistema y que son alterados por 61-; (3) la operation bologia que sigue estrechamente a la notacion de con-
-una acci6n que tiene lugar en un sistema y que lee juntos y a1 calculo de predicados. El dominio semantic0
o escribe datos en un estado-. Una operaci6n queda capacita a1 lenguaje para expresar requisitos de forma
asociada con dos condiciones: una precondici6n y una concisa. La estructura Z contiene esquemas, estructuras
postcondici6n. en forma de cuadro que presentan las variables y que
La matematica discreta -la notaci6n y practica aso- especifican las relaciones entre estas variables.
ciada a 10s conjuntos y a la especificaci6n constructiva, La decisi6n de utilizar mCtodos formales debe con-
a 10s operadores de conjuntos, a 10s operadores 16gicos siderar 10s costes de arranque, asi como 10s cambios pun-
y a las sucesiones- constituyen la base de 10s m6todos tuales asociados a una tecnologia radicalmente distinta.
formales. Estas matematicas estan implementadas en el En la mayoria de 10s casos, 10s mCtodos formales ofre-
context0 de un lenguaje de especificaci6n formal, tal cen 10s mayores beneficios para 10s sistemas de seguri-
como Z. dad y para 10s sistemas criticos para 10s negocios.
[BOW951 Bowan, J.P., y M.G. Hinchley, ..Ten Command- tions Techniques; eds.: N. Gehani y A.T. McKittrick, Addi-
ments of Formal Methods, Computer., vol. 28, n.",Abril son-Wesley, 1986, p. 3.
1995. [MAR941 Marcianiak, J.J. (ed.), Encyclopedia of Soft14,are
[GRI93] Gries, D., y F.B. Schneider, A Logical Approach to Engineering, Wiley, 1994.
Discrete Math, Springer-Verlag, 1993. [ROS95] Rosen, K.H., Discrete Mathematics and Its Appli-
[GUT931 Guttag, J.V., y J.J. Homing, Larch: Languages and cations, 3.%d., McGraw-Hill, 1995.
Tools for Formal Specifications, Springer-Verlag, 1993. [SPIXX] Spievy, J.M.. Understanding Z : A Specification Lun-
[HAL901 Hall, A., (<SevenMyths of Formal Methods,,, IEEE guuge and Its Formal Semantics, Cambridge University
Software, Septiembre 1990. Press, 1988.
[SPI92] Spievy, J.M., The Z Notation: A Reference Manual,
[HOR85] Hoare, C.A.R., Communicating Sequential Pro- Prentice-Hall, 1992.
cesses, Prentice-Hall International, 1985.
[WIL87] Witala, S.A., Discrete Mathematics: A Unified
[HIN95] Hinchley, M.G., y S.A. Jarvis, Concurrent Systems: Approach, McGraw-Hill, 1987.
Formal Development in CSP, McGraw-Hill, 1995.
[WIN901 Wing, J.M., <<ASpecifier's Introduction to Formal
[JON911 Jones, C.B., Systematic Development Using VDM, Methods,,, IEEE Computer, vol. 23, n." 9, Septiembre
2.%d., Prentice-Hall, 1991. 1990, pp. 8-24.
[LIS86] Liskov, B.H., y V. Berzins, <<AnAppraisal of Pro- [YOU941 Yourdon, E., <<FormalMethods)), Guerrilla Pro-
gram Specifications)), publicado en Software Specifica- grammer, Cutter Information Corp., Octubre 1994.
25.1. Revisar 10s tipos de deficiencias asociados a 10s enfo- a. el invariante de datos
ques menos formales de la ingenieria del software en la Sec-
ci6n 25.1.1. Proporcione tres ejemplos de cada uno de ellos, b. el estado
procedentes de su propia experiencia. c. las operaciones probables
25.2. Los beneficios de las matematicas como mecanismo de 25.4. Se le ha asignado un equipo de software que esta desa-
especificaci6n se han descrito con cierta extensi6n en este capi- rrollando software, denominado DuplicadosMemoria, y que
tulo. ~Existealglin aspect0 negativo? proporciona una mayor cantidad de memoria aparente para
25.3. Se le ha asignado un equipo de software que va a desa- un PC, en comparaci6n con la memoria fisica. Esto se logra
rrollar software para un fax m6dem. Su trabajo consiste en identificando, recogiendo y reasignando bloques de memo-
desarrollar el <<listintelef6nico)) de la aplicaci6n. La funci6n ria que hayan sido asignados a aplicaciones existentes per0
del listin telef6nico admite hasta MaxNombre nombres de no e s t h siendo utilizados. Los bloques no utilizados se rea-
direcciones que seran almacenados junto con 10s nombres de signan a aplicaciones que requieran memoria adicional. Efec-
la compaiiia, nlimeros de fax y otras informaciones relacio- tuando las suposiciones oportunas, y empleando el lenguaje
nadas. Empleando el lenguaje natural, defina: natural, defina:
I N G E N I E R ~ ADEL SOFTWARE. U N E N F O O U E PRACTICO
a. el invariante de datos 25.8. Desarrollar una especificacion constructiva de conjun-

tos correspondiente a1 conjunto de parejas en las cuales el pri-
b. el estado mer elemento de cada pareja es la suma d e dos numeros
c. las operaciones probables naturales no nulos, y el segundo elemento es la diferencia de
esos dos numeros. Ambos numeros deben de estar entre 100
25.5. Desarrollar una especificacion constructiva para un con- y 200 inclusive.
junto que contenga tuplas de numeros naturales de la forma
(x,y, z') tales que la suma de x e y es igual a z. 25.9. Desarrollar una descripcion matematica del estado y del
invariante de datos para el Problema 25.3. Refinar esta des-
25.6. El instalador de una aplicacion basada en PC determi- cripcion en el lenguaje de especificacion Z.
na si esta presente o no un conjunto de recursos de hardware
y software adecuados. Comprueba la configuracion de hard- 25.10. Desarrollar una descripcion matematica del estado y
ware para determinar si estan presentes o no diferentes dis- del invariante de datos para el Problema 25.4. Refinar esta des-
positivos (de entre muchos dispositivos posibles) y determina cripcion en el lenguaje de especificacion Z.
si ya estin instaladas las versiones especificas de software del 25.11. Utilizando la notacion Z presentada en la Tabla 25.1,
sistema y de controladores. iQuC conjunto de operadores se seleccionar alguna parte del sistema de seguridad HogarSe-
utilizaria para lograr esto? Proporcionar un ejemplo en este guro descrito anteriormente en este libro, e intentar especifi-
contexto. carlo empleando Z.
25.7. Intente desarrollar una expresion empleando la logica y 25.12. Empleando una o mas de las fuentes de informacion
un conjunto de operadores para la siguiente sentencia: <<Para indicadas en las referencias de este capitulo o en la seccion
todo x e y, si x es padre de y e v es padre de z, entonces A- es de Otrus Lecturas y Fuentes de Informacidn, desarrollar una
abuelo de z. Todas las personas tienen un padre.* Pista: utili- presentaci6n de media hora acerca de la sintaxis y semin-
ce las funciones P(x, y) y G(x, z) para representar las funcio- tica basica de un lenguaje de especificacion formal y dis-
nes padre y abuelo, respectivamente. tinto de Z.
Ademas de 10s libros utilizados como referencia en este capi- Jacky, J., The Way of Z: Practical Programming With For-
tulo, se ha publicado un numero bastante grande de libros mal Methods, Cambridge University Press, 1997.
acerca de temas relacionados con 10s metodos formales a lo Lano, J., y Haughton (eds.), Object-Oriented Specifica-
largo de 10s ultimos afios. Se presenta a continuacidn un lis- tion Case Studies, Prentice-Hall, 1993.
tad0 de 10s ejemplos mas significativos: Rann, D., J. Turnery J. Whitworth, Z: A Beginner's Guide,
Bowan, J., Formal Specification and Documentation using Chapman & Hall, 1994.
Z : A Case study Approach, International Thomson Compu- Ratcliff, B., Introducing Specification Using Z: A Practi-
ter Press, 1996. cal Case Study Approach, McGraw-Hill, 1994.
Casey, C., A Programming Approach to Formal Methods, D. Sheppard, An Introduction to Formal Specification with
McGraw-Hill, 2000. Z and VDM, McGraw-Hill, 1995.
Cooper, D., y R. Barden, Z in Practice, Prentice-Hall, 1995. Los ejemplos de septiembre de 1990 de IEEE Transac-
Craigen, D., S. Gerhart y T. Raltson, Industrial Applica- tions on Software Engineering, IEEE Software e IEEE Com-
tion of Formal Methods to Model, Design, Diagnose andAna- puter estaban dedicados todos ellos a 10s metodos formales.
lise Computer Systems, Noyes Data Corp., Park Ridge, NJ, Siguen siendo una fuente excelente de informacion util.
1995. Schuman ha editado un libro que describe 10s mCtodos
Diller, A., Z.: An Introduction to Formal Methods, 2.%d., formales y las tccnologias orientadas a objetos (Formal
Wiley, 1994. Object-Oriented Development, Springer-Verlag, 1996). El
Harry, A., Formal Methods Fact File: VDM y Z , Wiley, libro ofrece lineas generales acerca de la utilization selecti-
1997 va de metodos formales y acerca de la forma en que estos
Hinchley, M., y J. Bowan, Applications ofFormal Methods, mktodos se pueden utilizar en conjuncion con enfoques 00.
Prentice-Hall, 1995. En Internet se encuentra una gran cantidad de informa-
Hinchley, M., y J. Bowan, Industrial Strength Formal cion acerca de 10s mCtodos formales y de otros temas rela-
Methods. Academic Press, 1997. cionados. En http://www.pressman5.com se puede encontrar
Hussmann, H., Formal Foundations for Software Engi- una lista de referencias actualizada relevante para 10s meto-
neering Methods, Springer-Verlag, 1997. dos formales.
Palabras c l a v e
certifizacion ...........461
*..I .*.
espetificaciones
de caia limpia.. ....... .464
"---A:.".:...."-
estructura de caia.. ...-462

prueba de torreccibn. .. .465
K- ..
.-k
..?
.-
&UP er? iCu6ntas veces se ha ofdo decir (fallos informaticos) que s e cometen en s e analizan para permitir el c6lculo
*Halocorrectamentea la primeran? Esa el disefio y constmcci6n del software? matemaim de la fiabilidad proyectada
e s la filosofia primordial de la ingenie- Esto e s lo que promete la ingenieria del en el mmponente de software.
ria del software de sala limpia. un pro- software de sala limpia. gCu61 es el prodrcto obtenido? El
ceso que d a importancia a la verificacibn desarrollo d e especificaciones de caja
~Cualesson 10s pwos? Los modelos de
matemdrtica de lacorreccidn antes de que negra, de caja d e estado y d e caja lim-
analisis y disefio se crean utilizando la
comience la construccibn de un progra- pia. Y.ademas, el registro de 10s resul-
representaci6n de estructura de caja.
ma y de que la certificaci6nda la fiabili- iados d e las pruebas formales de
Una ncajan encapsula el sistema (o
dad deI software Iorme parts de la correccibn y las pruebas estadisticas
algun aspect0 del sistema) a un nivel
actividad de pruebas. Hacienda hinm- de utilization.
especiiico de abstraccidn. La verifica-
pie en ma lilosofia mas profunda, se tra-
ci6n de la correccidn se aplica una vez &Comopueda estar seguro de qre
taria de aquella que tiene indices de lallo
que s e ha completado el disefio de la lo he hecho correctamente? La
extremadamente bajos y que e s dificil o
estmctura de caja. Y la prueba estadis- prueba formal de correccibn s e aplica
imposible de lograr utilimndo metodos
tica de la utilizacih comienza una vez u la especilicacidn d e estructura d e
menos formales.
que s e ha verificado la correccibn en cajas. Lns pruebas estadisticas d e uti-
aQui6nla hace? Un ingeniero del soft- cada estmctura de caja. El software se lizacion ejercitan 10s escenarios de uti-
ware iormadopara esta e s p e c i a l i o n . pmeba definiendo un conjunto de esce- lizaci6n para asegurar que no s e
;POTqu8 es importante? h s errores narios, determinando la probabilidad revelen y se puedan corregir 10s erro-
conllevan doble trabajo. Trabajar el de utilimci6n de cada uno y definiendo res en la funcionalidad del usuario. Los
doble lleva m&s tiempo y e s mas caro. entonces las pruebas aleatorias que se datos d e prueba s e utilizan para pro-
iNo seria maravilloso poder reducir dra- ajustan a las probabilidades. Por ulti- porcionao una sefial de la fiabilidad del
mdticamente la cantidad d e errores mo. 10s registros de errores resultantes software.
Cuando el software falla en el mundo real, suelen abundar 10s peligros a largo plazo asi como
10s peligros inmediatos. Los peligros pueden estar relacionados con la seguridad humana, con
pkrdidas econ6micas o con el funcionamiento efectivo de una infraestructura social y de nego-
cios. La ingenieria del software de sala limpia es un modelo de proceso que elimina 10s defec-
tos antes de que puedan dar lugar a riesgos graves.
La filosofia de la <<salalimpiax en las tkcnicas de fabri- 26.1.1. La estrutegia de salu limpia

caci6n de hardware es en realidad algo bastante senci- El enfoque de sala limpia hace uso de una version espe-
110: se trata de una forma rentable y eficiente, en terminos cializada del modelo incremental de software (Capitu-
de tiempo, de establecer un enfoque de fabricacion que lo 2). Se desarrolla un cccauce de incrementos de software>>
impida la introduccion de defectos de produccion. En [LIN94] por parte de equipos de ingenien'a del software
lugar de fabricar un producto y dedicarse despues a eli- pequeiios e independientes. A medida que se va certifi-
minar defectos, el enfoque de sala limpia demanda la cando cada incremento, se integra en el todo. Cnnsi-
disciplina necesaria para eliminar errores en las espe- guientemente, la funcionalidad del sistema va creciendo
cificaciones y en el diseiio, fabricando entonces el pro- con el tiempo.
ducto de forma crlimpia~.
iCu6les son las tareas
principales que se realizan
en la ingenieria del software
de sala limpia?
La sucesi6n de tareas de sala limpia para cada incre-

mento se ilustra en la Figura 26.1. Los requisitos glo-
bales del sistema o producto se van desarrollando
empleando 10s metodos de ingenieria de sistemas des-
critos en el Capitulo 10. Una vez que se ha asignado
La filosofia de sala limpia fue propuesta por prime- una funcionalidad a1 elemento de software del sistema,
ra vez para la ingenieria del software por parte de Mills el tub0 de la sala limpia comienza sus incrementos. Se
y sus colegas [WIL87] durante 10s aiios 80. Aun cuan- producen las tareas siguientes:
do las primeras experiencias acerca de este enfoque dis-
Planificacion de incrementos. Se desarrolla un plan
ciplinado para 10s trabajos relacionados con el software
de proyecto que adopta la estrategia incremental. Se van
mostraba promesas significativas [HAU94], no ha alcan-
estableciendo las funcionalidades de cada uno de 10s
zado una amplia utilizacion. Henderson [HEN951 sugie-
incrementos, su tamaiio estimado y un plan de desarro-
tres posibles razones:
110 de sala limpia. Es precis0 tener especial cuidado para
La creencia en que la metodologia de sala limpia es asegurar que 10s incrementos certificados se vayan inte-
excesivamente teorica, excesivamente matematica y grando de forma temporalmente oportuna.
excesivamente radical para utilizarla en el desarro-
Recoleccion de requisitos. Mediante el uso de tCc-
Ilo de software real.
nicas similares a las presentadas en el Capitulo 11, se
No propugna una comprobacion unitaria por parte desarrolla una descripcion mas detallada de requisitos
de 10s desarrolladores, sin0 que la sustituye por una del nivel del usuario (para cada incremento).
verificacibn de la correccion y por un control esta-
Especificacion de la estructura de cajas. Se utiliza un
distico de la calidad -estos conceptos que repre-
metodo de especificacion que hace uso de estructuras de
sentan una desviacion fundamental con respecto a la
caja [HEV93] para describi la especificacion funcional.
forma en que se desarrolla la mayor parte del soft-
ware en la actualidad-. incrernento ng 1
I.1
La madurez de la industria de desarrollo del soft-
ware. El uso de procesos de sala limpia requiere
una aplicaci6n rigurosa de procesos definidos en
todas las fases del ciclo de vida. Dado que la mayor
parte de la industria funciona todavia en el nivel
ad hoc (segdn se ha definido por parte del Software
Engineering Institute Capability Maturity Model),
la industria no ha estado preparada para aplicar
estas tecnicas.
I S - lngenieria de sistemas G C - Generacion de codigo
Aun cuando existen ciertos indicios de verdad en RR - Recoleccion de requisitos IC - Inspection de codigo
todas las indicaciones expresadas anteriormente, 10s E E C - Especificacion de estructura C E U - Comprobacion estadistica
posibles beneficios de la ingenieria del software de sala de cajas de utilization
DF - DiseAo formal C - Certification
limpia compensan m8s que sobradamente la inversi6n V C - Verificacion de correccion PP - Planificacion de prueba
requerida para superar la resistencia cultural que se
encuentra en el ndcleo de estas objeciones. FIGURA 26.1. El modelo de proceso de sala limpia.
CAP~TULO
26 I N G E N I E R I A DEL S O F T W A R E DE S A L A L I M P I A
Ajustado a 10s principios de analisis operacional des-

critos en el Capitulo 11, la estructura de caja <<aislay
separa la definici6n creativa del comportamiento, de 10s l o solo limpia do impartancia a 10spruebas que ejercitan
datos, y de 10s procedimientos para cada nivel de refi- la manero en que se utiliza realmente elsohare.
namiento>>. 10s casas de utilizacibnpraporcionan una fuente
excelente para el praceso de planificacibn esstodistica
3
Referencia Web
Una fuente excelente de informocibn y de recursos
poro la ingenieria del software de solo limpio
de camprabacion.
Comprobacion estadistica de utilizacion. Recor-

dando que es imposible una comprobaci6n exhaustiva
del software de computadora (Capitulo 17), siempre
se puede encontror en www.cleansoft.com resulta necesario diseiiar un conjunto finito de casos de
prueba. Las tkcnicas estadisticas de utilizaci6n [PO0881
Diseno formal. Mediante el uso del enfoque de ejecutan una coleccion de pruebas derivadas de una
estructura de cajas, el diseiio de sala limpia es una exten- muestra estadistica (la distribution de probabilidad indi-
sidn natural y sin discontinuidades de la especificacibn. cada anteriormente) de todas las posibles ejecuciones
Aun cuando es posible efectuar una distincion clara entre del prograrna por parte de todos 10s usuarios de una cier-
estas dos actividades, las especificaciones (que se denota poblaci6n objetivo (Seccion 26.4).
minan <<cajasnegraw) se refinan iterativamente (den- Certificacion. Una vez que se ha finalizado la veri-
tro de cada incremento) para transformarse en diseiios ficacibn, la inspecci6n y la comprobacion de utilizaci6n
anilogos a la arquitectura y a 10s procedimientos (que (y despues de corregir todos 10s errores) se certifica el
se denominan <<cajasde estadon y majas trasparentes)), incremento como preparado para su integraci6n.
respectivamente).
A1 igual que otros modelos de proceso del soft-
verificacion de correccion. El equipo de sala lim- ware descritos en otras partes de este libro, el proce-
pia lleva a cab0 una serie de rigurosas actividades de so de sala limpia hace especial hincapik en la
verificacion de correcci6n aplicadas primer0 a1 diseiio necesidad de conducir unos modelos de anilisis y de
y despuCs a1 c6digo. La verificacion (Secciones 26.3 y diseiio de muy alta calidad. Seglin se vera posterior-
26.4) comienza con la estructura de cajas del mis alto mente en este capitulo, la notacion de estructura de
nivel (la especificacion) y avanza hacia el detalle de cajas no es mas que otra forma para que el ingenie-
diseiio y el c6digo. El primer nivel de verificaci6n de ro del software pueda representar 10s requisitos y el
correcci6n se lleva a cab0 aplicando un conjunto de diseiio. La distinci6n real del enfoque de sala limpia
<cuestionesde correction>> [LIN88]. Si este conjunto consiste en que se aplica la verificacidn formal a 10s
de preguntas no demuestra que la especificaci6n es modelos de ingenieria.
correcta, se utilizan mktodos mas formales (matemati-
cos) de verificaci6n.
26.1.2. ~ Q u hace
e diferente la sala limpia?
Dyer [DYE921 alude a las diferencias del enfoque de
occibn. Es un hdbita. sala limpia cuando define el proceso:
La sala limpia representa el primer intento prhctico de
poner el proceso de desarrollo del software bajo un control
Generacion de codigo, inspection y verificacion. estadistico de calidad con una estrategia bien definida para
Las especificaciones de estructura de caja, que se repre- la mejora continua del proceso. Para alcanzar esta meta, se
definio un ciclo unico de vida de sala limpia, que hacia hin-
sentan mediante un lenguaje especializado, se traducen cap2 en una ingenieria del software basada en las matema-
a1 lenguaje de programaci6n adecuado. Se utilizan enton- ticas para obtener diseiios de software correctos y que se
ces tkcnicas estindar de recomdo o de inspecci6n (Capi- basaba en software basado en estadistica para la certifica-
tulo 8) para asegurar el cumplimiento semantico de las cion de fiabilidad de ese software.
estructuras de c6digo y de cajas, y la correcci6n sintac- La ingenieria del software de sala limpia difiere de
tica de c6digo. A continuaci6n, se efectlia una verifica- 10s puntos de vista convencionales y orientados a obje-
ci6n de correccidn para el c6digo fuente. tos que se representan en la Partes Tercera y Cuarta de
Planificacion de la comprobacion estadistica. La este libro porque:
utilizacion estimada del software se analiza, se plani-
Hace uso explicit0 del control estadistico de calidad.
fica y se diseiia un conjunto de casos de prueba que
ejerciten la c<distribuci6nde probabilidadn de esa uti- Verifica la especificacion del diseiio empleando una
lizaci6n (Secci6n 26.4). Seglin se muestra en la Figu- demostraci6n de conecci6n basada en las matemtiticas.
ra 26.1, esta actividad de sala limpia se realiza en Hace mucho uso de la comprobaci6n estadistica de
paralelo con la especificaci6n, la verificaci6n y la gene- utilizaci6n para descubrir errores de especial inci-
raci6n de c6digo. dencia.
cubrir 10s errores) y depurado despuCs (para eliminar

10s errores). Cuando se publica finalmente el software,
la utilizaci6n prictica descubre aun mas defectos, y
10s corocterishcos mas importantes que dishnguen comienza otro ciclo de comprobacih y depuracion. Este
lo solo limpia son lo comprobocidn de correccidn trabajo repetido asociado a las actividades menciona-
y lo comprobocidn estodisko de dlizoci6n. das resulta costoso y lleva mucho tiempo. Y lo que es
peor, puede ser degenerativo; la correccion de errores
Evidentemente, el enfoque de sala limpia aplica la puede (inadvertidamente) dar lugar a la introducci6n de
mayor parte, si es que no todos, de 10s principios bisi- otros errores.
cos de ingenieria del software y de 10s conceptos que
se han presentado a lo largo de este libro. Son esencia-
les unos buenos procedimientos de analisis y disefio si
es que se desea producir una elevada calidad. Pero la lo vida y esto
pto lo mejor,
ingenieria de sala limpia diverge de las practicas de
software convencionales a1 quitar importancia (hay
quien diria eliminar) a1 papel de las pruebas de unidad
y a la depuracion y a1 reducir dramaticamente (o elimi-
nar) la cantidad de comprobaciones que son realizadas En la ingenieria del software de sala limpia, la com-
por quien desarrolla el software'. probacion unitaria y la depuracion se ven sustituidas
En el desarrollo convencional del software, 10s erro- por una verificacion de correccion y por pruebas basa-
res se aceptan como cosas que pasan. Dado que se con- das en la estadistica. Estas actividades, junto con el man-
sidera que 10s errores son inevitables, cada modulo del tenimiento de registros para una continua mejora, hacen
programa debe ser comprobado unitariamente (para des- que el enfoque de sala limpia sea h i c o .
Independientemente del mCtodo de analisis selecciona- Caja negra. Esta caja especifica el comportamien-
do, 10s principios de operaci6n presentados en el Capi- to del sistema, o de parte de un sistema. El sistema (o
tulo 11 siempre serin aplicables. Se modelan 10s datos, parte de 61) responde a estimulos especificos (sucesos)
las funciones y el comportamiento. Los modelos resul- mediante la aplicacidn de un conjunto de reglas de
tantes deben de ser descompuestos (refinados) para pro- transicidn que hacen corresponder el estimulo con la
porcionar un grado de detalle cada vez mas elevado. El respuesta.
objetivo global consiste en pasar de una especificacih Caja de estado. Esta caja encapsula 10s datos de
que captura la esencia de un problema, a una especifi- estados y de servicios (operaciones) de forma analo-
caci6n que proporciona una cantidad de detalle sustan- ga a 10s objetos. En esta vista de especificaci6n, se
cia1 para su implernentacion. representan las entradas de la caja de estados (10s esti-
La ingenieria del software de sala limpia satisface mulos) y sus salidas (las respuestas). La caja de esta-
10s principios de analisis operacional por cuanto emplea dos tambiCn representa la <<historiade estimulos>>de
un mCtodo denominado especificacidn de estructura de la caja negra, es decir, 10s datos encapsulados en la
caja. Una cccaja>>encapsula el sistema (o alglin aspec- caja de estado que deben ser mantenidos entre las tran-
to del sistema) con un cierto grado de detalle. Median- siciones implicadas
te un proceso de refinamiento progresivo, se van
refinando las cajas para formar una jerarquia en la cual Caja limpia. Las funciones de transici6n que esthn
cada caja tiene transparencia referential. Esto es, <<el implicadas en la caja de estado se definen en la caja
contenido de informaci6n de cada especificaci6n de caja limpia. Dicho literalmente, la caja limpia contiene el
basta para definir su refinamiento, sin depender de la disefio procedimental correspondiente a la caja de esta-
implementacidn de ninguna otra caja>>[LIN94]. Esto dos.
capacita a1 analista para desglosar jerkquicamente el
sistema, pasando de la representaci6n esencial situada i Como se Ileva a tab0
en la parte superior, hasta 10s detalles especificos de la el refinamiento como p r t e
implementaci6n situados en la parte inferior. Se utili- de la especificacion de estructura
zan tres tipos de cajas: de caja negra?
Las pruebas s e realizan, pero las efectua un equipo independiente

de pruebas.
CAP~TULO
26 I N G E N I E R f A DEL S O F T W A R E D E S A L A L I M P I A
La Figura 26.2 ilustra el enfoque de refinamiento 26.2.1. Especificacidn de caja negra

mediante el uso de una especificaci6n de estructura de Una especificaci6n de caja negra describe una abstrac-
cajas. Una caja negra (CN,) define las respuestas de ci6n, estimulos y respuestas empleando la notaci6n que
todo un conjunto completo de estimulos. CN, se pue- se muestra en la Figura 26.3. [MIL88]. La funci6n f se
de refinar en un conjunto de cajas negras, desde CN,., aplica a una secuencia, S*, de entradas (estimulos) y
hasta CN,,,,cada una de las cuales aborda una cierta esta funci6n 10s transforma en una salida (respuesta),
clase de comportamiento. El refinamiento prosigue R. Para componentes sencillos de software,f, puede ser
hasta que se identifique una clase cohesiva de com- una funci6n matemitica, per0 en general, f se describe
portamiento (por ejemplo, CN,,,.,).A continuaci6n, se empleando el lenguaje natural (o bien un lenguaje de
define una caja de estado (CE,,,,,)para la caja negra especificaci6n formal).
,,,,
(CN,.,,,). En este caso, CE, contiene todos 10s datos Muchos de 10s conceptos introducidos para sistemas
y semicios necesarios para implementar el comporta- orientados a objetos son aplicables tambiCn para la caja
miento definido por CN,,,,,. Por ultimo, se refina
,
CE, para formar un conjunto de cajas transparen-
, ,
negra. Las abstracciones de datos y las operaciones que
manipulan estas abstracciones, se ven encapsuladas por
tes (CT,.,,,,,)y se especifican 10s detalles de disefio de la caja negra. A1 igual que una jerarquia de clases, la
procedimientos. especificaci6n de caja negra puede mostrar las jerar-
A medida que se va realizando cada uno de estos quias de utilizaci6n en que las cajas de nivel inferior
pasos de refinamiento, se produce tambiCn una verifi- heredan las propiedades de las cajas de nivel superior
caci6n de la correcci6n. Se verifican las especifica- dentro de la estructura de irbol.
ciones de las cajas de estado para asegurar que todas
y cada una de ellas se ajustan a1 comportamiento defi-
nido por la especificaci6n de la caja negra predeceso-
ra. De manera similar, se verifican las especificaciones los conceptos orientodos o obitos se describen
de las cajas transparentes con respecto a la caja de esta-
dos predecesora.
26.2.2. Especificacidn de caja de estado
La caja de estado es ccuna generalizaci6n sencilla de una
miquina de estado>>[ML88]. Recordando la descripci6n
del modelado de comportamiento y de 10s diagramas de
El refinamienta de la estructura de caias y lo veidicacibn transici6n de estados que se ofrece en el Capitulo 12, un
de correccibn ocurren simulthneamente. estado es algun mod0 observable de comportamiento del
sistema. A medida que se produce el procesamiento, el
sistema va respondiendo a sucesos (estimulos) efectuan-
Es precis0 tener en cuenta que 10s mCtodos de espe-
do una transici6n que parte del estado y llega a a l g h nue-
cificaci6n basados en mCtodos formales (Capitulo 25) vo estado. A medida que se efectua la transici611, puede
se pueden utilizar en lugar del enfoque de especifica-
producirse una acci6n. La caja de estado utiliza una abs-
ci6n de estructura de cajas. El unico requisito es que se
tracci6n de datos para determinar la transici6n a1 estado
puede verificar formalmente cada uno de 10s niveles de
siguiente (respuesta) que se produciri como consecuen-
especificaci6n.
cia de la transici6n.
FIGURA 26.3. Una especificacion de caja negra IMIL881.
FIGURA 26.2. Refinamiento de la estructura de cajas. FIGURA 26.4. Una especificacion de caja de estado IMIL881.
463
Segun se muestra en la Figura 26.4, la caja de estado tituida por las estructuras de programaci6n estructura-
contiene una caja negra. El estimulo, S , que se introduce da que implementa g.
en la caja negra, procede de alguna fuente extema y de un
conjunto de estados intemos del sistema, T . Mills pro-
porciona una descripci6n matem5tica de la funcion,f, de El diseiio de procediiientosy la progromacibn
la caja negra contenida en el seno de la caja de estado: estructurado se describen en el Capltulo 16.
g: S* x T * + R X T
Como ejemplo, considkrese la caja limpia que se
donde g es una subfuncion que esta asociada a un esta- muestra en la Figura 26.5. La caja negra g, que se mues-
do especifico t. Cuando se consideran en su conjunto, tra en Figura 26.4 se ve sustituida por una sucesion de
las parejas de estados y subfunciones (t, g) definen la estructuras que contienen una estructura condicional.
funcion de caja negraf. Estas, a su vez, se pueden refinar para formar cajas trans-
parentes del interior a medida que vaya avanzando el
26.2.3. Especificaci6n d e caja limpia procedimiento de refinamiento progresivo.
La especificacion de caja limpia esta intimamente rela- Es importante tener en cuenta que la especificaci6n
cionada con el disefio de procedimientos y con la pro- de procedimientos descrita en la jerarquia de caja lim-
gramaci6n estructurada. En esencia, la subfunci6n g, pia se puede demostrar a efectos de correction. Este
que se encuentra dentro de la caja de estado, se ve sus- tema se considerara en la seccion siguiente.
El enfoque de diseiio que se utiliza en la ingenieria del per0 iquk pasa con el disefio de datos? En este aspec-
software de sala limpia hace mucho uso de la filosofia to, entra en juego un cierto numero de conceptos fun-
de la programaci6n estructurada. Pero, en este caso, la damentales de disefio (Capitulo 13). Los datos del
programaci6n estructurada se aplica de forma mucho programa se encapsulan como un conjunto de abstrac-
mas rigurosa. ciones a las cuales prestan servicio las subfunciones.
Los conceptos de encapsulamiento de datos, oculta-
miento de informaci6n y 10s tipos de datos se utilizan
entonces para crear el disefio de datos.
El program Do0 STARTS ha desorrollado varios guias

y docurnentos de solo lirnpia: ftp.cdrom.com/
pub/ada/docs/cleanrm
26.3.1. Refinamiento y verificacion del disefio

Cada especificacion de caja limpia representa el diseiio
de un procedimiento (subfunci6n) necesario para efec-
tuar una transicih de caja de estado. Mediante la caja
FIGURA 26.5. Una especificacion de caja transparente. limpia, se utilizan las estructuras de programaci6n
estructurada y de refinamiento progresivo segun se ilus-
La funciones basicas de procesamiento (que se des- tra en la Figura 26.6. Una funci6n de programa, f,se
cribian durante 10s refinamientos anteriores de la espe- refina para dar lugar a una sucesi6n de subfunciones g
cificaci6n) se refinan ahora utilizando una ~expansi6n y h. st as a su vez se refinan para formar estructuras
progresiva de funciones matematicas en estructuras de condicionales (si-entonces-sino y hacer-mientras). Un
conectividad 16gica [por ejemplo, si-entonces-sino] y refinamiento posterior ilustra la elaboraci6n 16gica con-
subfunciones, donde la expansi6n [se] efectua hasta que tinuada.
todas las funciones identificadas pudieran ser enuncia-
das directamente en el lenguaje de programacibn utili- L Que condiciones
zado para la implementaci6n~[DYE92]. se aplican para probar
El enfoque de la programaci6n estructurada se pue- que las construcciones
de utilizar de forma eficiente para refinar la funcibn, estructuradas son correctas?
C A P ~ T U L26
O I N G E N I E R ~ ADEL S O F T W A R E D E S A L A L l M P I A
Cada vez que se refina una caja limpia hasta el

siguiente nivel de detalle, se aplican las condiciones de
correcci6n indicadas anteriormente.
Es importante tener en cuenta que la utilizaci6n de
estructuras de programaci6n estructurada restringe el
numero de comprobaciones de correccion que es pre-
ciso efectuar. Se verifica una sola condicion en busca
de sucesiones; se verifican dos condiciones para 10s si-
entonces-sino; y se verifican tres condiciones para los
bucles.
Con objeto de ilustrar alguna verificacion de correc-
ci6n para un disefio de procedimientos, se utiliza un sen-
cillo ejemplo presentado por primera vez por parte de
Linger y sus colaboradores [LYN79]. Nuestro objetivo
es disefiar y verificar un pequefio programa que calcu-
le la parte entera, y, de una raiz cuadrada de un entero
dado, x. El disefio de procedimientos se representa
empleando el diagrama de flujo de la Figura 26.7.
FIGURA 26.6. Refinamiento progresivo.
Raiz cuadrada 1
En cada nivel de refinamiento, el equipo de sala lim-

pia2 lleva a cab0 una verificacion formal de correccion.
Para lograr esto, se asocia un conjunto de condiciones
de correccibn genkricas a las estructuras de programa-
ci6n estructurada. Si se expande una funci6n f para dar
una sucesi6n g y h, entonces la condici6n de correccion
para todas las entradas de f es:
;Es cierto que g seguido por h da lugar af!
Si se refina una funcidn p para llegar a una estruc-
tura condicional (si-entonces-sino),la condicion de
correcci6n para toda entrada de p es:
;Siempre que sea cierta la condicion (c) es cierto
que q realizap y siempre que (c) sea falsa, es
cierto que r realizap?
Si se refina una funci6n m en forma de bucle, las
condiciones de correcci6n para todas las entradas FIGURA 26.7. Calculo de la parte entera de una raiz
de m son: cuadrada [LlN79].
;Esta garantizada la finalizacion?
;Siempre que (c) sea verdadera es cierto que n Para verificar la correcci6n de este disefio, es preci-
seguido por rn realiza rn, siempre que (c) sea so definir las condiciones de entrada y de salida que se
falso, sigue realizandose rn si se obvia el bucle? indican en la Figura 26.8. La condici6n de entrada indi-
ca que x debe ser mayor o igual a 0. La condici6n de
salida requiere que x permanezca intacta y que adopte
un valor dentro del interval0 mostrado en la figura. Para
demostrar que el disefio es correcto, es necesario demos-
Si nos limitomos o construcciones estructurodos cuondo trar que las condiciones comienzo, bucle, cont, si y sali-
se creo un diseiio de procedimientos, lo prueba da mostradas en. la Figura 26.8 son ciertas en todos 10s
de lo correccibn es sencillo. Si se violon 10s construcciones, casos. En algunas ocasiones se denominan subdemos-
10spruebos de correccion son dificiles o imposibles. traciones.
Dado que todo el equipo esta implicado en el proceso de verifica-

cion, e s menos probable que se produzca un error al efectuar la veri-
ficacion en si.
Raiz ci6n que utilice x . Por tanto, queda intacto. Dado que
la comprobaci6n de condiciones (v + 112 I .r tiene
que fallar para alcanzar la condici6n salida, se sigue
que (y + 112 I x. Ademas, la condici6n bucle debe
seguir siendo verdadera (esto es, < x). Consi-
guientemente, que 0,+ 1)2 > x e y!? I-x se pueden
combinar para satisfacer la condici6n de salida.
Ademas, es preciso asegurar que finalice el bucle.
Un examen de la condici6n del bucle indica que dado
que y se va incrementando y que x 2 0, el bucle final-
mente debe terminar.
Los cinco pasos indicados anteriormente son una
demostraci6n de la correcci6n del diseiio del algoritmo
FIGURA 26.8. Dernostracion de la correccion del disefio - 26.7. Ahora estamos seguros
indicado en la Figura - de
que el diseiio calculara, realmente, la parte entera de
una raiz cuadrada.
La condici6n comienzo exige que [x 2 0 e y = 01. Es posible utilizar un enfoque matematicamente mas
Basandose en 10s requisitos del problema, se supone riguroso de la verificaci6n del disefio. Sin embargo, un
que la condici6n de entrada es correcta3. Consi- debate sobre este tema iria mas alla del alcance de este
guientemente, se satisface la primera parte de la con- libro. Los lectores interesados pueden consultar [LIN79].
dici6n comienzo, x 2 0. En el diagrama de flujo, la
sentencia que precede inmediatamente a la condi- 26.3.2. Ventajas de la verificaci6n del diseiio4
ci6n comienzo hace que y = 0. Consiguientemente,
la segunda parte de la condicion comienzo tambiCn La verification de correccion rigurosa de cada uno de
se satisface. De aqui que comienzo sea verdadero. 10s refinamientos del disefio de caja limpia posee un
cierto numero de ventajas evidentes. Linger [LIN94]
La condici6n bucle se puede encontrar de dos mane- las describe de la siguiente manera:
ras: (1) directamente saliendo de comienzo (en este
caso, la condicion del hucle se satisface directamente) Se reduce la verificacidn a un proceso finito. La
o bien (2) a travCs del control de flujo que pasa por forma anidada y secuencial, en que se organizan las
la condicion cont. Dado que la condici6n cont es estructuras de control en una caja limpia, define de
idCntica a la condici6n bucle, bucle es verdadera inde- manera natural una jerarquia que revela las condi-
pendientemente de la rama de flujo que lleve a ella. ciones de correcci6n que es preciso verificar. Un
axioma de sustituci6n [LIN79] nos permite reem-
plazar las funciones objetivo por sus refinamientos
de estructura de control dentro de la jerarquia de sub-
demostraciones. Por ejemplo, la subdemostraci6n
Para demoshor la correccion de un diseio, primero para la funci6n final f l de la Figura 26.9 requiere que
se deben identificar todos las condiciones y demoshar la comprobaci6n de las operaciones g l y g2 con la
que coda una de ellas toma un valor Booleano. funci6n final f2 produzca sobre 10s datos el mismo
Esto es lo que se lama subdemostrocion.
efecto f 1. ObsCrvese que f2 reemplaza a todos 10s
detalles de su refinamiento dentro de la demostra-
Se llega a la condici6n cont unicamente despuCs de
ci6n. Esta sustitucion localiza el argument0 de
haber incrementado en 1 el valor de y. Ademas, la
demostraci6n en la estructura de control que se esta
ruta de flujo de control que lleva a cont solamente se
estudiando. De hecho, permite a1 ingeniero del soft-
puede invocar si la condici6n si tambiCn es verda-
ware realizar demostraciones en cualquier orden.
dera. Consiguientemente si 0,+ 1)2 I x, se sigue que
y2 I x. La condicion cont se satisface. i Que es lo que se gana
La condici6n si se comprueba en la logica condicio- realizando las demostraciones
nal que se muestra. Consiguientemente, la condici6n de correccion?
si debe de ser verdadera cuando el flujo de control
pase por la via mostrada. Es imposible asociar una importancia excesiva a1
La condici6n salida exige, en primer lugar, que x no efecto positivo que posee sohre la calidad la reduc-
haya cambiado. Un examen del disefio indica que x cidn de la verificaci6n a un proceso finito. Aun
no aparece en ningun lugar a la izquierda de un ope- cuando todos, salvo 10s programas mas triviales,
rador de asignaci6n. No hay ninguna llamada a fun- muestran un conjunto, que en esencia es infinito, de
Un valor negativo para una raiz cuadrada carece de significado en Esta seccion y las Figuras 26.7 hasta la 26.9 se han adaptado de
este contexto. [LIN94]. Se utilizan con permiso del autor.
466
CAP~TULO
26 I N G E N I E R ~ ADEL SOFTWARE DE S A L A LIMPIA
rutas de ejecucion, se pueden verificar en un numero de acuerdo en que cada condicion es correcta, por
finito de pasos. tanto, un error solamente es posible si todos y cada
uno de 10s miembros del equipo verifican incorrec-
tamente una condicion. El requisito de acuerdo una-
nime basada en las verificaciones individuales de
Aun cuondo en un progromo hay uno contidad
resultados da lugar a un software que posee pocos o
extremadomentegronde de formos de ejecucibn, ningun defect0 antes de su primera ejecucion.
10s posos poro demostror que un progromo Es escalable. Todo sistema de software, indepen-
es torrecto son muy pocos. dientemente de su tamaiio, posee unos procedi-
mientos de caja transparente del mas alto nivel
[fll f 1 = [DO g l ; 92; [ f 2 ] END] ? formados por estructuras de secuencia, alternancias
DO e iteraciones. Cada uno de estos invoca tipicamente
92 a un gran subsistema que posee miles de lineas de
If21 f2 = [WHILE p l DO If31 END] ? c6digo -cada uno de estos subsistemas posee su
WHILE propio nivel superior de funciones y procedimientos
P1
DO If31 f3 = [DO 93; [f41; 98 END] ? finales-. Por tanto, las condiciones de correcci6n
93 para estas estructuras de control de alto nivel se veri-
[f41 f4 = [IF p2; THEN [f51 ELSE [f61 END] ?
IF
fican de la misma forma en que se procede con las
~2 estructuras de bajo nivel. Las verificaciones de alto
THEN If51 f5 = [DO 94; 95 END1 ? nivel pueden requerir, y merecera la pena, una mayor
94 cantidad de tiempo, per0 no se necesita mas teoria.
Produce un cddigo mejor que la comprobacidn uni-
taria. La comprobacion unitaria solamente com-
END prueba 10s efectos de ejecutar vias de pruebas
g8 seleccionadas entre muchas vias posibles. A1 basar
END la verificacion en la teoria de funciones, el enfoque
END
de sala limpia puede verificar todos y cada uno de
FIGURA 26.9. Disefio con subdemostraciones [LIN94]. 10s posibles efectos sobre 10s datos, porque aun
cuando un programa pueda tener multiples vias de
Permite que 10s equipos de sala limpia verifiquen ejecucion, solamente posee una funcion. La verifi-
todas las lineas de diseiio y de cddigo. Los diseiios cation es, ademas, mas eficiente que la comproba-
pueden efectuar la verificacion mediante un analisis cion unitaria. La mayor de las condiciones de
y debate en grupo de las bases del teorema de correc- verificacion se pueden verificar en unos pocos minu-
cion y pueden producir pruebas escritas cuando se tos, per0 las comprobaciones unitarias requieren una
necesite una confianza adicional en algun sistema cantidad notable de tiempo para prepararlas, ejecu-
critic0 para vidas o misiones. tarlas y comprobarlas.
Da lugar a un nivel de defectos prdximo a cero. Es importante tener en cuenta que la verificacion de
Durante una revision en equipo, se verifica por tur- disefio debe de aplicarse en ultima instancia a1 c6digo
nos la correcci6n de todas y cada una de las estruc- fuente en si. En este contexto, suele denominarse veri-
turas de control. Cada miembro del equipo debe estar jicaci6n de correccidn.
La tactica y estrategia de la prueba de sala limpia es algo El comportamiento visible para el usuario de ese pro-
fundamentalmente distinto de 10s enfoques convencio- grama esta controlado por las entradas y sucesos que
nales de comprobaci6n. Los mCtodos convencionales suelen ser producidos por el usuario. Pero en casos com-
derivan de casos de prueba para descubrir errores de plejos, el espectro posible de entradas y sucesos (esto
diseiio y de codificacion. El objetivo de 10s casos de es, 10s casos practicos) pueden ser extremadamente
prueba de sala limpia es validar 10s requisitos del soft- variables. ~ C u aes
l el subconjunto de casos practicos
ware mediante la demostracion de que una muestra esta- que verifica adecuadamente el comportamiento del pro-
distica de casos practicos (Capitulo 11) se han ejecutado grama? ~ s t es
a la primera cuestion que aborda la prue-
con Cxito. ba estadistica de casos practicos.
La prueba estadistica de casos ccequivale a probar
el software en la forma en que 10s usuarios tienen
26.4.1. Prueba estadistica de casos practicos intencion de utilizarlov [LIN94]. Para lograr esto, 10s
El usuario de un programa de computadora no suele equipos de prueba de sala limpia (tambiCn llamados
necesitar comprender 10s detalles tCcnicos del diseiio. equipos de certificacidn) deben determinar la distri-
bucion de probabilidad de utilizacibn correspondien- el intervalo de distribucion que se muestra en la tabla
te a1 software. La especificacion (caja negra) de cada anterior:
incremento del software se analiza para definir un con- HD-P-HD-HD-HD-FZ
junto de estimulos (entradas o sucesos) que pueden P-HD-HD-HD-C-HD-HD
dar lugar a que el software modifique su comporta- HD-HD-FZ-P-P-HD
miento. Basandose en entrevistas con posibles usua-
rios, en la creaci6n de escenarios de utilizacion y en El equipo de prueba ejecuta 10s casos pricticos indi-
una comprensi6n general del dominio de la aplica- cados anteriormente (y otros mas) y verifica el compor-
cion, se asigna una probabilidad de utilizacion a cada tamiento del software frente a la especificacion del
uno de 10s estimulos. sistema. La temporizacion de las pruebas se registra, de
Los casos practicos se generan para cada uno de 10s mod0 que sea posible determinar 10s intervalos tempo-
estimulos5 de acuerdo con la distribucion de probabili- rales. Mediante el uso de intervalos temporales, el equi-
dad de utilizacion. Como ejemplo, considkrese el siste- po de certificacion puede calcular el tiempo-minimo-entre
ma de seguridad HogarSeguro descrito anteriormente fallos. Si se lleva a cab0 una larga sucesion de pruebas
en este libro. Se esta utilizando la ingenieria del soft- sin fallo, el TMEF es bajo, y se puede suponer que la fia-
ware de sala limpia para desarrollar un incremento del bilidad del software es elevada.
software que gestione la interaction del usuario con el
teclado del sistema de seguridad. Para este incremento 26.4.2. Certificacidn
se pueden identificar cinco estimulos. El anilisis indi- Las tCcnicas de verificacion y prueba descritas ante-
ca el porcentaje de probabilidad de cada estimulo. Para riormente en este capitulo dan lugar a componentes
hacer que sea mas sencilla la selection de casos de prue- de software (y a incrementos completos) que se pue-
ba, estas probabilidades se hacen corresponder con inter- den certificar. En el context0 del enfoque de la inge-
valos numerados entre 1 y 99 [LIN94], lo que se muestra nieria del software de sala limpia, la certificacibn
en la tabla siguiente: implica que la fiabilidad (medida por el tiempo mini-
mo de fallo, TMDF) podrh ser especificada para cada
Estimulos Probabilidad Intervalo componente.
del programa El posible impact0 de 10s componentes de software
certificables va mas all5 de un sencillo proyecto de sala
habilitarl limpia. Los componentes de software reutilizables se
deshabilitar (HD) 50% 1-49 pueden almacenar junto con sus escenarios de utiliza-
fijar zona (FZ) 15% 50-63 cion, con 10s estimulos del programa y con las corres-
consulta (C) 15% 64-78 pondientes distribuciones de probabilidad. Cada uno de
10s componentes dispondra de una fiabilidad certifica-
prueba (P) 15% 79-94 da dentro del escenario de utilizacion y dentro del rCgi-
alarma (A) 5% 95-99 men de comprobacion descrito. Esta informaci6n es
sumamente valiosa para otras personas que tengan inten-
Para generar una sucesion de casos de prueba de cion de utilizar estos componentes.
utilizacion que se ajuste a la distribucion de probabi- El enfoque de la certificacion implica cinco pasos
lidades de utilizacion, se genera una serie de nume- [WOH94]:
ros aleatorios entre 1 y 99. El numero aleatorio 1. Es precis0 crear escenarios de utilizacion.
corresponde a1 intervalo de distribucion de probabi- 2. Se especifica un perfil de utilizacion.
lidad anteriormente destacado. Consiguientemente, la
3. Se generan casos de prueba a partir del perfil.
sucesion de casos practicos se define aleatoriamente
per0 se corresponde con la probabilidad correspon- 4. Se ejecutan pruebas y 10s datos de 10s fallos se
diente de aparicion de ese estimulo. Por ejemplo, registran y se analizan.
suponga que se generan las siguientes sucesiones de 5. Se calcula y se certifica la fiabilidad.
numeros aleatorios
i Como se certifica un
componente de software?
Los pasos 1 a 4 se han descrito en secciones ante-

Se derivan 10s siguientes casos pricticos median- riores. En esta section, nos concentramos en la certifi-
te la selecci6n de 10s estimulos adecuados basados en caci6n de fiabilidad.
Se utilizan herramientas automatizadas con este fin. Para mas infor-

macion, vease [DYE921
CAP~TULO
26 I N G E N I E R ~ ADEL S O F T W A R E D E S A L A LIMPIA
La certificaci6n para la ingenieria del software de sala Modelo de certificacion. Se estima y certifica la fia-
limpia requiere la creaci6n de tres modelos [P0034]: bilidad global del sistema.
Modelo de muestreo. La comprobaci6n de softwa- A1 final de la prueba estadistica de utilizaci6n, el
re ejecuta m casos de prueba aleatorios, y queda certi- equipo de certificaci6n posee la informaci6n necesaria
ficada si no se produce ning6n fallo o si se produce un para proporcionar un software que tenga un TMEF cer-
n6mero de fallos inferior a1 especificado. El valor de m tificado que se habri calculado empleando todos estos
se deriva matemiticamente para asegurar que se alcan- modelos.
ce la fiabilidad necesaria. Una descripci6n detallada del cilculo de 10s mode-
Modelo de componentes. Es precis0 certificar un sis- 10s de muestreo, de. componentes y de certificaci6n va
tema compuesto por n componentes. El modelo de com- mis alli del alcance de este libro. El lector interesado
ponentes capacita a1 analista para deterrninar la probabilidad encontrari detalles adicionales en [MUS87], [CUR861
de que falle el componente i antes de finahzar el programa. y [P0093].
La ingenieria del software de sala limpia es un enfoque definen condiciones de salida para cada una de las sub-
formal para el desarrollo del software, que puede dar funciones y se aplica un conjunto de subpruebas. Si se
lugar a un software que posea una calidad notablemen- satisfacen todas y cada una de las condiciones de sali-
te alta. Emplea la especificaci6n de estructura de cajas da, entonces el diseiio debe ser correcto.
(0 mCtodos formales) para el modelado de anilisis y Una vez finalizada la verificaci6n de correcci6n,
diseiio, y hace hincapiC en la verificaci6n de la correc- comienza la prueba estadistica de utilizaci6n. A dife-
ci6n, mis que en las pruebas, como mecanismo funda- rencia de la comprobaci6n condicional, la ingenieria del
mental para hallar y eliminar errores. Se aplica una software de sala limpia no hace hincapiC en la prueba
prueba estadistica de utilizaci6n para desarrollar la infor- unitaria o de integraci6n. En su lugar, el software se
maci6n de tasa de fallos necesaria para certificar la fia- comprueba mediante la definici6n de un conjunto de
bilidad del software proporcionado. escenarios, mediante la determinaci6n de las probabi-
El enfoque de sala limpia comienza por unos modelos lidades de utilizaci6n de cada uno de esos escenarios y
de anAlisis y diseiio que hacen uso de una representaci6n mediante la aplicaci6n posterior de pruebas aleatorias
de estructura de cajas. Una cccajan encapsula el sistema (o que satisfagan estas probabilidades. Los registros de
alg6n aspect0 del sistema) en un determinado nivel de error resultantes se combinan con modelos de muestreo,
abstracci6n. Se utilizan cajas negras para representar el de componentes y de certificaci6n para hacer posible el
comportamiento observable extemamente de ese sistema. cilculo matemitico de la fiabilidad estimada de ese com-
Las cajas de estado encapsulan 10s datos y operaciones de ponente de software.
ese estado. Se utiliza una caja limpia para modelar el dise- La filosofia de sala limpia es un enfoque riguroso de
iio de procedimientos que esti implicado por 10s datos y la ingenieria del software. Se trata de un modelo de pro-
operaciones de la caja de estados. ceso del software que hace hincapiC en la verificaci6n
Se aplica la verificaci6n de correcci6n una vez que matemitica de la correcci6n y en la certificacibn de la
esti completo el diseiio de estructura de cajas. El dise- fiabilidad del software. El resultado final son unas tasas
iio de procedimientos para un componente de software de fallo extremadamente bajas, que seria dificil o impo-
se desglosari en una serie de subfunciones. Para demos- sible de conseguir empleando unos mCtodos menos for-
trar la correcci6n de cada una de estas subfunciones, se males.
[CUR861 Currit, P.A., M. Dyer y H.D. Mills, <<Certifyingthe [HEN951 Henderson, J., <<Whyisn't cleanroom the Univer-
Reliability of Softwarew, IEEE Trans. Sofiivare Enginee- sal Software Development Methodology?>>,Crosstalk, vol.
ring, vol. SE-12, n.", Enero de 1994. 8, n.", Mayo de 1995, pp. 11-14.
[DYE921 Dyer, M., The Cleanroom Approach to Quality Soft- [HEV93] Hevner, A.R., y H.D. Mills, <<BoxStructure Methods
ware Development, Wiley, 1992. for System Development with Objects>>, IBM Systems Jour-
[HAU94] Hausler, P.A., R. Linger y C. Trammel, <<Adopting nal, vol. 31, n.", ~ e b r e r ode 1993, pp. 232-251.
Cleanroom Software Engineering with a phased Appro- [LIN79] Linger, R. M., H. D. Mills y B.I. Witt, Structured
achn, IBM Systems Journal, vol. 33, n." 1, Enero de 1994, Programming: Theory and Practice, Addison-Wesley,
pp. 89-109. 1979.
[LIN88] Linger, R. M., y H. D. Mills, {{ACase Study in Cle- [MUS87] Musa, J.D., A. Iannino y K. Okumoto, Engineering
anroom Software Engineering: The IBM COBOL Struc- and Managing Software with Reliability Measures,
turing Facility,,, Proc. COMPSAC '88, Chicago, Octubre McGraw-Hill, 1987.
de 1988. [PO0881 Poore, J. H., y H.D. Mills, {{Bringing Software
[LIN94] Linger, R., {{CleanroomProcess Model,,, IEEE Soft- Under Statistical Quality Control,,, Quality Progress,
ware, vol. 11, n.", Marzo de 1994, pp. 50-58. Noviembre de 1988, pp. 52-55.
[MIL871 Mills, H.D., M. Dyer y R. Linger, c(C1eanroom Soft- [PO0931 Poore, J. H., H.D. Mills y D. Mutchler, ((Planning
ware Engineering,,, IEEE Software, vol. 4, n . 9 , Sep- and Certifying Software System Reliability,,, IEEE Soft-
tiembre de 1987, pp. 19-24. ware, vol. 10, n.", Enero de 1993, pp. 88-99.
[MIL881 Mills, H.D., KStepwise Refinement and Verification [WOH94] Wohlin, C., y P. Runeson, {{Certificationof Soft-
in Box Structured Systems,,, Computer, vol. 2 1, n.", Junio ware Components,,, IEEE Trans, Sofmare Engineering,
de 1988, pp. 23-35. vol. 20, n.", Junio de 1994, pp. 494-499.
26.1. Si tuviera que seleccionar un aspect0 de la ingenieria del Descomponer el diseiio en subfunciones y definir un conjun-
software de sala limpia que la hiciera radicalmente distinta de to de condiciones que hagan posible demostrar que este algo-
10s enfoques convencionales u orientados a objetos de la inge- ritmo es correcto.
nieria del software, jcuil seria? 26.7. Documentar una demostraci6n de verificaci6n de correc-
26.2. iC6mo se combinan el modelo de proceso incremental cion para la ordenacidn por el mCtodo de la burbuja descrita
y el trabajo de certificaci6n para construir un software de ele- en el Problema 26.6.
vada calidad? 26.8. Seleccionar un componente de programa que se haya
26.3. Empleando la estructura de especificaci6n de cajas, desa- diseiiado en otro contexto (o bien asignado por el instruc-
rrollar un analisis de {{primerpasoz y unos modelos de dise- tor) y desarrollar para 61 una demostraci6n completa de
iio para el sistema HogarSeguro. correcci6n.
26.4. Desarrolle una especificacidn de estructura de cajas para 26.9. Seleccionar un programa que se utilice regularmente (por
una parte del sistema SSRB presentado en el Problema 12.13. ejemplo, un gestor de correo electr6nic0, un procesador de
26.5. Desarrolle una especificaci6n de estructura de cajas para texto, una hoja de c~lculo).Crear un conjunto de escenarios
el sistema de correo electr6nico en el Problema 21.14. de utilizaci6n para ese programa. Definir la probabilidad de
utilizaci6n de cada escenario y desarrollar entonces una tabla
26.6. Se define el algoritmo de ordenaci6n por el mCtodo de de estimulos del programa y de distribuci6n de probabilida-
las burbujas de la forma siguiente: des parecida a la que se muestra en la Seccidn 26.4.1.
procedure ordenburbuja;
26.10. Para la tabla de estimulos del programa y de distribu-
var i , t : integer;
ci6n de probabilidades desarrollada en el Problema 26.9, uti-
begin lizar un generador de ndmeros aleatorios con objeto de
repeat u n t i l t = a i l ] ; desarrollar un conjunto de casos de prueba para utilizarlo en
t:=a[ll una prueba estadistica de utilizacibn.
for j := 2 t o n do
i f a[j-11 > a [ j ] then begin 26.11. Con sus propias palabras, describa el objetivo de la cer-
t:= a[j-I]; tificacidn en el contexto de la ingenieria del software de sala
a [ ] - I ] : =a [ ] ]
limpia.
a [ j J := t ; 26.12. Escribir un pequefio trabajo que describa las matemi-
end ticas utilizadas para definir 10s modelos de certificaci6n des-
endrep critos brevemente en la Secci6n 26.4.2. Utilicense [MUS87],
end [CUR861 y [POP931 como punto de partida.
Prowell et al. (Cleanroom Software Engineering: Techno- excelente para aquellas personas que no estCn familiarizadas
logy and Process, Addison-Wesley, 1999) describe con con las pricticas de sala limpia.
profundidad todos 10s aspectos importantes del enfoque de The Cleanroom Panphlet (Software Technology Support
sala limpia. Estudios utiles sobre 10s temas de sala limpia Center, Hill AF Base, UT, abril 1995) contiene reimpresiones
han sido editados por Poore y Trammel1 (Cleanroom Soft- de varios articulos irnportantes. Linger [LIFT941 es una de las
ware: A Reader, Blackwell Publishing, 1996). Becker y mejores introducciones a este tema. Asset Source for Softwa-
Whittaker (Cleanroom Software Engineering Practices, re Engineering Technology, ASSET (Departamento de Defen-
Idea Group Publishing, 1996) presentan una visi6n general sa americano) ofrece un conjunto excelente de seis voldmenes
CAPfTULO 26 INGENIERfA DEL SOFTWARE DE S A L A LIMPIA
de Cleanroorn Engineering Handbooks. Se puede contactar Deck, M.D., <<UsingBox Structures to Link Cleanroom
con ASSET en [email protected]. Lockheed Martin ha and Object-Oriented Software Engineering,,, Technical Report
preparado la guia Guide to the Integration of Object-Orien- 94.01b, Cleanroom Software Engineering Inc., Boulder, CO,
ted Methods and Cleanroorn Sofnyare Engineering (1997) que 1994.
contiene un proceso genCrico de sala limpia para sistemas ope- Dyer, M. <<Designing Software for Provable Correctness:
rativos y estk disponible en: the direction for quality software)),Information and Softwa-
http://www.asset.com/stars/cleanroom/oo/guidhome.htm re Technology, vol. 30, n.", Julio/Agosto de 1988, pp. 331-
Linger y Trammel1 (Cleanroom Software Engineering 340.
Reference Model, SEI Technical Report CMUISEI-96-TR- Pruebas y Certificacion
022, 1996) han definido un conjunto de 14 procesos de sala Dyer, M., aAn Approach to Software Reliability Measu-
limpia y 20 productos de trabajos que forman la base del SEI rement,,, Information and Software Technology, vol. 29, n."
CMM para la ingenieria del software de sala limpia 8, Octubre de 1987, pp. 415-420.
(CMUISEI-96-TR-023). Head, G.E., <<Six-Sigma Software Using Cleanroom Soft-
Michael Deck, de Cleanroom Software Engineering, Inc., ware Engineering Techniques)), Hewlett-Packard Journal,
ha preparado una bibliografia sobre temas de sala limpia. Junio de 1994, pp. 40-50.
Entre las referencias se encuentran las siguientes: Oshana, R., <<QualitySoftware via a Cleanroom Metho-
Generales e Introductorias dology~,Embedded Systems Programming, Septiembre de
Deck, M.D., <<CleanroomSoftware Engineering Myths 1996, pp. 36-52.
and Realities,,, Quality Week 1997, San Francisco, CA, Mayo Whittaker, J.A., y Thomason, M.G., aA Markov Chain
de 1997. Model for Statistical Software Testing,,, IEEE Trans. on Soft-
Deck, M.D, y J.A. Whittaker, <<Lessons Learned from Fif- ware Engineering, Octubre de 1994, pp. 812-824.
teen Years of Cleanroom Testing,,, Sofnyare Testing,Analysis, Estudios de casos e informes experimentales
and Review (STAR) '97, San JosC, CA, 5-9 de Mayo de 1997.
Head, G.E., <<Six-Sigma Software Using Cleanroom Soft-
Lokan, C.J., <<The Cleanroom for Software Development,,,
ware Engineering Techniques,,, Hewlett-Packard Journal,
The Australian Computer Journal, vol. 25, n." 4, Noviembre
Junio de 1994, pp. 40-50.
de 1993.
Linger, Richard C., <<Cleanroom Software Engineering for Hevner, A.R., y H.D. Mills, <<Box-structured methods for
Zero-Defect Software,,, Proc. 15th International Conferen- systems development with objects,,, IBM systems Journal,
ce International on Software Engineering, Mayo de 1993. vol. 32, n." 2, 1993, pp. 232-251.
Keuffel, W., <<Clean Your Room: Formal Methods for the 2 Cleanroom,,, Proc. IS'Annual
Tann, L-G., ~ 0 S 3 and
9 0 ' s ~ Computer
, Language, Julio de 1992, pp. 39-46. European Industrial Symposium on Cleanroom Sofnyare Engi-
Hevner, A.R, S.A. Becker y L.B. Pedowitz, <<Integrated neering, Copenhagen, Denmark, 1993, pp. 1-40.
CASE for Cleanroom Development)), IEEE Software, Mar- Hausler, P.A., aA Recent Cleanroom Success Story: The
zo de 1992, pp. 69-76. Redwing Project)),Proc. I 71hAnnual Software Engineering
Cobb, R.H. y H.D. Mills, <<EngineeringSoftware under Workshop, NASA Goddard Space Flight Center, Diciembre
Statistical Quality Controlr, IEEE Software, Noviembre de de 1992.
1990, pp. 44-45. Trammel, C.J., Binder L.H. y Snyder, C.E., <<The Auto-
mated Production Control Documentation System: A Case
Practicas de Gestion Study in Cleanroom Software Engineering,,, ACM Trans. on
Becker, S.A., M.D. Deck y T. Janzon, crCleanroom and Orga- Software Engineering and Methodology, vol. 1, n." , Enero
nizational Change)),Proc. 141hPacific Northwest Sofnyare Qua- de 1992, pp. 8 1-94.
lity Conference, Portland, OR, 29-30 de Octubre de 1996. La verificacidn de diseiios mediante pruebas de correc-
Linger, R.C., <<CleanroomProcess Model,,, IEEE Soft- cidn se encuentra en el centro del enfoque de sala limpia. En
ware, marzo de 1994, pp. 50-58. 10s libros de Baber (Error-Free Software, Wiley, 1991) y
Linger, R.C. y Spangler, R.A., <<TheIBM Cleanroom Soft- Schulmeyer (Zero Defect Software, McGraw-Hill, 1990) se
ware Engineering Technology Transfer Program*, Sixth SEI estudia la prueba de correccidn de forma muy detallada.
Conference on Software Engineering Education, San Diego, En Internet se puede encontrar disponible mucha infor-
CA, Octubre de 1992. macidn variada sobre la ingenieria del software de sala lim-
Especificacion, Diseno y Revision pia y sobre temas relacionados. Para conseguir una lista
Deck, M.D., <<Cleanroomand Object-Oriented Software actualizada de referencias que sea relevante para la ingenie-
Engineering: A Unique Synergy)),1996 Software Technology ria del software de sala limpia se puede visitar http://www
Conference, Salt Lake City, UT, 24 de Abril de 1996. pressman5.com
adapiatibn ......... .479
dasificaciin ........ .482
composiciin ........ -480
turliicatiin ........ - 4 7 9
&Qu6es? Compre un equipo d e rnusica diciendo que 10ssistemas basados en en la arquitectura del sistema; (3)adap-
estereo y ll6veselo a casa. Cada com- componentes son mas firciles de ta 10scomponentes si s e deben hacer
ponente ha sido diseiiado para aco- ensarnblar y. por tanto, m6s caros de modificaciones para poderlos integrar
plarse en un estilo arquiteclbnico constmir a partirde piezas separadas. adecuadamente; (4) integra 10s compo-
especifico -1as conexiones son esttrn- Ademas, la ISBC hace hincapie en la nentes para formar subsistemas y la
dar y puede preestablecerse el protoco- utilizaci6n de palrones arquitectonicos aplicaci6n complela. Ademas, lo9 com-
lode comunicacidn-. El ensamblaje e s predecibles y en una infraestructura de ponentes personalizados s e han dise-
iCIcil porque eI sistema no tiene que software estandar, lo que lleva a un iiado para afrontar esos aspectos del
conshuirse a pcrrlir de piezas por sepa- resultado de calidad superior. sisterna que no pueden irnplementarse
rado. La ingenieria del software basa- utilizandocornponentes que ya existen.
;Cu&les s o n 10s pasor? La ISBC cIcom-
d a en componentes (ISBC) lucha por ;CuLI es el produclo obtenldo? El
pafia a dos octividades de ingenieria
conseguir lo mismo. Un conjuntode corn- producto de la ISBC es el software ope-
paralelas: la ingenieria del dominio y
ponentes de software preconstruidos y rational ensamblado utilizando 10s
el d e s a r r o h basado en componentes.
estandarizados estan disponibles para cornponentes de soitware existentes y
La ingenieria del dominio explora un
encajar en un estilo arquilect6nicoespe- 10s que s e acaban d e desarrollar.
dorninio d e aplicaciones con la inten-
cifico para a l g h dominiode aplicacion.
ci6n d e encontrar especificamente 10s iC6mo puedo estar segure de que
La aplicaci6n se ensambla entonces uti- lo he hecho correclamente?Utili-
componentes de datos funcionales y d e
liaandoestos componentes y no las =pie-
comportamiento candidates para Ia zando las mismas practicas SQA que
zas por separado- d e un Lenguaje de
reutilizaci6n. Estos componentes s e se nplican en todos 10s procesos de
programacibn' conventional.
encuentran en bibliotecas de reutiliza- ingenieria del software -1as revisio-
iQui4n lo hace ? Los ingenieros del ci6n. El desarrollo basado en cornpo- nes t k n i c a s iormales evaldan 10s
software. nentes obtiene 10srequisites del cliente modelos de anulisis y disefio-: las
~ P o qu6
r es tmportank? La instcda- y selecciona el eslilo arquitecl6nico revisiones especializadas tienen en
ci6n del equipo estereo solo lleva unos adecuado para cumplir 10s objetivos consideracih temas asociadoscon 10s
pocos minutos, porque 10s componen- del sistema que se va a construir, y a componentes adquiridos; y la compro-
tes estcin disefiados para integrarse continuaci6n: (1) selecciona posibles baci6n se aplica para descubrir errores
con facilidad. Aunque el software e s componentes para la reulilizaci6n: (2) e n el soitware nuevo y en componentes
considerablemente mtrs complejo que cualifica 10s componentes para asegu- reutilizables que se hayan integradoen
el sistema esiereo, se puede seguir rarse de que encajan adecuadarnente la arquitectura.
~NGEN~ER
DEL
~ ASOFTWARE. UN ENFOQUE P R A C T I C O
ai5adidos y asociados con la creaci6n de componentes de software reutilizables? iSe puede crear una biblioteca con 10s
componentes necesarios para llevar a cab0 la reutilizaci6n de manera accesible para aquellos que la necesitan?
Estas y otras preguntas siguen vivos en la comunidad de investigadores y de profesionales de la industria que
luchan por hacer que la reutilizacion de componentes de software sea el enfoque mas convencional de la ingenie-
ria del software. Algunas de estas preguntas se estudian en este capitulo.
Superficialmente, la ISBC parece bastante similar a la

~CuClesson las actividades
ingenieria del software orientada a objetos. El proceso
del marco de trabaio ISBC?
comienza cuando un equipo de software establece 10s
requisitos del sistema que se va a construir utilizando las Adaptacion de componentes. En el Capitulo 14 se
tkcnicas convencionales de obtenci6n de requisitos (Capi- sefial6 que la arquitectura del software representa 10s
tulos 10 y 11). Se establece un diseiio arquitect6nico patrones de diseiio que estan compuestos de componen-
(Capitulo 14), per0 en lugar de entrar inrnediatamente en tes (unidades de funcionalidad), conexiones y coordina-
tareas de diseiio detalladas, el equipo examina 10s requi- ci6n. Esencialmente la arquitectura define las normas del
sitos para determinar cual es el subsistema que esta dis- diseiio de todos 10s componentes, identificando 10s modos
puesto para la composici6n, y no para la construcci6n. de conexion y coordinaci6n. En algunos casos, es posi-
Esto es, el equipo formula las siguientes preguntas para ble que 10s componentes reutilizables actuales no se
todos y cada uno de 10s requisitos del sistema: correspondan con las normas del diseiio de la arquitec-
~ E posible
s disponer de componentes comerciales tura. Estos componentes deben de adaptarse para cum-
ya desarrollados (CYD) para implementar el requi- plir las necesidades de la arquitectura o descartarse y
sito? reemplazarse por otros componentes mas adecuados.
iSe dispone de componentes reutilizables desarro-
llados intemamente para implementar el requisito?
$on compatibles las interfaces de 10s componentes
que estan disponibles dentro de la arquitectura del
sistema a construir?
El equipo intenta modificar o eliminar aquellos requi-
sitos del sistema que no se pueden implementar con
componentes CYD o de desarrollo propio'. Si 10s requi-
sitos no se pueden ni cambia ni borrar, se aplican mCto- Composicion de componentes. El estilo arquitec-
dos de ingenieria del software convencionales u t6nico vuelve a jugar un papel clave en la forma en que
orientados a objetos para desarrollar 10s componentes 10s componentes del software se integran para formar
nuevos que se deben diseiiar para cumplir 10s requisi- un sistema de trabajo. Mediante la identificaci6n de 10s
tos. Pero para esos requisitos que se afrontan con 10s mecanismos de conexi6n y coordinaci6n (por ejemplo,
componentes disponibles comienza un conjunto dife- las propiedades de ejecuci6n en el diseiio), la arquitec-
rente de actividades de ingenieria del software: tura dicta la composici6n del producto final.
Cualificacion de componentes. Los requisitos del Actualization de componentes. Cuando se imple-
sistema y la arquitectura definen 10s componentes que mentan sistemas con componentes CYD, la actualiza-
se van a necesitar. Los componentes reutilizables (tan- ci6n se complica por la imposici6n de una tercera parte
to si son CYD como de desarrollo propio) se identifican (es decir, es posible que la empresa que desarroll6 el
normalmente mediante las caractensticas de sus inter- componente reutilizable no tenga el control de la empre-
faces. Es decir, se describen 4 0 s servicios que se pro- sa de ingenieria del software).
porcionan y el medio por el que 10s consumidores Todas y cada una de las actividades ISBC se estu-
acceden a estos servicios>>[BR096] como parte de la dian mas profundamente en la Secci6n 27.4.
interfaz del componente. Pero la interfaz no proporcio- En la primera parte de esta secci6n el tCrmino <<corn-
na una imagen completa del acople del componente en ponente,, se ha utilizando en repetidas ocasiones, a pesar
la arquitectura y en 10s requisitos. El ingeniero del soft- de que es dificil de efectuar una descripci6n definitiva
ware debe de utilizar un proceso de descubrimiento y de del tCrmino. Brown y Wallnau [BR096] sugieren las
analisis para cualificar el ajuste de cada componente. siguientes posibilidades:
' La irnplicacion es que la organization ajusta sus requisitos corner-
ciales o del producto de manera que se puede lograr la irnplementa-
cion basada e n componentes sin la necesidad de una ingenieria
personalizada. Este enfoque reduce el coste del sistema y rnejora el
tiempo de cornercializacion, per0 no siempre es posible.
C A P ~ T U L O27 INGENIERIA DEL SOFTWARE B A S A D A EN C O M P O N E N T E S
componente- una parte reemplazable, casi indepen- cionalidad sino tambiCn el rendimiento, la fiabilidad y
diente y no trivial de un sistema que cumple una fun- otros factores de calidad (Capitulol9) encajan con 10s
ci6n clara en el contexto de una arquitectura bien requisitos del sistema/producto que se va a construir;
definida;
componente del software en ejecuci6n- un paquete
dinimico de uni6n de uno o mis programas gestio- l a certificacihn de companentes se puede realizor
nados como una unidad, a 10s que se accede a travCs con 10s mbtodos de sola limpim. Para obtener
mbs infarmocibn comulte el Capflulo 26.
de interfaces documentadas que se pueden descubrir
en la ejecuci6n;
componentes adaptados- adaptados para modificar
componente de software- una unidad de composi- (tarnbiCn llamados ccenmascaradosn o <<envoltoriosn)
ci6n que solo depende del contexto contractual de [BR096] las caracteristicas no deseadas.
forma especifica y explicita; componentes ensamblados- integrados en un estilo
componente de negocio- la implementaci6n de soft- arquitect6nico e interconectados con una infraes-
ware de un concept0 comercial ccaut6nomon o de un tructura de componentes adecuada que permite coor-
proceso comercial; dinar y gestionar 10s componentes de forma eficaz;
Ademis de las descripciones anteriores, 10s compo- componentes actualizados- el software actual se
nentes del software tambiCn se pueden caracterizar por el reemplaza a medida que se dispone de nuevas ver-
uso en el proceso ISBC. Adem& de 10s componentes CYD, siones de componentes;
el proceso ISBC produce 10s siguientes componentes: Dado que la ISBC es una disciplina en evoluci6n, no
componentes cualifificados- evaluados por 10s inge- es probable que en el futuro surja una definici6n unifi-
nieros de software para asegurar que no s610 la fun- cada.
En el Capitulo 2, se utiliz6 un emodelo de desarrollo El modelo de proceso para la ingenieria del softwa-
basado en componentes>>(Fig. 2.12) para ilustrar la for- re basada en componentes hace hincapiC en las pistas
ma en que se integra una biblioteca de ~componentes paralelas en las que aparece concurrentemente la inge-
candidatosn reutilizables en un modelo tipico de pro- nieria del dominio (Secci6n 27.3) con el desarrollo basa-
ceso evolutivo. Sin embargo, el proceso ISBC se debe do en componentes. La ingenieria del dominio realiza
caracterizar de forma que no s610 identifique 10s comel trabajo que se requiere para establecer el conjunto de
ponentes candidatos sino que tarnbiCn cualifique la inter- componentes de software que el ingeniero del softwa-
faz de cada componente, que adapte 10s componentes re puede reutilizar. Estos componentes entonces se trans-
para extraer las faltas de coincidencias arquitect6nicas, fieren a travCs de un alimiten que separa la ingenieria
que ensamble 10s componentes en un estilo arquitect6- del dominio del desarrollo basado en componentes.
nico seleccionado y que actualice 10s componentes a
medida que cambian 10s requisitos del sistema [BR096].
lngenieria de dominio 3
Referencia Web
Lo pbgino de tecnologio de componentes proporciono
informoti6n irtil sobre ISBC:
www.odateam.com/cop/
La Figura 27.1 ilustra un modelo de proceso tipico que

acopla la ISBC explicitamente [CHR95]. La ingenieria del
dominio crea un modelo de dominio de aplicacion que se
utiliza como base para analizar 10s requisitos del usuario
en el flujo de la ingenieria del software. Una arquitectura
de software genCrica (y 10s puntos de estructura corres-
pondientes, vCase la Secci6n 27.3.3) proporciona la entra-
da para el disefio de la aplicaci6n. Finalrnente, despuCs de
que se han comprado 10s componentes reutilizables, se han
seleccionado a partir de las bibliotecas existentes o se han
I
construido (como parte de la ingenieria del dominio), 10s
L L '
ingenieros del software dispondrh de ellos durante la acti-

FIGURA 27.1. Un m o d e l o d e p r o c e s o de s o p o r t e a la ISBC. vidad de desarrollo basada en componentes.
lNGENlERfA DEL SOFTWARE. UN ENFOQUE P R ~ C T I C O
El objetivo de la ingenieria del dominio es identificar, Seleccionar funciones y objetos especificos.

construir, catalogar y diseminar un conjunto de compo- Abstraer funciones y objetos.
nentes de software que tienen aplicaci6n en el software Definir una taxonomia.
actual y futuro dentro de un dominio de aplicaci6n en
Identificar las caracteristicas comunes.
particular. El objetivo general consiste en establecer meca-
nismos que capaciten a 10s ingenieros del software para Identificar las relaciones especificas.
compartir estos componentes -para reutilizarlos- a lo Abstraer las relaciones.
largo de su trabajo en sistemas nuevos o actuales. Derivar un modelo funcional.
Definir un lenguaje del dominio.
~Comose pueden identificar

y clasificar 10s componentes
reutilizables?
El lenguaje del dominio hace posible la especifica-

ci6n y construcci6n posterior de aplicaciones dentro del
dominio.
Aun cuando 10s pasos indicados anteriormente pro-
La ingenieria del dominio incluye tres actividades porcionan un modelo 6til para el andisis del dominio, no
principales: anilisis, construcci6n y diseminaci6n. En proporcionan ninguna guia para decidir c d e s son 10s com-
el Capitulo 21 se present6 una revisi6n general del ani- ponentes de software que son candidatos para la reutiliza-
lisis del dominio. Sin embargo, este tema se vuelve a ci6n. Hutchinson y Hindley [HUT881sugieren el siguiente
tratar en las secciones siguientes. La construcci6n y la conjunto de cuestiones pragrniticas como guia para iden-
diseminaci6n del dominio se describirin mis adelante tificar 10s componentes del software reutilizables:
en otras secciones dentro de este mismo capitulo. ~ E las funcionalidad del componente un requisito
Se podria argumentar que <<lareutilizaci6n desapa- para futuras implementaciones ?
receri, no mediante la eliminacibn, sin0 mediante la
~ H a s t aquC punto es corriente la funci6n del com-
integraci6m en el entramado de pricticas de la inge-
ponente dentro del dominio?
nieria del software [TRA95]. Como la reutilizaci6n cada
vez recibe mis importancia, todavia hay quien Cree que ~ E x i s t euna duplicaci6n de la funci6n del compo-
en la pr6xima dCcada la ingenieria del dominio tendri nente dentro del dominio?
tanta importancia como la ingenieria del software. ~Dependeese componente del hardware?
~Permaneceintact0 el hardware entre implementa-
27.3.1. El proceso de analisis del dominio ciones?
En el Capitulo 21 se describia el enfoque general del ~Cuhlesson
anilisis del dominio en el context0 de la ingenieria del 10s componentes
software orientado a objetos. Las pasos del proceso se identificados durante el analisis
definian de la siguiente manera: del dominio que seran candidatos
1. Definir el dominio que hay que investigar. de la reutilizacion?
2. Categorizar 10s elementos extraidos del dominio.
3. Recoger una muestra representativa de las aplica- iEs posible trasladar las partes especificas del hard-
ciones del dominio. ware a otro componente?
LEsti el disefio suficientemente optimizado para la
4. Analizar cada aplicaci6n de la muestra.
siguiente implementaci6n?
5. Desarrollar un modelo de anilisis para 10s objetos.
~ E posible
s parametrizar un componente no reutili-
Es importante tener en cuenta que el anilisis del zable para que pase a ser reutilizable?
dominio se puede aplicar a cualquier paradigma de la iEs reutilizable ese componente en muchas imple-
ingenieria del software, siendo posible aplicarlo tanto mentaciones con cambios solo menores?
para el desarrollo convencional como para el desarro-
110 orientado a objetos. ~ E viable
s la reutilizaci6n mediante modificaciones?
Prieto-Diaz [PRI87] amplia el segundo paso del an& iSe puede descomponer un componente no reutili-
lisis del dominio indicado anteriormente y sugiere un zable para producir componentes reutilizables?
enfoque de ocho pasos para la identificaci6n y clasifi- ~ H a s t aquC punto es vilida la descomposici6n del
caci6n de componentes reutilizables: componente para su reutilizaci6n?
CAPfTULO 27 I N G E N I E R ~ ADEL S O F T W A R E B A S A D A EN C O M P O N E N T E S
Una descripci6n en profundidad de 10s mCtodos de 4. clararnente relevante, y si el software nuevo no posee
anfilisis del dominio va m 8 allfi del alcance de este libro. esta caracteristica, la reutilizaci6n sera ineficiente
Para mis informaci6n acerca del anfilisis del dominio, per0 quizfis siga siendo posible
vCase [PRI93]. 5. es claramente relevante, y si el software nuevo no
posee esta caracteristica, la reutilizaci6n sera inefi-
27.3.2. Funciones de caracterizaci6n ciente y la reutilizaci6n sin esta caracteristica no es
A veces resulta dificil determinar si un componente poten- recomendable.
cialmente reutilizable es realmente aplicable en una situa- Cuando se va a construir un software nuevo, w, den-
ci6n determinada. Para llevar a cab0 esta determinaci6n, tro del dominio de la aplicaci6n, se deriva para 61 un
es necesario definir un conjunto de caracteristicas del conjunto de caracteristicas del dominio. A continuacibn,
dominio que Sean compartidas por todo el software en el se efect6a una comparaci6n entre Dpi y D,,i, para deter-
sen0 del dominio. Una caracteristica del dominio define minar si el componente p se puede reutilizar eficazmente
alg6n atributo genCrico de todos 10s productos que exis- en la aplicaci6n w.
ten dentro del dominio. Por ejemplo, entre las caracte-
risticas genCricas se podria incluir: la importancia de la
seguridad y fiabilidad, el lenguaje de programacibn, la
concurrencia de procesamiento, y muchas mfis.
Un conjunto de caracteristicas de dominio de un com-
ponente reutilizable se puede representar como ( D p }en
3
Referencia Web
Para encontror referenciasvoliosos sobre
una tecnologio de obietos de direccionomiento
donde cada elemento Dpi del conjunto representa una de inforrnes, orquitecturosy on6lisis de dominios,
caracteristica especifica de dominio. El valor asignado se puede visitor a
l direccibn de Internet:
a D representa una escala ordinal como una indicacidn www.sei.cmu.edu/mbse/ wisr-report.html
fa
de relevancia de esa caracteristica para el componente
p. Una escala tipica [BAS941 podria ser: La Tabla 27.1 [BAS941 enumera las caracteristicas
1. no es relevante para que la reutilizaci6n sea o no ade- tipicas del dominio que pueden tener impact0 en la reu-
cuada. tilizaci6n del software. Estas caracteristicas del domi-
2. relevante s6lo en circunstancias poco comunes. nio deben de tenerse en cuenta con objeto de reutilizar
un componente de forrna eficiente.
3. relevante: el componente se puede modificar para
Aun cuando el software que se vaya a construir exis-
poder utilizarlo, a pesar de las diferencias.
ta claramente en el seno de un dominio de aplicaci61-1,
10s componentes reutilizables situados dentro de ese
Producto Proceso Personal dominio deberfin ser analizados con objeto de determi-
nar su aplicabilidad. En algunos casos (esperemos que
~p
Estabilidad Modelo Motivacion

sea un nlimero limitado), la ccreinvenci6n de la ruedaw
de requisitos de proceso
puede seguir siendo la opci6n mfis rentable.
Software Ajuste Educacion
concurrente del proceso
Restricciones Entorno Experiential 27.3.3. Modelado estructural y puntos de estructura
de memoria del proyecto formacion Cuando se aplica el anaisis del dominio, el analista bus-
Tamaho Restricciones dominio ca tramas repetidas en las aplicaciones que residen den-
de aplicaciones de planificacion de aplicacion tro del dominio. El modelado estructural es un enfoque
Complejidad Restricciones proceso de ingenieria basado en trarnas que opera efectuando la
de interfaz de presupuesto suposici6n consistente en que todo dominio de aplicacidn
de usuario posee tramas repetidas (de funcibn, de datos y de com-
Lenguaje(s1 Productividad plataforma portarniento) que tienen un potencial de reutilizaci6n.
de programacion Pollak y Rissman [POL941 describen 10s modelos
estructurales de la siguiente manera:
Seguridad lenguaje
Los modelos estructurales constan de un pequeiio numero
y fiabilidad de elementos estructurales que manifiestan unas tramas de
Requisitos Productividad interaccih claras. Las arquitecturas de sistemas que utilizan
de la duracion global del equipo modelos estructurales se caracterizan por multiples ensambla-
de desarrollo jes formados por estos elementos del modelo. De esta mane-
ra, las interacciones complejas entre sistemas que tienen muchas
Calidad del product0 unidades arquitect6nicas, surgen de trarnas sencillas de inte-
Fiabilidad mccion que existen en el conjunto pequeiio de elementos.
del ~ r o d u c t o
-- Todo dominio de aplicacidn se puede caracterizar
TABLA 27.1. Caracteristicas del dominio que afectan por un modelo estructural (por ejemplo, la avidnica difie-
al software IBAS941. re mucho en 10s aspectos especificos, per0 todo el soft-
ware modemo de este dominio tiene el mismo modelo un mecanismo de establecimiento de limites que per-
estructural). Por tanto, el modelo estructural es un esti- mite a1 usuario establecer limites sobre 10s parame-
lo arquitectonico (Capitulo 14) que puede y debe reuti- tros que hay que medir;
lizarse en aplicaciones pertenecientes a1 dominio. un mecanismo de gestihn de sensores que se comunica
McMahon [MCM95] describe un punto de estruc- con todos 10s sensores empleados en la monitorizacion;
tura como una ccestructura bien diferenciada dentro de un mecanismo de respuesta que reacciona frente a
un modelo estructural>>.Los puntos de estructura tienen las entradas proporcionadas por el sistema de ges-
tres caracteristicas bien claras: tion de sensores;
1. Un punto de estructura es una abstraccion que debe un mecanismo de control que capacita a1 usuario
de tener un ndmero limitado de instancias. Al replan- para controlar la forma en que se efectda la moni-
tear esta caracteristica en la jerga orientada a obje- torizaci6n.
tos (Capitulo 20), el tamaiio de la jerarquia de clases
debe ser pequeiio. Ademas, la abstracci6n debe repe-
tirse a lo largo de las aplicaciones del dominio. En
caso contrario, el esfuerzo requerido para verificar,
documentar y diseminar ese punto de estructura no Un punto de estruttura se puede ver tomo un potrbn
puede justificarse en tkrminos de coste. de diseiio que aparere repetidas vetes en oplitationes
dentro de un dominio especifito.
i Q u i es un ((punto
de estructuran y cuales Cada uno de estos puntos de estructura esta integra-
son sus caracteristicas? do en una arquitectura de dominio.
Es posible definir 10s puntos de estructura genkricos
2. La reglas que rigen la utilizaci6n del punto de estruc- que trascienden a un ndmero de dominios de aplicacio-
tura deben entenderse fhcilmente. Ademas, la inter- nes diferentes [STA94]:
faz con el punto de estructura debe ser relativamente Aplicaciones cliente. La IGU, que incluye todos 10s menus,
sencilla. paneles y capacidades de entrada y edici6n de 6rdenes.
3. El punto de estructura debe implementar el oculta- Bases de datos. El depcisito de todos 10s objetos relevantes
miento de infonnacibn aislando toda la complejidad para el dominio de la aplicacion
dentro del punto de estructura en si. Esto reduce la Motores de cdculo. Los modelos numkricos y no numkri-
complejidad percibida del sistema en su conjunto. cos que manipulan datos.
Como ejemplo de puntos de estructura como tramas Funcidn de reproduccidn de informes.La funci6n que pro-
arquitect6nicas para un sistema, considkrese el domi- duce salidas de todo tipo.
nio del software de sistemas de alarma. El dominio del Editor de aplicaciones. Mecanismo adecuado para perso-
sistema puede abarcar sistemas tan simples como nalizar la aplicacion ajusttindola a las necesidades de usuarios
HogarSeguro (descritos en capitulos anteriores) o tan especificos.
complejos como el sistema de alarma de un proceso Los puntos de estructura se han sugerido como alter-
industrial. Sin embargo, se encuentran un conjunto de nativa a las lineas de c6digo y a 10s puntos de funci6n
tramas estructurales predecibles: para la estimation del coste del software ([MCM95].
una interfaz que capacita a1 usuario para interactuar En la Secci6n 27.6.2 se presenta una description breve
con el sistema: del coste utilizando puntos de estructura.
El desarrollo basado en componentes es una actividad Una vez que se ha establecido la arquitectura, se debe
de la ISBC que tiene lugar en paralelo a la ingenieria popularizar mediante 10s componentes que (I) estan dis-
del dominio. La utilizacidn de mCtodos de diseiio arqui- ponibles en bibliotecas de reutilizacibn, y/o (2) se han
tect6nico y de analisis se ha descrito anteriormente en diseiiado para satisfacer las necesidades del cliente. De
otra secci6n de este texto, en donde el equipo del soft- aqui que el flujo de una tarea de desarrollo basada en
ware refina el estilo arquitectonico adecuado para el componentes tenga dos caminos posibles (Fig. 27.1).
modelo de analisis de la aplicacion que se va a cons- Cuando 10s componentes reutilizables estin disponibles
truir2. para una integracibn futura en la arquitectura, deben
Se deberia destacar que el estilo arquitectonico suele estar influen-

ciado por el modelo de estructura generic0 creado en la ingenieria
del dominio (vease Figura 27.1)
478
estar cualificados y adaptados. Cuando se requieren com- Cada uno de 10s factores anteriores es relativamen-
ponentes nuevos, deben disefiarse. Los componentes te ficil de valorar cuando se proponen 10s componen-
resultantes entonces se cccomponen, (se integran) en m a tes reutilizables que se han desarrollado dentro de la
plantilla de arquitectura y se comprueban a conciencia. misma aplicacion. Si se han aplicado pricticas de inge-
nieria del software de buena calidad durante el desa-
27.4.1. Cualificaci6n. adaptaci6n y cornposicion rrollo, se pueden disefiar respuestas para las preguntas
relacionadas con la lista anterior. Sin embargo, es mucho
de componentes
mas dificil determinar el funcionamiento intemo de com-
Corno se acaba de ver, la ingenieria del dominio propor- ponentes CYD o de terceras partes, porque la unica
ciona la biblioteca de componentes reutilizables necesa- informacion disponible es posible que sea la misma
rios para la ingenieria del software basada en componentes. interfaz de especificaciones.
Algunos de estos componentes reutilizables se desarro-
llan dentro de ella misma, otros se pueden extraer de las Adaptacion de componentes
aplicaciones actuales y aun otros se pueden adquirir de Lo ideal seria que la ingenieria del dominio creara una
terceras partes. biblioteca de componentes que pudieran integrarse ficil-
Desgraciadamente, la existencia de componentes reu- mente en una arquitectura de aplicaciones. La implica-
tilizables no garantiza que estos componentes puedan cion de una ccintegracion f8cil>>es que: (1) se hayan
integrarse ficilmente, o de forma eficaz, en la arquitec- implementado 10s mCtodos consecuentes de la gesti6n de
tura elegida para una aplicacion nueva. Esta es la razon recursos para todos 10s componentes de la biblioteca; (2)
por la que se aplica una sucesion de actividades de desa- que existan actividades comunes, tales como la gestion
rrollo basada en componentes cuando se ha propuesto de datos para todos 10s componentes, y (3) que se hayan
que se utilice un componente. implementado interfaces dentro de la arquitectura y con
el entomo extemo de manera consecuente.
Cualificacion de componentes
La cua1ificacid.n de conzponentes asegura que un com-
ponente candidato llevari a cab0 la funci6n necesaria,
encajari ademis ccadecuadamente~en el estilo arqui-
tectonic0 especificado para el sistema y exhibiri las
caracteristicas de calidad (por ejemplo, rendimiento, fia-
bilidad, usabilidad) necesarias para la aplicacion.
La descripcion de la interfaz proporciona informa-
cion util sobre la operacion y utilizacion de 10s compo-
nentes del software, per0 no proporciona toda la En realidad, incluso despuCs de haber cualificado
informaci6n necesaria para determinar si un componente un componente para su utilizacion dentro de una arqui-
propuesto puede de hecho volver a reutilizarse de mane- tectura de aplicacion, es posible exhibir conflictos en
ra eficaz en una aplicacion nueva. A continuacion, se una o mis de las ireas anteriores. Para mitigar estos
muestran algunos factores de 10s muchos a tener en cuen- conflictos se suele utilizar una tCcnica de adaptacion
ta durante la cualificacion de 10s componentes [BR096]: llamada ccencubrimiento de componentes>>[BR096].
la interfaz de programacion de aplicaciones (API); Cuando un equipo de software tiene total acceso a1 dise-
las herramientas de desarrollo e integracion necesa- fio interno y a1 codigo de un componente (no suele ser
rias para el componente; el caso de 10s componentes CYD) se aplica el encu-
brimiento de caja blanca. A1 igual que su homologo en
requisitos de ejecucion, entre 10s que se incluyen la las pruebas del software (Capitulo 17), el encubrimiento
utilizacion de recursos (por ejemplo, memoria o alma- de caja blanca examina 10s detalles del procesamien-
cenamiento), tiempo o velocidad y protocolo de red; to intemo del componente y realiza las modificaciones
a nivel de c6digo para eliminar 10s conflictos. El encu-
iCuales son 10s factores
brimiento de caja gris se aplica cuando la biblioteca
a tener en cuenta durante
de componentes proporciona un lenguaje de extension
la cualificacion de componentes?
de componentes, o API, que hace posible eliminar o
requisitos de servicio, donde se incluyen las interfa- enmascarar 10s conflictos. El encubrinziento de caja
ces del sistema operativo y el soporte por parte de negra requiere la introducci6n de un preprocesamien-
otros componentes; to o postprocesamiento en la interfaz de componentes
para eliminar o enmascarar conflictos. El equipo de
funciones de seguridad, como controles de acceso y
software debe determinar si se justifica el esfuerzo
protocolo de autenticacion;
requerido para envolver adecuadamente un componente
supuestos de disefios embebidos, incluyendo la uti- o si por el contrario se deberia disefiar un componente
lizacion de algoritmos numCricos y no numCricos; personalizado (diseiiado para eliminar 10s conflictos
manipulacion de excepciones. que se encuentren).
Composicion de componentes OMGICORBA. El Grupo de gestion de objetos (Object

Management Group) ha publicado una arquitectura comun de
La tarea de composicion de componentes ha ensam- distribucion de objetos (OMGICORBA). Los distribuidoresde
blado componentes cualificados, adaptados y disefia- objetos (ORB) proporcionan toda una garna de sewicios que
dos para popularizar la arquitectura establecida para hacen posible que 10s componentes reutilizables (objetos) se
una aplicacion. Para poder llevarlo a cabo, debe esta- comuniquen con otros componentes, independientemente de
blecerse una infraestructura donde 10s componentes su ubicacion dentro del sistema. Cuando se construyen com-
ponentes empleando el esthndar OMGICORBA, la integracion
esten unidos a un sistema operacional. La infraestruc- de esos componentes (sin modification) dentro del sistemaque-
tura (normalmente una biblioteca de componentes espe- da garantizada si se crea una interfaz mediante un lenguaje de
cializados) proporciona un modelo para la coordinacion definicibn de interfaces (LDI) para cada componente.
de componentes y senicios especificos que hacen posi-
ble coordinar unos componentes con otros, y llevar a
cab0 las tareas comunes.
Entre 10s muchos mecanismos para crear una infraes- Referencia web/
tructura eficaz, existe un conjunto de cuatro <<ingre- Lo informocibn mas otiuolizodo sobre CORBA se puede
dientes arquitect6nicos>>[ADL95] que se deberia obtener en www.omg.org
presentar para lograr la composici6n de componentes:
Modelo de intercambio de datos. Se trata de mecanismos Utilizando una methfora clientelservidor,10s objetos situa-
que capacitan a 10s usuarios y a las aplicaciones para interac- dos dentro de la aplicacion cliente solicitan uno o mas ser-
tuar y transferir datos (por ejemplo, arrastrar y soltar, cortar y vicios del servidor de ORB. Las solicitudes se hacen a traves
pegar), y que deberian estar definidos para todos 10s compo- del LDI, o bien dinamicamente en el momento de la ejecu-
nentes reutilizables. Los mecanismos de intercambio de datos cion. Un repositorio de interfaces contiene toda la informa-
no solamente permiten la transferencia de datos entre hombre cion necesaria acerca de las solicitudes de servicio y de 10s
y prograrna, y enbc componentes, sino que tambikn hacen posi- formatos de respuesta. CORBA se estudia con mas detalle
ble la transferencia entre 10s recursos del sistema (por ejem- en el Capitulo 28.
plo, arrastrar un archivo a1 icono de una impresora para COM de Microsoft. Microsoft ha desarrollado un mode-
imprimirlo). lo de objetos para componentes (COM) que proporciona una
Automatizacion. Para facilitar la interaccion entre com- especificacion para utilizar 10s componentes elaborados por
ponentes reutilizables se deberian de implementar herrarnien- diferentes fabricantes dentro de una aplicacion unica bajo el
tas, macros y guiones. sistema operative Windows. COM abarca dos elementos: las
interfaces COM (implementadas como objetos COM) y un
iCuiles son 10s ingredientes conjunto de mecanismos para registrar y pasar mensajes entre
interfaces COM. Desde el punto de vista de la aplicacion, (<el
necesarios para lograr
foco no esd en como [se implementan 10s objetos COM], sino
la composicion de componentes? en el hecho de que el objeto tiene una interfaz que se registra
con el sistema, y que utiliza el sistema de componentes para
Almacenamiento estructurado. Los datos heterogeneos comunicarse con otros objetos COMz [HAR98].
(por ejemplo, 10s datos graficos, de voz, texto, video y datos
numericos) dentro de un ccdocurnentocompuesto>>, deben estar
organizados para poder acceder a ellos como si de una sola
estructura de datos se tratase, en lugar de comportarse como si
fueran toda una coleccion de archivos por separado. aLos datos
estructurados mantienen un indice descriptivo de estructuras
de anidamiento, que las aplicaciones pueden recorrer libre-
3
Referencia Web
La informocibn mas ociuolizodo sobre COM se puede
obtener en www.microsoft.com/C0M
mente para localizar, crear o editar el contenido de datos indi-
viduales segdn lo indique el usuario final>>[ADL95]. Componentes JavaBean de SUN. El sistema de compo-
Modelo de objetos subyacente. El modelo de objetos ase- nentes JavaBean es una infraestructura ISBC portatil e inde-
gura que 10s componentes desarrolladosen distintos lenguajes pendiente de la plataforma que utiliza el lenguaje de
de programacion que residan en distintas plataformas pueden programacion Java. El sistema JavaBean amplia el applet4de
ser interoperables. Esto es, 10s objetos deben ser capaces de Java para acoplar 10s componentes de software mas sofistica-
comunicarse en una red. Para lograr esto, el modelo de obje- dos necesarios para el desarrollo basado en componentes.
tos define un esthdar para la interoperabilidad de 10s compe
nentes.
Dado que el impact0 futuro de la reutilizaci6n y de
la ISBC en la industria del software es enorme, una gran
cantidad de empresas importantes y consorcios indus-
triales3 han propuesto estfindares para el software por
3
Referencia Web
Pora obtener recursos excelentes de estimoci6n
visite lo Red de Gestores de Proyectos en
componentes: iava.sun.com/beans
En [ORF96] y YOU^^] se presenta un estudio excelente sobre 10s ' En este contexto, un applet se puede considerar un componente
estandares de ((objetosdistribuidos.. simple.
C A P ~ T U L O27 I N G E N I E R ~ ADEL S O F T W A R E B A S A D A EN C O M P O N E N T E S
El sistema de componentes JavaBean acompaiia un con- cccorrespondencia de especificaciones>>.

Bellinzoni y sus
junto de herramientas llamadas Kit de Desarrollo Bean (BDK), colaboradores [BEL95] describen un enfoque para 10s
que permite a 10s desarrolladores: (1) analizar el funcionamiento
de 10s Beans (componentes); (2) personalizar su comporta-
sistemas orientados a objetos:
miento y aspecto; (3) establecer mecanismos de coordinacidn Los componentes se definen y se almacenan como clases
y comunicacidn; (4) desarrollar Beans personalizados para su de especificacidn, diseiio e implementacidn con diferentes nive-
utilizacidn en una aplicacidn especifica; y (5) probar y evaluar les de abstraccidn (cada clase es una descripcidn ya realizada
el comportamiento de un Bean. de un proclucto procedente de aplicaciones anteriores). El cono-
cimiento de especificacidn -conocirniento de desarrollo-
iCufil de estos estfindares dominarfi la industria? Por se almacena en la forma de clases que sugieren la reutilizacidn,
el momento, no hay una respuesta fficil. Aunque muchos y que contienen indicaciones para recuperar cornponentes reu-
desarrolladores han establecido normas en base a uno tilizables basindose en su descripcih y tambikn para compe
de estos estandares, es probable que grandes empresas nerlos y ajustarlos una vez recuperados.
de software tengan la posibilidad de elegir entre tres
esthndares, dependiendo de las categorias y plataformas
de aplicacidn que hayan seleccionado.
Aunque lo empreso no hogo ingeniedo de dominias,
27.4.2. Ingenieria de componentes hay que ir reolizbndolo o medido que ovonzo el trobojo.
Cuondo conslroyo el modelo de onbliss pregintese:
Como se ha seiialado anteriormente en este capitulo, el qEs probable que este objeto o funcibn se puedo encontror
proceso de ISBC fomenta la utilizacidn de 10s compo- en otrm oplicociones de este tipa?)) Silo respuesto
nentes de software existentes. Sin embargo, hay oca- es afirmotivo, puede que el componenteyo existo.
siones en que se deben diseiiar 10s componentes. Es
decir, 10s componentes de software nuevos deben desa- Las herramientas automatizadas se utilizan para
rrollarse e integrarse con 10s componentes CYD ya exis- explorar el repositorio en un intento de hacer coinci-
tentes y 10s de desarrollo propio. Dado que estos dir el requisito indicado en la especificacidn actual con
componentes nuevos van a formar parte de la bibliote- 10s descritos para unos componentes reutilizables ya
ca de desarrollo propio de componentes reutilizables, existentes (clases). Las funciones de caracterizacidn
deberian diseiiarse para su reutilizacidn. (Seccidn 27.3.2) y las palabras reservadas se emplean
No hay nada de mfigico en la creacidn de compo- como ayuda para hallar componentes potencialmente
nentes de software que se pueden reutilizar. Conceptos reutilizables.
de diseiio tales como abstraccidn, ocultamiento, inde- Si la correspondencia de especificaciones produce
pendencia funcional, refinamiento y programacidn estruc- componentes que se ajustan a las necesidades de la
turada, junto con 10s mCtodos orientados a objetos, aplicaci6n en cuestibn, el diseiiador puede extraer
pruebas, SQA y mCtodos de verificacidn de correccidn, estos componentes de una biblioteca de reutilizaci6n
todos ellos contribuyen a la creacidn de componentes de (repositorio) y utilizarlos para diseiiar el nuevo siste-
software que son reutilizables5. En esta seccidn no se ma. Si no es posible hallar componentes de diseiio, el
revisarhn estos temas, sino que, por el contrario, se ten- ingeniero del software entonces debe aplicar mCtodos
drfin en consideraci6n 10s ternas especificos de la reuti- de diseiio convencionales u 00 para crearlos. Es en
lizacidn para prficticas s6lidas de ingenieria del software. este momento 4 u a n d o el diseiiador comienza a crear
un nuevo componente- en el que debe de conside-
rarse el diseiio para la reutilizacidn (DPR).
27.4.3. Analisis y diseiio para la reutilizaci6n
Los componentes de disefio y aniilisis se han tratado
detalladamente en las Partes Tercera y Cuarta de este
libro. Los modelos de datos, funcional y de comporta- Aunque existen usuntos especioles o tener en cuento
miento (representados mediante una gama de notacio- cuondo el objetivo es lo reutilzucibn, hay que centrorse
nes distintas) se pueden crear con objeto de describir lo en 10s principios bbsicos de un buen diserio. Si se siguen
que debe realizar una determinada aplicacidn. A conti- estos principios, 10s probobilidodes de reutilzocidn
nuacidn, se utilizan unas especificaciones por escrito uumentomn significotivomente.
para describir estos modelos, y obtener como resultado
final una descripci6n completa de 10s requisitos. Tal como se ha indicado anteriormente, el DPR
Lo ideal seria analizar el modelo de anfilisis para requiere que el ingeniero del software aplique unos s61i-
determinar aquellos elementos del modelo que indican dos conceptos y principios de diseiio del software (Capi-
unos componentes reutilizables ya existentes. El pro- tulo 13). Pero las caracteristicas del dominio de la
blema consiste en extraer informacidn a partir del mode- aplicacidn tambiCn tienen que tenerse en cuenta. Bin-
lo de requisitos, de forma que pueda llevar a una der [BIN931 sugiere un cierto ndmero de asuntos6 fun-
Para aprender mas sobre estos temas, vease desde el Capitulo 13 En general las preparaciones indicadas para el diseiio destinado a
hasta el 16, y desde el 20 al22. la reutilizacion deberian de llevarse a cab0 como parte de la inge-
nieria del dominio (Seccion 27.3).
481
INGENlERfA DEL SOFTWARE. UN ENFOQUE P R A C T I C O
damentales que deben considerarse como base del dise- Una vez que se han establecido 10s datos estandar,
fio para la reutilizaci6n: las interfaces y las plantillas de programa, el disefiador
Datos estcindar. Es preciso investigar el dorninio de la apli- posee un marco de referencia en el cual puede crear el
cacibn, y es preciso identificar las estructuras de datos estih- disefio. Los componentes nuevos que se ajustan a este
dar globales (por ejemplo, las estructuras de archivos o toda marco de referencia tendran una mayor probabilidad de
una base de datos cornpleta). Entonces se pueden caracterizar ser posteriormente reutilizables.
todos 10s componentes de diseiio para uso de estas estructuras
de datos esthdar.
A1 igual que el diseiio, la construccion de compo-
nentes reutilizables se basa en metodos de la ingenieria
Protocolos de inte$az estcindar. Deberian establecerse tres del software que ya se han descrito en otras partes de
niveles de protocolo de interfaz: la naturaleza de las interfaces
intramodulares, el diseiio de interfaces ttcnicas extemas (no este libro. La construcci6n se puede efectuar emplean-
humanas) y la interfaz hombre-miquina. do lenguajes convencionales de programacion, de ter-
Plantillas de programa. El modelo de estructura (Seccibn cera generacion, lenguajes de cuarta generacion y
27.3.3) puede servir como plantilla para el diseiio arquitect6 generadores de codigo, tecnicas de programaci6n visual
nico de un nuevo programa. o herramientas mas avanzadas.
Considere una gran biblioteca universitaria. Para su El concepto de un componente de software es una
utilizacion tiene disponibles decenas de millares de ccdescripcion de lo que hace el componenten [WHI95].
libros, peri6dicos y otras fuentes de informacion. La interfaz con el componente se describe completa-
Ahora bien, para acceder a estos recursos es preciso mente y su semantics -representada dentro del con-
desarrollar algun sistema de clasificacih. Para reco- texto de pre y postcondiciones- se identifica tambien.
rrer este gran volumen de informacion, 10s bibliote- El concepto debe comunicar la intenci6n del compo-
carios han definido un esquema de clasificaci6n que nente.
incluye un c6digo de clasificacion de la biblioteca,
palabras reservadas, nombres de autor y otras entra-
das de indice. Todas ellas capacitan a1 usuario para
encontrar el recurso necesario de forma rapida y sen-
cilla. Para describir un componente reulizoble, se tendra
que describir su concepto, contenido y contexto.
El contenido de un componente describe la forma en

que se construye el concepto. En esencia, el contenido
es una informacion que queda oculta a 10s ojos del usua-
rio habitual y que solamente necesita conocer quien
intentar6 modificar ese componente.
Considere ahora un gran deposit0 de componentes.
El contexto situa el componente de software reutili-
Residen en 61 decenas de millares de componentes de zable en el seno de su dominio de aplicabilidad, esto es,
software reutilizables. iC6m0 puede hallar el ingenie-
mediante la especificacion de caracteristicas concep-
ro del software el componente que necesita? Para res-
tuales, operacionales y de implementation, el contexto
ponder a esta pregunta, surge otra pregunta mas. iC6m0 capacita a1 ingeniero del software para hallar el com-
se describen 10s componentes de software en terminos
ponente adecuado para satisfacer 10s requisitos de la
de no ambiguos y facilrnente clasificables? Se trata de aplicacion.
cuestiones dificiles y todavia no se ha desarrollado una
respuesta definitiva. En esta seccion, se exploran las ten-
dencias actuales que capacitaran a 10s futuros ingenie-
ros del software para navegar por las bibliotecas
reutilizables. Referencia web/ '
Una detollada guia de reutilizaci6n de componentes
se puede descargor de la direccibn
27.5.1. Descripci6n de componentes reutilizables webl.ssg.gunter.af.mil/
Un componente de software reutilizable se puede des- sep/SEPver40/Main.html#GD
cribir de rnuchas rnaneras, per0 la descripci6n ideal abar-
ca lo que Tracz [TRA90] ha llarnado el Modelo 3C Para que resulte util en un sentido practice, el con-
--concepto, contenido y context-. cepto, el contenido.y el contexto tienen que traducirse
C A P ~ T U L 27
O INGENIERIA DEL S O F T W A R E B A S A D A EN C O M P O N E N T E S
en un esquema de especificacion concreto. Se han escri- Vocabulario

to varias docenas de articulos y trabajos acerca de 10s
esquemas de clasificacion para componentes de soft-
ware reutilizables (por ejemplo, [WHI95] contiene una
extensa bibliografia). Los mCtodos propuestos se pue-
den descomponer en tres zonas fundamentales: mCto-
dos de las ciencias de la documentaci6n y de
biblioteconomia, mCtodos de inteligencia artificial y sis-
temas de hipertexto. La gran mayoria de 10s trabajos
realizados hasta el momento sugiere la utilizaci6n de
mCtodos propios de biblioteconomia para la clasifica-
ci6n de componentes.
La Figura 27.2 presenta una taxonomia de 10s mCto-
dos de indexacion en biblioteconomia. Los vocabula-
rios controlados de indexaci6n limitan 10s tCrminos y
sintaxis que se pueden utilizar para clasificar 10s obje-
tos (componentes). Los vocabularies de indesacidn no FIGURA 27.2. Una taxonomia de metodos de indexacion
controlados no imponen restricciones sobre la naturale-
za de la descripci6n. La gran mayoria de 10s esquemas
de clasificaci6n para 10s componentes de software se Clasificacion por facetas. Se analiza una cierta area del
dominio y se identifica un conjunto de caracteristicasdescrip-
encuentran dentro de las tres categorias siguientes: tivas bkicas. Estas caracteristicas, que se denominan facetas,
Clasificacionenumerada. Los componentes se describen reciben entonces diferentes prioridades segun su importancia y
mediante la definicion de una estructura jertirquica en la cual se relacionan con un comDonente. La faceta ~ u e d edescribir la
se definen clases y diferentes niveles de subclases de compe funcion que lleva a c a b el componente, 10s datos que se mani-
nentes de software. Los componentes en si se enumeran en el pulan, el context0 en que se aplican o cualquier otra caracteris-
nivel m b bajo de cualquier ruta de la jerarquia enumerada. Por tica. El conjunto de facetas que describen 10s componentes se
ejem lo, una jerarquia enumerada para operaciones con ven- denomina descriptor de facetas. Generalmente, la description
tanasP podria ser por facetas se limita a un maxim0 de siete u ocho facetas.
operaciones ventana
visualizaci6n ~Cualesson las optiones
abrir disponiblespara tlasifitar
basados en menu' componentes?
ventanaAbierta
basados en sistemas Como ilustracion sencilla del uso de facetas en la clasifica-
ventanaSistema cion de componentes, considerese un esquema [LIA93] que
cerrar hace uso del siguiente descriptor de facetas:
a travgs de punter0 (funci6n. tip0 de objeto, tipo de sistema]
Cada una de las facetas del descriptorde facetas adopta uno
o mas valores que en general s e r h palabras reservadas des-
a trar& de 6rdenes criptivas. Por ejemplo, si funcion es una faceta de un compe
establecerTamVentana, redimensionadoEs- nente, entonces entre 10s valores tipicos que se asignan a esta
tandar, contraerventana faceta podriamos contar:
por arrastre funcicjtl = (copiar,desde) o bien (copiar,reemplazar.
arrastrarventana, est~rarVentana todo)
reordenaci6n de planos
La utilization de multiples valores de faceta hace posible
.... que la funcion primitiva copiar se refine m b exactamente.
desplazamiento
Las palabras resendas (valores)se asignan a1 conjunto de
.... facetas de cada componente de una cierta biblioteca de reutili-
cierre zacion. Cuando un ingeniero del software desea ocultar la biblio-
teca en busca de posibles componentes para un disefio, se
La estructura jerhquica de un esquema de clasificaci6n enu- especifica una lista de valores y se consulta la biblioteca en bus-
merado hace que sea sencillo comprenderlo y utilizarlo. Sin ca de posibles candidatos. Para incorporar una funci6n de dic-
embargo, antes de poder construir una jerarquia, es preciso Ile- cionario se pueden emplear herramientas automatizadas. Esto
var a c a b una ingenieria del dominio para que este disponible hace posible que la busqueda no so10 abarque las palabras reser-
una cantidad suficiente de conocimientos acerca de las entra- vadas especificadas por el ingeniero del software, sino tarnbitn
das correctas de esa jerarquia. otros sinonimos ttcnicos de esas mismas palabras resenadas.
' Solamente se indica un pequefio subconjunto de todas las opera-

ciones posibles.
Un esquema de clasificaci6npor facetas proporciona a1 inge- tos) que permite a la aplicaci6n cliente recuperar
niero del dominio una mayor flexibilidad a1 especificar des- 10s componentes y servicios del servidor de la
criptores complejos de 10s componentes [FRA94]. Dado que
biblioteca.
es posible aiiadir nuevos valores de facetas con facilidad, el
esquema de clasificaci6n por facetas es mis fgcil de extender unas herramientas CASE que prestan su apoyo a la
y de adaptar que el enfoque de enumeraci6n. integraci6n de componentes reutilizados en un nuevo
Clasificacion de atributos y valores. Para todos 10s com- disefio o implementaci6n.
ponentes de una cierta zona del dominio se define un conjun-
Cada una de estas funciones interactua con una
to de atributos. A continuaci6n, se asignan valores a estos
biblioteca de reutilizaci6n o bien se encuentra incorpo-
atributos de forma muy parecida a una clasificaci6n por face-
rada a esta ultima.
tas. De hecho, la clasificacionde atributos y valores es pareci-
La biblioteca de reutilizaci6n es un elemento de un
da a la clasificacion por facetas con las excepciones siguientes:
( I ) no hay limite para el nlimero de atributos que se pueden
repositorio CASE mhs extenso (Capitulo 3 1) y propor-
utilizar; (2) no se asignan prioridades a 10s atributos; y (3) no
ciona las posibilidades adecuadas para el almacena-
se utiliza la funcion diccionario.
miento de una amplia gama de elementos reutilizables
Bashdose en un estudio empirico de cada una de las (por ejemplo, especificaci611, disefio, casos de prueba,
tknicas anteriores de clasificaci6n, Frakes y Pole [FRA94] guias para el usuario). La biblioteca abarca una base de
indican que no existe una tCcnica que sea claramente <<la datos y las herramientas necesarias para consultar esa
mejorn y que ccningun mCtodo es mis que moderadamente base de datos y recuperar de ella componentes. Un
adecuado en lo tocante a efectividad de biisqueda.. ..>>. esquema de clasificaci6n de componentes (Secci6n
Parece entonces que es preciso realizar un trabajo mhs 27.5.1) servirh como base para consultas efectuadas a
extenso en el desarrollo de unos esquemas de clasifica- la biblioteca.
ci6n efectivos para las bibliotecas de reutilizaci6n. Las consultas suelen caracterizarse mediante el uso
del elemento de contexto del Modelo 3C que se descri-
27.5.2. El entorno de reutilizaci6n bia anteriormente. Si una consulta inicial da lugar a una
La reutilizaci6n de componentes de software debe de lista voluminosa de candidatos a componentes, enton-
estar apoyada por un entorno que abarque 10s elemen- ces se refina la consulta para limitar esa lista. A conti-
tos siguientes: nuacibn, se extraen las informaciones de concept0 y
una base de datos de componentes capaz de almace- contenido (despuCs de haber hallado 10s candidatos a
nar componentes de software, asi como la informaci6n componentes) para ayudar a1 desarrollador a que selec-
de clasificacion necesaria para recuperarlos. cione el componente adecuado.
Una descripci6n detallada de la estructura de biblio-
un sistema de gesti6n de bibliotecas que pro- tecas de reutilizaci6n y de las herramientas que las ges-
porciona acceso a la base de datos. tionan va mas all5 de 10s limites de este libro. El lector
un sistema de recuperaci6n de componentes de interesado deberia consultar [H0091] y [LIN95] para
software (por ejemplo, un distribuidor de obje- mis informaci6n.
La economia de la ingenieria del software basada en les indican que es posible obtener notables beneficios
componentes tiene un atractivo evidente. En teoria, de negocios mediante una reutilizaci6n agresiva del soft-
deberia proporcionar a las empresas de software unas ware. Se mejora tanto la calidad del producto, como la
ventajas notables en lo tocante a la calidad y a 10s tiem- productividad del desarrollador y 10s costes en general.
pos de realizaci6n. st as, a su vez, deberian traducirse
en ahorros de costes. existe en datos reales que presten
apoyo a nuestra intuicibn?
Para responder a esta pregunta primer0 es preciso ISBC no es un w n p e crismos))econdmico
comprender lo que se puede reutilizar en un contexto si 10s componentes disponibles son 10s correctos
de ingenieria del software, y cuiiles son 10s costes aso- poro el trobojo. Si lo reutilizocibn exige
personohzocidn, hoy que proceder con precoucidn.
ciados a la reutilizaci6n. Como consecuencia, sera posi-
ble desarrollar un anhlisis de costes y de beneficios para Calidad. En un entorno ideal, un componente del
la reutilizaci6n. software que se desarrolle para su reutilizaci6n estarh
verificado en lo tocante a su correcci6n (vCase el Capi-
27.6.1. Impacto en la calidad, productividady coste tulo 26) y no contendra defectos. En realidad, la verifi-
A lo largo de 10s filtimos afios, existen notables evi- caci6n formal no se lleva a cab0 de forma rutinaria, y
dencias procedentes de casos prhcticos en la industria 10s defectos pueden aparecer y aparecen. Sin embargo,
(por ejemplo, [HEN95], [MCM95] y [LIM94]), las cua- con cada reutilizaci6n, 10s defectos se van hallando y
CAPITULO 27 ~ N G E N I E R ~DEL
A SOFTWARE BASADA EN C O M P O N E N T E S
eliminando, y como resultado la calidad del componente ~Cualesson 10s costes

mejora. Con el tiempo, el componente llega a estar vir- asociados a la reutilizacion
tualmente libre de defectos. del software?
En un estudio realizado en Hewlet-Packard, Lim
[LIM94] informa que la tasa de defectos para el c6digo Increment0 de la documentaci6n para facilitar la reu-
reutilizado es de 0,9 defectos por KLDC, mientras que tilizaci6n;
la tasa para el software reciCn desarrollado es de 4,l Mantenimiento y mejora de componentes de la reu-
defectos por KLDC. Para que una aplicaci6n estC com- tilizaci6n;
puesta por un 68 por 100 de c6digo reutilizado, la tasa Licencias para componentes adquiridos extemamente;
de defectos sera de 2,O defectos -una mejora del51 por Creaci6n o adquisici6n y funcionamientode un dep6-
100 para la tasa esperada si la aplicaci6n hubiera sido sit0 para la reutilizaci6n;
desarrollada sin reutilizaci6n-. Henry y Faller [HEN951 Formaci6n del personal en el disefio y construcci6n
informan de una mejora de calidad del35 por 100. Aun
para la reutilizaci61-1.
cuando existen recortes anecd6ticos que abarcan un
espectro razonablemente amplio en porcentajes de mejo- Aun cuando 10s costes asociados a1 anilisis del domi-
ra de la calidad, es justo que la reutilizaci6n proporcio- nio (Secci6n 27.4) y el funcionamiento de un reposito-
ne un beneficio no despreciable en funci6n de la calidad no para la reutilizaci6n pueden resultar notables, muchos
y fiabilidad del software proporcionado. de 10s costes restantes indicados anteriormente se enfren-
tan con temas que forman parte de las buenas pricticas
de la ingenieria del software, tanto si se considera prio-
ritaria la reutilizaci6n como si no.
27.6.2. Analisis de coste empleando puntos

Aunque 10s datos ernpiricos varien, lo evidencia de estructura
industrial indica que la reutilizacion proporciono En la Secci6n 27.3.3 se definia un punto de estructura
un beneficio sustonciol en coste. como una trama arquitect6nica que aparece repetida-
mente en el sen0 de un determinado dominio de apli-
Productividad. Cuando se aplican componentes reu- caciones. El disefiador del software (o el ingeniero del
tilizables a lo largo del proceso del software, se invierte sistema) puede desarrollar una arquitectura para una
menos tiempo creando 10s planes, modelos, documentos, nueva aplicaci61-1,sistema o product0 mediante la defi-
c6digo y datos necesarios para crear un sistema fiable. nici6n de una arquitectura del dominio y poblindola
Se sigue proporcionando un mismo nivel de funcionali- entonces con puntos de estructura. Estos puntos de
dad a1 cliente con menos esfuerzo. Consiguientemente, estructura son, o bien componentes reutilizables, o bien
mejora la productividad. Aun cuando 10s informes acer- paquetes de componentes reutilizables.
ca de las mejoras de productividad son sumamente difi- Aun cuando 10s puntos de estructura Sean reutiliza-
ciles de interpretar8,parece que una reutilizaci6n de entre bles, su adaptaci61-1,integraci6n y costes de manteni-
el 30 y el 50 por 100 puede dar lugar a mejoras de pro- miento no s e r h despreciables. Antes de seguir adelante
ductividad que se encuentren entre el intervalo que media con la reutilizaci61-1,el gestor del proyecto debe enten-
entre el 25 y el 40 por 100. der 10s costes asociados a1 uso de puntos estructura.
Coste. El ahorro net0 de costes para la reutilizaci6n Dado que todos 10s puntos de estructura (y todos 10s
se estima proyectando el coste del proyecto si se hubie- componentes reutilizables en general) poseen una his-
ra desarrollado Cste desde cero, C, y restando despuCs toria pasada, es posible recoger datos de costes para cada
la suma de 10s costes asociados para la reutilizaci61-1,C,, uno de ellos. En una situaci6n ideal, 10s costes de adap-
y el coste real del software cuando este finalmente se tacibn, integracih y mantenimiento asociados a 10s com-
implanta, Ci. ponentes de una biblioteca de reutilizaci6n se mantienen
C se puede determinar aplicando una o mis de las para cada caso de utilizaci6n. Entonces es posible ana-
tCcnicas de estimaci6n descritas en el Capitulo 5. Los lizar estos datos para desarrollar una estimaci6n de cos-
costes asociados a la reutilizaci61-1, C,, incluyen tes para el pr6ximo caso en que se utilicen.
[CHR95]: Como ejemplo, considkrese una nueva aplicaci6n,
X, que requiere un 60 por 100 de c6digo nuevo, y la reu-
Modelado y anilisis del dominio; tilizaci6n de tres puntos de estructura, PE,, PE, y PE,.
Desarrollo de la arquitectura del dominio; Cada uno de estos componentes reutilizables ha sido
Existen muchas circunstancias atenuantes (por ejemplo, area de

aplicacion, complejidad del problema, estructura y tamaAo del equipo,
duracion del proyecto, tecnologia aplicada) que puede tener su
impact0 sobre la productividad del equipo de un proyecto.
utilizado en un cierto nlimero de aplicaciones adicio- lizaci6n en un sistema basado en computadoras. Los
nales, y 10s costes medios de adaptation, integracion y beneficios asociados a la reutilizacion dentro de un sis-
mantenimiento estin disponibles. tema S se pueden expresar como el siguiente cociente
iExiste un calculo rapido Rb (')= ['sin reutilizacih- '

con reutilizaci6nl 'sin reutilizacidn (27'1)
que permita estimar donde
el beneficio de la reutilizacion Csinreutilizaci6n es el coste de desarrollar S sin reutilizacion,
de componentes en terminos Y
de coste? Ccon es el coste de desarrollar S con reutilizacion
De lo que se deduce que Rb(S) se puede expresar
Para estimar el esfuerzo requerido para proporcionar como un valor no dimensional que se encuentra en el
la aplicacion, X, es preciso efectuar el siguiente cilculo: interval0
esfueno global = Enucvo + Eigua~+ E d p t u c i b n + Eintegmcicin 0 5 Rb(S)< 1 (27.2)
donde Devanbu y sus colaboradores [DEV95] sugieren que
EnUeYO = es el esfuerzo que el ingeniero requiere para cons- (1) Rb se veri afectado por el disefio del sistema; (2)
truu 10s nuevos componentes de software (que se determina- dado que Rb se ve afectado por el disefio, es importan-
r i empleando las tCcnicas descritas en el Capitulo 5); te hacer que Rb forme parte de la estimacion de alter-
Eigual= es el esfuerzo requerido para cualificar PE,, PE, y nativas de disefio; y (3) 10s beneficios asociados a la
PE,; reutilizaci6n estarin intimamente relacionados con 10s
Eadaptacidn
= es el esfuerzo requerido para adaptar PE,, PE,
beneficios en tCrminos de costes de cada uno de 10s com-
ponentes reutilizables individuales.
Y PE,;
Se define una medida general de reutilizacion en 10s
= es el esfuerzo requerido para integrar PE,, PE,
Eintegracidn
sistemas orientados a objetos, denominada aprovecha-
Y PE3;
miento de reutilizaci6n [BAN941 en la siguiente forma:
El esfuerzo necesario para cualificar, adaptar e inte-
Raprovechado = OBJreutilizadoslOBJconbtru~d~s (27.3)
grar PE,, PE, y PE, se determina calculando la media
de datos historicos recogidos para la cualificacion, adap- donde
taci6n e integracion de 10s componentes reutilizables OBSeutlllzados
es el n6mero de objetos reutilizados en el
en otras aplicaciones. sistema;
OBJconstruidos
es el numero de objetos construidos para el
27.6.3. Metricas de reutilizaci6n sistema.
Se ha desarrollado toda una gama de mCtricas de soft- De lo que se deduce que a medida que aumenta
ware en un intento de medir 10s beneficios de la reuti- Raprovechado,
tambiCn aumenta Rb.
La ingenieria del software basada en componentes rrollo basado en componentes cualifica, adapta e inte-
proporciona unos beneficios inherentes en lo tocante a gra estos componentes para su reutilizacih en un siste-
calidad del software, productividad del desarrollador y ma nuevo. Ademis, el desarrollo basado en componentes
coste general del sistema. Sin embargo, es preciso ven- disefia componentes nuevos que se basan en 10s requi-
cer muchas dificultades antes de que el modelo de pro- sitos personalizados de un sistema nuevo.
ceso ISBC se utilice ampliamente en la industria. Las tCcnicas de anilisis y disefio de componentes
Ademis de 10s componentes del software, un inge- reutilizables se basan en 10s mismos principios y con-
niero del software puede adquirir toda una gama de ceptos que forman parte de las buenas pricticas de inge-
elementos reutilizables. Entre estos se cuentan las nieria del software. Los cdmponentes reutilizables
representaciones tCcnicas del software (por ejemplo, deberian de disefiarse en el sen0 de un entorno que esta-
especificacion, modelos de arquitectura, disefios y blezca unas estructuras de datos estindar, unos proto-
codigos), documentos, datos de prueba e incluso tare- colos de interfaz y unas arquitecturas de programa para
as relacionadas con 10s procesos (por ejemplo, tCcni- todos 10s dominios de aplicacion.
cas de inspeccion). La ingenieria del software basada en componentes
El proceso ISBC acompafia a dos subprocesos con- hace uso de un modelo de intercambio de datos, herra-
currentes --ingenieria del dominio y desarrollo basado mientas, almacenamiento estructurado y un modelo
en componentes-. El objetivo de la ingenieria del domi- objeto subyacente para construir aplicaciones. El mode-
nio es identificar, construir, catalogar y diseminar un lo de objetos suele ajustarse a uno o rn& estindares de
conjunto de componentes de software en un determi- componentes (por ejemplo, OMGICORBA) que defi-
nado dominio de aplicacion. A continuacion, el desa- nen la forma en que una aplicacion puede acceder a 10s
CAP~TULO
27 I N G E N I E R I A DEL S O F T W A R E B A S A D A EN C O M P O N E N T E S
objetos reutilizables. Los esquemas de clasificaci6n La economia de reutilizacion del software se abar-
capacitan a1 desarrollador para hallar y recuperar corn- ca con una linica pregunta: ~ E rentable
s construir
ponentes reutilizables y se ajustan a un modelo que iden- menos y reutilizar mAs? En general, la respuesta es
tifica conceptos, contenidos y contextos. La clasificacion {{si>>,
per0 un planificador de proyectos de software
enumerada, la clasificacion de facetas, y la clasifica- debe considerar 10s costes no triviales asociados a la
ci6n de valores de atributos son representativas de adaptation e integracion de 10s componentes reutili-
muchos esquemas de clasificacion de componentes. zables.
[ADL95] Adler, R.M., {{EngineeringStandards for Compo- [HUT881 Hutchinson, J.W., y P.G. Hindley, {{APreliminary
nent Software,,, Computer, vol. 28, n." 3, Marzo de 1995, Study of Large Scale Software Reuse)),Software Enginee-
pp. 68-77. , ring Journal, vol. 3, n.' 5, 1998, pp. 208-212.
[BAS941 Basili, V.R., L.C. Briand y W.M. Thomas, {{Domain [LIM94] Lim, W.C., {{Effectsof Reuse on Quality, Producti-
Analysis for the Reuse of Software Development Expe- IEEE Software, Septiembre de 1994,
vity, and Economics>>,
riences),, Proc. Of the 1 9 ' ~Annual Software Engineering pp. 23-30.
Workshop, NASAIGSFC, Greenbelt, MD, Diciembre de [LIA93] Liao, H., y F. Wang, {{SoftwareReuse Based on a
1994. Large Object-Oriented Library)),ACM Software Enginee-
[BEL95] Bellinzona, R., M.G. Gugini y B. Pernici, {{Reusing ring Notes, vol. 18, n." 1, Enero de 1993, pp. 74-80.
Specifications in 00 Applications>>,IEEE Software, Mar- [LIN95] Linthicum, D.S., {{ComponentDevelopment (a spe-
zo de 1995, pp. 65-75. cial feature),,, Application Development Trends, Junio de
[BIN931 Binder, R., <<Designfor Reuse is for Real>>,
Ameri- 1995, pp. 57-78.
can Programmer, vol. 6, n." 8, Agosto de 1993, pp. 33- [MCM95] McMahon, P.E., <<Pattern-Based
Architecture: Brid-
37. ging Software Reuse and Cost Management,,, Crosstalk,
[BR096] Brown, A.W., y K.C. Wallnau, <{Engineeringof vol. 8,n."3,Marzode 1995,pp. 10-16.
Component Based Systems),, Component-Based Soft- [ORF96] Orfali, R., D. Harkey y J. Edwards, The Essential
ware Engineering, IEEE Computer Society Press, 1996, Distributed Objects Survival Guide, Wiley, 1996.
pp. 7-15.
[PRI87] Prieto-Diaz, R., {{DomainAnalysis for Reusabi-
[CHR95] Christensen, S.R., <<SoftwareReuse Initiatives at lity>>,Proc. COMPSAC '87, Tokyo, Octubre de 1987,
Lockheed>>,Crosstalk, vol. 8, n." 5, Mayo de 1995, pp. 26- pp. 23-29.
31. [PRI93] Prieto-Diaz, R., {{Issuesand Experiences in Software
[CLE95] Clemens, P.C., <<FromSubroutines to Subsystems: Reuse>>,American Programmer, vol. 6, n." 8, Agosto de
Component-Based Software Development>>, American 1993, pp. 10-18.
Programmer, vol. 8, n.' 11, Noviembre de 1995. [POL941 Pollak, W., y M. Rissman, c<StructuralModels and
[DEV95] Devanbu, P. et al., {{Analyticaland Empirical Eva- Patterned Architectures>>,Computer, vol. 27, n.' 8, Agos-
luation of Software Reuse Metrics,,, Technical Report, to de 1994, pp. 67-68.
Computer Science Department, University of Maryland, [STA94] Staringer,W., {{ConstructingApplications from Reu-
Agosto de 1995. sable Components>>, IEEE Software, Septiembre de 1994,
[FRA94] Frakes, W.B., y T.P. Pole, <{AnEmpirical Study of pp. 61-68.
Representation Methods for Reusable Software Compo- [TRA90] Tracz, W., <<WhereDoes Reuse Start?,,, Proc. Rea-
IEEE Trans. Software Engineering, vol. 20, n.' 8,
nents>>, lities ofReuse Workshop, Syracuse University CASE Cen-
Agosto de 1994, pp. 617-630. ter, Enero de 1990.
[HAR98] Harmon, P., {{Navigatingthe Distributed Compo- [TRA95] Tracz, W., {{ThirdInternational Conference on Soft-
nents Landscape,,, Cutter IT Journal, vol. 11, n." 2, ware Reuse-Summary>>, ACM Software Engineering Notes,
Diciembre de 1998, pp. 4-1 1. vol. 20, n." 2, Abril de 1995, pp. 21-22.
[HEN951 Henry, E., y B. Faller, <<LargeScale Industrial [WHI95] Whittle, B., <<Modelsand Languages for Compo-
Reuse to Reduce Cost and Cycle Time)),IEEE Software, nent Description and Reuse>>,ACM Software Engineering
Septiembre de 1995, pp. 47-53. Notes, vol. 20, n.' 2, Abril de 1995, pp. 76-89.
[H0091] Hooper, J.W., y R.O. Chester, Software Reuse: Gui- [YOU981 Yourdon, E. (ed.), {<DistributedObjects,,, Cutter IT
delines and Methods, Plenum Press, 1991. Journal, vol. 11, n."2, Diciembre de 1998.
INGENIERIA DEL SOFTWARE. UN ENFOQUE P R A C T I C O
27.1. Uno de 10s obsticulos principales de la reutilizaci6n con- 27.7. Desarrolle un modelo estructural sencillo para un domi-
siste en hacer que 10s desarrolladores de software consideren la nio de aplicaci6n que le asigne su instructor, o bien uno con el
reutilizaci6n de componentes ya existentes, en lugar de volver c u d este familiarizado.
a inventar otros nuevos. (jDespuCs de todo, es divertido cons-
truir cosas!) Sugiera tres o cuatro formas distintas en que una 27.8. ~ Q u Ces un punto de estructura?
organizaci6n de software pueda proporcionar incentivos para 27.9. Obtenga informaci6n de 10s esthdares m k recientes de
que 10s ingenieros de software utilicen la reutilizaci6n. ~ Q u C CORBA, COM o de JavaBeans y prepare un trabajo de 3 a 5
tecnologias deberian de estar implantadas para apoyar ese esfuer- paginas que trate 10s puntos m8s destacables. Obtenga infor-
zo de reutilizacibn? macion de una herramienta de distribuci6n de solicitudes de
27.2. Aunque 10s componentes de software son 10s ccelemen- objetos e ilustre en que esa herramienta se ajusta a1 estindar.
tom reutilizables m k obvios, se pueden reutilizar muchas otras 27.10. Desarrolle una clasificaci6n enumerada para un dominio
entidades producidas como p a t e de la ingenieria del software. de aplicaci6n que le asigne su instructor o para uno con el cual
Tenga en consideraci6n 10s planes de proyecto y las estimacio- est6 familiarizado.
nes de costes. iC6m0 se pueden reutilizar y c u d es el benefi-
cio de hacerlo? 27.11. Desarrolle un esquema de clasificaci6n por facetas para
27.3. Lleve a cabo una pequeiia investigaci6n acerca de la inge- un dominio de aplicaci6n que le asigne su instructor o bien para
niena de dominios, y detalle algo mks el modelo de procesos uno con el cual estC familiarizado.
esbozado en la Figura 27.1. Identifique las tareas necesarias para 27.12. Investigue en la literatura para conseguir datos recientes
el andisis de dominios y para el desarrollo de arquitecturas de de calidad y productividad que apoyen la utilization. Presente
software. esos datos a1 resto de la clase.
27.4. iEn quC sentido son iguales las funciones de caracteriza-
cion para 10s dominios de aplicaciones y 10s esquemas de cla- 27.13. Se estima que un sistema orientado a objetos requiere
sificaci6n de componentes? iEn que sentido son distintas? 320 objetos para su finalization. Ademk, se estima que es posi-
ble adquirir 190 objetos procedentes de un dep6sito ya exis-
27.5. Desarrolle un conjunto de caracteristicas del dominio para tente. i C u d es el aprovechamiento de reutilizaci6n? Suponga
sistemas de informacion que Sean relevantes para el procesa- que 10s objetos nuevos cuestan 260.000 pts., y que se necesitan
miento de datos de alumnos de una Universidad. 156.000 pts. para adaptar un objeto y 104.000 pts. para inte-
27.6. Desarrolle un conjunto de caracteristicasdel dominio que grarlo. ~ C U esA el coste estimado del sistema? iCu81 es el valor
Sean relevantes para el software de publication y autoedici6n. de Rb?
Durante 10s dltimos aiios se han ~ublicadolibros sobre el de mktodos cuantitativos para valorar 10s beneficios de la reu-
desarrollo basado en componentes y la reutilizacion de com- tilizaci6n del software.
ponentes. Allen, Frost y Yourdon (Component-Based Develop- Durante 10s liltimos aiios se han publicado docenas de libros
ment for Enterprise Systems: Applying the Select Perspective, que describen 10s mismos estindares basados en componentes
Cambridge University Press, 1998) abarca todo el proceso de de la industria, per0 tambiCn tienen en consideraci6n muchos
ISBC mediante el uso de UML (Capitulos 21 y 22) bashdose topicos importantes de la ISBC. A continuation se muestra un
en el enfoque del modelado. Los libros de Lim (Managing Sof- muestreo del estudio de 10s tres esthdares:
ware Reuse: A Comprehensive Guide to Strategically Reengi-
CORBA
neering the Organization for Reusable Components,
Prentice-Hall, 1998), Coulange (Software Reuse, Spriger Ver- Doss, G.M., CORBA Networking Java, Wordware
lag, 1998), Reifer (Practical Software Reuse, Wiley, 1997), Publishing, 1999.
Jacobson, Griss y Jonsson (Software Reuse: Architecture Pro- Hoque, R., CORBA for Real Programmers, Academic
cess and Organizationfor Business Success, Addison-Wesley, Press/Morgan Kaufmann, 1999.
1997) afronta muchos temas de ISBC. Fowler (Analysis Pat- Siegel, J., CORBA 3 Fundamentals and Programming,
terns: Reusable Object Models, Addison-Wesley, 1996) consi- Wiley, 1999.
dera la aplicaci6n de patrones arquitect6nicosdentro del proceso Slama, D., J. Garbis y P. Russell, Enterprise CORBA, Pren-
de ISBC y proporciona muchos ejemplos litiles. Tracz (Con- tice-Hall, 1999.
fessions of a Used Program Salesman: Institutionalizing Soft- COM
ware Reuse, Addison-Wesley, 1995) presenta un estudio algunas
veces desenfadado y muy util de 10s temas asociados con la cre- Box, D.K., T. Ewald y C. Sells, Effective Ways to Impro-
acidn de una cultura de reutilizaci6n. ve Your COM and MTS-Based Applications, Addison-Wes-
Leach (Software Reuse: Methods, Models and Costs, ley, 1999.
McGraw-Hill, 1997) proporciona un anilisis detallado de 10s Kirtland, M., Designing Component-Based Applications,
estudios de costes asociados con la ISBC y con la reutilizaci6n. Microsoft Press, 1999.
Poulin (Measuring Software Reuse: Principles, Practices, and Muchas compaiiias aplican una combinacion de esthdares
Economic Models, Addison-Wesley, 1996) sugiere un numero de componentes. Los libros de Geraghty et al. (COM-CORBA
CAPfTULO 27 INGENIER~ADEL SOFTWARE BASADA EN COMPONENTES
Interoperability, Prentice-Hall, 1999), Pritchard (COM and Valesky, T.C., Enterprise JavaBeans: Developing Com-
CORBA Side by Side: Architectures, Strategies, and Imple- ponent-Based Distributed Applications, Addison-Wesley, 1999.
mentations, Addsion-Wesley, 1999) y Rosen et al. (Integrating Vogel, A., y M. Rangarao, Programming with Enterprise
CORBA and COMApplications, Wiley, 1999) tienen en consi- JavaBeans, JTS and OTS, Wiley, 1999.
deracidn 10s temas asociados con la utilizaci6n de CORBA y En Internet esta disponible una gran variedad de fuentes
COM como base para el desarrollo basado en componentes. de informaci6n sobre la ingenieria del software basada en
JavaBeans componentes. Una lista actualizada de referencias en la red
Asbury, S., y S.R. Weiner, Developing Java Enterprise que son relevantes para la ISBC se puede encontrar en la direc-
Applications, Wiley, 1999. ci6n http://www.pressman5.com
INGENIER~A DEL SOFTWARE
DEL COMERCIO ELECTR~NICO
CLIENTE/SERVIDOR
Palabras c l a v e
A
finales de siglo, el desarrollo de una nueva generaci6n de mriquinas herramientas capa-
arquitedura ces de soportar fuertes tolerancias dieron poder a 10s ingenieros que disefiaban un pro-
estratificada ........496 ceso nuevo de fabricaci6n llamado producci6n en masa. Antes de la llegada de esta
clientes y servidores .492 tecnologia avanzada de mhquinas herramientas, no se podian soportar fuertes tolerancias. Pero
comercio eledrhico.. 499 con esta tecnologia se podian construir piezas intercambiables y fricilmente ensamblables -
componentes.. ......509 la piedra angular de la producci6n en masa-.
CORBA .............511 Cuando se va a desarrollar un sistema basado en computadora, un ingeniero de software se
ve restringido por las limitaciones de las tecnologias existentes y potenciado cuando las tec-
diseiio arquitect6nico. 51 3
nologias nuevas proporcionan capacidades que no estaban disponibles para las generaciones
diseiio debaser anteriores de ingenieros. La evolution de las arquitecturas distribuidas de computadora ha capa-
de datos. .......... .51 4 citado a 10s ingenieros de sistemas y del software para desarrollar nuevos enfoques sobre c6mo
distniuciin de datos .515 se estructura el trabajo y c6mo se procesa la informaci6n dentro de una empresa.
distribuci6n Las nuevas estructuras de las organizaciones y 10s nuevos enfoques de proceso de informaci6n
de funciones ........510 (por ejemplo: tecnologias intranet e Internet, sistemas de apoyo a las decisiones, software de gru-
opciones de po, e imigenes) representan una salida radical de las primeras tecnologias basadas en minicom-
configuration. ...... .509 putadoras o en mainframes. Las nuevas arquitecturas de computadora han proporcionado la tecnologia
ORB ...............511 que ha hecho posible que las empresas vuelvan a disefiar sus procesos de negocio (Capitulo 30).
prototolo.. .........497 En este capitulo, examinaremos una arquitectura dominante para el proceso de informaci6n
prueba .............516 -10s sistemas cliente/servidor (CIS) dentro del context0 de 10s sistemas de comercio e l e c t 6
dstemas distniuidos. 492 nico-. Los sistemas cliente/servidor han evolucionado junto con 10s avances de la informliti-
ca personal, en la ingenieria del software basada en componentes, con las nuevas tecnologias
rof tware intermedio
(middleware) .......494
de almacenaniiento, comunicaci6n mejorada a travCs de redes, y tecnologia de bases de datos
mejoradas. El objetivo de este capitulo' es presentar una visi6n global y breve de 10s sistemas
cliente/servidor con un Cnfasis especial en 10s temas de la ingenieria del software que deben de
afrontarse cuando se analizan, disefian, prueban y se da soporte a dichos sistemas CIS.
;Qu6 es? Las arquitecturas clientelservi- dominante. Puestoque 10s avances t e e lidad del cliente y del servidor dentrodel
dor (US)dominan el horizonte de los sis- nol&jcos (porejemplo,descmollob a a - contextode 10sestimdcnesde integ~aci6n
iemas basados e n computadora. Todo do en componentes,agentes de solicitud de componentesy de la tuquitectura CIS.
existe: desde redes de cajeros autom6- d e objetos, Java) cambian la forma de ;Cud1 es el product0 obtenido? Un
ticos hasta Internet, y esto e s debido a construir 10s sistemas CIS. en su cons- sistema CIS d e alta calidad e s el pro-
que el software que reside en una com- truccibn se debe d e aplicar un proceso ducto de la ingenieria del software C1S.
putadora --el cliente- solicita servi- de ingenieria del software sdlido. Tambibn se producen otros productos
cios ylo datos de otra computadora -1 &Cu&les son 10s pasos? Los pasos que de trabajo de software (tratados ante-
sewidor-. La ingenieria del software 6e siguen en la ingenieria de 10ssiste- riormente en este mismo libro).
clientelservidorcombina principim con- mas CIS son similares a 10sque s e apli- &=ma puedo estm segwo de que lo
vencionales, conceptos y metodos Ira- can durante la ingenierla del software he hecho correctamente? Utili-
tados unieriormente en este libro, con basada en componentes y 00.El mode- mndo las mismas practicas SQA que s e
elementos de la ingenieria del softwa- lo de proceso e s evolutivo, comenzan- aplican en todos 10s procesos de inge-
re basada en componentes y orientada do por la obtencibn de 10srequisites. nierfa del software -]as revisiones t k -
a objetw para crear sistemas CIS.
La hncionalidad se usigna a los subsis- nicas formales evaluan 10s modelos de
LQuienlo hace? Los ingenieros de s d t - temas de componentesque se van ausig- m&lisisy disefi-; las revisiones espe-
ware llevan a cabo el andisis, diseiio, nar despues o Lien a1 clienteo aI servidor cializadas consideran 10s ternas aso-
implementacibn y prueba de estos sis- de la arquitectura US. El diseiio se cen- ciados a la integracibn decomponentes
temas. Ira en la integraci6nde loscomponentes y a1 software intermedio (middleware),
;Por q u b es importanfe? El impact0 de existentes y en la creacibn d e compo- y las pruebas se aplican para desvelar
los sistemas CIS en 10s negocios, el nentes nuevos. La implementacibn y las errores a1 nivel d e componentes, sub-
comercio, el gobierno y la ciencia e s pruebas luchan por ejercitar la funciona- sistema, cliente y servidor.
I Parte d e este capitulo se ha adaptado a partir del material de cursos desarrollado porJohn Porter para el Client/Server Curri-
culum ofrecido e n la Facultad d e Ingenieria BE1 d e la Univenidad d e Fairfield. Se ha obtenido permiso para sit utilizacih
491
Los ultimos diez aiios han sido testigos de avances masi- datos que contienen las computadoras que componen el
vos en las ireas de computacibn. La primera es que el sistema. En lugar de tener que reproducir 10s datos en
hardware se ha ido abaratando cada vez mis, y a su vez todas las computadoras se pueden distribuir por un
se ha ido haciendo mis potente: las computadoras de pequefio numero de computadoras. Un sistema distribuido
sobremesa hoy en dia tienen la potencia que poseian 10s tambiCn proporciona acceso a servicios especializados
mainframes hace algunos aiios. La segunda Area es la de que quizb no se requieran muy frecuentemente, y que se
las comunicaciones; avances tales como 10s sistemas de puedan centralizar en una computadora del sistema.
comunicaci6n via satklite y 10s sistemas de telCfonos digi-
tales significa que ahora es posible conectar econ6mica-
mente y eficientemente con otros sistemas informiticos
separados fisicamente. Esto ha llevado al concept0 de un
sistema de computaci6n distribuido. Dicho sistema con-
siste en un ndmero de computadoras que e s t h conecta-
das y que llevan a cab0 diferentes funciones. Existen
muchas razones por las que tales sistemas se han hecho
populares :
Tolerancia a fallos. Un sistema distribuido se puede
Rendimiento. El rendimiento de muchos tipos de disefiar de forma que tolere 10s fallos tanto del hardware
sistemas distribuidos se puede incrementar afiadiendo como del software. Por ejemplo, se pueden utilizar varias
simplemente mis computadoras. Normalmente esta es computadoras que lleven a cab0 la misma tarea en un
una opci6n rnis sencilla y rnis barata que mejorar un sistema distribuido. Si una de las computadoras fun-
procesador en un mainframe. Los sistemas tipicos en cionaba mal, entonces una de sus hermanas puede
donde se puede lograr este increment0 en el rendimiento hacerse cargo de su trabajo. Una base de datos de una
son aquellos en donde las computadoras distribuidas computadora se puede reproducir en otras computado-
llevan a cab0 mucho proceso, y en donde la relaci6n tra- ras de forma que si la computadora original tiene un ma1
bajo de comunicaciones y proceso es bajo. funcionamiento, 10s usuarios que solicitan la base de
Comparticion de recursos. Un sistema distribuido datos son capaces de acceder a las bases de datos repro-
permite a sus usuarios acceder a grandes cantidades de ducidas.
28.2.1. Clientes y servidores poca potencia para comunicarse con el central. Los dos
El prop6sito de esta secci6n es introducir tanto la idea - problemas mis serios son la dificultad de mejorar y de
de cliente como la de servidor. Estos son 10s bloques copiar con interfaces IGU modemas. A medida que las
basicos de construcci6n de un sistema distribuido y, de aplicaciones van siendo m b grandes, la carga de una main-
esta manera, cuando se describa el diseiio y el desarro- frame comun llega al punto en que tarnbikn necesita mejo-
110 de dichos sistemas, sera necesario tener conocimiento rar y normalrnente con hardware de procesarniento nuevo,
de sus funciones y de su capacidad. memoria o almacenarniento de archivos. Mejorar dichas
Un servidor es una computadora que lleva a cab0 computadoras es m b ficil que antes; sin embargo, pue-
un servicio que normalmente requiere mucha poten- de resultar un proceso moderadarnente dificil y car0 - e s
cia de procesamiento. Un cliente es una computadora ciertamente rnis car0 y rnis dificil que aiiadir un servidor
que solicita 10s servicios que proporciona uno o mis nuevo basado en PC a un conjunto de computadoras con-
servidores y que tambiCn lleva a cab0 algdn tip0 de figuradas como clientes y servidores-. El segundo pro-
procesamiento por si mismo. Esta forma de organiza- blema es hacerse con interfaces IGU modemas. Para
ci6n de computadoras es totalmente diferente a 10s dos ordenar a una computadora que visualice incluso una pan-
modelos que dominaron 10s aiios ochenta y principios talla relativamente primitiva relacionada, digamos, con
de 10s noventa. unos cuantos botones y una barra de desplazamiento de
El primer modelo se conoce como procesarniento cen- la misma, conlleva tanto trifico en las lineas de comuni-
tral (host).En este modelo de organizaci6n todo el pro- caci6n que un sistema podria colapsarse ficilmente con
cesamiento que se necesitaba para una organizaci6n se 10s datos que se utilizan para configurar y mantener una
llevaba a cab0 por una computadora grande -normal- serie de interfaces basadas en IGUs.
mente una mainframe- mientras que 10s usuarios El segundo modelo de computation es en donde hay
emplean sencillas terminales informiticas o PCs de muy un grupo de computadoras actuando como servidores,
CAPfTULO 28 I N G E N I E R I A DEL S O F T W A R E D E L C O M E R C I O E L E C T R ~ N I C OC L I E N T E I S E R V I D O R
per0 poseen poco procesamiento que llevar a cabo. Nor- bre de cuenta, nombre del titular de la cuenta, saldo
malmente estos terminales poco inteligentes actuarian actual de la cuenta y limite de descubierto de la cuenta.
como servidores de archivos o servidores de impresi6n Una de las caracteristicas de las bases de datos que inva-
para un nlimero de PCs potentes o minicomputadoras lidan la utilizaci6n de 10s servidores de archivos es que
que llevarian a cab0 el procesamiento y estarian conec- 10s archivos que se crean son enormes y ralentizan el
tados a una red de k e a local. Las computadoras clien- trafico si se transfirieran en bloque a1 cliente. Afortu-
te solicitarian servicios a gran escala, como es obtener nadamente, para la gran mayoria de aplicaciones no se
un archivo, llevando a cab0 entonces el procesamiento requiere dicha transferencia; por ejemplo en una apli-
de dicho archivo. De nuevo, esto conduce a problemas caci6n bancaria las consultas tipicas que se realizarian
con el trafico en donde, por ejemplo, la transmisi6n de en una base de datos bancaria serian las siguientes:
archivos grandes a un numero de clientes que requie- Encontrar las cuentas de 10s clientes que tienen un
ren simultineamente estos archivos hace que el tiempo descubierto mayor de 2.000 pts.
de respuesta de la red vaya tan lento como una tortuga.
Encontrar el saldo de todas las cuentas del titular
tQue es la informitica John Smith.
cliente/servidor? Encontrar todas las 6rdenes regulares del cliente Jean
La computaci6n cliente/servidor es un intento de equi- Smith.
librar el proceso de una red hasta que se comparta la Encontrar el total de las transacciones que se reali-
potencia de procesamiento entre computadoras que lle- zaron ayer en la sucursal de Manchester Picadilly.
van a cab0 servicios especializados tales como acceder Actualmente una base de datos bancaria tipica ten-
a bases de datos (servidores), y aquellos que llevan a cab0 d r i millones de registros, sin embargo, las consultas
tareas tales como la visualizaci6n IGU que es mis ade- anteriores conllevarian transferir datos a un cliente que
cuado para el punto final dentro de la red. Por ejemplo, seria solamente una fraccion muy pequeiia del tamaiio.
permite que las computadoras se ajusten a tareas espe- En un entorno de bases de datos cliente/servidor 10s
cializadas tales como el procesamiento debases de datos clientes envian las consultas a la base de datos, nor-
en donde se utilizan hardware y software de prop6sito malmente utilizando alguna IGU. Estas consultas se
especial para proporcionar un procesamiento ripido de envian a1 servidor en un lenguaje llamado SQL (Len-
la base de datos comparado con el hardware que se guaje de Consultas Estructurado). El servidor de bases
encuentra en las mainframes que tienen que enfrentarse de datos lee el c6digo SQL, lo interpreta y, a continua-
con una gran gama de aplicaciones. ci6n, lo visualiza en alglin objeto HCI tal como una caja
de texto. El punto clave aqui es que el servidor de bases
28.2.2. Categorias d e servidores de datos lleva a cab0 todo el procesamiento, donde el
cliente lleva a cab0 10s procesos de extraer una consul-
Ya se ha desarrollado una gran variedad de servidores. ta de alglin objeto de entrada, tal como un campo de tex-
La siguiente lista ampliada se ha extraido de [ORF99]: to, enviar la consulta y visualizar la respuesta del
Servidores de archivos. Un servidor de archivos pro- servidor de la base de datos en alglin objeto de salida,
porciona archivos para clientes. Estos servidores se utili- tal como un cuadro de desplazamiento.
zan todavia en algunas aplicaciones donde 10s clientes Servidores de software de grupo. Software de
requieren un procesamiento complicado fuera del rango grupo es el tirmino que se utiliza para describir el soft-
normal de procesamiento que se puede encontrar en bases ware que organiza el trabajo de un grupo de trabajado-
de datos comerciales. Por ejemplo, una aplicaci6n que res. Un sistema de software de grupo normalmente
requiera el almacenamiento y acceso a dibujos ticnicos, ofrece las siguientes funciones:
digamos que para una empresa de fabricaci61-1,utilizaria
un servidor de archivos para almacenar y proporcionar Gestionar la agenda de 10s individuos de un equipo
10s dibujos a 10s clientes. Tales clientes, por ejemplo, serian de trabajo.
utilizados por ingenieros quienes llevarian a cab0 opera- Gestionar las reuniones para un equipo, por ejem-
ciones con dibujos, operaciones que serian demasiado plo, asegurar que todos 10s miembros de un equipo
caras de soportar, utilizando una computadora central que tienen que asistir a una reuni6n estin libres
potente. Si 10s archivos solicitados no fueran demasiado cuando se vaya a celebrar.
grandes y no estuvieran compartidos por un nlimero tan Gestionar el flujo de trabajo, donde las tareas se dis-
grande de usuarios, un servidor de archivos seria una forma tribuyen a 10s miembros del equipo y el sistema de
excelente de almacenar y procesar archivos. software de grupo proporciona informaci6n sobre la
Servidores de bases de datos. Los servidores de finalizaci6n de la tarea y envia un recordatorio al per-
bases de datos son computadoras que almacenan gran- sonal que lleva a cab0 las tareas.
des colecciones de datos estructurados. Por ejemplo, un Gestionar el correo electr6nic0, por ejemplo, organi-
banco utilizaria un servidor de bases de datos para alma- zar el envio de un correo especifico a 10s miembros
cenar registros de clientes que contienen datos del nom- de un equipo una vez terminada una tarea especifica.
Un semidor de software de grupo guarda 10s datos informar a las computadoras cliente que ya ha finali-
que dan soporte a estas tareas, por ejemplo, almacena zado una petici6n de impresi6n en particular.
las listas de correos electr6nicos y permite que 10s usua- Servidores de aplicaciones. Un semidor de aplica-
rios del sistema de software de grupo se comuniquen ciones se dedica a una aplicaci6n 6nica. Tales semidores
con 61, notifichndoles, por ejemplo, que se terminado suelen escribirse utilizando un lenguaje tal como Java o
una tarea o proporcionandoles una fecha de reuni6n en C++. Un ejemplo tipico del semidor que se utiliza en el
la que ciertos empleados puedan acudir. dibujo de un fabricante de aviones que gestionaba las ver-
siones diferentes de dibujos producidos por el personal
iQue es un servidor Web? tCcnico iria dirigido a algun proceso de fabricaci6n.
28.2.3. Software intermedio (middleware)

Servidores Web. Los documentos Web se almace- Hasta el momento probablemente ya tenga la impresidn
nan como phginas en una computadora conocida como de que la comunicaci6n entre cliente y semidor es direc-
semidor Web. Cuando se utiliza un navegador (brow- ta. Desgraciadamente, esto no es verdad: normalmente
ser) para ver las piginas Web normalmente pincha sobre existe por lo menos una capa de software entre ellos.
un enlace en un documento Web existente. Esto dara Esta capa se llama software intermedio (middleware).
como resultado un mensaje que se enviara a1 semidor Como ejemplo de software intermedio consideremos la
Web que contiene la pagina. Este semidor respondera Figura 28.1. ~ s t muestra
a la comunicaci6n entre un
entonces enviando una pagina a su computadora, donde cliente ejecutando un navegador como Internet Explo-
el navegador pueda visualizarlo. De esta manera 10s ser- rer y un semidor Web.
vidores Web act6an como una forma de servidor de
archivos, administrando archivos relativamente peque-
fios a usuarios, quienes entonces utilizan un navegador El software
intermedio
para examinar estas phginas. Para comunicarse con un deterrnina
navegador Web, un cliente que utiliza un navegador esta El navegador donde esta
solicita la pagina
haciendo uso a su vez de un protocolo conocido como una pagina Web y la solicita
HTTP.
Servidores de correo. Un servidor de correo ges-
tiona el envio y recepci6n de correo de un grupo de usua- Navegador
-
al servidor
Servidor
-
Web
rios. Para este semicio normalmente se utiliza un PC de
e-
rango medio. Existen varios protocolos para el correo
La pagina Web La pagina
-
electr6nico. Un semidor de correo estar6 especializado es devuelta es enviada
en utilizar solo uno de ellos. al navegador al software
interrnedio
Servidores de objetos. Uno de 10s desarrollos mhs por el servido
excitantes en la informatics distribuida durante 10s 6lti-
mos cinco afios ha sido el avance realizado, tanto por FIGURA 28.7. Software intermedio y servidor Web.
parte de 10s desarrolladores, como por parte de 10s inves-
tigadores, para proporcionar objetos distribuidos. Estos Aqui el software intermedio que se encuentra entre
son objetos que se pueden almacenar en una computa- el semidor Web y el cliente que ejecuta el navegador
dora, normalmente un semidor, con clientes capaces de Web intercepta las peticiones que proceden del nave-
activar la funcionalidad del objeto enviando mensajes gador. Si se hace una petici6n para una pagina Web
a1 objeto, 10s cuales se corresponden con mCtodos defi- entonces determina la localizaci6n del documento
nidos por la clase de objeto. Esta tecnologia liberarh Web y envia una petici6n para esa pagina. El semidor
finalmente a 10s programadores de la programaci6n de responde a la petici6n y devuelve la phgina a1 software
bajo nivel basada en protocolos requerida para acceder intermedio, quien la dirige a1 navegador que la visuali-
a otras computadoras de una red. En efecto, esto per- zara en la pantalla del monitor que utiliza el cliente.
mite que el programador trate a 10s objetos a distancia Existen dos categonas de software intermedio: el soft-
como si estuvieran en su computadora local. Un semi- ware intermedio general y el software intermedio de
dor que contiene objetos que pueden accederse a dis- semicios. El primer0 es el que esth asociado a 10s ser-
tancia se conoce como semidor de objetos. vicios generales que requieren todos 10s clientes y ser-
vidores. El software tipico que se utiliza como tal es:
Servidores de impresion. Los semidores de impre-
si6n dan semicio a las solicitudes de un cliente remoto. El software para llevar a cab0 comunicaciones utili-
Estos semidores tienden a basarse en PCs bastante bara- zando el protocolo TCPDP y otros protocolos de red.
tos, y llevan a cab0 las funciones limitadas de poner en El software del sistema operativo que, por ejemplo,
cola de espera las peticiones de impresibn, ordenar a la mantiene un almacenamiento distribuido de archi-
impresora que lleve a cab0 el proceso de impresi6n e vos. Este es una colecci6n de archivos que se espar-
El prop6sito de esta secci6n es explorar la idea de una ~ E relativamente
s esthtica la base de datos en lo que
arquitectura estratificada para una aplicaci6n clientelser- se refiere a predecir un crecimiento pequeiio de
vidor y se limita a describir las arquitecturas populares tamafio y estructura?
de dos y de tres capas. Una arquitectura de dos capas de ~ E esthtica
s la base del usuario?
una aplicaci6n clientelservidor consiste en una capa de existe en requisitos fijos o no hay muchas posibili-
16gica y presentacihn, y otra capa de bases de datos. La dades de cambio durante la vida del sistema?
primera tiene que ver con presentar a1 usuario conjuntos
~Necesitarael sistema un mantenimiento minimo?
de objetos visuales y llevar a cab0 el procesamiento que
requieren 10s datos producidos por el usuario y 10s devuel- Aunque algunas de estas cuestiones van enlazadas
tos por el servidor. Por ejemplo, esta capa contendria el (10s cambios en 10s requisitos dan lugar a las tareas de
c6digo que monitoriza las acciones de pulsar botones, el mantenimiento), se trata de un cantidad bien amplia de
envio de datos a1 servidor, y cualquier chlculo local nece- preguntas que deberian de tenerse en cuenta antes de
sario para la aplicaci6n. Estos datos se pueden almace- adoptar una arquitectura de dos capas.
nar en una base de datos convencional, en un archivo
simple o pueden ser incluso 10s datos que esthn en la
memoria. Esta capa reside en el servidor.
Normalmente las arquitecturas de dos capas se uti-
lizan cuando se requiere mucho procesamiento de datos. Cuando una aplicodon implica un procesamiento
La arquitectura del servidor Web de navegador es un considerable el enfoque de dos capos cado vez
buen ejemplo de una arquitectura de dos capas. El nave- es mds difkil de implementar.
gador del cliente reside en la capa de 16gica y presen-
taci6n mientras que 10s datos del servidor Web-las Cuando una aplicaci6n implica un procesamiento con-
phginas Web- residen en las capa de la base de datos. siderable, entonces comienzan a surgir problemas con
Otro ejemplo de aplicaci6n en donde se emplearia nor- la arquitectura de dos capas, particularmente aquellas
malmente una arquitectura de dos capas es una aplica- aplicaciones que experimentan cambios de funcionali-
ci6n simple de entrada de datos, donde las funciones dad a medida que se van utilizando. TambiCn, una arqui-
principales que ejercitan 10s usuarios es introducir 10s tectura de dos capas, donde no hay muchas partes de
datos de formas muy diversas en una base de datos c6digo de procesamiento unidas a acciones tales como
remota; por ejemplo, una aplicaci6n de entrada de datos pulsaci6n de botones o introducci6n de texto en un cam-
de un sistema bancario, donde las cuentas de usuarios po de texto, esth altamente orientada a sucesos especifi-
nuevos se teclean en una base de datos central de cuen- cos y no a 10s datos subyacentes de una aplicacibn, y de
tas. El cliente de esta aplicacion residirh en la capa 16gi- aqui que la reutilizaci6n sea algo complicado.
ca y de presentaci6n mientras que la base de datos de
Capa , Capa del servidor , Capa de bases
cuentas residiria en la capa de base de datos. la aplicacion de datos
Las dos aplicaciones descritas anteriormente mues-
tran la caracteristica principal que distingue a las apli-
1 -0
caciones de capas de otras aplicaciones que emplean
mhs capas por el hecho de que la cantidad de procesa-
miento necesario es muy pequeiia. Por ejemplo, en la Objetos
aplicaci6n de validaci6n de datos, el unico procesa- negocios
t
miento requerido del lado del cliente seria la validaci6n

de datos que se llevaria a cab0 sin recurrir a la base de Alguna base
datos de las cuentas. Un ejemplo seria comprobar que de datos
el nombre de un cliente no contiene ningdn digito. El
resto de la validaci6n se haria en la capa de la base de
datos y conllevaria comprobar la base de datos para ase-
0
1
'
Clientes
gurar que no se aiiadieron registros duplicados de clien-
tes a la base de datos. Reece [REE97] ha documentado FIGURA 28.3. Una arquitectura de tres capas.
10s criterios que se deberian utilizar cuando considera-
mos adoptar una arquitectura cliente servidor de dos La Figura 28.3 muestra una arquitectura de tres capas.
capas. Estos son 10s criterios: Se compone de una capa de presentacibn, una capa de
procesamiento (o capa de servidor de solicitudes) y una
~Utilizala aplicaci6n una dnica base de datos?
capa de base de datos. La capa de presentaci6n es la res-
iSe localiza el procesador de base de datos en una ponsable de la presentaci6n visual de la aplicaci6n, la
sola CPU? capa de la base de datos contiene 10s datos de la apli-
CAPtTULO 28 I N G E N I E R ~ ADEL SOFTWARE DEL COMERCIO E L E C T R ~ N I C OCLIENTEISERVIDOR
caci6n y la capa de procesamiento es la responsable del tra el servidor de 10s clientes. La localizaci6n de esta
procesamiento que tiene lugar en la aplicaci6n. Por ejem- capa no le resta valor a las ventajas que proporciona una
plo, en una aplicaci6n bancaria el c6digo de la capa de arquitectura de tres capas:
presentaci6n se relacionaria simplemente con la moni- En primer lugar, la arquitectura de tres capas permite
torizaci6n de sucesos y con el envio de datos a la capa aislar a la tecnologia que implementa la base de datos,
de procesamiento. Esta capa intermedia contendria 10s de forma que sea ficil cambiar esta tecnologia. Por
objetos que se corresponden con las entidades de la apli- ejemplo, una aplicacidn podria utilizar en primer
caci6n; por ejemplo, en una aplicaci6n bancaria 10s obje- lugar la tecnologia relacional para la capa de base de
tos tipicos serian 10s bancos, el cliente, las cuentas y las datos; si una base de datos basada en objetos fun-
transacciones. ciona tan eficientemente como la tecnologia rela-
La capa final seria la capa de la base de datos. ~ s t a cional que se pudiera entonces integrar fhcilmente,
estaria compuesta de 10s archivos que contienen 10s todo lo que se necesitaria cambiar serian 10s mCto-
datos de la aplicaci6n. La capa intermedia es la que dos para comunicarse con la base de datos.
conlleva capacidad de mantenimiento y de reutiliza- Utiliza mucho c6digo lejos del cliente. Los clien-
ci6n. Contendri objetos definidos por clases reutili- tes que contienen mucho c6digo se conocen como
zables que se pueden utilizar una y otra vez en otras clientes pesados (gruesos). En un entorno en donde
aplicaciones. Estos objetos se suelen llamar objetos de se suele necesitar alg6n cambio, estos clientes
negocios y son 10s que contienen la gama normal de pesados pueden convertirse en una pesadilla de
constructores, mCtodos para establecer y obtener varia- mantenimiento. Cada vez que se requiere un cam-
bles, mCtodos que llevan a cab0 cilculos y mCtodos, bio la organizaci6n tiene que asegurarse de que se
normalmente privados, en comunicaci6n con la capa ha descargado el c6digo correct0 a cada cliente.
de la base de datos. La capa de presentaci6n enviari Con una capa intermedia una gran parte del c6digo
mensajes a 10s objetos de esta capa intermedia, la cual de una aplicaci6n clientelservidor reside en un lugar
o bien responder5 entonces directamente o mantendri (o en un nGmero reducido pequeiio de lugares si se
un diilogo con la capa de la base de datos, la cual pro- utilizan servidores de copias de seguridad) y 10s
porcionari 10s datos que se mandarian como respues- cambios de mantenimiento ocurren de forma cen-
ta a la capa de presentaci6n. tralizada.
El lugar donde va a residir la capa intermedia depen- La idea de las tres capas encaja con las pricticas
de de la decisi6n sobre el diseiio. Podria residir en el
orientadas a objetos de hoy en dia: todo el procesa-
servidor, que contiene la capa de base de datos; por otro
miento tiene lugar por medio de 10s mensajes que se
lado, podna residir en un servidor separado. La deci-
envian a 10s objetos y no mediante trozos de c6digo
si6n sobre d6nde colocar esta capa dependeri de las
asociados a cada objeto en la capa de presentaci6n
decisiones sobre disefio que se apliquen, dependiendo
que se esti ejecutando.
de factores tales como la cantidad de carga que tiene un
servidor en particular y la distancia a la que se encuen-
Tipo Codigo Suma de Existe uno diferencio entre el software intermedio

(8bits) (8bits) verificacion
(middleware) y lo cop0 del servidor de la aplicocibn.
Parametros
- Lo que merece la pena destacar, llegado este pun-
to, es que existe una diferencia entre la capa inter-
Datos media del servidor de la aplicaci6n y el software
-
intermedio (middleware). Mientras que el primer0 des-
cribe el software de la aplicaci6n que media entre el
cliente y el servidor, el segundo se reserva para el soft-
FIGURA 28.4. El forrnato del protocolo ICMP. ware de sistemas.
En este capitulo hasta ahora se ha utilizado el tCrmi- 28.4.1. El concept0 II
no protocol0 sin proporcionar realmente mucho deta- Con objeto de describir 10 que es exactamente un pro-
lle. El prop6sito de esta seccidn es proporcionar este tocol~,utilizarC un pequeiio ejemplo: el de un cliente
detalle. que proporciona servicios bancarios para casa, permi-
tiendo, por ejemplo, que un cliente consulte una cuen- 28.4.2. IP e ICMP
.ta cuyos datos residen en el servidor. Supongamos que IP,el protocolo que ejecuta Internet es un protocolo muy
el cliente se comunica con el servidor que utiliza una complicado, y una description completa estaria fuera
serie de mensajes que distinguen las funciones requeri- del ambit0 de este libro, ya que la descnpcih de este
das por el cliente, y que tambiCn se comunica con otros protocolo necesitaria un libro entero que le hiciera jus-
datos requeridos por el servidor. ticia. Debido a esto me centrarC en una parte pequefia
Por ejemplo, el cliente puede ejercer la funci6n de del protocolo, aunque importante, conocida como ICMP
consultar un saldo de cuenta tecleando un n6mero de (Internet Control Message Protocol). Protocolo de men-
cuenta en un cuadro de texto y pulsando el b o t h del sajes de control de Internet que se utiliza para monito-
rat6n el cual enviarh el mensaje a1 servidor. Este men- rizar 10s errores y problemas de la red que utiliza IP. En
saje podria ser de la forma la Figura 28.4 se muestra el formato de 10s mensajes
que forman parte del protocolo.
El campo Tipo especifica el tip0 de error que ha ocu-
donde CS (Consulta del Saldo) especifica que el usua- rrido. Por ejemplo, este campo indicaria que el desti-
no ha consultado una cuenta para obtener el saldo con no de un mensaje era inalcanzable. El campo C6digo
el numero de cuenta que identifica la cuenta. El servi- contiene la information secundaria que se utiliza para
dor entonces recibira este mensaje y devolver6 el sal- proporcionar una interpretacih mas detallada del cam-
do; el mensaje que el servidor envia podria tener el po Tipo. El campo de Suma de verijicacibn es utiliza-
formato do por el software para comprobar que la transmision
S*<Cantidad del Saldo> del mensaje ICMP se ha llevado a cab0 correctamen-
te. Los dos campos restantes contienen 10s datos que
El cliente interpretarh este mensaje y visualizara el permitiran a1 software de comprobacion localizar el
saldo en algun elemento de salida. problema originado.
Si el cliente quisiera consultar 10s numeros de cuen- ICPM es utilizado por IP para llevar a cab0 el pro-
tas de todas las cuentas con las que 61 o ella esti aso- cesamiento basico de errores y tambiCn para incremen-
ciado, el mensaje entonces podria ser de la forma tar la eficacia de la red. Por ejemplo, se podria utilizar
para llevar a cab0 el cambio de direccion del mensaje
si una computadora, que se encontrara en el camino ini-
donde CC (Consulta de Cuenta) solicita las cuentas, y cia1 del mensaje, descubriera una ruta mejor.
en cuya funcion ya no se requieren mas datos. El ser-
vidor podria responder con un mensaje que comenza-
ra con (Informacion de Cuenta) y que estuviera 28.4.3. POP3
formado por numeros terminados con asteriscos. Por POP3 ( Post Office Protocol version 3) (Protocolo de
ejemplo, Oficina de Correos version 3) se utiliza para el envio y
la recepcion de correo electronico. Es un protocolo sen-
cillo y es ampliamente utilizado. En esta seccion reali-
10s mensajes que he descrito forman un protocolo sen- zarC un estudio de algunas de sus caracteristicas.
cillo que comunica funcionalidad y datos entre dos enti-
dades (un cliente y un servidor) en la red.
~ Q u es
L un protocolo? POP3 es un protocolo robusto y muy sencillo.
Uti1;celo todo lo posible m6s que o m protocolos.
Un punto importante acerca de 10s protocolos es que Existen varios protocolos de correo, entre 10s que se
siempre que se utiliza un mecanismo para la comuni- incluyen SMTP, IMAP y diferentes versiones de POP.
caci6n en una red existe un protocolo. Por ejemplo, 10s Probablemente el mas complicado de estos sea IMAP,
objetos distribuidos son objetos que se encuentran en el cual incluye funciones secundarias y un conjunto de
localizaciones remotas en una red, y es mediante la uti- mensajes mas rico que POP.
lizacidn de un protocolo la manera en que se envian 10s El propdsito de POP es posibilitar a 10s usuarios
mensajes, aunque la programacion de estos objetos estC acceder a1 correo remoto y consta de una serie de
a un nivel superior por debajo de la programaci6n y comandos que permiten a 10s programas de usuario
oculta a1 programador. interactuar con un servidor de correo POP. El esthn-
El protocolo que he descrito se asemeja a un jugue- dar POP3 describe un grupo de mensajes posibles que
te y tambiCn a un protocolo de aplicaciones. Merece pueden enviarse a1 servidor de correo POP3 y el for-
la pena entrar en el estudio de algunos protocolos mas mato de 10s mensajes es devuelto por el servidor. La
reales que estCn asociados a 10s servicios de nivel de Tabla 28.1 muestra un subconjunto pequeiio del pro-
sistema. t o c o l ~POP3.
C A P ~ T U L O28 I N G E N I E R I A DEL S O F T W A R E D E L C O M E R C I O E L E C T R ~ N I C OC L I E N T E I S E R V I D O R
protocolo HTTP y seran interpretados por el servidor

Mensaje Sign$cado que llevara a cab0 operaciones tales como devolver una
USER Informa a1 servidor sobre un usua- pagina Web o procesar algun formulario que estC inser-
rio en particular que esta intentan- tad0 dentro de una pagina.
do enviar un correo A continuation, se muestra un ejemplo que ilustra lo
PASS Proporciona una contraseiia para descrito anteriormente
un usuario en particular
STAT Pregunta a1 servidor cuantos men-
sajes hay esperando para ser leidos Este es el mensaje que envia un navegador cuando
DELE Borra un mensaje quiere visualizar una pagina en particular. Este mensa-
RETR Recupera un mensaje je se puede haber generado de diferentes maneras. Por
ejemplo, el usuario puede haber pinchado con el rat6n
TABLA 28.1. Un subconjunto del POP3. en un determinado enlace en un documento Web que
sefiala a la pagina solicitada. La linea anterior contiene
la palabra reservada GET, la cual especificaba que se
iba a devolver un archivo, y especificaba tambiCn el
28.4.4. El protocolo HTTP nombre del archivo que sigue a1 carhcter '1' (index.htm1)
Este es uno de 10s protocolos mas importantes que se y la versi6n del protocolo que utiliza el navegador que
utilizan dentro de Internet; es el protocolo que rige va a enviar el mensaje.
la comunicaci6n entre un cliente que utiliza un nave- El servidor tambiCn utilizara el protocolo HTTP para
gador Web tal como Internet Explorer y un servidor enviar mensajes de vuelta a1 cliente. Por ejemplo, el
Web. mensaje
La funci6n principal de un sewidor Web es poner a
disposici6n de clientes paginas Web. Estos clientes uti-
lizaran un navegador que les conectara a1 puerto 80 en significa que el servidor, que est8 utilizando HTTP ver-
el sewidor Web; este es el puerto estandar que se utili- si6n 1.1, ha procesado con Cxito la petici6n iniciada por
za para tales servidores. El navegador que est8 utili- el cliente. El c6digo 200 en este caso es un ejemplo del
zando el cliente enviara mensajes definidos por el codigo de estado que indica Cxito.
28.5.1. ~ Q u ees el comercio electronico? ese articulo. Normalmente la compafiia de subastas

especificaria un period0 de oferta para asi darla por
Para ilustrar la apariencia de un sistema distribuido exa- finalizada.
minaremos un ejemplo tomado de un k e a de aplicaci6n
conocida como comercio electr6nico. En un sentido Sistemas que proporcionan algun servicio basado en
amplio, el tCrmino cccomercio electr6nico~(Ecommer- red para usuarios. Probablemente 10s m8s conocidos
ce) se puede definir como la aplicaci6n de la tecnologia son 10s que ofrecen cuentas de correo gratis, donde
de sistemas dstribuidos que apoya las operaciones comer- 10s ingresos de dicha empresa probablemente pro-
ciales. A continuaci6n, se detallan algunos de dichos sis- cedan de la publicidad en las paginas Web que se uti-
temas: lizan para ese sitio Web. Estas son compafiias que
Sistemas para vender algunos articulos o servicios mediante un honorario monitorizan su sitio Web y le
envian un mensaje, normalmente por correo elec-
utilizando Intemet, donde 10s clientes interactuan
tr6nico o mediante un buscador si han detectado un
con el sistema que utiliza navegadores. Entre 10s
problema, como el ma1 funcionamiento del servidor
sistemas tipicos de comercio electr6nico de esta
que se utiliza para el sitio Web.
categoria se incluyen 10s que venden libros, ropa
y CDs. Sistemas que proporcionan servicios de asesora-
miento. Los sistemas tipicos de este tip0 son 10s que
~ Q u ees el comercio procesan una descripci6n de articulos, como un CD,
electrinico? para 10s que estableceran el mejor precio, despuCs
Sistemas para simular alguna actividad comercial en de haber explorado un numero de sistemas de venta
tiempo real utilizando tecnologia de red. Un buen en la red.
ejemplo de este tipo de sistemas es una subasta en la Sistemas intemos que el cliente no ve, per0 que dan
red.Un sistema de subasta tipico solicitaria articu- soporte a mas actividades comerciales convenciona-
10s a 10s usuarios de Intemet, ubicaria 10s datos en les. Por ejemplo, un sistema que apoya el suministro
una pagina Web y entonces comenzaria la oferta para de mercancias a un comerciante minorista de la calle.
Sistemas de publicidad. Muchos de 10s ingresos del realiza el pedido de un libro, a continuation se le
. comercio electr6nico proceden de la publicidad en solicitan 10s datos de la tarjeta de crCdito. Algunos
linea. Muchas piginas Web asociadas a las aplica- sistemas de pedidos suelen quedarse con 10s datos
ciones de comercio electr6nico contendrin peque- de las tarjetas de forma permanente de manera que
iios espacios publicitarios conocidos como banners. no se requiere que el cliente proporcione 10s datos
Estos anuncios se pueden <<pinchar,,,conduciendo cada vez que haga un pedido.
asi a1 usuario del navegador a un sitio Web el cual La provisidn de servicios de seguimiento. Estos ser-
normalmente vende algun producto o sewicio. Los vicios posibilitaran a1 cliente seguir con el proceso
sistemas de publicidad son una forma particular de de una compra utilizando su navegador. Las piginas
sistemas de comercio electrdnico que llevan a cab0 Web personalizadas para el cliente describirhn el
funciones tales como vender un banner (espacio desarrollo de un pedido: si ya se ha enviado, si esta
publicitario), monitorizando el Cxito de estos anun- esperando porque el libro no esta en stock, y cuil es
cios y la administraci6n del pago de 10s honorarios la fecha en la que se espera enviar el pedido.
de publicidad.
El procesamiento de revisiones. Un sewicio ofrecido
Estas forman un conjunto tipico de aplicaciones por 10s sitios de ventas de libros mhs sofisticados y
que estin bajo el <<banner*del comercio electr6nico. es el que proporciona el medio por el que 10s clien-
En la parte restante de esta secci6n observaremos una tes pueden escribir revisiones de 10s libros a com-
aplicaci6n tipica de comercio electr6nico que admi- prar. Estas revisiones se pueden comunicar a1
nistra la venta de un articulo. Esto es lo que piensa vendedor o bien por correo electr6nico o por una
cualquier persona de una aplicaci6n de comercio pigina Web especializada.
electrdnico, aunque espero que despuCs de leer este
La provisidn de un servicio de conferencia. Un ser-
preambulo este sistema se considerari s610 como un
vicio de conferencia capacita a un grupo de clientes
tip0 de sistema.
para interactuar entre ellos enviando mensajes a una
conferencia, entendiendo por conferencia algo dedi-
cad0 a un tema especifico tal como, por ejemplo, la
CLAVE liltima novela de Robert Goddard o el estado de la
Elcomercio electrbnico no es solamente ficci6n criminal. Tales servicios no proporcionan
un comercio minorista de red. ingresos directarnente a un vendedor de libros en red.
Sin embargo, si pueden proporcionar informaci6n
28.5.2. Un sistema tipico de comercio electronico util sobre las tendencias en las compras de libros de
las que el personal de ventas de una librena pueden
Con objeto de entender la naturaleza de 10s sistemas sacar provecho.
clientelservidor, merece la pena examinar un ejemplo La provisidn de noticias o boletines para clientes.
de una de las keas del comercio electr6nico. Es un sis- Un servicio popular que se encuentra en muchos
tema para administrar las ventas de una gran libreria sitios de comercio electr6nico dedicados a la venta
que tenga una funcionalidad similar a la que exhiben de un producto es el de proporcionar informaci6n
grandes librerias como Blackwells o la filial britinica por medio del correo electr6nico. Para el sitio de ven-
de Amazon. Las funciones tipicas que un sistema como tas de libros que se esta describiendo en esta secci6n
Cste proporciona son las siguientes: se incluirian mensajes tal como textos de revisiones,
La provisidn de servicios de Catdlogo. Cada libro ofertas especiales o mensajes relacionados con un
que venda una compaiiia estari en catilogo y la pedido especifico, tal como el hecho de haberse des-
pagina Web proporcionari la descripci6n de ese libro. pachado.
La informaci6n tipica que se proporciona sobre un Control y administracidn del stock. Este es un con-
libro es el nombre, autor, editorial y precio. junto de funciones que estin ocultas para el usuario
La provisidn de servicios de bhqueda. El usuario de del sistema de ventas de libros per0 que son vitales
dicho sistema necesitari navegar por el cathlogo para para el sistema. Estas funciones se asocian a las acti-
decidir si va a comprar un libro. Esta navegaci6n se vidades mundanas, tales como hacer pedidos de
podna realizar de muchas maneras diferentes: desde libros, hacer el seguimiento de 10s stocks y reorde-
navegar secuencialmente desde el primer libro que nar y proporcionar informaci6n de ventas a1 perso-
aparece, hasta navegar utilizando consultas de blis- nal responsable de 10s pedidos.
queda tal como el titulo de un libro o su ISBN. Informes financieros. Estos son de nuevo un con-
La provisidn de servicios de pedidos. Cuando un junto de funciones que e s t h ocultas ante 10s ojos del
cliente de un sitio de comercio electr6nico quiere usuario del sistema de ventas de libros per0 que son
comprar un libro, el sistema le proporcionari algun vitales. Proporcionan la informaci6n para la gesti6n
servicio para poderlo hacer y, normalrnente, mediante financiera de la compaiiia que ejecuta el sistema y
tarjetas de crCdito. Generalmente cuando el cliente proporciona la informaci6n de datos tales como las
CAPfTULO 28 I N G E N l E R f A D E L S O F T W A R E DEL C O M E R C I O E L E C T R 6 N I C O C L I E N T E I S E R V I D O R
ventas dia a dia, anuales y datos rnhs complejos tales

como la efectividad de ciertas estrategias de ventas
respecto a las ventas de 10s libros que eran el tema
de estas estrategias.
Cliente
Web 1 1 Sewidores
Web
de seguridad
Se puede decir que estas son un conjunto tipico de
corren
funciones mostradas por el comercio electr6nico dedi-
cad0 a vender productos; en nuestro caso el produc-
to son libros, aunque no hay ninguna razdn para no Sewidores
haber elegido, por ejemplo, ropa, CDs, antigiiedades, Sewidor de bases
de correo de datos
etc., aunque las funciones del sistema variarian un
poco; por ejemplo, en un sitio especializado en ven-
der ropa no habria raz6n por la que implementar las
funciones que esthn conectadas con las revisiones de
productos.
Antes de estudiar la arquitectura de dicho sistema
merece la pena hacer hincapiC en el desarrollo de tales
sistemas. Durante el nivel de anhlisis hay poca diferen-
- #
'
de conferencia
cia entre el sistema de comercio electr6nico y un siste-

ma rnhs convencional, tal como el que depende de 10s
Sewidor de rnonitorizacion I/
operadores telef6nicos para anotar 10s pedidos y donde
el cathlogo se imprime y se envia a 10s clientes de la FIGURA 28.5. La arquitectura.
forma convencional. Ciertamente existirhn funciones
que no estarhn dentro de tales sistemas convencionales, Un servidor de correo. Este sewidor mantendrh lis-
como por ejemplo 10s que tienen que ver con las revi- tas de correos de clientes que, por ejemplo, han indi-
siones; sin embargo, la mayor pate de las funciones son cad0 que desean estar puntualmente informados de
muy similares, y es posible que se lleven a cab0 de for- las ofertas especiales y 10s libros nuevos que se e s t h
ma diferente; por ejemplo, el proceso de obtener 10s publicando. Este sewidor se comunicarh con el ser-
datos de las tarjetas de crCdito seria llevado a cab0 por vidor Web principal, ya que 10s clientes proporcio-
un operador y no por una phgina Web. narhn sus direcciones de correo y 10s sewicios que
quieren, interactuando con las phginas Web que visi-
tan. Esto ilustra un tema importante acerca de 10s
clientes y 10s servidores: no hay una designacidn
fuerte o rhpida de lo que es un cliente o un sewidor
En el nivel de ondlisis hoy rnuy poco diferencio enire 10s de un sistema de comercio electr6nico: esto depende
sisternos de cornercio elecironico y 10s convencionoles. realmente de la relaci6n entre las entidades implica-
das. Por ejemplo, el sewidor Web act6a como un ser-
En la Figura 28.5 se muestra la arquitectura tCcnica vidor para 10s clientes que ejecutan un navegador,
de un sistema de libros tipico. Los componentes de este per0 act6a como un cliente con el sewidor de correo
sistema son: a1 cual le proporciona direcciones de correo para sus
Clientes Web. Estos ejecutarhn un navegador que listas de correo.
interact6a con el sistema y que principalmente lleva Un servidor de conferencia. Este es un sewidor que
a cab0 funciones de navegar sobre cathlogos y hacer administra conferencias. Lee en las contribuciones
pedidos. a la conferencia, visualiza estas contribuciones en
Un servidor Web. Este sewidor contendrh todas las una ventana asociada a una conferencia y borra cual-
phginas Web a las que el cliente irh accediendo y se quier entidad que no estC actualizada.
comunicarh con el resto del sistema para proporcio- Servidores de bases de datos. Son sewidores que
nar informacih tal como la disponibilidad de un administran las bases de datos asociadas a la apli-
libro. Normalmente existirh mhs de un sewidor Web caci6n de comercio. Aqui se incluye la base de datos
disponible para enfrentarse con un fallo del hard- principal de libros, la cual contiene datos de cada
ware. Si el sewidor Web estaba funcionando y se libro; la base de datos de pedidos que contiene datos
viene abajo, dicho suceso seria extremadamente serio de 10s pedidos que han realizado 10s clientes, todos
y se corresponderia con las puertas de una libreria 10s que no se han cumplido tanto anteriores como
convencional cerrada a 10s clientes impidiendo su actuales; la base de datos de clientes que contiene
entrada. Debido a las cajas registradoras, 10s siste- datos de 10s clientes de 10s vendedores de libros; y
mas de correo electn5nico que tienden a ser muy cd- una base de datos que contiene datos de las ventas
ticos para un negocio tendrh hardware reproducido, de libros concretos; esta base de datos es particu-
incluyendo reproducciones de sewidores de Web. larmente util para muchos vendedores de libros en
la red, puesto que les permite publicar las listas de dor Web frontal que se comunica con un sistema ser-
10s libros mhs vendidos junto con las ofertas espe- vidor no cliente. Este sistema sewidor no cliente es
ciales de esos libros. En muchos sistemas de comer- el que lleva existiendo ya desde hace alglin tiempo
cio electrhico estas bases de datos son imple- y se utilizaba para un procesamiento mis conven-
mentadas en varios servidores de bases de datos cional como es el de tomar pedidos por telCfono.
especializados que son duplicados: tales bases de Los servidores de bases de datos se mantendran
datos son vitales para el funcionamiento de una com- actualizados por medio de un software de sistemas
pafiia de comercio electronico: si el sewidor de bases que detecta cuando se va a aplicar una transaccion
de datos funcionaba ma1 y no existen servidores a una base de datos: primer0 aplica la transacci6n a
duplicados, ocurria algo muy serio, ya que no ten- la base de datos que se esti utilizando en ese
drian ingresos y 10s vendedores en red obtendrian momento y, a continuacion, la aplica a todas las
una reputacih muy pobre. Un punto importante a bases de datos duplicadas.
tener en cuenta sobre esta parte del sistema es que Un servidor de nzonitorizaci6n. Este es el servidor
no hay razon para que una tecnologia anterior, tal que se utiliza para monitorizar la ejecucion del sis-
como un mainfranze que ejecuta una monitorizacion tema. Es utilizado por un administrador del sistema
de transacciones se pueda utilizar para funciones de para comprobar el funcionamiento correct0 del sis-
bases de datos; en realidad muchos de 10s sistemas tema y tambiCn para ajustar el sistema de manera que
de comercio electr6nico se componen de un sewi- se archive un rendimiento optimo.
Existen varias tecnologias basadas en red que se utili- te de comunicar datos en un sistema distribuido que eje-
zan para las aplicaciones de comercio electronico. Antes cuta el protocolo TCP/IP.
de describirlas merece la pena decir que muchas tecno-
logias antiguas todavia se utilizan para este tip0 de apli- 28.6.2. Objetos distribuidos
cacion; el mejor ejemplo es el uso de la tecnologia de
bases de datos relacionales para proporcionar almace- iQue es un objeto
nes de datos a gran escala. distribuido?
Un objeto distribuido es aquel que reside en una com-

putadora, normalmente un sewidor, en un sistema dis-
tribuido. Otras computadoras del sistema pueden enviar
Muchos tecnologios antiguos todovio se utilizon
mensajes a este objeto como si residiera en su propia
poro oplicociones de comercio electrbnico.
computadora. El software del sistema se har6 cargo de
varias funciones: localizar el objeto, recoger 10s datos
que se requieren para el mensaje y enviarlos a travks
28.6.1. Conexiones (sockets) del medio de comunicacion que se utiliza para el siste-
ma. Los objetos distribuidos representan un nivel m6s
Un socket es un tip0 de conducto que se utiliza para
alto de abstraccion que las conexiones (sockets):a par-
conectarse a una computadora conectada a una red y
te de alglin c6digo de inicializacion, el programador no
basada en TCP/IP. El socket se configura de tal manera
es consciente del hecho de que el objeto residc cn otra
que 10s datos pueden ser bajados desde el cliente y
computadora. Actualmente existen tres tecnologias de
devueltos a1 mismo. Los lenguajes de programaci6n
objetos distribuidos en pugna:
modernos, como Java, proporcionan sewicios de alta
calidad por medio de 10s cuales un socket se puede RMI. Esta es la tecnologia asociada a1 lenguaje de
conectar mediante ccprogramacion>>a una computado- programaci6n de Java. Es un enfoque Java puro en
ra cuya direcci6n de Internet sea conocida y donde 10s el que solo 10s programas escritos en ese lenguaje se
datos se puedan enviar por este conducto. La progra- pueden comunicar con un objeto RMI distribuido.
maci6n necesaria para esto normalmente no es m& com- Es la tecnologia ideal para sistemas cerrados de Java;
plicada que la programaci6n que se requiere para escribir estos sistemas generalmente tendran pocas conexio-
y leer datos de un archivo. Los sockets son una imple- nes o ninguna con otros sistemas.
mentacion a bajo nivel de la conectividad; dentro de las DCOM. Esta es una tecnologia desarrollada por la
utilizaciones tipicas de un socket e s t h las aplicaciones compafiia Microsoft y permite que programas escri-
de conferencia, donde una entrada a una conferencia se tos en lenguajes tales como Visual Basic y Visual
enviaria a1 sewidor de conferencia que utiliza una con- J++ (la variedad de Java desarrollada por Microsoft)
figuration de sockets en el servidor. Los sockets son un se comuniquen con 10s objetos que estlin en compu-
mecanismo de bajo nivel, per0 una forma muy eficien- tadoras remotas.
CAPfTULO 28 I N G E N I E R I A D E L S O F T W A R E DEL C O M E R C I O E L E C T R O N I C 0 C L I E N T E I S E R V I D O R
CORBA. Esta es la tecnologia de objetos distribui- el formulario, y lleva a cab0 la funcionalidad asociada
dos mas sofisticada. Fue desarrollada por un con- a1 formulario; por ejemplo, recuperando 10s datos soli-
sorcio de compafiias informaticas, clientes y citados en el formulario. La programacion CGI se pue-
compafiias de software. La caracteristica mas impor- de llevar a cab0 en varios lenguajes de programacion,
tante del enfoque CORBA es que es multilenguaje, aunque el lenguaje seleccionado ha sido Perl, lenguaje
donde 10s programadores pueden utilizar diferentes de procesamiento de cadenas, existen otros entre 10s que
lenguajes de programacion para enviar mensajes a se incluyen, por ejemplo, Java y C++, que contienen 10s
objetos CORBA: las interfaces CORBA existen para servicios para el procesamiento CGI. Recientemente 10s
lenguajes tales como Java, FORTRAN, LISP, Ada y que desarrollan Java han proporcionado a 10s progra-
Smalltalk. CORBA esta a1 principio de su desarro- madores el servicio de utilizar Java para este tip0 de
110, sin embargo, amenaza con convertirse en la tec- programacion que utiliza la tecnologia conocida como
nologia dominante para objetos distribuidos. servlets. Estos trozos pequefios de codigo Java son inser-
La principal ventaja de 10s objetos distribuidos sobre tados en un servidor de Web y se ejecutan cuando ocu-
la de 10s sockets es el hecho de que como abarca ente- rre un suceso, como enviar un formulario. Los servlets
ramente el paradigma de orientacion a objetos se pue- ofrecen un alto grado de portabilidad sobre otros len-
de emplear 10s mismos mCtodos de analisis y disefio que guajes de programacion.
se utilizan para la tecnologia de objetos convencional.
28.6.5. Contenido ejecutable
28.6.3. Espacios Este es el tCrmino que se aplica a la inclusion en una pigi-
Esta es una tecnologia que se encuentra en un nivel de na Web de un programa que se ejecuta cuando la pagina
abstraction incluso mas alto que 10s objetos distribui- es recuperada por un navegador. Este programa puede
dos. Fue desarrollada por David Gelemter, un profesor llevar a cab0 un numero diverso de funciones entre las
de la Universidad de Yale. La tecnologia de espacios que se incluyen la animation y la presentacion de un for-
concibe un sistema distribuido en base a un gran alma- mulario a1 usuario para insertar datos. Existen varias tec-
cCn de datos persistentes donde las computadoras de un nologias que proporcionan servicios para insertar
sistema distribuido puede leer o escribir. No concibe el contenido ejecutable en una pagina Web. Aqui se inclu-
sistema distribuido como una serie de programas que yen applets, Active X y Javascript. Un applet es un pro-
pasan mensajes a 10s demas utilizando un mecanismo grams escrito en Java que interachia con una pigina Web.
como 10s sockets, o como una serie de objetos distri- Lo importante a sefialar de esta tecnologia es que es por-
buidos que se comunican utilizando mCtodos. Por el tatil: el cddigo Java se puede mover facilmente desde un
contrario, la tecnologia de espacios conlleva procesos sistema operativo a otro, per0 es potencialmente insegu-
como escribir, leer o copiar datos a partir de un alma- ro. La raz6n de por quC 10s applets son inseguros es que
cCn persistente. Un programador que utiliza esta tecno- se pueden utilizar como medio de transmision de virus y
logia no se preocupa por detalles como donde estan otros mecanismos de acceso a una computadora. Cuan-
almacenados 10s datos, quC proceso va a recoger 10s do una pagina de navegador que contiene un applet es
datos y cuando 10s va a recoger. descargada por un navegador, es lo mismo que cargar un
Esta tecnologia se encuentra solo a1 principio, aun- programa en la computadora cliente que ejecuta el nave-
que las implementaciones llevan ya disponibles duran- gador. Afortunadamente 10s disefiadores de Java desa-
te algun tiempo para lenguajes como C y C++; sin rrollaron el lenguaje de tal manera que es inmensamente
embargo, la irnplementacion de la tecnologia dentro de dificil escribir applets que provoquen violaciones en la
Java como Javaspaces deberia asegurar que cada vez se seguridad. Desafortunadamente la solucion que se adop-
utilizara mas para las aplicaciones principales. t6 evita acceder a 10s recursos de una computadora clien-
te o ejecutar otro programa en la computadora. Aunque
se han hecho muchas mejoras en 10s applets que permi-
28.6.4. CGI ten un acceso limitado, el modelo principal del uso de
applets esta restringido a este mod0 de ejecucion.
iPara que se utiliza CGI? Active X es otra tecnologia de contenido ejecutable
que fue desarrollada por Microsoft. De nuevo se trata
El tCrmino CGI (Common Gateway Interface) signifi- de un codigo de programa insertado en una pagina Web;
ca Interfaz comun de pasarela. Es la interfaz con el ser- la diferencia principal entre esta tecnologia y 10s applets
vidor Web a1 cual se puede acceder mediante 10s es el hecho de que estos trozos de codigo se pueden
programas que se ejecutan en el servidor. Gran parte de escribir en diferentes lenguajes como Visual Basic y
la interactividad asociada a las paginas Web se imple- C++. Esta forma de contenido ejecutable tambien sufre
menta programando el acceso a la CGI. Por ejemplo, de posibles problemas de seguridad.
cuando el usuario de un navegador accede a una pigi- Javascript es un lenguaje de programacion interpre-
na que contiene un formulario, Cste lo rellena y lo envia tad0 y sencillo que se inserta directamente en una pagi-
a1 servidor Web, programa que accede a1 CGI, procesa na Web. Se diferencia de las soluciones de Active X y
503
applets en que el c6digo fuente de cualquier programa Paquetes de seguridad. Estos son paquetes que moni-
de guiones de Java se integra en una pigina Web en vez torizan el trhfico dentro de un sistema distribuido y
de en el c6digo de objetos como ocurre con 10s applets avisan a1 administrador de sistemas de la aparici6n
y Active X . Javascript es un lenguaje sencillo que se de cualquier violaci6n posible en la seguridad. Por
utiliza para una programaci6n relativamente a bajo nivel. ejemplo, el hecho de que alguien intente entrar en un
sistema con una contrasefia sin reconocer.
28.6.6. Paquetes clientelservidor
Monitores de transacciones. Estos son paquetes de
Este tCrmino describe las colecciones de software que software que administran las transacciones que tie-
normalmente llevan a cab0 alg6n tip0 de procesamien- nen lugar dentro de un sistema distribuido y ase-
to de sistemas. A continuaci6n, se muestra un grupo de guran que se devuelvan 10s datos correctos como
ejemplos tipicos de paquetes de software: resultado de una transacci6n y en el orden correcto.
Paquetes de reproduccibn de datos. Este tip0 de soft- Muchas de las funciones de estos monitores tienen
ware realiza una transacci6n en la base de datos y la que ver con asegurar que 10s resultados correctos
aplica a un numero de bases de datos reproducidas, se devuelvan incluso en el entorno en donde
evitando asi acceder a estas bases de datos hasta que podrian aparecer errores de hardware o de trans-
estCn todas en sincronizaci6n. misi6n.
Antes de observar algunos de 10s principios del disefio ripidos (y caros). El proceso de asignar tales medios
que se utilizan en el desarrollo de sistemas distribuidos, normalmente tiene lugar despuCs de haber tomado deci-
particularmente de sistemas de comercio electr6nic0, siones sobre la potencia de procesamiento de distribu-
merece la pena reiterar lo que se ha sefialado anterior- ci6n en un sistema y, algunas veces, conlleva unas ligeras
mente: a nivel de anhlisis hay poca diferencia entre un iteraciones a1 final de la fase de diseiio.
sistema distribuido y un sistema local, y se basa en que
el modelo de anhlisis de un sistema no contendrh nin- 28.7.2. Mantenimiento de 10s datos mas usados
g6n dato de diseiio como el hecho de que tres compu- en un almacenamiento rapido
tadoras, y no una solo, estin llevando a cab0 alg6n
Este principio tambiCn es obvio. Requiere que el dise-
procesamiento. Esto significa que el desarrollador de
iiador examine 10s patrones de datos en un sistema y
un sistema distribuido se enfrentarh normalmente con
asegure que 10s datos a 10s que se accede frecuentemente
un modelo de objetos o un modelo funcional similar a1
se guarden en alg6n medio de almacenamiento rfipido.
que se mostr6 en las primeras partes de este libro; esta
descripci6n irh acompafiada de algunos de 10s tipos de En muchos sistemas tales datos pueden constituir no
mis del5 por 100 de 10s datos originales almacenados
computadoras y de hardware de redes que se van a uti-
en el sistema, y de esta manera permite utilizar con fre-
lizar. El proceso de diseiio implica transformar el mode-
cuencia las estrategias que conllevan el almacenamien-
lo de anilisis en alg6n modelo fisico que se implementa
to de estos datos dentro de la memoria principal.
en 10s elementos de hardware del sistema.
28.7.3. Mantenimiento de 10s datos cerca
de donde se utilizan
Este principio de disefio intenta reducir el tiempo que
Recuerde que durante el anblisis existe poca diferencia pasan 10s datos en medios lentos de transmisi6n. Muchos
entre una aplicacibn de comercio electrbnico de estos sistemas son en donde 10s usuarios acceden con
y una convencionol. frecuencia a un subconjunto de datos. Por ejemplo, un
sistema distribuido usado en una aplicaci6n bancaria
Es necesario que el disefiador de sistemas distribui- contendria bases de datos con datos de las cuentas de 10s
dos conozca una serie de principios de disefio. El resto clientes, en donde la mayor parte de las consultas a las
de esta secci6n muestra un esquema de 10s mismos. bases de datos de las sucursales las realizarh 10s clien-
tes de esa sucursal; entonces, si 10s datos de un sistema
bancario se distribuyen a 10s servidores de las sucursa-
28.7.1. Correspondencia del volumen de trans- les, y 10s datos asociados a 10s clientes de esa sucursal
misidn con 10s medios de transmisidn e s t h en esa sucursal, el resto de 10s datos podrian estar
Este es uno de 10s principios mis obvios. Esto signifi- en otros servidores con otras ubicaciones, y cualquier
ca que para un trhfico denso de datos en un sistema dis- consulta que se originara sobre 10s datos se tendria que
tribuido. se deberian utilizar medios de transmisi6n comunicar a travCs de lineas lentas de transmisi6n.
individuales de vacaciones deberian de estar cerca de buido y otro componente. El 6nico gasto que se requie-
10s datos que describen las reservas actuales de ese re para utilizar esta tCcnica es tiempo del procesador y
paquete. Ubicar por separado 10s datos en diferentes ser- la memoria necesaria para llevar a cab0 la compresi6n
vidores asegura que 10s medios de baja transmisi6n y en la computadora del emisor y la descompresi6n en la
muy cargados se cargaran incluso m8s. El disefiador de computadora del receptor.
un sistema distribuido debe asegurarse de que 10s datos
relacionados gracias a1 hecho de que se suelen recupe- 28.7.12. Diseiio para el fallo
rar juntos tendrin que residir lo mis cerca posible, pre-
feriblemente en el mismo servidor, o si no, y no de
manera tan preferible, en servidores conectados a tra- iPor que puede ser
vCs de medios de transmisi6n rapidos tales como 10s catastrofico un fallo de
hardware en un sistema de
medios utilizados en una red de Area local.
comerdo electronico?
28.7.8. Considerar la utilizaci6n de servidores Un fallo de hardware en la mayoria de 10s sistemas de

dedicados a funciones frecuentes comercio electr6nico es una catastrofe: para 10s siste-
Algunas veces se puede lograr un mayor rendimiento mas de ventas en red esto es equivalente a echar el cie-
mediante la utilizaci6n de un servidor de empleo espe- rre a 10s clientes. Una parte importante del proceso de
cifico para una funci6n en particular en lugar de, por disefio es analizar 10s fallos que podrian aparecer en un
ejemplo, un servidor de bases de datos. sistema distribuido y disefiar el sistema con suficiente
redundancia como para que dicho fallo no afecte seria-
mente y, en el mejor de 10s casos, que se pueda redu-
28.7.9. Correspondencia de la tecnologia con las
cir el tiempo de respuesta de ciertas transacciones. Una
exigencias de rendimiento decisi6n normal que suele tomar el disefiador es dupli-
Muchas de las tecnologias que se estudian en este capi- car 10s servidores vitales para el funcionamiento de un
tulo tienen pros y contras, y un factor importante aqui sistema distribuido. Una estrategia en 10s sistemas de
son las demandas de rendimiento de una tecnologia en alta integridad es que un servidor se reproduzca tres
particular. veces y que cada servidor lleve a cab0 la misma tarea
Por ejemplo, como medio de comunicaci6n, las en paralelo. Cada servidor produce un resultado a com-
conexiones (sockets) normalmente son un medio de parar. Si 10s tres servidores aceptan el resultado, Cste
comunicaci6n mucho mis rapido que 10s objetos dis- pasa a cualquier usuario o servidor que lo requiera; si
tribuidos. Cuando el disefiador elige una tecnologia debe uno de 10s servidores no esth de acuerdo, entonces sur-
de tener conocimiento de la transmision y de las cargas ge un problema y el resultado de la mayoria se pasa
de procesamiento que conlleva, y seleccionar una tec- informando a1 administrador de sistemas del posible
nologia que minimice estas cargas. problema. La duplicaci6n de servidores como estrate-
gia de mitigaci6n de fallos puede utilizarse junto con
28.7.10. Empleo del paralelismo todo lo posible el diseho de un sistema para lograr el paralelismo en
las tareas.
Una de las ventajas principales de la tecnologia clien-
telservidor es el hecho de que se pueden afiadir servi-
dores y, hasta cierto punto, elevar el rendimiento del 28.7.13. Minimizar la latencia
sistema. Muchas funciones del comercio electrdnico
pueden beneficiarse de la ejecuci6n que estan llevando Cuando 10s datos fluyen de una computadora a otra en
a cab0 diferentes servidores en paralelo. Esta no es una un sistema distribuido a menudo tiene que atravesar
decision sencilla. Mediante el empleo de varios servi- otras computadoras. Algunas de estas computadoras
dores, el disefiador esti creando la necesidad de que puede que ya tengan unos datos que expidan funciona-
estos servidores se comuniquen, por ejemplo, un semi- lidad; es posible que otras procesen 10s datos de algu-
dor puede que necesite a otro para completar una tarea na manera. El tiempo que tardan las computadoras es
en particular antes de finalizar la suya propia. Esta comu- lo que se conoce como latencia. Un buen diseiio de sis-
nicaci6n puede introducir retrasos y, si el disefiador no tema distribuido es el que minimiza el numero de com-
tiene cuidado, pueden negar 10s avances de rendimien- putadoras intermediarias.
to que se han logrado utilizando el paralelismo.
28.7.14. Epilogo
28.7.11. Utilizaci6n de la compresi6n de datos Este ha sido un estudio breve aunque necesario, y se
todo lo posible han tratado las diferentes estrategias de disefio que se
Se dispone de un grupo de algoritmos que comprimen utilizan en 10s sistemas distribuidos que implementan
datos y que reducen el tiempo que tardan 10s datos en las funciones del comercio electronico. Un punto impor-
transferirse entre un componente de un sistema distri- tante a tener en cuenta antes de abandonar esta secci6n
C A P ~ T U L28
O I N G E N I E R ~ ADEL S O F T W A R E DEL C O M E R C I O E L E C T R ~ N ~ CCOL l E N T E i S E R V I D O R
es que una estrategia puede militar contra otra, mini- de datos duplicadas incrementa la latencia de un siste-
mizar la latencia y duplicar bases de datos pueden ser ma; como consecuencia, el diseiio de sistemas distri-
dos estrategias opuestas: incrementar el numero de bases buidos, mas que otra cosa, es un arte.
El increment0 masivo en la utilization publica de sis- Estas son entonces algunas de las intrusiones que pue-
temas distribuidos ha dado lugar a algunos problemas den tener lugar dentro de un sistema distribuido; estas
graves con la seguridad. Los sistemas distribuidos ante- intrusiones cada vez son mas frecuentes, ya que gran
riores se suelen localizar en un lugar fisico utilizando parte de la transmisi6n en 10s sistemas de comercio elec-
tecnologias tales como redes de area local. Dichos sis- tr6nico ocurren en una Internet publicamente accesible
temas estaban fisicamente aislados de 10s usuarios exter- que utiliza protocolos publicamente disponibles.
nos y como consecuencia la seguridad, aunque es un Una de las tareas mhs importantes del diseiiador de
problema, no era un problema enorme como lo es aho- sistemas distribuidos es diseiiar un sistema con el pro-
ra para 10s sistemas de comercio electr6nico a 10s que p6sito de minimizar la posibilidad de Cxito de las ins-
pueden acceder miembros de usuarios que emplean un trucciones de alto riesgo. Para poder llevarlo a cab0 se
navegador. necesita utilizar una serie de tecnologias. En la siguien-
A continuaci6n, se detallan algunas de las intrusio- te secci6n se hace una relaci6n detallada de estas tec-
nes tipicas en la seguridad que pueden ocurrir: nologias.
Un intruso monitoriza el trhfico de una linea de trans-
misi6n y recoge la informaci6n confidencial que
genera un usuario. Por ejemplo, el intruso podria leer
el nlimero, la fecha de caducidad y el nombre del iQue es la entriptation y
titular de una tarjeta de crCdito. Y, a continuaci61-1, por que es util?
puede utilizar esta informaci6n para realizar pedidos Encriptaci6n es el tCrmino que se utiliza para referirse
en Internet. a1 proceso de transformar datos o texto (texto en claro)
Un intruso podria entrar en un sistema distribuido, para ser ilegible; ademis, deberia resultar virtualmente
acceder a la base de datos y cambiar la informaci6n imposible que un intruso pueda descifrarlo. A conti-
de la misma. Por ejemplo, podria cambiar el balance nuacibn, se detalla el proceso de utilizaci6n de esta tec-
de una cuenta en un sistema bancario en la red. nologia:
1. La computadora emisora transforma el texto en
alguna forma ilegible; este proceso se conoce como
encriptaci6n.
Ahoro que Internet ya se est6 utilizando 2. Los datos encriptados entonces se envian a travCs de
para muchas mas oplicociones, la seguridod lineas de transmisi6n insegura.
se convierte en un problerno importonte.
3. La computadora receptora procesa el texto encrip-
tad0 y lo transforma a su forma original. Este pro-
Un intruso podria leer una transacci6n que pasa por ceso se conoce como desencriptaci6n.
alguna linea de transmisi6n y alterar 10s datos den- Se utilizan dos formas de encriptaci6n. La primera
tro de ella en beneficio propio. Por ejemplo, podria es la encriptaci6n simCtrica, donde un mensaje se trans-
alterar la instrucci6n de un cliente de un sistema ban- forma en una forma encriptada utilizando una cadena
cario en red para transferir 10s datos de una cuenta a conocida como clave: se aplica alguna transformaci6n
otra para que la cuenta del intruso sea la que tiene en el mensaje utilizando la clave. Entonces la clave se
lugar en la transferencia. comunica a1 receptor a travCs de algun medio seguro y
Un ex empleado contrariado de una compaiiia envia es utilizado por el receptor para llevar a cab0 la desen-
un programa a1 sistema distribuido de la compaiiia criptaci6n.
monopolizando el tiempo del procesador del sistema, La encriptaci6n simCtrica es eficiente per0 padece
pasando gradualmente de sewidor a sewidor hasta un problema importante: si un intruso descubre la cla-
que el sistema queda exhausto y acaba parandose. ve, podria descubrir facilmente el mensaje encripta-
Esta es una forma de ataque conocido como dene- do. La encriptaci6n de clave ptiblica es una soluci6n
gacion de ataque a1 sewicio. a este problema, donde se utilizan dos claves de
Un empleado contrariado de una compaiiia envia un encriptaci6n: una conocida como clave publica y otra
programa a un sistema distribuido el cual borra 10s como clave privada. Un usuario que desea recibir men-
archivos importantes del sistema. sajes encriptados publicara su clave publica. Otros
usuarios que deseen comunicarse con el usuario uti- es la que se utiliza normalmente para esto. Conside-
lizarhn esta clave para encriptar cualquier mensaje; remos una forma de llevar a cab0 este proceso: dos
10s mensajes entonces son desencriptados mediante usuarios de computadoras A y B quieren comunicar-
la clave privada cuando 10s recibe el usuario original. se, y A quiere asegurarse de que se est6 comunicando
Esta forma de encriptaci6n tiene la ventaja principal con B. Para poder hacer esto, B necesita tener una cla-
de que la gesti6n de claves es sencilla: la clave pri- ve p6blica y una privada, y tener conocimiento de cu61
vada nunca se envia a nadie. Un intruso que monito- es la clave p6blica. A envia un mensaje a B con un tex-
riza 10s datos encriptados que viajan por alg6n medio to en el que A pide a B una encriptaci6n utilizando su
de transmisi6n es incapaz de decodificar ning6n men- clave privada. Este texto entonces es encriptado por B
saje puesto que no tienen acceso posible a la clave y devuelto a A quien lo descifra utilizando la clave
privada. El inconveniente principal de esta forma de p6blica que B le ha proporcionado. Si el mensaje es el
encriptaci6n es que se necesita una gran cantidad de mismo que el que se envi6, B es entonces quien dice
recursos para llevar a cab0 el proceso de desencrip- que es, pero, si no lo es, B entonces no ha demostra-
taci6n. Debido a esta clave p6blica, 10s sistemas nor- do su identidad. Este esquema comparte todas las ven-
malmente se limitan a envios cortos de texto o a un tajas de cualquier mCtodo de clave p6blica en donde
texto pensado para ser altamente seguro. TambiCn se la clave privada es segura; sin embargo, puede ser ata-
utiliza para la autenticacibn, la cual utiliza una tCcni- cad0 por cualquiera que desee establecer falta de con-
ca conocida como firmas digitales, que se describen fianza entre un emisor y un receptor. Esto se puede
en la secci6n siguiente. hacer alterando el mensaje encriptado que se ha devuel-
La tecnologia principal que se utiliza en Internet to a1 emisor.
para la encriptaci6n simktrica es la capa de sockets
seguros (SSL). Esta es una tecnologia que se utiliza
para encriptar datos confidenciales tales como 10s 28.8.4. Certificaciones digitales
n6meros de las tarjetas de crkdito que viajan desde el
navegador a un servidor Web, o desde una aplicacidn Una certificaci6n digital es un documento electr6nico
a otra. que proporciona a1 usuario un alto de grado de confianza
con una organizaci6n o persona con la que estCn tra-
tando. Se pueden utilizar cuatro tipos de certificacio-
nes:
28.8.2. Funciones d e compendio d e mensajes
Certificaciones de una autoridad de certificacih
Una funci6n de compendio de mensajes es un algorit- Una autoridad de certificaci6n es una organizaci6n
mo que genera un numero grande -normalmente entre que proporciona certificados digitales, tales como
128 y 256 bits de longitud- que representa un com- estas dos organizaciones: Canada Post Corporation
pendio o resumen de 10s caracteres de un mensaje. Tie- y 10s senicios postales de US.
ne la propiedad de que si el mensaje cambia y se vuelve
a aplicar el algoritrno, el numero entonces cambia. Exis- Certificaciones del servidor. Estas certificaciones
ten muchas utilizaciones de las funciones de compen- contienen datos tales como la clave p6blica del ser-
dio de mensajes. Un uso corntin es detectar 10s cambios vidor, el nombre de la organizaci6n que posee el ser-
en un mensaje, por ejemplo, el hecho de que una tran- vidor y la direcci6n del senidor en Internet.
sacci6n financiera se haya modificado en la transmisi6n Certificaciones personales. Estas son las certifica-
con objeto de favorecer a1 que modifica. Antes de enviar ciones asociadas a un individuo. Contendrh infor-
un mensaje se aplica la funci6n de compendio de men- maci6n fisica tal como la direcci6n del individuo
saje y se forma un ncmero grande. El mensaje enton- junto con la informaci6n relacionada con la compu-
ces se envia con el numero aiiadido a1 final. La funci6n tadora como la clave pcblica y la direcci6n de correo
de compendio de mensaje se aplica en el receptor y el electr6nico de la persona.
n6mero resultante se compara con el que se envi6. Si Certijicaciones del editor de software. Estos son cer-
10s dos son iguales el mensaje entonces no se ha modi-
tificados que proporcionan confianza en que el soft-
ficado: si no son iguales el mensaje ha sido modificado
ware ha sido producido por una compafiia de
durante la transmisi6n.
software especifica.
Como ejemplo para el funcionamiento de estas cer-
tificaciones tomemos el de las certificaciones del seni-
28.8.3. Firmas digitales
dor. Un senidor que utiliza la capa de sockets seguros
Una firma digital, como su propio nombre sugiere, es (SSL) debe de tener un certificado SSL. Este certifica-
una forma de que el emisor de un mensaje se pueda do contiene una clave pliblica. Cuando un navegador se
identificar con el receptor de tal manera que el recep- conecta con el senidor se utiliza entonces esta clave
tor pueda confiar en que el mensaje fue enviado real- publica para codificar la interaction inicial entre el ser-
mente por el emisor. La encriptacibn de clave p6blica vidor y el navegador.
CAPfTULO 28 INGENIERIA DEL S O F T W A R E DEL C O M E R C I O E L E C T R 6 N I C O CLIENTEISERVIDOR
28.9.2. Distribuci6n de componentes de software

En lugar de visualizar el software como una aplicaci6n Una vez que se han determinado 10s requisitos bisicos
monolitica que deberi de implementarse en una miqui- de una aplicaci6n clientelsemidor, el ingeniero del soft-
na, el software que es adecuado para una arquitectura ware debe decidir cdmo distribuir 10s componentes de
posee varios componentes distintos que se pueden aso- software descritos en la Secci6n 28.1.1 entre el cliente
ciar a1 cliente o a1 servidor, o se pueden distribuir entre y el semidor. Cuando la mayor parte de la funcionali-
ambas miquinas: dad asociada a cada uno de 10s tres componentes se le
Componente de interaccion con el usuario y pre- asocia a1 semidor, se ha creado un disefio de servidor
sentacion. Este componente implementa todas las fun- pesado (grueso). A la inversa, cuando el cliente imple-
ciones que tipicamente se asocian a una interfaz grifica menta la mayor parte de 10s componentes de interac-
de usuario (IGU). ci6nlpresentacibn con el usuario, de aplicaci6n y de
Componente de aplicacion. Este componente imple- bases de datos, se tiene un diseiio de cliente pesado
menta 10s requisitos definidos en el context0 del domi- (grueso).
nio en el cual funciona la aplicaci6n. Por ejemplo, una Los clientes pesados suelen encontrarse cuando se
aplicaci6n de negocios podria producir toda una garna implementan arquitecturas de semidor de archivo y de
de informes impresos basados en entradas numkricas, semidor de base de datos. En este caso el servidor pro-
cilculos, informaci6n de una base de datos y otros aspec- porciona apoyo para la gesti6n de datos, per0 todo el
tos. Una aplicaci6n de software de grupo podria pro- software de aplicaci6n y de IGU reside en el cliente.
porcionar funciones para hacer posible la comunicaci6n Los servidores pesados son 10s que suelen disefiarse
mediante boletines de anuncios electr6nicos o de correo cuando se implementan sistemas de transacciones y de
electrbnico, y en nuestro caso de estudio esto conlleva- trabajo en grupo. El semidor proporciona el apoyo de
ria la preparaci6n de informes como 10s que describen la aplicaci6n necesario para responder a transacciones
las ventas de libros. En ambos casos, el software de la y comunicaciones que provengan de 10s clientes. El soft-
aplicaci6n se puede descomponer de tal mod0 que algu- ware de cliente se centra en la gesti6n de IGU y de
no de 10s componentes residan en el cliente y otros resi- comunicaci6n.
dan en el semidor.
Un cliente ((pesodo)) implement0 lo moyoio de 10s oplicociones

especificas de lo oplicoci6n en el cliente. Un cliente ((ligeror
Lo PFR del grupo de notias comp.client-server se puede relego la mayor porte del proceso ol servidar.
encontror en la pbgino
www.foqs.org/faqs/client-server-faq Se pueden utilizar clientes y servidores pesados para
ilustrar el enfoque general de asignaci6n de compo-
nentes de software de cliente/semidor. Sin embargo, un
Componente de gestion de bases de datos. Este
enfoque mis granular para la asignaci6n de componentes
componente lleva a cab0 la manipulaci6n y gesti6n de
de software define cinco configuraciones diferentes.
datos por una aplicaci6n. La manipulaci6n y gesti6n
de datos puede ser tan sencilla como la transferencia de Presentacidn distribuida. En este enfoque clientelser-
un registro, o tan compleja como el procesamiento de vidor rudirnentario, la 16gica de la base de datos y la 16gica
sofisticadas transacciones SQL. de la aplicaci6n permanecen en el servidor, tipicarnente
Ademis de estos componentes, existe otro bloque de en una computadora central. El semidor contiene tam-
construcci6n del software, que suele denominarse soft- biCn la 16gica para preparar information de pantalla,
ware intermedio en todos 10s sistemas CIS. El softwa- empleando un software tal como CICS. Se utiliza un soft-
re intermedio se describi6 en la Secci6n 28.2.3. Orfali ware especial basado en PC para transformar la infor-
[ORF99] y sus colegas se han referido a1 software inter- maci6n de pantalla basada en caracteres que se transmite
medio como <<elsistema nervioso de un sistema clien- desde el semidor en una presentaci6n IGU en un PC.
te/semidor>>.
iCuiles son 10s opciones de
tonfiguracion para 10s
componentes de software
cliente/servidor?
El sofhvore intermedio estoblece lo infroestructura
que hoce posible que 10s componentes Presentacidn remota. En esta extensi6n del enfoque
cliente/servidor interoperen. de presentaci6n distribuida, la 16gica primaria de la base
l N G E N l E R f A DEL SOFTWARE. U N E N F O Q U E P R A C T I C O
de datos y de la aplicacion permanecen en el servidor,

y 10s datos enviados por el servidor seran utilizados por
el cliente para preparar la presentacion del usuario.
Ldgica distribuida. Se asignan a1 cliente todas las
tareas de presentacion del usuario y tambiCn 10s proce-
sos asociados a la introduccion de datos tales como la
validaci6n de nivel de campo, la formulaci6n de con-
sultas de servidor y las solicitudes de informaciones de
actualizaciones del servidor. Se asignan a1 servidor las El resto de 10s componentes de la aplicaci6n se dis-
tribuye entre cliente y servidor basandose en la distri-
tareas de gesti6n de las bases de datos, y 10s procesos
para las consultas del cliente, para actualizaciones de buci6n que optimice las configuraciones de cliente y
archivos del servidor, para control de version de clien- servidor y de la red que 10s conecta. Por ejemplo, la
implementaci6n de una relacion mutuamente excluyen-
tes y para aplicaciones de Ambito general de la empresa.
te implica una busqueda en la base de datos para deter-
Gestidn de datos remora. Las aplicaciones del ser- minar si existe un registro que satisfaga 10s parametros
vidor crean una nueva fuente de datos dando formato a de una cierta trama de busqueda. Si no se encuentra nin-
10s datos que se han extraido de algun otro lugar (por gun registro, se emplea una trama de busqueda altema-
ejemplo, de una fuente de nivel corporativo). Las apli- tiva. Si la aplicacion que cdntrola esta trarna de busqueda
caciones asignadas a1 cliente se utilizan para explotar esta contenida en su totalidad en el servidor, se minimi-
10s nuevos datos a 10s que se ha dado formato mediante za el trafico de red. La primera transmisih de la red des-
el servidor. En esta categoria se incluyen 10s sistemas de el cliente hacia el servidor contendria 10s parametros
de apoyo de decisiones. tanto para la trama de busqueda primaria como para la
Bases de datos distribuidas. Los datos de que consta trama de busqueda secundaria. La 16gica de aplicacion
la base de datos se distribuyen entre multiples clientes del servidor determinaria si se requiere la segunda bus-
y servidores. Consiguientemente, el cliente debe de queda. El mensaje de repuesta a1 cliente contendria el
admitir componentes de software de gesti6n de datos registro hallado como consecuencia bien de la primera
asi como componentes de aplicacidn y de IGU. o bien de la segunda busqueda. El enfoque altemativo
Durante 10s ultimos aiios se ha dado mucha impor- (el cliente implementa la logica para determinar si se
tancia a la tecnologia de cliente ligero. Un cliente lige- requiere una segunda busqueda) implicaria un mensaje
ro es la llamada <<computadora de redem que relega todo para la primera recuperaci6n de registros, una respues-
el procesamiento de la aplicacion a un servidor pesado. ta a travCs de la red si no se halla el registro, un segun-
Los clientes ligeros (computadoras de red) ofrecen un do mensaje que contuviera 10s parametros de la segunda
coste por unidad sustancialmente mis bajo a una per- busqueda, y una respuesta final que contuviera el regis-
dida de rendimiento pequeiia o nada significativa en tro recuperado. Si en la segunda busqueda se necesita el
comparaci6n con las computadoras de sobremesa. 50 por 100 de las veces, la colocacion de la logica en el
servidor para evaluar la primera busqueda e iniciar la
28.9.3. Lineas generales para la distribucih de segunda si fuera necesario reduciria el trafico de red en
componentes de aplicaciones un 33 por 100.
Aun cuando no existen reglas absolutas que describan
la distribucion de componentes de aplicaciones entre el
cliente y el servidor, suelen seguirse las siguientes line-
as generales: Aunque 10s lineos generoles de lo distribucidnson valiosos,
todos 10s sisternos deben de tornorse en considerucibn
El componente de presentacidnlinteracci6n suele por sus propios meritos. Puro todos 10s beneficios derivodos
ubicarse en el cliente. La disponibilidad de entomos de, digornos, un cliente pesodo, el diseriodor debe de luchor
basados en ventanas y de la potencia de c6mputo nece- con un conjunto porecido de controriedodes.
saria para una interfaz grafica de usuario hace que este
enfoque sea eficiente en tkrminos de coste. La decision final acerca de la distribuci6n de com-
Si es necesario compartir la base de datos entre mril- ponentes debena estar basada no solamente en la apli-
tiples usuarios conectados a trave's de la LAN, enton- caci6n individual, sino en la mezcla de aplicaciones que
ces la base de datos suele ubicarse en el servidor. El estC funcionando en el sistema. Por ejemplo, una insta-
sistema de gesti6n de la base de datos y la capacidad de laci6n podria contener algunas aplicaciones que requie-
acceso a la base de datos tambiCn se asignan a1 serviran un extenso procesamiento de IGU y muy poco
dor, junto con la base de datos fisica. procesamiento central de la base de datos. Esto daria
Los datos estaticos que se utilicen deberian de asig- lugar a la utilization de potentes estaciones de trabajo
name a1 cliente. Esto situa 10s datos mas pr6ximos a1 en el lado cliente y a un servidor muy sencillo. Una vez
usuario que tiene necesidad de ellos y minimiza un tri- implantada esta configuraci6n, otras aplicaciones favo-
fico de red innecesario y la carga del servidor. recerian el enfoque de cliente principal, para que las
CAPfTULO 28 I N G E N l E R f A D E L S O F T W A R E D E L C O M E R C I O E L E C T R ~ N I C OC L I E N T E I S E R V I D O R
capacidades del semidor no tuvieran necesidad de ver- el objeto a1 cual se habia destinado el mensaje, para invo-
se aumentadas. car su mCtodo, para pasar a1 objeto 10s datos adecuados,
Habria que tener en cuenta que a medida que madu- y para transferir 10s datos resultantes de vuelta a1 obje-
ra el uso de la arquitectura cliente/semidor, la tenden- to que generase el mensaje inicialmente.
cia es a ubicar la 16gica de la aplicacion volBtil en el
semidor. Esto simplifica la implantacidn de actualiza-
ciones de software cuando se hacen cambios en la 16gi-
ca de la aplicaci6n [PAU95]. Un ORB capacito o un objeto que resida en un cliente
para enviar un rnensaje o un rnetodo que estk
28.9.4. Enlazado de componentes de software CIS encopsulodo en otro objeto que resido en un servidor.
Se utiliza toda una gama de mecanismos distintos para En el Capitulo 27 se estudiaron 10s tres estindares
enlazar 10s distintos componentes de la arquitectura mBs utilizados que implementan una filosofia de redis-
clientelsemidor. Estos mecanismos estin incluidos en tribuci6n de objetos: CORBA, COM y JavaBeans. COR-
la estructura de la red y del sistema operativo, y resul- BA se utilizari para ilustrar la utilizaci6n del software
tan transparentes para el usuario final situado en el cen- intermedio ORB.
tro cliente. Los tipos mis comunes de mecanismos de
enlazado son:
Tuberias (pipes): se utilizan mucho en 10s sistemas
basados en UNIX; las tuberias permiten la mensaje-
ria entre distintas mBquinas que funcionen con dis- Lo inforrnocibn m 4 ociuolizoda sobre estandores de
tintos sistemas operativos. componentes se puede encontror en lo pagina
Llamadas a procedimientos remotos: permiten que www.omg.com, www.microsoft.com/C0M, y
java.sun.com/beans
un proceso invoque la ejecuci6n de otro proceso o
mddulo que resida en una miquina distinta. En la Figura 28.6 se muestra la estructura bisica de
una arquitectura CORBA. Cuando se implementa COR-
iCu6les son las opciones BA en un sistema cliente/semidor, 10s objetos y las cla-
disponibles para vincular ses de objetos (Capitulo 20) tanto en el cliente como en
componentes? el servidor se definen utilizando un lenguaje de des-
cripci6n de interfaces (LDI'), un lenguaje declarative
Inreraccidn SQL clienrelse~vidor:se utiliza para pasar que permite que el ingeniero del software defina obje-
solicitudes SQL y datos asociados de un componente tos, atributos, mCtodos y 10s mensajes que se requieren
(tipicamente situado en el cliente) a otro componente para invocarlos. Con objeto de admitir una solicitud para
(tipicamenteel SGBD del servidor).Este mecanismo un mCtodo residente en el servidor procedente de un
estB limitado linicamente a las aplicaciones SGBDR. objeto residente en el cliente, se crean stubs LDI en el
Conexiones (sockets), se tratan en la Secci6n 28.6. cliente y en el semidor. Estos stubs proporcionan la pasa-
rela a travCs de la cual se admiten las solicitudes de obje-
AdemBs, las implementaciones orientadas a objetos
tos a travCs del sistema CIS.
de componentes de software CIS dan lugar a una win-
Dado que las solicitudes de objetos a travCs de la red
culaci6n~que haga uso de un distribuidor de solicitu-
se producen en el momento de la ejecucion, es preciso
des de objetos. Este enfoque se describiri en la secci6n
establecer un mecanismo para almacenar una descrip-
siguiente.
ci6n del objeto de tal mod0 que la informacidn perti-
nente acerca del objeto y de su ubicaci6n estC disponible
28.9.5. Software intermedio (middleware) cuando sea necesario. El repositorio de interfaz hace
y arquitecturas de agente de solicitud precisamente esto.
de objetos
Los componentes de software CIS descritos en las sec-
ciones anteriores estin implementadas mediante obje-
tos que deben de ser capaces de interactuar entre si en
el seno de una sola miquina (bien sea cliente o semidor)
o a travCs de la red. Un agente de distribuci6n de obje-
tos (ORB) es un componente de software intermedio que
capacita a un objeto que resida en un cliente para enviar Cuando una aplicaci6n cliente necesita invocar un
un mensaje a un mCtodo que estC encapsulado en otro mCtodo contenido en el seno de un objeto residente en
objeto que resida en un servidor. En esencia, el ORB alguna otra parte del sistema, CORBA utiliza una invo-
intercepta el mensaje y maneja todas las actividades de
comunicaci6n y de coordinaci6n necesarias para hallar En ingles IDL (Interface Description Language).
511
cacion dinamica para (I) obtener la informaci6n perti- dentes del cliente, y lleva a cab0 otras muchas tareas
.nente acerca del objeto deseado a partir del dep6sito de de gesti6n de objetos [ORF99]. En el servidor unos
interfaz; (2) crear una estructura de datos con parime- stubs LDI, similares a 10s definidos en la maquina clien-
tros que habra que pasar a1 objeto; (3) crear una solicite, se emplean como interfaz con la implementaci6n
tud para el objeto; y (4) invocar la solicitud. A del objeto real que reside en la ubicaci6n del servidor.
continuaci6n, se pasa la solicitud a1 nucleo ORB -una El desarrollo del software para sistemas CIS moder-
parte dependiente de implementaci6n del sistema ope- nos esta orientado a objetos. Empleando la arquitectu-
rativo en red que gestione las solicitudes- y, a conti- ra CORBA descrita brevemente en esta seccibn, 10s
nuaci611, se satisface la solicitud. desarrolladores de software pueden crear un entorno en
La solicitud se pasa a travCs del ndcleo y es proce- el cual se pueden reutilizar 10s objetos a lo largo y ancho
sada por el servidor. En la ubicaci6n del servidor, un de una red muy amplia. Para mas informaci6n acerca
adaptador de objetos almacena la informaci6n de cla- de CORBA y de su impacto general sobre la ingenieria
ses y de objetos en un dep6sito de interfaz residente en del software para sistemas CIS, el lector interesado pue-
el servidor, admite y gestiona las solicitudes procede consultar [HOQ99] y [SIE99].
En el Capitulo 2 se present6 un cierto nlimero de

modelos de proceso de software distintos. Aun cuan-
do muchos de ellos se podrian adaptar para su utili-
zaci6n en el desarrollo de software para sistemas CIS,
hay dos enfoques que son 10s que se utilizan mas
comdnmente: (1) un paradigma evolutivo que hace
uso de la ingenieria del software basada en sucesos
y/o orientada a objetos; y (2) una ingenieria del soft-
ware basada en componentes (Capitulo 27) que se basa
en una biblioteca de componentes de software CYD
~0~
dinarnica de cliente
y de desarrollo propio.
Los sistemas cliente servidor se desarrollan emplean-
do las actividades de ingenieria del software clasicas
-el analisis, diseiio, construcci6n y depuraci6n- a
medida que evoluciona el sistema a partir de un con-
junto de requisitos de negocios generales para llegar a
ser una colecci6n de componentes de software ya vali-
dados que han sido implementados en maquinas clien-
te y servidor. FIGURA 28.6. La arquitectura basica CORBA.
La actividad de modelado de requisitos para 10s sistemas Dado que el modelado de analisis evita la especi-
CIS difiere poco de 10s mCtodos de modelado de andisis ficaci6n de detalles de implementacibn, s61o cuando
que se aplicaban para la arquitectura de computadoras m b se haga la transici6n a1 disefio se consideraran 10s
convencionales. Consiguientemente, 10s principios bisi- problemas asociados a la asignaci6n de software a1
cos de andisis descritos en el Capitulo 11 y 10s mCtodos cliente y a1 servidor? Sin embargo, dado que se apli-
de modelado de andisis presentados en 10s Capitulos 12 ca un enfoque evolutivo de la ingenieria del softwa-
y 2 1 son igualmente aplicables a1 software CIS. Se debe- re para 10s sistemas CIS, las decisiones de imple-
ria destacar, sin embargo, que dado que muchos sistemas mentacion acerca del enfoque CIS global (por ejem-
CIS modernos hacen uso de componentes reutilizables, plo, cliente pesado frente a servidor pesado) se podran
tambiCn se aplican las actividades de cualificaci6n aso- hacer durante las primeras iteraciones de analisis y
ciadas a la ISBC (Capitulo 27). diseiio.
Por ejernplo, una arquitectura C/S conforrne a CORBA (Seccion

28.1.5) tendra un profundo impacto en la decisiones sobre el disefio
y la irnplementacion.
CAP~TULO
28 INGENIERfA DEL SOFTWARE DEL COMERCIO E L E C T R ~ N I C O
CLIENTEISERVIDOR
Cuando se esta desarrollando un software para su imple- n'sticas. Sin embargo, tambien se pueden adoptar meto-
mentaci6n empleando una arquitectura de computado- dos convencionales (Capitulos 12 y 16).
ras concreta, el enfoque de disefio debe de considerar
el entorno especifico de construcci6n. En esencia, el 28.12.1. Diseiio arquitect6nico para sistemas
disefio deberia de personalizarse para adecuarlo a la
clientelservidor
arquitectura del hardware.
Cuando se disefia software para su implementaci6n El disefio arquitectonico de un sistema cliente senidor
empleando una arquitectura cliente/senidor, el enfoque se suele caracterizar como un estilo de comunicaci6n
de disefio debe de ser ccpersonalizado>> para adecuarlo de procesos. Bass y sus colegas [BAS981 describe esta
a 10s problemas siguientes: arquitectura de la siguiente manera:
El disefio de datos (Capitulol4) domina el proceso El objetivo es lograr la calidad de la escalabilidad. Un ser-
vidor existe para proporcionar datos para uno o m8s clientes,
de disefio. Para utilizar efectivarnente las capacida- que suelen estar distribuidos en una red. El cliente origina una
des de un sistema de gestion de bases de datos rela- llamada a1 servidor, el cual trabaja sincronamente o asincro-
cional (SGBDR) o un sistema de gesti6n de bases de namente, para servir a la solicitud del cliente. Si el servidor
datos orientado a objetos (SGBDOO) el disefio de funciona sincronamente, devuelve el control a1 cliente a1 mis-
10s datos pasa a ser todavia mis significativo que en mo tiempo que devuelve 10s datos. Si el servidor trabaja asin-
cronamente, devuelve solo 10s datos a1 cliente (el que tiene su
las aplicaciones convencionales. propio hilo de control).
Aun cuando el software C/S es diferente, se pueden

utilizor mitodos convencionoles o de diseio 00 con muy
pocos modificociones.
Dado que 10s sistemas modemos CIS estin basados
Cuando se selecciona el paradigma controlado por en componentes, se utiliza una arquitectura de agente
sucesos, deberia realizarse el modelado del com- de solicitud de objetos (ORB) para implementar esta
portamiento (una actividad del anilisis, Capitulo 12 comunicaci6n sincrona y asincrona.
y 21) y sera precis0 traducir 10s aspectos orientados A un nivel arquitect6nic0, el lenguaje de descrip-
a1 control implicitos en el modelo de comportamiento ci6n de la interfaz C O R B A ~se utiliza para especifi-
a1 modelo de diseiio. car 10s detalles de la interfaz. La utilizaci6n de LDI
El componente de interacci6n/presentaci6ndel usua- permite que 10s componentes de software de la apli-
rio de un sistema CIS implementa todas aquellas fun- caci6n accedan a 10s servicios ORB (componentes)
ciones que se asocian tipicamente con una interfaz sin un conocimiento de su funcionamiento interno.
grafica de usuario (IGU). Consiguientemente,se vera El ORB tambiCn tiene la responsabilidad de coordi-
incrementada la importancia del disefio de interfa- nar la comunicaci6n entre 10s componentes del clien-
ces (Capitulo 15). El componente de interacci6nlpre- te y del servidor. Para lograr esto, el diseiiador
sentaci6n del usuario implementa todas las funciones especifica un adaptador de objetos (tambien llamado
que se asocian tipicamente con una interfaz grafica encubridor) que proporciona 10s servicios siguientes
de usuario (IGU). [BAS98]:
Suele seleccionarse un punto de vista orientado a Se registran las implementaciones de componentes
objetos para el diseiio (Capitulo 22). En lugar de la (objetos).
estructura secuencial que proporciona un lenguaje
de procedimientos se proporciona una estructura de Se interpretan y se reconcilian todas las referencias
objetos mediante la vinculaci6n entre 10s sucesos de componentes (objetos).
iniciados en la IGU y una funci6n de gesti6n de Se hacen coincidir,las referencias de componentes
sucesos que reside en el software basado en el (objetos) con la implementaci6n de 10s componen-
cliente. tes correspondiente.
Aun cuando prosigue todavia el debate acerca del Se activan y desactivan objetos.
mejor enfoque de analisis y diseiio para 10s sistemas Se invocan metodos cuando se transmiten mensa-
CIS, 10s mktodos orientados a objetos (Capitulos 21 y jes.
22) parecen ofrecer la mejor combinaci6n de caracte- Se implementan servicios de seguridad.
En COM y JavaBeans se utiliza un metodo analogo.

Para adrnitir 10s componentes CYD proporcionados por tos de negocios se lleva a cab0 empleando 10s meto-
proveedores diferentes y componentes de desarrollo pro- dos de ingenieria de la informaci6n descritos en el
pio que pueden haber sido implementadosutilizando dife- Capitulo 10. La notaci6n de modelado del analisis
rentes tecnologias, se debe disefiar la arquitectura ORB convencional (Capitulo 12), tal como DER, se podra
para lograr interoperabilidad entres componentes. Para utilizar para definir objetos de negocios, per0 es pre-
poderlo llevar a cab0 CORBA utiliza un concept0 puente. ciso establecer un dep6sito de base de datos para cap-
Supongamos que un cliente se haya implementado turar la informaci6n adicional que no se puede
utilizando un protocolo ORB X y que el servidor se haya documentar por completo empleando una notaci6n
implementado utilizando el protocolo ORB Y. Ambos grafica tal como un DER.
protocolos son conforme CORBA, per0 debido a las En este dep6sit0, se define un objeto de negocio como
diferencias de implementation intemas, se deben comu- una information que es visible para 10s compradores y
nicar con un ccpuente,, que proporcione un mecanismo usuarios del sistema, per0 no para quienes lo imple-
para la traducci6n entre protocolos internos [BAS98]. mentan, por ejemplo, un libro en el caso de estudio de
El puente traduce mensajes de manera que el cliente y ventas de libros. Esta informaci6n que se implementa
el servidor se puedan comunicar suavemente. utilizando una base de datos relacional, se puede man-
tener en un dep6sito de disefio. La siguiente informa-
28.12.2. Enfoques de diseiio convencionales para ci6n de disefio se recoge para la base de datos
clientelservidor [POR94]:
software de aplicaciones
En 10s sistemas clientelservidor, 10s diagramas de flujo Entidades: se identifican en el DER del nuevo sis-
(Capitulos 12 y 14) se pueden utilizar para establecer tema.
el Bmbito del sistema, para identificar las funciones de Archives: que implementan las entidades identifica-
nivel superior y las Areas de datos tematicas (almace- das en el DER.
nes de datos), y para permitir la descomposici6n de fun- Relacidn entre campo y archivo: establece la dispo-
ciones de nivel superior. Apartandose del enfoque DFD sici6n de 10s archivos a1 identificar 10s campos que
tradicional, sin embargo, la descomposici6n se detiene estan incluidos en cada archivo.
en el nivel de un proceso de negocio elemental, en lugar Campos: define 10s campos del diseiio (el dicciona-
de proseguir hasta el nivel de procesos at6micos. rio de datos).
En el context0 CIS, se puede definir un proceso ele-
mental de negocios (PEN) como un cierto conjunto de Relaciones entre archivos: identifican 10s archivos
tareas que se llevan a cab0 sin interrupci6n por parte relacionados que se pueden unir para crear vistas
de un usuario en 10s centros cliente. Estas tareas o bien 16gicas o consultas.
se realizan en su totalidad, o bien no se realizan en Validacidn de relaciones: identifica el tip0 de rela-
absoluto. ciones entre archivos o entre archivos y campos que
El diagrama entidad relacion adopta tambiCn un se utilicen par la validaci6n.
papel miis importante. Sigue utilizandose para des- Tipos de campo: se utiliza para permitir la herencia
componer las areas de datos tematicas (de almacenes de caracteristicasde campos procedentes de superen-
de datos) de 10s DFD con objeto de establecer una laces del campo (por ejemplo, fecha, texto, numero,
visi6n de alto nivel de la base de datos que haya que valor, precio).
implementar empleando un SGBDR. Su nuevo papel
consiste en proporcionar la estructura para definir obje-
Tipo de datos: las caracteristicas de 10s datos conte-
nidos en el campo.
tos de negocios de alto nivel (Secci6n 28.4.3).
En lugar de servir como herramientas para una des- Tipo de archivo: se utiliza para identificar cualquiera
composici6n funcional, el diagrama de estructuras se de las ubicaciones del archivo.
utiliza ahora como diagrama de ensamblaje, con obje- Funcidn del campo: clave, clave extema, atributo,
to de mostrar 10s componentes implicados en la solu- campo virtual, campo derivado, etc.
ci6n de algun procedimiento de negocios elemental. Valorespermitidos: identifica 10s valores permitidos
Estos componentes, que constan de objetos de inter- para 10s campos de tip0 de estado.
faz, objetos de aplicacion y objetos de bases de datos,
establecen la forma en la que se van a procesar 10s Reglas de negocios: reglas para editar, calcular carn-
datos. pos derivados, etc.
28.12.3. Diseiio de bases de datos

El disefio de bases de datos se utiliza para definir y
despuCs para especificar la estructura de 10s objetos
de negocios que se emplean en el sistema clientelser-
vidor. El analisis necesario para identificar 10s obje-
C A P ~ T U L O2 8 I N G E N I E R ~ ADEL S O F T W A R E D E L C O M E R C I O E L E C T R 6 N l C O C L I E N T E I S E R V I D O R
A medida que las arquitecturas CIS se han ido hacien- que van mas all6 del alcance de este libro. El lector inte-
do mas frecuentes, la tendencia hacia una gesti6n de resado puede consultar [BR091], [BER92], [VAS93] y
datos distribuida se ha visto acelerada. En 10s sistemas [ORF99] para una descripci6n m6s extensa.
CIS que implementan este enfoque, el componente de
gesti6n de datos reside tanto en el cliente como en el ser-
vidor. En el context0 del diseiio de bases de datos, un interfaz
problema fundamental es la distribuci6n de datos. Esto (Componentes)
es, jc6m0 se distribuyen 10s datos entre el cliente y el
servidor y c6mo se dispersan entre 10s nudos de la red? Asociacion
Un sistema de gestion de bases de datos relacional
(SGBDR) hace facil el acceso a datos distribuidos median-
I
te el uso del lenguaje de consulta estructurado (SQL). La Objetos de
ventaja de SQL en una estructura CIS es que ccno requie- base d e datos
re navegar,, [BER92]. En un SGBDR, 10s tipos de datos (Componentes)
se especifican empleando SQL, per0 no se requiere infor-
macion de navegaci6n. Por supuesto, la implication de
esto es que SGBDR debe ser suficientemente sofisticado FIGURA 28.7. Notacion de diagrama de estructura
para mantener la ubicacion de todos 10s datos y tiene que para componentes CIS.
ser capaz de definir la mejor ruta hasta ella. En sistemas
de bases de datos menos sofisticados, una solicitud de 28.12.4. Visidn general d e un enfoque d e disefio
datos debe indicar a quC hay que acceder y donde se
encuentra. Si el software de aplicaci6n debe mantener la Porter [POR95] sugiere un conjunto de pasos para dise-
informaci6n de navegacibn, entonces la gestion de datos iiar un proceso elemental de negocio que combine ele-
se vuelve mucho mas complicada por 10s sistemas CIS. mentos de diseiio convencional con elementos de
diseiio orientado a objetos. Se supone que se ha desa-
~ Q u optiones
e existen para rrollado un modelo de requisitos que defina 10s obje-
distribuir datos dentro de un tos de negocio, y que se ha refinado ya antes de
sistema CIS? comenzar el diseiio de 10s procesos elementales de
negocio. Entonces, se utilizan 10s pasos siguientes para
Es preciso tener en cuenta que tambiCn estan dispo- derivar el diseiio:
nibles para el diseiiador [BER92] otras tCcnicas para la
distribuci6n y gesti6n de datos: 1. Para cada proceso elemental de negocio, se identifi-
can 10s archivos creados, actualizados, borrados o
Extraccion manual. Se permite a1 usuario copiar referenciados
manualmente 10s datos adecuados de un servidor a un 2. Se utilizan 10s archivos identificados en el paso 1
cliente. Este enfoque resulta util cuando el usuario como base para definir componentes u objetos.
requiere unos datos estaticos y cuando se puede dejar 3. Para cada componente, se recuperan las reglas de
el control de la estaci6n en manos del usuario. negocio y otra informaci6n de objetos de negocio
Instantanea. Esta tecnica automatiza la extracci6n que se haya determinado para el archivo relevante.
manual a1 especificar una ccinstantanean de 10s datos que 4. Se determinan las reglas que son relevantes para el
deberan de transferirse desde un cliente hasta un servi- proceso y se descomponen las reglas hasta llegar a1
dor a intervalos predefinidos. Este enfoque es util para nivel de mCtodos.
distribuir unos datos relativamente estaticos que sola-
mente requieran actualizaciones infrecuentes. 5. Segun sea necesario, se definen 10s componentes
adicionales que se requieren para implementar 10s
Duplicacion. Se puede utilizar esta tecnica cuando mCtodos.
es preciso mantener multiples copias de 10s datos en dis-
tintos lugares (por ejemplo, servidores distintos o clien- Porter [POR95] sugiere una notacion especializada
tes y servidores). En este caso, el nivel de complejidad de diagramas de estructura (Fig. 28.7) para representar
se incrementa porque la consistencia de 10s datos, las la estructura de componentes de un proceso elemental
actualizaciones, la seguridad y el procesamiento deben de negocio. Sin embargo, se utiliza una simbologia dife-
de coordinarse entre 10s multiples lugares. rente para que el diagrama se ajuste a la naturaleza orien-
Fragrnentacion. En este enfoque, la base de datos tada a objetos del software CIS. En la figura, se
del sistema se fragmenta entre multiples maquinas. Aun- encuentran cinco simbolos distintos:
que resulta intrigante en teoria, la fragmentaci6n es Objeto de interfaz. Este tipo de componente, que
excepcionalmente dificil de implementar y hasta el tambiCn se denomina componente de interaccidnlpre-
momento no es frecuente encontrarla. sentacidn con el usuario, se construye tipicamente en
El diseiio de bases de datos, y mas especificamente, un 6nico archivo o bien otros archivos relacionados que
el diseiio de bases de datos para sistemas CIS son temas se hayan unido mediante una consulta. Incluye mCto-
dos para dar formato a la interfaz IGU y tambiCn la Asociacion de datos. Cuando un objeto invoca a otro
16gica de aplicaci6n residente en el cliente, junto con objeto independiente, se pasa un mensaje entre dos obje-
10s controles de la interfaz. TambiCn incluye sentencias tos. El simbolo de asociaci6n de datos se utiliza para
incrustadas de SQL, que especifican el procesamiento denotar este hecho.
de la base de datos efectuado en el archivo primario con Asociacion de control. Cuando un objeto invoca a
respecto a1 cual se haya construido la interfaz. Si la otro objeto independiente y no se pasan entre 10s dos
16gica de aplicaci6n asociada normalmente a un objeto objetos, se utiliza un simbolo de asociaci6n de control.
de interfaz se implementa en un sewidor, tipicamente
mediante el uso de herramientas de software interme-
dio, entonces la 16gica de aplicaci6n que funcione en el 28.12.5. Iteracion d e l disefio de procesos
servidor debera de identificarse como un objeto de apli- El repositorio de disefio (Secci6n 28.4.3), que se utili-
caci6n por separado. za para representar objetos de negocio, se emplea tam-
Objeto de base de datos. Este tip0 de componentes biCn para representar objetos de interfaz, de aplicacidn
se utiliza para identificar el procesamiento de bases de y de base de datos. Obs6wese que se han identificado
datos tal como la creacion o selecci6n de registros que las entidades siguientes:
estC basada en un archivo distinto del archivo primario Me'todos: describen c6mo hay que implementar una
en el cual se haya construido el objeto de interfaz. Es regla de negocio.
preciso tener en cuenta que si el archivo primario con Procesos elementales:definen 10s procesos elementa-
respecto a1 cual se construye el objeto de interfaz se pro- les de negocio identificados en el modelo de andisis.
cesa de manera distinta, entonces se puede utilizar un Enlace procesolcomponente: identifica a 10s com-
segundo conjunto de sentencias SQL para recuperar un
ponentes que forman la solucion de un proceso ele-
archivo en una secuencia alternativa. La tCcnica de pro-
cesamiento del segundo archivo deberia identificarse mental de negocio.
por separado en el diagrama de estructura, en forma de Componentes: describe 10s componentes mostrados
un objeto de base de datos por separado. en el diagrama de estructura.
Objeto de aplicacion. Es utilizado por un objeto de Enlace regla de negocios/componente: identifican a
interfaz, bien por un objeto de base de datos, y este com- 10s componentes que son significativos para la imple-
ponente sera invocado bien por un activador de una base mentaci6n de una determinada regla de negocio.
de datos, o por una llamada a procedimientos remotos. Si se implementa un repositorio utilizando un
TambiCn se puede emplear para identificar la 16gica de SGBDR, el diseiiador tendra acceso a una herramienta
negocios que normalmente se asocia a1 procesamiento de disefio muy fitil que proporciona informes que sir-
de interfaz que ha sido trasladado a1 servidor para su ven de ayuda tanto para la construcci6n como para el
funcionamiento. futuro mantenimiento del sistema CIS.
La naturaleza distribuida de 10s sistemas clientelser-

vidor plantea un conjunto de problemas especificos para
10s probadores de software. Binder [BIN921 sugiere las
siguientes zonas de inter&:
Referencia web/ '
Se presentan rerursos e informori6n util
Consideraciones del IGU de cliente. sobre comproboriones C/S en lo direction
Consideraciones del entorno destino y de la diversi- www.icon-stl.net/-djmosley/
dad de platafomnas.
La estrategia y las tacticas asociadas a la comproba-
Consideraciones de bases de datos distribuidas (inclu-
ci6n CIS deben disefiarse de tal mod0 que se permita
yendo datos duplicados). abordar todos y cada uno de 10s problemas anteriores.
Consideracionesde procesamiento distribuido (inclu-
yendo procesos duplicados).
28.13.1. Estrategia general de pruebas CIS
Entornos destino que no son robustos.
En general, las pruebas de software clientelservidor se
Relaciones de rendimiento no lineales. produce en tres niveles diferentes: (1) las aplicaciones
5 Esta seccion es una version muy abreviada y adaptada de un ar-

ticulo escrito por Daniel Mosley [MOS96] (utilizado con permiso del
autor). En [MOS99] se puede encontrar una version actualizada y
ampliada.
CAPfTULO 28 I N G E N I E R I A DEL S O F T W A R E D E L C O M E R C I O E L E C T R O N I C 0 C L I E N T E I S E R V I D O R
de cliente individuales se prueban de mod0 <<desconec-

tado,, (el funcionamiento del servidor y de la red sub- Lm thikas de eficifod6n de reuuisitos v 10s cosos
yacente no se consideran); (2) las aplicaciones de
software de cliente y del senidor asociado se prueban
a1 unisono, per0 no se ejercitan especificamente las ope-
raciones de red; (3) se prueba la arquitectura completa Para desarrollar el perfil operativo, es precis0 deri-
de CIS, incluyendo el rendimiento y funcionamiento de var un conjunto de escenarios de usuario [BIN95], que
la red. sea similar a 10s casos pricticos de estudio tratados en
Aun cuando se efectlien muchas clases distintas de este libro. Cada escenario abarca quiCn, d6nde, quC y
pruebas en cada uno de 10s niveles de detalle anterio- por quC. Esto es, quiCn es el usuario, d6nde (en la arqui-
res, es frecuente encontrar 10s siguientes enfoques de tectura fisica) se produce la interacci6n con el sistema,
pruebas para aplicaciones CIS: cuil es la transacci611, y por quC ha sucedido. Se pue-
den derivar 10s escenarios durante las tCcnicas de obten-
Pruebas de funcidn de aplicacidn. Se prueba la fun- ci6n de requisitos o a travCs de discusiones menos
cionalidad de las aplicaciones cliente utilizando 10s formales con 10s usuarios finales. Sin embargo, el resul-
mCtodos descritos en el Capitulo 17. En esencia, la apli- tad0 deberia ser el mismo. Cada escenario debe pro-
caci6n se prueba en solitario en un intento de descubrir porcionar una indicaci6n de las funciones del sistema
errores de su funcionamiento. que se necesitarh para dar senicio a un usuario con-
creto; el orden en que serin necesarias esas funciones,
~ Q u tipos
e de 10s tiempos y respuestas que se esperan, y la frecuen-
tomprobationes se realizan cia con la que se utilizari cada una de estas funciones.
para 10s sistemas CIS? Entonces se combinan estos datos (para todos 10s usua-
rios) para crear el perfil operativo.
Pruebas de servidor. Se prueban la coordinaci6n y La estrategia para probar arquitecturas CIS es ani-
las funciones de gesti6n de datos del senidor. TambiCn loga a la estrategia de pruebas para sistemas basados en
se considera el rendimiento del senidor (tiempo de res- software que se describian en el Capitulo 18. La com-
puesta y trasvase de datos en general). probaci6n comienza por comprobar a1 por menor. Esto
Pruebas de bases de datos. Se prueba la precisi6n e es, se comprueba una h i c a aplicaci6n de cliente. La
integridad de 10s datos almacenados en el senidor. Se integraci6n de 10s clientes, del senidor y de la red se
examinan las transacciones enviadas por las aplicacio- iri probando progresivamente. Finalmente, se prueba
nes cliente para asegurar que 10s datos se almacenen, todo el sistema como entidad operativa. La prueba tra-
actualicen y recuperen adecuadamente. TambiCn se dicional visualiza la integraci6n de m6dulos para sub-
prueba el archivado. sistemas/sistemas y su prueba (Capitulo 18) como un
Pruebas de transacciones. Se crea una serie de prue- proceso descendente, ascendente o alguna variaci6n de
bas adecuada para comprobar que todas las clases de tran- 10s dos anteriores. La integraci6n de m6dulos en el desa-
sacciones se procesen de acuerdo con 10s requisitos. Las rrollo CIS puede tener algunos aspectos ascendentes o
transacciones hacen especial hincapiC en la correcci6n descendentes,per0 la integraci6n en proyectos CIS tien-
de procesamiento y tambiCn en 10s temas de rendimiento de mis hacia el desarrollo paralelo y hacia la integra-
(por ejemplo, tiempo de procesamiento de transacciones ci6n de m6dulos en todos 10s niveles de diseiio. Por
y comprobaci6n de vollimenes de transacciones). tanto, la prueba de integraci6n en proyectos CIS se efec-
Pruebas de comunicaciones a travb de la red. Estas tlia a veces del mejor mod0 posible empleando una apro-
pruebas verifican que la comunicaci6n entre 10s nudos ximaci6n no incremental o del tipo <<big bang*.
de la red se produzca correctamente, y que el paso de
mensaje, las transacciones y el trifico de red relacio-
nado tenga lugar sin errores. TambiCn se pueden efec-
tuar pruebas de seguridad de la red como parte de esta
actividad de prueba.
Para llevar a cab0 estos enfoques de pruebas, Musa
[MUS93] recomienda el desarrollo de perfiles operati-
vos derivados de escenarios cliente/senidor. Un perfil
operativo indica la forma en que 10s distintos tipos de El hecho de que el sistema no se estC construyendo
usuarios interactlian con el sistema CIS. Esto es, 10s per- para utilizar un hardware y un software especificado
files proporcionan un ~patr6nde u s o que~ se puede apli- con anterioridad tiene su impact0 sobre la comproba-
car cuando se diseiian y ejecutan las pruebas. Por ci6n del sistema. La naturaleza multiplataforma en red
ejemplo, para un determinado tipo de usuarios, LquC de 10s sistemas CIS requiere que se preste bastante mis
porcentaje de las transacciones s e r h consultas? LActua- atenci6n a la prueba de configuraciones y a la prueba
lizaciones? ~Pedidos? de compatibilidades.
La doctrina de prueba de configuraciones impone la formas. Ademas, la comprobaci6n debe explorar un
prueba del sistema en todos 10s entornos conocidos de elevado n6mero de rutas logicas, porque la IGU crea,
hardware y software en 10s cuales vaya a funcionar. La manipula y modifica una amplia gama de objetos grfi-
prueba de compatibilidad asegura una interfaz funcio- ficos. La comprobaci6n se ve complicada aun mas por-
nalmente consistente entre plataformas de software y que 10s objetos pueden estar presentes o ausentes,
hardware. Por ejemplo, la interfaz de ventanas puede ser pueden existir durante un cierto period0 de tiempo, y
visualmente distinta dependiendo del entorno de imple- pueden aparecer en cualquier lugar del escritorio.
mentacibn, per0 10s mismos comportamientos bfisicos Esto significa que el enfoque tradicional de captu-
del usuario deberian dar lugar a 10s mismos resultados ra/reproducci6n para comprobar interfaces convencio-
independientemente del esthdar de interfaz de cliente. nales basadas en caracteres debe ser modificado para
que pueda manejar las complejidades de un entorno
IGU. Ha aparecido una variaci6n funcional del para-
digma de captura/reproducci6n denominado captural
reproduccibn estructurada [FAR931 para efectuar la
prueba de la IGU.
La captura/reproducci6n tradicional registra las
Espetifiracibn de pruebas CIS
entradas tales como las teclas pulsadas y las salidas
tales como imfigenes de pantalla que se almacenan
28.13.2. Tacticu de pruebas CIS para comprobaciones posteriores. La capturalrepro-
Aun cuando el sistema CIS no se haya implementado duccidn estructurada esta basada en una visidn in-
empleando tecnologia orientada a objetos, las tCcni- terna (16gica) de las actividades externas. Las
cas de pruebas orientadas a objetos (Capitulo 23) tie- interacciones del programa de aplicacidn con la IGU
nen sentido porque 10s datos y procesos duplicados se se registran como sucesos internos, que se pueden
pueden organizar en clases de objetos que compartan almacenar en forma de <<guiones>> escritos en Visual
un mismo conjunto de propiedades. Una vez que se Basic de Microsoft, en una de las variantes de C, o
hayan derivado 10s casos prricticos para una clase de en el lenguaje patentado del fabricante. Las herra-
objetos (o su equivalente en un sistema desarrollado mientas que ejercitan las IGUs no abarcan las vali-
convencionalmente), estos casos de prueba deberian daciones de datos tradicionales ni tampoco las
resultar aplicables en general a todas las instancias de necesidades de comprobaci6n de rutas. Los mCtodos
esa clase. de comprobaci6n de caja blanca y caja negra descri-
El punto de vista 00 es especialmente valioso cuantos en el Capitulo 17 son aplicables en muchos casos,
do se considera la interfaz grfifica de usuario de 10s y las estrategias orientadas a objetos especiales que
sistemas CIS modernos. La IGU es inherentemente se presentaban en el Capitulo 23 son adecuadas tan-
orientada a objetos, y se aparta de las interfaces tradi- to para el software de cliente conio para el software
cionales porque tiene que funcionar en muchas plata- de servidor.
Aun cuando 10s sistemas cliente/semidor pueden adop- Las arquitecturas de agente de solicitud de objetos
tar uno o mas de 10s modelos de procesos de software simen de apoyo para 10s diseiios CIS en 10s cuales 10s
y muchos de 10s mCtodos de analisis, diseiio y com- objetos cliente envian mensajes a 10s objetos semidor.
probaci6n descritos anteriormente en este libro, las El estfindar CORBA hace uso de un lenguaje de defini-
caracteristicas de arquitecturas especiales de CIS requie- ci6n de interfaz, y 10s repositories de interfaz gestionan
ren una personalizaci6n del software de ingenieria del las solicitudes de objetos independientemente de su ubi-
software. En general, el modelo de proceso del software caci6n dentro de la red.
que se aplica a 10s sistemas CIS tiene una naturaleza evo- El analisis y el diseiio de sistemas clientelservidor
lutiva, y 10s mCtodos tkcnicos suelen tender a enfoques hacen uso de diagramas de flujo de datos y de enti-
orientados a objetos. El desarrolladordebe describir aque- dades y relaciones, diagramas de estructura modifi-
Uos objetos que se produzcan en la implementaci6n de 10s cados, y otras notaciones que se encuentran en el
componentes de interacci6n lrepresentaci6n con el usua- desarrollo de aplicaciones convencionales. Es preci-
rio, de base de datos y de aplicaci6n. Los objetos defi- so modificar las estrategias de comprobaci6n para ade-
nidos para estos componentes deberian asignarse bien cuarlas a las comprobaciones que examinan la
a la maquina, o bien a la mfiquina semidor, y se pue- comunicaci6n a travCs de la red y el juego entre el
den vincular a travCs de un distribuidor de solicitudes software que reside en el cliente y aquel que reside en
de objetos. el semidor.
CAP~TULO
28 I N G E N I E R I A DEL S O F T W A R E DEL C O M E R C I O E L E C T R ~ N I C OC L I E N T E I S E R V I D O R
[BAS981 Bass, L., P. Clemens y R. Kazman, Software Archi- [MOS99] Mosley, D., Client Server Software Testing on the
tecture in Practice, Addison-Wesley, 1998. Desk Top and the Web, Prentice-Hall, 1999.
[BER92] Berson, A., ClientlSenvr Architecture, McGraw- [MUS93] Musa, J., <<OperationalProfiles in Software Relia-
Hill, 1992. bility Engineering,,, IEEE Sofhvare, Marzo de 1993, pp.
14-32.
[BIN921 Binder, R., <<ACASE-based Systems Engineering
Approach to Client-Server Developmentr, CASE Trends, [ORF99] Orfali, R., D. Harkey y J. Edwards, Essential
1992. ClientlServer Survival Guide, 3.%d., Wiley, 1999.
[PAU95] L. G. Paul, c<Client/ServerDeployment,,, Compu-
[BIN951 Binder, R., <<Scenario-BasedTesting for Client Ser- terworld, 18 de Diciembre, 1995.
ver systems,,, Sofhvare Development, vo]. 3, n." 8, Agos-
to de 1995, pp. 43-49. [POR94] Porter, J., 0 - D E S Design Manual, Fairfield Uni-
versity, 1994.
[BR091] Brown, A.W., Object-Oriented Databases, [POR95] Porter, J., Synon Developer's Guide, McGraw-Hill,
McGraw-Hill, 199 1. 1995.
[FAR931 Farley, K.J., <<SoftwareTesting For Windows Deve- [REE97] Reece, G., JBDC and Java, O'Reilly, 1997.
lopers,,, Data Based Advisor, Noviembre de 1993, pp. 45- [SIE99] Siegel, J., CORBA 3 Fundamentals and Program-
46, 50-52. ming, Wiley, 1999.
[HOQ99] Hoque, R., CORBA for Real Programmers, Aca- [VAS93] Vaskevitch, D., ClientlServer Strategies, IDG
demic Press/Morgan Kaufmann, 1999. Books. 1993.
28.1. Empleando publicaciones comerciales o recursos e Inter- Wide Web, y se pueden hacer pedidos a travCs de correo elec-
net de informaci6n de fondo, defina un conjunto de criterios trbnico, mediante el sitio Web y tarnbiCn por telCfono o fax.
para evaluar herramientas para la ingenieria del software CIS. Se construiri un sistema cliente/servidor para prestar su apo-
28.2. Sugiera cinco aplicaciones en las cuales un servidor pesa- yo a1 procesamiento de pedidos en el sitio de la compaiiia.
do parezca una estrategia de diseiio adecuada. Defina un conjunto de objetos de alto nivel que fueran nece-
sarios para el sistema de procesamiento de pedidos, y organi-
28.3. Sugiera cinco aplicaciones en las cuales un cliente pesa- ce estos objetos en tres categorias de componentes: la
do parezca ser una estrategia de diseiio adecuada. presentaci6n con el usuario, la base de datos y la aplicaci6n.
28.4. Efechie una investigacidn sobre 10s dltimos delitos come- 28.8. Formule reglas de negocio para establecer c u h d o se pue-
tidos en Internet y describa cdmo la tecnologia de seguridad de efectuar un envio si el pago se efechia mediante tarjeta de
apuntada en este capitulo podria haberla evitado. crCdito, con respecto al sistema descrito en el Problema 28.7.
28.5. Describa cdmo se podria estructurar un sistema de reser- Aiiada reglas adicionales si el pago se efechia mediante cheque.
vas en unas lineas aCreas como un sistema clientelservidor. 28.9. Desarrolle un diagrarna de transici6n de estados (Capi-
28.6. Investigue 10s dltimos avances en software para traba- tulo 12) que defina 10s sucesos y estados que resultan'an visi-
jo en grupo y desarrolle una breve presentaci6n para la clase. b l e ~para un dependiente de entrada de pedidos que trabajase
El profesor puede asignar una funci6n especifica a 10s distin- en un PC cliente en la divisi6n de ventas por catilogo (Pro-
tos participantes. blema 28.7).
28.7. Una compaiiia va a establecer una nueva divisi6n de 28.10.0frezca ejemplos de tres o cuatro mensajes que pudie-
ventas por catilogo para vender mercancias de uso frecuente ran dar lugar a una solicitud de un mCtodo de cliente mante-
y en exteriores. El cadogo electrbnico se publicari en la World nido en el servidor.
Aun cuando 10s mCtodos bisicos de anilisis y diseiio para nahan (Developing Client-Server Applications, IDG Books
sistemas cliente/servidor son bastante parecidos a 10s siste- Worldwide, 1999) abarca un amplio abanico de temas CIS.
mas 00 convencionales, se requieren tCcnicas y conoci- A un nivel m i s sofisticado, Orfali y sus colaboradores
mientos especializados. Lowe y Helda han escrito unas [ORF99], y Linthicum (Guide to ClientlServer and Intranet
introducciones valiosas a 10s conceptos bdsicos (ClientlSer- Development, Wiley, 1997) proporcionan las lineas genera-
ver Computing for Dummies, 3.%d., IDG Books Worldwide, les detalladas para aplicaciones CIS. Berson (ClientlServer
1999), al igual que Zantinge y Adriaans (Managing ClientlSer- Architecture, 2.+d., McGraw-Hill, 1996) trata temas de arqui-
ver, Addison-Wesley, 1997). En un nivel intermedio, McCla- tectura y componentes.
En 10s ultimos aiios las computadoras de redes se han con- dimiento del software y 10s aplican a la arquitectura y al dise-
vertido en un tema tecnol6gico candente (y una estrategia anies- fio de los sistemas distribuidos. Heinckiens y Loomies (Buil-
gada de negocios). Sinclair y Merkow (Thin Clients Clearly ding Scalable Database Applications: Object-Oriented
Explained, Morgan Kaufmann Publishers, 1999), Friedrichs y Design, Architectures, and Implementations, Addison-Wes-
Jubin (Java Thin-Client Programming for a Network Compu- ley, 1998) dan importancia a1 disefio de bases de datos en su
ting Environment, Prentice-Hall, 1999), Dewire (Thin Clients, guia para construir aplicaciones clientelservidor. Ligon
McGraw-Hill, 1998) y Kanter (Understanding Thin-ClientlSer- (ClientlServer Communications Services: A Guide for the
ver Computing, Microsoft Press, 1998) proporcionan una guia Applications Developer, McGraw-Hill, 1997) tiene en cuen-
valiosa de c6mo disefiar, construir, hacer uso y apoyar siste- ta una gran variedad de temas de comunicacih relacionados
mas cliente ligeros (delgados). entre 10s que se incluyen TCP/IP, ATM, EDI, CORBA, men-
Empezando con el modelado de sucesos de negocios, sajes y encriptacion. Schneberger (ClientlSer-ver Software
Ruble (Practical Analysis and Design for ClientlServer and Maintenance, McGraw-Hill, 1997) presenta un marco de tra-
GUI Systems, 1997) proporciona un estudio en profundidad bajo para controlar 10s costes de mantenimiento de software
de las tCcnicas para el analisis y diseiio de sistemas CIS. Los CIS y para optimizar el apoyo a1 usuario.
libros de Goldman, Rawles y Mariga (ClientlSener Infor- Literalmente cientos de libros abarcan el desarrollo de sis-
mation Systems: A Business-Oriented Approach, Wiley, 1999), temas CIS especificos del vendedor. La siguiente relacidn
Shan, Earle y Lenzi (Enterprise Computing With Objects: representa un pequefio muestreo:
From ClientlServer Environments to the Internet, Addison- Anderson, G.W., Client/Server Database Design With
Wesley, 1997) y Gold-Berstein y Marca (Designing Enter- Sybase: A High-Performance and Fine-Tuning Guide,
prise ClientlServer Systems, Prentice-Hall, 1997) tienen en McGraw-Hill, 1997.
consideracion 10s sistemas CIS en un contexto mas amplio Barlotta, M. J., Distributed Application Development With
de empresa. Powerbuilder 6, Manning Publications Company, 1998.
Existe un grupo de libros que estudian la seguridad en Bates, R.J., Hands-on ClientIServer Internetworking,
redes; a continuacion se proporciona una muestra: McGraw-Hill, 1997.
Stallings, W., Cryptology and Network Security, Prenti- Mahmoud, Q.H., Distributed Programming with java,
ce-Hall, 1998. Manning Publications Company, 1998.
Gralla, P., The Complete Idiots Guide to Protecting Your- Orfali, R., y Harkey, ClientIServer Programming with
self Online, Que, 1999. JavaBeans, Wiley, 1999.
Ghosh, A. K., E-commerce Security: Weak Links, Best Sankar, K., Building Internet Client/Server Systems,
Defenses, John Wiley, 1998. McGraw-Hill, 1999.
Atkins, D. T., Shelden y T. Petru, Internet Security: Pro- Mosley [MOS99] y Bourne (Testing ClientlServer Sys-
fessional Reference, New Riders Publishing, 1997. tems, McGraw-Hill, 1997) han escrito libros de guia detalla-
Bemstein, T., A.B. Bhimani, E. Schultz y C. Siegel, Inter- dos para pruebas CIS. Arnbos autores proporcionan un estudio
net Security for Business, John Wiley, 1998. en profundidad de las estrategias de comprobacion, tacticas
Garfinkel, S., y G. Spafford, Web Security and Commer- y herramientas.
ce, 0 . Reilly, 1997. Una gran variedad de fuentes de information sobre inge-
nieria del software cliente/servidor esth disponible en Inter-
Tiwana, A., Web Security, Digital Press, 1999.
net. Una lista actualizada de referencias a sitios (paginas) web
Loosely y Douglas (High-Performance ClientlServer, que son relevantes para sistemas CIS se pueden encontrar en
Wiley, 1997) explican 10s principios de la ingenieria de ren- http:l/www.pressman5.com.
A World Wide Web e Internet han introducido a la poblaci6n en general en el mundo de
la inforn~itica.Compramos fondos de inversi6n colectivos y acciones, descargamos
1mlisica, vemos peliculas, obtenemos asesoramiento mkdico, hacemos reservas de habi-
.
de ralidad., . . ...525524 5ones en hoteles, vendemos articulos personales, planificamos vuelos en lineas aCreas, cono-
atributos mos gente, hacemos gestiones bancarias, recibimos cursos universitarios, hacemos la compra
de WebbApps.. .. ..522
.. . .. e s decir, en el mundo virtual se puede hacer todo lo que se necesite-. Se puede decir que
. . ternet y la Web son 10s avances m8s importantes en la historia de la informitica. Estas tec-
dogias informiticas nos han llevado a todos nosotros a la era de la informitica (con otros
illones de personas quienes finalmente entrardn tambih). Durante 10s primeros aTios del siglo
:intiuno estas tecnologias han llegado casi a formar parte de nuestra vida diaria.
Para todos nosotros que recordamos un mundo sin Web, el crecimiento ca6tico de la tecno-
gia tiene su origen en otra era -10s primeros dias del software-. Eran tiempos de poca dis-
plina, pero de enorme entusiasmo y creatividad. Eran tiempos en que 10s programadores a
enudo entraban en otros sistemas, algunas veces con buena intenci6n y otras con mala inten-
diseiio 6n. La actitud que prevalecia parecia ser la de <<Hazlorripidamente, y entra en el campo, que
de la interla1 ........531 )sotros lo limpiaremos (y mejor seria que entendieras lo que realmente queremos construir)
land0 actuemos>>.i L e suena familiar?
En una mesa redonda virtual publicada en IEEE Software [PRE98], mantuve en firme mi
)stura en relaci6n con la ingenieria de Web:
Me parece que cualquier producto o sistema importante es merecedor de recibir una ingenieria. Antes
krmulacion. .........526 de comenzar it construirlas. lo mejor es entender el problema, diseiiar una soluci6n viable, implementarla
gestion de proyectos. .534 de una manera s6lida y comprobarla en profundidad. Probablemente tambiCn se deberian controlar 10s
,.,,,,, A IW-I. c9c cambios a medida que el trabnjo vaya avanzando, y disponer de mecanismos para asegurar la calidad del
resultado finill. Muchos de 10s que desarrollan Webs no dicen lo mismo: ellos piensan que su mundo es
realmente diferente, y que simplernente no se van a aplicar 10s enfoques de ingenieria del software con-
vencionales.
6QuC es? Los sistemas y aplicaciones iiias (por ejemplo, comercio electroni- bas. Dado que las WebApps estdrn e n
(WebApps)basados en Web hacen posi- c ~ )y, cada vea e s mas importante la constante evoluci6n. deben d e esta-
ble que una poblacibn extensa de usua- necesidad do construir sistemas fia- blecerse 10s mecanismos para el con-
rios finales dispongan de una gran bles, utilizables y adaptables. Esta e s trol d e conliguraciones, garantia d e
variedad d e contenido y Iuncionalidad. la razbn por la que e s necesario un calidad y soporte continuado.
La ingenieria Web noes un cl6nico per- enfoque disciplinado para el desorro- 4 Cud es el producto obtenldo? La
fecto de Ia ingenieria del software, per0 110 de WebApps. elaboraci6n d e una gran variedad d e
toma prestado muchos de 10sconcep- 2Cuales san 10s pasos a segub ? Al productos de tralwjode ingenieria Web
tos y principios Msicos d e la ingenie- igual que cualquier disciplina de inge- (por ejemplo. modelos de an6lisis.
ria del software, dando importancia a nieria, la ingenieria Web aplica un modelos de diseilo, procedimientos de
laa mismas actiridades tbcnicas y d e enfoque generic0 que s e suaviza con pruebas). Y como producto final la
gesti6n. Existen diferencias sutiles e n estrategias, tacticas y m6todos espe- WebApp operativa.
la forma en pue se llevan a cabo estas cializados. El proceso d e ingenieria C6mo puedo eslar seguro de que
actividades, per0 la filosofia primordial Web comienza con una formulaciondel lo he hecho correctamenle?Apli-
e s ld6ntica dado que dicta un enfoque problema que pasa a resolverse con cando las mismas practicas SQAque se
disciplinado para el desarrollo de un las WebApps. Se planifica el proyecto aplican en todos 10s procesos d e inge-
sistema basado en computadora. y s e analizan 10s requisitos d e la nieria del software -las revisiones t&-
~Qui8n lo hace? Los ingenieros Web y WebApp, entonces se lleva a c a b el nicas formales valoran 10smodelos de
10s desarrolladores d e contenido no diseiio de interlaces arquitectbnico y analisis y d i s e i i e ; las revisiones espe-
t6cnicos crean las WebApps. del navegador. El sistema s e imple- cializadas tienen en consideraci6n la
&Porqu6 e s Cmportante? A medida menta utilizando lenguajes y herra- usabilidad; y la comprobaci6n se apli-
que las WebApps s e integran cada vez mientas especializados asociados con ca para descubrir errores en el conteni-
m&s e n grandes y pequeiias compa- la Web, y entonces comienzan las prue- do, funcionalidad y compatibilidad.
Esto nos lleva a formular una pregunta clave: jPue-

den aplicarse principios, conceptos y mCtodos de inge-
nieria en el desarrollo de la Web? Creo que muchos de
ellos si se pueden aplicar, per0 su aplicaci6n quizas
requiera un giro algo diferente.
Pero, jquC ocurriria si estuviera equivocado?, y jsi
persiste el enfoque actual y especifico para ese desa-
rrollo de la Web? Con la ausencia de un proceso disci-
ulinado uara sistemas basados en Web, cada vez nos
preocupa mas la manera en que nos podemos enfrentar con problemas serios para obtener Cxito en el desarrollo,
empleo y ccmantenimiento>> de estos sistemas. En esencia, a medida que entramos en el nuevo siglo, la infraes-
tructura de las aplicaciones que se estan creando hoy en dia puede llevarnos a algo que se podria llamar ccWeb
enmarafiada,,. Esta frase connota un cdmulo de aplicaciones basadas en Web pobremente desarrolladas y con una
probabilidad de fallo bastante alta. Y lo que es peor, a medida que 10s sistemas basados en Web se van compli-
cando, un fallo en uno de ellos puede propagar y propagara problemas muy extensos en todos. Cuando ocurra esto,
la confianza en Internet se puede romper provocando resultados irremediables. Y lo que es adn peor, puede con-
ducir a una regulacidn gubernamental innecesaria y ma1 concebida, provocando dafios irreparables en estas tec-
nologias singulares.
Con objeto de evitar una Web enmarafiada y lograr un mayor Cxito en el desarrollo y aplicaci6n de sistemas
basados en Web complejos y a gran escala, existe una necesidad apremiante de enfoques de ingenieria Web disci-
plinada y de mCtodos y herramientas nuevos para el desarrollo, empleo y evaluaci6n de sistemas y aplicaciones
basados en Web. Tales enfoques y tCcnicas deberan tener en cuenta las caracteristicas especiales en el medio nue-
vo, en 10s entomos y escenarios operativos, y en la multiplicidad de perfiles de usuario implicando todo ello un
reto adicional para el desarrollo de aplicaciones basadas en Web.
La Ingenieria Web (IWeb) esta relacionada con el establecimiento y utilizaci6n de principios cientificos, de
ingenieria y de gestion, y con enfoques sistematicos y disciplinados del Cxito del desarrollo, empleo y manteni-
miento de sistemas y aplicaciones basados en Web de alta calidad [MUR99].
No hay mucho que decir con respecto a1 hecho de que el mundo). De forma alternativa, una aplicaci6n se pue-
10s sistemas y las aplicaciones' basados en Web (nos de ubicar en una Intranet (implementando la comuni-
referiremos a estas como WebApps) son muy diferentes caci6n a travCs de redes de una organizaci6n) o una
de las otras categorias de software informatico que se Extranet (comunicaci6n entre redes).
tratan en el Capitulo 1. Powell resume las diferencias
basicas cuando afirma que 10s sistemas basados en Web
ccimplican una mezcla de publicaci6n impresa y desa-
rrollo de software, de marketing e informatica, de comu-
nicaciones internas y relaciones externas, y de arte y Los WebApps son intensivas de red, controlodos
tecnologia>>[POW98]. Los atributos siguientes se van por el contenido y en continuo evolucibn. Estos otributos
tienen un profundo impocto dentro de la formo
a encontrar en la gran mayoria de las ~ e b ~ ~ ~ s ~ :
en w e se llevo o cobo lo IWeb.
Intensivas de Red. Por su propia naturaleza, una
WebApp es intensiva de red. Reside en una red y debe Controlada por el contenido. En muchos casos, la
dar servicio alas necesidades de una comunidad diver- funci6n primaria de una WebApp es utilizar hiperme-
sa de clientes. Una WebApp puede residir en Internet dia para presentar a1 usuario el contenido de textos, gra-
(haciendo posible asi una comunicaci6n abierta por todo ficos, sonido y video.
En esta categoria se incluyen unos sitios Web cornpletos, funcio- En el context0 de este capitulo el terrn~no~~aplicacion Web))abar-
nalidad especializada dentro de 10s sitios Web y aplicaciones de pro- card todo, desde una pagina Web simple que podria ayudar a un con-
ceso de inforrnacion que residen en Internet, en una lntranet o en surnidor a calcular el pago de un alquiler de un coche hasta un sitio
una Extranet. Web cornpleto que proporcione 10s sewicios cornpletos para viajes
de negocios y de vacaciones.
CAPiTULO 29 INGENIERfA WEB
Evolucibn continua. A diferencia del software de apli- medidas de seguridad en toda la infraestructura que apo-
caciones convencional, que evoluciona con una sene de ya una WebApp y dentro de la misma aplicacion.
versiones planificadas y cronologicamente espaciadas, Este'tica. Una parte innegable del atractivo de una
las aplicaciones Web estin en constante evolucion. No WebApp es su apariencia e interaccion. Cuando se ha
es inusual que algunas WebApps (especificamente, su disefiado una aplicaci6n con el fin de comercializarse o
contenido) se actualicen cada hora. vender productos o ideas, la estktica puede tener mucho
Algunos argumentan que la evolucion continua de que ver con el Cxito del disefio tCcnico.
las WebApps hace que el trabajo realizado en ellas sea Las caracteristicas generales destacadas anterior-
similar a la jardineria. Lowe [LOW991 trata este tema mente se aplican a todas las WebApps, per0 con un gra-
con el siguiente escrito: do diferente de influencia. Las categorias de aplicaciones
La ingenieria esta a punto de adoptar un enfoque cienti- que se enumeran a continuation son las m8s frecuentes
fico y consecuente, suavizado por un context0 especifico y en el trabajo de la Web [DAR99]:
practico, para el desarrollo y el comisionado de sistemas y
aplicaciones. El desarrollo de 10s sitios Web suele estar des- informativa: se proporciona un contenido solo de lec-
tinado a crear una infraestructura (sembrar el jardin) y enton- tura con navegacion y enlaces simples;
ces ccocuparse,, de la informaci6n que crece y brota dentro descarga: un usuario descarga la informaci6n desde
del jardin. DespuCs de un tiempo, el jardin (es decir, el sitio
Web) continuara evolucionando, cambiando y creciendo. el servidor apropiado;
Una buena arquitectura inicial deberi permitir que este cre-
cimiento ocurra de forma controlada y consecuente.. .podri- ~ C O se~ pueden
O
amos hacer que cctres cirujanosn podaran 10s .arboles>>(es categorizar las WebApps?
decir, las secciones del sitio Web) dentro del jardin (el sitio
en si) a la vez se asegura la integridad de las referencias cru-
zadas. Podriamos disfrutar de ccguarderias de jardinr donde personalizable: el usuario personaliza el contenido
ccse cultiven,, las plantas j6venes (es decir, las configuracio- a sus necesidades especificas;
nes de diseiio para sitios Web). Acabemos con esta analogia, interaccidn: la comunicacion entre una comunidad
no vaya a ser que vayamos demasiado lejos.
de usuarios ocurre mediante un espacio chat (charla),
Un cuidado y una alimentaci6n continua permite que tablones de anuncios o mensajeria instantinea;
un sitio Web crezca (en robustez y en importancia). Pero entrada del usuario: la entrada basada en formula-
a diferencia de un jardin, las aplicaciones Web deben rios es el mecanismo primario de la necesidad de
de servir (y adaptarse a) las necesidades de mis de un comunicaci6n;
jardinero. Las siguientes caracteristicas de WebApps
orientada a transacciones: el usuario hace una soli-
son las que conducen el proceso:
citud (por ejemplo, la realization un pedido) que es
Inmediatez. Las aplicaciones basadas en Web tienen cumplimentado por la WebApp;
una inmediatez [NOR991 que no se encuentra en otros
tipos de software. Es decir, el tiempo que se tarda en orientado a servicios: la aplicacion proporciona un
comercializar un sitio Web completo puede ser cuestion servicio a1 usuario, por ejemplo, ayuda a1 usuario a
de dias o semanas'. Los desarrolladores deberin utili- determinar un pago de hipoteca;
zar 10s mCtodos de planificacion, anilisis, disefio, imple- portal: la aplicacion canaliza a1 usuario llevindolo
mentaci6n y comprobaci6n que se hayan adaptado a a otros contenidos o servicios Web fuera del domi-
planificaciones apretadas en tiempo para el desarrollo nio de la aplicacion del portal;
de WebApps. acceso a bases de datos: el usuario consulta en una
base de datos grande y extrae information;
almacenes de datos: el usuario hace una consulta en
una colecci6n de bases de datos grande y extrae infor-
No hay dudo de que lo inmediotez o menudo prevolece
en el desorrollo de 10s WebApps, pero hay que tener
maci6n.
cuidodo, porque el hecho de hocer alga rapidomente Las caracteristicas y las categorias destacadas ante-
no significa tener el privilegio de hocer un trobojo riormente en esta section, y las categorias de aplica-
de ingenierio pobre. Lo rapido y erroneo roros veces ciones representan 10s hechos reales para 10s ingenieros
tiene un resultado oceptoble. de la Web. La clave es vivir dentro de las restricciones
impuestas por las caracteristicas anteriores y aun asi
Seguridad. Dado que las WebApps estin disponibles tener Cxito en la elaboration de la WebApp.
a travCs del acceso por red, es dificil, si no imposible,
limitar la poblacion de usuarios finales que pueden acce-
der a la aplicaci6n. Con objeto de proteger el conteni- 29.1.1. Atributos de calidad
do confidencial y de proporcionar formas seguras de Todas las personas que hayan navegado alguna vez por la
transmisi6n de datos, deberin implementarse fuertes Web o hayan utilizado una intranet de una c o m p ~ ' apue-
Paginas Web sofisticadas pueden elaborarse en pocas horas

den opinar sobre lo que hace una <<buena>> WebApp. Los Desarrollo basado en componentes
.uuntos de vista individuales varian enormemente. Algu- - Las tecnologias de componentes estudiadas en 10s Capi-
-
nos usuarios disfrutan con maficos llamativos, en cambio tulos 27 y 28 han evolucionado en gran parte gracias al
otros solo quieren un texto sencillo.Algunos exigen infor- crecimiento explosivo de 10s sistemas y aplicaciones
maci6n copiosa, otros desean una presentacion abreviada. basados en Web. Retomando el estudio del capitulo ante-
En efecto, la percepci6n de <<lobueno, por parte del usua- rior, 10s ingenieros Web disponen de tres estandares
rio (y como consecuencia, la aceptaci6n o no aceptacion importantes para la infraestructura: CORBA,
resultante de la WebApp) pdriaser mhs importante que COM/DCOM y JavaBeans. Estos estandares (acompa-
cualquier discusi6n tCcnica sobre la calidad de la WebApp. iiados por 10s componentes preconstruidos, herramientas
Pero jc6m0 se percibe la calidad de la WebApp? y tCcnicas) proporcionan una infraestructura que permite
L ~ U Catributos deben de exhibirse ante 10s ojos de 10s a 10s que diseiian emplear y personalizar componentes de
usuarios para lograr lo bueno y a1 mismo tiempo exhi- terceras partes permitiCndoles asi comunicarse unos con
bir las caracteristicas tCcnicas de calidad que permitan otros y con servicios a nivel de sistemas.
a un ingeniero corregir, adaptar, mejorar y soportar la
aplicaci6n a largo plazo?
Arbol detallado de 10s requisitos

de calidad poro WebApps
En realidad, todas las caracteristicas generales de la

calidad del software estudiadas en 10s Capitulos 8, 19
y 24 se aplican tambiCn a las WebApps. Sin embargo, Seguridad
las caracteristicas mas relevantes -usabilidad, fiabili- Si en una red reside una WebApp, Csta esta abierta a un
dad, eficiencia y capacidad de mantenimiento- pro- acceso sin autorizaci6n. En algunos casos, ha sido el per-
porcionan una base util para evaluar la calidad de 10s sonal intemo el que ha intentado acceder sin autorizacion.
sistemas basados en Web. En otros casos, intrusos (hackers) pueden intentar acce-
Olsina y sus colaboradores [OSL99] han preparado der por deporte, por sacar provecho o con intenciones mas
un <<iirbolde requisitos de calidad>>que identifica un maliciosas. Mediante la infraestructura de red se propor-
conjunto de atributos que conduce a w e b ~ p p des alta ciona una variedad de medidas de seguridad, tales como
calidad. La Figura 29.1 resume su trabajo. - encriptacibn, cortafuegos y otras. Un estudio amplio de
este tema queda fuera del h b i t o de este libro. Para mas
informaci6n, el lector interesado puede consultar en esta
bibliografia: [ATK97], [KAE99] y [BRE99].
Estandares de Internet
Durante la ultima dCcada el estandar dominante en la
creacion del contenido y la estructura de la WebApp ha
sido HTML, un lenguaje de marcas que posibilita al desa-
rrollador proporcionar una serie de etiquetas que des-
criben una gran variedad de objetos de datos (texto,
graficos, audiolvideo, formularios, etc.). Sin embargo, a
medida que las aplicaciones crecen en tamaiio y com-
plejidad, se ha adoptado un nuevo esthdar -XML-
para la proxima generaci6n de WebApps. XML
(Extensible Markup Language) el Lenguaje de marcas
FIGURA 29.1. Arb01 de requisitos de calidad (OSL 99). extensible es un subconjunto estrictamente definido del
metalenguaje SGML [BRA97], permitiendo que 10s dise-
29.1.2. Las tecnologias iiadores definan etiquetas personalizadas en las descrip-
El diseiio y la implementation de sistemas basados en ciones de una pagina Web. Mediante una description del
Web incorporan tres tecnologias importantes: el desarro- metalenguaje XML,, el significado de las etiquetas per-
110 basado en componentes, la seguridad y 10s estandares sonalizadas se define en la informaci61-1transmitida a1
de Internet. Un ingeniero Web debera estar familiarizado sitio del cliente. F'ara miis informaci6n sobre XML, el
con las tres para construir WebApps de alta calidad. lector interesado debera consultar [PAR991 y [STL99].
Las caracteristicas de sistemas y aplicaciones basados suelen ser controladas por el contenido haciendo hin-
en Web influyen enormemente en el proceso de IWeb. capiC en la estCtica, es probable que las actividades de
La inmediatez y la evolucidn continuan dictando un desarrollo paralelas se planifiquen dentro del proceso
modelo de proceso incremental e interactivo (Capitulo IWeb y necesiten un equipo de personas tanto tCcnicas
2) que elabora versiones de WebApps muy rapidamen- como no (por ejemplo, redactores publicitarios, dise-
te. La naturaleza intensiva de red de las aplicaciones en Aadores graficos).
este dominio sugiere una poblacidn de usuarios diver-
sa (exigiendo especialmente la obtencidn y modelado g
de requisitos), y una arquitectura de aplicacion que pue- CLAVE
da ser altamente especializada (realizando de esta mane- Lo lWeb demondo un proceso de softwore
ra exigencias en el diseiio). Dado que las WebApps increment01y evolutivo
IWEB
A medida que la evolution de las WebApps pasa de uti- tos tCcnicos para la WebApp e identifica 10s elementos
lizar recursos estaticos de informacidn controlada por del contenido que se van a incorporar. TambiCn se defi-
el contenido a utilizar entornos de aplicaciones din& nen 10s requisitos del diseiio grafico (estCtica).
micos controlados por el usuario, cada vez es mas impor- La actividad de ingenieria incorpora dos tareas para-
tante la necesidad de aplicar una gestion s6lida y unos lelas, como se muestra a la derecha en la Figura 29.2. El
principios de ingenieria. Para conseguir esto, es nece- disefio del contenido y la produccibn son tareas lleva-
sario desarrollar un marco de trabajo IWeb que acom- das a cab0 por personas no tCcnicas del equipo IWeb. El
paiie a un modelo de proceso eficaz, popularizado por objetivo de estas tareas es diseiiar, producir, y/o adqui-
las actividades4 del marco de trabajo y por las tareas de rir todo el contenido de texto, grafico y video que se
ingenieria. En la Figura 29.2 se sugiere un modelo de vayan a integrar en la WebApp. A1 mismo tiempo, se lle-
proceso para IWeb. va a cab0 un conjunto de tareas de diseiio (Seccion 29.5)
El proceso IWeb comienza con laformulacibn -acti- La generacibn de pciginas es una actividad de cons-
vidad que identifica las metas y 10s objetivos de la WebApp truccidn que hace mucho uso de las herramientas auto-
y establece el imbito del primer increment-. matizadas para la creaci6n de la WebApp. El contenido
definido en la actividad de ingenieria se fusiona con 10s
diseiios arquitectonicos,de navegacidn y de la interfaz para
elaborar paginas Web ejecutables en HTML, XML y otros
lenguajes orientados a procesos (por ejemplo, Java). Duran-
te esta actividad tambiCn se lleva a cab0 la integracidn con
el software intermedio (middleware) de componentes (es
decir, CORBA, DCOM o JavaBeans). Las pruebas ejer-
citan la navegacion, intentan descubrir 10s errores de las
applets, guiones y formularies, y ayuda a asegurar que la
la interfaz WebApp funcionara correctamente en diferentes entomos
(por ejemplo, con diferentes navegadores).
FIGURA 29.2. E l modelo de proceso IWeb.
La planijicacibn estima el coste global del proyecto,

3
Referencia Web
W3C es un consorcio de industrio que proporciono
occeso o informocion WWW de interk
evalua 10s riesgos asociados con el esfuerzo del desa- poro 10s ingenieros de Web, y se puede encontror
rrollo, y define una planificacion del desarrollo bien gra- en lo direccibn www.w3.org
nulada para el incremento final de la WebApp, con una
planificacion mas toscamente granulada para 10s incre- Cada incremento producido como parte del proceso
mentos subsiguientes. El ancilisis establece 10s requisi- IWeb se revisa durante la actividad de evaluacibn del
Retomando el estudio de 10s modelos de proceso del Capitulo 2, las

actividades del marco de trabajo se realizan para todas las WebApps,
mientras que las tareas se adaptan al tamafio y a la cornplejidad de
la WebApp que se va a desarrollar.
cliente. Es en este punto en donde se solicitan cambios se integran en la siguiente ruta mediante el flujo incre-
(tienen lugar ampliaciones del imbito). Estos cambios mental del proceso.
La formulacion y el anilisis de sistemas y aplicaciones en zonas geogrhficas en donde actualmente no tenemos alma-
basados en Web representan una sucesi6n de activida- cenes de ventas.
des de ingenieria Web que comienza con la identifica- Finalmente, la compaiiia define la demografia para
ci6n de metas globales para la WebApp, y termina con la WebApp: ccLos usuarios potenciales de HogarSegu-
el desarrollo de un modelo de anilisis o especificaci6n roInc.com son propietarios de casas y de negocios
de 10s requisitos para el sistema. La formulaci6n per- pequeiios.>>
mite que el cliente o diseiiador establezca un conjunto Las respuestas que se han establecido anteriormen-
c o m ~ nde metas y objetivos para la construcci6n de la te implican metas especificas para el sitio Web Hogar-
WebApp. TambiCn identifica el fimbito de esfuerzo en SeguroInc.com. En general, se identifican dos categonas
el desarrollo y proporciona un medio para determinar [GNA99]:
un resultado satisfactorio. El anhlisis es una actividad Meras informativas: indican la intencion de propor-
tecnica que identifica 10s datos y requisitos funcionales
cionar el contenido y/o informaci6n especificos para
y de comportamiento para la WebApp. el usuario final.
Metas aplicables: indican la habilidad de realizar
Powell [POW981 sugiere una serie de preguntas que algunas tareas dentro de la WebApp.
deberh formularse y responderse a1 comienzo de la eta-
pa de formulaci6n:
~ C u ies
l la motivaci6n principal para la WebApp?
LPor quC es necesaria la WebApp? Para todo WebApp deberbn definirse metos
~QuiCnva a utilizar la WebApp? informotivos y oplitobles.
i Q ~ preguntas
e En el contenido de la Web HogarSeguroInc.com,una
se deberian hater meta informativa podria ser la siguiente:
para formular el problema?
El sitio proporcionara a 10s usuarios especificaciones de un
producto detallado,como descripcibn tttcnica, instruccionesde
La respuesta a estas preguntas deberh ser de lo mhs instalaci6n e informaci6n de precios.
sucinto posible. Por ejemplo, supongamos que el fabri-
cante de sistemas de seguridad en el hogar ha decidido El examen de las respuestas anteriores llevari a
poderse aplicar la afirmaci6n de meta siguiente:
establecer un sitio Web de comercio electr6nico para
vender sus productos directamente a 10s consumidores. HogarSeguroInc.com consultar6 a1 cliente sobre la ins-
Una frase que describiera la motivaci6n de la WebApp talaci6n (es decir, sobre la casa, oficina/almacttn minoris-
ta) que se va a proteger, y dara recomendaciones per-
podna ser la siguiente: sonalizadas sobre el producto y la configuraci6n que se va
HogarSegurolnc.com5permitira a 10s consumidores confi- utilizar.
gurar y comprar todos 10s componentes necesarios para insta-
lar un sistema de seguridad en casa o en su comercio. Una vez que han identificado todas las metas apli-
Es importante destacar que en esta frase no se ha pro- cables e informativas se desarrolla el perfil del cliente.
porcionado n i n g ~ ndetalle. El objetivo es delimitar la El perfil del usuario recoge cclas caracteristicas rele-
intenci6n global del sitio Web. vantes de 10s usuarios potenciales incluyendo antece-
DespuCs de discutir con otros propietarios de Hogar- dentes, conocimiento, preferencias e incluso m i s s
Seguro Inc., la segunda pregunta se podna contestar de [GNA99]. En el caso de HogarSeguroInc.com, el per-
la siguiente manera: fil de usuario identificarfi las caracteristicas de un com-
prador tipico de sistemas de seguridad (esta informaci6n
HogarSeguroInc.com nos permitiri vender directamente a
10s consumidores,eliminando por tanto 10s costes de interme- sena proporcionada por el departamento de marketing
diarios, y mejorando de esta manera 10s mirgenes de benefi- de HogarSeguroInc.com).
cios. TambiCn nos permitira aumentar las ventas en un 25 por Una vez que se han desarrollado las metas y 10s per-
100 por encima de las ventas anuales y nos permitira penetrar files de usuarios, la actividad de formulaci6n se centra en
HogarSeguro ya se ha utilizado anteriormente como ejemplo en el

libro.
C A P ~ T U L O29 INGENIERIA WEB
la afirmacidn del hmbito para la WebApp (Capitulo 5).

En muchos casos, las metas ya desarrolladas se integran
en la afirmaci6n del Ambito. Ademas es M , no obstan-
te, indicar el grado de integration que se espera para la
WebApp. Es decir, a menudo es necesario integrar 10s
sistemas de informaci6n existentes (por ejemplo, la apli-
cacidn de base de datos existente) en un planteamiento
basado en Web. En este punto se tienen en consideracidn
tambiCn 10s temas de conectividad.
29.4.2. Analisis
Los conceptos y principios que se trataron para el ani- de procesamiento. Aqui se realiza una descripci6n deta-
lisis de 10s requisitos del software (Capitulo 11) se apli- llada de todas las funciones y operaciones.
can sin revision en la actividad de analisis de ingenieria Analisis de la configuration. Se efect6a una des-
Web. Para crear un modelo de analisis completo para la cripci6n detallada del entorno y de la infraestructura en
WebApp se elabora el ambit0 definido durante la acti- donde reside la WebApp. La WebApp puede residir en
vidad de formulacion. Durante la IWeb se realizan cua- Internet, en una intranet o en una Extranet. Ademas, se
tro tipos de analisis diferentes: debera identificar la infraestructura (es decir, la infra-
Analisis del contenido. Se trata de la identificacion estructura de 10s componentes y el grado de utilizaci6n
del espectro completo de contenido que se va a pro- de la base de datos para generar el contenido) de la
porcionar. En el contenido se incluyen datos de texto, WebApp.
grificos, imagenes, video y sonido. Para identificar y Aun cuando se recomienda una especificacidn
describir cada uno de 10s objetos de datos que se van a detallada de 10s requisitos para WebApps grandes y
utilizar dentro de la WebApp se puede utilizar el mode- complejas, tales documentos no son 10s usuales. Se
lado de datos (Capitulo 12). puede decir que la continua evolucion de 10s requisi-
tos de la WebApp puede hacer que cualquier docu-
Analisis de la interaccion. Se trata de la descrip- mento se quede obsoleto antes de finalizarse. Aunque
cion detallada de la interaccion del usuario y la se puede decir que esto sucede de verdad, es necesa-
WebApp. Para proporcionar descripciones detalladas rio definir un modelo de analisis que pueda funcio-
de esta interaccion se pueden desarrollar casos pricti- nar como fundamento de la siguiente actividad de
cos (Capitulo 11). diseiio. Como minimo, la informacion recogida duran-
Analisis funcional. Los escenarios de utilizacion te las cuatro tareas de analisis anteriores debera ser
(casos de uso) creados como parte del analisis de inte- revisada, modificada a peticion, y organizada para
raccidn definen las operaciones que se aplicarhn en el formar un documento que pueda pasarse a 10s dise-
contenido de la WebApp e implicarh otras funciones Aadores de WebApps
La naturaleza de inrnediatez de las aplicaciones basadas en Con objeto de realizar un diseAo eficaz basado en
Web unida a la presidn de evolucionar continuamente obli- Web, el ingeniero deberfi trabajar reutilizando cuatro
ga a que un ingeniero establezca un disefio que resuelva el elementos tCcnicos [NAN98]:
p b l e m a comercial inmediato, mientras que a1mismo tiem- Principios y mktodos de diseno. Es importante des-
po obliga a definir una arquitectura de aplicacidn que ten- tacar que 10s conceptos y principios del disefio estu-
ga la habilidad de evolucionar ripidamente con el tiempo. diados en el Capitulo 13 se aplican a todas las WebApps.
El problema, desde luego, es que resolver (rapidamente) el La modularidad eficaz (exhibida con una cohesidn alta
problema inrnediato puede dar como resultado compromi- y con un acoplamiento bajo), la elaboracidn paso a paso,
sos que afectan a la habilidad que tiene la aplicacion de e v e y cualquier otra heuristica de disefio del software con-
lucionar con el paso del tiempo. ducira a sistemas y aplicaciones basados en Web mas
3
Referencia Web
Uno fuente volioso de linens generoles prbclicos
poro el diseiio de sitios Web se puede encontror en
ficiles de adaptar, mejorar, probar y utilizar.
Cuando se crean aplicaciones Web se pueden reutili-
zar 10s mktodos de diseiio que se utilizan para 10s siste-
mas orientados a objetos estudiados anteriormente en
este libro. La hipermedia define ccobjetos>>que interac-
www.ibm.com/ibm/eosy /design/lower/ t6an mediante un protocolo de comunicacidn algo simi-
f060100.html lar a la mensajena. De hecho, la notacidn de diagramas
propuesta por UML (Capitulos 21 y 22) puede adaptar- Una vez que se ha especificado una plantilla, cualquier par-
. se y utilizarse durante las actividades de diseiio de las te de una estructura hipermedia que se acopla a esta plantilla
se podra generar o actualizar automiticamente llarnando sola-
WebApps. Ademhs, se han propuesto otros hipermedios mente a la plantilla con datos relevantes [para dar cuerpo a1
de metodos de diseiio (por ejemplo, [ISA95], [SCH96]). esquema]. La utilizaci6n de plantillas constructivas depende
irnplicitamente del contenido separado de 10s documentos hiper-
media, de la especificaci6ny de su presentaci6n: 10s datos fuen-
te se organizan en la estructura del hipertexto tal y como se
cspecifica en la plantilla
29.5.1. Diseiio arquitectbnico

El diseiio arquitect6nico para 10s sistemas y aplicacio-
nes basados en Web se centra en la definici6n de la
estructura global hipermedia para la WebApp, y en la
aplicaci6n de las configuraciones de diseiio y plantillas
constructivas para popularizar la estructura (y lograr la
reutilizaci6n). Una actividad paralela, llamada diserio
Reglas de oro. Las aplicaciones hipermedia inte- del contenido6, deriva la estructura y el formato deta-
ractivas (WebApps) llevan constmyendose ya hace una llados del contenido de la informaci6n que se presenta-
dCcada. Durante ese tiempo, 10s disefiadores han desa- r i como parte de la WebApp.
rrollado un conjunto de heuristicas de diseiio (reglas de
oro) que se podran volver a aplicar durante el diseiio de
aplicaciones nuevas.
l a mayorio de las estructuras de las WebApps
Configuraciones de diseno. Como se ha destacado simplemente aparecen. Evite esta trampa. Establezca
anteriormente en este libro, las configuraciones de dise- el diseria estructurol de la WebApp explkitamente
iio son un enfoque generic0 para resolver pequefios pro- antes de empezar a desarrollar 10s detalles de la pbgino
blemas que se pueden adaptar a una variedad mis amplia y de la navegacian.
de problemas especificos. En el context0 de las
WebApps, las configuraciones de diseiio se pueden apli- Estructuras de las WebApps
car no solo a 10s elementos funcionales de una aplica- La estructura arquitect6nica global va unida a las metas
cibn, sino tambiCn a 10s documentos, grificos y estetica establecidas para una WebApp, a1 contenido que se va
general de un sitio Web. a presentar, a 10s usuarios que la visitarhn y a la filoso-
Plantillas.Las plantillas se pueden utilizar para pro- fia de navegaci6n (Secci6n 29.5.3) establecidos. Cuan-
porcionar un marco de trabajo esquemitico de cualquier do el encargado de la arquitectura va a realizar el diseiio
configuraci6n de diseiio o documento a utilizar dentro de una WebApp tipica puede elegir entre cuatro fuen-
de una WebApp. Nanard y Kahn [NAN981 describen tes diferentes [POW98].
este elemento de diseiio reutilizable de la siguiente
manera: iCubles son las optiones
disponibles para el diseiio de
una ~ e b ~ p p .?
Las estructuras lineales (Fig. 29.3) aparecen cuan-

do es comun la sucesi6n predecible de interacciones
(con alguna variaci6n o diversificaci6n). Un ejemplo
clhsico podria ser la presentacidn de un manual de usua-
rio en la que las piginas de informaci6n se presentan
con grificos relacionados, videos cortos o sonido solo
despuCs de haber presentado un prerrequisito. La suce-
sion de presentation del contenido queda predefinida y
se puede decir que, generalmente, es lineal. Otro ejem-
Lineal con flujo Lineal plo podn'a ser la sucesi6n de una entrada de pedido de
Lineal con desviaciones
opcional
un product0 donde se tenga que especificar la informa-
Estructuras lineales. ci6n especifica en un orden especifico. En tales casos,
El disefio del contenido es una actividad no tecnica que llevan a

cab0 redactores publicitarios, artistas, diseiiadores graficos y otros
que generan el contenido de las WebApps. Para mas informacion.
vease [DIN981 y [LYN99].
C A P ~ T U L O 29 INGENIERIA WEB
las estructuras que se muestran en la Figura 29.3 son las del extremo izquierdo de la jerarquia puede tener enlaces
adecuadas. A medida que el contenido y el procesa- de hipertexto que lleven a1 contenido que existe en medio
miento crecen en complication, el flujo puramente line- de la rarna derecha de la estructura. Sin embargo, deberia
al que se muestra a la derecha da como resultado de destacarse que aunque dicha rarna permita una nave-
estructuras lineales mas sofisticadas en las que se pue- gaci6n rapida por el contenido de la WebApp, puede ori-
de invocar el contenido alternative, o en donde tiene ginar tambi~nconfusi6npor parte del usuGo.
lugar una desviacion para adquirir un contenido com-
plementario (la estructura se muestra a la derecha en la
Fig. 29.3).
El acop/omientoes un temo engarioso para
lo orquitecturo de 10s WebApps. Por un lodo, focilito
lo novegocian. Pero, par a h , tombien puede hocer
que el usuorio ((se pierdo). No rehogo canexiones
horizontoles dentro de uno jerorquio.
FIGURA 29.4. Estructura reticular.

Las estructuras reticulares (Fig. 29.4) son una opcion
arquitectonica que puede aplicarse cuando el contenido
de la WebApp puede ser organizado categoricamente en
dos dimensiones (o mas). Por ejemplo, consideremos una FIGURA 29.5. Estructurasjerarquicas.
situation en la que un sitio de comercio electronico ven-
de palos de golf. La dimension horizontal de la reticula Una estructura en red o de <<webpura>>(Fig. 29.6)
representa el tipo de palo en venta (por ejemplo, made- se asemeja en muchos aspectos a la arquitectura en evo-
ras, hierros, wedges, putters). La dimension vertical repre- lucion para 10s sistemas orientados a objetos. Los com-
senta la oferta proporcionada por 10s fabricantes de palos ponentes arquitectonicos (en este caso las paginas Web)
de golf. De aqui que un usuario pueda navegar por la reti- se disefian de forma que pueden pasar el control
cula horizontalmente para encontrar la columna de 10s (mediante enlaces de hipertexto) a otros componentes
putters, y recorrer la columna para examinar las ofertas del sistema. Este enfoque permite una flexibilidad de
proporcionadas por 10s vendedores de putters. Esta arqui- navegacion considerable, aun cuando puede resultar
tectura WebApp es de utilidad solo cuando se encuentra confuso para el usuario.
un contenido muy regular [POW98].
las estructuros reticulares funcionan bien cuondo

el contenido puede organizorse cotegoricomente
en dos dirnensiones o mus.
Las estructurasjerarquicas (Fig. 29.5) son sin duda la

arquitectura WebApp mas comun. A diferencia de la divi-
sion de jerarquias de software estudiadas en el Capitulo
14, que fomentan el flujo de control solo a lo largo de las
ramas verticales de la jerarquia, se podri disefiar una
estructura jerhrquica de la WebApp para posibilitar (por FIGURA 29.6. Estructura en red o ((webpura)).
medio de la ramificacion de hipertexto) el flujo de con-
trol en horizontal atravesando las ramas verticales de la Las estructuras arquitectonicas estudiadas en 10s
estructura. Por tanto, el contenido presentado en la rama pkafos anteriores se pueden combinar para formar estruc-
turas compuestas. La arquitectura global de una WebApp Tamiz: una configuracion que va guiando a1 usuario
puede ser jerhrquica, per0 parte de la estructura puede a travCs de una serie de opciones (decisiones) con el
exhibir caracten'sticas lineales, mientras que otra parte de fin de llevar a1 usuario a un contenido especifico e
la arquitectura puede confeccionarse en red. La meta del indicado por la sucesion de opciones elegidas o deci-
diseiiador arquitectonico es hacer corresponder la estruc- siones tomadas.
tura de la WebApp con el contenido que se va a presen- Vecindario: una configuracion que abarca un marco
tar y con el procesamiento que se va a llevar a cabo. de navegacion uniforme por todas la paginas Web
Patrones de diseno para permitir que un usuario tenga una guia de nave-
Como se ha destacado anteriormente en este mismo gacion consecuente independientemente de la loca-
libro, 10s patrones de disefio son un buen mktodo para lizaci6n de la WebApp.
resolver pequeiios problemas que pueden adaptarse a Las configuraciones de diseiio de hipertexto que se
una variedad mucho mas amplia de problemas especi- han descrito anteriormente se pueden reutilizar a medi-
ficos. En el context0 de 10s sistemas y aplicaciones basada que el contenido va adquiriendo el formato que per-
dos en Web, 10s patrones de diseiio pueden aplicarse en mitira la navegacion a travts de una WebApp.
el nivel jerarquico, nivel de componentes y nivel de
hipertexto (de navegacion).
29.5.2. Disefio de navegacion
Una vez establecida una arquitectura de WebApp, una
En 10s Capitulos 14 y 22 se puede enconhar m6s vez identificados 10s componentes (paginas, guiones,
informaci6n sabre las configurociones de diseiio. applets y otras funciones de proceso) de la arquitectu-
ra, el disefiador deberi definir las rutas de navegacion
Cuando dentro de una WebApp se requiere la fun- que permitan a1 usuario acceder a1 contenido y a 10s ser-
cionalidad del proceso de datos, pueden aplicarse 10s vicios de la WebApp. Para que el diseiiador pueda lle-
patrones de disefio arquitect6nicas a nivel de compo- varlo a cabo, debe (1) identificar la semantics de la
nentes propuestas por [BUS96], [GAM95] y otros. Los navegacion para diferentes usuarios del sitio; y (2) defi-
patrones de disefio a nivel de hipertexto se centran en nir la mecanica (sintaxis) para lograr la navegacion.
el diseiio de las caracteristicas de navegacion que per- Generalmente una WebApp grande tendra una varie-
miten a1 usuario moverse por el contenido de la WebApp dad de roles de usuarios diferentes. Por ejemplo, 10s
ficilmente. Entre muchos de 10s patrones de disefio de roles podrian ser el de x~isitante,cliente registrado o
hipertexto propuestos en literatura sobre este tema se cliente privilegiado. Cada uno de estos roles se pueden
encuentran 10s siguientes [BER98]: asociar a diferentes niveles de acceso a1 contenido y de
Ciclo: una configuracion que devuelve a1 usuario a1 servicios diferentes. Un xisitante puede tener acceso
nodo de contenido visitado anteriormente. s610 a un contenido limitado, mientras que un cliente
registrado puede tener acceso a una variedad mucho
miis amplia de informacion y de servicios. La semin-
tica de la navegacion de cada uno de estos roles seria
diferente.
El disefiador de WebApps crea una unidad semanti-
ca de navegacidn (USN) para cada una de las metas aso-
ciadas a cada uno de 10s roles de usuario [GNA99]. Por
ejemplo, un cliente registrado puede tener seis metas
diferentes, todas ellas con un acceso a informacion y
Anillo de Web: una configuracion que implementa sewicios diferentes. Para cada meta se crea una USN.
un ccgran ciclo que enlaza hipertextos enteros via- Gnaho y Larcher [GNA99] describen la USN de la
jando por un terns,) [BER98]. siguiente manera:
Contorno: un patr6n que aparece cuando varios ciclos La estructura de una USN se compone de un conjunto de
inciden en otro, permitiendo navegar por rutas defi- subeshucturasde navegaci6n que Ilamamos,formas de nave-
nidas por 10s ciclos. gacidn [WON (Ways of navigating)]. Una WON representa
Contrapunto: un patron que aiiade comentarios de la mejor forma de navegaci6n o ruta para que usuarios con
hipertexto interrumpiendo la narrativa del contenido ciertos perfiles logren su meta o submeta deseada. Por tan-
to, el concepto de WON se asocia a1 concepto de Perfil de
para proporcionar mas informacion o mas indagacion. Usuario.
Mundo de espejo: el contenido se presenta utilizando
diferentes hilos narrativos, cada uno con un punto de La estructura de una WON se compone de un conjunto de
nodos de na,.egacidn (NN) relevantes conectados a enlaces
vista o perspectiva diferente. Por ejemplo, el conte- de navegacidn, entre 10s que algunas veces se incluyen las
nido que describe una computadora personal podria USNs. Eso significa que las USNs pueden agregarse para
permitir a1 usuario seleccionar una narrativa crtkc- formar una USN de nivel superior, o anidarse en cualquier
nica>>o <<notCcnica)) que describa la maquina. nivel de profundidad.
C A P ~ T U L O29 I N G E N I E R h WEB
do, la sofisticacion de las capacidades, 10s servicios de

procesamiento y el beneficio global de la WebApp en
si, una interfaz con un disefio pobre decepcionarh a1
Uno USN se compone de un coniunto de subestructuros usuario potencial y podrii de hecho hacer que el usua-
de novegacion llomodos aformas de navegoci6nr (WON). rio se vaya a cualquier otro sitio. Dado el gran volumen
Una USN represents una meta de navegoci6n especifico de WebApps que compiten virtualmente en todas las
para un tip0 especifico de usuario. areas temiticas, la interfaz debe ccarrastrar,, inmediata-
mente a1 usuario potencial. Nielsen y Wagner [NIE96]
Durante las etapas iniciales del diseiio de navega- sugieren unas cuantas lineas generales y sencillas en el
c i h , para determinar una o mas WoNs para cada meta redisefio de una WebApp:
de usuario, se evaluara la estructura de la WebApp Probabilidad de que 10s errores del servidor, incluso
(arquitectura y componentes). Como se ha destacado 10s mas pequefios, hagan que el usuario abandone el
anteriormente, una WON identifica 10s nodos de nave- sitio Web y busque informacion y servicios en algun
gaci6n (por ejemplo, paginas Web), y entonces 10s enla- otro sitio.
ces que hacen posible la navegaci6n entre ellos. La WON
entonces se organiza en USNs. iCuales son algunas
A medida que avanza el diseiio, se va identificando la de las lineas generales
mechnica de cada enlace de navegacion. Entre otras basicas para el diseiio
muchas opciones se encuentran 10s enlaces basados en de la interfaz de un sitio Web?
texto, iconos, botones, intemptores y metaforas graficas.
El disefiador debera elegir 10s enlaces de navegaci6n ade- La velocidad de lectura del monitor de una compu-
cuados para el contenido y consecuentes con la heuristi- tadora es aproximadamente un 25 por 100 mas lento
ca que conduce a1 disefio de una interfaz de alta calidad. que leer una copia impresa. Por tanto, no hay que obli-
Ademis de elegir la mecanica de navegacibn, el dise- gar a1 usuario a leer cantidades voluminosas de texto,
iiador tarnbiCn debera establecer las convenciones y ayu- particularmente cuando el texto explica la operacion
das adecuadas. Por ejemplo, 10s iconos y 10s enlaces de la WebApp o ayuda a navegar por la red.
graficos deberhn tener un aspect0 ccclickable (capacidad
de accederse),, con 10s bordes biselados, y dar asi una Evite 10s simbolos ((bajo construcci6n~-levantan
imagen en tres dimensiones. La realimentacion visual expectaci6n y provocan un enlace innecesario que
o de sonido se debera disefiar para proporcionar a1 usua- seguramente sea decepcionante-.
rio una indicacion de que se ha elegido una opcion de Los usuarios prefieren no tener que recorrer la pan-
navegacion. Para la navegaci6n basada en texto, se debe- talla. Dentro de las dimensiones normales de una
r6 utilizar el color que indica 10s enlaces de navegacion ventana del navegador se debera incluir informaci6n
y proporcionar una indicaci6n de 10s enlaces por 10s que importante.
se ha navegado. Estas son solo unas pocas convencio-
nes de las docenas que hacen que la navegaci6n por la Los menus de navegaci6n y las barras de cabecera se
red sea agradable. Ademas de las convenciones, en este deberan disefiar consecuentemente y deberin estar
punto tambiCn se deberan disefiar ayudas de navegaci6n disponibles en todas las paginas a las que el usuario
tales como mapas de sitios, tablas de contenidos, meca- tenga acceso. El diseiio no debera depender de las fun-
nismos de busqueda y servicios dinimicos de ayuda ciones del navegador para ayudar en la navegacion.
La estetica nunca debera sustituir la funcionalidad.
Por ejemplo, un b o t h sencillo podria ser una opci6n
29.5.3. Diseiio de la interfaz de navegacion mejor que una imagen o icono estk-
Los conceptos, principios y mCtodos de diseiios de inter- ticamente agradables, per0 vagos cuya intenci6n no
faz que se presentaron en el Capitulo 15 son todos apli- es muy clara.
cables a1 diseiio de interfaces de usuario para WebApps.
Sin embargo, las caracteristicas especiales de 10s siste-
mas y aplicaciones Web requieren otras consideracio-
nes adicionales. Referencia web/ '
Uno de 10s meiores grupos de recursos de usobilidod
de lo Web ha sido recogido por el Grupo de Usobilidad,
y se puede encontror en lo direcci6n
www.usobility.com/umi-linkshtm
Las opciones de navegacion deberan ser obvias,

incluso para el usuario casual. El usuario debera bus-
La interfaz de usuario de una WebApp es la aprimera car la pantalla para determinar c6mo enlazar con otro
impresion>>.Independientemente del valor del conteni- contenido o servicio.
1NGENIERfA DEL SOFTWARE. UN ENFOQUE PRACTICO
Una interfaz bien diseiiada mejora la percepci6n de las interfaces WebApp de usuario esta fuera
del contenido o de 10s servicios del usuario que pro- del imbito de este libro. Los lectores interesados
porciona el sitio Web. No tiene que ser necesaria- pueden consultar [SAN96], [FLE98], [ROS98], o
mente deslumbrante, per0 debera estar siempre bien [LYN99] entre 10s cientos de ofertas que existen
estructurada y ergonomica. Un estudio completo como guia.
28.6 P R R D
E
LN WEB
A
S
En el Capitulo 17, se destac6 que las pruebas son el proces de navegaci6n (Secci6n 29.5.2) son revisados
ceso de ejercitar el software con la intention de encon- para asegurar su correspondencia con 10s especifi-
trar (y por ultimo corregir) 10s errores. Esta filosofia cados en cada USN del rol de usuario.
fundamental no se cambiari para el caso de las WebApps. 3. Se aplican pruebas de unidad a 10s componentes de
De hecho, dado que 10s sistemas y aplicaciones basados proceso seleccionados y las pbginas Web. Cuando
en Web residen en una red e interoperan con muchos sis- lo que se tiene en consideration es el tema de las
temas operativos diferentes,navegadores, plataformas de WebApps el concept0 de unidad cambia. Cada una
hardware, y protocolos de comunicaci6n, la busqueda de de las paginas Web encapsular5 el contenido, 10s enla-
errores representa un reto significative para 10s ingenie- ces de navegacion y 10s elementos de procesamiento
ros Web. (formularios, guiones, applets). No siempre es posi-
iQue pasos hay que seguir ble o practico comprobar cada una de las caracteris-
para la comprobacib de una ticas individualmente. En muchos casos, la unidad
WebApp? comprobable mas pequeiia es la pagina Web. A dife-
rencia de la comprobacion de unidades de software
convencional, que tiende a centrarse en el detalle
El enfoque de las pruebas de las WebApps adopta 10s algoritmico de un m6dulo y 10s datos que fluyen por
principios bisicos de todas las pruebas del software (Capi- la interfaz del m6dul0, la comprobacion por paginas
tulo 17) y aplica estrategias y tacticas que ya han sido se controla mediante el contenido, proceso y enla-
recomendadas para 10s sistemas orientados a objetos (Capi- ces encapsulados por la pagina Web.
tulo 23). Este enfoque se resume en 10s pasos siguientes:
1. El modelo de contenido de la WebApp es revisadopara
descubrir errores. Esta actividad de c<prueba>> se ase- los estrutegias de integration se abarcon
meja en muchos aspectos a la de un corrector orto- en 10s Copltulos 18 y 23.
grifico de un documento escrito. De hecho, un sitio
Web grande tendra la capacidad de construir un lis-
4. Se construye la arquitectura, se realizan las pruebas
tad0 de 10s servicios de correctores profesionales para
de integracibn. La estrategia para la prueba de inte-
descubrir errores tipograficos, errores gramaticales,
graci6n depende de la arquitecturaque se haya elegido
errores en la consistencia del contenido, errores en
para la WebApp. Si la WebApp se ha diseiiado con una
representaciones graficas y de referencias cruzadas.
estructurajerkquica lineal, reticular o sencilla, es posi-
ble integrar paginas Web de una manera muy similar
a como se integran 10s m6dulos del software conven-
cional. Sin embargo, si se utiliza una jerarquia mez-
para 10s que clada o una arquitectura de red (Web), la prueba de
se sabe q u i integraci6n es similar a1 enfoque utilizado para 10s sis-
parh'cular, temas 0 0 . La comprobaci6n basada en hilos (Capi-
P P ~ v, se tulo 23) se puede utilizar para integrar un conjunto de
paginas Web (se puede utilizar una USN para definir
el conjunto adecuado) que se requiere para responder
a un suceso de usuario. Cada hilo se integra y se prueba
2. El modelo de diseiio para la WebApp es revisado individualrnente. La prueba de regresi6n se aplica para
para descubrir errores de navegacidn. Los casos asegurar que no haya efectos secundarios. La com-
practices derivados como parte de la actividad de probaci6n de agrupamientos integra un conjunto de
analisis pemite que un ingeniero Web ejercite cada paginas colaborativas (deteminadas examinando 10s
escenario de utilizaci6n frente a1 diseiio arquitect6- casos pricticos y la USN). Los casos de prueba se deri-
nico y de navegacion. En esencia, estas pruebas no van para descubrir errores en las colaboraciones.
ejecutables ayudan a descubrir errores en la nave- 5. La WebApp ensamblada se prueba para conseguir
gaci6n (por ejemplo, un caso en donde el usuario no una funcionalidad global y un contenido. A1 igual
pueda leer un nodo de navegaci6n). Ademas, 10s enla- que la validation convencional, la validaci6n de 10s
CAP~TULO
29 INGENIERIA WEB
sistemas y aplicaciones basados en Web se centra en cubrir 10s errores asociados con todas y cada una de
acciones visibles del usuario y en salidas reconoci- las configuraciones posibles.
bles para el usuario que procedan del sistema. Para 7. La WebApp se comprueba con una poblacidn de usua-
ayudar en la derivation de las pruebas de validation, riosfinales controlada y monitorizada. Se selecciona
las pruebas deberan basarse en casos prkticos. El un grupo de usuarios que abarque todos 10s roles posi-
caso prfictico proporciona un escenario con una pro- bles de usuarios. La WebApp se pone en prktica con
babilidad alta de descubrir errores en 10s requisitos estos usuarios y se evaluan 10s resultados de su inte-
de interaction del usuario. racci6n con el sistema para ver 10s errores de conte-
6. La WebApp se implementa en una variedad de con- nido y de navegacion, 10s intereses en usabilidad,
figuraciones diferentes de entornos y comprobar asi compatibilidad, fiabhdad y rendmiento de la WebApp.
la compatibilidad con cada configuracidn. Se crea Dado que muchas WebApps e s t b en constante evo-
una matriz de referencias cruzadas que define todos lucion, el proceso de comprobaci6n es una actividad
10s sistemas operativos probables, plataformas de continua, dirigida por un personal de apoyo a la Web
hardware para navegadores7 y protocolos de comu- que utiliza pruebas de regresi6n derivadas de pruebas
nicaci6n. Entonces se llevan a cab0 pruebas para des- desarrolladas cuando se cre6 la WebApp.
Dada la inmediatez de las WebApps, seria razonable ciplinas.. .>> Aun cuando 10s autores e s t b absolutamente
preguntarse: jnecesito realmente invertir tiempo esfor- en lo cierto, 10s ccrenacentistaw no disponen de muchas
zhndome con la WebApp? jno deberia dejarse que la provisiones, y dado las exigencias asociadas a 10s pro-
WebApp evolucionara de forma natural, con poca o nin- yectos importantes de desarrollo de WebApps, el conjun-
guna gesti6n explicita? Muchos diseiiadores de Webs to de conocimientos diversos necesario podri distribuirse
optarian por gestionar poco o nada, pero eso no hace incluso mejor dentro del equipo de IWeb.
que estCn en lo cierto.
La ingenieria Web es una actividad tCcnica com-
plicada. Hay muchas personas implicadas, y a menu-
do trabajando en paralelo. La combinaci6n de tareas
tCcnicas y no tCcnicas que deben de tener lugar (a tiem-
po y dentro del presupuesto) para producir una
WebApp de alta calidad representa un reto para cual-
quier grupo de profesionales. Con el fin de evitar cual- Los equipos de IWeb pueden organizarse de forma
quier confusi6n, frustraci6n y fallo, se debera poner muy similar a como se organizan 10s equipos de softwa-
en acci6n una planificaci6n, tener en cuenta 10s ries- re del Capitulo 3. Sin embargo, pueden existir diferen-
gos, establecer y rastrear una planificacidn temporal cias entre 10s participantes y sus roles. Entre 10s muchos
y definir 10s controles. Estas son las actividades clave conocimientos que deben distribuirse por 10s miembros
que constituyen lo que se conoce como gesti6n de pro- del equipo W e b se encuentran 10s siguientes: ingeniena
yectos. del software basada en componentes,realizacidn de redes,
disefio arquitect6nicoy de navegacibn, lenguajes y estAn-
dares de Internet, diseiio de interfaces para personas, dise-
10s acfividades asaciadas con la gestibn de proyectos fio grifico, disposici6n del contenido y pruebas de las
de software se estudiin en lo Parte Segunda WebApps. Los roles8siguientes deberb ser distribuidos
de este libro.
entre 10s miembros del equipo N e b :
29.7.1. El equipo de IWEB ~ Q u epapeles juegan

La creaci6n de una buena aplicaci6n Web exige un amplio las personas que forman
parte del equipo de IWeb?
abanico de conocimientos. Tilley y Huang [TIL99] se
enfrentan a este tema cuando afirman: <<Haymuchos Desarrolladores y proveedores de contenido. Dado
aspectos diferentes en relaci6n con el software de aplica- que las WebApps son controladas inherentemente por
ciones [Web] debido a1 resurgimiento del renacentista, el contenido, el papel de 10s miembros del equipo IWeb
aquel que se encuentra c6modo trabajando en varias dis- se centra en la generaci6n y/o recolecci6n del conteni-
LOSnavegadores son excelentes para implementar sus propias inter- Estos roles se han adaptado de Harsen y sus colaboradores [HAN99].
pretaciones lcestandar))ligeramente diferentes de HTML y Javascript.
Para un estudio de temas de compatibilidad, vease www.browser-
caps.com.
do. Retomando la idea de que el contenido abarca un el desarrollo e implementaci6n de normas para el
amplio abanico de objetos de datos, 10s diseiiadores y funcionamiento de la WebApp;
proveedores del contenido pueden proceder de diver- el establecimiento de 10s procedimientos de soporte
sos planos de fondo (no de software). Por ejemplo, el y realimentaci61-1;
personal de ventas o de marketing puede proporcionar 10s derechos de acceso y seguridad de la implemen-
informaci6n de productos e imageries gr8ficas: 10s pro- taci6n;
ductores de medios pueden proporcionar imagen y soni-
la medici6n y analisis del trafico del sitio Web;
do; 10s diseiiadores graficos pueden proporcionar diseiios
para composiciones graficas y contenidos estCticos; 10s la coordinaci6n de 10s procedimientos de control de
redactores publicitarios pueden proporcionar conteni- cambios (Secci6n 29.7.3);
do basado en texto. AdemAs, existe la posibilidad de la coordinaci6n con especialistas de soporte.
necesitar personal de investigacih que encuentre y dC El administrador tambiCn puede estar involucrado
formato a1 contenido externo y lo ubique y referencie en las actividades tCcnicas realizadas por 10s ingenie-
dentro de la WebApp. ros de Web y por 10s especialistas de soporte.
Editores de Web. El contenido tan diverso generado
por 10s desarrolladores y proveedores de contenido debe- 29.7.2. Gesti6n del proyecto
r i organizarse e incluirse dentro de la WebApp. Ademas, En la Parte Segunda de este libro se tuvieron en consi-
alguien debera actuar como conexion entre el personal deraci6n todas y cada una de las actividades global-
ticnico que disefia la WebApp y 10s diseiiadores y pro- mente llamadas gesti6n de proyectos9. Las metricas de
veedores del contenido. Esta funci6n la lleva a cab0 el procesos y proyectos, la planificaci6n de proyectos (y
editor de Web, quien debera entender la tecnologia tan- estimacibn), el anilisis y gestion de riesgos, la planifi-
to del contenido como de la WebApp en donde se inclu- caci6n temporal y el rastreo, SQA y CGS, se estudia-
ye el lenguaje HTML (o ampliaciones de generaciones ron en detalle. En teoria, la mayoria de las actividades
posteriores, tal como XML), la funcionalidad de bases de gesti6n de proyectos, si no todas, estudiadas en capi-
de datos y guiones, y la navegaci6n global del sitio Web. tulos anteriores, se aplican a 10s proyectos de Web. Pero
Ingeniero de Web. Un ingeniero Web cada vez se en la practica, el enfoque de IWeb para la gestion de
involucra mAs con la gran cantidad de actividades del proyectos es considerablemente diferente.
desarrollo de una WebApp entre las que se incluyen la En primer lugar, se subcontrata un porcentaje sus-
obtencion de requisitos, modelado de an6lisis, diseiio tancial1° de WebApps a proveedores que (supuesta-
arquitectdnico, de navegaci6n y de interfaces, implemente) son especialistas en el desarrollo de sistemas y
mentaci6n de la WebApp y pruebas. El ingeniero de Web aplicaciones basados en Web. En tales casos, un nego-
tambiCn debera conocer a fondo las tecnologias de com- cio (el cliente) solicita un precio fijo para el desarrollo
ponentes, las arquitecturas cliente/servidor, HTMLKML, de una WebApp a uno o mas proveedores, evallia 10s
y las tecnologias de bases de datos; y debera tener cono- precios de 10s candidatos y selecciona un proveedor para
cimiento del trabajo con conceptos de multimedia, pla- hacer el trabajo. Pero, es lo que busca la organi-
taformas de hardwarelsoftware, seguridad de redes y zacion contratista?, jc6m0 se determina la competen-
temas de soporte a 10s sitios Web. cia de un proveedor de WebApps?, jc6m0 se puede
saber si un precio es razonable?, jquC grado de planifi-
Especialistas de soporte. Este papel se asigna a la per- cacih, programacion temporal, y valoraci6n de riesgos
sona (personas) que tiene la responsabilidad de continuar se puede esperar a medida que una organizaci6n (y su
dando soporte a la WebApp. Dado que las WebApps eskh subconstratista) se va embarcando en un desarrollo
en constante evoluci6n, el especialista de soporte es el res- importante de WebApps'?
ponsable de las correcciones, adaptaciones y mejoras del En segundo lugar, el desarrollo de WebApps es una
sitio Web, donde se incluyen actualizaciones del conteni- Area de aplicaci6n relativamente nueva por tanto se pue-
do, implementaci6n de productos y formularies nuevos, den utilizar pocos datos para la estimaci6n. Hasta la
y cambios del patr6n de navegaci6n. fecha, no se ha publicado virtualmente ninguna mCtri-
Administrador. Se suele llamar Web master, y es el ca de IWeb. De hecho, tampoco han surgido muchos
responsable del funcionamiento diario de la WebApp, estudios sobre lo que esas metricas podrian ser. Por tan-
en donde se incluye: to, la estimaci6n es puramente cualitativa -basada en
9 Se recornienda que lectores no farniliarizados con 10s conceptos l o Aun cuando 10s datos de industria fiables son dificiles de encon-
basicos de gestion de proyectos revisen en este rnomento el Capi- trar, es seguro deck que este porcentaje es considerablernente mayor
tulo 3 . que el que s e encuentra en el trabajo del software convencional.
CAP~TULO
29 I N G E N I E R ~ AWEB
experiencias anteriores con proyectos similares-. Pero una WebApp con Cxito. Esta informacion debera de
casi todas las WebApps tienen que ser innovadoras documentarse en una especificaci6n del producto.
4 f r e c i e n d o algo nuevo y diferente a aquellos que la Se deberci desarrollar internamente un diseiio apro-
utilizan-. De aqui que la estimaci6n experimental, aun- ximado de la WebApp. Obviamente una persona
que sea 6ti1, esth abierta a errores considerables. Por experta en el desarrollo de WebApps crearh un disefio
consiguiente, jc6m0 se derivan estimaciones fiables?, completo, per0 puede ahorrar tiempo y dinero iden-
icon quC grado de seguridad pueden cumplirse 10s pro- tificando el aspect0 e interacci6n general de la
gramas temporales definidos? WebApp para el proveedor de subcontrataci6n (esto
En tercer lugar, el analisis de riesgos y la programa- siempre puede modificarse durante las etapas preli-
ci6n temporal se predican bajo un entendimiento claro minares del proyecto). El disefio deberi incluir la in&-
del Ambito del proyecto. Y sin embargo, la caracteristi- caci6n del proceso interactivo que se va a llevar a
ca de ccevoluci6n continuan tratada en la Secci6n 29.1 cab0 (por ejemplo, formularios, entrada de pedidos).
sugiere que el Ambito de la WebApp sea fluido. iC6m0 Se deberci desarrollar una planificacidn temporal apro-
pueden controlar 10s costes la organization contratista
ximada del proyecto, incluyendo no solo las fechas
y el proveedor subcontratado?, y jc6m0 pueden plani- finales de entrega. sino tambie'n lasfechas hito (signi-
ficar el momento en que es probable que 10s requisitos ficativas). Los hitos deberhn adjuntarse alas versiones
cambien drtisticamente a lo largo del proyecto?, jc6m0 de entrega posibles a medida que avanza el proyecto.
se puede controlar el cambio del Ambito?, y lo que es
mas importante, dado su naturaleza ideberan contro- Se dehera identificar el grado de supervisidn e itzte-
larse 10s sistemas y aplicaciones basados en Web ? raccidn del contratista con el proveedor. Deberti
Llegado a este punto de gesti6n de proyectos para incluirse el nombre del contacto del proveedor y la
WebApps, las preguntas que se han formulado por las identificaci6n de la responsabilidad y autoridad del
diferencias destacadas anteriormente no son fhciles de contacto, la definici6n de 10s puntos de revision de
responder. Sin embargo, merece la pena tener en con- calidad a medida que el desarrollo va avanzando, y
sideraci6n una serie de lineas generales. la responsabilidad de 10s proveedores en relaci6n con
la comunicaci6n entre organizaciones.
Inicio de un proyecto. Aun cuando la subcontrata-
Toda la informacion desarrollada en 10s pasos ante-
ci6n sea la estrategia elegida para el desarrollo de
riores debera de organizarse en una solicitud de opcio-
WebApps, una organizaci6n debera realizar una serie
tzes que se transmite a 10s proveedores candidatos".
de tareas antes de buscar el proveedor de subcontrata-
ci6n para hacer el trabajo.
I . Muchas de las actividades de ancilisis tratadas en la
Seccidn 29.3 se debercin realizar internamente. Se
identifica el piiblico de la WebApp; se confecciona un
listado de aquellos con intereses internos en la
WebApp; y se definen y revisan las metas globales de
la WebApp; se especifica tanto la informaci6n como Selection entre 10s proveedores de subcontrata-
10s servicios que se van a proporcionar en la WebApp; cion candidatos. En 10s 6ltimos afios han surgido miles
se destacan 10s sitios Web rivales, y se definen las de compaiiias de d s e f i o Webn para ayudar a las empre-
<<medidas>> cuantitativas y cualitativas para obtener sas a establecer una presencia y/o implicacidn Web en
el comercio electr6nico. Muchas han llegado a tener
adicci6n por el proceso Web, mientras que otras muchas
se asemejan a 10s intrusos informhticos (hackers). Con
objeto de seleccionar el desarrollador de Web candida-
to, el contratista debera llevar a cab0 una diligencia obli-
gada: (1) entrevistar a 10s clientes antiguos para
determinar la profesionalidad del proveedor de Web, la
habilidad de cumplir 10s compromisos de horarios y cos-
tes, y la habilidad de comunicarse eficazmente; (2) deter-
minx el nombre del ingeniero jefe de Web del proveedor
de proyectos anterior con Cxito (y despuCs cerciorarse
de que esta persona se vea obligada mediante contrato
a su implicaci6n en el proyecto), y (3) examinar cuida-
dosamente las muestras de trabajo del proveedor simi-
I I Si el trabajo de desarrollo de la WebApp e s dirigida por un grupo

intemo, nada cambia. El proyecto se inicia de la misma manera.
lares en aspect0 e interaccidn (y en k e a de negocios) a <<temporalmente>>. Este enfoque hace posible que el equi-
. la WebApp que se va a contratar. Antes incluso de que po de la WebApp trabaje sin tener que aceptar una comen-
se vaya a establecer la oferta, una reuni6n cara a cara te continua de carnbios, pero reconociendo la caracteristica
puede proporcionar una buena impresidn para que el de evolucidn continua de la mayoria de las WebApps.
contratista y el proveedor conecten bien. Las lineas generales sugeridas anteriormente no pre-
Evaluacion de la validez de las ofertas de precios tenden ser un recetario a prueba de tontos para WebApps
y de la fiabilidad de las estimaciones. Dado que exis- puntuales y con una produccidn a un coste bajo. Sin
ten muy pocos datos histdricos y el imbito de las embargo, ayudarin tanto a1 contratista como a1 provee-
WebApps es notoriamente fluido, la estimacidn es inhe- dor a iniciar el trabajo suavemente con unos conoci-
rentemente arriesgada. Por esta razdn algunos provee- mientos minimos.
dores incorporarin mirgenes sustanciales de seguridad
en las ofertas de precios de un proyecto. Evidentemen- 29.7.3. Problemas GCS para la IWEb
te esto es comprensible y adecuado. La pregunta no es Durante la 6ltima dCcada, las WebApps han evolucio-
si tenemos la mejor solucidn para nuestra inversidn, sino nado y han pasado de utilizar dispositivos informales
la serie de preguntas que se muestran a continuaci6n: para la difusidn de informacidn a utilizar sitios sofisti-
iEs el coste acordado una buena oferta para propor- cados para el comercio electrbnico. A medida que las
cionar un beneficio direct0 o indirect0 sobre la inver- WebApps van creciendo en importancia para la super-
sidn y justificar asi el proyecto? vivencia y el crecimiento de 10s negocios, tambiCn cre-
iEs el proveedor de la oferta una muestra clara de la ce el control de la configuraci6n. iPor quC? Porque sin
profesionalidad y experiencia requeridos? controles eficaces cualquier cambio inadecuado en una
Si la respuesta es xsi,,, el precio ofertado es justo. WebApp (recordemos que la inmediatez y la evolucidn
continua son 10s atributos dominantes de muchas
El grado de gestion del proyecto que se puede espe- WebApps) puede conducir a: (1) una ubicaci6n no auto-
rar o realizar. La formalidad asociada con las tareas de rizada de la informacidn del product0 nuevo; (2) una
gestidn del proyecto (llevadas a cab0 tanto por el provee- funcionalidad err6nea y pobremente comprobada que
dor como por el contratista) es directamente proporcional frustra a 10s visitantes del sitio Web; (3) agujeros de
a1 tamaiio, coste y complejidad de la WebApp. Para pro- seguridad que ponen en peligro a 10s sistemas internos
yectos complejos y grandes deberi desarrollarse una pla- de las compafiias, y otras consecuencias econdmica-
nificacidn que defina las tareas del trabajo, 10s puntos de mente desagradables e incluso desastrosas.
comprobacidn, 10s productos de trabajo de ingenieria, 10s
puntos de revisidn del cliente y 10s hitos importantes. El
proveedor y el contratista deberin evaluar el riesgo en
conjunto, y desarrollar 10s planes de mitigar, monitorizar
y gestionar esos riesgos considerados como importantes.
Los mecanismos para la seguridad de calidad y el control
de cambios se deberh definir explicitamente a1 escribir-
se. Y tendrh que establecerse mCtodos de comunicaci6n
entre el contratista y el proveedor. Se pueden aplicar las estrategias generales para la
Evaluacion de la planificacibn temporal del desa- gestidn de la configuracidn del software (GCS) descri-
rrollo. Dado que las planificaciones de desarrollo de las tas en el Capitulo 9, per0 las ticticas y herramientas
WebApps abarcan un period0 de tiempo relativamente deberin adaptarse y ajustarse a la naturaleza 6nica de
corto (normalmente menos de un mes o dos), la plani- las WebApps. Cuando se desarrollan ticticas para la
ficacidn de desarrollo deberi tener un alto grado de gra- gestidn de configuracidn de las WebApps, deberh tener-
nularidad. Es decir, las tareas del trabajo y 10s hitos se en consideracidn cuatro temas [DAR99]: el conteni-
menores se tendran que planificar dia a dia. Esta grado, las personas, la escalabilidad y la politica.
nularidad permite que el contratista y el proveedor reco- Contenido. Una WebApp normal contiene una gran
nozcan la reduccidn del tiempo de planificaci6n antes cantidad de contenido -texto, grificos, applets, guiones,
de que amenace la fecha de finalizacidn. archivos de sonido y video, elementos activos de pigi-
Gestion del ambito. Dado que es muy probable que nas, tablas, corrientes de datos y muchos mis-. El reto
el imbito cambie a medida que avanza el proyecto de la es organizar este mar de contenido en un conjunto razo-
WebApp, el modelo de proceso deberi ser incremental nable de objetos de configuracidn (Capitulo 9), y enton-
(Capitulo 2). Esto permite que el equipo de desarrollo ces establecer 10s mecanismos de control de configuracidn
<<congele>> el Ambito para poder crear una nueva versi6n adecuados para estos objetos. Un enfoque sera modelar
operativa de la WebApp. El incremento siguiente puede el contenido de la WebApp mediante la utilizacidn de tCc-
afrontar 10s cambios de imbito sugeridos por una revi- nicas convencionales de modelado de datos (Capitulo
si6n del incrementoprecedente, per0 una vez que comien- 1 I), adjuntando un conjunto de propiedades especializa-
za el incremento, el imbito se congela de nuevo das a cada objeto. La naturaleza estatica y d i n h i c a de
CAPfTULO 29 INGENIERfA WEB
cada objeto y la longevidad proyectada (por ejemplo, en las actividades de gestidn y control asociadas con la
existencia temporal y fija, o un objeto permanente) son IWeb. En algunos casos 10s disefiadores de WebApps
ejemplos de las propiedades necesarias para establecer se encuentran fuera de la organizaci6n TI, dificultando
un enfoque GCS eficaz. Por ejemplo, si se cambia un posiblemente la comunicaci6n. Para ayudar a entender
objeto de contenido cada hora, se dice que tiene una lon- la politica asociada a IWeb, Dart [DAR99] sugiere las
gevidad temporal. Los mecanismos de control de este siguientes preguntas: iquiCn asume la responsabilidad
objeto serhn diferentes (menos formales) de 10s que se de la informaci6n en el sitio Web? iquiCn asegura que
aplican a un componente de formularios (objeto perma- 10s procesos de control de calidad se han llevado a cab0
nente). antes de publicar la informaci6n en el sitio Web? iquiCn
es el responsable de hacer 10s cambios? iquiCn asume
el coste del cambio? Las respuestas ayudarhn a deter-
minx quC personas dentro de la organizaci6n deberhn
Es esenciol controlor el combio duronte 10s proyectos adoptar un proceso de gesti6n de configuraci6n para las
IWeb, oun cuondo puede hocerse de formo exogerodo. WebApps.
Empiece por 10s procedimientos de control de combio La gesti6n de configuration para la IWeb esth toda-
de relotivo informolidad (Copik~lo9). l a meta iniciol sera
via en su infancia. Un proceso convencional de GCS
evitar 10s efectas de trinquete en cambios incontrolados.
puede resultar demasiado pesado y torpe. La gran mayo-
Personas. Dado que un porcentaje significativo del ria de las herramientas GCS no tienen las caracteristi-
desanollo de las WebApps continua realizindose depen- cas que permiten adaptarse fhcilmente a la IWeb. Entre
diendo del caso, cualquier persona que estC implicada 10s temas que quedan por tratar se encuentran 10s
en la WebApp puede (y a menudo lo hace) crear el con- siguientes [DAR99]:
tenido. Muchos creadores de contenido no tienen ante- creaci6n de un proceso de gesti6n de configuraci6n
cedentes en ingenieria del software y no tienen ningun que sea lo suficientemente hhbil como para aceptar la
conocimiento de la necesidad de una gesti6n de confi- inmediatez y la evoluci6n continua de las WebApps;
guraci6n. La aplicaci6n crece y cambia de forma incon- aplicaci6n de mejores conceptos y herramientas de
trolada.
gesti6n de configuraci6n para aquellos que desarro-
Escalabilidad. Las tCcnicas y controles aplicados a llan y no e s t h familiarizados con la tecnologia;
una WebApp pequefia no tienen buena escalabilidad. suministro del soporte a 10s equipos de desarrollo de
No es muy comun que una WebApp sencilla crezca sig- WebApps distribuidos;
nificativamente cuando se implementan las intercone-
suministro de control en un entorno de cuasipubli-
xiones que existen dentro de 10s sistemas de
informaci6n, bases de datos, almacenes de datos y pasa- cacibn, donde el contenido cambia de forma casi con-
relas de portales. A medida que crece el tamafio y la tinua;
complejidad, 10s pequefios cambios pueden tener efec- consecuci6n de la granularidad necesaria para con-
tos inalcanzables y no intencionados que pueden ser trolar una gran cantidad de objetos de configuraci6n;
problemhticos. Por tanto, el rigor de 10s mecanismos de incorporaci6n de la funcionalidad de gestidn de con-
control de la configuraci6n deberin ser directamente figuraci6n en las herramientas IWeb existentes;
proporcionales a la escalabilidad de la aplicaci6n. gestion de cambios en objetos que contienen enla-
Politics. iQuiCn es el propietario de una WebApp? ces con otros objetos.
Esta pregunta se argumenta en compafiias grandes y Estos y otros temas deberhn afrontarse antes de que se
pequefias, y la respuesta tiene un impacto significativo disponga m a gesti6n de configuraci6n eficaz para la IWeb.
Se puede argumentar que el impacto de 10s sistemas y nadas por el contenido y e s t h en continua evolution. La
aplicaciones basados en Web es el acontecimiento mhs inmediatez que conduce a su desanollo, la necesidad pri-
significativo en la historia de la informhtica. A medida mordial de seguridad a1 funcionar, y la demanda de est&
que las WebApps crecen en importancia, el enfoque de tica y la entrega del contenido funcional son otros factores
ingenieria de Web disciplinado ha empezado a evolu- diferenciadores. Durante el desarrollo de la WebApp hay
cionar -basado en principios, conceptos, procesos y tres tecnologias que se integran con otras de ingenieria
mCtodos que se han desarrollado para la ingenieria del del software convencional; desarrollo basado en compo-
software-. nentes, seguridad y lenguajes de notas esthndar.
Las WebApps son diferentes de otras categorias de El proceso de ingenieria de Web comienza con la for-
software informhtico. Son intensivas de red, e s t h gober- mulaci6n -una actividad que identifica las metas y 10s
I N G E N I E R ~ ADEL SOFTWARE. UN ENFOQUE P R ~ c T ~ C O
objetivos de la W e b A p p . La planificaci6n estima el probaci6n ejercita la navegaci6n de la WebApp, inten-

coste global del proyecto, evalua 10s riesgos asociados tando descubrir errores en la funci6n y el contenido, y
con el esfuerzo del desarrollo y define una programaci6n asegurando mientras tanto que la WebApp funcione
temporal del desarrollo. El anilisis establece requisitos correctamente en diferentes entornos. La ingenieria de
tkcnicos e identifica 10s objetos del contenido que se incor- Web hace uso de un modelo de proceso iterativo e incre-
porarin en la WebApp. La actividad de ingenieria incor- mental porque la linea temporal del desarrollo para la
pora dos tareas paralelas: disefio del contenido y disefio WebApp es muy corta. Las actividades protectoras apli-
tCcnico. La generacion de piginas es una actividad de cadas durante el trabajo de la ingenieria del software
construction que hace un uso extenso de herramientas -SQA, GCS, gesti6n de proyectos- se aplican a todos
automatizadas para la creaci6n de WebApps, y la com- 10s proyectos de ingenieria de Web.
[ATK97] Atkins, D., et al., Internet Security: Professional [MUR99] Murugesan, S., WebE Home Page, http://fist-
Reference, New Riders Publishing, 2.%d., 1997. Julio de 1999.
se~.macarthur.uws.edu.au./san/WebHome,
[BER98] Bernstein, M., <<Patternsin Hypertext)), Proc. 91h [NAN981 Nanard, M., y P. Kahn, <<PushingReuse in Hyper-
ACM Conf. Hypertext, ACM Press, 1998, pp. 21-29. media Design: Golden Rules, Design patterns and cons-
tructive Templates)), Proc. 91hACM conf. On Hypertext
[BRA971 Bradley, N., The Concise SGML Companion, Addi-
and Hypermedia, ACM Press, 1998, pp. 11-20.
son-Wesley, 1997.
[NIE96] Nielsen, J., y A. Wagner, <<UserInterface Design for
[BRE99] Brenton, C., Mastering Network Security, Sybex,
the WWWD,Proc. CHI' 96 conference on Human Factors
Inc., 1999.
in Computing systems, ACM, Press, 1996, pp. 330-331.
[BUS961 Buschmann, F. et al., Pattern-Oriented Software
[NOR991 Norton, K., <<ApplyingCross Functional Metho-
Architecture, Wiley, 1996.
dologies to Web Development)>,Proc. IS' ICSE Works-
[DAR99] Dart, S., <<Containingthe Web Crisis Configura- hop on Web Engineering. ACM, Los Angeles, Mayo de
tion Management)), P ~ o cIS'
. ICSE Workshop on Web engi- 1995.
neering, ACM, Los Angeles, Mayo de 1999".
[OSL99] Olsina, L. et al., <<SpecifyingQuality Characteris-
[DIN981 Dinucci, D., M. Giudice y L. Stiles, Elements of tics and Attributes for Web Sites,), Proc. I"' Workshop on
Web Design: The Designer's Guide to a New Medium, 2." Web Engineering. ACM, Los Angeles, Mayo de 1995.
ed., Peachpit Press, 1998.
[PAR991 Pardi, W.J., XML in Action, Microsoft Press, 1999.
[GAM95] Gamma, E. et al., DesignPatterm, Addison-Wes-
[POW981 Powell, T.A., Web Site engineering, Prentice-Hall,
ley, 1998.
1998.
[GNA99] Gnaho, C., y F. Larcher, (<AUser Centered Me-
[PRE98] Pressman, R.S. (moderador), <<CanInternet-Based
thodology for Complex and Customimizable Web Appli-
Applications be Engineered?)), IEEE Software, Septiem-
cations engineering*, Proc. 1st ICSE Workshop on Web
bre de 1998, pp. 104- 1 10.
engineering, ACM, Los Angeles, Mayo de 1999.
[ROS98] Rosenfeld, L., y P. Morville, Information Architec-
[HAN99] Hansen, S., Y. Deshpande y S. Murgusan, <<A
Skills
ture for the World Wide Web, O'Reilly &Associates, 1998.
Hierarchy for Web Information system Development)>,
Proc. Is' lCSE Workshop on Web Engineering, ACM, Los [SAN96] Sano, D., Designing Large-Scale Web Sites: A
Angeles, Mayo de 1999. Visual Design Methodology, Wiley 1996.
[ISA95] Isakowitz, T. et al., <tRMM:A Methodology for [SCH96] Schwabe, D., G. Rossi y S. Barbosa, <<Systematic
Structured Hypermedia Design)), CACM, vol. 38, n." 8, Hypermedia Application Design with OOHDMD,Proc.
Agosto de 1995, pp. 43-44. Hypertext ' 96, pp. 116-128.
[KAE99] Kaeo, M., Designing Network Security, Cisco [SP098] Spool, J.M., et al., Web Site Usability: A Desig-
Press, 1999. ner's Guide, Morgan Kaufmann Publishers, 1998.
[LOW991 Lowe, D., <<Web Engineering or Web Gardening?,), [STL99] St. Laurent, S., y E. Cerami, Building XMLAppli-
WebNet Journal, vol. 1, n . 9 , Enero-Marzo de 1999. cations, McGraw-Hill, 1999.
[LYN99] Lynch, P.J., y S. Horton, Web Style Guide: Basic [TIL99] Tilley, S., y S. Huang, <<Onthe emergence of the
Design Principles for Creating Web Sites, Yale University Renaissance Software engineer,, Proc. IS' ICSE Workshop
Press, 1999. on the WebEngineering, ACM, Los Angeles, Mayo de 1999.
'*
Los procedimientos del Primer Taller ICSE sobre Ingenieria del SoR-
ware se publican en la red en http://fistserv.marcarthur.
uws.edu.au/san/icse99-WebE/ICSE99-Web-E-~/defa~t.h~
C A P ~ T U L O29 I N G E N I E R I A WEB
29.1. existe en otros atributos genCricos que diferencien a las 29.10. Realice un analisis del contenido para HogarSegu-
WebApps de otras aplicaciones de software? Enumere 2 6 3. roInc.com o para un sitio Web asignado por su profesor.
29.2. ~ C d m ose juzga la calidad de un sitio Web? Confeccio- 29.11. Sugiera tres ~reglasde ore), que serviran como guia en
ne una lista de 10 atributos de calidad prioritarios que consi- el disefio de WebApps.
dere mas importantes. 29.12. iEn quC difiere una configuracidn de disefio WebApp
29.3. Realice una pequeiia investigacion y realice un trabajo de una plantilla?
de 2 6 3 paginas que resuma una de las tres tecnologias que 29.13. Seleccione un sitio Web con el que estC familiarizado
se destacaron en la Seccidn 29.1.2. y desarrolle un disefio arquitectonico razonablemente com-
29.4. Utilizando un sitio Web real como ejemplo, ilustre las pleto para el sitio. ~ Q u Cestructura arquitectdnica selecciond
diferentes manifestaciones del cccontenidos de la WebApp. el diseiiador del sitio?
29.5. Responda a las tres preguntas de formulacidn para un 29.14. Haga una investigacion breve y escriba 2 6 3 paginas
sitio Web con el que estC familiarizado. Desarrolle una afir- que resuman el trabajo actual en las configuraciones de dise-
macidn de ambito para el sitio Web. fio de las WebApps.
2916. Desarrolle un conjunto de perfiles para HogarSegu- 29.15. Desarrolle un disefio arquitectdnico para HogarSegu-
roInc.com o un sitio Web asignado por su profesor. roInc.com o para un sitio Web asignado por su instructor.
29.7. Desarrolle una lista completa de metas informativas y 29.16. Utilizando un sitio Web real como ejemplo, desarrolle
aplicables para HogarSeguroInc.com o un sitio Web asigna- una critica de su interfaz de usuario y haga una recomenda-
do por su profesor. cidn que lo mejore.
29.8. Elabore un conjunto de casos de uso para HogarSegu- 29.17. Describa la manera en que una gestidn de proyecto para
roInc.com o un sitio Web asignado por su profesor. sistemas y aplicaciones basados en Web difieren de la gestidn
29.9. iEn quC difiere el analisis del contenido del analisis fun- de proyecto para el software convencional. iEn quC se ase-
cional y de interaccidn? meja?
Durante los ultimos aiios se han publicado cientos de libros Menasce y Almeida (Capacity Planning for Web Perfor-
que tratan uno o mas temas de ingenieria de Web, aunque mance: Metrics, Models, and Methods, Prentice-Hall, 1998)
relativamente pocos tratan todos los aspectos. Lowe y Hall tratan la valoracion cuantitativa del rendimiento de las
(Hypertext and the Web: An Engineering Approach, Wiley, WepApps. Amoroso (Intrusion Detection: An Introduction to
1999), y Powell [POW981 abarcan razonablemente estos Internet Surveillance, Correlation, Trace Back, Traps, and
temas. Norris, West y Warson (Media Engineering: A Quide Response, 1ntrusion.Net Books, 1999) proporciona una guia
to Developing Information Products, Wiley, 1997). Navarro detallada para los ingenieros de Web que estan especializa-
y Khan (Effective Web Desrgn: Master the Essentials, Sybex, dos en temas de seguridad. Umar (Application (Re)Enginee-
1998), Fleming y Koman (Web Navigation: Designing the ring: Building Web-Based Applications and Dealing With
User Experience, O'Reilly & Associates, 1998), y Sano Legacies, Prentice-Hall, 1997) estudia estrategias para la trans-
[SAN96] tambiCn abarcan aspectos importantes del proceso formacidn (reingenieria) de sistemas anteriores en aplicacio-
de ingenieria. nes basadas en Web. Mosley (Client Server Software Testing
Ademas de [LYN99], [DIN981 y [SP098], los siguientes on the Desk Top and the Web, Prentice-Hall, 1999) ha escri-
libros proporcionan una guia util para 10s aspectos del dise- to uno de 10s mejores libros que estudian 10s temas de com-
iio de WebApps tanto tecnicos como no: probacidn asociados con WebApps.
Baumgardt, M., Creative Web Design: Tips and Tricks Haggard (Survival Guide to Web Site Development,
Step by Step, Springer Verlag, 1998. Microsoft Press, 1998) y Siege1 (Secrets of Successful Web
Donnelly, D. et al., Cutting Edge Design: The Next Gene- Sites: Project Management on the World Wide Web, Hay-
ration, Rockport Publishing, 1998. den Books, 1997) proporcionan una guia para el gestor que
Holzschlag, M.E., Web by Design: The Complete Guide, debe de controlar y hacer un seguimiento del desarrollo de
Sybex, 1998. WebApps.
Niederst, J., y R. Koman, Web Design in a Nutshell: A Una amplia variedad de fuentes de informacidn sobre inge-
Desktop Quick Reference, O'Reilly & Associates, 1998. nieria de Web esta disponible en Internet. Una lista amplia y
Weinman, L., y R. Prirouz, Click Here: Web Communi- actualizada de referencias en sitios (piginas) web se puede
cation Design, New Riders Publishing, 1997. obtener en http:/www.pressman5.com.
estruttura de dator . . .549
lngenleria avanzada.. ,551
ingenieria inversa.. ...547
nivel de ahstratdin . . - 5 4 7
&Qules? Tenga en consideracidn cual- ;Por qu6 es 'mportante? Vivimos en un 10sprogramas exisfentes que exhiben
quier producto de 'lecnologia que hcrya mundoenwnstante cambia lasdeman- una mantenibilidad de mayor calidad.
adquirido. Lo ve con regularidad, p r o d a s de funciones de negccios y de tec- ;Cual es el produelo obtenldo? Son
est6 envejeciendo. Se rompe con fre- nologia de informaci6nque las soportan varios 10s productos que s e elaboran
cuencia, tarda e n repararse y ya n o e s t h cambiando a un titmo que impo- (por ejemplo, modelos cm&lisis,modebs
representa la dltima tecnologia. $ 2 ~ 6 ne mucha pesi6n competitiva en todas de diseiio, procedimienfos de pruebas).
s e puede hacer? Si el producto es de las organizaciones comerciales. Tanto El resultado final e s un prcceso de rein-
hardware, probablemente lo tirara y se 10s negocios coma el softwareque sopor- genieria de negccios y/o el software de
comprara uno nuevo. Pero si es un soft- tan (o es) el negccio debenin diseiiarse reingenieria que lo soporla.
ware personalizado. no dispondrh la una vez mas pcna mantener el ritmo. kC6mo puedo e s t a seguro
~ de que lo
opci6n d e tirarlo. Necesitara recons- ~Cuirlesson lor pmas?L a reingenieda he hecho wrrectamente? Utilizun-
truirlo. CrearCE un producto con una lun- de procesos de negocios (RPN)define las do las mismas practicas que se aplican
cionalidad nueva, un mejor rendimiento metas comerciales, identifica y evalua en todos 10s prccesos de ingenieria del
y fiabilidad, y un mantenimiento mejo- 10s procesos de negccios existentes, y software -las revisiones tecnicas for-
rado. Em es lo a u e llamamos reinae- ----------- -----:A,-.- --..L-A---.- ".-I,.- -...-.I.+.-- 1-- -,.A-l-- d- .-."Al:":-
y d e diseiios, las revisiones especialim-

das tienen en consideraci6n la capaci-
dad de aplicacibn comercial y la
compatibilidad, y la comprobaci6n s e
--I: ------ 2 L-1- I-- A- -1
En este capitulo se examina la reingenieria de forma descendente, comenzando por una vision general de la reingenie-
ria de procesos de negocio y pasando entonces a una discusion mas detallada de las actividades tCcnicas que se producen
cuando se efectua una reingenieria del software.
La Reingenieria de procesos de negocio, RPN (Busi-

ness Process Reingineering,BPR~)va mas alla del h b i -
to de las tecnologias de la informaci6n y de la ingenieria Como ingeniero del softwore, el trobojo de reingenieria
del software. Entre las muchas definiciones (la mayo- tiene lugor en lo porte inferior de lo jerorquio.
ria de ellas, algo abstractas) que se han sugerido para la Sin embargo, oseglirese de que olguien hoyo pensodo
RPN, se cuenta con una publicada en la revista Fortu- seriomente en el nivel anterior. Si no lo hon hecho,
ne [STE93]: <<...la bdsqueda e implementaci6n de cam- su trobojo corre olglin riesgo.
bios radicales en el proceso de negocios para lograr un Cada uno de 10s sistemas de negocios (tambiCn lla-
avance significative,,. Ahora bien jc6m0 se efectua la
mados funcidn de negocios) estan compuestos por uno
busqueda, y c6mo se lleva a cab0 la implementaci6n?
o mas procesos de negocio, y cada proceso de negocio
0 lo que es mas importante, jc6m0 podemos estar segu-
esta definido por un conjunto de subprocesos.
ros de que el cccambio radical), que se sugiere va a dar
La RPN se puede aplicar a cualquier nivel de la jerar-
lugar realmente a un ccavance significativon en lugar de
quia, per0 a medida que se amplia el Ambito de la RPN
conducirnos a un caos organizativo?
(esto es, a medida que se asciende dentro de la jerarquia)
10s riesgos asociados a la RPN crecen de forma dramati-
ca. Por esta razon, la mayor parte de 10s esfuerzos de la
RPN se centran en procesos o subprocesos individuales.
30.1.2. Principios de reingenieria de procesos

de negocios
En muchos aspectos, la RPN tiene un objetivo y un Bmbi-
30.1.1. Procesos de negocios to idCntico a1 proceso de la ingenieria de la informacidn
Un proceso de negocio es can conjunto de tareas 16gi- (Capitulo 10). Lo ideal seria que la RPN se produjera de
camente relacionadas que se llevan a cab0 para obtener forma descendente, comenzando por la identificacidn de
un determinado resultado de negocio)) [DAV90]. Den- 10s objetivos principales del negocio, y culminando con
tro del proceso de negocio, se combinan las personas, una especificaci6n mucho mas detallada de las tareas que
10s equipos, 10s recursos materiales y 10s procedimien- definen un proceso especifico de negocios.
tos de negocio con objeto de producir un resultado con- Hammer [HAM901 sugiere una serie de principios
creto. Entre 10s ejemplos de negocio se incluyen el que nos guiaran por las actividades de la RPN cuando
disefio de un nuevo producto, la adquisici6n de semi- se comienza en el nivel superior (de negocios):
cios y suministros, la contrataci6n de nuevos emplea- Organizacidn en torno a 10s resultados, no en torno a las
dos o el pago a proveedores. Cada una requiere un tareas.Hay muchas compafiias que poseen actividades de nego-
conjunto de tareas y se basa en diversos recursos den- cio compartimentadas, de tal mod0 que no existe una h i c a
persona (u organization) que tenga la responsabilidad (o el con-
tro del negocio. trol) de un cierto resultado de negocio. En tales casos, resulta
Cada proceso de negocio posee un cliente bien defi- dificil determinar el estado del trabajo e incluso mas dificil
nido -una persona o grupo que recibe el resultado (por depurar 10s problemas de proceso cuando esto sucede. La RPN
ejemplo: una idea, un informe, un disefio, un produc- debera disefiar procesos que eviten este problema.
to)-. Ademas, 10s procesos de negocio cruzan 10s limi- Hay que hacer que quienes urilicen la salida del proceso
tes organizativos. Requieren que distintos grupos de la lleven a caho elproceso. El objetivo de esta recomendaci6nes
organizaci6n participen en las cctareas 16gicamenterela- permitir que quienes necesiten las salidas del negocio contro-
len todas las variables que les permitan obtener esa salida de
cionadasn que definen el proceso. forma temporalmente adecuada. Cuanto menor sea el ndmero
En el Capitulo 10 se indicaba que todo sistema es en de personas distintas implicadas en el proceso, mas facil sera
realidad una jerarquia de subsistemas. El negocio glo- el camino hacia un resultado rapido.
bal se puede segmentar de la siguiente manera:
El negocio
sistemas de negocio
proceso de negocio
subprocesos de negocio
3
Referencia Web
Para encontrar una extenso information
sobre la reingenieria de procesos de negocios
BPR, en castellano RPN visite la direction www.brint.com/BPR.htrn
Hay que incorporar el trabajo de procesamiento de infor- IdentificacMn de procesos. En esta actividad se iden-
macidn a1 trabajo real que produce la informacidn pura. A tifican 10s procesos cnticos para alcanzar 10s objetivos
medida que la TI se distribuye, es posible localizar la mayor
definidos en la definici6n del negocio. A continuacidn,
parte del procesamiento de informacion en el seno de la orga-
nizacion que produce 10s datos. Esto localiza el control, redu- pueden recibir prioridades en funci6n de su importan-
ce el tiempo de comunicaci6n y la potencia de cornputacidn se cia, necesidad de cambio, o cualquier otra forrna que
pone en manos de quienes tienen fuertes intereses en la infor- resulte adecuada para la actividad de reingenieria.
macion producida.
Hay que manipular recursos geogr6frcamente dispersos
como si estuviesen centralizados. Las comunicaciones basa- del negocio
das en computadoras se han sofisticado tanto que es posible
situar grupos geogrificarnente dispersos en una misrna ~ofici-
na virtual*. Por ejemplo, en lugar de ernplear tres turnos de
ingenieria en una unica localizacidn, toda la compaiiia podri
tener un turno en Europa, un segundo turno en Nortearnkrica
y un tercer turno en Asia. En todos 10s casos, 10s ingenieros tra-
bajarkn durante el dia y se comunicarh empleando redes de
un elevado ancho de banda.
Hay que enlazar las actividadesparalelasen lugar de inte-

par sus resultados. Cuando se utilizan diferentes gmpos de
empleados para realizar tareas en paralelo, es esencial disehar FIGURA 30.1. Un modelo de BPR.
un proceso que exija una continuation en la comunicacion y
coordinacih. En caso contrario, es seguro que se producirkn
problemas de integracibn. Evaluacion de procesos. Los procesos existentes
Hay que poner el punto de decisidn en el lugar donde se
deberhn analizarse y medirse exhaustivamente. Las
efectua el trabajo, e incorporar el control a1 proceso. Dentro tareas de procesos se identificarhn; 10s costes y 10s tiem-
de la jerga del disefio del software, esto sugiere una estructura pos consumidos por las tareas de proceso se anotarhn
organizativa mis uniforme y con menos factorizacidn. cuidadosamente, y se aislarhn 10s problemas de calidad
Hay que capturar 10s datos una sola vez, en el lugar don- y rendimiento.
de se producen. Los datos se deberh almacenar en cornputa- Especificacion y diseiio de procesos. Bashdose en la
doras, de tal mod0 que una vez recopilados no sea necesario informacidn obtenida durante las tres primeras actividades
volver a introducirlos nunca.
de la RPN, se prepararzin casos priicticos (Capitulo 11) para
Todos y cada uno de 10s principios anteriores repre- cada uno de 10s procesos que se tengan que rediseiiar. Den-
sentan una visidn <ctotalmentegeneral), de la RPN. Una tro del contexto de la RPN, 10s casos prkticos identifican
vez informados por estos principios, 10s planificadores de un escenario que proporciona resultados a un cliente. Con
negocios y 10s diseiiadores de procesos deberhn empezar el uso de casos prhcticos como especificacidn del proceso,
a procesar el nuevo disefio. En la seccidn siguiente, se se disefia un nuevo conjunto de tareas (que se ajustan a 10s
examinarh el proceso de RPN mas detalladamente. principios indicados en la Seccidn 30.2.1) para el proceso.
Creacion de prototipos. Es preciso construir un pro-
30.1.3. Un modelo d e RPN totipo del proceso de negocios redisefiado antes de inte-
A1 igual que la mayoria de las actividades de ingenie- grarlo por completo en el negocio. Esta actividad
ria, la reingenieria de procesos de negocio es iterativa. cccomprueba>,el proceso para que sea posible efectuar refi-
Los objetivos de negocio, y 10s procesos que 10s logran, namientos.
deberhn adaptarse a un entomo de negocio cambiante. Refinamiento e instanciacion. Bashndose en la rea-
Por esta razdn, no existe ni principio ni fin en la RPN limentacidn procedente del prototipo, se refina el pro-
-se trata de un proceso evolutivc-. En la Figura 30.1 ceso de negocio y despuCs se instancia en el seno de un
se representa un modelo de reingenieria de procesos de sistema de negocio.
negocio. Este modelo define seis actividades: En algunas ocasiones las actividades de RPN descritas
Definicion del negocio. Los objetivos de negocios anteriormente se utilizan junto con herrarnientas de anili-
se identifican en un contexto de cuatro controladores sis del flujo de trabajo. El objetivo de estas herrarnientas
principales: reduccidn de costes, reduccidn de tiempos, es construir un modelo del flujo de trabajo existente, en un
mejora de calidad y desarrollo y potenciacidn del per- esfuerzo por analizar mejor 10s procesos existentes. Ade-
sonal. Los objetivos se pueden definir en el nivel de m b , para implementar las cuatro primeras actividades des-
negocios o para un componente especifico del negocio. critas en el modelo de procesos se pueden utilizar las
INGENIERfA DEL S O F T W A R E . U N E N F O Q U E P R A C T I C O
tCcnicas de modelado que se asocian normalmente a las dos por la evidencia empirica. Para muchas compaiiias parece
actividades de ingenieria de la informaci6n tales como la que la bala de plata no da en el blanco.
planificaci6n de estrategias de informaci6n y el anili- Para otras, sin embargo, el nuevo esfuerzo de la reingenie-
sis de ireas de negocios (Capitulo 10). ria ha tenido evidentemente su fruto...
La RPN puede funcionar, si es aplicada por personas
30.1.4. Advertencias motivadas y formadas, que reconozcan que el proceso de
Es muy frecuente que se exagere la importancia de un reingenieria es una actividad continua. Si la RPN se lle-
nuevo enfoque de negocio -en este caso, la RPN- va a cab0 de forma efectiva, 10s sistemas de informaci6n
como si fuese la panacea, para despuCs criticarla con se integran mejor con 10s procesos de negocios. Dentro
tanta severidad que pase a ser un desecho. A lo largo de del context0 de una estrategia mis amplia de negocios se
10s ultimos afios, se ha debatido de forma exagerada puede examinar la reingenieria de aplicaciones mis anti-
acerca de la eficacia de la RPN (por ejemplo: [BLE93] guas, y tambiCn se pueden establecer de forma inteligente
y [DIC95]). En un resumen excelente del caso a favor las prioridades de reingenieria del software.
y en contra de la RPN, Weisz (WEI95) expone su argu- Aunque la reingenieria de negocio sea una estrate-
mento de la manera siguiente: gia rechazada por una compafiia, la reingenieria del soft-
ware es algo que debe hacerse. Existen decenas de
Resulta tentador atacar a la RPN como si se tratase de otra
reencarnacion de la famosa bala de plata. Desde varios puntos
millares de sistemas heredados -aplicaciones crucia-
de vista -pensamiento de sistemas, tratamiento de personal, les para el Cxito de negocios grandes y pequefios- que
simple historia- habria que predecir unos indices de fallos se ven afectados por una enorme necesidad de ser
elevados para el concepto, indices que parecen ser confirma- reconstruidos o rehechos en su totalidad.
Este escenario resulta sumamente conocido: Una apli- debajo de la superficie. A principios de 10s afios 70, el
caci6n ha dado servicio y ha cubierto las necesidades iceberg de mantenimiento era lo suficientemente gran-
del negocio de una compaiiia durante diez o quince aiios. de como para hundir un portaaviones. En la actualidad
A lo largo de este tiempo, ha sido corregida, adaptada podria hundir toda la Armada.
y mejorada muchas veces. Las personas se dedicaban a El mantenimiento del software existente puede dar
esta tarea con la mejor de sus intenciones, per0 las pric- cuenta de mis del60 por 100 de las inversiones efec-
ticas de ingenieria del software buenas siempre se echa- tuadas por una organizaci6n de desarrollo, y ese por-
ban a un lado (por la urgencia de otros problemas). centaje sigue ascendiendo a medida que se produce mis
Ahora la aplicaci6n se ha vuelto inestable. Sigue fun- software [HAN93]. Los lectores que tengan menos
cionando, per0 cada vez que intenta efectuar un cam- conocimientos en estos temas podrian preguntarse por
bio se producen efectos colaterales graves e inesperados. quC se necesita tanto mantenimiento, y por quC se invier-
~ Q u Cse puede hacer? te tanto esfuerzo. Osborne y Chifosky [OSB90] ofre-
La imposibilidad de mantener el software no es un cen una respuesta parcial:
problema nuevo. De hecho, el gran inter& por la rein- Gran parte del software del que dependemos en la actua-
genieria del software ha sido generado por un <<iceberg>> lidad tiene por tCrmino medio entre diez y quince afios de
de mantenimiento de software que lleva creciendo des- antigiiedad. Aun cuando estos programas se crearon emple-
de hace mis de treinta afios. ando las mejores tCcnicas de diseiio y codificaci6n conoci-
das en su Cpoca (y la mayoria no lo fueron), se crearon
cuando el tamaiio de 10s programas y el espacio de alma-
cenamiento eran las preocupaciones principales. A conti-
nuacibn, se trasladaron a las nuevas plataformas, se ajustaron
Referencia web/ '~ para adecuarlos a cambios de miquina y de sistemas ope-

rativos y se mejoraron para satisfacer nuevas necesidades
del usuario; y todo esto se hizo sin tener en cuenta la arqui-
SEl ofrece uno voriedod de recursos tectura global.
de reingenieria del softwore en la
direccion: www.sei.cmu.edu/reengineering/ El resultado son unas estructuras muy ma1 diseiiadas, una
mala codification, una logica inadecuada, y una escasa docu-
mentacion de 10s sistemas de software que ahora nos piden
que mantengamos en marcha ...
30.2.1. Mantenimiento d e l software
Hace casi treinta afios, el mantenimiento del software La naturaleza ubicua del carnbio subyace en todos
se caracterizaba [CAN721 por ser como un <<iceberg>>. 10s tipos de trabajo del software. El carnbio es algo ine-
Esperibamos que lo que era inmediatamente visible fue- vitable cuando se construyen sistemas basados en com-
ra de verdad lo que habia, per0 sabiamos que una enor- putadoras; por tanto debemos desarrollar mecanismos
me masa de posibles problemas y costes yacia por para evaluar, controlar y realizar modificaciones.
Antes de dembar y de construir toda la casa, aseg6-
rese de que la estructura esti en ma1 estado. Si la casa
toy de comprensibn son tiene una buena estructura, quiza sea posible remo-
delarla sin reconstruirla (con un coste muy inferior
y en mucho menos tiempo).
Antes de ernpezar a reconstruir, aseg6rese de que
entiende la forma en que se construy6 el original.
A1 leer 10s phrrafos anteriores, un lector podria argu- Eche una ojeada por detras de las paredes. Com-
mentar: cc. ..per0 yo no invierto el 60 por 100 de mi tiem- prenda el cableado, la fontanena y 10s detalles inter-
po conigiendo errores de 10s programas que desarrollo>>. nos de la esuuctura. Aunque vaya a eliminarlos todos,
Por supuesto, el mantenimiento del software es algo que la idea que haya adquirido de ellos le serviran de
va mucho m b alla de cccomgir e m s > >El . mantenimiento mucho cuando empiece a construirla.
se puede definir describiendo las cuatro actividades Si empieza a reconstruir, utilice tan solo 10s materia-
[SWA76] que se emprenden cuando se publica un progra- les mas modemos y de mayor duraci6n. Quiz5 ahora
ma para su utilizaci6n. En el Capitulo 2 se definieron cua- le cuesten un poquito mas, per0 le ayudarin a evitar
tro actividades diferentes de mantenimiento: mantenimiento un mantenirniento costoso y lento en fecha posterior.
corrective, mantenimiento adaptativo, mejoras o rnante- Si ha decidido reconstruir, tenga una actitud disci-
nimiento de pelfeccionamiento y mantenimientopreventi- plinada. Utilice pricticas que den como resultado
vo o reingenieria. Tan s610 el 20 por 100 de nuestros una gran calidad -tanto hoy como en el f u t u r w .
esfuerzos de mantenimiento se invertirh ccconigiendoe m
rew. El 80 por 100 se dedicarh a adaptar 10s sistemas exis-
tentes a 10s carnbios de su entomo extemo, a efectuar las
mejoras solicitadas por 10s usuarios y a rehacer la ingenie- Los pasos poro uno coso indicodos oquison obvios.
ria de las aplicaciones para su posterior utilizaci6n. Cuan- Aseglirese de que su considerocibn sobre el sohare
do se considera que el mantenimiento abarca todas estas onticuodo oplico posos que seon tan obvios. Pienselo.
actividades, es facil ver por q d absorbe tanto esfuerzo. Hay mucho dinem en juego.
30.2.2. Un modelo de procesos de reingenieria Aunque 10s principios anteriores se centran en la

reconstrkci6n de una casa, son aplicables igualmente
del software a la reingenieria de sistemas y aplicaciones basados en
La reingenieria requiere tiempo; conlleva un coste de computadoras.
dinero enorme y absorbe recursos que de otro mod0 Para irnplementar estos principios, se aplica un modelo
podrian emplearse en preocupaciones mas inmediatas. de proceso de reingenieria del software que define las seis
Por todas estas razones, la reingenieria no se lleva a actividades mostradas en la Figura 30.2. En algunas oca-
cab0 en unos pocos meses, ni siquiera en unos pocos siones, estas actividades se producen de forma secuencial
aiios. La reingenieria de sistemas de informaci6n es una y lineal, pero esto no siempre es asi. Por ejemplo,puede ser
actividad que absorbera recursos de las tecnologias de que la ingenien'a inversa (la comprensi6ndel funcionamiento
la informaci6n durante muchos aiios. Esta es la razdn intemo de un prograrna) tenga que producirse antes de que
por la cual toda organizaci6n necesita una estrategia pueda comenzar la reestructuraci6n de documentos.
pragmatics para la reingenieria del software. El paradigma de la reingenieria mostrado en la figu-
Una estrategia de trabajo tambikn acompafia a1 mode- ra es un modelo ciclico. Esto significa que cada una de
lo de procesos de reingenieria. Mas adelante, en esta las actividades presentadas como parte del paradigma
misma seccibn, se describira este modelo, per0 veamos pueden repetirse en otras ocasiones. Para un ciclo en
en primer lugar algunos de 10s principios basicos. particular, el proceso puede terminar despuks de cual-
La reingenieria es una tarea de reconstrucci6n, y se quiera de estas actividades.
podra comprender mejor la reingenieria de sistemas de Analisis de inventario. Todas las organizaciones de
informaci6n si tomamos en consideraci6n una activi- software deber6n disponer de un inventario de todas sus
dad aniloga: la reconstrucci6n de una casa. Considere- aplicaciones. El inventario puede que no sea mas que una
mos la situacidn siguiente: hoja de calculo con la inforrnaci6n que proporciona una
Suponga que ha adquirido una casa en otro lugar. descripci6n detallada (por ejemplo: tamaiio, edad, impor-
Nunca ha llegado a ver la finca realmente, per0 la con- tancia para el negocio) de todas las aplicaciones activas.
sigui6 por un precio sorprendentementereducido, advir-
tikndosele que quiz6 fuera precis0 reconstruirla en su
totalidad. iC6m0 se las arreglana?
Antes de empezar a construir, seria razonable inspec-
cionar la casa. Para determinar si necesita una recons-
trucci6n, usted (o un inspector profesional) creara una
lista de criterios para que la inspecci6n sea sistematica. Andlisis de inventario
Los candidatos a la reingenieria aparecen cuando se Ingenieria inversa. El tkmino ccingenieria inversan tie-
ordena esta informacion en funci6n de su importancia ne sus origenes en el mundo del hardware. Una cierta com-
para el negocio, longevidad, mantenibilidad actual y patiia desensarnbla un producto de hardware competitivo
otros criterios localmente importantes. Es entonces cuan- en un esfuerzo por comprender 10s ccsecretosn del disefio
do es posible asignar recursos a las aplicaciones candi- y fabricacion de su competidor. Estos secretos se podrin
datas para el trabajo de reingenieria. comprender mas fhcilmente si se obtuvieran las especifi-
Es importante destacar que el inventario debera revi- caciones de diseiio y fabricacion del mismo. Pero estos
sarse con regularidad. El estado de las aplicaciones (por documentos son privados, y no estin disponibles para la
ejemplo, la importancia con respecto a1 negocio) pue- compaiiia que efectda la ingenieria inversa. En esencia,
de cambiar en funcion del tiempo y, como resultado, una ingenieria inversa con exito precede de m a o m h espe-
cambiaran tambiin las prioridades para la reingenieria. cificaciones de disefio y fabricacion para el producto,
mediante el examen de ejemplos reales de ese producto.
La ingenieria inversa del software es algo bastante
similar. Sin embargo, en la mayoria de 10s casos, el pro-
grama del cual hay que hacer una ingenieria inversa no
es el de un rival, sino, mas bien, el propio trabajo de la
compafiia (con frecuencia efectuado hace muchos afios).
Los ccsecretos, que hay que comprender resultan incom-
prensibles porque nunca se llego a desarrollar una espe-
cificacion. Consiguientemente, la ingenieria inversa del
software es el proceso de analisis de un programa con
el fin de crear una representacion de programa con un
nivel de abstraccion mas elevado que el codigo fuente.
La ingenieria inversa es un proceso de recuperacion de
diseiio. Con las herramientas de la ingenieria inversa se
FIGURA 30.2. Un modelo de proceso de reingenieria extraera del programa existente informacion del diseiio
de software. arquitectonico y de proceso, e informacion de 10s datos.
Reestructuracion del codigo. El tip0 mas comdn de
reingenieria (en realidad, la aplicacion del tkrmino rein-
Reestructuracion de documentos. Una documen-
taci6n escasa es la marca de muchos sistemas hereda- genieria seria discutible en este caso) es la reestructu-
dos. ~ Q u Cse puede hacer a1 respecto? raci6n del codigo. Algunos sistemas heredados tienen
una arquitectura de programa relativamente solida, per0
Opcidn n.' I : La creaci6n de documentacion consume 10s m6dulos individuales han sido codificados de una
muchisimo tiempo. El sistema funciona, y ya nos apatiaremos
con lo que tengamos. En algunos casos. este es el enfoque
forma que hace dificil comprenderlos, comprobarlos y
correcto. No es posible volver a crear la documentacion para mantenerlos. En estos casos, se puede reestructurar el
cientos de programas de computadoras. Si un programa es rela- codigo ubicado dentro de 10s m6dulos sospechosos.
tivamente estitico esta llegando a1 final de vida util, y no es Para llevar a cab0 esta actividad, se analiza el c6di-
probable que experirnente muchos cambios: idejemoslo asi!
go fuente mediante una herramienta de reestructuracion,
Opcidn n . 9 : Es preciso actualizar la documentaci6n, pero se indican las violaciones de las estructuras de progra-
se dispone de recursos limitados. Se utilizara un enfoque ccdel
tipo documentar si se modifica,,. Quiza no se necesario volver maci6n estructurada, y entonces se reestructura el codi-
a documentar por completo la aplicacion. Mas bien se docu- go (esto se puede hacer autom8ticamente). El c6digo
mentaran por cornpleto aquellas partes del sistema que e s t h reestructurado resultante se revisa y se comprueba para
experimentando cambios en ese momento. La colecci6n de asegurar que no se hayan introducido anomalias. Se
documentos util y relevante ira evolucionando con el tiempo. actualiza la documentacion intema del codigo.
Opcidn n.' 3: El sistema es fundamental para el negocio, y
es preciso volver a documentarlo por completo. En este caso, Reestructuracion de datos. Un programa que posea
un enfoque inteligente consiste en reducir la documentaci6n a1 una estructura de datos dCbil serh dificil de adaptar y de
minimo necesario. mejorar. De hecho, para muchas aplicaciones, la arqui-
tectura de datos tiene mas que ver con la viabilidad a
largo plazo del programa que el propio codigo fuente.
Cree sb1o la documentacibn que necesite A diferencia de la reestructuracion de codigo, que se
para mejorar su comprension sobre el sohare. produce en un nivel relativamente bajo de abstraccion,
No para avanzar una pbgina mos. la estructuracion de datos es una actividad de reinge-
nieria a gran escala. En la mayoria de 10s casos, la rees-
Todas y cada una de estas opciones son viables. Las tructuracion de datos comienza por una actividad de
organizaciones del software deberan seleccionar aque- ingenieria inversa. La arquitectura de datos actual se
lla que resulte mas adecuada para cada caso. analiza minuciosamente y se definen 10s modelos de
datos necesarios (Capitulo 12). Se identifican 10s obje- do un <<motorde reingenierian automatizado. En el
tos de datos y atributos y, a continuacion, se revisan las motor se insertaria el programa viejo, que lo analizaria,
estructuras de datos a efectos de calidad. reestructuraria y despuCs regeneraria la forma de exhi-
bir 10s mejores aspectos de la calidad del software. Des-
puCs de un espacio de tiempo corto, es probable que
llegue a aparecer este <<motor>>, per0 10s fabricantes de
CASE han presentado herramientas que proporcionan
Para poder obtener una gran cantidad de recursos un subconjunto limitado de estas capacidades y que se
para la comunidad de reingenieria visite esto direction: enfrentan con dominios de aplicaciones especificos (por
www.comp.lancs.ac.uk/projects/RenaissanceWeb/ ejemplo, aplicaciones que han sido implementadas
empleando un sistema de bases de datos especifico). Lo
Cuando la estructura de datos es dCbil (por ejemplo, que es rnhs importante, estas herramientas de reinge-
actualmente se implementan archivos planos, cuando nieria cada vez son rnhs sofisticadas.
un enfoque relational simplificaria muchisimo el pro- La ingenieria directa, que se denomina tambiCn reno-
cesamiento), se aplica una reingenieria a 10s datos. vacidn o reclamacidn [CHI90], no solamente recupera la
Dado que la arquitectura de datos tiene una gran informacion de diseiio de un software ya existente, sino
influencia sobre la arquitectura del programa, y tambiCn que, ademas, utiliza esta informacion para alterar o recons-
sobre 10s algoritmos que lo pueblan, 10s cambios en truir el sistema existente en un esfuerzo por mejorar su
datos darhn lugar invariablemente a cambios o bien de calidad global. En la mayoria de 10s casos, el software
arquitectura o bien de codigo. procedente de una reingenieria vuelve a implementar la
Ingenieria directa (forward engineering). En un funcionalidad del sistema existente, y aiiade ademhs nue-
mundo ideal, las aplicaciones se reconstruyen utilizan- vas funciones y/o mejora el rendimiento global.
La ingenieria inversa invoca una imagen de eranura La completitud de un proceso de ingenieria inversa
mhgica,,. Se inserta un listado de c6digo no estructura- alude a1 nivel de detalle que se proporciona en un deter-
do y no documentado por la ranura, y por el otro lado minado nivel de abstraccion. En la mayoria de 10s casos,
sale la documentaci6n completa del programa de com- la completitud decrece a medida que aumenta el nivel
putadora. Lamentablemente, la ranura mhgica no exis- de abstracci6n. Por ejemplo, dado un listado del codi-
te. La ingenieria inversa puede extraer informacion de go fuente, es relativamente sencillo desarrollar una repre-
diseiio del codigo fuente, per0 el nivel de abstraccibn, sentacion de diseiio de procedimientos completa.
la completitud de la documentaci6n, el grado con el cual TambiCn se pueden derivar representaciones sencillas
trabajan a1 mismo tiempo las herramientas y el analis- del flujo de datos, per0 es mucho rnhs dificil desarrollar
ta humano, y la direccionalidad del proceso son suma- un conjunto completo de diagramas de flujo de datos o
mente variables [CAS88]. un diagrama de transition de estados.
El nilvl de abstraccidn de un proceso de ingenieria
inversa y las herramientas que se utilizan para realizarlo
aluden a la sofisticaci6n de la informacidn de diseiio que
se puede extraer del c6digo fuente. El nivel de abstracci6n
ideal deberh ser lo rnhs alto posible. Esto es, el proceso de Se deben ofrontar tres enfoques de ingenieria inverso:
ingenieria inversa deberh ser capaz de derivar sus repre- nivel de abstroccion, compleh'tud y direccionalidod.
sentaciones de diseiio de procediientos (con un bajo nivel
de abstracci6n); y la informaci6n de las eshucturas de datos La completitud mejora en proportion directa a la can-
y de programas (un nivel de abstracci6n ligeramente m& tidad de anhlisis efectuado por la persona que esth efec-
elevado); modelos de flujo de datos y de control (un nivel tuando la ingenieria inversa. La interactividad alude a1
de abstracci6n relativamente alto); y modelos de entida- grado con el cual el ser humano se ~cintegra),con las
des y de relaciones (un elevado nivel de abstracci6n). A herramientas automatizadas para crear un proceso de
medida que crece el nivel de abstracci6n se proporciona ingenieria inversa efectivo. En la mayona de 10s casos,
al ingeniero del software informaci6n que le perrnitir6 com- a medida que crece el nivel de abstraccion, la interacti-
prender m& fhcilmente estos programas. vidad deberh incrementarse, o sino la completitud se
verh reducida.
Si la direccionalidad del proceso de ingenieria inver-
sa es monodireccional, toda la informaci6n extraida del
c6digo fuente se proporcionarh a la ingenieria del soft-
ware que podra entonces utilizarla durante la actividad
Por ejemplo, suele producirse una verificaci6n de 10s Para toda variable (dentro de un programa) que repre-
datos y una comprobaci6n de 10s limites dentro de la sente una matriz o archivo, la construcci6n de un lis-
secci6n de c6digo que prepara 10s datos para su proce- tad0 de todas las variables que tengan una relaci6n
samiento. ldgica con ella.
Para 10s sistemas grandes, la ingenieria inversa sue-
le efectuarse mediante el uso de un enfoque semiauto-
matizado. Las herramientas CASE se utilizan para
ccanalizarn la semintica del c6digo existente. La salida En 10s proximos oiios 10s mmpromisos relativomente
de este proceso se pasa entonces a unas herramientas significotivos en 10s estructvras de datos pueden conducir
de reestructuraci6n y de ingenieria directa que comple- a tener problemas patencialmente catastraficos. Fijese
por ejemplo en el efecto del oiio 2000.
tartin el proceso de reingenieria.
Estos pasos hacen posible que el ingeniero del soft-
30.3.2. Ingenieria inversa para comprender ware identifique las clases del programa que interactd-
10s datos an con las estructuras de datos globales.
La ingenieria inversa de datos suele producirse a dife- Estructuras de bases de datos. Independientemen-
rentes niveles de abstracci6n. En el nivel de programa, te de su organizaci6n 16gica y de su estructura fisica,
es frecuente que sea precis0 realizar una ingenieria inver- las bases de datos permiten definir objetos de datos, y
sa de las estructuras de datos internas del programa, apoyan 10s mCtodos de establecer relaciones entre obje-
como parte del esfuerzo general de la reingenieria. En tos. Por tanto, la reingenieria de un esquema de bases
el nivel del sistema, es frecuente que se efectde una rein- de datos para formar otro exige comprender 10s objetos
genieria de las estructuras globales de datos (por ejem- ya existentes y sus relaciones.
plo: archivos, bases de datos) para ajustarlas a 10s
paradigmas nuevos de gesti6n de bases de datos (por ~Cualesson 10s pasos que
ejemplo, la transferencia de archivos planos a unos sis- se pueden aplicar para aplicar
temas de bases de datos relacionales u orientados a obje- la ingenieria inversa en una estructura
tos). La ingenieria inversa de las estructuras de datos de bases de datos existente?
globales actuales establecen el escenario para la intro-
ducci6n de una nueva base de datos que abarque todo Para definir el modelo de datos existente como pre-
el sistema. cursor para una reingenieria que produciri un nuevo
Estructuras de datos internas. Las tCcnicas de inge- modelo de base de datos se pueden emplear 10s pasos
nieria inversa para datos de programa internos se cen- siguientes [PRE94] :
tran en la definici6n de clases de objetoss. Esto se logra Construccibn de un modelo de objetos inicial. Las
examinando el c6digo del programa en un intento de claves definidas como parte del modelo se podrin
agrupar variables de programa que estCn relacionadas. conseguir mediante la revisi6n de registros de una
En muchos casos, la organizaci6n de datos en el sen0 base de datos de archivos planos o de tablas de un
del c6digo identifica 10s tipos abstractos de datos. Por esquema relacional. Los elementos de esos registros
ejemplo, las estructuras de registros, 10s archivos, las o tablas pasarin a ser atributos de una clase.
listas y otras estructuras de datos que suelen propor- Determinacibn de 10s candidatos a claves. Los atribu-
cionar una indicaci6n inicial de las clases. tos se examinan para determinar si se van a utilizar o
Para la ingenieria inversa de clases, Breuer y Lano no para sefialar a otro registro o tabla. Aquellos que sir-
[BRE9 11 sugieren el enfoque siguiente: van como punteros pasarb a ser candidatos a claves.
Identificaci6n de 10s indicadores y estructuras de Refinamiento de las clases provisionales. Se deter-
datos locales dentro del programa que registran infor- mina si ciertas clases similares pueden o no combi-
maci6n importante acerca de las estructuras de datos narse dentro de una 6nica clase.
globales (por ejemplo, archivos o bases de datos). Definicibn de las generalizaciones. Para determinar
Definici6n de la relacidn entre indicadores y estruc- si se debe o no construir una jerarquia de clases con
turas de datos locales y las estructuras de datos glo- una clase de generalizaci6n como precursor de todos
bales. Por ejemplo, se podrh activar un indicador sus descendentes se examinan las clases que pueden
cuando un archivo estC vacio; una estructura de tener muchos atributos similares.
datos local podri servir como memoria intermedia Descubrimiento de las asociaciones. Mediante el uso
de 10s cien 6ltimos registros recogidos para una de tCcnicas anilogas a1 enfoque de CRC (Capi-
base de datos central. tulo 21) se establecen las asociaciones entre clases.
Para una descripcion completa de estos conceptos orientados a

objetos, vease la Parte Cuarta de este Iibro.
Una vez que se conoce la informaci6n definida en 10s iCuAles son las acciones bhsicas que debera proce-
pasos anteriores, se pueden aplicar una serie de trans- sar la interfaz, por ejemplo, acciones de teclado y
formaciones [PRE94] para hacer corresponder la estruc- clics de rat6n?
tura de la vieja base de datos con una nueva estructura iCuAl es la descripci6n compacta de la respuesta de
de base de datos. comportamiento del sistema a estas acciones?
iQuk queremos decir con ccsustituci6n~,o mas exac-
30.3.3. Ingenieria inversa d e interfaces tamente, q u t concept0 de equivalencia de interfaces
d e usuario es relevante en este caso?
Las IGUs sofisticadas se van volviendo de rigor para La notaci6n de modelado de comportamiento (Capi-
10s productos basados en computadoras y para 10s sis- tulo 12) puede proporcionar una forma de desarrollar las
temas de todo tipo. Por tanto el nuevo desarrollo de respuestas de las dos primeras preguntas indicadas ante-
interfaces de usuario ha pasado a ser uno de 10s tipos riormente. Gran parte de la informaci6n necesaria para
mas comunes de las actividades de reingenieria. Aho- crear un modelo de comportamiento se puede obtener
ra bien, antes de que se pueda reconstruir una interfaz mediante la obsenaci6n de la manifestation externa de
de usuario, debera tener lugar una actividad de inge- la interfaz existente. Ahora bien, es preciso extraer del
nieria inversa. c6digo la informacidn adicional necesaria para crear el
modelo de comportamiento.
~Comopuedo entender Es importante indicar que una IGU de sustitucion
el funcionamiento de la puede que no refleje la interfaz antigua de forma exac-
interfaz de usuario existente? ta (de hecho, puede ser totalmente diferente). Con fre-
cuencia, merece la pena desarrollar metaforas de
Para comprender totalmente una interfaz de usuario interacci6n nuevas. Por ejemplo, una solicitud de IU
ya existente (IU), es preciso especificar la estructura y antigua en la que un usuario proporcione un factor
comportamiento de la interfaz. Merlo y sus colabora- superior (del 1 a 10) para encoger o agrandar una ima-
dores [MER93] sugieren tres preguntas bhsicas a las gen grhfica. Es posible que una IGU diseiiada utilice
cuales hay que responder cuando comienza la ingenie- una barra de imageries y un rat6n para realizar la mis-
ria inversa de la IU: ma funci6n.
La reestructuraci6n del software modifica el c6digo Reduce la frustration entre ingenieros del software
fuente y/o 10s datos en un intento de adecuarlo a futu- que deban trabajar con el programa, mejorando por
ros cambios. En general, la reestructuraci6n no modifi- tanto la productividad y haciendo mas sencillo el
ca la arquitectura global del programa. Tiende a centrarse aprendizaje.
en 10s detalles de diseiio de m6dulos individuales y en Reduce el esfuerzo requerido para llevar a cab0 las
estructuras de datos locales definidas dentro de 10s actividades de mantenimiento.
modulos. Si el esfuerzo de la reestructuracion se extien- Hace que el software sea mas sencillo de comprobar
de mas alla de 10s limites de 10s m6dulos y abarca la y de depurar.
arquitectura del software, la reestructuraci6n pasa a ser La reestructuraci6n se produce cuando la arquitectura
ingenieria directa (Secci6n 30.5). basica de la aplicaci6n es sblida, aun cuando sus interio-
ridades tkcnicas necesiten un retoque. Comienza cuando
~ Q u beneficios
e se derivan existen partes considerables del software que son 6tiles
de la reestructuracibn? todavia, y solamente existe un subconjunto de todos 10s
m6dulos y datos que requieren una extensa modificaci6n6.
Arnold [ARN89] define un cierto numero de bene-
ficios que se pueden lograr cuando se reestructura el 30.4.1. Reestructuracion del codigo
software: La reestructuracidn del cddigo se lleva a cab0 para con-
Programas de mayor calidad -con mejor docu- seguir un diseiio que produzca la misma funci6n per0 con
mentaci6n y menos complejidad, y ajustados a las mayor calidad que el programa original. En general, las
prhcticas y estandares de la ingenieria del software ttcnicas de reestructuraci6n del c6digo (por ejemplo, las
moderna-. ttcnicas de simplificacibn Mgica de Warnier [WAR74])
En algunas ocasiones, resulta dificil distinguir entre una reestructura-

cion extensa y un nuevo desarrollo. Ambos son casos de reingenieria.
modelan la logica del programa empleando algebra Boo- sa, llamada a n d i s i s del cddigo fuente. En primer
leana, y a continuaci6n aplican una serie de reglas de lugar se evaluaran todas las sentencias del lenguaje
transformacion que dan lugar a una logica reestructura- de programacion con definiciones de datos, des-
da. El objetivo es tomar el c6digo de forma de ccplato de cripciones de archivos, de E/S, y descripciones de
espaguetis,, y derivar un disefio de procedimientos que interfaz. El objetivo es extraer elementos y objetos
se ajuste a la filosofia de la programacion estructurada de datos, para obtener informacion acerca del flujo
(Capitulo 16). de datos, asi como comprender las estructuras de
datos ya existentes que se hayan implementado. Esta
actividad a veces se denomina analisis de datos
[RIC89].
Aun cuondo lo reestrutturocibn puede olivior Una vez finalizado el analisis de datos, comien-
10s problemos inmediotos osociodos o lo depurocion za el redisetio de datos. En su forma mas sencilla se
y 10s pequefios combios, eso no es reingenierio. emplea un paso de estandarizacidn de redisetio de
El beneficio re01 se logro solo cuondo se datos que clarifica las definiciones de datos para
reestructuron 10s dotos y lo orquitecturo. lograr una consistencia entre nombres de objetos de
Se han propuesto tambiCn otras ticnicas de reestructu- datos, o entre formatos de registros fisicos en el sen0
racion que puedan utilizarse con herramientas de reinge- de la estructura de datos o formato de archivos exis-
nieria. Por ejemplo, Chot y Acacchi [CH090] sugieren la tentes. Otra forma de redisefio, denominada racio-
creacion de un diagrama de intercambio de recursos que nalizacidn de nombres de datos, garantiza que todas
diseiia cada uno de 10s modulos de programa y 10s recur- las convenciones de denominaci6n de datos se ajus-
sos (tipos de datos, procedimientos y variables) que se ten a 10s estandares locales, y que se eliminen las
intercambian en este y otros m6dulos. Mediante la crea- irregularidades a medida que 10s datos fluyen por el
cion de representaciones del flujo de recursos, la arqui- sistema.
tectura del programa se puede reestructurar para lograr Cuando la reestructuracion sobrepasa la estandari-
el acoplamiento minimo entre 10s modulos. zaci6n y la racionalizacion, se efectuan modificaciones
fisicas en las estructuras de datos ya existentes con obje-
to de hacer que el disefio de datos sea mas efectivo. Esto
30.4.2. Reestructuracibn de 10s datos puede significar una conversion de un formato de archi-
Antes de que pueda comenzar la reestructuracion de vo a otro, o, en algunos casos, una conversion de un tip0
datos, es precis0 llevar a cab0 una ingenieria inver- de base de datos a otra.
Un programa que posea flujo de control es el equivalente caciones, aplicando un enfoque de ingenieria del soft-
grhfico de un plato de espaguetis con ccm6dulos>>,es decir ware a todos 10s segmentos revisados.
con 2.000 sentencias de longitud; con pocas lineas de 4. La posibilidad de redisefiar, recodificar y comprobar
comentario utiles en 290.000 sentencias de c6digo fuente, el programa en su totalidad, utilizando herramientas
y sin ninguna otra documentaci6n que se deba modificar CASE (herramientas de reingenieria) que serviran
para ajustarle a 10s requisitos de cambios del usuario. Se para comprender el disefio actual.
puede decir que disponemos de las opciones siguientes:
1. La posibilidad de esforzarse por efectuar una modi- No existe una unica opcion cccorrecta>>.
Las circuns-
ficacion tras otra, luchando con el disefio implicit0 tancias pueden imponer la primera opcibn, aun cuando
y con el codigo fuente para implementar 10s cambios las otras Sean las preferidas.
necesarios. En lugar de esperar a que se reciba una solicitud
2. La posibilidad de intentar comprender el funciona- de mantenimiento, la organizaci6n de desarrollo o
rniento intemo m h amplio del programa, en un esfuerzo de soporte utilizara 10s resultados del analisis de
por hacer que las modificaciones Sean mas efectivas. inventario para seleccionar el prograrna ( 1 ) que con-
tinue utilizandose durante un numero determinado
de afios, (2) que se estC utilizando con Cxito en la
iQue optiones existen
tuando nos enfrentamos
actualidad, y (3) que tenga probabilidades de sufrir
ton un programa de diseiio
grandes modificaciones o mejoras en un futuro pr6-
e implementation pobres?
ximo. Entonces, se aplicardn las opciones 2, 3 6 4
anteriores.
Este enfoque de mantenimiento preventivo fue intro-
3. La posibilidad de redisefiar, recodificar y comprobar ducido por Miller [MIL811 con el nombre de ccreajuste
aquellas partes del software que requieran modifi- estructuradou. Definia este concept0 como ccla aplica-
ci6n de las metodologias de hoy a 10s sistemas de ayer 30.5.1. Ingenieria directa para arquitecturas
,para prestar apoyo a 10s requisitos del maiiana>>. clientelservidor
A primera vista, la sugerencia de volver a desarro- A lo largo de la ultima dCcada, muchas aplicaciones de
llar un gran programa cuando ya existe una versi6n ope- grandes computadoras han sufrido un proceso de rein-
rativa puede parecer mas bien extravagante. Sin genieria para adaptarlas a arquitecturas clientelservidor
embargo, antes de pasar a emitir un juicio, considCren- (CIS). En esencia, 10s recursos de computaci6n centra-
lizados (incluyendo el software) se distribuyen entre
El coste de mantener una linea de c6digo fuente muchas plataformas cliente. Aunque se puede diseiiar
puede estar entre veinte y cuarenta veces por encima toda una garna de entomos distribuidos distintos, la apli-
del coste del desarrollo inicial de esa linea. caci6n tipica de computadora central que sufre un pro-
El rediseiio de la arquitectura del software (del proceso de reingenieria para adoptar una arquitectura
grama y/o de las estructuras de datos) empleando clientelservidor posee las caracteristicas siguientes:
conceptos de diseiio modemos puede facilitar mucho la funcionalidad de la aplicaci6n migra hacia todas
el mantenimiento futuro. las computadoras cliente;
Dado que ya existe un prototipo del software, la pro- se implementan nuevas interfaces IGU en 10s cen-
ductividad de desarrollo debera ser mucho m& ele- tros clientes;
vada que la media. las funciones de bases de datos se le asignan a1 ser-
En la actualidad, el usuario ya tiene experiencia con vidor;
el software. Por tanto, 10s nuevos requisitos y la direc- la funcionalidad especializada (por ejemplo, 10s an&
ci6n dei cambio se podran estimarse con rnucha mas lisis de computaci6n intensiva) pueden permanecer
facilidad. en el centro del servidor; y
Las herramientas CASE para la reingenieria auto- 10s nuevos requisitos de comunicaciones, seguridad,
matizaran algunas partes del trabajo. archivado y control deberan establecerse tanto en el
Cuando finalice el mantenimiento preventivo, se dis- centro cliente, como en el centro servidor.
pondra de una configuraci6n completa del software
(documentos, programas y datos).
Lo reingenierio es muy similar ol hecho de lovone Es importante tener en cuenta que la migration des-
10s dientes. Se puede pensor en mil rozones de computadoras centrales a un proceso CIS requiere
y tordor en lovbnelos, dejbndolo poro mbs torde. tanto una reingenieria del negocio como una reinge-
Pero, 01 fino/, estos tbcticos de reirasor 10s cosos nieria del software. Ademhs, es precis0 establecer una
siempre volverbn o rondornos. ccinfraestructura de red de empress>>. [JAY941
Cuando una organizaci6n de desarrollo de software
vende el software como un producto, el mantenimien-
to preventivo se ve como ctnuevas versionesn del pro- En olgunos cosos, 10s sistemos t/S o 10s sistemos 00
grama. Un gran desarrollador de software local (por disedodos para reemplozor uno oplicocibn ontiguo deberon
ejemplo, un grupo de desarrollo de software de siste- enfocorse como un proyecto nuevo de desorrollo.
mas para una compaiiia de productos de un consumidor Lo reingenierio entro en iuego solo cuondo 10s elementos
de un sistemo ontiguo se van o integror mn lo nueva
de gran volumen) puede tener entre 500 y 2.000 pro-
orquitectum. €n olgunos cosos, quiz$ es meior no acepeptor
gramas de produccion dentro de su dominio de respon- lo viejo y creor uno funcionolidod nuevo e idintica.
sabilidad. Se podran asignar prioridades a estos
programas segun su importancia, y a continuaci6n se La reingenieria de aplicaciones CIS comienza con
revisaran esos programas como 10s candidatos para el un analisis exhaustivo del entomo de negocios que abar-
mantenimiento preventivo. ca la computadora central existente. Se pueden identi-
El proceso de ingenieria del software aplica prin- ficar tres capas de abstracci6n (Fig. 30.4). La base de
cipios, conceptos y mCtodos de ingenieria del softwa- datos se encuentra en 10s cimientos de la arquitectura
re para volver a crear las aplicaciones existentes. En clientelservidor, y gestiona las transacciones y consul-
la mayoria de 10s casos, la ingenieria directa no se limi- tas que proceden de las aplicaciones de servidor. Sin
ta a crear un equivalente modemo de un programa ante- embargo, estas transacciones y consultas tienen que ser
rior, sino que mas bien se integran 10s nuevos requisitos controladas en el context0 de un conjunto de reglas de
y las nuevas tecnologias en ese esfuerzo de volver a negocio (definidas por un proceso de negocio ya exis-
aplicar reingenieria. El programa que se ha vuelto a tente o que ha experimentado una reingenieria). Las
desarrollar amplia las capacidades de la aplicaci6n aplicaciones de cliente proporcionan la funcionalidad
anterior. deseada para la comunidad de usuarios.
Las funciones del sistema de gestion de bases de Un estudio cornpleto sobre el disefio y reingenieria
datos ya existente y la arquitectura de datos de la base de software clientelservidor es mhs adecuado para otros
de datos existente deberan sufrir un proceso de inge- libros especializados en este materia. El lector intere-
nieria inversa como precedente para el redisefio de la sad0 debera consultar [VAS93], [INMW [ y [BER92].
capa de fundamento de la base de datos. En algunos
casos, se crea un nuevo modelo de datos (Capitulo 12). 30.5.2. Ingenieria directa para arquitecturas
En todos 10s casos, la base de datos CIS sufre un pro-
ceso de reingenieria para asegurar que las transaccio- orientadas a objetos
nes se ejecutan consistentemente; para asegurar que La ingenieria del software orientada a objetos se ha trans-
todas las actualizaciones se efectuen dnicamente por formado en el paradigma opcional de desarrollo para
usuarios autorizados; para asegurar que se impongan muchas organizaciones de software. Sin embargo, iquC
las reglas de negocios fundarnentales (por ejemplo, antes sucede con las aplicaciones existentes que se desarro-
de borrar el registro de un proveedor, el servidor se ase- llaron empleando mktodos convencionales? En algunos
gura de que no exista ningun registro pendiente, con- casos, la respuesta consiste en dejar estas aplicaciones
trato o comunicaci6n para ese proveedor); para asegurar tal y como eran. Pero en otros casos, es preciso aplicar
que se puedan admitir las consultas de forma eficaz; y una reingenieria a las viejas aplicaciones para que se
para asegurar que se ha establecido una capacidad com- puedan integrar facilmente en grandes sistemas orienta-
pleta de archivado. dos a objetos.
La reingenieria del software convencional para pro-
ducir una implementation orientada a objetos hace uso
Interfaz: IGU de muchas de las mismas tCcnicas descritas en la Cuar-
ta Parte de este libro. En primer lugar, se hace una inge-
nieria inversa del software existente para que sea posible
Aplicaciones cliente
crear 10s modelos adecuados de datos, funcional y de
comportamiento. Si el sistema que se aplica a la reinge-
nieria extiende la funcionalidad o comportamiento de la
I aplicaci6n original, se crean casos prkticos (Capitulos
Interfaz: solicitudes de proceso 11 y 21). Los modelos de datos creados durante la inge-
nieria inversa se utilizan entonces junto con un modela-
do CRC (Capitulo 21) para establecer la base para la
definicidn de clases. Las jerarquias de clases, 10s mode-
10s de relaciones entre objetos, 10s modelos de compor-
tamiento de objetos, y 10s subsistemas se definen a
continuation, y comienza el disefio orientado a objetos.
I Interfaz: transacciones y consultas A medida que la ingenieria directa orientada a objetos
pasa del anhlisis hasta el disefio, se podra invocar el mode-
lo de proceso de ISBC (Capitulo 27). Si la aplicaci6n exis-
tente se encuentra con un dorninio ya ha sido popularizada
por muchas aplicaciones orientadas a objetos, es proba-
ble que exista una biblioteca robusta de componentes y
FIGURA 30.4. Proceso de reingenieria de aplicaciones que se pueda utilizar durante la ingenieria directa.
de cornputadores centrales a clientelservidor. Para aquellas clases que sea preciso construir partiendo
de cero, quiz6 sea posible reutilizar algoritmos y estruc-
La capa de reglas de negocios representa el software turas de datos procedentes de la aplicaci6n convencional
residente tanto en el cliente como en el servidor. Este ya existente. Si embargo, es preciso volver a disefiarlos
software lleva a cab0 las tareas de control y coordina- para ajustarse a la arquitectura orientada a objetos.
ci6n para asegurar que las transacciones y consultas
entre la aplicaci6n cliente y la base de datos se ajusten
a 10s procesos de negocios establecidos. 30.5.3. Ingenieria directa para interfaces
La capa de aplicaci6n del cliente implementa las fun- de usuario
ciones de negocios requeridas por grupos especificos de Cuando las aplicacionesrnigran desde la computadora cen-
usuarios finales. En muchos casos, se segrnenta una apli- tral a la computadora de sobremesa, 10s usuarios ya no
caci6n de computadora central en un cierto numero de estih dispuestos a adrnitir unas interfaces de usuarios arca-
aplicaciones miis pequefias, sometidas a reingenieria, y nas basadas en caracteres. De hecho, una parte significa-
adecuadas para su funcionamiento de sobremesa. La tiva de todos 10s esfuerzos invertidos en la transicidn desde
comunicaci6n entre aplicaciones de sobremesa (cuando la computaci6n de computadora central hash la arquitec-
es necesaria) sera controlada por la capa de reglas de tura clientelservidor se pueden reinvertir en la reingenie-
negocios. ria de las interfaces de usuario de la aplicaci6n cliente.
siendo 10s rnismos. La interfaz redisefiada debera seguir

$uCles son 10s pasos a seguir
para una ingenieria de interfaz
permitiendo que el usuario muestre el comportamiento
de usuario?
de negocios adecuado. Por ejemplo, cuando se efec-
tua una consulta en una base de datos, es posible que,
Merlo y colaboradores [MER95] sugieren el modelo para especificar la consulta, la interfaz vieja necesite
siguiente para la reingenieria de interfaces de usuario: una serie larga de 6rdenes basadas en textos. La IGU
Comprender la interfaz original y 10s datos que se sometida a reingenieria puede hacer que la consulta
trasladan entre ella y ei resto de la aplicacidn. El sea mas eficiente, reducikndola a una pequeiia secuen-
objetivo es comprender la forma en que 10s demhs cia de selecciones con el ratbn, per0 la intenci6n y el
elementos del programa interactiian con el c6digo contenido de la consulta deberin permanecer intactas.
existente que implementa la interfaz. Si se ha de desa- lntroducir mejoras que hagan que el modo de inter-
rrollar una nueva IGU, entonces el flujo de datos accidn sea mds efrciente. Los fallos ergon6micos de
entre la IGU y el resto del programa debera ser con- la interfaz existente se estudian y se corrigen en el
secuente con 10s datos que en la actualidad fluyen disefio de la IGU nueva.
entre la interfaz basada en caracteres y el programa. Constrrlir e integrar la IGU nueva. La existencia de
Remodelar el camportamiento implicit0 en interfaz bibliotecas de clases y de herramientas de cuarta
existente para formar una serie de abstracciones que generaci6n puede reducir el esfuerzo requerido para
tengan sentido en el contexto de m a IGU. Aunque el construir la IGU de forma significativa. Sin embargo,
modelo de interacci6n pueda ser radicalmente distinto, la integraci6n con el software de aplicacion ya exis-
el comportamiento de negocios mostrado por 10s usua- tente puede llevar mas tiempo. Para asegurarse de
rios de la interfaz nueva y vieja (cuando se consideran que la IGU no propague unos efectos adversos a1
en funci6n del escenario de utilizaci6n) deberh seguir resto de la aplicaci6n es preciso tener cuidado.
En un mundo perfecto, todo programa que no se pudie-

ra mantener se retiraria inmediatamente, para ser susti-
tuido por unas aplicaciones de alta calidad, fabricadas
mediante reingenieria y desarrolladas empleando las
prhcticas de la ingenieria del software modernas. Sin
embargo, vivimos en un mundo de recursos limitados.
La reingenieria consume recursos que se pueden utili-
zar para otros prop6sitos de negocio. Consiguiente-
mente, antes de que una organizaci6n intente efectuar El coste asociado a1 mantenimiento continuado de
una reingenieria de la aplicaci6n existente, debera lle- una aplicaci6n candidata (esto es, si no se realiza la rein-
var a cab0 un anhlisis de costes y beneficios. genieria) se puede definir como:
Sneed [SNE95] ha propuesto un modelo de analisis
de costes y beneficios para la reingenieria. Se definen C,,, = [P3 - (PI + P2)I X L (30.1)
nueve parametros: Los costes asociados con la reingenieria se definen
P I = coste de mantenimiento anual actual para una empleando la relaci6n siguiente:
aplicaci6n;
Pz = coste de operaci6n anual de una aplicaci6n;
Empleando 10s costes presentados en la ecuaciones
P3 = valor de negocios anual actual de una aplicaci6n; (30.1) y (30.2), 10s beneficios globales de la reingenie-
P4 = coste de mantenimiento anual predicho despuCs ria se pueden calcular en la forma siguiente:
de la reingenieria;
P5 = coste de operaciones anual predicho despuCs de Beneficio y coste = - Cmant (30.3)
la reingenieria; El analisis de costes y beneficios presentados en
P6 = valor de negocio actual predicho despuCs de la las ecuaciones anteriores se puede llevar a cab0 para
reingenieria; todas aquellas aplicaciones de alta prioridad que se
hayan identificado durante un anhlisis de inventario
P7 = costes de reingenieria estimados;
(Seccion 30.2.2). Aquellas aplicaciones que muestren
P8 = fecha estimada de reingenieria; el mayor beneficio en relaci6n con 10s costes podrhn
P9 = factor de riesgo de la reingenieria (P9 = 1,O es destinarse a la reingenieria, mientras que las demis
el valor nominal); podran ser propuestas hasta que se disponga de m8s
L = vida esperada del sistema. recursos.
La ingenieria se produce en dos niveles distintos de dad -se trata de programas que Sean viables hasta bien
abstraccion. En el nivel de negocios, la reingenieria entrado el siglo veintiun*.
se concentra en el proceso de negocios con la inten- El analisis de inventarios permite que una organiza-
ci6n de efectuar cambios que mejoren la competitivi- cion estime todas y cada una de las aplicaciones siste-
dad en algun aspect0 de 10s negocios. En el nivel del maticamente, con el fin de determinar cuales son las
software, la reingenieria examina 10s sistemas y apli- candidatas para una reingenieria. La reestructuracion
caciones de informacion con la intencion de rees- de documentos crea un marco de trabajo de documen-
tructurarlos o reconstruirlos de tal mod0 que muestren tos necesario para el apoyo de una cierta aplicacion a
una mayor calidad. largo plazo. La ingenieria inversa es el proceso de ana-
La reingenieria de procesos de negocio (RPN) defi- lizar un programa en un esfuerzo por extraer informa-
ne 10s objetivos de negocios, identifica y evalua 10s cion acerca de 10s datos, de su arquitectura y del disefio
procesos de negocios ya existentes (en el context0 de de procedimientos. Por ultimo, la ingenieria directa
10s objetivos definidos), especifica y disefia 10s pro- reconstruye el programa empleando practicas de inge-
cesos revisados, y construye prototipos, refina e ins- nieria moderna del software y la informacion obtenida
tancia esos procesos en el sen0 de un negocio. La RPN durante la ingenieria inversa.
tiene un objetivo que va mas all6 del software. Su resul- Los costes y beneficios de la reingenieria se pue-
tad0 suele ser la definicion de formas en que las tec- den determinar de forma cuantitativa. El coste del sta-
nologias de la informacion puedan prestar un mejor tus quo, esto es, 10s costes asociados a1 mantenimiento
apoyo a 10s negocios. y soporte que conlleva una aplicacion existente se pue-
La reingenieria del software abarca una serie de acti- de comparar con 10s costes estimados de la reingenie-
vidades entre las que se incluye el analisis de inventa- ria, y con la reduccion resultante de 10s costes de
rio, la reestructuracion de documentos, la ingenieria mantenimiento. En casi todos 10s casos en que un pro-
inversa, la reestructuracion de programas y datos, y la grama tiene una vida larga y muestra en la actualidad
ingenieria directa. El objetivo de esas actividades con- un mantenimiento dificultoso, la reingenieria repre-
siste en crear versiones de 10s programas existentes que senta una estrategia de negocios eficiente en relacion
muestren una mayor calidad, y una mejor mantenibili- con 10s costes.
[ARN89] Arnold, R. S., <<SoftwareRestructuring)), Proc. [DEM95] DeMarco, T., <<Leanand Mean,,, IEEE Softwczre,
IEEE, vol. 77, n." 4, Abril de 1989, pp. 607-617. Noviembre de 1995, pp. 101-102.
[BER92] Berson, A., ClientlServer Architecture, McGraw- [DIC95] Dickinson, B., Strategic Business Reengineering,
Hill, 1992. LC1 Press, 1995.
[BLE93] Bleakley. F.R.. <<The Best Plans: Many Companies [HAM901 Hammer, M., <<Reengineer Work: Don't Automa-
Try Management Fads, Only to See Them Flop)),The Wall te, Obliterate,,, Harvard Business Review, Julio-Agosto
Street Journal, 6 de Julio de 1993, p. 1. de 1990, pp. 104-112.
[BRE911 Breuer, P.T., y K. Lano, <<CreatingSpecification [HAN93] Hanna, M., <<MaintenanceBurden Begging for a
From Code: Reverse-Engineering Techniques,,, Journal Remedy,), Datamation, Abril de 1993, pp. 53-63.
of Software Maintenance: Research and Practice, vol. 3,
Wiley, 1991, pp. 145-162. [INM93] Inmon, W.H., Developing Client Server Applica-
tions, QED Publishing, 1993.
[CAN721 Canning, R., <<TheMaintenance "Iceberg",,, EDP
Analyzer, vol. 10, n." 10, Octubre de 1972. [JAY941 Jaychandra, Y., Re-engineering the Networked Enter-
prise,,, McGraw-Hill, 1994.
[CAS88] <<Case Tools for Reverse Engineering,,, CASE Out-
look, CASE Consulting Group, Lake Oswego, OR, vol. 2, [MAR941 Markosian, L. et al., <<Usingan Enabling Techno-
n." 2, 1988, pp. 1-15. logy to Reengineer Legacy Systems, CACM, vol. 37, n." 5,
Mayo de 1994, pp. 58-70.
[CHI901 Chifofsky, E.J., y J.H. Cross, 11, <<ReverseEnginee-
ring and Design Recovery: A Taxonomy,,, IEEE Software, [MER93] Merlo, E. et al., <<ReverseEngineering of User
Enero de 1990, pp. 13-17. Interfaces,,, Proc. Working Conference on Reverse Engi-
neering, IEEE, Baltimore, MD, Mayo de 1993, pp. 171-
[DAV90] Davenport, T.H., y J.E. Young, <<TheNew Indus- 178.
trial Engineering: Information Technology and Business
Process Redesign,,, Sloan Management Review, Summer [MER95] Merlo, E. et al., <<Reengineering
User Interfaces)),
1990, pp. 11-27. IEEE Software, Enero de 1995, pp. 64-73.
~ N G E N ~ E RDEL
~ A SOFTWARE. UN ENFOQUE P R A C T ~ C O
[MIL8 1 ] Miller, J., Techniques of Program and System Main- [STE93] Steward, T.A., ctReengineering: The Hot New Mana-
tenance (G. Parikh, ed.), Winthrop Publishers, 1981. ging Tool)), Fortune, 23 de Agosto de 1993, pp. 41-48.
[OSB90] Osbome, W.M., y E.J. Chifofsky, ((Fitting Pieces to [SWA76] Swanson, E.B., <The Dimensions of Maintenan-
the Maintenance Puzzle)),IEEE Software, Enero de 1990, ce)), Proc. 2nd Intl. Conf. Software Engineering. IEEE,
pp. 10-11. Octubre de 1976, pp. 492-497.
[PRE94] Premerlani, W.J., y M.R. Blaha, ((An Approach for [VAS93] Vaskevitch, D., ClientlServer Strategies, IDG Books,
Reverse Engineering of Relational Databases)), CACM, San Mateo, CA, 1993.
vol. 37, n." 5, Mayo de 1994, pp. 42-49. [WAR741 Wamier, J.D., Logical Construction of Programs,
[RIC89] Ricketts, J.A., J.C. DelMonaco y M.W. Weeks, ((Data VanNostrand Reinhold, 1974.
Reengineering for Application Systems)),Proc. Conf. Soft- [WE1951 Weisz, M., <<BPRis Like Teenage Sex)),American
ware Maintenance-1 989, IEEE, 1989, pp. 174-179. Programmer, vol. 8, n." 6, Junio de 1995, pp. 9-15.
30.1. Considere cualquier trabajo que haya desempeiiado en 30.5. Sugiera alternativas para el papel y el lapiz o para la
10s dltimos cinco aiios. Describa el proceso de negocios en documentaci6n electronica convencional que puedan semir
que haya desempefiado su funcion. Utilice el modelo RPN como base para la reestructuraci6n de documentos. [Pista:
descrito en la Secci6n 30.1.3 para recomendar cambios en el Piense en las nuevas tecnologias descriptivas que se podrian
proceso con la intencidn de hacerlo mas eficiente. utilizar para comunicar el objetivo del software.]
30.2. Realice una investigacion acerca de la eficacia de la rein- 30.6. Algunas personas creen que las tCcnicas de inteligencia
genieria de procesos de negocios. Presente argumentos a favor artificial incrementaran el nivel de abstraccion de 10s proce-
y en contra de este enfoque. sos de ingenieria inversa. Efectde una investigacidn sobre este
30.3. Su profesor seleccionara uno de 10s programas que haya tema (esto es, el uso de la IA para ingenieria inversa) y escri-
desarrollado alguien de la clase durante el curso. Intercambie ba un articulo breve que se decante por este tema.
su programa aleatoriamente con cualquier otra persona de la 30.7. iPor quC es mas dificil lograr la completitud a medida
clase. No le explique ni revise el programa. A continuacibn, que el nivel de abstraccion crece?
implemente una mejora (especificada por el instructor) en el 30.8. iPor quC tiene que incrementarse la interactividad si es
programa que haya recibido. precis0 incrementarse la completitud?
a. Lleve a cab0 todas las tareas de ingenieria del software
incluyendo una breve revision (pero no con el autor del 30.9. Obtenga literatura de productos correspondientes a tres
programa). herramientas de ingenieria inversa y presente sus caractens-
ticas en clase.
b. Lleve la cuenta cuidadosamente de todos 10s errores encon-
trados durante la comprobacion. 30.10. Existe una diferencia sutil entre la reestructuraci6n y
c. Describa su experiencia en clase. la ingenieria directa. iEn quC consiste?
30.4. Explore la lista de comprobaci6n del anilisis de inventa- 30.11. Investigue en la literatura para hallar uno o dos articu-
n o presentada en el sitio Web SEPA e intente desarrollar un sis- 10s que describan casos practicos de reingenieria de grandes
tema de evaluation cuantitativo del software que se pueda aplicar computadoras para producir una arquitectura cliente/semidor.
a 10s programas existentes en un esfuerzo de seleccionar 10s pro- Presente un resumen.
gramas candidatos para su reingenieria. Su sistema debera ir 30.12. iC6m0 se determinarian 10s valores de P4 a P7 en el
mas all5 del anilisis economico presentado en la Seccion 30.6. modelo de costes y beneficios presentado en la Secci6n 30.6?
A1 igual que muchos tdpicos candentes dentro de la comuni- 1997), Hunt (ProcessMapping: How to Reengineer Your Busi-
dad de negocios, el bombo publicitario de la reingenieria de ness Processes, Wiley 1996), y Carr y Johanson (Best Prac-
procesos de negocios ha dado pie a una vision mas pragmAti- tices in Reengineering: What Works and What Doesn't in the
ca del tema. Hammer y Champy (Reengineering the Corpo- Reengineering Process, McGraw-Hill, 1995) presentan casos
ration, HarperCollins, 1993) anticiparon gran inter& por el practicos y lineas generales detalladas para RPN.
tema con su best seller. ~osteriormente,Hammer (Beyond Feldmann (The Practical Guide to Business Process Reen-
Reengineering: How the Processed-Centered Organization is gineering Using IDEFO, Dorset House, 1998) estudia una
Changing Our Work and Our Lives, Harper-Collins, 1997) refi- notaci6n modelada que ayuda en la RPN. Berztiss (Software
no su vision centrimdose en temas cccentrados en procesos)). Methods for Business Reengineering, Springer, 1996) y Spurr
Los libros de Andersen (Business Process Improvement y colaboradores (Software Assistance for Business Reengi-
Toolbox, American Society for Quality, 1999), Harrington et neering, Wiley, 1994) estudian las herramientas y tCcnicas
al. (Business Process Improvement Workbook, McGraw-Hill, que facilitan la RPN.
Relativamente pocos libros se han dedicado a la reingenie- mation Architectures: Reengineering Information Systems,
ria del software. Rada (Reengineering Software: How to Reu- Prentice Hall, 1996) estudia el puente que existe entre RPN
se Programming to Build New, State-Of-The-Art Software, y la tecnologia de informacidn. Aiken (Data Reverse Engi-
Fitzroy Dearborn Publishers, 1999) se centra en la reinge- neering, McGraw-Hill, 1996) estudia cdmo reclamar, reor-
nieria a un nivel tCcnico. Miller (Reengineering Legacy Soft- ganizar y reutilizar 10s datos de la organizacih. Arnold
ware Systems, Digital Press, 1998) ccproporciona un marco (Software Reengineering, IEEE Compute; Society Press,
de trabajo para mantener 10s sistemas de aplicaciones sin- 1993) ha publicado una antologia excelente de 10s primeros
cronizados con las estrategias de negocios y con 10s cambios trabajos sobre las tecnologias de reingenieria del software.
tecnologicos>>.Umar (Application (Re)Engineering: Building En Intemet se disponen de gran variedad fuentes de infor-
Web-BasedApplications and Dealing With Legacies, Prentice macidn sobre la reingenieria de procesos de negocios y la
Hall, 1997) proporciona una guia valiosa para aquellas orga- reingenieria del software. Una lista actualizada de referen-
nizaciones que quieren transformar 10s sistemas antiguos en cias a sitios (paginas) web se puede encontrar en la direccidn
un entomo basado en Web. Cook (Building Enterprise Infor- http:/www.pressman5.com.
funciones
del reposiforio .... .561-8
I --.*.*P r,,
I-CASE ............ -565

IPSE .............. .561
......
iQu6 es? Las herramlentas CASE ayude trabajo o para rwlizar algirn hito tie- niero del software en la producci6n de
dan a los gestores y practicantes d e la ne un beneficio sustancial. Pero hay resultados de alta calidad. Ademas,
ingenieria del software en todas l a s algo incluso mas importante. Lus hena- disponer d e automatizacidn permite
actividades asociadas a 10s procesos mientas pueden proporcionar nuevas que el usuario de CASE elabore resul-
d e software. Automatizan las activida- formas de obsewar la iniormaci6n de la tados adicionales y personalizados
des de gestion de proyectos, gestionan Ingenieria del software -formas que que no serdn fdrciles ni pr6rcticos d e
todos 10s productos de 10s trabajos ela- mejoran la perspicacia del ingeniero producir sin el soporte de l a s herra-
borados a travbs del proceso. y ayudan que realiza el trabaj-. Esto conduce a mientas.
a 10s ingenieros en el trabajo de anali- tomar mejores decisiones y conseguir LCdmo pueda estar seguro de que
sis, diseiio y codificaci6n. Lus herra- una wlidad mejor del software. lo he hecho correctamente? Uti-
mientas CASE s e pueden integrar ~ C u i l e son
s 10s pasos? CASE se utili- lice las herramientas como comple-
dentro de un entomo sofisticado. za junto con el modelo de procesog que mento d e las prdrcticas d e ingenleria
lQul6n lo hace? Los gestores d e pm- s e haya elegido. Si se dispone d e un del software -no como sustitutivcr-.
yectos y 10singenieros del software. juego completo de herramientas. se uti- Antes de poder utilizar las herramien-
@or qu6 es importante?La ingenieria lizar&CASEa lo largo de casi todos 10s tas eficazmente, deber6n aprenderse
del software e s dificil. Lus herramientas pasos del proceso d e software. 10sconceplos y mbtodos de la ingenie-
que reducen la cantidad de esfuem que &Cat51es el producto obtenido?Las ria del software. Solo entonces CASE
s e requiere para producir un producto herramientas CASE ayudan a1 inge- proporcionardr algrin beneiicio.
INGENIERIA DEL SOFTWARE. UN ENFOQUE P R ~ C T I C O
El mejor taller de un artesano -sea mecinico, carpin- El taller de ingenieria del software se denomina un
tero o ingeniero del software- tiene tres caracteristi- entorno de apoyo integ~wdoa proyecfos (que se des-
cas fundamentales: (1) una colecci6n de herramientas cribirri posteriormente en este capitulo), y el conjunto
utiles que le ayudalin en todos 10s pasos de la cons- de herramientas que llena ese taller se denomina inge-
truccion de un producto; (2) una disposition organiza- nieri'u del software asisfida por computadora (CASE).
da que permitirri hallar ripidamente las herramientas y CASE proporciona a1 ingeniero la posibilidad de
utilizarlas con eficacia; y (3) un artesano cualificado que automatizar actividades manuales y de mejorar su visi6n
entienda la forma de utilizar las herramientas de mane- general de la ingenieria. A1 igual que las herramientas
ra eficaz. Ahora es cuando 10s ingenieros del software de ingenieria y de diseiio asistidos por computadora que
reconocen que necesitan m;is herramientas y m b varia- utilizan 10s ingenieros de otras disciplinas, las herra-
das junto con un taller eficiente y organizado en el que mientas CASE ayudan a garantizar que la calidad se
puedan ubicarlas. diseiie antes de llegar a construir el producto.
La ingenieria del software asistida por computadora permiten a cada una de las herramientas comunicarse
puede ser tan sencilla ccmo una dnica herramienta que entre si, para crear una base de datos clel proyecto, y
preste su apoyo para una unica actividad de ingenieria para mostrar el mismo aspecto a1 usuario final (el inge-
clel software, o tan compleja como todo un entorno que niero del software). Los servicios de portabilidad per-
abarque ccherramientasu, una base de datos, personas, miten que las herramientas CASE y su marco de
hardware, una red, sistemas operativos, estrindares, y integraci6n migren entre distintas plataformas del hard-
otros mil componentes mris. Los bloques de construc- ware y sistemas operativos sin un mantenimiento adap-
ci6n de CASE se ilustran en la Figura 3 1.1. Cada blo- tativo significative.
que de construcci6n forma el fundamento del siguiente,
estando las herramientas situadas en la parte superior
del m o n t h . Es interesante tener en cuenta que el fun-
damento de 10s entornos CASE efectivos tiene relati-
Herramientas CASE
h
vamente poco que ver con las herramientas de ingenieria
del software en sf. Miis bien, 10s entomos para la inge- I Marco de lntegracidn
h
nieria del software se construyen con Cxito sobre una
arquitectura de entornos que abarca un hardware y un
software de sistemas adecuados. Ademis, la arquitec-
I Servicios de portabilidad
k
tura del entorno deberh tener en cuenta 10s patrones de Sistema operativo 1
trabajo humano que se aplicarrin durante el proceso de -
ingenieria del software. Plataforma hardware
h
Arqubcmra de entorno
1
10s herramientas CASE m6s voliosas son aquellas

- 1
-
.=--
que contribuyen can informacibn en el procesa de FIGURA 31.1. Bloques de construccion CASE.
desarrallo.
Robert Dixan Los bloques de construcci6n representados en la
Figura 3 1.1 representan un fundamento completo para
la integraci6n de herramientas CASE. Sin embargo, la
Las arquitecturas del entomo, que constan de una pla- mayor parte de las herramientas CASE que se utilizan
taforma hardware y de un soporte de sistema operativo en la actualidad no han sido construidas empleando
(incluyendo software de red, gesti6n de la base de datos todos 10s bloques de construcci6n anteriormente des-
y servicios de gesti6n de objetos), establece 10s cimien- critos. De hecho, algunas herramientas siguen siendo
tos para un entorno CASE. Pero el entorno CASE en si las ccsoluciones puntuales>>.Esto es, una herramienta se
requiere otros bloques de construcci6n. Existe un con- utiliza para prestar apoyo en una actividad de ingenie-
junto de servicios de portahiliclad que proporciona un ria del software concreta (por ejemplo, modelado de
puente entre las herramientas CASE, su marco de inte- anfilisis), pero esta herramienta no se comunica direc-
graci6n y la arquitectura del entorno. El marc0 de inre- tamente con otras, no esth unida a una base de datos del
~ r a c i b ne s un grupo de programas especializados que proyecto, y no forma parte de un entorno integrado
CASE (I-CASE). Aunque esta situaci6n no es la ideal, puente entre herramientas (por ejemplo, una herramienta
se puede utilizar una herramienta CASE bastante efi- de anhlisis y diseiio que se enlaza con un generador de
ciente, aunque se trate de una solicitud puntual. codigo). Mediante la utilizaci6n de este enfoque, la siner-
gia entre herramientas puede producir unos resultados
finales que senan dificiles de crear empleando cada una
Herramienta individual
0 (solucion puntual)
de las herramientas por separado. La integracibn de
fuente zinica se produce cuando un dnico vendedor de
herramientas CASE integra una cierta cantidad de herra-
Fuente unica mientas distintas y las vende en forma de paquete. Aun-
lntercambio de datos que este enfoque es bastante eficiente, la arquitectura
cerrada de la mayoria de 10s entomos de fuente dnica
puentes y asociaciones
entre herramientas ???? evita aiiadir fhcilmente herramientas procedentes de
otros fabricantes.
EAIP Las herramientas CASE de solucion puntual pueden

proporcionar un beneficio sustancial, pero un equipo de
FIGURA 31.2. Opciones integradas.
s o b r e necesita herramientas que se comuniquen entre
si las herromientas integradas ayudan o que el equipo
Los niveles relativos de integraci6n CASE se mues- desorrolle, orgonice y cantrole 10s productos del trobojo.
tran en la Figura 3 1.2. En el extremo inferior del espec- Utilkelas.
tro de integraci6n se encuentra la herramienta individual
(soluci6n puntual). Cuando las h e m i e n t a s individuales En el extremo superior del espectro de integraci6n
proporcionan servicios para el intercambio de datos se encuentra el entorno de apoyo integrado a proyec-
(como lo hacen la mayona), el nivel de integraci6n mejo- tos integrado (EAIP). Se han creado esthndares en cada
ra ligeramente. Estas herramientas producen su salida uno de 10s bloques de construcci6n descritos anterior-
en un formato esthndar que deberh ser compatible con mente. Los fabricantes de herramientas CASE utilizan
otras herramientas que Sean capaces de leer ese forma- 10s esthndares EAIP para construir herramientas que
to. En algunos casos, 10s constructores de herramientas Sean compatibles con el EAIP, y que por tanto Sean com-
CASE complementarias trabajan juntos para formar un patibles entre si.
Existe un cierto ndmero de riesgos que son inherentes nistradores o personal tCcnico, por su utilizaci6n en 10s
siempre que se intenta efectuar una categorizacidn de distintos pasos del proceso de ingenieria del software,
las herramientas CASE. Existe una sutil implicaci6n que por la arquitectura del entomo (hardware y software)
consiste en que para crear un entomo CASE efectivo se que les presta su apoyo, o incluso por su origen o cos-
deberh implement= todas las categonas de h e m i e n t a s te [QED89]. La taxonomia que se presenta a continua-
-+st0 no es ni sencillo, ni ciert-. Cuando hay perso- ci6n utiliza como criterio principal la funci6n.
nas que creen que una herramienta pertenece a una cate-
goria, se puede crear cierta confusi6n (o contradicci6n)
a1 ubicar una herramienta especifica dentro de otra cate-
gona. Es posible que algunos lectores piensen que se ha
omitido una categoria completa --eliminando por tan-
to un conjunto de herramientas completo e incluirlo asi
en el entomo CASE global-. Ademhs, una categoriza- Herramientas CASE
ci6n sencilla tiende a ser plana --esto es, no se muestra Herramientas de ingenieria de procesos de nego-
la interaction jerarquica de las herramientas o las relacio. A1 modelar 10s requisitos de informaci6n estratC-
ciones que existen entre ellas-. A pesar de estos ries- gica de una organization, las herramientas de ingenieria
gos, es necesario crear una taxonomia de herramientas de procesos de negocios proporcionan un ccmetamo-
CASE -para comprender mejor la amplitud de CASE delon del cual se derivan sistemas de informaci6n espe-
y para apreciar mejor en donde se pueden aplicar estas cificos. En lugar de centrarse en 10s requisitos de una
herramientas dentro del proceso del software-. aplicaci6n especifica, estas herramientas CASE mode-
Las herramientas CASE se pueden clasificar por su lan la informaci6n de negocio cuando Csta se transfiere
funcibn, por su papel como instrumentos para admi- entre distintas entidades organizativas en el sen0 de una
I N G E N I E R ~ ADEL SOFTWARE. U N ENFOQUE P R A C T I C O
compafiia. El objetivo primordial de las herramientas

. de esta categoria consiste en representar objetos de datos
de negocio, sus relaciones y la forma en que fluyen estos
objetos de datos entre distintas zonas de negocio en el
sen0 de la compafiia.
Herramientas de gestion de proyectos. La planifi-
cacion del proyecto y el plan del proyecto deberan ser
lo ingenierla de procesos de negocios se hata rastreados y monitorizados de forma continua. Ademas,
en el Copitulo 10. el g e s t x debera utilizar las herramientas que recojan
metricas que en ultima instancia proporcionen una indi-
Modelado de procesos y herramientas de gestion. cation de la calidad del product0 del software. Las herra-
Si una organization trabaja por mejorar un proceso de mientas de esta categoria suelen ser extensiones de
negocio (o de software) lo primer0 que debe hacer es herramientas de planificacion de proyectos.
entenderlo. Las herramientas de modelado de procesos
(llamadas tambien herramientas de tecnologia de pro-
cesos) se utilizan para representar 10s elementos clave Elseguimiento y la monitorizocibn se trotan
del proceso de manera que sea posible entenderlo mejor. en el Capitulo 7.
Estas herramientas tambiCn pueden proporcionar vincu-
10s con descripciones de procesos que ayuden a quienes
estCn implicados en el proceso de comprender las tareas Herramientas de seguimiento de requisitos.
que se requieren para llevar a cab0 ese proceso. Ademas, Cuando se desarrollan grandes sistemas, las cosas Kse
las herramientas de gestion de procesos pueden propor- derrumban,,. Es decir, el sistema proporcionado suele
cionar vinculos con otras herramientas que proporcionan no satisfacer 10s requisitos especificados por el cliente.
un apoyo para las actividades de proceso ya definidas. El objetivo de las herramientas de seguimiento es pro-
porcionar un enfoque sistematico para el aislamiento de
10s requisitos, comenzando por el RFP del cliente o por
la especificaci6n. Las herramientas tipicas de segui-
10s elementos de procesos del software se trotan miento de requisitos combinan una evaluacion de tex-
en el Capftulo 2. tos por interaction humana, con un sistema de gestion
de bases de datos que almacena y categoriza todos y
Herramientas de planificacion de proyectos. Las cada uno de 10s requisitos del sistema que se ccanalizan,,
herramientas de esta categoria se centran en dos Areas a partir de la RFP o especificacion original.
primordiales: estimacion de costes y de esfuerzos del
proyecto de software y planificacion de proyectos. Las
herramientas de estimacion calculan el esfuerzo esti- 10s m&%s de ingenierio de requisitos se trotan
mado, la duraci6n del proyecto y el numero de perso- en el Capitulo 10.
nas recomendado para el proyecto. Las herramientas
de planificaci6n de proyectos hacen posible que el ges-
tor defina todas las tareas del proyecto (la estructura Herramientas de metricas y de gestion. Las mCtri-
de desglose de tareas), que Cree una red de tareas (nor- cas del software mejoran la capacidad del gestor para
malmente empleando una entrada grifica), que repre- controlar y coordinar el proceso de ingenieria del soft-
sente las interdependencias entre tareas y que modele ware y la capacidad del ingeniero para mejorar la cali-
la cantidad de paralelismo que sea posible para ese dad del software que se produce. Las metricas o
proyecto. herramientas de medidas actuales se centran en caracte-
risticas de procesos y productos. Las herramientas orien-
tadas a la gesti6n se sirven de metricas especificas del
proyecto (por ejemplo, LDC/persona-mes, defectos por
punto de funcion) que proporcionan una indicacidn glo-
bal de productividad o de calidad. Las herramientas con
orientation tkcnica determinan las metricas tCcnicas que
Herramientas de analisis de riesgos. La identifi- proporcionan una mejor visi6n de la calidad del disefio
cation de posibles riesgos y el desarrollo de un plan o del codigo.
para mitigar, monitorizar y gestionar esos riesgos tiene
una importancia fundamental en 10s proyectos grandes.
Las herramientas de anAlisis de riesgos hacen posible
que el gestor del proyecto construya una tabla de ries-
gos proporcionando una guia detallada en la identifica- Herramientas de documentacion. Las herramien-
ci6n y analisis de riesgos. tas de producci6n de documentos y de autoedicion pres-
C A P ~ T U L O31 INGENIERIA DEL SOFTWARE ASISTIDA P O R COMPUTADORA
tan su apoyo a casi todos 10s aspectos de la ingenieria

del software, y representan una importante oportunidad Elrepositorio de software se estudim en el topitub 9.
de <<aprovecharniento>> para todos 10s que desarrollan
software. La mayoria de las organizaciones dedicadas
a1 desarrollo de software invierten una cantidad de Herramientas de gestion de configuracion de soft-
tiempo considerable en el desarrollo de documentos, y ware. La gesti6n de configuraci6n de software (GCS) se
en muchos casos el proceso de documentaci6n en si encuentra en el nlicleo de todos 10s entomos CASE. Las
resulta bastante deficiente. Es frecuente que una orga- herrarnientas pueden ofrecer su asistencia en las cinco
nizaci6n de desarrollo de software invierta en la docu- tareas principales de GCS -identificaci6n, control de ver-
mentacion hasta un 20 o un 30 por 100 de su esfuerzo siones, control de cambios, auditoria y contabilidad de
global de desarrollo de software. Por esta razon, las estados-. La base de datos CASE proporciona el meca-
herramientas de documentacion suponen una oportuni- nismo de identificar todos 10s elementos de configuracion
dad importante para mejorar la productividad. y de relacionarlo con otros elementos; el proceso de con-
trol de cambios se puede implementar con ayuda de las
herramientas especializadas; un acceso sencillo a 10s ele-
mentos de configuracion individuales facilita el proceso
Lo documentocionse estudio o lo largo de todo el de auditoria; y las herramientas de comunicaci6n CASE
libro. En SepoWeb se presenton m$ dotas. pueden mejorar enormemente la contabilidad de estados
(ofreciendo informaci6n acerca de 10s cambios a todos
aquellos que necesiten conocerlos).
Herramientas de software de sistema. CASE es
una tecnologia de estaciones de trabajo. Por tanto, el
entorno CASE debera adaptarse a un software de sis- Los octividodes GCS en donde se incluyen
tema en red de alta calidad, al correo electrhico, a 10s la idenlificocibn, conrol de veniones, conrol
tablones de anuncios electr6nicos y a otras posibilida- de combios, ouditorio, y contobilidod de estodos
se estudion en el Copiiulo 9.
des de comunicarse.
Herramientas de analisis y diseno. Las herra-

Consulte 10s Copitulos 27,28 y 29 poro un esiudio mientas de analisis y disefio hacen posible que el inge-
limitodo de estos temos. niero del software Cree modelos del sistema que vaya a
construir. Los modelos contienen una representacion de
10s datos, funcion y comportamiento (en el nivel de anh-
Herramientas de control de calidad. La mayor lisis), asi como caracterizaciones del disefio de datos,
parte de las herramientas CASE que afirman tener de arquitectura, a nivel de componentes e interfaz'. A1
como principal inter& el control de calidad son en rea- efectuar una comprobaci6n de consistencia y validez de
lidad herramientas de mCtricas que hacen una audito- 10s modelos, las herramientas de anhlisis y disefio pro-
ria del c6digo fuente para determinar si se ajusta o no porcionan a1 ingeniero del software un cierto grado de
a ciertos estandares del lenguaje. Otras herramientas vision en lo tocante a la representacion del anhlisis, y
extraen mCtricas tCcnicas (Capitulos 19 y 24) en un le ayudan a eliminar errores antes de que se propaguen
esfuerzo por extrapolar la calidad del software que se a1 disefio, o lo que es peor, a la propia implernentacion.
esta construyendo.
El ondlisis y el d b a o se esiudion en Ins Portes

GCS se presenta en el Copiiulo 8. Tercero y Cuorto de este libro.
Herramientas de gestion de bases de datos. El soft-

ware de gesti6n de bases de datos sirve como funda- Herramientas PROISIM. Las herramientas PRO/SIM
mento para establecer una base de datos CASE (de construcci6n de prototipos y sirnulacion) [NIC90] pro-
(repositorio), que tambiCn se denominara base de datos porcionan a1 ingeniero del software la capacidad de pre-
del proyecto. Dada la importancia de 10s objetos de con- decir el comportamiento de un sistema en tiempo real
figuration, las herramientas de gesti6n de bases de datos antes de llegar a construirlo. Ademas, tambiCn le capaci-
para CASE pueden evolucionar a partir de 10s sistemas tan para desarrollar simulaciones del sistema de tiempo
de gestion de bases de datos relacionales (SGBDR) para real, lo que permitira que el cliente obtenga ideas acerca
transformarse en sistemas de gestion de bases de datos de su funcionamiento, comportamiento y respuesta antes
orientadas a objetos (SGBDOO). de la verdadera implementaci6n.
La herramientas de diseiio y de analisis orientado a objetos pro-

porcionan representaciones analogas.
lo conslmccii de prototiposy la simulaciin WEB se estudia en el Capltulo 29
se estudian brevemente en el Capltulo 10.
Herramientas de integracion y pruebas. En el
Herramientas de desarrollo y diseno de interfaz. Las directorio de herramientas de pruebas de software del
herramientas de desarrollo y diseiio de interfaz son en rea- Software Quality Engineering [SQE95], se definen las
lidad un conjunto de herrarnientas de componentes de pro- categorias de herramientas de pruebas siguientes:
grarnas (clases) tales como mends, botones, estructurasde adquisicidn de datos: herramientas que adquieren
ventanas, iconos, mecanismos de desplazamiento de la 10s datos que se utilizaran durante la prueba;
pantalla, controladores de dispositivos, etc. Sin embargo, nzedida estcitica: herrarnientas que analizan el c6digo
estos conjuntos de herrarnientas se e s t h viendo sustitui- fuente sin ejecutar casos de prueba;
dos por herramientas de construcci6n de prototipos de inter-
faz que permiten una rhpida creaci6n en pantalla de
lo comprobaci6n del software se estudia
interfaces de usuario sofisticadas,que se ajustan a1 esth- en 10s Capitulos 17, 18 y 23 osl como en 10s
dar de interfaz que se haya adoptado para el software. Capitulos 28 y 29.
medida dinbmica: herramientas que analizan el
Los element~sdel diseiio de intetfaz de usuario c6digo fuente durante la ejecuci6n;
se presentan en el Capltulo 15. simulacidn: herramientas que simulan las funciones
del hardware o de otros elementos externos;
gestidn de pruebas: herramientas que prestan su asis-
Herramientas de construccion de prototipos. Se tencia en la planificaci6n, desarrollo y control de las
puede utilizar toda una gama de herramientas de cons- pruebas;
trucci6n de prototipos. Los generadores de pantallas per- herramientas de funcionalidad a-uzada: se trata de
miten a1 ingeniero del software definir rapidamente la herramientas que atraviesan 10s limites de las cate-
disposici6n de la pantalla para aplicaciones interactivas. gorias anteriores.
Otras herramientas de prototipos CASE mas sofisticadas
Deben'a tenerse en cuenta que muchas de las herra-
permiten la creaci6n de un disefio de datos, acompafiado
mientas de prueba poseen caracteristicas que abarcan
por diseiios e informes de la pantalla. Muchas herra-
dos categon'as o mas de las anteriormente mencionadas.
mientas de analisis y diseiio son mas extensas y propor-
cionan opciones de construcci6n de prototipos. Las Herramientas de analisis estAtico. Las herramientas
herramientas PROISIM generan un disefio esquemitico de analisis estritico prestan su asistencia a1 ingeniero del
de c6digo fuente en Ada y C para las aplicaciones de inge- software a efectos de derivar casos prhcticos. En la indus-
nieria (en tiempo real). Por dltimo, una gama amplia de tria se utilizan tres tipos distintos de herramientas estati-
herramientas de cuarta generaci6n poseen tambiCn carac- cas de prueba: herrarnientas de prueba basadas en c6digo;
ten'sticas de construcci6n de prototipos. lenguajes de prueba especializados y herramientas de
prueba basadas en requisitos. Las herramientas de prueba
basadas en cddigo admiten un c6digo fuente (o LDP)
La consl~cci6nde prototipos se estudio como entrada, y llevan a cab0 varios analisis de 10s que
en 10s Capltulos 2 y 11. se obtiene la generaci6n de casos de prueba. Los lengua-
jes de prueba especializados (por ejemplo, ATLAS) hacen
posible que el ingeniero del software escriba especifica-
Herramientas de programacion. La categoria de ciones de prueba detalladas para describir todos 10s casos
herramientas de programaci6n abarca 10s compilado- de prueba y la logistics de su ejecuci6n. Las herramien-
res, editores y depuradores disponibles para apoyar a la tas de prueba basadas en requisitos aislan 10s requisitos
mayon'a de 10s lenguajes de programaci6n convencio- del usuario y sugieren 10s casos de prueba (o clases de
nales. Ademas, en esta categoria tambien residen 10s prueba) que ejercitarh esos requisitos.
entornos de programaci6n orientados a objetos (OO),
10s lenguajes de cuarta generacibn, 10s entornos de pro-
gramaci6n grafica, 10s generadores de aplicaciones y
10s lenguajes de consulta de bases de datos. 10s mlrtodos de comprobarihn de caio negra
se estudian en el Copitulo 17.
Herramientas de desarrollo de Webs. Las activi-
dades asociadas a la ingenieria Web estan apoyadas por Herramientas de analisis dinamico. Las herra-
una variedad de herramientas de desarrollo de WebApps. mientas de analisis dinamico interactdan con el pro-
Entre estas herramientas se incluyen las que prestan grama que se estC ejecutando, prueban la cobertura de
ayuda en la generaci6n de texto, graficos, formularies, rutas, prueban las afirmaciones acerca del valor de varia-
guiones, applets y otros elementos de una pagina Web. bles especificas e instrumentan por otro lado el flujo de
C A P ~ T U L O3 1 I N G E N I E R ~ ADEL S O F T W A R E A S I S T I D A P O R C O M P U T A D O R A
ejecucion del programa. Las herramientas dinamicas

pueden ser intrusivas, o no intrusivas. Las herrarnien- lo pruebo C/S se eshrdio en el Copitulo 20.
tas intrusivas modifican el software que hay que com-
probar mediante la insertion de sondas (instrucciones
adicionales) y que efectuan las actividades menciona- Herramientas de reingenieria. Las herramientas
das anteriormente. Las herrarnientas de prueba no intru- para el software heredado abarca un conjunto de activi-
sivas utilizan un procesador hardware por separado que dades de mantenimiento que actualmente absorben un
funciona en paralelo con el procesador que contiene el porcentaje significativo de todo el esfuerzo relacionado
programa que se estd probando. con el software. La categoria de herramientas de rein-
geniena se puede subdividir en las funciones siguientes:
Herramientas de gestion de pruebas. Las herra-
mientas de gesti6n de pruebas se utilizan para controlar herrarnientas de ingenieria inversa para producil-
y coordinar las pruebas del software por todos y cada uno especificaciones: se toma el c6digo fuente como
de 10s pasos principales de las pruebas. Las herramien- entrada y se generan modelos grdficos de anhlisis y
tas de esta categoria gestionan y coordinan las pruebas disefio estructurados, listas de utilizaciQ y mas infor-
de regresiones, efectuan comparaciones que determinan maci6n sobre el disefio;
las diferencias entre la salida real y la esperada y reali-
zan pruebas por lotes de programas con interfaces hom-
bre-maquina interactivas. Ademas de las funciones Los mitodos de reingenieria se eshrdion
indicadas anteriormente, muchas herramientas de ges- en el Copihrlo 30.
tidn de pruebas sirven tambiCn como controladores de
pruebas genkricos. Un controlador de pruebas lee uno o herramientas de reestructuracidn y ancilisis de
mds casos de prueba de algun archivo de pruebas, aplica cddigo: se analiza la sintaxis del programa, se genera
formato a 10s datos de prueba para que se ajusten a las una grafica de control de flujo y se genera automi-
necesidades del software que se esta probando, e invoca ticamente un programa estructurado; y
entonces a1 software que es precis0 probar.
herramientas de reingenieria para sisternas on-
line: se utilizan para modificar sistemas de bases
Las esirotegios de pruebo se eshrdion
de datos on-line (por ejemplo, para convertir archi-
en el Copitulo 18. vos IDMS o DB2 en un formato de entidades y
relaciones).
Herramientas de pruebas clientelservidor. El Muchas de las herramientas anteriores se ven limi-
entorno CIS exige unas herramientas de pruebas espe- tadas a lenguajes de programacidn especificos (aunque
cializadas que ejerciten la interfaz grafica de usuario abarcan la mayoria de 10s lenguajes principales) y
y 10s requisitos de comunicaciones en red para el cliente requieren un cierto grado de interacci6n con el inge-
y el servidor. niero del software.
Aunque se pueden obtener beneficios individualmen-

te de las herramientas CASE que abarcan actividades tCuiles son 10s beneficios
de ingenieria del software por separado, la verdadera de CASE integradas?
potencia de CASE solamente se puede lograr median-
te la integration. Entre 10s beneficios del CASE inte- Ahora bien, I-CASE tambiCn expone a desafios sig-
grado (I-CASE) se incluyen: (1) una transferencia nificativos. En cada acci6n exige unas representaciones
regular de information (modelos, programas, docu- consecuentes de la informaci6n de la ingenieria del
mentos, datos) entre una herramienta y otra, y entre software; unas interfaces estandarizadas entre las herra-
un paso de ingenieria y el siguiente; (2) una reducci6n mientas, un mecanismo homogCneo para la comuni-
del esfuerzo necesario para efectuar actividades glo- cacidn entre el ingeniero del software y todas sus
bales tales como la gesti6n de configuraci6n de soft- herramientas, y un enfoque efectivo que hara posible
ware, el control de calidad y la producci6n de que I-CASE se desplace a lo largo de distintas plata-
documentos; (3) un aumento del control del proyecto formas de hardware y distintos sistemas operativos. Los
que se logra mediante una mejor planificaci6n, moni- entomos I-CASE generales han comenzado a surgir mds
torizaci6n y comunicaci6n; (4) una mejor coordina- lentamente de lo que inicialmente se esperaba. Sin
ci6n entre 10s miembros del personal que estCn embargo, 10s entomos integrados si que existen, y con
trabajando en grandes proyectos de software. el paso de 10s afios se van haciendo mas poderosos.
permitir un acceso direct0 y no secuencial a cual-

quier herramienta del entorno;
CLAVE establecer un apoyo automatizado para el modelo de
Lo integracion de 10s herrarnientas CASE exige uno base procesos de software que se haya seleccionado, inte-
de datos que contengo 10s representodonesconsecuentes
grando herramientas CASE y elementos de configu-
de la inforrnocion de lo ingenierio del software.
raci6n del software en una estructura estandar de
El tCrmino integraci6n implica tanto combinacidn desglose de trabajo;
como cierre. I-CASE combina toda una gama de herra- permitir que 10s usuarios de cada una de las herra-
mientas e informacion distintos de tal mod0 que hace mientas puedan experimentar con el aspecto e inte-
posible el cierre de la comunicaci6n entre las herra- racci6n de la interfaz hombre-mhquina;
mientas, entre personas y entre procesos de software.
Las herramientas se integran de tal manera que la infor-
maci6n de ingenieria del software estC disponible para 10s temas relacionados con 10s pmcesos se esiudian
todas las herramientas que se necesiten; la utilization en 10s Capitulos 2,4 y 7. Los EG se presenton
se integra de tal mod0 que se proporciona un aspecto y en el Copfhrlo 9.
una interaction comun para todas las herramientas; y
se integra una filosofia de desarrollo que aplica prhcti- dar soporte a la comunicaci6n entre ingenieros del
cas modernas y mCtodos ya probados. software; y
Para definir la integracion en el context0 del proce-
so del software, es necesario establecer un conjunto de recoger mCtricas tanto tCcnicas como de gesti6n que
requisitos para I-CASE [FOR89a]. Un entorno CASE se puedan utilizar para mejorar el proceso y el pro-
integrado deberia: duct~.
proporcionar un mecanismo para compartir la infor- Para alcanzar estos objetivos, cada uno de 10s blo-
macion de la ingenieria del software entre todas las ques de construcci6n de una arquitectura (CASE
herramientas dentro del entorno; -Fig. 3 1. I-) deberh encajar con 10s demas sin nin-
hacer posible que un cambio de un elemento de infor- gun tipo de limitation. Los bloques de construcci6n
macidn se siga hasta 10s demas elementos de infor- fundamentales -arquitectura del entorno, plataforma
macion relacionados; hardware y sistema operativo- deberan ccunirse>>a
proporcionar un control de versiones y una gestion travts de un conjunto de servicios de portabilidad a un
de configuraci6n general para toda la informacion de marco de referencia de integraci6n que alcance 10s
la ingenieria del software; objetivos indicados anteriormente.
Un equipo de ingenieria del software utiliza herra- ra 3 1.3. se muestra un modelo sencillo del marco de
mientas CASE, 10s mCtodos correspondientes y un referencia que representa unicamente 10s componen-
marco de referencia de proceso con objeto de crear tes indicados anteriormente.
un conjunto de informaciones de ingenieria del soft-
ware. El marco de referencia de integracion facilita
la transferencia de informaci6n desde y hacia ese con-
junto de informaciones. Para lograr esto, deberan
existir 10s componentes de arquitectura siguientes: la
creacidn de una base de datos (para almacenar la
informaci6n); la construcci6n de un sistema de ges- Uno listo de todos 10s elernentos de informacion
tion de objetos (para gestionar 10s cambios efectua- de la ingenierio del software puede encontrorse
dos en la informaci6n); la construcci6n de un boio 10s ECs.
mecanismo de control de herramientas (para coordi-
nar la utilizaci6n de herramientas CASE), y una inter- La capa de interfaz del usuario (Figura 3 1.1) incor-
faz de usuario que proporcione una ruta consecuente pora un conjunto de herramientas de interfaz estanda-
entre las acciones efectuadas por el usuario y las rizado, con un protocolo de presentaci6n comun. El kit
herramientas que estan dentro del entorno. La mayo- de herramientas de interfaz contiene software para la
ria de 10s modelos (por ejemplo, [FOR90], [SHA95] gestidn de la interfaz hombre-mhquina, y una bibliote-
del marco de referencia de integracion representan a ca de objetos de visualizaci6n. Ambos proporcionan un
estos componentes como si fueran capas. En la Figu- mecanismo consecuente para la comunicaci6n entre la
CAPfTULO 3 1 INGENlERfA DEL SOFTWARE ASISTIDA P O R C O M P U T A D O R A
interfaz y las herramientas CASE individuales. El pro- multitarea, coordina el flujo de informaci6n desde el
t o c o l ~de presentacidn es el conjunto de lineas gene- repositorio y el sistema de gesti6n de objetos a las
rales que proporciona un mismo aspect0 a todas las herramientas, realiza las funciones de seguridad y audi-
herramientas CASE. Las convenciones del disefio de toria y recoge mktricas acerca de la utilizaci6n de herra-
pantalla, nombres y organizaci6n del menu, iconos, mientas.
nombres de 10s objetos, utilizaci6n del teclado y del
rat6n, y el mecanismo para acceder a las herramientas
se definen todos ellos como parte del protocolo de pre-
sentaci6n.
10srecunas para la integracibnde herramientasCASE
Capa de interfaz de usuario y para 10s Entornos de lntegracionde lngenierio
Kit de herramientas de interfaz
Protocolo de presentacidn
del software se pueden obtener en:
see.cs.flinders.edu.au/sewcb/ti/
I Servicios de gestidn de herramientas 1 La capa de gestidn de objetos (CGO) lleva a cab0
I II I I n
I
- las funciones de gesti6n de configuraci6n que se des-

Herramienta Capa de herramientas
Capa de gesti6n de objetos

- cribian en el Capitulo 8. En esencia, el software de esta
capa de la arquitectura de marco de referencia propor-
ciona el mecanismo para la integraci6n de herramien-
tas. Cada herramienta CASE ccse enchufa>>en la capa
Servicios de integracidn
Servicios de gestidn de configuracion de gesti6n de objetos. A1 funcionar en conjunto con el
repositorio CASE, la CGO proporciona 10s servicios de
integraci6n -un conjunto de m6dulos estindar que aco-
plan las herramientas con el repositori*. Ademis, la
OML proporciona 10s semicios de gesti6n de configu-
raci6n haciendo posible la identificacih de todos 10s
FIGURA 31.3. Modelo de arquitectura para el marco objetos de configuracibn, llevando a cab0 el control de
de referencia de integracion. versiones y proporcionando apoyo para el control de
cambios, auditorias y contabilidad de estados.
La capa de herramientas incorpora un conjunto de La capa de repositorio compartido es la base de datos
servicios de gesti6n de herramientas con las herra- CASE y las funciones de control de acceso que hacen
mientas CASE en si. Los servicios de gestibn de herra- posible que la capa de gesti6n de objetos interactue con
mientas (SGH) controlan el comportamiento de las la base de datos. La integraci6n de datos se logra
herramientas dentro del entorno. Si durante la ejecu- mediante las capas de gesti6n de objetos y de reposito-
ci6n de una o rnis herramientas se emplea la multita- rio compartido que se estudian rnis adelante y con rnis
rea, SGH efectua la sincronizaci6n y comunicaci6n profundidad en este mismo capitulo.
El Diccionario Websterdefine la palabra repositorio como del software) es interactuar con el repositorio empleando
cctodo objeto o persona considerado centro de acumula- herramientas CASE integradas con 61.
ci6n o almacenamiento>>. Durante las primeras fases de la En este libro, se utiliza un determinado numero de
historia del desarrollo del software, el repositorio era en tCrminos distintos para hacer alusi6n a1 lugar de alma-
realidad una persona --el programador que tenia que recor- cenamiento de la informaci6n de la ingenierfa del soft-
dar la ubicaci6n de toda la informaci6n relevante para un ware: base de datos CASE, base de datos del proyecto,
determinado proyecto de software, que tenia que recordar base de datos de entorno de apoyo integrado a proyec-
informaci6n que nunca se habia escrito y que tenia que to ( E m ) ,diccionario de requisitos (una base de datos
reconstruir la informaci6n que se habia perdid*. Triste- limitada) y repositorio. Aunque existen sutiles diferen-
mente, la utilizaci6n de una persona como cccentro de acu- cias entre algunos de estos tkrminos todos ellos hacen
mulaci6n y almacenamiento>> (aunque corresponda con la referencia a1 centro de acumulaci6n y almacenamiento.
definici6n del diccionario) no funciona demasiado bien.
En la actualidad, el repositorio es una cccosa>>-una base
de datos que actua como centro tanto para la acumulaci6n 31.6.1. El papel del repositorio en I-CASE
como para el alrnacenamientode informacidn de ingenie- El repositorio de un entomo I-CASE es el conjunto de
I ria del software--. El papel de la persona (del ingeniero mecanismos y de estructuras de datos que consiguen la
integracion entre datos y herramientas, y entre datos y 31.6.2. Caracteristicas y contenidos

datos. Proporciona las funciones obvias de un sistema Las caracteristicas y contenido del repositorio se entien-
de gestion de bases de datos, pero, ademas, el reposito- den especialmente bien examinindolo desde dos pers-
rio lleva a cab0 o precipita las funciones siguientes pectivas: iQu6 es lo que hay que almacenar en el
[FOR89b]: repositorio, y qu6 sewicios especificos son 10s que pro-
integridad de datos: incluye funciones para validar porciona el repositorio? En general, 10s tipos de cosas
las entradas efectuadas en el repositorio, para asegu- que habra que almacenar en el repositorio incluyen:
rar la consistencia entre objetos relacionados, y para el problema que hay que resolver;
efectuar automaticamente modificaciones ccen cas-
cadan cuando un carnbio efectuado en un objeto exige informacion acerca del dominio del problema;
algun carnbio en otros objetos relacionados con 61; la soluci6n del sistema a medida que va surgiendo;
informacidn compartida: proporciona un mecanismo las reglas e instrucciones relativas a1 proceso de soft-
para compartir informacion entre multiples desarro- ware (metodologia) que se esta siguiendo;
lladores y entre multiples herramientas; gestiona y el plan del proyecto, sus recursos y su historia;
controla el acceso multiusuario a 10s datos, y blo-
informaci6n acerca del context0 organizativo.
quealdesbloquea objetos para que 10s cambios no se
superpongan inadvertidamente; En la Tabla 3 1.1 se ha incluido una lista detallada de
tipos de representaciones, documentos y otros produc-
iCuales son las funciones que tos que se almacenan en el repositorio CASE.
llevan a cabo 10s servicios que Un repositorio CASE robusto proporciona dos cla-
se acoplan con el repositorio CASE? ses distintas de sewicios: (I) 10s mismos tipos de ser-
vicios que puede uno esperar de cualquier sistema de
integracidn datos-herramientas: establece un modelo gestion de bases de datos sofisticados; y (2) sewicios
de datos a1 que pueden acceder todas las herramien- que son especificos del entomo CASE.
tas del entorno I-CASE; controla el acceso a 10s Muchos requisitos del repositorio son iguales a 10s
datos, y lleva a cab0 las funciones de gestion de con- de las aplicaciones tipicas que se construyen tomando
figuration adecuadas; como base un sistema de gesti6n de bases de datos de
integracidn datos-datos: el sistema de gestion de comercial (SGBD). De hecho, muchos de 10s reposito-
bases de datos relaciona 10s objetos de datos de tal rios CASE actuales hacen uso de un SGBD (normal-
manera que se puedan alcanzar las demhs funcio- mente relacional u orientado a objetos) como la
nes; tecnologia de gesti6n de datos basica. Entre las carac-
teristicas de un SGBD que dan soporte a la gesti6n de
imposicidn de la metodologia: el modelo E-R de informaci6n de desarrollo del software se incluyen las
datos almacenado en el repositorio puede implicar siguientes:
un paradigma especifico de ingenieria del software;
como minimo, las relaciones y 10s objetos definen Almacenamiento de datos no redundante. Cada
un conjunto de pasos que se llevara a cab0 para cons- objeto es almacenado solo una vez, aunque es accesi-
truir el contenido del repositorio; ble por todas las herramientas CASE siempre y cuando
estas lo necesiten.
estandarizacidn de documentos: la definition de obje-
tos de la base de datos da lugar directamente a un Acceso de alto nivel. Se implementa un mecanismo
enfoque estandar para la creacion de documentos de com6n de acceso a 10s datos de tal mod0 que no sea pre-
ingenieria del software. ciso duplicar las funciones de gestion de datos en todas
las herramientas CASE.
Para conseguir estas funciones, se define el reposi-
torio en funci6n de un metamodelo. El metamodelo
iCuales son las caracteristicas
determina la forma en que se almacena la informacion
tipicas de 10s SGBD que don
en el repositorio, la forma en que las herramientas pue-
soporte a CASE ?
den acceder a 10s datos y estos datos pueden ser visua-
lizados por 10s ingenieros de software, el grado hasta el
cual se puede mantener la seguridad e integridad de 10s Independencia de datos. Las herramientas CASE y
datos, y la facilidad con que se puede ampliar el mode- las aplicaciones destino se aislan del almacenamiento
lo ya existente para admitir nuevas necesidades fisico para que no se vean afectadas cuando la configu-
[WEL89]. raci6n del hardware se cambie.
El metamodelo es la plantilla en la cual se sit6a la Control de transacciones. El repositorio implementa
informacion de ingenieria del software. Una description bloqueo de registros, admisiones de dos fases, registros
detallada de estos modelos va mas all6 del alcance de este de transacciones y procedimientos de recuperation para
libro. Para mas informacion, el lector interesado podria mantener la integridad de 10s datos cuando existen usua-
consultar [WEL89], [SHA95] y [GRI95]. rios concurrentes.
C A P ~ T U L O3 1 1NGENIERfA DEL SOFTWARE ASlSTlDA P O R COMPUTADORA
lnformacion de la empresa Construccion

Estructura organizativa Codigo fuente; codigo objeto
Analisis del area de negocios lnstrucciones de construccion del sistema
Funciones de negocios lmagenes binarias
Reglas de negocios Dependencias de configuracion
Modelos de procesos (escenarios) lnformacion de cambios
Arquitectura de la informacion
Validacion y verification
Diseiio de aplicaciones Plan de comprobacion; casos de prueba de 10s
Reglas de metodologia datos
Representaciones graficas Guiones de comprobacion de regresion
Diagramas de sistema Resultados de comprobaciones
Estandares de denominacion Analisis estadisticos
Reglas de integridad referenciales Metricas de calidad de software
Estructuras de datos
lnformacion de gestion del proyecto
Definiciones de proceso
Planes de proyecto
Definiciones de clase
Estructura de desglose de tareas
Arboles de menu
Estimaciones; planificaciones
Criterios de rendimiento
Carga de recursos; informe de problemas
Restricciones temporales
Solicitudes de cambios; informes de estado
Definiciones de pantalla
lnformacion de auditoria
Definiciones de informes
Definiciones logicas Documentacion del sistema
Logicas de comportamiento Documentos de requisitos
Algoritmos Disetios internodexternos
Reglas de transformacion Manuales de usuario
TABLA 31.1. Contenido de un repositorio CASE [FOR89B].
Seguridad. El repositorio proporciona mecanismos Almacenamiento de estructuras de datos sofisrica-

para controlar quiCn puede visualizar y modificar la das. El repositorio debe admitir tipos de datos cornple-
informacion contenida en 61. jos tales corno diagramas, documentos y archivos, asi
Consultas e informes de d a m ad hoc. El reposito- como sencillos elementos de datos. Un repositorio tarn-
rio permite acceder directamente a su contenido biCn incluye un modelo de informacion (o metamodelo)
mediante una interfaz de usuario c6moda tal como SQL, que describe la estructura, relaciones y semintica de 10s
o mediante un ccnavegador,, (browser) orientado a for- datos almacenados en 61. El metamodelo deberi poder
mularios, haciendo posible un anilisis definido por el arnpliarse para dar cabida a representaciones nuevas y
usuario que va mis alli de 10s informes estindar pro- a una informacion organizativa unicas. El repositorio
porcionados por el conjunto de herramientas CASE. no solamente almacena rnodelos y descripciones de 10s
Apertura. Los repositorios suelen proporcionar un sistemas en desarrollo, sino que 10s metamodelos aso-
mecanismo de importacion/exportaci6n sencillo que ciados (esto es, una informaci6n adicional que describe
hace posible las cargas o transferencias de informaci6n la informaci6n de ingenieria del software en si, tal como
a1 por mayor. el momento en que se ha creado un componente de
disefio concreto, su estado actual y la lista de compo-
Soporte multiusuario. Un repositorio robusto deberi
nentes de 10s cuales depende).
permitir que multiples desarrolladores trabajen en una
aplicacih a1 mismo tiempo. Deberi gestionar el acceso iCuiles son las taratteristitas
concurrente a la base de datos mediante multiples espetiales mostradas en el
herramientas y por parte de multiples usuarios, con repositorio CASE?
arbitraje de accesos y con bloqueos en el nivel de archi-
vos o registros. Para 10s entornos basados en redes, el Imposicibn de una integridad. El modelo de infor-
soporte multiusuario implica tambiCn que el reposito- macion del repositorio contiene tambiCn reglas, o poli-
rio se podri comunicar mediante interfaz con proto- ticas, que describen reglas de negocios validas y otras
colos (agentes de solicitud de objetos) y servicios restricciones y requisitos acerca de la informaci6n que
comunes de red. se inserta en el repositorio (directamente o a travis de
El entomo CASE tambikn efectua demandas espe- una herramienta CASE). Es posible emplear un semi-
ciales con respecto a1 repositorio que van mis all6 de cio llamado disparador para activar las reglas asocia-
lo que esth disponible directarnente en un SGBD comer- das a un objeto siempre que este sea rnodificado, lo cual
cial. Entre las caracteristicas especiales de 10s reposi- hace posible verificar la validez de 10s modelos de diseiio
torios CASE se incluyen las siguientes: en tiempo real.
de datos relacionados, definiciones de pantallas y m6du- de una serie de configuraciones que representartin hitos
10s de c6digos tambiCn requieren modificaci6n y pue- especificos del proyecto o de versiones de producci6n.
dan llamar la atenci6n del desarrollador 10s componentes La gesti6n de versiones proporciona las versiones nece-
afectados. sarias, y la gesti6n de enlaces hace seguimiento de las
Seguimiento de requisitos. Esta funci6n especial interdependencias.
depende de la gesti6n de enlaces y proporciona la capa- Seguimiento de auditoria. El seguimiento de auditoria
cidad de hacer seguimiento dz 10s componentes de establece informaci6n extra acerca de cuhndo, por quC, y
disefio y de 10s productos derivados que proceden de por quiCn son efectuados 10s cambios. La informaci6n
una especificaci6n de requisitos especifica (seguimiento acerca de las fuentes de las modificaciones se pueden intro-
progresivo). Ademis, proporciona la capacidad de iden- duck en forma de atributos de objetos especificos del repo-
tificar cuiles son 10s requisitos que generaron cualquier sitorio. Un mecanismo disparador del repositorio resultarh
product0 derivado (seguimiento regresivo). litil para solicitar a1 desarrollador o a la herramienta que
Gestibn de conjiguracibn. Una funcion de gesti6n de estC utilizando que inicie la introducci6n de informacion
configuracion que trabaja muy cerca de las funciones de auditoria (tal como la raz6n del cambio) siempre que
de versiones y gesti6n de enlaces para hacer seguimiento se modifique un elemento de disefio.
Las herramientas de ingenieria del software asistida por por parte de fabricantes que trabajan a la vez, o bien se
computadora abarcan todas las actividades del proceso puede lograr mediante un software de gesti6n que se
del software y tambiCn aquellas actividades generales proporcione como parte del repositorio.
que se aplican a lo largo de todo el proceso. CASE com- La integraci6n entre hombre y computadora se logra
bina un conjunto de bloques de construcci6n que mediante esthndares de interfaz que se estin volviendo
comienzan en el nivel del hardware y del software de cada vez mas comunes a lo largo y ancho de toda la
sistema operativo y finalizan en las herramientas indi- industria. Para facilitar la integration de 10s usuarios
viduales. con las herramientas, de las herramientas entre si, de las
En este capitulo se ha tenido en consideration una herramientas con 10s datos y de 10s datos con otros datos
taxonomia de herramientas CASE. Las categonas abar- se disefia una arquitectura de integraci6n.
can tanto las actividades de gesti6n como las tCcnicas, Se ha aludido a1 repositorio CASE con el nombre de
e incluyen la mayor parte de las ireas de aplicaci6n del <<busde software>>. La informacion pasa por 61, y va cir-
software. Todas las categorias de herramientas se han culando de herramienta en herramienta a medida que
considerado ccsoluciones puntuales>>. progresa el proceso de software. Pero el repositorio es
El entorno I-CASE combina mecanismos de inte- mucho mis que un <<bus>>. TambiCn se trata de un lugar
graci6n para datos, herramientas e interacci6n hombre- de almacenamiento que combina sofisticados mecanis-
computadora. La integraci6n de datos se puede conseguir mos para integrar herramientas CASE mejorando con-
mediante el intercambio direct0 de informaci6n, median- siguientemente el proceso mediante el cual se desarrolla
te estructuras de archivos comunes, mediante datos comel software. El repositorio es una base de datos relacio-
partidos o interoperabilidad, o a travCs de la utilizaci6n nal u orientada a objetos que es <<elcentro de acumula-
de un repositorio I-CASE completo. La integraci6n de ci6n y almacenamiento>> de la informacion de ingenieria
herramientas se puede disefiar de forma personalizada del software.
[FOR89a] Forte, G., <<InSearch of the Integrated Environ- [QED89] CASE: The Potential and the Pitfalls, QED Infor-
ment)), CASE Outlook, MarzoIAbril de 1989, pp. 5-12. mation Sciences, Inc., Wellsley, MA, 1989.
[FOR89b] Forte, G., <<RallyRound the Repository)), CASE [SHA95] Sharon, D., y R. Bell, <<Toolsthat Bind: Creating
Outlook, Diciembre de 1989, pp. 5-27. Integrated Environments)),IEEE Software, Marzo de 1995,
[FOR901 Forte, G., <(IntegratedCASE: A Definition)),Proc. pp. 76-85.
3'* Annual TEAMWORKERS Inti. User's Group Confe-
rence, Cadre Technologies, Providence, IR, Marzo de 1990. [SQE95] Testing Tools Reference Guide, Software Quality
Engineering, Jacksonville, FL, 1995.
[GRI95] Griffen, J., <<Repositories:Data Dictionary Descen-
dant Can Extend Legacy Code Investment),, Application [WEL89] Welke, R.J. c<MetaSystems on Meta Models)),
Development Trends, Abril de 1995, pp. 65-71. CASE Outlook, Diciembre de 1989, pp. 35-45.
lNGENlERfA DEL SOFTWARE. UN ENFOQUE P R ~ C T ~ C O
31.1. Haga una lista de todas las herramientas de desarrollo 31.6. /,Existen situaciones en las cuales las herramientas de
de software que utilice. Organicelas de acuerdo con la taxo- comprobacion dinamicas sean ccla unica forma posible~?De
nomia presentada en este capitulo. ser asi, jcuiles son?
31.2. Empleando las ideas introducidas en 10s Capitulos 14 y 31.7. Describa otras actividades humanas en las cuales la inte-
16, ic6m0 Cree usted que debenan de construirse 10s sewicios graci6n de un conjunto de herramientas haya proporcionado
de portabilidad? un mayor beneficio que la utilizacih de cada una de esas herra-
31.3. Construye un prototipo en papel para una herramienta mientas de forma individual. No utilice ejemplos de compu-
de gesti6n de proyectos que abarque las categonas indicadas tacion.
en la Seccion 31.3. Utilice la Segunda Parte de este libro para 31.8. Describa lo que quiere decir la integration entre herra-
obtener informacion adicional. mientas y datos con sus propias palabras.
31.4. Lleve a cab0 una investigacion acerca de 10s sistema de 31.9. En diferentes lugares de este capitulo se utilizan 10s tCr-
gestion de bases de datos orientados a objetos. Estudie por quC minos metamodelos y metadatos. Describa lo que significan
un SGBDOO sena ideal para herramientas GCS. estos terminos empleando sus propias palabras.
31.5. Recoja la informaci6n de productos de a1 menos tres 31.10.iSe le ocurre algun elemento de configuraci6n adicio-
herramientas CASE en una categona especificada por su pro- nal que pudiera incluirse entre 10s elementos del repositorio
fesor. Desarrolle una matriz que compare las caractensticas. mostrados en la Tabla 3 1. l ? Haga una lista.
En 10s aiios ochenta y principios de 10s noventa se publica- entornos de desarrollo de software. Muller y sus colaborado-
ron varios libros sobre CASE en un esfuerzo de sacar provecho res (ComputerAided Sojhare Engineering, Kluwer Academic
del alto grado de inter& de la industria en ese momento. Entre Publishers, 1996) han editado una coleccion de descripciones
las primeras ofertas que todavia disfrutan de valor se encuentran: de investigacion CASE a mediados de 10s noventa. La mejo-
Bergin, T. et al., Computer-Aided Software Engineering: res fuentes de informacion actual sobre herramientas CASE se
Issues and Trends for the 1990s and Beyond, Idea Group encuentran en Internet, en publicaciones ticnicas periaicas y
Publishing, 1993. en boletines informativos de industria.
Braithwaite, K.S., Application Development Using CASE El estfindar 1209 IEEE (Evaluation and Selection of CASE
Tools, Academic Press, 1990. Tools) presenta un conjunto de lineas generales para evaluar
Brown, A. W., D.J. Carney y E.J. Morris, Principles of las herramientas CASE para 10s ccprocesos de gestion de pro-
CASE Tool Integration, Oxford University Press, 1994. yectos, procesos de predesarrollo, procesos de desarrollo, pro-
Clegg, D., y R. Barker, CASE Method Fast-Track: A RAD cesos de postdesarrollo y procesos integralew. Un informe
Approach, Addison Wesley, 1994. detallado de Wallnau y Feiler (Tool Integration and Envi-
Lewis, T.G., Computer-Aided Software Engineering, Van ronment Architectures, Software Engineering Institute,
Nostrand-Reinhold, 1990. CMU/SEI-91-TR-11, Mayo de 1991), aunque este fechado,
Mylls, R., Information Engineering; CASE Practices and sigue siendo uno de 10s mejores tratamientos sobre entomos
Techniques, Wiley, 1993. CASE ficilmente disponibles.
Una amplia variedad de fuentes de informaci6n sobre
En la antologia de Chifofsky (Computer-Aided Software CASE esta disponible en Internet. Una amplia lista actuali-
Engineering, IEEE Computer Society, 2 . W . , 1992) se encuen- zada de referencias a sitios (pfiginas) web se puede obtener
tra una colecci6n util de 10s primeros trabajos sobre CASE y en http:/www.pressman5.com.
Pulabras c l a v e
rn
imbiio del ccanbio.. .574
comentaria final ....578
imporfancia
E
PERSPECTIVAS FUTURAS
N 10s 3 1 capitulos anteriores, se ha ido explorando un proceso de ingenieria del softwa-

re. Se han presentado procedimientos de gesti6n y mitodos ticnicos, principios bhsicos
y tCcnicas especializadas, actividades orientadas a personas y tareas adecuadas para su
automatizaci611, notaci6n de papel y llipiz y herramientas CASE. Se ha afirmado que la medi-
del software.. .....574 da, la disciplina y un especial inter& por la calidad darlin lugar a un software que va a satisfa-
lecnologia ....... . .577 cer las necesidades del usuario, a un software fiable, a un software mantenible y a un software
infotmacih ........576
ntejor. Y,sin embargo, nunca se ha prometido que la ingenieria del software fuera la panacea.
perml...........574 A medida que vamos avanzando hacia el comienzo de un nuevo siglo, la tecnologia de soft-
proceso.. ...........575
ware y de sistemas siguen siendo un desafio para todo profesional del software y para toda com-
pafiia que construya sistemas basados en computadoras. Aunque esto se escribi6 hace mlis de
una dCcada, Max Hopper [HOP901 describe el estado actual de 10s acontecimientos:
Dado que 10s cambios de la tecnologia de la i n f o m a c i h cada vez se producen m6s rlipidamente y son
implacables, y dado que las consecuencias de quedarse atr6s son irreversibles, las compaiiias tienen que
dominar esta tecnologia o morir. Hay que pensar que se trata del molino de la tecnologia. Las cornpafiias
tendran que correr ceda vez mis deprise para estar a la altura.
Los cambios de la tecnologia de la ingenieria del software son, en efecto, ccrhpidos e impla-
cables,, per0 a1 mismo tiempo el progreso suele ser bastante lento. Pero una vez que se toma
la decisi6n de adaptar un mitodo nuevo (o una herramienta nueva), la decisi6n de llevar a cab0
la formaci6n necesaria para comprender su aplicaci61-1,y la decisi6n de introducir la tecnologia
en la cultura de desarrollo del software, ya ha surgido algo nuevo (e incluso mejor) y comien-
za de nuevo el proceso.
~ Q ues?
i El futuro nunca e s i&cild e pre- Lpor qu6 10s grandes empresas multi- &Cude s e l products obtenido?
decir: los entendidos y expertos d e la nacionales contratan a otras empresas Una visibn del t6rmino futuro q u e
industria nose resisten. El iuturo esta- asesoms y a grandes pensadores para pueda o no ser correcta.
ba plagado d e carcasas de tecnologi- prepaxar 10s pron6sticos?, jpor qu6 un ~Cdnropuedo ester segaro de que
as nuevas y exciiantes que realmente gran porcentaje de lectores est6n pen- lo he hccho correctemente?
nunca llegaron a ser eso (a pesar del dientes de los hor6scopos? Queremos Predecir el futuro e s un arte, no una
b o m b que tuvieron), y que adquirie- saber lo que v a a ocurrir para estar ciencia. De hecho, e s bastante extra-
ron forma con tecnologias m6s rnoder- preprados. iio cuando s e ha hecho una predic-
nas que de alguna manera rnodificaron acutiles son 10s pesos? No hay una cidn seria, q u e Bsta s e a absolu-
su direccidn y exlensidn. Por lo tanto f6rmula para predecir e l futuro. Lo tamente verdadera o inequfvoca-
no pretendemos predecir el futuro sino hemos intentado recogiendo datos y mente err6nea (con l a e x c e p c i h .
que estudiaremos algunos temas que organiz6ndolos con el fin Be propor- afortunadamente, d e l a s prediccio-
hay que tener en cuenta para entender cionar una informacibn 6111; exami- nes sobre el fin del mundo). Se bus-
10s wmbios futuros d e la ingenierla del nando Ius asociaciones sutiles para can tendencias y se intenta extra-
software y del mismo software. extraer el conocimiento y. u purtir d e polarlas a1 futuro. Solarnente s e pue-
&Qui&n la hece? Todos. h t e , sugerir posibles uparlciones d e evaluar l a correccibn d e e s t a
~ P o quti
r es importante?~ P oqu6 r 10s que predecirbn c6mo ser6 todo e n el extrapolacibn u medida que pasa el
reyes antiguos contrataban adivinos?, futuro. tiempo.
En este capitulo se examinan las tendencias futuras. Nuestro intento noes explorar todas las
Areas de investigaci6n que resulten prometedoras. Tampoco lo es mirar en una <<bolade cris-
t a b y pronosticar el futuro, mds bien se intentar%explorar el Ambito del carnbio y la forma en
que el carnbio en si va a afectar a1 proceso del software en 10s afios venideros.
La importancia del software de computadora se puede de una corporacih. El software es crucial para casi todos 10s
enunciar de muchas formas. En el Capitulo 1, el soft- aspectos del negocio. Pero de muchas maneras, el software es
ware se caracterizaba como diferenciador. La funcion tambiin una tecnologia oculta. Encontramos el software (fre-
cuentemente, sin darnos cuenta) cuando nos desplazamos has-
proporcionada por el software es lo que diferencia a 10s ta nuestro trabajo, cuando efectuamos cualquier compra, cuando
productos, sistemas y servicios, y proporciona una ven- nos detenemos en el banco, cuando hacemos una llamada tele-
taja competitiva en el mercado. Sin embargo, el soft- fonica, cuando visitamos a1 mtdico o cuando realizamos cual-
ware es mas que un diferenciador. Los programas, quiera de 10s cientos de actividades diarias que reflejan la vida
documentos y datos que constituyen el software ayu- modema.
dan a generar la mercancia mas importante que pueda El software esti en todas partes y, sin embargo, hay muchas
adquirir cualquier individuo, negocio o gobiemo -la personas en puestos de responsabilidad que tienen pma o nin-
guna comprension de lo que realmente es, como se conshuye,
informaci6n-. Pressman y Herron [PRE91] describen ode lo que significa para las instituciones que lo controlan (y a
el software de la forma siguiente: las que controla). Y, lo que es mas importante,tienen muy poca
El software de computadora es una de las pocas tecnologi- idea de 10s peligros y oportunidades que este software ofrece.
as clave que tendrh un impacto significativo en 10s aiios 90. La omnipresencia del software nos lleva a una con-
Se trata de un mecanismo para automatizar negocios, indus- clusion sencilla: siempre que una tecnologia tiene un
trias y gobiemos, un medio para transferir nuevas tecnologias, impacto amplio -un impacto que puede salvar vidas o
un mitodo para adquirir experiencia valiosa que otras perso-
nas puedan utilizar, un medio para diferenciar 10s productos de ponerlas en peligro, construir negocios o destruirlos,
una compaiiia de 10s productos de 10s de sus competidores, y informar a 10s jefes de gobiemo o confundirlos-, es
una ventana que permite examinar el conmimiento colectivo precis0 ccmanejarla con cuidado>>.
Los cambios en la informitica durante 10s liltimos 50 Es posible que la influencia de las ciencias no expe-
aiios han sido controlados por 10s avances en las cccien- rimentales ayude a moldear la direction de la investi-
cias experimentales duras-fisica, quimica, ciencia de gacion informitica en las ciencias experimentales. Por
materiales e ingenieria-. Durante las proximas dCca- ejemplo, el diseiio del las cccomputadoras futuraw pue-
das, 10s avances revolucionarios en la informitica serfin de que sea dirigido mas por un entendimiento de la psi-
dirigidos por las ccciencias no experimentales waves>> cologia del cerebro que por el entendimiento de la
-psicologia humana, biologia, neurofisiologia, socio- microelectronica convencional.
logia, filosofia y otras-. El period0 de gestation de las Los cambios que afectarhn a la ingenieria del soft-
tecnologias informiticas que se puede derivar de estas ware durante la proxima dCcada se verin influenciados
disciplinas es muy dificil de predecir. por cuatro fuentes simultheas: (1) las personas que rea-
lizan el trabajo; (2) el proceso que aplican; (3) la natu-
raleza de la information, y (4) la tecnologia informitica
subyacente. En las secciones siguientes, cada uno de
estos componentes -personas, proceso, informaci61-1y
tecnologia- se estudiarh detalladamente.
El software necesario para 10s sistemas de alta tecnologia ware, es posible que la productividad global del grupo
cada vez son mhs dificiles a medida que van pasando 10s sufra. Un mCtodo para resolver este problema es crear
aiios y el tarnaiio de 10s programas resultantes incremen- un n6mero de equipos de ingenieria del software, por
ta de manera proportional. El crecirniento rhpido del tama- el que se compartimentalicen las personas en grupos de
iio del programa ccpromediou nos presentarh unos cuantos trabajo individuales. Sin embargo, a medida que el
problemas si no fuera por el simple hecho de que: a medi- ndmero de equipos de ingenieria del software aumen-
da que el programa aumenta, el nlimero de personas que ta, la comunicacion entre ellos es tan dificil y larga como
deben trabajar en 61 tambiCn aumenta. la comunicaci6n entre individuos. Es alin peor, la comu-
La experiencia indica que a medida que aumenta el nicacidn (entre individuos o equipos) -es decir, es
nlimero de personas de un equipo de proyecto de soft- demasiado tiempo el que se pasa transfiriendo poco con-
CAPfTULO 32 PERSPECTIVAS FUTURAS
tenido de informaci6n, y toda esta informaci6n impor- (o en continentes diferentes) se ccencuentren,, regular-
tante suele ccperderse entre las grietas-. mente. Pero el video tambiCn proporciona otra ventaja:
Si la comunidad de ingenieria del software va a tra- se puede utilizar con10 dep6sito para conocimiento sobre
tar el dilema de la comunicaci6n de manera eficaz, el el software y para 10s reciCn llegados a un proyecto.
futuro de 10s ingenieros deberh experimentar cambios La evoluci6n de 10s agentes inteligentes tambiCn
radicales en la forma en que 10s individuos y 10s equi- cambiarh 10s patrones de trabajo de un ingeniero del
pos se comunican entre si. El correo electr6nic0, 10s software ampliando dramhticamente las herramientas
tablones de anuncios y 10s sistemas de videoconferen- del software. Los agentes inteligentes mejorarh la habi-
cia son 10s lugares comunes como mecanismos de cone- lidad de 10s ingenieros mediante la comprobaci6n de
xi6n entre muchas personas de una red de informaci6n. 10s productos del trabajo utilizando el conocimiento '
La importancia de estas herramientas en el context0 del especifico del dominio, realizando tareas administrati-
trabajo de la ingenieria del software no se puede sobre- vas, llevando a cab0 una investigaci6n dirigida y coor-
valorar. Con un sistema de correo electr6nico o de tabl6n dinando la comunicaci6n entre personas.
de anuncios eficaz, el problema que se encuentra un Finalmente, la adquisici6n de conocimiento esth cam-
ingeniero del software en la ciudad de Nueva York, se biando profundamente. En Internet, un ingeniero del soft-
puede resolver con la ayuda de un compaiiero en Tokio. ware puede subscribirse a un grupo de noticias centrado
En realidad, 10s tablones de anuncios y 10s grupos de en Areas de tecnologia de inmediata preocupaci6n. Una
noticias especializados se convierten en 10s dep6sitos pregunta enviada a un grupo de noticias provoca res-
de conocimiento que permiten recoger un conocimien- puestas de otras partes interesadas desde cualquier lugar
to colectivo de un grupo grande de tkcnicos para resol- del globo. La World Wide Web proporciona a1 ingenie-
ver un problema tCcnico o un asunto de gesti6n. ro del software la biblioteca mhs grande del mundo de
trabajos e informes de investigaci61-1,manuales, comen-
tarios y referencias de la ingenieria del software'.
Si la historia pasada se puede considerar un indicio,
es justo decir que las mismas personas no van a cam-
biar. Sin embargo, las formas en que se comunican, el
entomo en el que trabajan, la forma en que adquieren
el conocimiento, 10s mCtodos y herrarnientas que utili-
zan, la disciplina que aplican, y por tanto, la cultura
El video personaliza la comunicaci6n. Y lo mejor es general del desarrollo del software si cambiarh signi-
que hace posible que compaiieros en lugares diferentes ficativa y profundamente.
. .
32.4.EL <( NUEVO w P R Q C ~ O F T W
,. . ~
Es razonable caracterizar las dos primeras dCcadas de del marco de tiempo asignado. Los modelos evolutivos
la prhctica de ingenieria del software como la era del hacen hincapiC en la necesidad de productos de trabajo
ccpensamiento lineal),. Impulsado por el modelo de ciclo incrementales,anhlisis de riesgos, planificaci6n y revisi6n
vital clhsico, la ingenieria del software se ha enfocado de planes, y realimentaci6n que provenga del cliente.
como una actividad en la cud se podian aplicar una serie
de pasos secuenciales en un esfuerzo por resolver pro-
blemas complejos. Sin embargo, 10s enfoques lineales
del desarrollo del software van en contra de la forma en
que se construyen realmente la mayoria de 10s sistemas.
En realidad, 10s sistemas complejos evolucionan de for-
ma iterativa, e incluso incremental. Por esta raz6n, un
gran segment0 de la comunidad de la ingenieria del soft- ~ Q u Cactividades deberhn de poblar el proceso evo-
ware se esth desplazando hacia modelos evolutivos para lutivo? A lo largo de la dCcada pasada, el Modelo de
el desarrollo del software. madurez de capacidad desarrollado por el Software
Los modelos de proceso evolutivos reconocen que la Engineering Institute (SEI) [PAU93] ha tenido un irnpac-
incertidumbredomina la mayoria de 10s proyectos; que las to apreciable sobre 10s esfuerzos por mejorar las prhc-
lineas temporales suelen ser imposibles y cortas; y que la ticas de ingenieria del software. El MMC ha dado lugar
iteraci6n proporciona la habilidad de dar una soluci6n par- a muchos debates (por ejemplo, [BOL91] y [GIL96]),
cial, aunque un product0 completo no es posible dentro y sin embargo proporciona una buena indicaci6n de 10s
' El sitio Web SEPA puede proporcionar enlaces electronicos con las
materias mas importantes que se presentan en este libro.
atributos que deben existir cuando se pone en practica El crecimiento rfipido de las aplicaciones basadas en
una buena ingenieria del software. Web (WebApps) esta cambiando tanto en el proceso de
Las tecnologias de objetos, junto con la ingenieria del la ingenieria del software como en sus participantes. De
software (Capitulo 27) son un brote de la tendencia hacia nuevo, nos encontramos con un paradigma incrernen-
10s modelos de proceso evolutivos. Ambos tendran un tal y evolutivo. Pero en el caso de las WebApps, la inme-
irnpacto profundo sobre la productividad de desarrollo del diatez, seguridad y estCtica se estan convirtiendo en las
software y sobre la calidad del producto. La reutilizacion preocupaciones dominantes. Un equipo de ingenieria
de componentes proporciona beneficios inmediatos y con- de Web mezcla tCcnicos con especialistas de contenido
vincentes. Cuando la reutilizaci6n se une a las herramientas (por ejemplo, artistas, musicos, videografos) para cons-
CASE para 10s prototipos de una aplicacion, 10s incre- truir una fuente de informaci6n para una comunidad de
mentos del programa se pueden construir mucho m b ripi- usuarios grande e irnpredecible. El software que ha sur-
damente que mediante la utilizacih de enfoques gido del trabajo de la ingenieria de Web ya ha dado como
convencionales. La construcci6n de prototipos arrastran resultado un carnbio radical tanto econ6mico como cul-
a1 cliente a1 proceso. Por tanto es probable que clientes y tural. Aunque 10s conceptos y principios bfisicos trata-
usuarios se impliquen mis en el desarrollo del software. dos en este libro son invariables, el proceso de ingenieria
Esto, a su vez, puede llevar a una satisfacci6n mayor del del software debera adaptarse para llegar a acoplarse a
usuario final y a una calidad mejor del software global. la Web.
A lo largo de las dos ultimas dCcadas, se ha producido

una sutil transici6n en la terminologia que se utiliza para
describir el trabajo de desarrollo de software realizado
para la comunidad de negocios. Hace treinta aiios, el datos: lnformacion:
tkrmino procesamiento de datos era la frase operativa No hay asociatividad Asociatividad en un
solo contexto
para describir la utilizaci6n de computadoras en un con-
texto de negocio. En la actualidad, el proceso de datos
ha dado lugar a otra frase -tecnologia de la informa-
cidn- que significa lo mismo pero presenta un sutil
carnbio de nuestro centro de atenci6n. La irnportancia
ya no estfi meramente en procesar grandes cantidades
Conocimiento: Sabiduria:
de datos, sino rnhs bien en extraer una informaci6n sig- Asociatividad Creacion de principios
nificativa a partir de estos datos. Evidentemente, Cste entre contextos generalizados basandose
ha sido siempre el objetivo, pero el carnbio de la ter- m~iltiples en el conocimiento
minologia refleja un carnbio bastante mas importante ~rocedentede distintas fuentes
en la filosofia de la gesti6n.
Cuando en la actualidad se describen las aplicacio- FIGURA 32.1. Un espectro de ccinformacion)).
nes de software, las palabras datos e informacidn apa-
recen en numerosas ocasiones. La palabra conocimiento cuatro puntos de vista de la ccinformaci6nu se han repre-
se encuentra en algunas aplicaciones de inteligencia arti- sentado esquemhticarnente en la Figura 32.1.
ficial, pero su utilizaci6n es relativamente escasa. Casi Hasta la fecha, la gran mayoria del software que se
nadie describe la sabiduria en el contexto de las aplica- ha construido ha tenido como misi6n procesar datos o
ciones del software para computadoras. informaci6n. Los ingenieros de software del siglo vein-
Los datos son informaci6n pura -una colecci6n de tiuno seguirfin estando reocupados por sistemas que
hechos que es precis0 procesar para que Sean significa- procesen conocimiento? El conocimiento es bidimen-
tivos-. La informaci6n se deriva asociando 10s hechos sional. La informaci6n recogida acerca de una gama
en el sen0 de un contexto dado. El conocimiento aso- amplia de temas relacionados y no relacionados se agru-
cia la informaci6n obtenida en un contexto con otra pan para formar un cuerpo de hechos a1 que se deno-
informacih obtenida en un contexto distinto. Por ulti- mina conocimiento. La clave es nuestra capacidad para
mo, la sabiduria se produce cuando se derivan unos prin- asociar informaci6n de una gama de fuentes distintas
cipios generalizados de conocimientos dispares. Estos que puedan no poseer conexiones evidentes entre si y
El crecimiento rapido de las tecnologias de mineria de datos (data

mining) y de almacenes de datos (datawarehousing) reflejan este
rapido crecimiento.
C A P ~ T U L O32 PERSPECTIVAS FUTURAS
combinarlas de mod0 que nos proporcione algun bene- durante la pr6xima dkcada, el numero de alumnos que
ficio definido. cursarhn estudios primarios y secundarios, o la pre-
si6n habida sobre 10s politicos para reducir 10s impues-
tos y limitar por tanto 10s aumentos de sueldo para 10s
profesores.
Todos estos elementos de informaci6n se pueden
combinar para formular una representacidn del conoci-
miento -existirh una presidn significativa sobre el sis-
tema de educaci6n de 10s Estados Unidos a principios
del siglo veintiuno y esta presion proseguirh durante
Para ilustrar la progresi6n desde 10s datos a1 cono- rnhs de una dkcada-. Mediante este conocimiento,pue-
cimiento, consideraremos 10s datos del censo que indi- de aparecer la oportunidad de un negocio. Quizh exis-
can que el n6mero de nacimientos en 10s Estados tan oportunidades significativaspara desarrollar nuevos
Unidos en 1996 fue de 4,9 millones. Este numero modelos de aprendizaje que sean rnhs efectivas y menos
representa un valor de datos. A1 relacionar este dato costosas que 10s enfoques actuales.
con 10s nacimientos de 10s cuarenta afios anteriores se El futuro del software conduce a sistemas que pro-
puede extraer un elemento de informacion util: aque- cesan el conocimiento. Se ha estado procesando datos
llas personas que tuvieron muchos hijos en 10s afios durante cincuenta aiios y extrayendo informaci6n duran-
50 y a principios de 10s 60, esthn efectuando un ulti- te casi tres dkcadas. Uno de 10s desafios rnhs significa-
mo esfuerzo por tener niiios antes de llegar a1 final de tivos a 10s que se enfrenta la comunidad de la ingenieria
sus afios fkrtiles. Esta informaci6n se puede conectar del software consiste en construir sistemas que den el
entonces con otros elementos de informaci6n aparen- siguiente paso en el espectro: sistemas que extraigan el
temente no relacionados, por ejemplo, el n6mero actual conocimiento de 10s datos y de la informaci6n para que
de profesores de escuelas primarias que se retirarhn sea prhctica y beneficiosa.
Las personas que construyen y utilizan software, el pro- les) pueden dar lugar a cambios radicales en la clase
ceso de ingenieria del software que se aplica, y la infor- de software que se puede construir y tambikn a cam-
maci6n que se produce se ven afectados todos ellos por bios fundamentales en nuestro enfoque de la ingenie-
10s avances en la tecnologia del hardware y software. ria del software. Dado que estos enfoques no tradicio-
Hist61icamente, el hardware ha servido como impulsor nales siguen estando en el primer segment0 del ciclo
de la tecnologia de la computaci6n. Una nueva tecno- de quince afios, resulta dificil predecir la forma en que
logia de hardware proporciona un potencial. Entonces el mundo del software se modificarh para adaptarse a
10s constructores de software reaccionan frente a las ellas.
solicitudes de 10s clientes en un intento de aprovechar Las tendencias futuras de la ingenieria del softwa-
ese potencial. re se verhn impulsadas por las tecnologias de softwa-
Las tendencias futuras de la tecnologia del hardware re. La reutilizaci6n y la ingenieria del software basada
tienen probabilidades de progresar en dos rutas parale- en componentes (tecnologias que todavia no esthn
las. En una de las rutas, las tecnologias de hardware maduras) ofrecen la mejor oportunidad en cuanto a
seguirh evolucionando rhpidamente. Mediante la mayor mejoras de gran magnitud en la calidad de 10s siste-
capacidad que proporcionan las tecnologias de hard- mas y se encuentran en el momento de comerciali-
ware tradicionales, las demandas efectuadas a 10s inge- zarse. De hecho, a medida que pasa el tiempo, el
nieros de software seguirhn creciendo. negocio del software puede empezar a tener un aspec-
to muy parecido a1 que tiene el negocio del hardwa-
re en la actualidad. Quizh existan fabricantes que
construyan dispositivos diferentes (componentes de
software reutilizables), otros fabricantes que cons-
truyan componentes de sistemas (por ejemplo, un con-
junto de herramientas para la interacci6n hombre-
. Pero 10s cambios verdaderos de la tecnologia de mhquina) e integradores de sistemas que proporcio-
hardware se pueden producir en otra direcci6n. El nen soluciones para el usuario final.
desarrollo de arquitecturas de hardware no tradicio- La ingenieria del software va a cambiar -de eso
nales (por ejemplo, mfiquinas masivamente paralelas, podemos estar seguros-. Pero independientemente de
procesadores 6pticos y mhquinas de redes neurona- lo radicales que sean 10s cambios, podemos estar segu-
INGENlERfA DEL SOFTWARE. U N E N F O Q U E PRACTICO
ros de que la calidad nunca perdera su importancia, y probacion competente siempre tendran su lugar en el
de que un analisis y disefio efectivos junto con una com- desarrollo de sistemas basados en computadoras.
Ya han pasado 20 aios desde que se escribio la prime- 10s cuales parecen estar preparados a repetir 10s errores
ra edici6n de este libro. Y todavia me acuerdo de cuan- del pasado.
do era un joven profesor sentado en mi mesa y Para facilitar la transicion necesitamos muchas cosas
escribiendo (a mano) el manuscrito de un libro sobre un -un proceso de software adaptable y sensible, mCtodos
tema que no preocupaba a muchas personas y que aun mas eficaces, herramientas mas potentes y una acepta-
menos entendian realmente. Recuerdo la cartas de 10s ci6n mejor de sus partidarios y soporte de 10s directores,
editores rechazando el libro y argumentando (de forma y una dosis no pequeiia de education y <<publicidad)+.
educada, per0 contundente) que nunca habria mercado La ingenieria del software no ha disfrutado de una gran
para un libro sobre ccingenieria del softwaren. Afortu- publicidad, per0 a medida que va pasando el tiempo el
nadamente, McGraw-Hill decidio intentarlo3, y el res- concept0 se vende solo. De alguna manera, este libro es
to ya es historia. un ccanuncio,, para la tecnologia.
Durante 10s 6ltimos veinte afios, este libro ha cam- Es posible no estar de acuerdo con todos 10s enfo-
biado espectacularmente +n Ambito, tamafio, estilo y ques descritos en este libro. Algunas de las tCcnicas y
contenid-. A1 igual que la ingenieria del software mis- opiniones son polCmicas; otras deberan ajustarse para
ma, el libro tambiCn ha crecido, y por suerte tambiCn ha trabajar en diferentes entomos de desarrollo de softwa-
madurado durante 10s ultimos afios. re. Sin embargo, mi sincera esperanza es que Ingenie-
Hoy en dia un enfoque de ingenieria en el desarro- ria del Software: U n enfoque practico haya dibujado
Ilo del software de computadora es una sabiduria 10s problemas con 10s que nos enfrentarnos; haya demos-
convencional. Aunque continlie el debate sobre el ccpara- trado las ventajas de 10s conceptos de la ingenieria del
digma adecuado,,, el grado de automatizacion y 10s software, y haya proporcionado un marco de trabajo de
mCtodos mas efectivos, hoy en dia 10s principios sub- mCtodos y herramientas.
yacentes de la ingenieria del software se aceptan a tra- Como empieza un nuevo milenio, el software se
vCs de la industria. Entonces, ipor quC solo hace muy ha convertido en el product0 mas importante de la
poco tiempo que estamos siendo testigos de su gran industria y tambitn mas importante a nivel mundial.
adoption? Su impact0 e importancia han recomdo un largo cami-
La respuesta, creo yo, radica en la dificultad de la no. Y, sin embargo, una nueva generation de desa-
transicion de la tecnologia y el cambio cultural que la rrolladores de software deberan encontrarse con
acompafia. Aunque la mayoria de nosotros apreciamos muchos de 10s mismos retos con 10s que se enfrenta-
la necesidad de una disciplina de ingenieria para el soft- ron generaciones anteriores. Esperemos que aquellas
ware, luchamos contra la inercia de la practica anterior personas que se encuentren con el reto 4 n g e n i e r o s
y nos enfrentamos con nuevos dominios de aplicacio- del software- tengan la sabiduria de desarrollar sis-
nes (y 10s que disefian que son quienes trabajan en ellos) temas que mejoren la condition humana.
[BOL91] Bollinger, T., y C. McGowen, ccA Critical Look at [HOP901 Hopper, M.D., <<RattlingSABRE, New Ways to
Software Capability Evaluations,)) IEEE Software, Julio Compete on Information,), Harvard Business Review,
de 1991, pp. 25-41. Mayo-Junio de 1990.
[GIL96] Gilg, T., <<Whatis level Six?,,, IEEE Software, Ene- IPAU931 P a u k M. et a]., Capability Maturity Model for
ro de 1996, pp. 97-98 y 103 Somare, Software Engineering Institute, Camegie Mellon
University, Pittsburgh, PA, 1993.
Realmente 10s meritos son de Peter Freeman y Eric Munson, que

fueron quienes convencieron a McGraw-Hill de que valdria la pena
intentarlo.
CAPfTULO 32 PERSPECTIVAS FUTURAS
32.1 Consiga una copia de las mejores revistas de negocios y 32.4 Revise el estudio de 10s modelos de proceso evolutivo
de noticias de esta semana (por ejemplo: Newsweek, Time, Busi- del Capitulo 2. Haga una investigaci6n y recoja articulos
ness Week).Haga una lista de todos 10s articulos o noticias que recientes sobre este tema. Resuma las ventajas e inconvenientes
se puedan utilizar para ilustrar la importancia del software. de 10s paradigmas evolutivos basados en las experiencias indi-
32.2 Uno de 10s dominios de aplicaciones de software mas cadas en 10s articulos.
candentes son 10s sistemas y las aplicaciones basados en Web 32.5 Intente desarrollar un ejemplo que comience con la
(Capitulo 29). Estudie la forma en que las personas, comuni- recolecci6n de datos puros y dC lugar a la adquisicion de
cacidn y proceso tienen que evolucionar para adoptar el desa- informaci6n, despuCs del conocimiento, y finalmente de sabi-
rrollo de WebApps de ccpr6xima generation,,. duria.
32.3 Escriba una breve descripcih del entomo de desarrollo
ideal de un ingeniero del software hacia el aiio 2010. Descri- 32.6 Seleccione una tecnologia de actualidad <<candenten(no
ba 10s elementos del entomo (hardware, software y tecnolo- necesita ser una tecnologia de software) que se estC estudian-
gias de comunicaci6n) y su impacto en la calidad y el tiempo do en 10s medios populares y describa la forma en que el soft-
de comercializaci6n. ware posibilita su evoluci6n e impacto.
Los libros que estudian las tendencias futuras del software tution Press, 1999) han publicado una coleccion de articulos
y de la computacion abarcan una amplia gama de temas tec- y ensayos sobre el impacto de la tecnologia en las estructu-
nicos cientificos, economicos, politicos y sociales. Robertson ras sociales, de negocios y economicas. Para aquellos que
(The New Renaissance: Computers and The Next Level of estCn interesados en estos temas tCcnicos, Luryi, Xu y Zas-
Civilization, Oxford University Press, 1998), argumenta que lavsky (Future Trends in Microelectronics, Wiley, 1999) han
la revolucion informatica puede que sea el unico avance mas publicado una colecci6n de articulos sobre las direcciones
significative en la historia de la civilization. Dertrouzos y probables del hardware de computadora. Hayzelden y Big-
Gates (What Will Be: How The New World of Information ham (Software Agents for Future Communication Systems,
Will Change Our Lives, Harperbusiness, 1998) proporcionan Springer Verlag, 1999) han editado una coleccion que estu-
un profundo estudio de algunas de las direcciones que las tec- dia las tendencias del desarrollo de 10s agentes de software
nologias de la informacidn pueden seguir en las primeras inteligentes.
dCcadas de este siglo. Barnatt (Valueware: Technology,Huma- Kurzweil (The Age of Spiritual Machines, When Compu-
nity and Organization, Praeger Publishing, 1999) presenta un ters Exceed Human Intelligence, Vikinflenguin Books, 1999)
estudio intrigante de la cceconomia de las ideas,, y de la for- argumenta que dentro de 20 afios la tecnologia del hardware
ma en que se creara el valor econdmico a medida que evolu- tendra la capacidad de modelar completamente el cerebro
ciona el ciber-negocio. El libro de Negroponte (Being Digital, humano. Borgman (Holding on to Reality: The Nature of
Alfred A. Knopf, Inc., 1995) fue un best seller a mediados de Information at the Turn of the Millenium, University of Chi-
10s noventa y continua proporcionando una vision interesan- cago Press, 1999) ha escrito una historia de informacih intri-
te de la computacion y de su impacto global. gante, haciendo un seguimiento de su papel en la
Kroker y Kroker (Digital Delirium, New World Perspecti- transformacidn de la cultura. Devlin (InfoSense: Turning Infor-
ves, 1997) han publicado una coleccion p o l h i c a de ensayos, mation into Knowledge, W.H. Freeman & Co., 1999) trata de
poemas y humor en donde exarninan el impacto de las tecno- dar sentido a1 constante flujo de informacidn que nos bom-
logias digitales en las personas y en la sociedad. Brin (The Trans- bardea dia a dia. Gleik (Faster: The Acceleration of Just About
parent Society: Will Technology Force us To Choose Between Everything, Pantheon Books, 2000) estudia el ritmo cada vez
Privacy and Freedom?, Perseus Books, 1999) repasa el debate mas veloz del cambio tecnol6gico y de su impacto en todos
continuo asociado a la pCrdida inevitable de privacidad perso- 10s aspectos de la vida modema. Jonscher (The Evolution of
nal que acompaiia a1 crecimiento de las tecnologias de la infor- Wired Life: From the Alphabet to the Soul-Catcher Chip-How
macion. Shenk (Data Smog: Surviving the Information Glut, Information Technologies Change Our World, Wiley, 2000)
Harpercollins, 1998) estudia 10s problemas asociados con la argumenta que el pensamiento humano y la interaccion tras-
ccsociedad infectada de informaci6nn que se esta produciendo cienden la importancia de la tecnologia.
del volumen de informacion que producen las tecnologias de Una variedad de fuentes de informacion sobre las ten-
informacibn. dencias futuras en la informatica esta disponible en Internet.
Miller, Michalski y Stevens (21S' Century Technologies: Una lista actualizada de referencias en la red se puede encon-
Promises and Perils of a Dynamic Future, Brookings Insti- trar en http://www.pressman5.com
Ias Espanol I Ingles
V (Anilkis del hrca del negocio) BAA (Business Area Analysis)

L' (Autoridad de control de cambio) CCA (Change Control Authority)
3 (Acoplamiento entre clases de objetos) CBO (Coupling Between Object Classes)
Ps (Areas clave de proceso) KPAs (Key Process Areas)
V (Arquitectura del ciclo de vida) LCA (Life Cycle Architecture)
30 (Anlilisis del dominio orientado a objetos) OODA (Objcct-Oriented Domain Analysis)
(Aniilisis estructurado) SA (Structured Analysis)
2D (Anlilisis geomktrico de dos dimensiones) 2DGA (Two-dimensional Geometric Analysis)
3D (Anlilisis geomdtrico de Ires dimcnsiones) 3DGA (Three-dimensional Geometric Analysis)
0 (Anlilisis orientado a objetos) OOA (Object-Oriented Analysis)
1 (Acceso pliblico a datos miembros) PAD (Public Access to Data members)
1 (Arb01 de profundidad de herencia) DIT (Depth of the Inheritance Tree)
(Interfaz de programacicin de aplicaciones) API (Application Programming Interface)
DO (Anlilisis de 10s requisitos orientado a objetos) OORA (Object-Oriented Requirements Analysis)
;(Anhlisis de valor ganado) EVA (Earned Value Analysis)
(Anlilisis de vitlores limites) BVA (Boundary Value Analysis)
K (Kit de desarrollo Bean) BDK (Bean Development Kit)
D (Operador relational y de ramificacibn) BRO (Branch and Relational operator)
(brutos.sueldos) GW (gross.wagcs)
Certificacicin) C (Certification)
Consulta) Q (Query)
I (construccibn e integracibn) C 1 I (Construcfion and Integration)
(Clientelservidor) CIS (Client/sewer)
D (Disefio asistido por computadora) CAD (Computer-Aided Design)
ena DU (cadena de definicidn-uso) DU chain (Definition-Use chain)
SE (Ingenieria del software asistida por computadora) CASE (Conlputer-Aided Software Engineering)
(Ccntralizado controlado) C C (Controlled Centralised)
M (Carencia de cohesidn en 10s mCtodos) LCOM (Lack of Cohesion in Methods)
U (Comprobacicin estadistica de utilizacicin) SUT (Statistical Use Testing)
D (Cohesiones l'uncionales dkbiles) WFC (Weak Function Cohesion)
F (Cohesiones funcionales fuertcs) SFC (Strong Functional Cohesion)
I (Intetiaz conliln de pasarela) CGI (Common Gatcaiay Interface)
0 (Capa de gesticin de objetos) O M L (Object Management layer)
strir cle n ~ P t r i i w(Chidamber y Kemcrer) CK rncrrics s~rite(Chidamber and Kemerer metrics)
(Control numkrico) NC (Numerical Control)
(Complejidad de open~cidn) O C (Operillion Complexity)
COMO (Modelo constructive del coste) COCOMO (Constructive Cost Model)
I (Capacidad operativa inicial) IOC (Initial Operational Capability)
M (Modelo de objetos para componcntes) COM (Component Object Model)
RBA (Arquitectura comiln de distribncibn de objetos) CORBA (Common Object Request Broker Architecture)
(Control de perifkricos) PC (Peripheral Control)
r P (Coste de presupuestos del trabajo planilicado) BCWS (Budgeted Cost of Work Scheduled)
r R (Coste de presupuestos del trabajo realizado) BCWP (Budgeted Cost of Work Performed)
(Conveniencia de la representacicin) LA (Layout Appropriateness)
C (Clase-responsabilidad-colaboraci6n) CRC (Class-Responsibility-Collabori~tor)
TR (Coste real de trabajo realizado) ACWP (Actual Cost of Work Performed)
A (Control de trlifico aCreo) ATC (Air Traffic Control)
D (Comerciales ya desarrolladas) COTS (Commercial Off-The-Shelf)
C (Desarrollo basado cn componcntes) CBD (Component-Based Development)
(Descentralimdo controlado) CD (Controlled Decentralised)
BC (Descubrimiento de conocimiento en bases de datos) KDD (Knowledge Discovery in Databases)
S (Diagrama de context0 del sistema) SCD (System Context Diagram)
(Descentralizado democriitico) DD (Democratic Decentralized)
E (Desviacicin deliverada de la especilicaci6n) IDS (Intentional Deviation from Specification)
R (Diagrama de entidad-relecicin) ERD (Entity Relationship Diagram)
(Diseho formal) FD (Fomlal Design)
Tirmino en Espariol
DFC (Despliegue de la funcidn de calidad) QFD (Quality Function Deployment)

DFC (Diagrama de flujo de control) CFD (Control Flow Diagram)
DFD (Diagrama de flujo de datos) DFD (Data Flow Diagram)
DFS (Diagrama de flujo del sistema) SFD (System Flow Diagram)
DII (Documentaci6n imprecisa o incompleta) IID (Inaccurate or Incomplete Documentation)
D O 0 (Diseiio orientado a objetos) OOD (Object-Oriented Design)
DPR (Disefio para la reutilizacidn) DFR (Design for Reuse)
DRA (Desarrollo rhpido de aplicaciones) RAD (Rapid Application Development)
DSED (Desarrollo de sistemas estructurados de datos) DSSD (Data Structured Systems Development)
DSJ (Desarrollo de sistemas Jackson ) JSD (Jackson System Development)
DSN (Disefio de sistema de negocio) BSD (Business System Design)
DTE (Diagrama de transicidn de estados) STD (State Transition Diagram)
EAIP (Entorno de apoyo integrado a proyectos) IPSE (Integrated Project Support Environment)
EAT (Estructuras de anhlisis del trabaio) WBS (Work Breakdown Structure)
E C (Especificacion de control) CSPEC (Control Specification)
ECS (Elementos de configuracion del software) SCI (Software Configuration Items)
ED (Elementos de datos) DE (Data Elements)
EDC (Espacio de disefio cuantificado) QDS (Quantity Design Space)
EDE (Elementos de datos de entrada) DEI (Input Data Elements)
EDR (Elementos de datos retenidos) DER (Retained Data Elements)
EDS (Elementos de datos de salida) DEO (Output Input Data Elements)
EEC (Especificaci6n de estructura de cajas) BSS (Box Structure Specification)
EED (Eficacia de elimination de defectos) DRE (Defect Removal Efficiency)
EIE (Especificacion incompleta o errdnea) IES (Incomplete or Erroneous Specification)
EIS (Entorno de ingenieria del software) SEE (Software Engineering Environment)
ELD (Error en la 16gica de disefio) EDL (Error in Design Logic)
E P (Especificacion de proceso) PSPEC (Process Specification)
ERD (Error en representacidn de datos) EDR (Error in Data Representation)
ES (Estados) ST (States)
ETRP (Evaluacion y tCcnica de revision de programas) PERT (Program Evaluation and Review Technique)
FA (Factor de acoplamiento) C F (Coupling Factor)
FHA (Factor de herencia de atributo) AIF (Attribute Inheritance Factor)
F H M (Factor de herencia de mCtodos) MIF (Method Inheritance Factor)
FIR (FICA.impuesto.retenido) FTW (FICA.Tax.Withheld)
FP (Factor de polimorfismo) P F (Polymorphism Factor)
FPGC (Facilidades de presentacion grhfica de computadora) CGDF (Computer Graphics Display Facilities)
FURPS (Funcionalidad, facilidad de uso, fiabilidad, FURPS (Functionality, Usability, Reliability,
rendimiento y capacidad de soporte) Performance and Supportability)
FZ (Fijar zona) ZS (Zone Set)
GBD (Gestidn de base de datos) DBM (Database Management)
G C (Generation de cbdigo) C G (Code Generation)
GCS (Garantia de calidad del software) SQA (Software Quality Assurance)
GCS (Gestion de la configuracidn del software) SCM (Software Configuration Management)
G I P (Grupo independiente de prueba) ITG (Independent Test Group)
OCMIOPM (Objetivo, cuestidn (pregunta), mttrica) GQM (Goal, Question, Metric)
GTC (Gestidn total de calidad) T Q M (Total Quality Management)
HD (Habilitarldeshabilitar) AD (Arm-Disarm) ( p . 731)
HIR (Hoja de informacidn del riesgo) RIS (Risk Information Sheet)
HTTP (Protocolo de transferencia de hipertexto) HTTP (Hypertext Transfer Protocol)
IA (Inteligencia artificial) A1 (Artificial Intelligence)
I C (Inspeccidn de codigo) CI (Code Inspection)
I-CASE (CASE integrado) I-CASE (Integrated CASE)
ICED (indice de calidad de la estructura de disefio) DSQI (Design Structure Quality Index)
I C M P (Protocolo de mensajes de control de Internet) ICMP (Internet Control Message Protocol)
IDC (indice de desarrollo de coste) CPI (Cost Performance Index)
IDL (Lenguaje de definicidn de interfaces) IDL (Interface Definition Language)
IDP (fndice de desarrollo de planificacion) SPI (Schedule Performance Index)
1E (indice de error) E l (Error index)
IEC (Informes de estado de la configuracion) CSR (Configuration Status Reporting)
IEP (Incumplimiento de 10s esthdandares de programacibn) VPS (Violation of Programming Standards)
IES (hdice de especializacidn) SI (Specialisation Index)
I F (fndice de fase) PI (Phase index)
IGU (Interfaz grafica de usuario) GUI (Graphical User Interface)
I H M (Interfaz hombre-mhquina) HCI (Human-Computer Interface)
IMI (Interfaz de mddulo inconsistente) I C I (Inconsistent Component Interface)
IMS (hdice de madurez del software) SMI (Software Maturity Index)
Te'rmino en Espatiol Te'rmino equivalente en I n & %
I P (Protocolo de Internet) I P (Internet Protocol)

IPN (Ingenieria de proceso de negocio) BPE (Business Process Engineering)
IS (Ingenieria de sistemas) SE (System Engineering)
ISBC (Ingenieda del software basada en componentes) CBSE (Component-Based Software Engineering)
I S 0 0 (Ingenieria del software orientada a objetos) OOSE (Object-Oriented Software Engineering)
ISOOAC (Ingenieria del software orientada a objetos asistida OOCASE (Object-Oriented Computer Aided Software
por computadora) Engineering)
IU (Interfaz de usuario) UI (User Interface)
IUSC (Interfaz de usuario y funciones decontrol) UICE (User Interface and Control Facilities)
IWeb (Ingenieria Web) WebE (Web-Engineering)
KLDC (mil lineas de c6digo) KLOC (thousands lines of code)
LDAs (Lenguajes de descripci6n arquitectbnica) ADLs (Architectural Description Languages)
LDC (Lineas de codigo) LOC (Lines of Code)
LDP (Lenguaje de disefio de programas) PDL (Program Design Language)
LIM (Lenguaje de interconexi6n de modulos) M I L (Module Interconnection Language)
LPN1 (Limite de proceso natural inferior) LPNL (Lower Natural Process Limit)
LSPN (Limite superior del proceso natural) UNPL (Upper Natural Process Limit)
MACA (Metodo de analisis de compromiso para la arquitectura) ATAM (Architecture Trade-off Analysis Method)
MAD (Modulos de analisis de diseiio) DAM (Design Analysis Modules)
MCC (Mala interpretation de la comunicaci6n del cliente) MCC (Misinterpretation of Customer Communication)
MCC (Metodo del camino critico) CPM (Critical Path Method)
MCM (Modelo de capacidad de madurez) CMM (Capability Maturity Model)
M C P (Marco comun de proceso) C P F (Common Process Framework),
MDOO (Metricas para el disefio orientado a objetos) MOOD (Metrics for Object-Oriented Design)
MEPS (Mejora estadistica del proceso de software) SSP1 (Statistical Software Process Improvement)
MMCGP (Modelo de madurez de la capacidad de gestion de personz11) PM-CMM (People Management Capability Maturity Model)
MMGR (Mitigacibn, monitorizaci6n y gesti6n del riesgo) RMMM (Risk Mitigation, Monitoring and Management)
Modelo M 0 1 (Motivacion, organizaci6n. ideas o innovaci6n) MO1 Model (Motivation, Organisation, Ideas or innovation)
M O M (Software intermedio orientado a mensajes) MOM (Message Oriented Middleware)
MPC (MCtodos ponderados por clase) WMC (Weighted Methods per Class)
NCC (Numero de clases clave) NKC (Number of Key Classes)
NCR (Numero de clases raiz) NOR (Number of Root Classes)
NDD (Numero de descendientes) NOC (Number of Children)
NE (Numero de escenarios) NSS (Number of Scenario Scripts)
NN (Nodos de navegacion) WON (Ways of Navigating)
NOA (Numero de operaciones afiadidas por una subclase) NOA (Number of Operations Added by a subclass)
NOR (Nlimero de operaciones redefinidas para una subclase) N O 0 (Number of Operations Overridden by subclass)
NPD (Numero de padres directos) FIN (Fan in)
NPprom (Nlimero de parimetros por operaci6n promedio) NPaVg(Average Number of Parameters per operation)
NSUB ( N h e r o de subsistemas) NSUB (Number of Subsystems)
OB (Objetos) OB (Objects)
OCI (Orden de cambio de ingenieria) ECO (Engineering Change Order)
OCV (Objetivos del ciclo de vida) L C 0 (Life Cycle Objectives)
ODBC (Conectividad abierta de bases de datos) ODBC (Open Database Connectivity)
OLCRS (Sistema interactivo para apuntarse a cursos) OLCRS (On-Line Course Registration System)
OMG/CORBA (Grupo de gestidn de objetosIArquitectura comlin OMG/CORBA (Object Management Group/Common Object
de distribution de objetos) Request Broker Architecture)
00 (Orientado a objetos) 00 (Object-Oriented)
ORB (Agente de distribuici6n de objetos) ORB (Object Request Broker)
P (Prueba) T (test)
P&R (Pregunta y respuesta) Q&A (Question and Answer)
PAT (Presupuesto a Ia terminacibn) BAC (Budget At Completion)
PEI (Planificaci6n de la estrategia de informaci6n) ISP (Information Strategy Planning)
PEN (Proceso elemental de negocios) EBP (Elementary Business Process)
PF (Puntos de funcion) F P (Function Points) y
Pfu (Primitivas funcionales) FuP (Functional Primitives)
P I E (Prueba incompleta o err6nea) IET (Incomplete or Erroneous Testing)
PMFu (Primitivas modificadas de funcidn manuaI) FuPM (Modified Manual Function Primitives)
P O 0 (Programaci6n orientada a objetos) O O P (Object-Oriented Programming)
POP3 (Protocolo de oficina de correos versi6n 3) POP3 (Post Office Protocol version 3)
P P (Planificaci6n de prueba) T P (Test Planning)
P P P (Porcentaje public0 y protegido) PAP (Percent PubIic and Protected)
PRO/SIM (Construcci6n de prototipos y simulaci6n) PRO/SIM (PROtotyping and SIMuIation)
P r o 0 (Pruebas orientadas a objetos) OOT (Object-Oriented Testing)
PSI (Procesos secuenciales intercomunicados) CSP (Communicating Sequential Processes)
RE (Relaciones) RE (Relationships)
583
APENDICE
Te'rmino en Espaiiol Te'rmino equivalente eti Inglhs
' Rei (Conexiones de relacion) Rei (Relationship connections)

RFP RFP
Rm (Rangos de movimiento) mR (moving range)
RPC (Respuesta para una clase) RFC (Response for a class)
RPN (Reingenieria de procesos de negocios) BPR (Business Process Reengineering)
R R (Recolecci6n de requisitos) RG (Requirements Gathering)
R T F (Revisibn tecnica formal) FTR (Formal Technical Review)
SBDOO (Sistemas de bases de datos orientadas a objetos) OODBS (Object-Oriented Database System)
SCCT (Sistema de clasificacion de cinta transportadora) CLSS (Conveyor Line Sorting System)
SCE (Salidas/Control/entradas) OCI (Output/Control/Input)
SDIU (Sistemas de desarrollo de la interfaz de usuario) UIDS (User-Interface Development Systems)
SEI (Institute de ingenieria de software) SEI (Software Engineering Institute)
SGBDOO (Sistemas de gestion de bases de datos orientadas a objetos) OODBMS (Object-Oriented Database Management System)
SGBDR (Sistema de gesti6n de bases de datos relational) RDBMS (Relational Database Management System)
SGH (Servicios de gesti6n de herramientas) TMS (Tools management services)
SIG (Sistemas de informaci6n de gesti6n) MIS (Management Information System)
SQA (Gesti6n de calidad de Software) SQA (Software Quality Assurance
SQE (Ingenieria de Calidad del software) SQE (Software Quality Engineering)
SQL (Lenguaje de consultas estructurado) SQL (Structure Query Language)
SSRB (Sistema de seguimiento y reparacidn de baches) PHTRS (Pot Hole Tracking and Repair System)
T4G (TCcnicas de cuarta generation) 4GT (Fourth Generation Techniques)
TADE (TCcnicas de Anilisis y disefio estructurado) SADT (Structured Analysis and Design Technique)
TAP (Tabla de activation de procesos) PAT (Process Activation Language)
T C (Tamaiio de clase) CS (Class Size)
TC, (Muestras (tokens) de datos) TCi (Data tokens)
TFEA (TCcnicas para facilitar las especificaciones de la aplicacih) FAST (Facilitated Application Specification Techniques)
T I (Tecnologias de la informacion) I T (Information technologies)
T L P (Error en la traduccidn del disefio al lenguaje de programaci6n) PLT (error in Programming Language Translation)
T M C (Tiempo medio de cambio) MTTC (Mean-time-to-change)
T M E F (Tiempo medio entre fallos) MTTF (Mean time to failure)
TMEF (Tiempo medio entre fallos) MTBF (Mean time between failure)
T M O (Tkcnica de modelado de objetos) OMT (Object Modelling Technique)
TMR (Tiempos medios de reparaci6n) MTTR (Mean time to repair)
TOp,,, (Tamaiio medio de operation) OSaVg (Average Operation Size)
TR (Transiciones) T R (Transitions)
UML (Lenguaje de modelado unificado) UML (Unified Modelling Language)
USN (Unidad semintica de navegaci6n) SNU (Semantic Navigation Unit)
V&V (Verificaci6n y validaci6n) V&V (Verification and Validation)
VC (Varianza del Coste) CV (Cost Variance)
VC (Verification de correccidn) CV (Correctness Verification)
VP (Varianza de planificacibn) SV (Schedule Variance)
WebApps (Aplicaciones basadas en Web) WebApps (Web-based Applications)
XML (Lenguaje de marcas extensible) XML (Extensible Mark-up Language)
Sighs Inglks / Espanol
Thrmino en Ingle's Thrmino equivalenre en Espaiiol
2DGA (Two-dimensional Geometric Analysis) AG2D (Anilisis geomCtrico de dos dimensiones)

3DGA (Three-dimensional Geometric Analysis) AG3D (Anilisis geomCtrico de tres dimensiones)
4GT (Fourth Generation Techniques) T4G (Tecnicas de cuarta generacidn)
ACWP (Actual Cost of Work Performed) CRTR (Coste real de trabajo realizado)
AD (Arm-Disarm) HD (Habilitarldeshabilitar)
ADLs (Architectural Description Languages) LDAs (Lenguajes de descripcidn arquitectonica)
A1 (Artificial Intelligence) IA (Inteligencia artificial)
AIF (Attribute lnheritance Factor) FHA (Factor de herencia de atributo)
API (Application Programming Interface) API (Interfaz de programacion de aplicaciones)
ATAM (Architecture Trade-off Analysis Method) MACA (MCtodo de anAlisis de compromiso para la arquitectura)
ATC (Air Traffic Control) CTA (Control de trafico aereo)
BAA (Business Area Analysis) AAN (Analisis del Area del negocio)
BAC (Budget At Completion) PAT (Presupuesto a la terminacibn)
BCWP (Budgeted Cost of Work Performed) CPTD (Coste de presupuestos del trabajo desarrollado)
BCWS (Budgeted Cost of Work Scheduled) CPTP (Coste presupuestado del trabajo planificado)
BDK (Bean Development Kit) BDK (Kit de desarrollo Bean)
Te'rmino en Ingle's Te'rmino equivalenre en Espariol
BPE (Business Process Engineering) IPN (Ingenieria de proceso de negocio)

BPR (Business Process Reengineering) RPN (Reingenieria de procesos de negocios)
BRO (Branch and Relational operator) BRO (Operador relational y de ramificaci6n)
BSD (Business System Design) DSN (Diseiio de sistema de negocio)
BSS (Box Structure Specification) EEC (Especificacion de estructura de cajas)
BVA (Boundary Value Analysis) AVL (Andlisis de valores limites)
C (Certification) C (Certificaci6n)
C & I (Construction and Integration) C & I (conshuccibn e integracion)
CIS (ClientIServer) CIS (Clientelservidor)
CAD (Computer-Aided Design) CAD (Diseiio asistido por computadora)
CASE (Computer-Aided Software Engineering) CASE (Ingenieria del software asistida por computadora)
CBD (Component-Based Development) DBC (Desarrollo basado en componentes)
CBO (Coupling Between Object Classes) ACO (Acoplamiento entre clases de objetos)
CBSE (Component-Based Software Engineering) ISBC (Ingenieria del software basada en componentes)
C C (Controlled Centralised) C C (Centralizado controlado)
CCA (Change Control Authority) ACC (Autoridad de control de cambios)
C D (Controlled Decentralised) DC (Descentralizado controlado)
C F (Coupling Factor) FA (Factor de acoplamiento)
CFD (Control Flow Diagram) DFC (Diagrama de flujo de control)
C G (Code Generation) G C (Generacibn de c6digo)
CGDF (Computer Graphics Display Facilities) FPGC (Facilidades de presentacidn grifica de computadora)
CGI (Common Gateway Interface) CGI (Interfaz comun de pasarela)
C I (Code Inspection) I C (Inspecci6n de cbdigo)
CK metrics suite (Chidamber and Kemerer metrics) C K sene de metricas (Chidamber y Kemerer)
CLSS (Conveyor Line Sorting System) SCCT (Sistema de clasificacidn de cinta transportadora)
C M M (Capability Maturity Model) M C M (Modelo de capacidad de madurez)
COCOMO (Constructive Cost Model) COCOMO (Modelo constructivo del coste)
C O M (Component Object Model) COM (Modelo de objetos para componentes)
CORBA (Common Object Request Broker Architecture) CORBA (Arquitectura comdn de distribuci6n de objetos)
COTS (Commercial Off-The-Shelf) CYD (Comerciales ya desarrolladas)
C P F (Common Process Framework) M C P (Marco comun de proceso)
CPI (Cost Performance Index) IDC (hdice de desarrollo de coste)
C P M (Critical Path Method) CPM (MCtodo del camino critico)
C R C (Class-Responsibility-Collaborator) CRC (Clase-responsabilidad-colaboraci6n)
C S (Class Size) TC (Tamaiio de clase)
CSP (Communicating Sequential Processes) PSI (Procesos secuenciales intercomunicados)
CSPEC (Control Specification) E C (Especificaci6n de control)
CSR (configuration Status Reporting) I E C (Inforrnes de estado de la configuraci6n)
CV (Correctness Verification) VC (Verificaci6n de correccibn)
CV (Cost Variance) VC (Varianza del Coste)
DAM (Design Analysis Modules) MAD (M6dulos de andlisis de disefio)
DBM (Database Management) GBD (Gestibn de base de datos)
DD (Democratic Decentralized) DD (Descentralizado democritico)
D E (Data Elements) ED (Elementos de datos)
DEI (Input Data Elements) EDE (Elementos de datos de entrada)
DEO (Output Data Elements) EDS (Elementos de datos de salida)
DER (Retained Data Elements) EDR (Elementos de datos retenidos)
DFD (Data Flow Diagram) DFD (Diagrama de flujo de datos)
DFR (Design For Reuse) DPR (DiseAo para la reutilizaci6n)
DIT (Depth of the Inheritance Tree) APH (Arb01 de profundidad de herencia)
DRE (Defect Removal Efficiency) EED (Eficacia de la eliminacidn de defectos)
DSQI (Design Structure Quality Index) ICED (hdice de calidad de la estructura de disefio)
DSSD (Data Structured Systems Development) DSED (Desarrollo de sistemas estmcturados de datos)
DU chain (Definition-Use chain) Cadena DU (cadena de definicih-uso)
EBP (Elementary Business Process) PEN (Proceso elemental de negocios)
E C O (Engineering Change Order) OCI (Orden de cambio de ingenieria)
EDL (Error in Design Logic) ELD (Error en la 16gica de diseiio)
EDR (Error in Data Representation) ERD (Error en la representaci6n de 10s datos)
E I (Error Index) I E (indice de error)
ERD (Entity Relationship Diagram) DER (Diagrama de entidad-relacih)
EVA (Earned Value Analysis) AVG (Andlisis de valor ganado)
FAST (Facilitated Application Specification Techniques) TFEA (Tkcnicas para facilitar las especificaciones de la aplicaci6n)
FD (Formal Design) DF (DiseAo formal)
FIN (Fan in) NPD (Numero de padres directos)
F P (Function Points) PF (Puntos de funci6n)
FTR (Formal Technical Review) RTF (Revisi6n tknica formal)
Te'rmino en Ingle's Te'rmino equivalente en Espatiol
FTW (FICA.tax.withheld) FIR (FICA.impuesto.retenido)

F u P (Functional Primitives) Pfu (Primitivas funcionales)
FuPM (Modified Manual Function Primitives) PMFu (Primitivas modificadas de funcidn manual)
FURPS (Functionality, Usability, Reliability, FURPS (Funcionalidad, facilidad de uso, fiabilidad,
Performance and Supportability) rendimiento y capacidad de soporte)
GQM (Goal, Question, Metric) GQM (Objetivo, cuestion, mitrica)
GUI (Graphical User Interface) IGU (Interfaz grifica de usuario)
G W (gross.wages) BS (bmtos.sueldos)
HCI (Human-Computer Interface) IHM (Interfaz hombre-maquina)
HTTP (Hypertext Transfer Protocol) HTTP (Protocolo de transferencia de hipertexto)
I-CASE (Integrated CASE) I-CASE (CASE integrado)
ICI (Inconsistent Component Interface) IMI (Interfaz de m6dulo inconsistente)
ICMP (Internet Control Message Protocol) ICMP (Protocolo de mensajes de control de Internet)
IDL (Interface Definition Language) IDL (Lenguaje de definicion de interfaces)
IDS (Intentional Deviation from Specification) DDE (Desviacibn deliverada de la especificacion)
IES (Incomplete or Erroneous Specification) EIE (Especificacion incompleta o err6nea)
I E T (Incomplete or Erroneous Testing) PIE (Prueba incompleta o erronea)
IID (Inaccurate or Incomplete Documentation) DII (Documentacibn imprecisa o incompleta)
IOC (Initial Operational Capability) COI (Capacidad operativa inicial)
I P (Internet Protocol) I P (Protocolo de Internet)
lPSE (Integrated Project Support Environment) EAIP (Entorno de apoyo integrado a proyectos)
ISP (Information Strategy Planning) PEI (Planificacion de la estrategia de informacion)
I T (Information Technologies) T I (Tecnologias de la informacion)
ITG (Independent Test Group) G I P (Grupo independiente de pmeba)
JSD (Jackson System Development) DSJ (Desarrollo de sistemas Jackson)
KDD (Knowledge Discovery in Databases) DCBC (Descubrimiento de conocimiento en bases de datos)
KLOC (thousands Lines of Code) KLDC (miles de lineas de codigo)
KPAs (Key Process Areas) ACPs (Areas clave de proceso)
LA (Layout Appropriateness) CR (Conveniencia de la representation)
LCA (Life Cycle Architecture) ACV (Arquitectura del ciclo de vida)
L C 0 (Life Cycle Objectives) OCV (Objetivos del ciclo de vida)
LCOM (Lack of Cohesion in Methods) CCM (Carencia de cohesion en 10s mitodos)
LOC (Lines of Code) LDC (Lineas de codigo)
LPNL (Lower Natural Process Limit) LPN1 (Limite de proceso natural inferior)
MCC (Misinterpretation of Customer Communication) MCC (Mala interpretacion de la comunicacion del cliente)
M I F (Method lnheritance Factor) FHM (Factor de herencia de mCtodos)
MIL (Module Interconnection Language) LIM (Lenguaje de interconexidn de m6dulos)
MIS (Management lnfonnation System) SIG (Sistemas de informacion de gestion)
MIS (Miscellaneous) VAR (Varios)
MOI Model (Motivation, Organisation, Ideas or Innovation) Modelo MOI (Motivacion, organizacibn, ideas o innovacibn)
MOM (Message Oriented Middleware) MOM (Software intermedio orientado a mensajes)
MOOD (Metrics for Object-Oriented Design) MDOO (Metricas para el diseiio orientado a objetos)
mR (moving Range) Rm (Rangos de movimiento)
MTBF (Mean Time Between Failure) T M E F (Tiempo medio entre fallos)
MTTC (Mean-Time-To-Change) T M C (Tiempo medio de cambio)
MTTF (Mean Time To Failure) T M F (Tiempo medio de fallos)
MTTR (Mean Time To Repair) TMR (Tiempos medios de reparation)
NC (Numerical Control) CN (Control numirico)
NKC (Number Of key classes) NCC (Numero de clases clave)
NOA (Number of Operations Added by a subclass) NOA (Nlimero de operaciones afiadidas por una subclase)
NOC (Number of Children) NDD (Numero de descendientes)
N O 0 (Number of Operations Overridden by subclass) NOR (Numero de operaciones redefinidas para una subclase)
NOR (Number of Root classes) NCR (Nbmero de clases raiz)
NPavg (Average Number of Parameters per operation) NPprom (NGmero de parimetros por operacidn promedio)
NSS (Number of Scenario Scripts) NE (Nlimero de escenarios)
NSUB (Number of Subsystems) NSUB (Nhmero de susistemas)
O B (Objects) OB (Objetos)
O C (Operation Complexity) C O (Complejidad de operation)
OCI (Output/Control/Input) SCE (Salidas/Dontrol/entradas)
ODBC (Oven
. . Database Connectivity) ODBC (Conectividad abierta de bases de datos)
OLCRS (On-line Course Registration System) OLCRS (Sitema interactivo para apuntarse a cursos)
OMGlCORBA (Object Management Group/Common Object Request OMGICORBA (Grupo de gestidn de objetos/Arquitectura comun
Broker Architecture) de distribucibn de objetos)
OML (Object Management Layer) CGO (Capa de gesti6n de objetos)
OMT (Object Modelling Technique) TMO (TCcnica de modelado de objetos)
00 (Object-Oriented) 00 (Orientado a objetos)
Te'rmino en Ingle's Te'rmino equivalente en Espatiol
OOA (Object-oriented Analysis) AOO (AnAlisis orientado a objetos)

OOCASE (Object-Oriented Computer Aided Software Engineering) ISOOAC (Ingenieria del software orientada a objetos asistida
por computadora)
OOD (Object-Oriented Design) D O 0 (Diseiio orientado a objetos)
OODA (Object-Oriented Domain Analysis) A D O 0 (Anhlisis del dominio orientado a objetos)
OODBMS (Object-Oriented Database Management System) SGBDOO (Sistemas de gesti6n de bases de datos orientadas a objetos)
OODBS (Object-Oriented Database Systems) SBDOO (Sistemas de bases de datos orientadas a objetos)
O O P (Object-Oriented Programming) P O 0 (Programacion orientada a objetos)
OORA (Object-Oriented Requirements Analysis) AROO (Analisis de 10s requisitos orientado a objetos)
OOSE (Object-Oriented Software Engineering) I S 0 0 (Ingenieria del software orientada a objetos)
O O T (Object-Oriented testing) P r o 0 (Pmebas orientadas a objetos)
ORB (Object Request Broker) ORB (Agente de distribuici6n de objetos)
OSavg (Average Operation Size) TOprom (Tamafio medio de operation)
PAD (Public Access to Data members) APD (Acceso pdblico a datos miembros)
PAP (Percent Public and protected) P P P (Porcentaje publico y protegido)
PAT (Process Activation Language) TAP (Tabla de activacidn de procesos)
P C (Peripheral Control) C P (Control de perifkricos)
PDL (Program Design Language) LDP (Lenguaje de disefio de programas)
PERT (Program Evaluation and Review Technique) PERT (Ttcnica de evaluacion y revision de programas)
P F (Polymorphism Factor) F P (Factor de polimorfismo)
PHTRS (Pot Hole Tracking and Repair System) SSRB (Sistema de seguimiento y reparation de baches)
PI (Phase Index) I F (hdice de fase)
PLT (error in Programming Language Translation) T L P (Error en la traduccion del diseiio a1 lenguaje de programacion)
PM-CMM (People Management Capability Maturity Model) MMCGP (Modelo de madurez de la capacidad de gestion de personal)
POP3 (Post Office Protocol version 3) POP3 (Protocolo de oficina de correos version)
PROISIM (PROtotyping and SIMulation) PROISIM (Constmccibn de prototipos y simulacibn)
PSPEC (Process SPECification) E P (Especificacion de proceso)
Q (query) C (Consulta)
Q&A (Question and Answer) P&R (Pregunta y respuesta)
QDS (Quantity Design Space) EDC (Espacio de disefio cuantificado)
QFD (Quality Function Deployment) DFC (Despliegue de la funcion de calidad)
RAD (Rapid Application Development) DRA (Desamollo rhpido de aplicaciones)
RDBMS (Relational Database Management System) SGBDR (Sistema de gestidn de bases de datos relational)
RE (Relationships) RE (Relaciones)
Rei (Relationship connections) Rei (Conexiones de relacion)
RFC (Response For a Class) RPC (Respuesta para una clase)
R G (Requirements Gathering) RR (Recoleccion de requisitos)
RIS (Risk Information Sheet) HIR (Hoja de informaci6n de riesgos)
RMMM (Risk Mitigation, Monitoring and Management) RSGR (Reduccibn, supervision y gesti6n de riesgos)
SA (Structured Analysis) AE (Anilisis estmcturado)
SADT (Structured Analysis and Design Technique) TADE (TCcnicas de Anhlisis y diseiio estmcturado)
SCD (System Context Diagram) DCS (Diagrama de context0 del sistema)
SCI (Software Configuration Items) ECS (Elementos de configuraci6n del software)
SCM (Software Configuration Management) GCS (Gestibn de la configuracion del Software)
SE (System Engineering) IS (Ingenieria de sistemas)
SEE (Software Engineering Environment) EIS (Entomo de ingenieria del software)
SEI (Software Engineering Institute) SEI (Instituto de ingenieria de software)
SFC (Strong Functional Cohesion) C F F (Cohesiones funcionales fuertes)
SFD (System Flow Diagram) DFS (Diagrama de flujo del sistema)
SI (Specialisation Index) IES (hdice de especializacion)
SMI (Software Maturity Index) IMS (hdice de madurez del software)
SNU (Semantic Navigation Unit) USN (Unidad semhntica de navegacibn)
SPI (Schedule Performance Index) IDP (Indice de desamollo de planificacion)
SQA (Software Quality Assurance) GCS (Garantia de calidad del software)
SQE (Software Quality Engineering) SQE (Ingenieria de Calidad del software)
SQL (Structure Query Language) SQL (Lenguaje de consultas estmcturado)
SSP1 (Statistical Software Process Improvement) MEPS (Mejora estadistica del proceso de software)
S T (States) ES (Estados)
STD (State Transition Diagram) DTE (Diagrama de transition de estados)
SUT (Statistical Use Testing) CEU (Comprobaci6n estadistica de utilization)
SV (Schedule Variance) V P (Varianza de planificacibn)
T (test) P (Pmeba)
TCi (Data tokens) TCi (Muestras -tokens- de datos)
TMS (Tools Management Services) SGH (Servicios de gesti6n de herramientas)
T P (Test Planning) P P (Planificacih de prueba)
TQM (Total Quality Management) GTC (Gesti6n total de calidad)
Te'rmino en Ingle's Thmino equivalente en Espatiol
TR (Transitions) TR (Transiciones)
UI (User Interface) IU (Interfaz de usuario)
UICE (User Interface and Control Facilities) IUFC (Interfaz de usuario y facilidades de control)
UIDS (User-Interface Development Systems) SDIU (Sistemas de desarrollo de la interfaz de usuario)
UML (Unified Modelling Language) UML (Lenguaje de modelado unificado)
UNPL (Upper Natural Process Limit) LPNS (Limite de proceso natural superior)
V&V (Verification and validation) V&V (Verificaci6n y validacibn)
VPS (Violation of Programming Standards) IEP (Incumplimiento de las estidandares de programacion)
WBS (Work Breakdown Structure) EAT (Estructuras de anilisis del trabajo)
WebApps (Web-based Applications) WebApps (Aplicaciones basadas en Web)
WebE (Web-Engineering) IWeb (Ingenieria Web)
WFC (Weak Function Cohesion) CFD (Cohesiones funcionales dtbiles)
WMC (weighted methods per class) MPC (MCtodos ponderados por clase)
WON (Ways of navigating) NN (Nodos de navegaci6n)
XML (Extensible Mark-up Language) XML (Lenguaje de marcas extensible)
ZS (Zone Set) FZ (Fijar zona)
Abstracci6n. 223-224.423 funcional, 527
Acceso publico a datos rniembros (APD), 429 para ganar valores, 125- I26
Ackerman. A.F., 308 de interaccibn, 527
Acoplarniento, 23 1.424 de inventario, 545-546,554
entre clases objeto (ACO), 426 (n~crpping)
cornh. 23 1 de las transacciones. 252-255
de contenido. 23 1 de las transforrnaciones, 247-252
de control, 23 1 orientado a objetos (AOO), 352,376
externo, 23 1 de cornponentes genkricos. 366-367
rnCtricas de, 334-335 consistencia, 4 10-4 12
Actividndes enfoque(s)
de construcci6n e integraci6n (C&I), 170, 171 00,362
del rnarco de trabajo, 25,46 unificado, 363-364
de rnodelado de disefio, 171 exactitud, 409-4 10
protectoras, 16, 38 , mCtodos de, 362-363
Actores, 187- 188, 368 proceso, 367-373
Adaptador de objetos, 5 13 pruebas, 409-4 10
Agente de distribuci6n de objetos (ORB), 5 1 1 principios del, 188- 192
Agregaci6n. 394-395 de 10s requisites, 20
Agrupaci6n descripci6n, 182- 183
de datos atines, 505-506 orientado a objetos (AROO), 344
de objetos, 156 para la reutilizaci6n. 48 1-482
Albretch, A.J., 62 de selecci6n del diseiio, 244-245
Algoritrnos, 6 1 de tareas, 264
disefio de, 389-390 de valores lirnite (AVL). 297
Alrnactn Aplicaciones basadas en Web (WehApps)
CASE integsado (I-CASE) atributos de calidad, 523-524
caracteristicas y contenido, 568-57 1 caracteristicas, 523
papel, 567-568 categorias, 523
de dntos, 239-240, 504 contenido, 536-537
Almacenanliento estructurado, 480 controladas por el contenido, 522
Arnbigiiedades, 436 diseiio, 527-532
~ r n b i t o536
. escalabilidad. 537
del concepto, 1 19, 120- 121 evoluci6n continua, 523
prelirninases, 119 intensivas de red, 522
del software, 45 personas, 537
definici6n. 79 politicas, 537
ejernplo, 80-82 pruebas, 532-533
obtener informaci611, 79-80 tecnologias, 524
vabilidad, 80 Arbol
Ambler, S., 368 de decision, 93-94
Andisis, 216, 563 de profundidad de herencia (APH). 425,429
del drbol de fallos, 144 Areas de proceso clave (ACP), 14
del drea de negocio (AAN), 170 car;~cteristicas,18
del cbdigo fuente, 550-55 1 Arnold, R.S., 550
de cornprorniso para la arquitectura, 243-244 Arquitectura(s), 169- 170
de la configu~.acicin,527 de aplicaci6n. 169- 170
del contenido, 527 del ciclo de vida (ACV), 27
de contribuci6n, 245 cliente/servidor (CIS), 552-553
de coste, 485-486 de control, 243
de datos, 55 1 de datos, 169- 170,24 1-242.243
descripci6n del, 181, 36 1 descripci6n,238
del dorninio, 364,476-477 estratificadas, 242,496-497
orientado a objetos (ADOO), 344 importancia de la, 238-239
proceso, 365-366 de integraci6n. 566-567
estructurado, 216-217 de llarnada y retosno, 242
descripcibn, 199-200 orientadas a objetos, 242
historia, 200 del software, 226
rnecmisrnos, 2 10-2 15 Asignacibn de componentes
de fallos, 56-57 gesti6n de datos rernota, 5 10
Asignaci6n de componentes (Cont.) Capa de
16gica distribuida, 5 10 gestion de objetos (CGO), 567
' presentacidn distribuida, 509 interfaz de usuario, 566
remota, 509-5 10 repositorio cornpartido, 567
Asociacion, 395 Capacidad
de control, 5 I6 de descomposici6n, 284
de datos, 5 16 de expansion, 325
Atributos, 202,233-234 operativa inicial (COI), 27
especificacion de, 353 Card, D.N., 332
Auditona de configuracion, 158-159 Cardinalidad, 203
Autodocumentaci6n, 325 Carencia de cohesion en 10s mCtodos (CCM), 426,428
Automatization, 480 CASE integrado (I-CASE), 565-566
Autoridad de control de cambio (ACC), 157-158, 159 Cashman, M., 35 1
Caso(s) de
prueba, 415
Bach, J., 156 derivacion, 288-290
Balzer. R., 194 USO,186-188,367-368,374-375,395-397
Base de datos, 166,239,509 Caswell, D.L., 65
diseiio de, 5 14-515 Cavano, J.P., 326
estructura, 549-550 Certification, 461,468-649
objeto de, 5 16 Certificados digitales, 508
pruebas, 5 17 Champeaux, D. de, 347,367
Basili, V., 67 Charnpy, J., 4
Bass, L., 238, 513 Chapin, N., 276
Beizer, B., 282,290 Charette, R.N., 97
Belady, L., 219 Chen, P., 204
Bennett, S., 383 Chidamber, S.R., 427
Berard, E., 421,422 Chifovsky, E.J., 544
Berard, E.V., 344,355 Christel, M.G., 172
Bieman, J.M., 334 Churcher, N.I., 425
Binder, R.V.. 407,428,429 Ciclo de vida clasica. Ve'ase rnodelo secuencial lineal
Boal, I., 4 Clases. 346, 368-369
Boehm, B., 25,26,49,91, 134,306 clave, 429-430
Boock, G., 355,362,382 dependientes, 4 12
Bowan, J.P., 455 dispositivo de, 369
Breuer, P.T., 549 identificacion de, 350-353
Brooh, J., 4 interaction de, 369
Brooks, F., 9,21, 113 interdependientes,4 12
Buschmann, F., 385 propiedad de, 369
Clases-responsabilidades-colaboraciones(CRC), 368-371
consistencia, 410-412
estructuras, 371-372
Cadena definition-uso (DU), 292-293
jerarquias, 37 1-372
Calidad, 63-64,69,306, 324
subsistemas, 372
componentes reutilizables, 484-485 tarjetas indice, 368,369, 373,411
conceptos, 132-134 Clasificaci6n
control de variacibn, 132 de atributos y valores, 484
de concordancia, 132-133 enumerada, 483
de coste, 133 por facetas, 483-484
de diseiio, 132-133,220,221 Clements, P.C., 473
estgndares, 146-147 Clemm, G.M., 155
factores Cliente, 39, 169
extemos, 223 comunicacion, 25,46,79-80
intemos, 223 evaluacion, 25,46
ISO, 326 ligero, 5 10
de McCall, 234-235 pesado, 509
fallo, 134 reacci6n ante el concepto, 119
FURPS, 325-326 Coad, P., 346, 352,362-363, 382,386,387
medidas de, 94 Cobertura
mCtricas, 331-332 de enlaces, 296
movimiento, 134-135 de nodos, 296
prevencibn, 133 C6digo fuente, metricas, 336-337
transition a una vision cuantitativa, 326-327 Cohesion, 230,424
valoracion, 134 accidental, 230
variaciones entre muestras, 132 logics, 230
Cambio, 9- 10
metricas de, 334
ambito, 574 temporal, 230
Colaboraciones, 368,370-37 1 Contradicciones, 436
Coleccion de mktricas MDOO, 427 Control
COM de Microsoft, 480 cambio(s), 156-158
Comercio electronic0 formal, 158
arquitectura tkcnica, 501-502 individual. 158
descripcion, 499-500 proceso estadistico, 70-72
funciones, 500-501 sincronizacih, 158
tecnologias, 502-508 versiones, 155- 156
Complejidad, 423 Controlabilidad, 284
arquitectonica, 245 Controladores, riesgo, 101
ciclomitica, 287-288, 337 Conversion (mapping)
de datos, 333 arquitectonica, 245-246
mktricas, 335 de transacciones, 245-246
de operaciones, 428 de transformaciones, 247-252
Completitud, 325,424,436 Correcci611, 64,324
Componente(s) Coste, 485
actualizaci6n de, 474, 475 de la calidad, 133-134
adaptacion de, 474,475,479 empirico, 49
de la administracion de datos, 386-387 de presupuesto de trabajo
de administracion de tareas, 386 planificado (CPTP), 125-126
de aplicacion, 509,5 10-51 1 realizado (CPTR), 125- I26
clasificacion y recuperation de, 482-484 Counsell, S.J., 428
composicidn de, 474,475,480-481 Criterios de adaptacion, 117
cualificacion de, 193 Cuellos de botella, 505
diseiio de datos, 240-24 1 Cuestiones de context0 libres, 79-80, 183
de disponibilidad inmediata, 82.474 Cumplimiento de las estructuras, 278
distribution de, 509-520
de DOO, 385-387
estandar, 85 Datos, 576-577
de experiencia agrupar datos afines, 505-506
completa, 82-83 Davis, A,, 27, 188, 331-332
parcial, 474,475,479 Davis, M., 3 1
de gestion de recursos, 387 Decision hacer-comprar, 92-93
de interfaz de usuario, 386 arbol de decisiones, 93-94
JavaBean de Sun, 480-48 1 subcontratacion (outsourcing), 94
N, 154 Defectos,
nuevos, 83 ampliacion, 138
reutilizables, 193 impact0 del coste, 137-I38
de riesgo, 100- 101 Definicidn de objetos, 353
Composicion, 394-395 DeMarco, T., 42, 199. 200, 330. 331
Compresion de datos, 506 Dependencias
Comprobacion de cuenta, 370 de compartimiento, 245
Computadora de red, 5 10 flujo de, 245
Comunicaci6n restrictivas, 245
del cliente, 46 Depuracibn. 3 18
del equipo, 43-44 consideraciones psicol6gicas, 3 19
de procesos, 5 13-5 14 enfoques, 320-321
entre subsistemas, 387-388 proceso. 3 19
tkcnicas, 183-184 Desarrollo
Concentrador de impresion, 439-441 basado en componentes (DBC), 28-29,478-482,524
Concepto de la horda mongoliana, 9 de conceptos, 25
Concisibn, 325 rapid0 de aplicaciones (DRA), 22-23
Condicion, 274, 275 del software, matematicas, 437
compuesta, 291 de Webs, 564
de datos, 208 Descomposici6n, 84
Conectividad, 227 de proceso, 47
Configuracion del software, 10 de producto, 45
Conjunto de tareas, 16,25, 38 tkcnicas, 85-90
calculo del valor de seleccibn, 117-118 Descripcion(ones)
definicibn, 116- 117 de la informacion, 194
Consistencia, 325 funcional, 195
Constantine, L., 41,42 de objetos, 388-389
Construccidn de sistemas, 574-575 Descubrimiento de conocimiento en bases de datos
Contabilidad del estado, 159 (DCBC), 239
Contenido Despliegue de la funcion de calidad (DFC), 186-188
ejecutable, 503-504 Deutsch, M., 281
de la informacion, 189-190 Devanbu, P., 486
Dhama, H., 334 enfoque convencional VSP. 00,380-381
Diagrama(s) exactitud, 409
de burbujas, 206 mktodos, 382-383
de context0 del sistema (DCS), 176-177 metricas, 423-424
de flujo de control (DFC), 208 piramide, 380
creaci6n de, 2 13-214 pruebas, 409-410
creacion de, 2 10-211 plantillas, 528
entidad-relacion (DER), 200,204-205 principios, 222-223,528
de espina, 57 de procedimientos. Ve'ase Diseiio a nivel de componentes
de estado, 397 proceso, 22 1
de flujo de prueba basada en escenario, 415-417
de datos (DFD), 200-201,206-207,208 reglas de oro, 528
creacion, 2 11-2 13 para la reutilizaci6n,48 1-482
del sistema (DFS), 177 del sistema, proceso, 384-388
de Gantt, 123 de sistemas de negocio (DSN), 170
de transicion de estados (DTE), 183,209 tipos de, 220
Diccionario de datos, 200,206.2 15-216 visi6n general, 5 15-516
Dijkistra, E., 273-274 Disponibilidad, 143
Dimension, 85 Dispositivos
cambio, 85 de deteccion, 145-146
componente estindar, 85 poka-yoke, 145-146
de control, 6 1 Divisi6n estructural, 227-228
de datos, 6 1 Documentaci6n, 166,233,562-563
funcional, 6 1 pmeba de la, 300
logica difusa, 85 Dominio de la informaci6n, 189-190
punto de funcion, 85 valores, 60
Disefio, 234,563 Druker, P., 97
a nivel de componentes, 23 Dunn, R., 32 1
descripcion,273 Duplicacibn, 5 15
metricas, 333-335 de datos, 505
arquitectonico, 220,256,528-530 paquetes de, 504
analisis, 243-245
descripcion, 237
guia cuantitativa para, 244-245 Ecuacion de software, 92
metricas del, 332-333, 337 Eficacia de eliminaci6n de defectos (EED), 64-65
refinamiento del, 255 Eficiencia, 325
de sistemas CIS, 5 13-514 de ejecucion, 325
calidad de, 132 Eje de punto de entrada del proyecto, 25
de casos de prueba, 285,301 Ejogu, L.. 328
entre clases, 417-420 Elemento escalar, 228
convencional, 414 Encapsulamiento, 348,422-423,428
software 00,412-417 Encriptacion, 507-508
conceptos de, 223-229 Encubrimiento de caja
consistencia/uniformidaddel, 222 gris, 479
de datos, 220,239-240 negra, 479
a nivel de componente, 240-24 1 Entidades, 156
descripcion, 2 19 extemas, 176
efectivo, 229-23 1 Entomo
especificacion, 154.233 de desarrollo, 82
evaluacion, 225 de ingenieria del software (EIS), 84
para el fallo, 506 prototipos del, 193
formal, 461 Equipo
heuristicas, 23 1-232 centralizado y controlado (CC), 41
de usuario, 270 de descentralizado democratico, (DD), 41,42
descripcion, 259 descentralizado y controlado (DC), 41,42
evaluacion, 268-269 de ingenieria Web, 533-534
modelos, 262-263 administrador, 534
procesos, 263 desarrollador del contenido, 534
reglas de oro, 260-26 1 editor, 534
metodos de, 527-528 especialista de soporte, 534
de navegacion, 530-53 1 ingeniero, 534
de objetos, proceso, 388-390 proveedores, 534
orientado a objetos (DOO), 344,405 de software
aproximacion unificada, 383-384 coordinaci6n/comunicaci6n, 43-44
aspectos, 38 1-382 organizaci6n/estructura, 40-43
consistencia, 41 0-411 Errores, 3 11
descripcion, 379 deteccion de. 29 1-292
Errores (Cont.) diseiio de, 389-391
Iogica de, 286 internas, 549
tipograficos de, 286 jerarquicas, 529
Esfuerzo lineales, 528-529
distribuci6n, 115-116 en red, 529
personas, 114-116 reticulares, 529
Espacios, 503 Evaluacion y tCcnica de revision de programas (ETRP),
de diseiio cuantificado (EDC), 245 122-123
n-dimensional, 228-229 Exactitud, 325
Especificacion, 193-195 Expresi6n lbgica (Booleana), 291 -292
algebraica, 450-452 Extraccibn manual, 5 15
de control (EC), 201,208,213-214
de datos, 240-241
diseiio, 233 Facilidad de
de la estructura de cajas, 460-461,462 auditona, 325
de estado, 462,463-464 comprension, 284
negra, 462,463 prueba, 325
transparente, 462,464 atributos, 284
formal, 193 caracten'sticas,283-284
lenguajes de, 445 Factor de
notacibn matematica, 444-445 acoplamiento (FA), 427-428
funcional, 462-464 herencia de mCtodos (FHM), 427
principios, 194 polimorlismo (FP), 428
de proceso (EP), 20 1,206-207,2 14-215 Fallo(s), 506
representacibn, 194 del aiio 2000,3,4
de 10s requisitos del software, 194-195 dobles, 299
del sistema, 173, 177 multimodales, 299
Z, 446-447 simples, 299
Espiral WINWIN, 26-27 Fase de
Esquema del modelado del sistema, 176, 178 definicibn, 15
Estabilidad, 284 desarrollo, 15
Estado del sistema, 189 soporte, 15
Esthdares de Internet, 524 adaptacibn, 15
Estandarizacibn de correccibn, 15
la comunicaci6n, 325 mejora, 15
datos, 325 prevencibn, 15
rediseiio de datos, 55 1 Fecha limite, 112-113
Estilos arquitectbnicos, 24 1-242 Feigenbaum, E.A., 4
organizaci6n de, 243 Fenton, N., 327,333
refinamiento de, 243 Fiabilidad, 80, 143,324,326
taxonomia de, 24 1-243 disponibilidad, 143
Estimacibn, 78.84 medidas, 143
automatizada, 84 Firesmith, D.G., 369
basada Firma digital, 508
problemas, 86-87 Fleming, Q.W., 125
procesos, 89 Flexibilidad, 325
ejemplo basado en procesos, 89-90 Florac, W.A., 53
empirica, 84 Flujo de
Lineas de c6digo (LDC), 85-88 control, 208
00,299-300 datos, 242
Puntos de funci6n (PF), 86-87, 88 arquitecturas, 242
Estrategia de prueba, 321 continuo en el tiempo, 207
aspectos, 309-310 discreto, 207
depuracibn, 3 18-321 grafo de, 206
descripcibn,305 pruebas, 292-293
enfoque, 306-309 informacibn, 189-190
integracibn, 3 12-315 modelo, 205-209
organizacibn, 307 transaccih,246
sistema, 3 17-318 transformacibn,246
unidad, 3 10-312 Formacibn,325
validacibn, 3 16 Fragmentacibn, 274,5 15
Estructura(s) de Freedman, D.P., 137
anllisis del trabajo (EAT), 122 Freeman, P., 237
datos, 228-229.239 Funci6n de
jerkquicas, 228-229 ayuda
la informacibn, 189-190 complementaria, 267
programa. 226-227,229 integrada, 267
Funcidn (Cont.) individual, 7 1
. pmeba, 300 rangos en movimiento (Rm), 70
caracterizaci6n,477 de tiempo, 123-124
compendia de mensajes, 508 Grafo, 350
FURPS, 325-326 de evolucih, 155, 156
Gran conocimiento del sistema, 505
Gmpo independiente de prueba (GIP), 307
Gaffney, J.E., 62 Guiones de escenario, 429
Gamma, E., 379,390
Gane, T., 200
Garantia de la calidad del software (SQA), 148
actividades, 136 Habilidad de codificar, 279
antecedentes, 135- 136 Halstead, M., 337
definicion. 135 Hammer, M., 5.54 1, 542
descripcion, 13 1- 132 Hardware, 5, 166
estadistica, 14 1- 142 Hares, J.S., 170
plan, 147 Harrison, R., 428
Garlan, D., 226, 238 Hatley, D.J., 208
Gause, D.C., 79-80, 183 Henderson, J., 460
GCI, 785 Henry, S., 333
Generacion de Herencia, 348-349,423,429
codigo, 461 multiple, 349
una aplicacion, 22 Herramientas, 14
Generadores de pantallas, 564 capa, 567
Generalidad, 325 dinimico, 564
Generalization, 394 estitico, 564
Gestion de desarrollo, 564
de la configuracion del software (GCS), 159-160 de gestion ,562
categonas, 152 de pmebas, 565
descripcibn, 15 1 de implementaci6n, 268
elementos, 78 de programacion, 564
identificacion de objetos, 154-155 taxonomia, 561-565
IWeb, 536-537 Herron, R., 574
lineas base, 152- 153 Hetzel, W., 301
proceso, 154 Hinchley, M.G., 455
de programas relacionada con el personal, 50 Hindley, P.G., 476
de proyectos, 534-535,562 Hopper, M., 573
basada en metricas, 50 Humphrey, W., 56, 125
descripcion, 37 Hutchinson, J.W., 476
expectacion/rendimiento, 536
inicio de un proyecto, 535
personal, 38
proceso, 38 Identification de
producto, 38 objetos
proyecto, 39 bisicos, 154
de riesgos formal, 49 compuesta, 154
total de calidad (GTC), 135 requisitos, 183-188
atarimae hinshitsu, 135 inicio del proceso, 183- 184
kaizen, 135 Incertidumbre estructural, 78
miryokuteki hinshitsu, 135 Incompletitud, 437
Gestor(es) Independencia
de bloques, 439,444-445 funcional, 229-230
superiores, 39 del hardware, 325
(tkcnico) de proyectos, 39 !ndicadores de proceso, 55
Gilb, T., 309 Indice de
Glass, R., 332 errores (IE), 142
Gnaho, C., 530 especializacion (IE), 427
Goethert, W.B., 53 espectro, 244
Gooldman, N., 194 Informacibn, 576-577
Grado de rigor, 117 Informe de
casual, 117 cambio, 157
estricto, 117 estado de configuraci6n, 159
estructurado, 117 Ingenieria, 25,45-46
reaccion rapida, 117 del software basada en componentes (ISBC), 486
Grady, R.G., 56,57,65 actividades, 474-475
Grifico(s) de descripcih, 473-474
control, 70 econdmica de, 484-486
Ingenieria (Cont.) objeto, 265-266,5 15-516
proceso, 475 reducir la carga de memoria del usuario, 260-26 1
de componentes del sistema, 17 1 de usuario, 550,552-553
directa, 547,551-552 Internet, 3
arquitectura 0 0 , 553 Interoperahilidad, 325
clienteJservidor,552-553 Invanante de datos, 438
interfaces de usuario, 553-554 IS0
del dominio, 362, 366,476-478 9000-3, 146
de informaci6n, 20 9001, 146-147
inversa, 546, 547-548 9004-2, 146
datos, 549-550 9126,326
interfaz de usuario, 550 Iteraci6n del diseiio de procesos, 5 16
procesamiento, 548-549
de proceso de negocio (IPN), 169- 170, 178,561-562
de producto, 17 1, 178 Jackman, M., 42
de requisitos, 171, 172 Jackson, M.A., 223.227
analisis, 173 Jacobson, I., 187,362,382
especificaci6n, 173 Jerarquia(s) de
gestion, 174-175 clases, 4 16
identificaci6n, 172 control, 226-227
modelado, 174 tipos de objetos de datos, 204
negociaciones, 173 Juego de herramientas de la interfaz de usuario. 268
validation, 174
de sala limpia, 29,469
caracteristicas, 46 1 Kafura, D., 333
definicih, 3, 14 Kahn, P., 528
descripcion, 459 Kaizen, 135
enfoque. 460-462 Kang, K.C., 172
estrategia, 460-46 1 Kapln, C., 134
futuro, 573-579 Kautz, K., 72
importancia, 574 Kidd, J., 356,426, 427
paradigma, 19 Kirani, S., 418
proceso nuevo, 575-576 Kit de Desarrollo Bean (BDK), 481
pruebas, 467-469 Koppleman, J.M., 125
sistemas CIS, 5 12 Kraul, R..44
vision genCrica, 14- 16
de seguridad, 507
de sistemas, 178 Lano, K., 549
descripcion, 165 Larcher, F., 530
jerarquia, 167-169 Latencia, 506
del software, 7 Legibilidad para la computadora, 278
asistida por computadora (CASE), 9, 14 Lenguaje(s)
bloques de construcci6n, 560-561 de descripcion arquitectonica(LDAs),226
descripcion, 559 de diseiio de programas (LDP), 276-277
taxonomia, 561-565 ejemplo, 277-278
Web (IWeb), 537-538 de interconexion de modulos (LIM), 155
atributos, 522-524 estructurado. VPase Lenguaje de diseiio de programas (LDP)
descripci6n,52 1-522 unificado de modelado (UML), 29,363-364,383-384,393-397
estimation, 534-535,536 estudio de un caso, 398-400
marco de trabajo, 525-526 Leveson, N.G., 144
problemas de gestion, 533-537 Levy, J., 336
proceso, 525 Libros en linea, 398-400
subcontratacion (outsourcing), 534,535-536 Liderazgo
Inspection. Viase Revisiones ttcnicas formales (RTF) caracteristicas, 40
Instantanea, 5 15 rasgos, 40
Instituto de Ingenieria del Software (SEI), 16, 18, 136 Limite del proceso natural
libro de guia, 73-74 inferior, 71
Instrumentaci6n, 325 superior, 7 1
Integracih, 564 Lineas de c6digo (LDC), 58,62-63
Integridad, 64 ejemplo de estimacibn, 87-88
Interfaz estimaci6n,86-87
action, 265-266 Linger, R.M., 465,466
construccion consistente, 26 1 Lister, T., 42
dar el control a1 usuario, 260 Localizaci6n, 422
diseiio, 220, 266-268,531-532,564 L6gica en tiempo real, 144
grifica de usuario (IGU), pruebas, 299-300 Lorenz, M., 356-357,426,427
hombre-miquina, 337 Lowe, D., 523
MACA, 244 desarrollo, 67,69-70
Madurez del proceso, 16- 18 de diseiio 00,423-424
definicibn, 16- 17 establecimiento de programas para, 72-74
gestionada, 17 etiqueta, 56
inicial, 17 evaluacih, 66
optimizacih, 17 de integracibn con objetos, 66
repetible, 17 linea base, 66
Mandel, T., 260-261 de mantenimiento, 338
Mantei, M., 41 del modelo
Mantenibilidad (capacidad de mantenimiento), 64,278,325, 326 de analisis, 329-336
Mantenimiento, 338,544-545 de diseiio, 332-336
Marco de proceso comun, 16 de organizaciones pequeiias, 72
00,355-356 orientadas a
Matemiticas, 437,441 clases, 424-428
aplicacibn, 444-445 funciones, 59-61
conjuntos, 441-442 objetos
especificacibn constructiva, 441 -442 caractensticas, 422-423
sucesiones, 443 descripcibn,421
Matrices de grafos, 290 propbsito,422
McCabe, T.J., 335 operaciones. 428
McCall, J.A., 324-325, 326 tamaiio, 59
McCorduck, P., 4 privadas, 56
McGlaughlin, R., 221 de proceso, 55-57,69-70
McMahon. P.E.. 478 de producto, 58
Medicibn, 69, 74 de proyecto(s), 58-59
calidad, 63-65 00,356-357,428-430
definicion, 53, 54 de prueba, 337
descripcibn, 323-324 pliblicas, 56
directa, 58 punto de funcibn ampliado, 61-62
indirecta, 58 reconciliacibn de diferentes enfoques, 62-63
principios, 328 de reutilizacibn, 486
razones, 53 de software sencillo, 72
Medida, descripcibn, 54 tkcnicas, 43
Mejora marco de trabajo, 327-329
estadistica del proceso de software (MEPS), 56-57 reto de, 327
del proceso del software, 55-57 de validez estadistica, 70-72
Mellor, S., 207 Meyer, B., 225
Mensajes, 347-348 Miller, E.. 306
de error, 267-268 Mills, H.D., 460
Merlo, E., 554 Mitigacibn, monitorizacibn y gestibn del riesgo (MMGR), 102,
Mktodo(s), 14, 347 105-106, 107
del camino critic0 (MCC), 122-123 Mitos, 8
formales, 456 de clientes, 9-10
basados en objetos, 447-450 de desarrolladores. 10
conceptos basicos, 436-441 de gestibn, 9
concurrentes, 452-455 Modalidad, 203
descripcibn, 435 Modelado, 190
10s diez mandamientos de, 455-456 de analisis, 512
futuro, 456 actividades del, 171
modelo, 29 descripcibn del, 199
preliminares matematicos, 441-443 elementos del, 200-201
ponderados por clase (MPC), 425 del comportamiento, 209-210
Mktrica(s), 17,426-427 de datos, 22, 154, 189
acoplamiento, 334-335 cardinalidad, 203
de argumentos a favor, 65-66 elementos, 201-203
atributos, 328-329 modalidad, 203-204
bang, 330-33 1,337 representaci6n grafica, 204-205
calculo, 33 1 estructural, 363,477-478
basadas en funciones, 329-330 funcional, 190
calculo, 66 del negocio, 22
de calidad, 63-65 de procesos, 22,562
de especificaciones, 33 1-332 del sistema, 167-168, 174, 175-177
de cbdigo fuente, 336-337 limitaciones, 168
de cohesibn, 334 preferencias, 168
de coleccibn, 66 restricciones, 168
complejidad, 335 simplificaciones, 168
definicibn, 53,54 supuestos, 167-168
~ N D I C EDE MATERIAS
Modelo(s) descendientes (NDD), 425,429

de andisis, 21 escenarios (NE), 429
particionar el, 384-385 operaciones
de caos, 19 aiiadidas por una subclase (NOA), 427
de clases, 393-394 redefinidas para una subclase (NOR), 427
de cornportamiento, 190 padres directos (NPD), 429
pruebas, 4 19-420 parhetros por operaci6n promedio (NPp,,), 428
UML, 363-364 subsistemas (NSUB), 430
dinimicos, 226
de diseiio, 222,233
de estimacion Objetivo, pregunta, metrica (OPM), 67-69
COCOMO, 9 1-92 aplicaci6n,68-69
empiricos, 90-92 entomo, 68-69
estructura, 90 perspectiva, 68-69
estructurales, 226 prop6sito,67
fundamental del sisterna, 206 Objetivos
de implementaci6n,364 del ciclo de vida (OCV), 27
de intercambio de datos, 480 de las pruebas, 282
de madurez de capacidad (MCM), 16-17 Objeto
del marco de trabajo, 226 de aplicacidn,5 16
MOI, 40 de datos asociativo, 205
de objetos, 480 2,447-450
identificaci6n de elementos, 350-354 Objetos, 346
comportamiento, 374-376 de datos, 201-202
relacibn, 373-374 distribuidos, 502-503
recursive paralelo, 344-345 identification, 350-352
de proceso(s), 19,226 Observabilidad, 283
de prototipos, 21-22 Ocultamiento de informaci6n,229,423
DRA, 22-23 OMGICORBA, 480
evolutivo, 23-28 Operacidn dibujo, 350
desarrollo concurrente, 27-28 Operaciones, 347,438
espiral WINWIN, 26-27 definicibn, 353-354
espirales, 24-26 mktricas, 428
incrementales, 23-24 Operadores matemkicos
secuencial lineal, 20-2 1 de conjuntos, 442-443
de redes de Petri, 144 Idgicos, 443
catarata. Ve'ase Modelo de proceso secuencial lineal Operatividad, 283, 325
de usuario, 363 Orden de cambio de ingenieria (OCI), 157-158
Modularidad, 224-225,278,325 Orientaci6n a objetos (OO), 358-359
Modulos arquitectura, 553
de trabajador, 227-228 conceptos de, 345-350
eficaces, 23 1-232 descripcidn de, 343
Monarchi, D:E., 366 enfoque para planificaci6n, 357-358
Monitores de transacciones, 504 estimaci6n,356-358
Musa, J.D., 308 gestidn de proyectos, 354-358
Myers, G., 234 metricas de proyecto, 356-357,429-430
Myers, W., 80 paradigma, 344-345
seguimiento del progreso, 358
Originalidad, 424
Naisbitt, J., 4 Osborne, A., 4
Nannard, M., 527 Osbome, W.M., 544
Negociacibn, 26, 173 Ott, L.M., 334
Nielsen, J., 336
Nithi, R.V., 428
Nivel de Page-Jones, M., 37,200
clase, prueba, 417-418 Paquetes
referencia del riesgo, 103 cliente/servidor (CIS), 504
Notaci6n de seguridad, 504
de diseiio Paradigma(s)
comparaci6n,278-279 abiertos, 42
grifica, 274-276 aleatorios, 4 1
tabular, 390,527-528, 530 cerrados, 4 1
de grafo de flujo, 286-287 de mejora de calidad, 67
Numero de sincronos, 42
clases clave Paralelismo, 506
(NCC), 429-430 Park, R.E., 53
(NCR). 429 Partici6n. 190-191
Particion (Cont.) efectividad, 283
, basada en atributos. 418 exhaustivos, 283
basada en categorias, 41 8 de menor a mayor, 283
basadas en estados, 418 de Pareto, 283
equivalente, 296-297 planificacibn, 283
pruebas, 417-418 seguimiento hasta 10s requisites del cliente, 282
Participantes, 183 W ~ H H49 ,
Partidario, 39 PROISIM, 563
Patrones de disefio, 390,528,530 Problemas
ciclo, 530 de alcance, 172
contomo, 530 de comprension, 172
contrapunto, 530 volatilidad, 172
descripcion, 390-391 Procedimiento(s), 166
filtro, 392-393 de software, 229
futuro, 393 Procesamien to
Memento, 391 -392 central (host), 492-493
mundo de espejo, 530 de datos, 189
Singleton, 39 1 Proceso(s), 14, 38
tamiz, 530 automatico, 278
vecindario, 530 caracteristicas, 16
Peligros, 106 de comprobaci6n de entrada y salida, 158
Personal, 38, 166,537,574-575 de desarrollo de software unificado, 29
equipo de software, 40-43 descomposicibn, 47
jefes de equipo, 40 descripcion. 13
participantes, 39 indicador, 55
Peticion de cambio, 156 integration con metricas, 65-66
Phadke, M.S., 298,299 secuenciales intercomunicados (PSI), 452-455
Phillips,D., 86 de software personal, 56
Pirbhai, I.A., 208 Productividad, 485
Planificacion, 25 Producto, 3 1,38
de contingencia, 105-106 Bmbito, 44-45
de la comprobaci6n estadistica, 46 1 descomposicion, 45
de la estrategia de informaci6n, (PEI), 170 Programacion
de incrementos, 460 estructurada, 274-278
de proyectos, 127 orientada a objetos (POO). 344, 400-403
decision hacer-comprar, 92-94 impacto en pruebas, 414-4 15
descomposicion, 85-90 Programas legales, 16
descripcion, 77 Protocolo(s), 497
estimacibn, 84 conceptos, 498
herramientas de estimacion automatizadas, 94-95 HTTP, 499
modelos de estimacion empiricos, 90-92 ICMP, 498
objetivos, 79 IP, 498
recursos, 82-83 POP3,498
NNGR, 107 de presentacion, 567
en tiempo Prototipo(s), 21-22, 192,543, 564
conceptos basicos, 112-114 desechables, 193
desarrollo, 536 entomos, 193
descripcion, 111 evolucionario, 193
detallada, 113 evolutivo, 193
estimacion, 49 herramientas, 193
herramientas/tCcnicas, 122- 125 mCtodos, 193
lineas generales, 114 selection de enfoque, 158
macroscopico, 113 Proyeccion del riesgo, 101
00,357-358 evaluaci6n del impacto. 103
relacion personal/esfuerzo, 114-116 tabla, 101-103
riesgo, 100 Proyecto(s)
seguimiento, 124 complejidad, 78
Polimorfismo, 349-350 desarrollo de aplicaciones nuevas, 116
Pollak, W., 477 de desarrollo de conceptos, 1 16, 119
Porcentaje publico y protegido (PPP), 429 ambito, 119
Portabilidad, 325, 326 evaluaci6n de riesgos de la tecnologia, 119
Powell, T.A., 522 implementation, 119
Prictica de software critico, 49-50 planificacion preliminar, 119
Pressman, R., 574 prueba, 119
Prieto-Diaz, R., 476 reaccion del cliente, 119
Principio(s) enfoque, 48
de las pruebas, 282-283 indicador, 55
Proyecto(s) (Conr.) de recuperacion. 3 17
mantenimiento de aplicaciones, 116 de rendimiento, 3 18
mejoras de aplicaciones, 116 de resistencia (esrre's), 3 18
planificacion, 49 de seguridad, 3 17-3 18
reingenieria, 1 16 del sistema, 301, 3 17
tamafio, 78 delegation de culpabilidad, 3 17
Prueba(s), 5 16. 564 recuperacion, 3 17
a nivel de clase, 417-418 rendimiento, 3 18
de agrupamiento, 41 1 resistencia (estrh), 3 18
alfa, 3 16 seguridad, 317-3 18
basada(s) en, en tiempo real, 300-301
escenarios, 415-4 17 del software
fallos, 4 14-4 15 descripcion, 28 1-282
grafos, 294-296 fundamzntos, 282-284
hilos, 4 13,420 de la tabla ortogonal, 298-299
usos, 4 12 tacticas CIS, 5 18
beta, 293 entre tareas, 301
de bucles, 294 de transacciones, 5 17
anidados, 294 de unidad, 307-308
concatenados, 294 consideraciones, 3 10-311
no estructurados, 294 contexto 00,410-411
simples, 293 procedimientos, 3 11-312
de la caja de validacibn, 3 16
blanca, 285,286 alfa y beta, 3 16
negra, 294-299,302 contexto 0 0 , 4 1 1
de camino base, 286 criterios, 3 16
de ciclo rhpido, 309-3 10 revisi6n de configuration, 316
de clase multiple, 418-419 Pseudocodigo. Ve'ase Lenguaje de disefio de programas (LDP)
cliente/servidor, 300 Puhr, G.I., 366
de cornparacion,297-298 Puntos
de comportamiento, 301 de caracteristlcas, 61
de comunicaci6n de redes, 5 17-5 18 de estructura, 477-478,485-486
de condicion, 29 1-292 de fijacion, 26
criterios para completar, 308-309 de funci6n (PF), 60-61, 85
documentacion, 300 ampliados, 6 1-62
del dominio, 29 1 ejemplo de estimac~on,88
y entrega. 23 estimacih, 86-87
estadistica de casos pricticos, 467-468 tres dimensiones,
de estrategia CIS, 5 16-5 17 Putnam, L., 80
estructura
de control, 291 -294
profunda, 41 7 Raccoon, L.B.S., 19
de superficie, 417 Recolecci6n de requisites, 460
facilidades de ayuda, 300 Recursos
de funci6n de la aplicacion, 517 de entomo, 83
herramientas CIS, 565 humanos, 82
IGU, 299-300 Red de tareas, 121-122
impact0 de la programacion 0 0 , 3 15 Rediseiio de datos, 55 1
de integraci6n, 31 2,413,420 Reel, J.S., 48
ascendente, 3 13-314 Reestructuracion de, 550-55 1
contexto 0 0 , 4 1 3 codigo, 546,550-55 1
descendente, 3 12-313 datos, 546-547, 55 1
estudio, 3 15 documentos, 546
humo. 3 14-3 15 Refmamiento, 224,464-465
regresibn, 3 14 paso a paso, 224
de limites, 3 11 Region(ones) de
de mano a mano, 298 defectos, 298
mktricas, 337 tareas, 26
modelo de Regla 90-90,48
AOO, 409-410 Regla (Conr.)
DOO, 409-4 10 de zona, 7 1
del operador relational y de ramificackin (BRO), 292 Reifer., D.J., 181
orientadas a objetos (OO), 409-419,420 Reingenieria
descripcion, 409 coste-beneficio, 554
estrategias, 41 2 descripci6n,541-542
mktricas, 428-429 economia de la, 554
de ramificaciones, 29 1 herramientas. 565
tNDICE DE MATERIAS
Reingenieria (Cont.) Sarson, C., 200

, del proceso de negocio (RPN), Sawyer, P., 172
creaci6n de prototipos, 543 Sears, A., 335
definition del negocio, 543 Seguimiento
descripcion, 542 de defectos, 50
especificacion y disefio de procesos, 543 de errores, 126- 127
evaluaci6n de procesos, 543 para ganar valores, 50
identificacion de procesos, 543 de requisitos, 562
modelo, 543 Seguridad, 144,325,524
principios, 542-543 de calidad estadistica, 141-142
refinamiento e instanciacibn, 543 Serie de mCtricas CK, 425-430
del software, 544-545, 555 Senicios, 347
modelo de procesos, 545-547 de gestion de herramientas (SGH), 567
Relaciones, 202-203, 296 Senidor(0res). Ve'ase tambie'n Sistemas cliente/senidor (CIS)
reflexivas, 296 de aplicacion, 494
Repeticion, 274-275 de archivos, 493
Representacion de de bases de datos, 493,501-502
datos, 278 de conferencia, 501
estados, 375-376 de correo, 494,501
Requisitos dedicados, 506
directrices de representation, 194 de impresi6n,494
esperados, 186 de monitorizaci6n, 502
innovadores, 186 de objeto, 494
normales, 186 pesado, 509
Resoluci6n de problemas, de gestion, 40 de software de grupo, 493-494
Responsabilidades, 368,369-370 Web, 494,501
Respuesta para una clase (RPC), 426 Shaw, M., 226,238
Reusabilidad (capacidad de reutilizaci6n), 82-83, 325 Shepperd, M.J., 425
Reutilizacion,364,482-484 Shingo, S., 145
aprovechamiento de, 486 Shneiderman, B., 259
de componentes, 482-484 Shooman, M.L., 305
economia, 484-485 Simetria, 296
entomo, 484 Similitud, 424
mttricas, 486 Simplicidad, 284,325
Revision(ones) Sirnulacion del sistema, 168
de configuration, 3 16 Sistema(sj
estructurada vkase. Revisiones ttcnicas formales (RTF) basados en Web
tCcnicas formales (RTF), 10, 137 analisis, 527
construccion, 3 10 formulacion, 526-527
descripcion, 138-139 de bases de datos orientados a objetos (SBDOO), 344
directrices, 140-14 1 de clasificaci6n de cinta transportadora (SCCT), 8 1, 176-177
informe, 140 cliente/senidor (CIS), 27, 518. Vkase tambikn senidores
registro, 140 categon'as, 493-494
reunion, 139 componentes software, 509-512
utilizaci6n,3 10 descripcion, 49 1
Riesgo disefio, 513-516
analisis, 25,46, 107,562 enlazado, 5 11
caracteristicas, 98 ingenieria del software, 5 12
componentes, 100-101 modelos, 492-493
conocido, 99 pruebas, 300,518,565
controladores, 100- 101 complejos, 166
definicion, 97 de desarrollo de la interfaz de usuario (SDIU), 268
estimation, 101-104 definicion, 166
evaluacion, 100-101, 103-104 distribuidos, 492-497
de la tecnologia, 119 compartimento de recursos, 492
identificacibn, 99-101 diseiio de, 504
negocio, 98-99 rendimiento, 492
proyecto, 98 tolerancia a fallos, 492
reactivo frente a proactivo, 98 de tiempo real, 207
refinamiento, 104 extensiones
seguridad, 106 Hatleypirbhai, 208-209
del soporte, 101 WardiMellor, 207-208
Rissman, M., 477 pruebas, 300-301
Robinson, H., 145 Sitaram, P., 27
Roche, J.M., 328 Sobrecarga, 350
Ross, D., 200 Sockets (Conexiones), 502
Rumbaugh, J., 362,366,373,382,387 Software, 166
f N D l C E DE MATERIAS
software (Cont.) Tkcnica(s)

aplicacion, 5 14 de cuarta generation, 30, 193
aplicaciones, 6-8 de modelado de objetos (TMO), 382
basado en Web, 8 para facilitar las especificaciones de la aplicacion (TFEA),
calidad, 22 1 80, 184-186 (1 1.2.2.)
caractensticas, 4-6 Tecnologia(s), 506,577-578
cientifico, 8 infraestructura, 23 1
de computadora personal, 8 de objetos, 28
desarrollo, 5 del proceso, 31,38
description, 3 Tiempo
crisis en, 8 medio de fallo (TMDF), 143
curvas de fallos, 6 de respuesta del sistema, 267
de deterioro, 5-6 Tillmann, G., 203
ensamblador, 6 Toffler, A., 4
evoluci6n del disefio, 221 Tolerancia a1 error, 325
historia, 4-6 Toxinas del equipo, 43
insertado, 7 Transmision, 504
intermedio (middleware), 494-495,509, 5 11-512 Trazabilidad, 325
ejemplo, 495 tablas, 175
de inteligencia artificial, 7 Tsai, W.T., 418
de negocio, 6
de prueba de errores, 145-146
Quality Engineering (SQE), 564 Ullman, R., 321
de sistema, 6, 563 Usabilidad, 64, 326
en tiempo real, 6 Usuario final. 39
Sommerville, L., 172
Streeter. L., 44
Subclase, 346 Vaguedaz, 437
Subcontratacion (outsourcing), 94,534,535 validacion, 306
Subsistemas, 387-388,430 criterios, 195
aplicacion, 509, 510-5 11 requisitos, 174
asignacion, 385 Valor de seleccion del conjunto de tareas, calculo, 117-118
enlazado de software CIS, 511 interpretation, 119
gestion de bases de datos, 509 Van Vleck, T., 320
interacci6n/presentaci6n de usuario, 509 Variabilidad, 267
Sucesion, 274,275 Variantes, 155-155
Suficiencia, 424 Verification, 306,464-467
Superclase, 346 de correccion, 461
de logica, 278
Visibilidad, 424
Tabla de
Vision esencial, 191-192
activation de procesos, 209
Vista
decision, 276
simbolos, 438-439 del entorno, 364
de irnplementacion, 191-192
Tai, K.C., 292
Volatilidad, 424
Talbot, S., 4
Tamafio
clase (TC), 426-427 Ward, P.T., 207
medio de operacion (TO,,,,,), 528 Wamier-Orr, J., 227
Tareas Wasserman, A., 223
de adaptacion, 25 Weinberg, G.M., 79, 137, 183
asignacion de tiempo, 114 Weinberg, J., 40
compartimentalizaci6n, 114 Whitmire, S., 423
concurrentes, 385 Wilkens, T.T., 125
de construcci6n,25 Wirf-Brock, R., 363, 369, 370, 382
hitos definidos, 114 Wirth, N., 224
interdependencia, 114
productos definidos, 114
prueba, 300-301 Yourdon, E., 4, 31 1,346,352,362-363,382-386, 387
refinamiento, 120-121
responsabilidades definidas, 114
seleccion, 119-120 Zhao, J., 245
validacion de esfuerzo, 114 Zultner, R., 70

Ingenieria de SOFT Un Enfoque Practico P PDF

Cargado por

Copyright:

Formatos disponibles

Ingenieria de SOFT Un Enfoque Practico P PDF

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Ingenieria de SOFT Un Enfoque Practico P PDF

Cargado por

Copyright:

Formatos disponibles

ACERCA DEL AUTOR.

PARTE PRIMERA: EL PRODUCT0 Y EL PROCESO

PARTE SEGUNDA: GESTION DE PROYECTOS DE SOFTWARE

PARTE TERCERA: METODOS CONVENCIONALES PARA LA INGENIERIA DEL SOFTWARE

PARTE CUARTA: INGENIERIA DEL SOFTWARE ORIENTADA A OBJETOS

CAPITULO 28. INGENIERIADEL SOFTWARE DEL COMERCIO ELECTRONICO

PARTE PRIMERA: EL PRODUCTO Y EL PROCESO

CAPITULO 4: PROCESO DE SOFTWARE Y METRICAS DE PROYECTOS, 53

CAPITULO 6: ANALISISY GESTION DEL RIESGO, 97

CAPITULO7: PLANIFICACION TEMPORAL Y SEGUIMIENTO DEL PROYECTO, 111

7.2. LA RELACION ENTRE LAS PERSONAS Y EL ESFUERZO, 114

CAPITULO 8: GARANTIA DE CALIDAD DEL SOFTWARE (SOAIGCS), 131

CAPITULO 9: GESTION DE LA CONFIGURACION DEL SOFTWARE (GCSISCM), 151

PARTE TERCERA: METODOS CONVENCIONALES PARA LA ~ N G E N ~ E R IDEL

SISTEMAS BASADOS EN COMPUTADORA, 167

ANALISIS DE REQUISITOS, 182

CAPITULO 12: MODELADO DEL ANALISIS, 199

CAPITULO 13: CONCEPTOS Y PRINCIPIOS DE DISENO, 219

13.5.1. INDEPENDENCIA FUNCIONAL, 229

CAPITULO 14: DISENO AROUITECTONICO, 237

CAPITULO 15: DISENO DE LA INTERFAZ DE USUARIO, 259

15.5. HERRAMIENTAS DE IMPLEMENTACION, 268

CAPITULO 16: DISENO A NIVEL D E COMPONENTES, 273

CAPITULO 17: TECNICAS DE PRUEBA DEL SOFTWARE, 281

CAPITULO 18: ESTRATEGIAS DE PRUEBA DEL SOFTWARE, 305

CAPITULO 19: METRICAS TECNICAS DEL SOFTWARE, 323

CAPITULO 20: CONCEPTOS Y PRINCIPIOS ORIENTADOS A OBIETOS, 343

CAPITULO 21: ANALISIS ORIENTADO A OBJETOS, 361

CAPITULO 22: DISENO ORIENTADO A OBJETOS, 379

CAPITULO 23: PRUEBAS ORIENTADAS A OBJETOS, 407

23.4.2. APLICABILIDAD DE LOS METODOS CONVENCIONALES DE DISENO DE CASOS DE

CAPITULO 24: METRICAS TECNICAS PARA SISTEMAS ORIENTADOS A OB.IETOS, 421

CAPITULO 25: METODOS FORMALES, 435

25.3. APLICACION DE LA NOTACION MATEMATICA PARA LA ESPECIFICACION

CAPITULO 26: INGENIERIA DEL SOFTWARE DE SALA LIMPIA, 459

CAPITULO 27: INGENIERIA DEL SOFTWARE BASADA EN COMPONENTES, 473

27.6.3. METRICAS DE REUTILUACION, 486

CAPITULO 28: INGENIERIA DEL SOFTWARE DEL COMERCIO ELECTRONICO

28.9. COMPONENTES DE SOFTWARE PARA SISTEMAS CIS, 509

CAPITULO 29: INGENIERIA WEB, 521

CAPITULO 30: REINGENIERIA, 541

30.1.3. UN MODEL0 DE RPN, 543

CAPITULO 31: INGENIERIA DEL SOFTWAREASISTIDA POR COMPUTADORA, 559

CAPITULO 32: PERSPECTIVASFUTURAS. 573

Definicion del termino <<Ingenieriadell Software>>

El tCrmino Ingenieria se define en el DRAEZcorno: <<I. Conjunto de conocimientos y tCcni-

Ingenieria de Software es el estudio de losprincipios y metodologias para desarrollo y man-

Ingenieria del Software es la aplicaci6n prdctica del conocimiento cientifico en el disefio

' En Hispanoamerica, el termino utilizado normalmente es: Ingenieria de Software.

La aplicaci6n de un enfoque sistemdtico, disciplinado y cuantificable a1 desarrollo, opera-

Tomando como base la referencia de estas definiciones seleccionadas, se producen de inme-

Inspecci6n de software critico.

EL LIBRO COMO TEXT0 DE REFERENCIA UNIVERSITARIA

La importancia fundamental de la disciplina Ingenieria del Sofh.mre se esti manifestando, de mod0

1. Conceptos fundamentales de resoluci6n de problemas.

En Espaiia, el Consejo de Universidades, organism0 encargado de dictar directrices y nor-

Madrid, septiembre de 1997

Luis Joyanes Aguilar

NUEVOS RECURSOS DOCENTES Y PROFESIONALES